Running Nut/OS Apps on a UNIX machine. More...
Data Structures | |
struct | _UNIXDCB |
UNIX devices low level information structure. More... | |
Modules | |
Initialization | |
Starting Nut/OS. | |
System Support | |
Hardware dependant functions used by Nut/OS. | |
Typedefs | |
typedef struct _UNIXDCB | UNIXDCB |
Variables | |
NUTDEVICE | devUart0 |
UART 0 Device information structure. | |
NUTDEVICE | devUart1 |
UART 1 Device information structure. | |
NUTDEVICE | devUart2 |
uart device 2 information structure. | |
NUTDEVICE | devUsartAvr0 |
USART0 device information structure. | |
NUTDEVICE | devUsartAvr1 |
USART1 device information structure. | |
NUTDEVICE | devUsartAvr2 |
usartavr device 2 information structure. | |
NUTDEVICE | devDebug0 |
Debug device 0 information structure. | |
NUTDEVICE | devDebug1 |
Debug device 1 information structure. | |
NUTDEVICE | devDebug2 |
Debug UART 2 device information structure. |
Running Nut/OS Apps on a UNIX machine.
Nut/OS can be compiled for a native unix target.
The following hardware is currently emulated: RTC and UART. A RTC clock is provided. All AVR UARTS are mapped to STDIO but this can configure at app start-up using command line paramters. Syntax:
MyNutOSAPP.unix [-u0 deviceName] [-u1 deviceName] [-u2 deviceName]
The unix emulation provides a third uart for debugging purposes as devDebug2, devUsart2 and devUsartAvr2)
USART0 device information structure.
An application must pass a pointer to this structure to NutRegisterDevice() before using the serial communication driver of the AVR's on-chip USART0.
The device is named uart0.
USART1 device information structure.
An application must pass a pointer to this structure to NutRegisterDevice() before using the serial communication driver of the AVR's on-chip USART1.
The device is named uart1.
usartavr device 2 information structure.
Debug device 0 information structure.
Debug device 0 information structure.
Usually, the device structure is the only public symbol that may be referenced by the application code using
#include <dev/debug.h> { ... NutRegisterDevice(&devDebug0, 0, 0); ... }
If not referenced, the driver code (and this structure) will not be included in the final binary.
The name of the structure may differ among platforms. Portable applications should avoid it and instead make use of dev/board.h.
#include <dev/board.h> { ... NutRegisterDevice(&DEV_DEBUG, 0, 0); ... }
While output is supported by default, input may be not. If input is required, applications may replace DEV_DEBUG by DEV_CONSOLE. In this case the debug driver is selected only, if it has input capability (see NUT_DEV_DEBUG_READ). Otherwise an interrupt driven UART driver will be used.
Note, that this polling driver has certain advantages
but also some disadvantages
When used with Harvard architectures, additional functions may be offered to access data in program space.
Debug device 0 information structure.
An application must pass a pointer to this structure to NutRegisterDevice() before using the serial communication driver of the LPC17xx's on-chip USART0.
The device is named usart0.
Debug device 1 information structure.
Debug device 1 information structure.
An application must pass a pointer to this structure to NutRegisterDevice() before using the serial communication driver of the LPC17xx's on-chip USART1.
The device is named usart1.
Debug UART 2 device information structure.
An application must pass a pointer to this structure to NutRegisterDevice() before using the serial communication driver of the LPC17xx's on-chip USART2.
The device is named usart2.