Sollte ich MBED von ARM oder eine native Plattform von Mikrocontroller-Anbietern verwenden? [geschlossen]

Es hängt davon ab, ob.

• Möchten Sie eine einfache Portierbarkeit zwischen ARM-Mikrocontrollern verschiedener Produktfamilien oder sogar Hersteller? Sie möchten IoT-Anwendungen entwickeln und wünschen sich eine einfache Internetanbindung? Möchten Sie eine große Auswahl an tragbaren, einfach zu verwendenden Bibliotheken?
  Verwenden Sie MBed.

• Verachten Sie es, das Rad neu erfinden zu müssen, möchten aber nicht den Overhead von mbed? Entwickeln Sie nicht gerne Code mit einer Web-App? Der Wechsel zu einem anderen Hersteller ist für Sie überflüssig, aber Portabilität innerhalb der gleichen Produktfamilie ist dennoch gefragt?
  Verwenden Sie die nativen Bibliotheken von ST (HAL oder SPL).

• Wollen Sie die volle Kontrolle über jedes noch so kleine Detail der Hard- und Software? Möchten Sie Ihren Code so optimieren, dass er in den billigsten Mikrocontroller passt, superschnell ausgeführt wird oder so wenig Strom wie möglich verbraucht? Hassen Sie es, sich mit zu abstrahierten, langsamen und unflexiblen Bibliotheken herumschlagen zu müssen und würden es lieber selbst machen?
  Programmieren Sie Bare Metal: Fügen Sie nur CMSIS und Registerdefinitionen hinzu, studieren Sie das Datenblatt sorgfältig und schreiben Sie Ihren eigenen Code.

Mbed bietet:

• Portabilität zwischen anderen Cortex-M-Plattformen.
• Eine große Auswahl an Netzwerkstapeln (LWiP, Nanostack) und Netzwerktreibern.
• Ein Echtzeitbetriebssystem.
• Umschließt den STM32 HAL immer noch, wenn Sie also etwas ganz Bestimmtes benötigen, stehen Ihnen diese Funktionen zur Verfügung (auf Kosten der Nicht-Portabilität).
• Kann weiterhin in der STM-Workbench entwickeln und debuggen - zusätzlich zur Online-IDE, uVision, VSCode usw.

Meiner persönlichen (aber voreingenommenen!) Meinung nach hat die Verwendung von Mbed also nur wenige Nachteile. Es ist jedoch viel breiter angelegt als das STM32 HAL, wobei viele Entscheidungen für Sie getroffen werden (Wahl des RTOS, Wahl der Netzwerkinfrastruktur). Wenn Sie damit unzufrieden sind, gerne Bare-Metal-Programmierung machen oder den Overhead von Mbed nicht wollen (obwohl es viele Möglichkeiten gibt , es kleiner zu machen); Sie könnten sich für STM32 HAL entscheiden.

Wenn Sie handelsübliche Bibliotheken wie stm hal oder mbed oder eine Kombination davon verwenden, lernen Sie so gut wie nichts über ARM. Auch wenn Sie die Bibliotheken umgehen, hat die meiste Arbeit nichts mit ARM zu tun, sondern hauptsächlich mit dem Chip.

Sie sollten alle Wege gehen, für die Sie Zeit haben. Die Lösungen auf hohem und sehr hohem Niveau erscheinen an der Oberfläche einfach, aber es kann eine Menge Arbeit/Schmerz damit verbunden sein. Sie verlassen sich hauptsächlich auf den Code anderer Leute, und wenn Sie sich in diesen Code vertiefen, stellen Sie möglicherweise fest, dass er Ihnen nicht gefällt. Beruflich ist es Ihrem Chef egal, ob Sie den Aufwand beenden und eine Bibliothek verwenden wollten, und dann die Bibliothek kaputt ging und das Produkt ausfiel und/oder ein gewisser Prozentsatz eines Laufs verworfen werden musste oder zusätzliche Kosten für die Neuprogrammierung anfielen. Was auch immer Sie für Ihre Entscheidungen verantwortlich sein müssen, wenn Sie eine Bibliothek verwenden möchten, müssen Sie sie besitzen, den Code untersuchen und sich mit ihren Lösungen wohlfühlen.

Ich finde, dass die Verwendung der Bibliothek viel schneller zu entwickeln ist (direkt aus dem Handbuch), einfacher ist und Sie der Code besitzen. Kleiner, leistungsstärker usw. Aber gleichzeitig gibt es etwas an diesem Teil, das Sie nicht wissen, hat der Chiphersteller keinen Timing-Fehler gefunden, weil er Bibliothekscode verwendet hat, der langsam lief und kein Problem aufdeckte, oder aufgebläht oder nicht Ihr Code kann ein Peripheriegerät mit einer anderen Taktfrequenz als Ihrer treffen, und wiederum eine Nuance des Chips, die noch nicht entdeckt wurde. Gibt es undokumentierte Register, die Sie nicht berührt haben usw. Sie können / sollten ihren Code von Zeit zu Zeit untersuchen, auch wenn Sie Ihr eigenes Ding tun, um zu versuchen, diese Probleme zu lösen, ein Problem mit dem Bibliothekscode, sei es, dass Sie Ihren Code über Teile hinweg wiederverwenden oder der Bibliothekslieferant, ist, dass, obwohl der Chip-Anbieter wahrscheinlich ein Modul im Chip wiederverwendet, es möglicherweise Änderungen gegeben hat,

Wenn Sie hoffen, ein professioneller Entwickler zu werden, ist es in Ihrem besten Interesse, sich auf all diesen Ebenen wohl zu fühlen. Der Preis dieser Produkte oder sogar die Verwendung von Simulatoren, wo immer möglich, kostenlos bedeutet, dass es nur eine Frage Ihrer Zeit ist, kein Dollarbetrag. Versuchen Sie, das RTOS zu verwenden, falls vorhanden, das von den Chipherstellern SDK/BSP bereitgestellt wird, um etwas zu implementieren. Versuchen Sie, die SDK/BSP-Bibliotheken des Chipanbieters zu verwenden, um eine bibliotheksbasierte Bare-Metal-Lösung zu erstellen, und versuchen Sie, die Dokumentation für das Teil zu verwenden, um eine Bare-Metal-Lösung zu erstellen. Letzteres ist eines, bei dem Sie etwas über ARM lernen oder zumindest eher lernen.

Die Beherrschung der Tools ist hier ein wichtiger Faktor. Sie können in der Lage sein, eine funktionierende Binärdatei zu erstellen, auch wenn das Blinken einer LED etwas trivial ist, indem Sie Ihre eigene Ausnahme- / Vektortabelle, Ihren Bootstrap-Code, Ihre Anwendung und Ihr Linker-Skript verwenden. Die Toolchains wie GNU sind sofort einsatzbereit und zielen auf die Linux-/Betriebssystem-basierte Entwicklung oder vielleicht eine bestimmte Bibliothek/SDK ab. Aber gleichzeitig nimmt ein Compiler nur High-Level-Code und gibt Assembly aus, ein Assembler übernimmt Assembly und gibt ein Objekt aus und ein Linker verknüpft Objekte. Je tiefer die Toolchain durchgeht, desto spezifischer wird sie für die Toolchain. Ein gnu ld-Linker-Skript kann völlig anders funktionieren als einige andere Compiler-Marken. Der Linker im Allgemeinen für diese Angelegenheit. Auch hier sollten Sie professionell versuchen, etwas anderes als GNU zu verwenden, versuchen Sie es mit llvm/clang, obwohl das etwas zusammenhängt,

Wenn Sie nur wissen, wie man eine vorgefertigte Ide/Umgebung nimmt und einige Bibliotheken aufruft oder Apps für ein bestimmtes RTOS schreibt, während Sie immer noch Ihren Lebensunterhalt verdienen können, sind Ihre Möglichkeiten eindeutig begrenzt. In der Zeit, die Sie brauchen, um eine neue Staffel einer Serie zu sehen, könnten Sie diese in der Ecke des Bildschirms oder auf einem nahe gelegenen Fernseher spielen und parallel dazu mindestens eine neue Sache gelernt haben, die Ihnen beruflich zugute kommt ...

Obwohl ARM die Prozessorwelt eindeutig dominiert, gibt es viele andere noch aktive Architekturen, die es wert sind, erkundet zu werden. Der 8051 wird in absehbarer Zeit nicht sterben, Sie haben mindestens einen, wenn nicht mehrere in dem Gerät, auf dem Sie dies lesen. Der z80 ist zwar nicht so beliebt, wird aber immer noch als 8051-Alternative verwendet. Es gibt natürlich andere beliebte MCUs, die nicht in etwas anderem vergraben sind, msp430, pic, avr (Ardino verwendet diese) und eine Reihe anderer, die immer noch sehr weit verbreitet sind, obwohl sie von Arm-Lösungen übergangen wurden. Viele davon haben Simulatoren oder offene Kerne, die Sie kostenlos verwenden können, um die Architekturprobleme zu lernen, die zum Booten usw. erforderlich sind, bevor Sie sich mit den nicht architekturspezifischen Peripheriedetails befassen. Ebenso haben einige von diesen ähnlich preiswerte Hobby-/Evaluierungsboards. Holen Sie sich noch besser ein paar Proben, ein Breakout Board,