This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Request for comments onCYG_I2C_BITBANG_SCL_LOW_SDA_INPUT patch


On Fri, 2006-03-10 at 17:38 +0000, Bart Veer wrote:
> ...
>
> Of course (2) should never be necessary, hardware should always be
> designed sensibly. However the current bit-banging code was intended
> to work on somewhat broken hardware as well. The platform-specific
> banger function is given operations such as SCL_LOW_SDA_INPUT rather
> than just SCL_LOW, so that it can implement these in a way appropriate
> for the target hardware.
> ...

I agree with Bart on this. The separation of SCL_LOW_SDA_INPUT and
SCL_LOW makes it possible to handle any quirks in the hardware in the
implementation for just that hardware.

On our platform, I saw the potential for problems (never actually saw a
problem, though) and so I disabled interrupts in the banger function as
mentioned by Bart. Nice to see a second opinion that confirms it.

I do have an issue with the I2C stuff. Some of the (larger?) I2C eeproms
use parts of the I2C device address mixed with the read/write address
to...er...address(!) the location within the device to read/write.

The way it works now, my I2C eeprom has to appear as 4 different I2C
devices. It kinda sucks! I think the I2C bus should be
defined/abstracted as is, but the actual I2C devices shouldn't be. I
guess this would mean passing around an I2C device address to the
functions, but at least you would be able to generate I2C device
addresses "on the fly".



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]