Ich bin Entwickler von Steuergeräten für Schaltnetzteile, die ein oder mehrere PWM-Signale mit einer Frequenz von etwa 100 kHz erzeugen, analoge Signale messen, über USART kommunizieren, relativ einfache Berechnungen durchführen müssen und so weiter. Es ist auch wichtig, schnell zu starten und sehr schnell auf einige Ereignisse wie externe Interrupts zu reagieren (oft innerhalb eines Bruchteils von Mikrosekunden).
Jetzt verwende ich Atmel Studio mit GNU C Compiler.
Ich möchte von 8-Bit-AVRs zu ARMs wechseln. Die Hauptgründe sind (hoffentlich): schnellere, flexiblere, leistungsfähigere Berechnungen, besserer Community-Support.
Ich möchte wirklich eine kurze Lernkurve und einen schnellen Entwicklungszyklus.
Ich habe mich für ARM Cortex-M0- und M3-Prozessoren entschieden.
Kann ich das Betriebssystem auf ARM verwenden?
Die Gründe, warum ich denke, dass es in meinem Fall nützlich sein könnte - schnellere Lernkurve und Entwicklungszeit. Aber ich habe einige Zweifel, dass ich in der Lage sein werde, die Anwendung innerhalb einiger Millisekunden nach dem Anlegen der Versorgungsspannung auszuführen, und dass ich in der Lage sein werde, mit ARM-Peripheriegeräten (wie Timern) zu interagieren.
Brauche ich also in meinem Fall ein Betriebssystem?
Ein Universalbetriebssystem wie Linux unterscheidet sich von einem Echtzeitbetriebssystem (RTOS) wie FreeRTOS und ARMs eigenem RTX. Sie können nach weiteren Informationen zu den Unterschieden suchen.
Aus der Beschreibung Ihrer Anwendung würde ich sagen, dass Sie sicherlich kein Allzweck-Betriebssystem benötigen und wahrscheinlich auch nicht wollen. Ein RTOS könnte verwendet werden, ist aber wahrscheinlich nicht notwendig.
Ich glaube, die ARM Cortex M0- und M3-Mikrocontroller haben keine Memory Management Unit (MMU), so dass es schwierig wird, ein Allzweck-Betriebssystem darauf auszuführen. Ein RTOS benötigt keine MMU.
Wenn Sie bereits mit der AVR-Programmierung, aber nicht mit der RTOS-Programmierung vertraut sind, wird die Verwendung eines RTOS in Ihrem neuen ARM-Projekt Ihre Lernkurve wahrscheinlich eher erhöhen als verringern .
Ein RTOS benötigt nicht viel Zeit zum Hochfahren wie ein Allzweck-Betriebssystem. Eine RTOS-Anwendung kann innerhalb von Millisekunden betriebsbereit sein.
Ein RTOS sollte Ihnen nicht im Weg stehen, auf die Mikrocontroller-Peripherie wie Timer zuzugreifen.
Du stellst zwei sehr unterschiedliche Fragen.
Kann ich das Betriebssystem auf ARM verwenden?
Natürlich, aber es wird wahrscheinlich eher ein RTOS wie FreeRTOS sein als ein Desktop-Betriebssystem wie Linux.
Brauche ich also in meinem Fall ein Betriebssystem?
Genau genommen: natürlich nicht. Jede Anwendung kann eigenständig geschrieben werden, ohne OS oder RTOS.
Aber die Frage, die Sie hätten stellen sollen, ist
werde ich von der Verwendung eines RTOS profitieren.
Das ist schwieriger zu beantworten. Die Vorteile eines RTOS sind Multithreading und die (zusätzlichen) Bibliotheken, einschließlich Hardware-Abstraktion. Der Nachteil ist, dass es Zeit braucht, um zu lernen, wie man diese Einrichtungen benutzt.
Mein Bauchgefühl ist, dass Ihnen die Verwendung eines RTOS für die von Ihnen beschriebene Anwendung nicht viel helfen wird, sodass das Lernen Sie mehr kosten wird, als es Sie spart. Aber ein RTOS zu kennen, wird wahrscheinlich für ein zukünftiges Projekt nützlich sein.
Ich denke, es kommt darauf an, was du genau machst. Wenn das Steuerungssystem einfacher ist als normalerweise ein RTOS, fügt es nur die Belastung hinzu, anstatt sie zu verringern.
Ein Grund, warum Sie ein RTOS benötigen, ist, wenn in Ihrer MCU mehr als eine Sache vor sich geht.
Ich habe ein ziemlich kompliziertes AVR-Projekt, das ein RTOS auf einem erforderte ATtiny85: einen Lichtdimmer, der über Glasfaser gesteuert wird. Die MCU muss zwei Dinge gleichzeitig tun: das AC-Phasenerfassungssignal beobachten und zeitlich festlegen und das TRIAC-Steuersignal zu einem geeigneten Zeitpunkt ausgeben, und einen seriellen Software-Port mit 9600 Baud für die optische Schnittstelle. Ich muss beide mit Timer-basiertem Interrupt-gesteuertem nicht blockierendem Code programmieren.
Paul A. Clayton