[En-Nut-Discussion] Why not change from Nut/OS to BeRTOS

Harald Kipp harald.kipp at egnite.de
Mon Jun 10 17:21:45 CEST 2013

Hi all,

I have no idea how to proceed... I'm in a very bad mood... :-(

I failed to get an old application working, which I know for sure had
been working previously. Obviously the SPI chip selects for the VSCODEC
are not properly initialized.

Diving into the code, I found


which translates via the Configurator into


In include/dev/gpio_avr.h we have

#define PIOD_ID     4

so the call again translates to

GpioPinConfigSet(4, 6, GPIO_CFG_OUTPUT);

and in gpio_avr.c we have

int GpioPinConfigSet(int bank, int bit, uint32_t flags)
 if (flags & GPIO_CFG_OUTPUT) {
  AVR_DDRX(bank) |= _BV(bit);

which translates, according to gpio_avr.h

#define AVR_DDRX(bank)  (_SFR_IO8(bank -1))

This is finally _SFR_IO8(3), but should have been _SFR_IO8(0x11).

How the hell can it be, that AVR GPIO code, which had been working all
the time, seems to be completely broken for many months (r4642 - 24th
Sept. 2012). Note, that setting wrong I/O registers may cause hardware

The crowning glory is found at line 66 of nut/arch/avr/dev/gpio_avr.c.

Gosh! We exchanged a lot of email filled with high level discussions
about GPIO tricks, optimizations, compiler issues etc. etc. etc. And now
it turns out, that not even the basics are working.

As this module is used in several hardware-independent Nut/OS drivers
I'd consider Nut/OS severely broken for the AVR platform since months.
This is ridiculous and unacceptable. If I were a harmless user only, I'd
see Nut/OS very badly maintained and give BeRTOS, Femto OS or whatever a
try. Unfortunately I'm part of the developer team.

We definitely have to implement some kind of quality procedures ASAP.



P.S.: Well, after cooling down a bit, I'm considering, that I may have
overlooked something. In that case, please send your flames to my
private email address.

More information about the En-Nut-Discussion mailing list