diff --git a/Documentation/NuttxPortingGuide.html b/Documentation/NuttxPortingGuide.html index c188ee72d1..7ea3e39c13 100644 --- a/Documentation/NuttxPortingGuide.html +++ b/Documentation/NuttxPortingGuide.html @@ -12,7 +12,7 @@

NuttX RTOS Porting Guide

-

Last Updated: September 14, 2014

+

Last Updated: October 14, 2014

@@ -104,45 +104,69 @@ 4.3.4 Tickless OS
4.3.5 Watchdog Timer Interfaces - 4.4 Address Environments + 4.4 Work Queues - 4.5 APIs Exported by NuttX to Architecture-Specific Logic + 4.5 Address Environments - 4.6 Shared Memory + 4.6 APIs Exported by NuttX to Architecture-Specific Logic - 4.7 On-Demand Paging
- 4.8 LED Support + 4.7 Shared Memory + 4.8 On-Demand Paging
+ 4.9 LED Support + 5.0 NuttX File System
@@ -2900,7 +2924,418 @@ VxWorks provides the following comparable interface: means either that wdog is not valid or that the wdog has already expired.

-

4.4 Address Environments

+

4.4 Work Queues

+

Work Queues. + NuttX provides work queues. Work queues are threads the service a queue of work items to be performed. There are useful for off-loading work to a different threading context, for delayed processing, or for serializing activities. +

+ +

4.4.1 Classes of Work Queues

+ +

Classes of Work Queues. + There are three different classes of work queues, each with different properties and intended usage. These class of work queues along with the the common work queue interface are described in the following paragraphs. +

+ +

4.4.1.1 High Priority Kernel Work queue

+ +

High Priority Kernel Work queue. + The dedicated high-priority work queue is intended to handle delayed processing from interrupt handlers. This work queue is required for some drivers but, if there are no complaints, can be safely disabled. The high priority worker thread also performs garbage collection -- completing any delayed memory deallocations from interrupt handlers. If the high-priority worker thread is disabled, then that clean up will be performed either by (1) the low-priority worker thread, if enabled, and if not (2) the IDLE thread instead (which runs at the lowest of priority and may not be appropriate if memory reclamation is of high priority) +

+

Device Driver Bottom Half. + The higher priority worker thread is intended to serve as the bottom half for device drivers. As a consequence it must run at a very high, fixed priority rivalling the priority of the interrupt handler itself. Typically, the high priority work queue should be the highest priority thread in your system (the default priority is 224). +

+

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 CONFIG_PRIORITY_INHERITANCE is also selected): The priority of the lower priority worker thread can then be adjusted to match the highest priority client. +

+

+ Configuration Options. +

+ +

+ Common Configuration Options. + These options apply to all work queues: +

+ + +

4.4.1.2 Low Priority Kernel Work Queue

+

+ Low Priority Kernel Work Queue. + This lower priority work queue is better suited for more extended, application oriented processing such as file system clean-up, memory garbage collection and asynchronous I/O operations. +

+

+ Compared to the High Priority Work Queue. + The lower priority work queue runs at a lower priority than the high priority work queue, of course, and so is inapproperiate to serve as a driver bottom half. The lower priority work queue has the other advantages, however, that make it better suited for some tasks: +

+ +

+ Configuration Options. +

+ + +

4.4.1.3 User-Mode Work Queue

+

+ Work Queue Accessibility. + The high- and low-priority worker threads are kernel-mode threads. In the normal, flat NuttX build, these work queues are are useful to application code and may be shared. However, in the NuttX protected and kernel build modes, kernel mode code is isolated and cannot be accessed from user-mode code. +

+

+ User-Mode Work Queue. + if either CONFIG_BUILD_PROTECTED or CONFIG_BUILD_KERNEL are selected, then the option to enable a special user-mode work queue is enable. The interface to the user-mode work queue is identical to the interface to the kernel-mode work queues and the user-mode work queue is functionally equivalent to the high priority work queue. It differs in that its implementation does not depend on internal, kernel-space facilities. +

+

+ Configuration Options. +

+ + +

4.4.2 Common Work Queue Interfaces

+

4.4.2.1 Work Queue IDs

+ +

+ Work queue IDs. + All work queues use the identical interface functions (at least identical in terms of the function signature). The first parameter passed to the work queue interface function identifies the work queue: +

+

+ Kernel-Mode Work Queue IDs: +

+

+

+ User-Mode Work Queue IDs: +

+

+ +

4.4.2.2 Work Queue Interface Types

+ + + +

4.4.2.3 Work Queue Interfaces

+
4.4.2.3.1 work_queue()
+

+ Function Prototype: +

+

+

+ Description. + Queue work to be performed at a later time. All queued work will be performed on the worker thread of execution (not the caller's). +

+

+ The work structure is allocated by caller, but completely managed by the work queue logic. The caller should never modify the contents of the work queue structure; the caller should not call work_queue() again until either (1) the previous work has been performed and removed from the queue, or (2) work_cancel() has been called to cancel the work and remove it from the work queue. +

+

+ Input Parameters: +

+ +

+ Returned Value: +

+ + +
4.4.2.3.2 work_cancel()
+

+ Function Prototype: +int work_cancel(int qid, FAR struct work_s *work); +

+

+

+ Description. + Cancel previously queued work. This removes work from the work queue. After work has been cancelled, it may be re-queue by calling work_queue() again. +

+

+ Input Parameters: +

+ +

+ Returned Value: +

+ + +
4.4.2.3.3 work_signal()
+

+ Function Prototype: +int work_signal(int qid); +

+

+

+ Description. + Signal the worker thread to process the work queue now. This function is used internally by the work logic but could also be used by the user to force an immediate re-assessment of pending work. +

+

+ Input Parameters: +

+ +

+ Returned Value: +

+ + +
4.4.2.3.4 work_available()
+

+ Function Prototype: +

+

+

+ Description. +

+

+ Input Parameters: + Check if the work structure is available. +

+ +

+ Returned Value: +

+ + +
4.4.2.3.5 work_usrstart()
+

+ Function Prototype: +

+

+

+ Description. + The function is only available as a user interface in the kernel-mode build. In the flat build, there is no user-mode work queue; in the protected mode, the user-mode work queue will automatically be started by the OS start-up code. But in the kernel mode, each user process will be required to start is own, private instance of the user-mode work thread using this interface. +

+

+ Input Parameters: None +

+

+ Returned Value: +

+ + +
4.4.2.3.6 lpwork_boostpriority()
+

+ Function Prototype: +

+

+

+ Description. + Called by the work queue client to assure that the priority of the low-priority worker thread is at least at the requested level, reqprio. This function would normally be called just before calling work_queue(). +

+

+ Input Parameters: +

+ +

+ Returned Value: None +

+ +
4.4.2.3.7 lpwork_restorepriority()
+

+ Function Prototype: +

+

+

+ Description. + This function is called to restore the priority after it was previously boosted. This is often done by client logic on the worker thread when the scheduled work completes. It will check if we need to drop the priority of the worker thread. +

+

+ Input Parameters: +

+ +

+ Returned Value: None +

+ +

4.5 Address Environments

CPUs that support memory management units (MMUs) may provide address environments within which tasks and their child threads execute. The configuration indicates the CPUs ability to support address environments by setting the configuration variable CONFIG_ARCH_HAVE_ADDRENV=y. @@ -2923,35 +3358,35 @@ VxWorks provides the following comparable interface:

@@ -2964,12 +3399,12 @@ VxWorks provides the following comparable interface:

@@ -2992,19 +3427,19 @@ VxWorks provides the following comparable interface:

@@ -3018,17 +3453,17 @@ VxWorks provides the following comparable interface:

-

4.4.1 up_addrenv_create()

+

4.5.1 up_addrenv_create()

Function Prototype:

-

4.4.2 up_addrenv_destroy()

+

4.5.2 up_addrenv_destroy()

Function Prototype:

-

4.4.3 up_addrenv_vtext()

+

4.5.3 up_addrenv_vtext()

Function Prototype:

-

4.4.4 up_addrenv_vdata()

+

4.5.4 up_addrenv_vdata()

Function Prototype:

-

4.4.5 up_addrenv_heapsize()

+

4.5.5 up_addrenv_heapsize()

Function Prototype:

-

4.4.6 up_addrenv_select()

+

4.5.6 up_addrenv_select()

Function Prototype:

-

4.4.7 up_addrenv_restore()

+

4.5.7 up_addrenv_restore()

Function Prototype:

-

4.4.8 up_addrenv_clone()

+

4.5.8 up_addrenv_clone()

Function Prototype:

-

4.4.9 up_addrenv_attach()

+

4.5.9 up_addrenv_attach()

Function Prototype:

-

4.4.10 up_addrenv_detach()

+

4.5.10 up_addrenv_detach()

Function Prototype:

-

4.4.11 up_addrenv_ustackalloc()

+

4.5.11 up_addrenv_ustackalloc()

Function Prototype:

-

4.4.12 up_addrenv_ustackfree()

+

4.5.12 up_addrenv_ustackfree()

Function Prototype:

-

4.4.13 up_addrenv_vustack()

+

4.5.13 up_addrenv_vustack()

Function Prototype:

-

4.4.14 up_addrenv_ustackselect()

+

4.5.14 up_addrenv_ustackselect()

Function Prototype:

-

4.4.15 up_addrenv_kstackalloc()

+

4.5.15 up_addrenv_kstackalloc()

Function Prototype:

-

4.4.16 up_addrenv_kstackfree()

+

4.5.16 up_addrenv_kstackfree()

Function Prototype:

-

4.5 APIs Exported by NuttX to Architecture-Specific Logic

+

4.6 APIs Exported by NuttX to Architecture-Specific Logic

These are standard interfaces that are exported by the OS for use by the architecture specific logic.

-

4.5.1 os_start()

+

4.6.1 os_start()

To be provided

-

4.5.2 OS List Management APIs

+

4.6.2 OS List Management APIs

To be provided

-

4.5.3 sched_process_timer()

+

4.6.3 sched_process_timer()

Function Prototype: void sched_process_timer(void);

Description. @@ -3393,7 +3828,7 @@ VxWorks provides the following comparable interface: MSEC_PER_TICK.

-

4.5.4 sched_timer_expiration()

+

4.6.4 sched_timer_expiration()

Function Prototype:

-

4.5.5 sched_alaram_expiration()

+

4.6.5 sched_alaram_expiration()

Function Prototype:

-

4.5.6 irq_dispatch()

+

4.6.6 irq_dispatch()

Function Prototype: void irq_dispatch(int irq, FAR void *context);

Description. @@ -3448,7 +3883,7 @@ void sched_timer_expiration(void); the appropriate, registered handling logic.

-

4.6 Shared Memory

+

4.7 Shared Memory

Shared memory interfaces are only available with the NuttX kernel build (CONFIG_BUILD_KERNEL=y). These interfaces support user memory regions that can be shared between multiple user processes. @@ -3457,7 +3892,7 @@ void sched_timer_expiration(void); Those interfaces are described below:

-

4.6.1 up_shmat()

+

4.7.1 up_shmat()

Function Prototype:

-

4.6.2 up_shmdt()

+

4.7.2 up_shmdt()

Function Prototype:

-

4.7 On-Demand Paging

+

4.8 On-Demand Paging

The NuttX On-Demand Paging feature permits embedded MCUs with some limited RAM space to execute large programs from some non-random access media. If the platform meets certain requirements, then NuttX can provide on-demand paging: @@ -3521,7 +3956,7 @@ int up_shmdt(uintptr_t vaddr, unsigned int npages); Please see the NuttX Demand Paging design document for further information.

-

4.8 LED Support

+

4.9 LED Support

A board architecture may or may not have LEDs. @@ -3531,7 +3966,7 @@ int up_shmdt(uintptr_t vaddr, unsigned int npages); However, the support provided by each architecture is sufficiently similar that it can be documented here.

-

4.8.1 Header Files

+

4.9.1 Header Files

LED-related definitions are provided in two header files: @@ -3555,7 +3990,7 @@ int up_shmdt(uintptr_t vaddr, unsigned int npages);

-

4.8.2 LED Definitions

+

4.9.2 LED Definitions

The implementation of LED support is very specific to a board architecture. @@ -3619,7 +4054,7 @@ int up_shmdt(uintptr_t vaddr, unsigned int npages); -

4.8.3 Common LED interfaces

+

4.9.3 Common LED interfaces

The <arch-name>/src/common/up_internal.h probably has definitions