[En-Nut-Discussion] (In)stability of NutOS

[Harald Kipp]

We recently had a large application running in two different
test environments, one in our office and another at the
customer's place.

The system consists of 4 CPU's. One is an Ethernut 1.3 and
the other 3 are running Nut/OS on ATmega128 CPUs without
external RAM. All CPUs communicate via multimaster I2C.
The three low end CPUs are emulating an I2C double UART,
each running 4 application threads. The Ethernut board
provides 4 TCP threads, two UDP threads for I/O monitoring
and another UDP thread for device discovering and configuration.
Another thread is used for protocol parsing. Furthermore
the Ethernut runs two more threads for on-board UART communication.

Running query/response protocols on all 8 serial ports at
115200 Baud and transferring the raw data via TCP to the
PC host, which in turn regularly switches 8 relais and monitors
the feedback via 16 digital inputs via UDP is quite some
workload, specifically for the thread/timer modules.
None of the three systems showed any kind of instability.
In fact, under rare circumstances a telegram got lost
due to a bug in the multimaster I2C, which is still undiscovered.
But no hang ups or re-boots.

Oh, I forgot to mention, that the system produces a lot
of test status output via syslog UDP.

The tests started initially with Nut/OS 4.0.1, compiled by
WinAVR-20030913 and was later switched to Nut/OS 4.0.2,
compiled by WinAVR-20060125.

The obvious difference to the systems, for which failures
had been reported here, is that HTTP is not used and TCP
connections are seldom closed and re-opened.

But from the experience with the system we tested, I can
hardly believe that there are any problems with the
thread/timer modules. Though, as we say in Germany:
"Ich habe schon Pferde kotzen sehen."

Harald

At 17:08 20.02.2006 +0100, you wrote:
>
>So I'm curious if anyone is looking/improving/working on the new modules in
>the os part (such as event.c, thread.c, timer.c)?
>