Create freertos port

.gitmodules

@@ -1,3 +1,6 @@
 [submodule "third-party/ceedling"]
 	path = third-party/ceedling
 	url = https://github.com/ThrowTheSwitch/Ceedling.git
+[submodule "third-party/freertos/freertos_kernel"]
+	path = third-party/freertos/freertos_kernel
+	url = https://github.com/FreeRTOS/FreeRTOS-Kernel.git

.travis.yml

@@ -12,7 +12,8 @@ os:
     - linux
 
 install:
-    - sudo gem install ceedling
+    - gem install bundler
+    - gem install ceedling
     - sudo apt-get install lcov
     - sudo apt-get install cppcheck
 

demo/cross/shared/build/arm-cortex/freertos/ciaa-nxp/README_en.md

@@ -0,0 +1,139 @@
+# *Shared* example
+
+## Description:
+
+This application deals with the shared resource problem in active object systems. Showing one of the biggest benefit of using active objects: resource encapsulation.
+
+The encapsulation naturally designates the owner of the resource as the ultimate arbiter in resolving any contention and potential conflicts for the resource.
+
+The *Shared* application is relatively simple and can be tested only with a couple of LEDs on your target board.
+
+Still, *Shared* contains five (5) concurrent active objects that exchange events via direct event posting mechanism.
+
+The application uses four timers, as well as dynamic and static events.
+On the other hand, this application could be used in either preemptive or cooperative environment.
+
+Additionally, the *Shared* could be used to verify a new RKH port.
+
+
+## *BSP*
+
+As it was said before, this application is the current *"Gold Standard"* to test the proper working of a newly developed port. For this reason, this example (or *demo*) can be compiled for multiple platforms. In this case, it's to validate the FreeRTOS port but many others can be found in the RKH/demo tree.
+
+Even though this port can run in multiple hardware targets depending in FreeRTOS's compatibility, in this particular case it is used the NXP LPC4337 based CIAA board (in either educational or full version) for convenience.
+
+## IDE & Compiling
+
+This project was developed and tested on [MCUXpresso](https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-integrated-development-environment-ide:MCUXpresso-IDE) in order to simplify the process with all the embedded tools it contains. As it's an *Eclipse IDE* after all, you can use it too provided that you make the necessary changes regarding the *toolchain* used to compile the code.
+
+### Import the project
+
+Just go to `File->Import` and select the `Import Projects from File System or Archive` option. Point to the `mcuxpresso` directory located where this README is located and proceed to import the project listed.
+
+### Platform specific parameters
+
+To differ the compiling process to one of the mentioned platforms, an environment variable is used. This variable is `BOARD`, selected for compatibility with some board-specific code.
+
+To select the platform, there is no need to change the variable's value. Just **select the build configuration desired** in `Project->Build Configurations->Set Active`.
+
+### RKH related memory usage
+
+Next we can see a table depicting the memory usage by RKH modules for this demo including the *trace* capability. All values shown are in bytes.
+
+| Module         | .bss | .text | .data | .rodata |
+|----------------|-----:|------:|------:|--------:|
+| rkhfwk_bittbl  |    0 |    44 |     0 |       8 |
+| rkhfwk_dynevt  |   36 |   860 |     0 |      16 |
+| rkhfwk_evtpool |   80 |   344 |     0 |      16 |
+| rkhfwk_pubsub  |    0 |     0 |     0 |       0 |
+| rkhfwk_rdygrp  |    0 |     0 |     0 |       0 |
+| rkhfwk_sched   |    0 |     0 |     0 |       0 |
+| rkhfwk_version |    0 |     0 |     0 |       8 |
+| rkhmempool     |    0 |   760 |     0 |      12 |
+| rkhqueue       |   12 |   776 |     0 |      12 |
+| rkhsm          |    0 |  3016 |     0 |      16 |
+| rkhsma         |   32 |   672 |     0 |       8 |
+| rkhsma_prio    |    0 |     0 |     0 |       0 |
+| rkhsma_sync    |    0 |     0 |     0 |       0 |
+| rkhtmr         |    4 |   976 |     0 |       8 |
+| rkhtrc_filter  |   26 |   784 |     0 |      48 |
+| rkhtrc_record  |    2 |   812 |     0 |       0 |
+| rkhtrc_stream  |  528 |   336 |     0 |       0 |
+
+Next the same analysis without *trace*.
+
+| Module         | .bss | .text | .data | .rodata |
+|----------------|-----:|------:|------:|--------:|
+| rkhfwk_bittbl  |    0 |     0 |     0 |       0 |
+| rkhfwk_dynevt  |   36 |   456 |     0 |      16 |
+| rkhfwk_evtpool |   80 |   216 |     0 |      16 |
+| rkhfwk_pubsub  |    0 |     0 |     0 |       0 |
+| rkhfwk_rdygrp  |    0 |     0 |     0 |       0 |
+| rkhfwk_sched   |    0 |     0 |     0 |       0 |
+| rkhfwk_version |    0 |     0 |     0 |       8 |
+| rkhmempool     |    0 |   576 |     0 |      12 |
+| rkhqueue       |   12 |   508 |     0 |      12 |
+| rkhsm          |    0 |  1200 |     0 |      16 |
+| rkhsma         |   32 |   472 |     0 |       8 |
+| rkhsma_prio    |    0 |     0 |     0 |       0 |
+| rkhsma_sync    |    0 |     0 |     0 |       0 |
+| rkhtmr         |    4 |   684 |     0 |       8 |
+| rkhtrc_filter  |    0 |     0 |     0 |       0 |
+| rkhtrc_record  |    0 |     0 |     0 |       0 |
+| rkhtrc_stream  |    0 |     0 |     0 |       0 |
+
+You can see the small footprint added by the framework.
+
+## Running/Debugging the application
+
+
+### Interface
+To debug the application, it is used the board included programming/debugging interface. It's based on the FTDI FT2232H, the rather well known IC that exposes a JTAG interface and a UART through USB.
+
+The JTAG is managed by OpenOCD and for this, the corresponding script is provided.
+
+### Starting the session in the IDE
+Included in the project there are two launchers (and one more as a legacy/backup) that will initiate the tools embedded in MCUXpresso (Check the [documentation](https://www.nxp.com/docs/en/quick-reference-guide/MCUXpresso_IDE_FreeRTOS_Debug_Guide.pdf) about this subject). One for each platform previously said.
+
+The only difference between each launcher is an argument passed to the OpenOCD program to deal with the specific target.
+
+The launchers will start an instance of OpenOCD and GDB. They will also inform to the OpenOCD that it has to be aware of the presence of FreeRTOS so we can get the full benefits of this tool. To see more details of this, please go to [OpenOCD's documentation](http://openocd.org/doc/html/GDB-and-OpenOCD.html#RTOS-Support).
+
+As we configure the OpenOCD in this way, it will inform to the GDB the "presence" of the rtos threads and they will be listed independently during the debug session. But it has a drawback: it will fetch a structure that informs about the threads and if it's not created already it will crash. To prevent this, the temporary breakpoint normally set on main is removed. **If it's not removed the debug session will fail at start**. In the launchers this temporary breakpoint was moved to `vTaskStartScheduler` as it is a safe location to infer that the according structure is already created and populated.
+
+In case that you need to debug the initialization or task creation process, we recommend to tailor the third debug launcher to your needs as it will not configure the OpenOCD to be RTOS-aware. This will not try to list the threads and a breakpoint can be placed on the main to debug this section of the application. Be aware that a temporary breakpoint can persist even if you change the debug configuration.
+
+### Interfacing with the app and the RKH framework
+
+The app will have a "console output" using semihosting through the JTAG interface. It will show the banner or "splash" information of the demo and the messages generated to inform the client-server interaction.
+
+Also, if the trace capability is enabled, the according output is channelized through the UART to the COM/TTY interface. In this case you can run [Trazer](https://github.com/vortexmakes/Trazer) to interpret it.
+
+In case that you are using Linux, you can launch it with:
+```sh
+./trazer -c /dev/ttyUSB1 19200 8N1
+```
+
+This tool will allow you to store the trace in a file using the `-o` argument and you can analyse it later on in a tool like [Trace Compass](https://github.com/vortexmakes/TrazerTC).
+
+### Demo workings
+
+You will notice that this demo is using FreeRTOS to encapsulate each *Active Object* in a independent thread. To communicate between them, the artifacts of FreeRTOS (e.g. queues, etc) are used.
+
+This is **not** the only way you can integrate RKH and FreeRTOS in a project. For example, you can dedicate a single thread to the framework and use RKH's scheduler an IPCs. This will be left to the reader to explore.
+
+### Demo hardware interaction
+
+As this example can be compiled either for CIAA-NXP or EDU-CIAA-NXP platforms, the means to interact with the app running differ:
+
+Each Client has its own LED to show when the server is running its request. The assignment is according to the next table.
+
+|   Platform   | Client 1 | Client 2 | Client 3 | Client 4 |
+|:------------:|:--------:|:--------:|:--------:|:--------:|
+|   CIAA-NXP   |   DOUT4  |   DOUT5  |   DOUT6  |   DOUT7  |
+| EDU-CIAA-NXP |   LEDB   |   LED1   |   LED2   |   LED3   |
+
+To pause the server, one has to drive the `DIN0` input or press the `TEC1` button depending if you are using the CIAA-NXP or EDU-CIAA-NXP respectively. This will generate a pause `event`.
+When the server is paused, this situation will be indicated lighting **all** the Client's LEDs at the same time.
+
+To resume from the pause, just press or activate again the previous input.

demo/cross/shared/build/arm-cortex/freertos/ciaa-nxp/ciaa-nxp.cfg

@@ -0,0 +1,179 @@
+###############################################################################
+#
+# Copyright 2014, Juan Cecconi (UTN-FRBA, Numetron)
+#
+# This file is part of CIAA Firmware.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# 1. Redistributions of source code must retain the above copyright notice,
+#    this list of conditions and the following disclaimer.
+#
+# 2. Redistributions in binary form must reproduce the above copyright notice,
+#    this list of conditions and the following disclaimer in the documentation
+#    and/or other materials provided with the distribution.
+#
+# 3. Neither the name of the copyright holder nor the names of its
+#    contributors may be used to endorse or promote products derived from this
+#    software without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+#
+###############################################################################
+#OpenOCD configuration (target and interface) for CIAA-NXP
+
+######################################################################################################
+# Utilizar una interface tipo FTDI, todo lo que sigue está basado en ello
+######################################################################################################
+interface ftdi
+
+######################################################################################################
+# Agrego el Par VID-PID del FTDI, si hay más agregar a continuación...
+######################################################################################################
+ftdi_vid_pid 0x0403 0x6010
+
+######################################################################################################
+# Se utilizó el Channel A (ADBUS0 a ADBUS3) para conectar el JTAG mediante MPSSE
+######################################################################################################
+ftdi_channel 0
+
+######################################################################################################
+# ftdi_layout_init 'Valor' 'Dirección', Configura los GPIO (H-L), su valor y dirección en ese orden(1 = Salida, 0 = entrada)
+# los 16 bits se arman H-L como sigue 'ACBUS7-0+ADBUS7-0'
+#ADBUS0 = FT_CLCK = 1, salida de Clock
+#ADBUS1 = FT_TDI = 1, salida de datos del FT
+#ADBUS2 = FT_TDO = 0, entrada de datos al FT
+#ADBUS3 = FT_TMS = 1, salida de Test Mode Select, setear a 1
+#ADBUS4 = Pin 14 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
+#ADBUS5 = Pin 12 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
+#ADBUS6 = Pin 10 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
+#ADBUS7 = Pin 8 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
+#ACBUS0 = FT_TRST = 1, salida de TRST...va al buffer y luego no se usa, setear a 1
+#ACBUS1 = FT_RST = 1, salida de RST...va al buffer y luego no se usa, setear a 1
+#ACBUS2 = FT_OE = 1, salida de OE para manejar el Buffer del JTAG, setear a 1
+#ACBUS3 = Pin 6 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
+#ACBUS4 = Pin 4 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
+#ACBUS5 = Pin 2 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
+#ACBUS6 = Pin 1 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
+#ACBUS7 = Pin 3 - conector P9 = 1 salida para no dejar flotante e ingresar ruido al FT
+######################################################################################################
+ftdi_layout_init 0x0708 0xFFFB
+
+######################################################################################################
+# La creación de las señales que siguen no hacen falta porque se indicó en el Target cfg que no se
+# las tiene conectadas a ningún lado
+######################################################################################################
+
+######################################################################################################
+# Creo la señal llamada nTRST (Not TAP Reset) que es una tipo dato, y usa el bit 8 del GPIO (H-L), es
+# decir GPIOH0 (pin ACBUS0) por eso 0x100, y a la vez se activa conjuntamente con el OE que
+# está usado en el bit 10 del GPIO, es decir, en GPIOH2 (pin ACBUS2) por eso 0x400
+######################################################################################################
+#ftdi_layout_signal nTRST -data 0x0100
+
+######################################################################################################
+# Creo la señal llamada nSRST (Not System Reset) que se activa cuando se hace un cmd 'reset'
+# Es tipo dato y usa el bit 9 del GPIO (H-L), es decir GPIOH1 (pin ACBUS1) por eso 0x200,
+# y a la vez se activa conjuntamente con el OE que  está usado en el bit 10 del GPIO, es decir,
+# en GPIOH2 (pin ACBUS2) por eso 0x400
+######################################################################################################
+#ftdi_layout_signal nSRST -data 0x0200
+
+################################################################
+# Especifica en KHz la frecuencia del Clock en el JTAG (TCK)
+################################################################
+transport select jtag
+adapter_khz 8000
+
+################################################################
+# Defino nombre de CHIP
+################################################################
+set _CHIPNAME lpc4337
+
+################################################################
+# Defino los TAP del JTAG, para el core M4 y M0
+################################################################
+
+# M4 JTAG mode TAP
+set _M4_JTAG_TAPID 0x4ba00477
+
+# M0 TAP
+set _M0_JTAG_TAPID 0x0ba01477
+
+jtag newtap $_CHIPNAME m4 -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_M4_JTAG_TAPID
+
+jtag newtap $_CHIPNAME m0 -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_M0_JTAG_TAPID
+
+################################################################
+# Creo los 2 targets lpc4337.m4 y lpc4337.m0
+################################################################
+target create $_CHIPNAME.m4 cortex_m -chain-position $_CHIPNAME.m4
+target create $_CHIPNAME.m0 cortex_m -chain-position $_CHIPNAME.m0
+
+################################################################
+# Defino un area de trabajo en la RAM para acelerar el proceso
+# de programación de la flash
+################################################################
+set _WORKAREASIZE 0x8000
+$_CHIPNAME.m4 configure -work-area-phys 0x10000000 -work-area-size $_WORKAREASIZE
+
+################################################################
+# Se define un banco de flash, grabable usando el driver lpc2000
+# que es compatible con el LPC4337
+# flash bank <name> lpc2000 <base> <size> 0 0 <target#> <variant> <clock> [calc checksum]
+################################################################
+set _FLASHNAME $_CHIPNAME.flash
+flash bank $_FLASHNAME lpc2000 0x1a000000 0x80000 0 0 $_CHIPNAME.m4 lpc4300 96000 calc_checksum
+
+################################################################
+# Se define un banco de flash qspi, grabable usando el driver lpcspifi
+# que es compatible con el LPC4337. Solo usable para la CIAA-NXP (no EDU)
+# flash bank <name> lpcspifi <base> <size> 0 0 <target#>
+################################################################
+if { ![info exists ::env(BOARD)] || [info exists ::env(BOARD)] && [string equal $::env(BOARD) "ciaa_nxp"]} {
+   if { [info exists ::env(BOARD)]} {
+      echo "Using CIAA-NXP, qspi flash defined!"
+   } else {
+      echo "BOARD variable undefined: Using CIAA-NXP as default board, qspi flash defined!"
+   }
+   set _QSPIFLASHNAME $_CHIPNAME.spiflash
+   flash bank $_QSPIFLASHNAME lpcspifi 0x14000000 0 0 0 $_CHIPNAME.m4
+   } else {
+   echo "Using Edu-CIAA-NXP, qspi flash is not present!"
+}
+
+################################################################
+# TRST (TAP Reset) y SRST (System Reset) no están conectados más allá del Buffer
+# en el prototipo.
+# Por lo tanto se indica 'none'
+################################################################
+reset_config none
+
+################################################################
+# on this CPU we should use VECTRESET to perform a soft reset and
+# manually reset the periphery
+# SRST or SYSRESETREQ disable the debug interface for the time of
+# the reset and will not fit our requirements for a consistent debug
+# session
+################################################################
+cortex_m reset_config vectreset
+
+set _TARGETNAME $_CHIPNAME.m4
+
+targets $_CHIPNAME.m4
+
+$_CHIPNAME.m4 configure -event gdb-attach {
+   echo "Reset Halt, due to gdb attached...!"
+   reset halt
+}