¿El Raspberry Pi 3 es compatible con RTOS?

Soy nuevo en el mundo RTOS. Estoy planeando usar algunos RTOS en una Raspberry Pi 3 (puede ser FreeRTOS). ¿Alguien puede sugerir qué RTOS sería bueno para los principiantes?

Dado que aún no han publicado una hoja de datos en el BCM2837, ¿es posible cargar RTOS en una Raspberry Pi 3?

¿Esto ayudará?

Aunque el proyecto original solo es compatible con Raspberry Pi 1, he compilado con éxito esta bifurcación en un Raspberry Pi 2, y dice que también es compatible con 3.

https://github.com/Forty-Tw0/RaspberryPi-FreeRTOS

Hasta ahora probé el siguiente RTOS sin éxito para raspberry pi 3, que ayudará a alguien a no perder tiempo (no tenía 3 meses): FreeRTOS, Xenomai, RTEMS, BitThunder, ChibiOS / RT

Para RISC OS no es un RTOS.

El único que pude ejecutar en raspberry pi 3 hasta ahora es el kernel de Fuchsia OS (Magenta), pero está en una etapa anterior y poco documentado

Otra forma es construir su RTOS por sí mismo, sí, es posible, utilizando ULTIBO CORE y siguiendo esos tutoriales: - http://www.valvers.com/open-software/raspberry-pi/step01-bare-metal- programación-en-cpt1 / - https://www.youtube.com/watch?v=TCfpb8M0WeQ

ARM, la familia ISA utilizada por los procesadores Broadcom en todos los modelos actuales de Raspberry Pi, se basa en RISC , para lo cual está escrito RISC OS . Creo que el sistema operativo RISC predominaba en los dispositivos ARM durante su primera década, ya que la misma compañía tecnológica con sede en el Reino Unido (Acorn) diseñó originalmente los sistemas operativos ARM y RISC. De hecho, ARM inicialmente significaba "máquina Acorn RISC", y parte de la razón por la que se llama Raspberry Pi es lo que es debido a la tradición en el Reino Unido de nombrar sistemas informáticos después de frutas o nueces.

RISC OS no es un verdadero sistema operativo en tiempo real, sin embargo, utiliza tareas múltiples cooperativas , lo que significa que puede ejecutar un proceso que puede negarse voluntariamente a entregarse a otro proceso. No sé qué consecuencias puede tener esto, pero supongo que:

• Puede configurar las cosas para permitir esto sin problemas, pero puede implicar restricciones sobre lo que el sistema operativo puede lograr (por ejemplo, con respecto a las redes).

• Los cambios de contexto al modo kernel solo ocurrirán debido a las llamadas al sistema realizadas por el proceso para completar sus objetivos.

Eso está bastante cerca de la funcionalidad en tiempo real, dependiendo de qué tan "en tiempo real" necesite obtener. Además, hay alguna confirmación de que RISC OS se ejecuta en Pi 3 .

Dado que la definición de un RTOS varía en la aplicación, generalmente una computadora que finge ser algo mucho más simple, RISC OS es un RTOS para las aplicaciones de complejo medio, y no necesariamente para las de alto complejo, aunque es un RTOS altamente complejo Suena como una contradicción en los términos. El ejemplo de Mahmoud Almostafa RABBAH no se refiere a ningún sistema operativo y ejecuta un programa de tarea única directamente desde el cargador de arranque, que tampoco es un RTOS.

La única forma razonable de dar sentido a esto es dividir la definición RTOS en tres niveles:

• La baja complejidad sería algo así como una lavadora o un registrador de datos, y probablemente sea mejor con un hardware más simple, por ejemplo, Arduino o tal vez una MCU más simple, o incluso solo lógica secuencial, en primer lugar. Consumirá menos energía y habrá mucho menos de qué preocuparse: nunca haga las cosas más complicadas de lo que deben ser.

• La alta complejidad sería algo así como un sistema multitarea completo, que no es un RTOS. Probablemente sería mejor ejecutar su GUI en un dispositivo separado, si así lo desea. La alta complejidad también podría ser el monitoreo de procesos que llaman a otros procesos, y algunos deben ser priorizados, pero nuevamente es mejor con algún tipo de procesamiento paralelo allí, o falla la capacidad de responder en tiempo real.

• La complejidad media sería donde necesita las interfaces que puede proporcionar un sistema operativo normal, por ejemplo, USB, y tal vez una pequeña salida de pantalla, pero desea procesar un flujo de datos y no ser interrumpido por nada. Esto suena como el nivel de una aplicación automotriz.

  Para eso, podría compilar algo sin un sistema operativo, utilizando una máquina host para desarrollarlo, o podría utilizar la versión del sistema operativo RISC que arranca directamente en BASIC y se desarrolla en la máquina de destino, que generalmente es más fácil.

  Eso ejecutará una sola tarea que puede ser lo suficientemente rápida como para sondear una serie de eventos, sin ser interrumpida por otras cosas. Las interrupciones de hardware seguirían ejecutándose a menos que estén deshabilitadas (bastante fácil de hacer), y son necesarias para que la pantalla / USB, etc. Otras interrupciones de hardware ejecutan temporizadores e IO que quizás no esté utilizando.

Otra ventaja del sistema operativo RISC en las aplicaciones RTOS es que solo puede usar los módulos que necesita, algo que no tiene sentido en las aplicaciones GUI tradicionales, y que STD / AdvantageSix [1] había usado, por ejemplo, aunque usan el término "sistemas integrados" en lugar de "RTOS". Las ventajas que esto brinda son un diseño simplificado, menores requisitos de energía, menor uso de memoria y tiempos de arranque más rápidos (algunas interfaces de dispositivos de E / S requieren un mini arranque, y el sistema operativo tiene que participar en esto, aunque las escalas de tiempo generalmente son demasiado cortas para darse cuenta )

Espero que ambos llenen algunos vacíos en la información anterior y aclaren los vacíos en mi propio conocimiento.

[1] http://www.advantagesix.co.uk/about_us.html (Otros ejemplos de memoria ya no están disponibles en línea).