Create freertos port

[leanfrancucci]

[leanfrancucci]

Después de hacer un análisis de shared y del port para freertos, aporto algunas ideas para resolverlo:

1. Sabemos que main() no puede cambiarse porque es una app cross, tenemos que lidiar desde el port (rkhport.c) y el bsp (bsp_shared.c)
2. En bsp_shared.c podemos plantear bsp_init() como:

bsp_init(...)
{
    ...
    rkh_fwk_init();
    RKH_FILTER_*;
    RKH_TRC_OPEN();
}

3. En rkhport.c:

• rkh_fwk_init() es responsable de establecer dónde se ejecuta el tick de RKH (RKH_TIM_TICK()) para manejar los timers. En freertos tenemos tres posibilidades:
  • Desde la callback de un software timer de freertos. Esta se ejecuta en contexto de tarea. Es mi opción favorita
  • Desde una tarea específica que ejecuta un loop con un retardo. Similar a lo que hacía rkh_fwk_enter()
  • Desde el hook de la función tick de freertos. Esta se ejecuta en contexto de ISR

rkh_fwk_init(...)
{
    /* There are 3 alternatives to execute RKH_TIM_TICK() */
    /* 1. From a FreeRTOS software timer (Task context) */ /* <- favorite */
    /* 2. From a specific task (Task context) */
    /* 3. From FreeRTOS tick hook function (ISR context) */
}

• rkh_fwk_enter() es responsable principalmente de llamar al scheduler del OS

rkh_fwk_enter(...)
{
    RKH_HOOK_START();   /* start-up callback */
    RKH_TR_FWK_EN();
    vTaskStartScheduler();
    RKH_HOOK_EXIT();    /* cleanup callback */
}

[cmancon]

@leanfrancucci algunos comentarios sin sopesar completamente cada opción:

1. Sabemos que main() no puede cambiarse porque es una app cross, tenemos que lidiar desde el port (rkhport.c) y el bsp (bsp_shared.c)

Estoy de acuerdo con lo anterior, siempre y cuando no afecte negativamente al port. Es decir, terminar haciendo un port a medida para una app y un main en particular. No creo que suceda pero me refiero a no tener completamente cerrada la opción de hacer una modificación en un main, mientras que la misma sea una abstracción compatible con todas las plataformas. Lo planteo en el sentido de no sesgar la solución, no por alguna razón técnica.

2. En bsp_shared.c podemos plantear bsp_init() como:

bsp_init(...)
{
    ...
    rkh_fwk_init();
    RKH_FILTER_*;
    RKH_TRC_OPEN();
}

Si no me equivoco, el planteo es mantener el bsp_init() como se encuentra en la actualidad.

1. En rkhport.c:

• rkh_fwk_init() es responsable de establecer dónde se ejecuta el tick de RKH (RKH_TIM_TICK()) para manejar los timers. En freertos tenemos tres posibilidades:

  • Desde la callback de un software timer de freertos. Esta se ejecuta en contexto de tarea. Es mi opción favorita
  • Desde una tarea específica que ejecuta un loop con un retardo. Similar a lo que hacía rkh_fwk_enter()
  • Desde el hook de la función tick de freertos. Esta se ejecuta en contexto de ISR

rkh_fwk_init(...)
{
    /* There are 3 alternatives to execute RKH_TIM_TICK() */
    /* 1. From a FreeRTOS software timer (Task context) */ /* <- favorite */
    /* 2. From a specific task (Task context) */
    /* 3. From FreeRTOS tick hook function (ISR context) */
}

Concuerdo con la idea y preferencia del Software Timer.

• rkh_fwk_enter() es responsable principalmente de llamar al scheduler del OS

rkh_fwk_enter(...)
{
    RKH_HOOK_START();   /* start-up callback */
    RKH_TR_FWK_EN();
    vTaskStartScheduler();
    RKH_HOOK_EXIT();    /* cleanup callback */
}

Me genera interrogantes de la compatibilidad del port cuando la aplicación sea parte no reactiva y parte reactiva.

Por otra parte, tu análisis sugiere que no es necesaria la función rkh_startupTask(). ¿Entendí bien?

[cmancon]

Perdón, botón equivocado... :S

[leanfrancucci]

@cmancon respecto del main() y su relación con el port. Si la aplicación está basada en el framework entonces el main() generalmente tiene la forma del de shared. Y además se relaciona de manera similar con el bsp y el port.

Ahora, a esta arquitectura se le pueden sumar, sin ningún problema, tareas que no usan el framework.

Por otro lado, si se requiere usar el framework con una aplicación existente que usa freertos entonces puede que el port deba modificarse o incluso se requiera crear otro diferente. Eso lo veremos cuando nos enfrentemos con el problema. Por ahora me inclino por resolver el port para aplicaciones basadas en el fwk.

Respecto de usar el fwk en aplicaciones ya funcionando, es exactamente el caso de lo que podríamos enfrentar al incluir RKH en ESP8266_RTOS_SDK. Dicho sea de paso, estuve analizando cómo crear tareas propias dentro de la arquitectura ESP8266_RTOS_SDK y en principio parece viable agregar el fwk para resolver la "lógica de más alto nivel" del dispositivo, haciendo uso de todas las bibliotecas y funcionalidades que provee ESP8266_RTOS_SDK

Por otra parte, tu análisis sugiere que no es necesaria la función rkh_startupTask(). ¿Entendí bien?

Si, en principio no es necesaria.

[leanfrancucci]

@cmancon tenés algo de estadística de shared ejecutándose al cabo de un tiempo pronunciado, tipo valores máximos o promedio de Stack Usage y Runtime?

[cmancon]

No recuerdo si tengo guardados los resultados pero he dejado funcionando el ejemplo unas 5 horas verificando los valores en las herramientas de Debug de FreeRTOS de MCUXpresso. Me parecían bastante saludables.

Lo que no recuerdo que tuviera era el watermark, pero si el uso de Stack por tarea y su respectivo Runtime

¿Te parece que hagamos un ensayo y registremos acá los resultados?

[leanfrancucci]

@cmancon tenés info de ocupación de RAM y ROM de los archivos de la app shared y del fwk?. Tal vez tengas el IDE resume estos datos o sino pueden estar en el archivo que especifica el mapa de carga

[cmancon]

Bueno, habría que ver qué compilación tomar como parámetro.

Como para dar una idea, el siguiente es el uso de memoria del Shared usando semishoting con redlib(semihost) y teniendo el trace activado:

Memory region	Used Size	Region Size	%age Used
MFlashA512:	43504 B	512 KB	8.30%
MFlashB512:	0 B	512 KB	0.00%
RamLoc32:	10200 B	32 KB	31.13%
RamLoc40:	40 KB	40 KB	100.00%
RamAHB32:	0 B	32 KB	0.00%
RamAHB16:	8 KB	16 KB	50.00%
RamAHB_ETB16:	0 B	16 KB	0.00%

Tanto RamLoc40 como RamAHB16 estan manejados por el MCUXpresso con el Managed Linker Script y allocan heap y stack respectivamente.

Como estamos usando el heap3 que envuelve el malloc() y el free() no puedo aproximar cuánto del heap dedicado es utilizado.

[leanfrancucci]

Are there pending tasks related to this port?. It would be great to turn over a new leaf, and then to think about fresh application examples with freeRTOS and RKH, as we have talked about several weeks ago :muscle: :muscle:

[cmancon]

We are back to English? hehe Possible tasks to finish:

1. Merge #14
2. Compose some sort of memory usage report.
3. Compose a README.

What do you think?

[codecov-commenter]

Codecov Report

Merging #13 into develop will increase coverage by 0.03%. The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop      #13      +/-   ##
===========================================
+ Coverage    95.65%   95.68%   +0.03%     
===========================================
  Files           13       13              
  Lines          598      603       +5     
===========================================
+ Hits           572      577       +5     
  Misses          26       26              

Impacted Files	Coverage Δ
source/tmr/src/rkhtmr.c	100.00% <0.00%> (ø)
source/fwk/src/rkhfwk_evtpool.c	100.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 16b319c...4af13ed. Read the comment docs.