Searching \ for '[SX]: "Real" IRQ driven I2C routines' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/ubicom/lib/io/index.htm?key=i2c
Search entire site for: '"Real" IRQ driven I2C routines'.

Exact match. Not showing close matches.
PICList Thread
'[SX]: "Real" IRQ driven I2C routines'
2002\01\16@022015 by Russell McMahon

picon face
Requirement:    FULLY interrupt driven I2C code that allows byte read and
write and ideally block write fully under interrupt control.
(The theory is easy - but hopefully someone has already invented this
wheel.)

Background:     I am using the UBICOM / Scenix interrupt driven IIC routines
on an SX28.
These worked after a little beating around the head - probably needed due to
using an integrated virtual peripheral where several VPs had been rolled
together as a demo (I used the I2C multimaster plus 2 uarts and extended
this to 3 uarts). The code was essentially sound but there were a few places
where eg RAM banking seemed inconsistent. Next time I use VPs I'll use the
single task version and integrate it myself with other VPs.

However, while the I2C core is interrupt driven, the majority of the I2C
state machine is run in the foreground and is not immediately amenable to
multitasking of other semi real time tasks. (eg - while the UART routines
will receive a single byte entirely under interupt control when left to
their own devices the I2C state machine must be driven in the foreground. As
presently conceived the I2C peripheral is called once in the foreground and
does not return control until the whole read or write task is completed. If
other time critical tasks occur (eg perhaps several serial ports delivering
data more or less simultaneously) then at higher baud rates the I2C task
must be interrupted if data is not to be lost (especially during I2C write
delays). (The UART tx/rx routines also hang until data is ready/sent as
supplied but are easily converted to useful operation by monitoring their
status and only calling them when they are free/data ready respectively).

This level of I2C peripheral autonomy compares extremely poorly with that
provided by hardware peripherals which can be set to process at least one
byte and usually several data bytes without further intervention. While it
would not be conceptually hard to take the Scenix I2C and drive the state
machine under interrupt control it may take some time to "get it right". A
look for available code (including at PICLIST & SX list sites) did not
disclose anything which does this fully automatically.

SO - has anyone got "fully" interrupt driven I2C code available for general
use?
(Or am I going to have to further automate the existing code myself :-( ).


regards



               Russell McMahon

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...