On Tuesday 21 October 2008, Joakim Tjernlund wrote: > > > Maybe it indeed makes more sense to use polling for high bitrates. > > The cpu can't keep up at ~10MHz for me, but even at much small Hz > the poll is significantly faster, the IRQ overhead seems huge or is it > something else?
I'd guess IRQ-per-word is a bad design policy ... If you assume 10 MHz SPI clock, and (keeping math simple) a 10-bit word, then a polling loop of 1 MHz -- 1 usec/loop -- is needed to keep up. Regardless of latency, per-IRQ overheads (save context, call handler, do its work, return, restore) are not always below 1 usec... > The question is if the poll code I sent is good, even for longer transfers? > Perhaps some sort of LOWLAT flag could be used for transfers that really need > them? So long as you do the polling with IRQs enabled, I'd keep it simple and just always poll. YMMV of course, but most devices seem to prefer more like 10 MHz clocks than 1 MHz ones. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
