This is the mail archive of the ecos-patches@sourceware.org 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: i2c interface polled/IT driven transfer


>>>>> "Peter" writes:

    Peter> I realised, that the I2C API does not offer the possibolity
    Peter> of switching between polled and IT driven transaction (like
    Peter> the SPI does). I've added this functionality on device
    Peter> level , taking one bit of i2c_flags. (unlike in case of
    Peter> SPI, in order to leave the current interface functions
    Peter> unchanged)

    Peter> Opinions?

This was actually a deliberate decision during the API design, albeit
not an easy one. Although both SPI and I2C are serial buses, there are
some crucial differences. I2C runs at a fixed bus speed, typically
100KHz. SPI runs at a variable bus speed, possibly 10MHz or more. If
you are going to be transferring one or two bytes at 10MHz on typical
hardware then there is no point in doing so using an interrupt-driven
transfer: the interrupt would fire near enough immediately so no other
thread would get a chance to run, and more cpu cycles would be spent
servicing the interrupt than in equivalent polling code. On the other
hand, if the SPI transfer involves a lot of data at a relatively slow
speed, say 100KHz or less, then it is likely that an interrupt-driven
transfer would give better overall performance - especially if the
SPI hardware has DMA capability.

The wide range of speeds for SPI buses, two or more orders of
magnitude, means that it would be very hard for an SPI device driver
to decide whether any given transfer should be interrupt-driven or
polled. Instead the decision is left to higher-level code, providing
flexibility at the code of an API that is more difficult to use.

I2C with its fixed bus speed is much more predictable. At only 100KHz
it is likely that an interrupt-driven transfer will still leave plenty
of cpu cycles for other code to run on typical hardware, so most
drivers will just default to that behaviour. Some drivers may prefer
polled mode for small transfers, or in the case of the bit-banged
driver there is no choice and polled mode has to be used. When
interrupt-driven transfers are the default it is still possible for
the driver to work in a polled-only environment such as RedBoot or
during application startup simply by checking whether or not
interrupts are currently enabled. The M68K/MCF52xx I2C driver provides
an example of this.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


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