This is the mail archive of the ecos-discuss@sources.redhat.com 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: Software I2C


>> If working on interrupts have such an overhead that it's hard to work at 100
kHz than what's the reason of using interrupts here? All after all writing the
code >> with simple coutning loops or "wait for timer overflow" loops is very
easy and can work at 400 kHz without any problems.

True, this can be considered. Both methods have its advantages. The main
advantage of interrupts is that other processes can continue better during large
transfers (1Kb). At 80kHz this works fine. If you can work at 400kHz (the I2C
device must support this and this gives demands to the pin drivers, see I2C
specs) a 66MHz processor might be better off with counting loops.

Writing a assembly-only interrupt routine is also an option, but assembly is
very hard for maintain for this complex routines (and not portable to other
platforms).

By the way, I used a single shot timer for my interrupt routine. A fixed timer
has the problem that if the interrupt routine is delayed by another interrupt,
the next interrupt will come too soon, which violates the 100kHz I2C specs.

Eric



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


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