[En-Nut-Discussion] Best way to implement a time-critical RS485 driver

[Matthias Ringwald]

Hi Christian,

  I guess I can give you some hints on some limitations of nut/os.

  First, it is a cooperative multi-threaded os (which has pros and  
cons, but e.g.
  for the default ehternut embedd webserver, the pros outweight the
  others pretty much).

  In such an os, a thread is only interrupted by a an IRQ. a thread
switch happens on request of the thread or implicitly e.g. when data
has to be written to uart but the uart buffer is full at the moment.

Because of this, a thread is not really able to respond in a timely
manner to something like a incoming byte. if it has the highest
priority, yes, it is the next one to run. but even the thread with
lowest priority can take as long as it wants before passing on to
the 'high' priority thread.

btw, on 7.3 Mhz, a context switch takes about 40 us.
a 150 us timeout is already tought, if you are not in full
control of all threads or use interrupts.


I guess reducing the state machine in the IRQ to the minimum is
your best bet.
  another solution can be, that upon starting of your communication
you do everything in one thread, not passing control to other
threads ever. if you are happy with this depends on your application.

ah.. maybe a good answer to this..
On 02.09.2005, at 12:09, Christian.Schilmoeller at camco.de wrote:
> ... But I'm afraid that the disadvantage would be a huge
> overhead of complete thread switches which are triggered by the irq
> handlers.
The main problem is, that an IRQ just cannot even trigger a thread
switch.