[En-Nut-Discussion] USART on SPEED (was: Nut/OS goes Real-Time)

[Matthias Ringwald]

Hi

after some parallel discussions both on and off the lists, I'd like  
to summarize the options to
improve/boost USART handling. To me, it looks like the following  
options are possibe,
and could be applied in most combinations. All uS are for 7.3 Mhz Atmel.

* Replace Nut/OS IRQ handler with direct SIGNAL handler in the USART  
implementation
   + could easily done using #ifdefs ( altough harald doesn't like  
them very much :)
   + will reduce the RX Complete IRQ handler by 20 uS. (also others,  
e.g. Tx Empty, too)

* Read two bytes from FIFO buffer, if available
   - if one byte in FIFO extra cost: one extra comparison
   + if two bytes in FIFO, 40 uS (special IRQ handler) - 60 uS (Nut/ 
OS Hanlder) savings, because
     IRQ is called only once instead of two times.
   + especially useful, if RX complete is already called quite late,  
because of ill-behaving
     critical sections

* USART Blocking Read / DMA
   - if not used: one extra comparison
   + if used: RX handler might use only half the time / RingBuffer  
not used (no measurements available)
   + Application speedup

* Fixed 256 Bytes Ringbuffer
   + Less comparisions, less checks, could save some cycles
   - reduces flexibility

* Add #ifdef to remove software flow control if not needed by  
application
   + removes two comparisons ( maybe the extra two mentioned in  
option 2 and 3. .. :)
   - extra #ifdefs
   - reduces flexibility


those are the general ones. I'm interested which of those options  
would be welcome in Nut/OS.
Otherwise, for BTnut, we can just all of them at once by having our  
own non-standart USART.

orthogonal to this, we have to hunt down long critical sections!

that's it, have a nice weekend,
matthias