Linux más freertos o baremetal

[Carlos Pantelides]

Hola,

Un amigo está haciendo algún controlador con raspberry pi + python y no le daba bien el tiempo real así que hizo algo muy ingenioso con soft y fuzzy logic y lo logró pero me parece que era medio chancho.

Entonces le dije, "por qué no corrés linux en 3 cores y en el restante resolvés el tiempo real, tipo un coprocesador de tiempo real que mida y calcule y sólo te mande los resultados?"

Como ya lo hizo chancho pero anda, no tiene incentivo en investigar, pero a mí me queda la inquietud y por más que he buscado no he hallado referencias a ejecutar linux en 3 cores de una raspberry pi y freertos o baremetal en el restante, que dicho en general entiendo que sería

limitar linux a 3 cores

limitar linux a que no use toda la memoria

configurar las interrupciones para que le peguen a los cores de linux salvo algunas selectas para el restante

avisarle a linux que ciertos dispositivos no son suyos

ejecutar un programa o sistema operativo en el core restante informándole cual es su memoria, interrupciones y dispositivos

establecer algún método para intercambiar mensajes

quizás lidiar con la coherencia del cache?

Si esa lista conceptualmente es correcta y completa, de ahí a la realidad sin duda hay un arduo camino.

Luego ví que freertos no soporta oficialmente raspberry, así que me quedaría solo con baremetal.

¿alguien sabe o tiene pistas?

O quizás más sencillo, ¿se podría desde mismo linux asignarle a un proceso y a una interrupción un core y viceversa de modo exclusivo?

Gracias y saludos

[Alejandro Celery]

Charlie, me tiro un piletazo muy descolgado:

Linux usa Device Trees para saber que hardware tiene montado abajo (cosas como USB las puede enumerar el kernel, cosas como el layout de memoria que yo sepa no).

Deberias agarrar el DT para raspberry y podarle el hardware que queres reservar para FreeRTOS.

Despues tendrias que ver desde Linux como "flashear" el binario y la memoria que queres en el resto del hardware (esto evidentemente no te va a costar viendo como flasheas vos habitualmente >)

Igual esta buena tu curiosidad, me siento a esperar que dicen los que saben de verdad.

Abrazo!

[Adrian Pardini]

On Mon, 2 Mar 2020 at 20:23, Carlos Pantelides
<carlos.p...@gmail.com> wrote:

> O quizás más sencillo, ¿se podría desde mismo linux asignarle a un proceso y a una interrupción un core y viceversa de modo exclusivo?

Hola Carlos,

yo arrancaría usando el parámetro de boot isolcpus para reservar un
core/cpu y luego correr su proceso con taskset en ese mismo.
También tocando /sys/devices/system/cpu/cpuN/online (hacele un echo 0
o 1 >) podés sacar un core del flujo normal del scheduler, los
procesos que tenía corriendo ahí se quedan pero no va a ejecutar nada
a no ser que se lo pases en forma explícita.

Saludos

--
Adrián Pardini

[Carlos Miguens]

Hola! ¿Por que no poner un pequeño micro externo con un RTOS y linux lo consulte para resolver el tiempo real?

Se ahorraría horas de ingeniería y posibles dolores de cabeza en futuros mantenimientos.

[Carlos Pantelides]

muy buenas respuestas, ahi comparto con mi amigo, la de Adrian ya la pruebo en un rato en mi PC, la de Alejandro veo de hacerme un rato y la de Carlos, bue, debe ser para ahorrarse unos pesitos

Muchas gracias

[Guillermo Enrique VIDES]

si existe una alternativa a la raspberry, se puede usar

---

De: embeb...@googlegroups.com <embeb...@googlegroups.com> en nombre de Carlos Pantelides <carlos.p...@gmail.com>
Enviado: martes, 3 de marzo de 2020 15:42
Para: Embebidos32 <embeb...@googlegroups.com>
Asunto: Re: [embeb32] Linux más freertos o baremetal

 

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/d8d85c87-16d5-4c41-8cd8-c858c08c08bd%40googlegroups.com.

[Carlos Pantelides]

 Adrián

Nop, echo 0 > /sys/devices/system/cpu/cpu3online funcionó ok, pero luego taskset no ve la cpu offline.

Búsquedas como "how to run a program in an offline cpu linux" no me traen nada útil, parece que habría que arreglarse con la cpu affinity, un proceso en una cpu, todos los procesos restantes en las cpu restantes. Pero yo soy bastante ignorante, no sé si realmente mejoraría la situación o si es overkill.

Así que nos iríamos quedando con aprender a manipular bien cpu affinity o como dice Carlos agregar un microcontrolador extra que debe ser lo más sencillo y modular.

[Hernan]

Hola Carlos,   me engancho y también tiro estas ideas, quizá descolgado (rápido):

Pruebas/Sugerencias:

1.   Desconociendo los requerimientos de "tiempo real" que tiene la solución,  probaron correr  por ej. Micrium uc/OS III sobre linux ?? 

   tienen que modificar el rtprio,  en la pagina de Micrium (ahora con licencia Open Source)  van a encontrar las notas técnicas y el port POSIX para compilar el Kernel/Scheduler y correrlo bajo Linux  (lo probe con éxito sobre un Ubuntu 14.04).

2.  La descripción que das, reservar un core, etc.  me recuerda a los diseños con FPGA de Xilinx,  donde separas los cores y armas el hardware a tu gusto,

     tuve una aplicación sobre la MiniZed,   con dos cores ARM,  en uno corríamos Linux, en el otro FreeRTOS, la comunicación entre los dos mediante shared physical memory.

Exitos!

Hernan

[Pedro Martos]

Hola,

No se si es posible hacerlo en una RPi porque necesitarias configurar el bootloader para poder hacerlo y no se si hay suficiente documentacion publica disponible.

Xilinx tiene FPGAs con dos procesadores Cortex A9 y tiene notas de aplicacion para correr linux + baremetal y linux + freertos, por ahi te son utiles:

Linux en un procesador y bare metal en el otro

https://www.xilinx.com/support/documentation/application_notes/xapp1078-amp-linux-bare-metal.pdf  

Linux en un procesador y freertos en el otro

https://www.xilinx.com/support/documentation/sw_manuals/petalinux2013_04/ug978-petalinux-zynq-amp.pdf  

cordialmente,

Pedro Ignacio Martos

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/6a1f3fe0-5192-4e41-acac-0193aa197e18%40googlegroups.com.

--

cordiales saludos,

Pedro Ignacio Martos

pma...@fi.uba.ar / pima...@gmail.com

http://web.fi.uba.ar/~pmartos

[Carlos Miguens]

Hola! independientemente si la implementación es usando un core del RPi o un mcu externo ¿Como realizarían la comunicación entre ambos para que el tiempo real del RTOS no se pierda en los tiempos que maneja el scheduler de Linux? ¿Shared memory / alguna otra tecnica?

Otra solución tambien podria ser utilizar eCos o RealtimePi ¿Fueron analizadas estas opciones? ¿que opinion les merece?

Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/MT-0bDp4Enk/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/CAM1aq_-zpap4%3DCh3wEmAg9cRNO-ONc_1PQ7YcVtu4mobvVRMyQ%40mail.gmail.com.

[Franco Bucafusco]

Pablo Ridolfi hizo su trabajo de maestria con relacion a eso.

espero les sirva.

sds

--------------------------------------------------------- Franco Bucafusco ---------------------------------------------------------

https://groups.google.com/d/msgid/embebidos32/CAJCn5sQaCSgkubRogmbhzqhkK%3DEbdxNXYXVnfOYy-v9M4Qxsuw%40mail.gmail.com

.

[Sebastian Wetzel]

Hola carlos, fijate si esto te sirve, la idea seria darle a un proceso la maxima prioridad, otorgarle un core en especifico y desactivar las interrupciones (si no me equivoco) que es lo que se muestra en post.
http://www.hydrogen18.com/blog/howto-give-a-single-process-its-own-cpu-core-in-linux.html

[Carlos Pantelides]

Bueno, esto es muy jugoso, tengo que convencer a mi amigo que se subscriba y manifieste.

Mientras, por mi puedo decir:

Carlos Miguens: si no entendí mal el problema origina, la tarea real time es samplear una señal y producir unos valores estadísticos para consumir desde el proceso principal, entiendo que la frecuencia de cambio de estos valores es baja, espero haber sido claro

Pablo y Hernán, con respecto a lo de xilinx, la lectura del libro de mpsoc zynq es lo que me inspiró en darle esa idea, en ese soc hay unos cores dedicados para realtime

Gracias y saludos

On Wed, Mar 4, 2020 at 4:39 PM Sebastian Wetzel <seba....@gmail.com> wrote:

Hola carlos, fijate si esto te sirve, la idea seria darle a un proceso la maxima prioridad, otorgarle un core en especifico y desactivar las interrupciones (si no me equivoco) que es lo que se muestra en post.
http://www.hydrogen18.com/blog/howto-give-a-single-process-its-own-cpu-core-in-linux.html

--

-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/MT-0bDp4Enk/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/d69d113a-a9a4-4429-b696-5a4313000de2%40googlegroups.com.

--

--
Carlos Pantelides

@pelucaKiller

https://github.com/cpantel
https://seguridad-agile.blogspot.com/