Étant donné que la définition d'un RTOS varie selon l'application, généralement un ordinateur prétendant être quelque chose de beaucoup plus simple, RISC OS est un RTOS pour les applications moyennement complexes, et pas nécessairement pour les applications très complexes, bien qu'un RTOS très complexe sonne comme une contradiction en termes. L'exemple de Mahmoud Almostafa RABBAH ne fait référence à aucun système d'exploitation et à l'exécution d'un programme à tâche unique directement à partir du chargeur de démarrage, qui n'est pas non plus un RTOS.
La seule façon raisonnable de comprendre cela est de diviser la définition RTOS en trois niveaux:
Une faible complexité serait quelque chose comme une machine à laver ou un enregistreur de données, et vous êtes probablement mieux avec un matériel plus simple, par exemple Arduino ou peut-être un MCU plus simple, ou même simplement une logique séquentielle, en premier lieu. Cela consommera moins d'énergie et il y aurait beaucoup moins à s'inquiéter: ne jamais rendre les choses plus compliquées qu'elles ne doivent l'être.
Une grande complexité serait quelque chose comme un système multitâche complet, ce qui n'est pas le cas d'un RTOS. Il serait probablement préférable d'exécuter votre interface graphique sur un appareil séparé, si vous le souhaitez. Une complexité élevée pourrait également être la surveillance de processus qui appellent d'autres processus, et certains doivent être classés par ordre de priorité, mais là encore, il vaut mieux utiliser un type de traitement parallèle, sinon la capacité de réponse en temps réel échoue.
La complexité moyenne serait là où vous avez besoin des interfaces qu'un système d'exploitation normal peut fournir, par exemple USB, et peut-être une petite sortie d'affichage, mais vous voulez traiter un flux de données et ne pas être interrompu par quoi que ce soit. Cela ressemble au niveau d'une application automobile.
Pour cela, vous pouvez compiler quelque chose sans OS, en utilisant une machine hôte pour le développer, ou vous pouvez utiliser la version de RISC OS qui démarre directement dans BASIC et se développe sur la machine cible, ce qui est généralement plus facile.
Cela exécutera une seule tâche qui peut être assez rapide pour interroger un certain nombre d'événements, sans être interrompue par d'autres choses. Les interruptions matérielles continueraient de fonctionner à moins qu'elles ne soient désactivées (assez faciles à faire), et elles sont nécessaires pour faire fonctionner l'affichage / USB, etc. D'autres interruptions matérielles exécutent des minuteurs et des E / S que vous n'utilisez peut-être pas.
Un autre avantage de RISC OS dans les applications RTOS est que vous ne pouvez utiliser que les modules dont vous avez besoin, ce qui n'a aucun sens dans les applications GUI traditionnelles, et avait été utilisé par exemple par STD / AdvantageSix [1] bien qu'ils utilisent le terme "systèmes embarqués" au lieu de "RTOS". Les avantages que cela apporte sont une conception simplifiée, des besoins en énergie réduits, une utilisation de la mémoire réduite et des temps de démarrage plus rapides (certaines interfaces de périphériques d'E / S nécessitent un mini-démarrage elles-mêmes, et le système d'exploitation doit y participer, bien que les délais soient généralement trop courts pour être remarqués. ).
J'espère que les deux remplissent certaines lacunes dans les informations ci-dessus et clarifient les lacunes de ma propre connaissance.
[1] http://www.advantagesix.co.uk/about_us.html
(les autres exemples de la mémoire ne sont plus disponibles en ligne.)