Raspberry Pi 3 supporta RTOS?

Sono nuovo nel mondo RTOS. Sto programmando di utilizzare alcuni RTOS su un Raspberry Pi 3 (potrebbe essere FreeRTOS). Qualcuno può suggerire quale RTOS sarebbe buono per i principianti?

Dato che non hanno ancora rilasciato un foglio dati sul BCM2837, è anche possibile caricare RTOS su un Raspberry Pi 3?

Questo aiuterà?

Anche se il progetto originale supporta solo Raspberry Pi 1, ho compilato con successo questo fork su un Raspberry Pi 2 e dice di supportare anche 3.

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

Fino ad ora ho testato il seguente RTOS senza successo per raspberry pi 3, che aiuterà qualcuno a non perdere tempo (ho perso 3 mesi): FreeRTOS, Xenomai, RTEMS, BitThunder, ChibiOS / RT

Per SO RISC non è un RTOS.

L'unico che sono stato in grado di eseguire su raspberry pi 3 fino ad ora è il kernel di Fuchsia OS (Magenta), ma è in una fase precedente e poco documentato

Un altro modo è quello di costruirti RTOS da solo, sì è possibile, usando ULTIBO CORE, e seguendo questi tutorial: - http://www.valvers.com/open-software/raspberry-pi/step01-bare-metal- programmazione-in-cpt1 / - https://www.youtube.com/watch?v=TCfpb8M0WeQ

ARM, la famiglia ISA utilizzata dai processori Broadcom su tutti gli attuali modelli Raspberry Pi, si basa su RISC , per il quale è stato scritto RISC OS . Penso che il sistema operativo RISC abbia prevalso sui dispositivi ARM per il loro primo decennio, poiché la stessa società tecnologica britannica (Acorn) aveva originariamente progettato sistemi operativi ARM e RISC. In effetti, ARM inizialmente stava per "macchina RISC Acorn" e parte del motivo per cui il Raspberry Pi è chiamato così com'è a causa di una tradizione nel Regno Unito di denominare i sistemi di computer come frutta o noci.

Il sistema operativo RISC non è un vero sistema operativo in tempo reale, tuttavia utilizza il multitasking cooperativo , il che significa che è possibile eseguire un processo che può rifiutarsi volontariamente di arrendersi a un altro processo. Quali conseguenze potrebbe avere non lo so, ma suppongo che:

• Puoi configurare le cose per consentirlo senza problemi, ma ciò può comportare restrizioni su ciò che il sistema operativo può realizzare (ad es. Rispetto alla rete).

• I cambi di contesto in modalità kernel si verificheranno solo a causa delle chiamate di sistema effettuate dal processo al fine di completarne gli obiettivi.

È abbastanza vicino alla funzionalità in tempo reale, a seconda di quanto "tempo reale" è necessario ottenere. Inoltre, ci sono alcune conferme che il SO RISC gira su Pi 3 .

Poiché la definizione di RTOS varia in base all'applicazione, in genere un computer che finge di essere qualcosa di molto più semplice, il sistema operativo RISC è un RTOS per le applicazioni medio-complesse e non è necessariamente per quelle molto complesse, sebbene un RTOS altamente complesso sembra una contraddizione in termini. L'esempio di Mahmoud Almostafa RABBAH non fa riferimento a nessun sistema operativo e esegue un programma a tasking singolo direttamente dal caricatore di avvio, che non è neanche un RTOS.

L'unico modo ragionevole per dare un senso a questo è di dividere la definizione RTOS in tre livelli:

• La bassa complessità sarebbe qualcosa come una lavatrice o un registratore di dati, e probabilmente stai meglio con un hardware più semplice, ad esempio Arduino o forse un MCU più semplice, o anche solo una logica sequenziale, in primo luogo. Consumerà meno energia e ci sarebbe molto meno di cui preoccuparsi: mai rendere le cose più complicate di quanto debbano essere.

• L'alta complessità sarebbe qualcosa di simile a un sistema multi-tasking completo, che non è un RTOS. Probabilmente sarebbe meglio eseguire la tua GUI su un dispositivo separato, se lo desideri. Un'elevata complessità potrebbe anche essere il monitoraggio di processi che chiamano altri processi e alcuni devono essere prioritari, ma ancora una volta si sta meglio con un qualche tipo di elaborazione parallela lì, o non riesce a rispondere in tempo reale.

• La media complessità sarebbe dove sono necessarie le interfacce che un normale sistema operativo può fornire, ad esempio USB, e forse un piccolo display di output, ma si desidera elaborare un flusso di dati e non essere interrotto da nulla. Sembra il livello di un'applicazione automobilistica.

  Per questo, potresti compilare qualcosa senza un sistema operativo, utilizzando un computer host per svilupparlo, oppure puoi utilizzare la versione del sistema operativo RISC che si avvia direttamente in BASIC e si sviluppa sul computer di destinazione, che di solito è più facile.

  Ciò eseguirà una singola attività che può essere abbastanza veloce da eseguire il polling per un numero di eventi, senza essere interrotto da altre cose. Gli interrupt di processo continuerebbero a meno che non siano disabilitati (abbastanza facili da fare) e quelli sono necessari per far funzionare il display / USB ecc. Altri interrupt di processo eseguono timer e IO che potresti non utilizzare.

Un altro vantaggio del sistema operativo RISC nelle applicazioni RTOS è che è possibile utilizzare solo i moduli richiesti, qualcosa che non ha senso nelle applicazioni GUI tradizionali ed era stato utilizzato ad esempio da STD / AdvantageSix [1] sebbene utilizzino il termine "sistemi integrati" invece di "RTOS". I vantaggi che ne derivano sono la progettazione semplificata, i requisiti di alimentazione più bassi, l'utilizzo della memoria inferiore e i tempi di avvio più rapidi (alcune interfacce dei dispositivi I / O richiedono il mini boot da soli e il sistema operativo deve partecipare a questo, sebbene i tempi siano solitamente troppo brevi per accorgersene ).

Spero che entrambi colmino alcune lacune nelle informazioni di cui sopra e chiarisca le lacune nelle mie conoscenze.

[1] http://www.advantagesix.co.uk/about_us.html (Altri esempi dalla memoria, non sono più disponibili online.)