Re: [ECOS] Software I2C

[Andrew Lunn <andrew dot lunn at ascom dot ch>]

On Mon, Jul 07, 2003 at 10:45:45AM +0200, Slawek wrote:
> Hello,
> 
> 
> 
> I'm going to implement I2C master support in software.

By in software, do you mean you are going to use GPIO pins?

How much time do you have to spend in this? Is it going to be
something quick, or can you spend some time to produce a generic
layered set of drivers, support for multiple devices, hardware
abstraction etc. So you can have at the bottom layer a driver which
toggles actual lines/reads lines. Above that a generic bit banger
layer, and above that generic I2C master support. This layering gives
the flexibility for someone with different hardware to replace the
software bit banger layer with eg pcf for the philips chipset.

> I don't like the idea of tight-loop style delays.
> 
> Is there any good way to receive relatively high frequency interrupt in eCos?
> Something between 100kHz and 200kHz.

Our 200Mhz StrongARM has no problems with around 2KHz interrupts. The
load is places for these ISR is not significant compared to the rest
of the software. I know its 2 orders of magnitude less than what you
want, but its a start. We have also found that eCos is also very good
in terms of interrupt latency, at least at 2KHz. We virtually never
see ISRs/DSR disabled for 'long' periods of time. ie we get to service
every interrupt without a problem.
 
> What are the main do's and dont's when configuring such an interrupt?

Use a separate interrupt. ie i would not just increase the rate of the
normal timer used by eCos for all its scheduling etc. Use a different
timer with its own interrupt line and interrupt handler.

> Can I setup eCos to have less interrupt overhead in some way?

Depends on your hardware. With the ARM there are two real interrupt
lines on the processors, IRQ and FIQ. There is then in interrupt
controller which multiplexes the different interrupts down to these
two lines. By default eCos does not use the FIQ, but it is available
for use. We attached our interrupt source to the FIQ. We then wrote
our own VSR routine which is installed directly into the FIQ
vector. ie eCos does not even see the interrupt. 12/16 of our
interrupt don't actually need eCos to do anything, so this works well
for us. When we do need eCos, there is a software controllable
interrupt source in the interrupt controller. ie we write a 1 to it,
and an ISR interrupt is created. We have a standard eCos interrupt
function registered to that one, so we can go through the chain or
ISR/DSR/Thread.
 
 Andrew

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