Developers

You can access the latest status of the source code directly from the Ethernut CVS repository at Sourceforge. A further description about the CVS structure is given bere

We welcome all contributions to the Ethernut project and have created the following guidelines to provide a development framework.

Coding Style

Please try to follow some rules to keep the code consistent and easy to read.

• Use K&R indentation style.

• Tab size is 8. This is very important.

• Follow the Doxygen inline documentation style. Otherwise your changes will not appear in the API manual.

Nut/OS uses BSD-style type definitions defined in types.h. These definitions are most often used in TCP/IP implementations, but rarely used for embedded system applications. For example, BSD uses u_char as a shortcut to unsigned char and u_long as a shortcut to unsigned long, while embedded programmers often prefer u08 and u32 resp. The argument for using u08 or u32 in order to show the size is weak in my opinion, because a character is 8 bit and a long is 32 bit by definition. To be consistent, you would have to define i16 or s16 for short etc. Also note, that int is defined the same length as the word size of the target platform, but minimum 16 bit.

It should be noted, that nowadays programmers are switching to uchar_t or ulong_t, which is even more consistent with standard C types. But changing this would require a major update of the sources.

Contributors are invited to discuss these topics in the mailing list.

However, it's no secret, that the current source code contains some major flaws, which makes porting to other platforms impossible or at least very difficult. See the next topic.

Supported Targets

The current release supports the Ethernut Reference Design only, but this is going to change soon. If you are developing for a different hardware, your contributions are welcome, provided that the hardware design is published under the same license as the Ethernut hardware.

In the meantime more people are asking for the possibility to port Nut/OS to other CPU platforms than the AVR, specially ARM or Intel. Unfortunately the code is spoiled with many compatibility issues. Ralph Mason has listed some suggestions to avoid these problems in the future.

1. Use u_int not u_short: This means that things can scale to the size of the compilers int. Means printf (with %i) keeps working, and expands the range of the heap functions to the machine size.

2. Virtualize device drivers (this makes sense even if your not porting it) By virtualize I mean when you call other driver functions from driver functions call them through the pointers in the NUTDEVICE structure.

3. Define a MM_IO macro and use that for all memory mapped IO. This allows and emulation of a device to run (by trapping the MM_IO addresses) or a device with a separate IO space to use the same code.

4. Don't use the IOREG = Value , Value = IOREG notation (eg PORTD=0xf0 ; someval = PORTD). Use outb, outw, inb and inw. This allows traping and emulation.

This should be considered at least when writing new code.

Supported Tools

Keep in mind, that the code is intended to work with several compilers running on different Operating Systems. Currently AVRGCC for Linux and Windows and ICCAVR for Windows are supported. Compiler specific variations should be exclusively defined in compiler.h.

Private Modifications

If you are working on a commercial project, you may not want to publish your modifications. This is no problem, because the Ethernut license explicitly allows usage and distribution of the software without releasing any source code.

If you need to modify modules of the RTOS, you can use the mod subdirectory. This is most useful, if you want to change include files. Copy the include file to the corresponding subdirectory below mod and apply your changes. When recompiling Nut/OS, the compiler will preferably take include files with the same name from the mod subdir.