From c255df1df9c1cd51e6d0e71ee5f2e92a22eac5cf Mon Sep 17 00:00:00 2001 From: Lorenz Meier Date: Thu, 13 Jun 2013 09:14:40 +0200 Subject: Merged in upstream, took upstream UART driver without changes, needs re-evaluation (minor diffs to local version) --- nuttx/Documentation/NuttxPortingGuide.html | 169 +++++++++++++++++++++-------- 1 file changed, 124 insertions(+), 45 deletions(-) (limited to 'nuttx/Documentation/NuttxPortingGuide.html') diff --git a/nuttx/Documentation/NuttxPortingGuide.html b/nuttx/Documentation/NuttxPortingGuide.html index 845f4e5d5..236215fff 100644 --- a/nuttx/Documentation/NuttxPortingGuide.html +++ b/nuttx/Documentation/NuttxPortingGuide.html @@ -12,7 +12,7 @@

NuttX RTOS Porting Guide

-

Last Updated: March 20, 2013

+

Last Updated: June 11, 2013

@@ -46,7 +46,8 @@ 2.4.2.1 Board Specific Logic
2.4.2.2 Board Specific Configuration Sub-Directories - 2.4.3 Supported Boards + 2.4.3 Supported Boards
+ 2.4.4 Adding a New Board Configuration 2.5 nuttx/drivers/
2.6 nuttx/fs/
@@ -795,13 +796,13 @@
  • configs/ea3131: - Embedded Artists EA3131 Development bard. This board is based on the + Embedded Artists EA3131 Development bard. This board is based on the an NXP LPC3131 MCU. This OS is built with the arm-nuttx-elf toolchain. STATUS: This port is complete and mature.
  • configs/eagle100: - Micromint Eagle-100 Development board. This board is based on the + Micromint Eagle-100 Development board. This board is based on the an ARM Cortex-M3 MCU, the Luminary LM3S6918. This OS is built with the arm-nuttx-elf toolchain. STATUS: This port is complete and mature.
  • @@ -819,7 +820,7 @@
  • configs/lm3s6965-ek: - Stellaris LM3S6965 Evaluation Kit. This board is based on the + Stellaris LM3S6965 Evaluation Kit. This board is based on the an ARM Cortex-M3 MCU, the Luminary/TI LM3S6965. This OS is built with the arm-nuttx-elf toolchain. STATUS: This port is complete and mature.
  • @@ -926,7 +927,7 @@
  • configs/rgmp: - RGMP stands for RTOS and GPOS on Multi-Processor. RGMP is a project for + RGMP stands for RTOS and GPOS on Multi-Processor. RGMP is a project for running GPOS and RTOS simultaneously on multi-processor platforms. You can port your favorite RTOS to RGMP together with an unmodified Linux to form a hybrid operating system. This makes your application able to use both RTOS @@ -978,7 +979,7 @@
  • configs/xtrs: TRS80 Model 3. This port uses a vintage computer based on the Z80. - An emulator for this computer is available to run TRS80 programs on a + An emulator for this computer is available to run TRS80 programs on a Linux platform (http://www.tim-mann.org/xtrs.html).
  • @@ -1021,6 +1022,84 @@ is available to build these toolchains under Linux or Cygwin.

    +

    2.4.4 Adding a New Board Configuration

    +

    + Okay, so you have created a new board configuration directory. + Now, how do you hook this board into the configuration system so that you can select with make menuconfig? +

    +

    + You will need modify the file configs/Kconfig. + Let's look at the STM32F4-Discovery configuration in the Kconfig file and see how we would add a new board directory to the configuration. + For this configuration let's say that you new board resides in the directory configs/myboard; + It uses an MCU selected with CONFIG_ARCH_CHIP_MYMCU; and you want the board to be selected with CONFIG_ARCH_BOARD_MYBOARD. + Then here is how you can clone the STM32F4-Discovery configuration in configs/Kconfig to support your new board configuration. +

    +

    + In configs/Kconfig for the stm32f4-discovery, you will see a configuration definition like this: +

    +

    +

    + The above selects the STM32F4-Discovery board. + The select lines say that the board has both LEDs and buttons and that the board can generate interrupts from the button presses. + You can just copy the above configuration definition to a new location (notice that they the configurations are in alphabetical order). + Then you should edit the configuration to support your board. + The final configuration definition might look something like: +

    + +

    + Later in the configs/Kconfig file, you will see a long, long string configuration with lots of defaults like this: +

    + +

    + This logic will assign string value to a configuration variable called CONFIG_ARCH_BOARD that will name the directory where the board-specific files reside. + In our case, these files reside in configs/myboard and we add the following to the long list of defaults (again in alphabetical order): +

    + +

    + Now the build system knows where to find your board configuration! +

    +

    + And finally, add something like this near the bottom of configs/myboard: +

    + +

    + This includes additional, board-specific configuration variabled defintion in configs/myboard/Kconfig. +

    +

    2.5 nuttx/drivers

    @@ -1078,7 +1157,7 @@ drivers/ | |-- Kconfig | |-- Make.defs | `-- (Common USB host driver source files) -|-- wirelss/ +|-- wireless/ | |-- Kconfig | |-- Make.defs | `-- (Common wireless driver source files) @@ -1666,7 +1745,7 @@ The system can be re-made subsequently by just typing make.

    4.1.5 up_use_stack()

    -

    Prototype: +

    Prototype: STATUS up_use_stack(FAR struct tcb_s *tcb, FAR void *stack, size_t stack_size);

    @@ -1864,7 +1943,7 @@ The system can be re-made subsequently by just typing make.

    Description. Called when the priority of a running or - ready-to-run task changes and the reprioritization will + ready-to-run task changes and the reprioritization will cause a context switch. Two cases:

      @@ -2146,7 +2225,7 @@ else

      @@ -2175,13 +2254,13 @@ else Initialize the hardware RTC per the selected configuration. This function is called once during the OS initialization sequence -

    1. up_rtc_time(). +
    2. up_rtc_time(). Get the current time in seconds. This is similar to the standard time() function. This interface is only required if the low-resolution RTC/counter hardware implementation selected. It is only used by the RTOS during intialization to set up the system time when CONFIG_RTC is set but neither CONFIG_RTC_HIRES nor CONFIG_RTC_DATETIME are set.
    3. -
    4. up_rtc_gettime(). +
    5. up_rtc_gettime(). Get the current time from the high resolution RTC clock/counter. This interface is only supported by the hight-resolution RTC/counter hardware implementation. It is used to replace the system timer (g_system_tick). @@ -2250,11 +2329,11 @@ else Returns the virtual base address of the address environment.
    6. - 4.1.22.3 up_addrenv_select(): + 4.1.22.3 up_addrenv_select(): Instantiate an address environment.
    7. - 4.1.22.4 up_addrenv_restore(): + 4.1.22.4 up_addrenv_restore(): Restore an address environment.
    8. @@ -2315,7 +2394,7 @@ else

      Description:

        - Return the virtual address associated with the newly create address environment. + Return the virtual address associated with the newly create address environment. This function is used by the binary loaders in order get an address that can be used to initialize the new task.

      Input Parameters:

      @@ -2531,9 +2610,9 @@ else

      4.3.2 LED Definitions

      - The implementation of LED support is very specific to a board architecture. - Some boards have several LEDS, others have only one or two. - Some have none. + The implementation of LED support is very specific to a board architecture. + Some boards have several LEDS, others have only one or two. + Some have none. Others LED matrices and show alphanumeric data, etc. The NuttX logic does not refer to specific LEDS, rather, it refers to an event to be shown on the LEDS in whatever manner is appropriate for the board; @@ -2705,7 +2784,7 @@ extern void up_ledoff(int led); These different device driver types are discussed in the following paragraphs. Note: device driver support requires that the in-memory, pseudo file system - is enabled by setting the CONFIG_NFILE_DESCRIPTORS in the NuttX configuration file to a + is enabled by setting the CONFIG_NFILE_DESCRIPTORS in the NuttX configuration file to a non-zero value.

      @@ -3451,7 +3530,7 @@ extern void up_ledoff(int led);

      As part of its operation during the binding operation, the USB host class driver will register an instances of a standard NuttX driver under the /dev directory. To repeat the above example, the USB host mass storage class driver (drivers/usbhost/usbhost_storage.c) will register a standard, NuttX block driver interface (like /dev/sda) - that can be used to mount a file system just as with any other other block driver instance. + that can be used to mount a file system just as with any other other block driver instance.

      Examples: @@ -3487,7 +3566,7 @@ extern void up_ledoff(int led);

      Examples: - arch/arm/src/dm320/dm320_usbdev.c, arch/arm/src/lpc17xx/lpc17_usbdev.c, + arch/arm/src/dm320/dm320_usbdev.c, arch/arm/src/lpc17xx/lpc17_usbdev.c, arch/arm/src/lpc214x/lpc214x_usbdev.c, arch/arm/src/lpc313x/lpc313x_usbdev.c, and arch/arm/src/stm32/stm32_usbdev.c.

      @@ -3914,11 +3993,11 @@ int kbd_decode(FAR struct lib_instream_s *stream, FAR struct kbd_getstate_s *sta stream: An instance of lib_instream_s to perform the actual low-level get operation.
    9. - pch: The location to save the returned value. + pch: The location to save the returned value. This may be either a normal, character code or a special command (i.e., a value from enum kbd_getstate_s.
    10. - state: A user provided buffer to support parsing. + state: A user provided buffer to support parsing. This structure should be cleared the first time that kbd_decode() is called.
    11. @@ -3989,12 +4068,12 @@ int kbd_decode(FAR struct lib_instream_s *stream, FAR struct kbd_getstate_s *sta -

      USB Serial Device Class Driver (Prolific PL2303 Emulation)

      +

      USB Serial Device Class Driver (Prolific PL2303 Emulation)