Re: [ECOS] Software I2C

["Slawek" <sgp at telsatgp dot com dot pl>]

Hello Andrew,



Yes, I'm going to use GPIO.

It will be somethig extremally fast. Probably somewhere around 10 instructions not counting saving registers etc. I'm going to use jump table on the start to speed up selection of "what should we do now". Of course from time to time (probably once per transmitted byte) we will need to do something more.

It has not beed decided so far if we're going to handle this in DSR or in thread (after DSR signaling semaphore that it sent / received a byte). I can imagine DSR is faster but is always running at a very-high-priority, which meens it's not always the best approach.


We may use some king of layering if compiler would optimise it out. Some #defines or templates, but I really can't see any reason for creating more layering than that. Looks like some #defines: "highscl", "lowscl", "highsda", "lowsda", "readscl", "readsda".

Unfortunatelly to bring speed to optimum we may need to write it in asm, so we would not need to save all registers on the stack. Or are there any ways to tell the compiler to save all used registers and not the others? Writing in asm is not very cross-platform...


We're probably not going to use 200MHz as main clock but up to 66MHz which are available on lower ARM cores. This together with say 125 kHz interrupt (giving 62,5 kHz I2C) means an interrupt generated once per 528 cycles. This basically has to have an impact on performance ;)

Although we may disable an interrupt when there are no I2C transmissions which bring us to conclusion that using an interrupt is better than delay loops anyway. As long as there is interrupt source available of course.


Ok, I think it's time to dig into Atmel and ARM documentations about interrupt sources and handing and try to handle one without eCos. I guess such interrupt handler will be hard to debug.


Thanks for your hints, Andrew. Especially about the mark of software controllable interrupt. I have had some experience with MCS-51 and PIC microcontrollers so far and wouldn't imagine that an interrupt may be generated by software :) (unless something like int3 on x86).


-- 
Slawek Piotrowski


----- Original Message ----- 
From: "Andrew Lunn" <andrew.lunn@ascom.ch>
To: "Slawek" <sgp@telsatgp.com.pl>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Monday, July 07, 2003 12:12 PM
Subject: Re: [ECOS] Software I2C


> 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