[En-Nut-Discussion] Real-ly the right time? (was: Nut/OS goes Real-Time and USART on SPEED)

[Mivhael Jones]

Hi do all that have tuned into the Real-Time discussion...

I personally think that we have to get back into the frame of what an
embedded OS, in this case Nut/OS, is and what not. An Embedded-OS real is
"just" a helper to get a project finished in a limited amount of time - as
we don't have to reinvent the wheel, and with a low failure risk - as we use
a well tested and evaluated platform. Though the idea of having e.g.
real-time onboard is charming we should look at what the common application
requires and how that common denominator will benefit from new features as
well as if this will influence the code-base out in the field...

As the discussion has been revolving around the USARTs a lot I'll use that
as an example:

If I'm developing a application that requires a stable well featured serial
interface that can provide functionality with the smallest amount of work
overhead I would look at the OS and expect it to deliver just that.

But what if my requirements take the hardware - and that is what we are
actually looking at in the moment - to the limit?

That is where feature meets fact - we can not simply change the OS to bump
up the speed. If we are at a point where we are starting to count cycles
then we should do just that - but that is custom code! Why? Because counting
cycles works for CPU XX but CPU YY might (actually: most likely) have a
different way of doing things and will not allow what ever optimizations we
have made to be transported. An OS that attempt this ends up behaving
different on different CPUs in a non-deterministic way (I've been there). 

The nice thing about e.g. Nut-OS is that it does allow us to do two things; 

1) we can e.g. create an alternative driver of "our" version of USART
2) we can simply acquire the interrupts and handle them the way that we see
fit to solve the problem.

Now I can hear some saying "you can't do that - that is not portable!" and
yes those saying that are correct; most likely it isn't, yet it works.
Whereas an OS that would have to provide a optimized way (and remember your
way might not be my way) would be littered with e.g. ifdefs.

In my case I've already ran into a scenario where I had to do sidestep the
OS - why? Well I've got a SPI device that runs at clk/16 on an ATMEGA128 at
14.7456MHz. Unluckily the SPI has a higher interrupt priority then the
UARTs. This makes it virtually impossible to receive an error free stream at
19200 not even mentioning the 115K that I needed. So what to do? No point
blaming the OS - the CPU is the problem (and the requirement). I solved this
by using the interrupt 2 which is in parallel to the USART1 (and higher
priority then the SPI) to signal when the first bit arrives and then
temporary slows down the SPI. Works like a charm - but where would that fit
into an OS? And also a different hardware would not require this trick
anyway (actually the ATMEGA162 did not have this problem). 

So my credo is to keep Nut/OS clean - optimize it yes but don't try to turn
it into something that it can't be.


All the best,
Michael