Difference between revisions of "Nut/OS Roadmap"

From Nutwiki
Jump to: navigation, search
(Current Tasks For Next Release)
m (1 revision imported)
(No difference)

Latest revision as of 18:02, 27 October 2016

Upcoming Releases

Release Date Features Notes
5.2 In progress Cortex-M
5.4 Unknown IPv6

Current Tasks For Next Release

Task Status Notes
Cortex-M Support In progress License issues
STM32 Support In progress
LPC17xx Support In progress
License Issues In progress
Multiple network interfaces In progress
PPP Dial-In In progress


This is a first unsorted list of future enhancements.

We may later add more details like estimated release dates, which are missing in the SourceForge Tracker.

Feel free to add your ideas and needs. If you are able and willing to help with a specific implementation, please use the Ethernut Discussion List to get in touch with other developers.

General Preconditions

Enhancing Existing Releases

Nut/OS releases are distinguished by unique versions, which are divided into four parts.

1 Major version number. Typically changes when major feature were added and backward compatibility cannot be guaranteed.
2 Minor version number. Even numbers are used for final releases. The number changes to the next even value, when new features had been added. Odd numbers are used for beta releases, which are based on the previous final release, but may or may not contain new features, incompatibilities and even bugs.
3 Release number. For final releases this is incremented on each bugfix release. For beta releases this changes on each release, which may contain more features, more incompatibilities and more bugs.
4 Build number. Typically changes when new compilers had been tested or installations had been fixed. No code changes are expected between different build numbers of a specific release.

New feature must not be added to existing final releases, unless they fix or help to fix serious problems.

Code Size

New features must not add code to existing applications, unless the extension is essential for most environments. Example: SNMP is not essential, additional code will be accepted only, if an application makes use of SNMP. Gratuitous ARP is an essential feature for all applications using Ethernet. Moderate grow in code size will be accepted.

Backward Compatibility

Backward compatibility must be maintained at least until the next major version. If new functions replace older ones, the latter will be kept for backward compatibility, but marked as deprecated.

As an exception to the above rule, newly introduced functions, which never became part of an official final release, may change during development.

License Issues

All code must comply to the BSD License. Code that had been released under GPL is not acceptable.

If possible, stick to BSDL. Although, LGPL and other licenses may fit, it is difficult to track them over the years. Also, users may easily becoming confused by too many license issues.

Note, that it is planned to introduce a new contrib folder is planned, which will contain source code released under incompatible licenses, but is clearly separated from the rest (see below).

Wanted Features

in no particular order.

Bus Concept

There is currently no generic bus interface, which provides a framework for SPI, I2C, USB etc.

Gratuitous ARP

Support for gratuitous ARP is urgently required to handle duplicate IP addresses and inform other nodes about IP address changes.

IOCTL for Network Driver

Network drivers do not support an ioctl interface, which would allow to activate or shut down the interface, query its MAC address, etc.

A first attempt had been made with dev/lan91.c.


Customer request.

Configurable Standard Initialization

Make the classic run on all platforms.

<source lang="c">

  1. include <stdio.h>

int main(void) {

 printf("Hello world!");

} </source>

An attractive solution to avoid NutRegisterDevice calls would be to create a board specific module, which defines all required NUTDEVICEs, located in a unique linker section. During initialization, Nut/OS will examine this section and register all contained devices.

USB Stack

License issues?

USB Questions

My company bought the licenses for a block of USB addresses, this should not be a problem for us. I am looking forward to a CDC, or even just an HID implementation to build on.

IRDA Stack

Requested many years ago. Will this still make sense?

Encryption Support

Graphic Library

So far no exiting Open Source implementation had been found. Our requirements are

  • Compatible with BSD license
  • Simple enough for 8-bit AVR
  • Minimum abstraction layers (not those LcdGoto, LcdDrawCircle libraries)

Supporting more Targets


Scheduled 3.Q.2009
Volunteers wishing to help with peripheral driver development please mailto: dferbas at etech dot cz


Preliminary support have been checked in. Further development is still needed. As well as drivers and interrupt handlers to this MCU specific peripherals.

Some info about application port, bootloader and eicall can be found here ...


The AVR32 UC3 port have been incorporated into the project's repository and should be available in the next relese. Many of the Nut/OS samples are already working.

Anyone interested should speak-up on the mailing list or contact one of the developers.

Delayed Interrupt Handling

See discussion in the Ethernut mailing list.

Different Licenses

Nut/OS is often used in commercial project, because it is released under BSDL or compatible licenses, which do not require to release the code of the whole project or any modifications.

However, there are several projects based on Nut/OS, which are released as Open Source, which would benefit from other Open Source projects, which are released under incompatible licenses. A good example is the Helix MP3 library, which is distributed under RPSL.

We suggest to add a new subfolder named contrib, which contains code that is distributed under incompatible licenses and is clearly marked as such.

Note, that the BSDL applies to code running on the target only. Most tools, which are used to create Nut/OS applications and libraries are distributed under GPL, like the GNU Compiler or the Nut/OS Configurator.

Additional Debugging Support

Remember the last running thread after reboot caused by the watchdog.

Completely fill the stack with a specific pattern to track real stack usage. This had been suggested long time ago by mifi, but was rejected because of performance issues. However, it would make sense when using a configurable switch.

Make extended use of NUTASSERT(). Nut/OS generally avoids parameter checking at runtime to reduce code size. Using NUTASSERT in debug versions will compensate this.

Expected Release Dates

To be worked out.