[ECOS] Request for comments onCYG_I2C_BITBANG_SCL_LOW_SDA_INPUT patch

Newsgroups Reader mail_lists@telus.net
Fri Mar 10 19:19:00 GMT 2006


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



More information about the Ecos-discuss mailing list