From 26f3d216a3e471800dc8e5bbbdabb5299c6decb5 Mon Sep 17 00:00:00 2001
From: Gregory Nutt Last Updated: January 28, 2016 Last Updated: March 13, 2016
@@ -1506,8 +1506,8 @@
NuttX RTOS
-
@@ -1558,8 +1558,8 @@
- PJRC Teensy-LC. + PJRC Teensy-LC. This is a port of NuttX to the PJRC Teensy-LC board that features the MKL25Z64 Cortex-M0+ MCU, 64KB of FLASH and 8KB of SRAM. The Teensy LC is a DIP style breakout board for the MKL25Z64 and comes with a USB based bootloader. See the Freescale website for further information about this board. @@ -3753,7 +3753,7 @@ nsh>
- NXG Technologies LPC4330-Xplorer. + NXG Technologies LPC4330-Xplorer. This NuttX port is for the LPC4330-Xplorer board from NGX Technologies featuring the NXP LPC4330FET100 MCU. See the NXG website for further information about this board.
@@ -3799,7 +3799,7 @@ nsh>- NXP/Embest LPC4357-EVB. + NXP/Embest LPC4357-EVB. This NuttX port is for the LPC4357-EVB from NXP/Embest featuring the NXP LPC4357FET256 MCU. The LPC4357 differs from the LPC4330 primarily in that it includes 1024KiB of on-chip NOR FLASH. See the NXP website for more detailed information about the LPC4357 and the LPC4357-EVB. @@ -3811,7 +3811,7 @@ nsh>
NuttX-7.6 +
NuttX-7.6. The basic port is was contributed by Toby Duckworth. This port leverages from the LPC4330-Xplorer port (and, as of this writing, still requires some clean up of the technical discussion in some files). The basic NuttShell (NSH) configuration is present and has been verified. @@ -3821,7 +3821,7 @@ nsh>
- NXP LPC4370-Link2 + NXP LPC4370-Link2. This is the NuttX port to the NXP LPC4370-Link2 development board featuring the NXP LPC4370FET100 MCU.
- WaveShare LPC4337-WS + WaveShare LPC4337-WS. This is the NuttX port to the WaveShare LPC4337-WS development board featuring the NXP LPC4337JBD144 MCU.
diff --git a/Documentation/NuttxPortingGuide.html b/Documentation/NuttxPortingGuide.html index 32cad9675d6..674938f799a 100644 --- a/Documentation/NuttxPortingGuide.html +++ b/Documentation/NuttxPortingGuide.html @@ -12,7 +12,7 @@
Last Updated: February 14, 2016
+Last Updated: March 13, 2016
src/:
This directory contains board specific drivers.
- This directory will be linked as /src/board at configuration
+ This directory will be linked as <config>/arch/<arch-name>/src/board at configuration
time and will be integrated into the build system.
This configuration file will be used at build time:
-include/nuttx/config.h which is included by
most C files in the system.@@ -1349,7 +1349,7 @@ include/ | `-- (Wireless device driver header files) `- sys/ `-- (More standard header files) -
@@ -1397,7 +1397,7 @@ libc/ | `-- (Implementation of some functions from time.h) `-- unistd/ `-- (Implementation of some functions from unistd.h) - +
@@ -1599,7 +1599,7 @@ netutils/
- If your application directory is not in the standard location (../apps or ../apps-<version>),
+ If your application directory is not in the standard location (../apps or ../apps-<version>),
then you should also specify the location of the application directory on the command line like:
@@ -1739,7 +1739,7 @@ The system can be re-made subsequently by just typingmake. An interface which is unique to a certain microprocessor should be prefixed with the name of the microprocessor, for examplestm32_, and be prototyped in some header file in thearch/directories.- There is also a
@@ -1751,7 +1751,7 @@ The system can be re-made subsequently by just typingarch/header file that can be used to communicate other microprocessor-specific information between the board logic and even application logic. + There is also a/include/ /chip.h arch/<architecture>/include/<chip>/chip.hheader file that can be used to communicate other microprocessor-specific information between the board logic and even application logic. Application logic may, for example, need to know specific capabilities of the chip. Prototypes in thatchip.hheader file should follow the microprocessor-specific naming convention.make. Theseboard_definitions provide the interface between the board-level logic and the architecture-specific logic.- There is also a
@@ -1760,7 +1760,7 @@ The system can be re-made subsequently by just typingconfigs/header file that can be used to communicate other board-specific information between the architecture logic and even application logic. + There is also a/include/board.h configs/<board>/include/board.hheader file that can be used to communicate other board-specific information between the architecture logic and even application logic. Any definitions which are common between a single architecture and several boards should go in thisboard.hheader file;include/nuttx/arch.his reserved for board-related definitions common to all architectures.make. Board-Specific Interfaces. Any interface which is unique to a board should be prefixed with the board name, for examplestm32f4discovery_. Sometimes the board name is too long sostm32_would be okay too. - These should be prototyped inconfigs/and should not be used outside of that directory since board-specific definitions have no meaning outside of the board directory. + These should be prototyped in/src/ .h configs/<board>/src/<board>.hand should not be used outside of that directory since board-specific definitions have no meaning outside of the board directory.
nuttx/arch/sim/src/up_tickless.c. There is another example for the Atmel SAMA5 at nuttx/arch/arm/src/sama5/sam_tickless.c. These paragraphs will explain how to provide the Tickless OS support to any platform.
-@@ -2519,7 +2519,7 @@ config ARCH_SIM
The interfaces that must be provided by the platform specified code are defined in include/nuttx/arch.h, listed below, and summarized in the following paragraphs:
#include <nuttx/arch.h> void up_timer_initialize(void); - +
Description:
up_intialize(). On return, the current up-time should be available from up_timer_gettime() and the interval timer is ready for use (but not actively timing).
@@ -2609,7 +2609,7 @@ void up_timer_initialize(void);
#include <nuttx/arch.h> int up_timer_gettime(FAR struct timespec *ts); - +
Description:
Return the elapsed time since power-up (or, more correctly, sinceup_timer_initialize() was called). This function is functionally equivalent to clock_gettime() for the clock ID CLOCK_MONOTONIC. This function provides the basis for reporting the current time and also is used to eliminate error build-up from small errors in interval time calculations.
#include <nuttx/arch.h> int up_alarm_cancel(FAR struct timespec *ts); - +
Description:
Cancel the alarm and return the time of cancellation of the alarm. These two steps need to be as nearly atomic as possible.sched_timer_expiration() will not be called unless the alarm is restarted with up_alarm_start(). If, as a race condition, the alarm has already expired when this function is called, then time returned is the current time.
#include <nuttx/arch.h> int up_alarm_start(FAR const struct timespec *ts); - +
Description:
Start the alarm.sched_timer_expiration() will be called when the alarm occurs (unless up_alaram_cancel is called to stop it).
#include <nuttx/arch.h> int up_timer_cancel(FAR struct timespec *ts); - +
Description:
Cancel the interval timer and return the time remaining on the timer. These two steps need to be as nearly atomic as possible.sched_timer_expiration() will not be called unless the timer is restarted with up_timer_start(). If, as a race condition, the timer has already expired when this function is called, then that pending interrupt must be cleared so that sched_timer_expiration() is not called spuriously and the remaining time of zero should be returned.
#include <nuttx/arch.h> int up_timer_start(FAR const struct timespec *ts); - +
Description:
Start the interval timer.sched_timer_expiration() will be called at the completion of the timeout (unless up_timer_cancel() is called to stop the timing).
Compared to the Low Priority Kernel Work Queue.
- For less critical, lower priority, application oriented worker thread support, consider enabling the lower priority work queue. The lower priority work queue runs at a lower priority, of course, but has the added advantage that it supports priority inheritance (if
Configuration Options. @@ -3030,7 +3030,7 @@ typedef uint32_t wdparm_t;
Priority Inheritance.
- The lower priority worker thread(s) support priority inheritance (if
NOTE: This priority inheritance feature is not automatic. The lower priority worker thread will always a fixed priority unless additional logic implements that callslpwork_boostpriority()to raise the priority of the lower priority worker thread (typically called before scheduling the work) and then calls the matchinglpwork_restorepriority()when the work is completed (typically called within the work handler at the completion of the work). Currently, only the NuttX asynchronous I/O logic uses this dynamic prioritization feature.