Wie bestimmen Sie, wie viel Flash/RAM Sie für einen Mikrocontroller benötigen?

Angenommen, Sie beginnen ein eingebettetes Projekt mit einigen bekannten Funktionen. Wenn Sie einen Mikrocontroller auswählen, wie wählen Sie aus, wie viel RAM Sie benötigen?

Verwenden Sie ein Entwicklerboard und codieren Sie zuerst Ihr Projekt und sehen Sie dann, wie viel Speicher Sie verwendet haben, und wählen Sie dann einen geeigneten Mikrocontroller aus, der zu diesem Speicher passt?

Wählen Sie einfach einen kräftigen Mikrocontroller für einen Prototypen aus und skalieren Sie ihn dann herunter, nachdem Sie ein funktionierendes Produkt haben?

Wählen Sie einfach etwas aus, von dem Sie sicher sind, dass es ausreicht, und wenn Ihnen der Speicherplatz ausgeht, rüsten Sie einfach auf eine höhere Speicherdichte auf, andernfalls behalten Sie einfach den vorhandenen Mikrocontroller?

Was gilt als gute Praxis?

Mir scheint, dass es aus informationstheoretischer Sicht möglich sein sollte, den RAM-Bedarf innerhalb einer Größenordnung (Dimentional Reasoning Style) aus der Aufgabenspezifikation abzuschätzen. Hmmm...
Wenn Sie Bibliotheken verwenden, können Sie deren Speicherbedarf recherchieren. Bei eigenem Code muss man mit Erfahrung vorgehen. Vergleichen Sie das neue Projekt mit den alten und bestimmen Sie, ob Sie erwarten, dass es größer oder kleiner wird.

Antworten (4)

Persönlich tendiere ich für Hobbyprojekte dazu, den leistungsstärksten Mikrocontroller der Familie mit dem richtigen Platzbedarf zu verwenden. Dann entwickle ich die Leiterplatte, schreibe etwas Code und produziere einen Prototyp.

Das hat den Vorteil, dass ich die kleine Anzahl von Mikrocontrollern ziemlich gut kenne, sodass ich schnell Prototypen erstellen kann, ohne ein ganzes Datenblatt lesen zu müssen. Ich habe auch Breakout-Boards und Code-Vorlagen dafür.

Wenn es funktioniert und ich mehr als eine Handvoll mache, kaufe ich den billigsten Mikrocontroller, der die richtigen Peripheriegeräte und genug Speicher für alles hat, was ich zuvor codiert habe. Dies kann ärgerlich sein, wenn sich interne Register ändern (passiert auf dem PIC) oder wenn einer der Mikrocontroller über zusätzliche Peripheriegeräte verfügt, die deaktiviert werden müssen, damit der Code funktioniert.

Für Produktionszwecke würde dies jedoch dazu führen, dass Sie eine beträchtliche Menge von jeder Einheit einsparen können.

Für meine persönlichen Projekte neige ich dazu, einen ähnlichen Ansatz zu verwenden. Die gleiche Methode schleicht sich auch bei mir ins Büro ein. Es ist nicht falsch, es funktioniert, aber gibt es bessere Möglichkeiten usw.. Schätzen Sie die Eingabe!
In einer "echten" Umgebung wird es definitiv bessere Möglichkeiten geben, warten wir auf andere Antworten!
Absativ. Entwickeln Sie in einer großen Sandbox und schneiden Sie sie später ab. Die Zeit, die Sie sparen, wird die zusätzlichen 4 $, die Sie pro Mikrocontroller für die Entwicklung ausgeben, mehr als decken. Dies funktioniert für mehr als nur Hobby-Sachen - und ist sogar noch wichtiger. Stellen Sie sich 12 Leute vor, die darauf warten, dass ein Wechsel zu einem größeren Controller anstelle von einem stattfindet!!

Natürlich kann es für einen einzelnen selbstgebauten Prototypen eine gute Empfehlung sein, mit dem leistungsstärksten aller kompatiblen Mikros zu beginnen und danach herunterzuskalieren.

Wenn Sie jedoch ein Angebot gewinnen möchten, müssen Sie Ihrem Kunden einen Preis nennen , bevor Sie das Geld haben, um etwas umzusetzen.

Daher empfiehlt es sich, eine Art Spezifikation aufzuschreiben, bevor Sie mit dem Programmieren beginnen. Sie wissen, was Sie tun möchten, und Sie sollten aufschreiben, wie Sie es tun werden.

Dieses „Wie“ beinhaltet auch das Nachdenken über ein Softwaredesign, die Beantwortung von Fragen wie:

  • Benötigen Sie ein Betriebssystem? Welcher? Welche Ressourcen braucht es?
  • Möchten Sie eine mehrschichtige Architektur haben? Dies erfordert Schnittstellen, die RAM verbrauchen können
  • Welche Bibliotheken sind bereits verfügbar und für Ihren Zweck nützlich/notwendig und wie viel Speicher benötigen sie (eine gute Bibliotheksdokumentation beantwortet dies anhand mindestens eines Referenzaufbaus)?
  • Welche Strukturen und Variablen müssen Sie für Ihre eigenen Treiber und Ihre Anwendung implementieren?

Wenn Sie all diese Werte zusammenfassen, erhalten Sie eine grobe Schätzung. Wie weit Sie darauf vertrauen können, hängt davon ab, wie detailliert Ihre Analyse ist, und es hängt von Ihrer Erfahrung ab :-)
Eine Marge von mindestens 30..50% Ihrer Schätzung hinzuzufügen, ist sicherlich eine gute Idee.

Wenn Ihr Produkt fertig ist und Sie ca. 80..90% RAM in Verwendung haben, können Sie ziemlich sicher sein, dass Ihre Auswahl richtig war - zumindest was den Arbeitsspeicher betrifft.

Betreff: "80..90% RAM belegt". Die Standardpraxis besteht darin, sicherzustellen, dass Sie sowohl CPU als auch Arbeitsspeicher nur mit maximal 50 % Auslastung verwenden, um zukünftige Upgrades und Fehlerkorrekturen berücksichtigen zu können.
@Dunk: Hängt vom Geschäft ab. In der Automobilindustrie werden 80 % aller Ressourcen (CPU, RAM, Flash) bei SOP allgemein akzeptiert. Bei billiger Unterhaltungselektronik beispielsweise können es sogar noch mehr sein: Wie wahrscheinlich ist ein Upgrade bei einem System mit einer Lebensdauer von nur 2-3 Jahren?
@Dunk: Ich könnte mich irren, aber es hört sich so an, als wären Sie an Software im Desktop-Stil mit dynamischem Speicher und all den damit verbundenen Unsicherheiten gewöhnt. Die überwiegende Mehrheit der eingebetteten Anwendungen weist alles statisch zu. Garantiert keine Speicherlecks. Dann können Sie genau 100% verwenden und für immer in Ordnung sein, solange Sie es nicht ändern. Das funktioniert natürlich nur, wenn Sie einen von Ihrem Arbeitsspeicher getrennten Stack haben oder wenn Sie jederzeit genau wissen, wie sich der Stack verhalten wird. Es ist eine gute Idee, etwas Platz dafür zu lassen, aber 10-20 % reichen locker für das, was ich getan habe.
Das größere Problem bei eingebetteter Software sind Rogue-Pointer, Pufferüberläufe, Division durch Null und ähnliches. Einige MCUs können Ausnahmen in der Hardware auslösen, ähnlich wie Interrupts, aber alles, was ich verwendet habe, wird fröhlich weitermachen, als wäre nie etwas passiert. Es wird eine Art Ergebnis geben, aber es ist wahrscheinlich nicht das, was Sie erwartet haben, und Sie müssen das überprüfen. Einige Dinge, wie arithmetischer Über-/Unterlauf, sind leicht zu überprüfen und sofort zu beheben; andere Dinge, wie Rogue-Pointer, können völlig unbemerkt bleiben, bis eine Funktion, die jahrelang funktioniert hat, explodiert.
Es ist die Herausforderung und Verantwortung der Entwickler sicherzustellen, dass NICHTS Unerwartetes passiert ;-) Normalerweise lassen 80% genügend Spielraum, um Bugfixes einzubringen, weil ein Fix die Codegröße nicht (so sehr) verändert. Wenn dies der Fall ist, war das Testen vor SOP nicht gut genug. Kosten- und Zeitdruck erhöhen das Risiko. Der Kostendruck erfordert aber auch, den Mikrocontroller-Preis so niedrig wie möglich zu halten. Ein Upgrade der Software ist eine andere Sache, die möglicherweise einen größeren Spielraum erfordert (z. B. ein neuer Codec für das Soundsystem).
OK, ich ziehe meinen 50 %-Kommentar zurück. Ich habe bei 5 verschiedenen Unternehmen an wahrscheinlich 50 Projekten und 20 "einzigartigen" Kunden gearbeitet und alle haben die 50%-Regel angewendet. Deshalb habe ich anscheinend fälschlicherweise angenommen, dass dies eine ziemlich übliche Praxis ist.
Ob Sie ein 80-%-Ziel oder ein 50-%-Ziel anstreben, hängt von Ihrem Kunden ab. Mit einer festen Spezifikation und nur Fehlerbehebungen sind 80 % in Ordnung. Unzuverlässige Spezifikationen, erwartetes Feature-Creep und ein ausreichend großer Spielraum, um dies zuzulassen, können dazu führen, dass Sie den Aufpreis für mehr Headroom zahlen. Einmal kauften wir doppelt so viele Mikrocontroller, wie wir brauchten, und wählten diejenigen aus, die genug übertakten würden, um uns die benötigte Leistung zu bieten, das war viel billiger als ein PCB-Redesign für einen leistungsstärkeren Chip.

Wenn es nur möglich wäre, Ihr eingebettetes System zuerst zu codieren und dann die Hardware zu bauen. Das würde das Leben aller erleichtern. Leider bedeutet das auch, dass Ihre Fristen aus dem Fenster sind. Typischerweise muss die Hardware entworfen werden, lange bevor die Software fertig ist, da Hardwareteile häufig lange Vorlaufzeiten haben.

Daher müssen Entwickler eingebetteter SW normalerweise den Speicher- und CPU-Bedarf ihres Programms abschätzen. Ihr erster Schritt sollte sein, die Hardware-Jungs davon zu überzeugen, Ihnen den leistungsstärksten Mikrocontroller/CPU mit dem größtmöglichen RAM zu geben. Das funktioniert selten, weil sie ihre eigenen Anforderungsziele haben, aber hin und wieder hat man Glück.

Wenn das nicht funktioniert, ist das nächste, was Sie tun würden, ein High-Level-Softwaredesign und zerlegen Sie die Module in Funktionalität. Sie würden dann Codezeilen für jede Funktion für jedes Modul im System schätzen. Sie können dann eine Formel verwenden, um Codezeilen in eine ungefähre Schätzung des Codespeichers umzuwandeln. Sie würden auch alle ungewöhnlichen Speicheranforderungen (wie große Arrays) untersuchen und eine Schätzung hinzufügen, um dies zu berücksichtigen. Fügen Sie dann einen Prozentsatz zu dieser Summe hinzu, um alles abzudecken, was Sie verpasst haben. Verdoppeln Sie diese dann, um die typische Auslastungsanforderung von 50 % zu erfüllen.

Ja, es braucht Zeit. Ja, es ist notwendig, durch alle Hürden zu springen, weil das Ändern der Hardware nach dem Bau wirklich schwierig ist.

Wo finden wir die Formel, um Codezeilen in Codespeicher umzuwandeln?
Das hängt davon ab, welche Sprache und welcher Compiler Sie verwenden. Wenn Sie Assembler verwenden, entspricht eine Zeile ungefähr einem Speicherwort (unabhängig von der Wortgröße Ihres Chips). Wenn Sie C verwenden, können es etwa 3-5 Wörter pro Zeile sein, und wenn Sie C++ oder etwas noch Komplexeres verwenden, können es immer noch viel mehr sein. Am besten kompilieren Sie ein paar Programme, die in dieser Sprache geschrieben sind, und vergleichen die Codezeilen mit dem Codespeicher, um einen Durchschnitt zu erhalten.

Im Allgemeinen stecken Hersteller von Mikrocontrollern eine Reihe von Speicher in ihre Geräte, die für typische Anwendungen geeignet sind. Wenn Sie also nur wenige I/O-Pins und einen SPI in einem Gerät mit geringem Platzbedarf benötigen, werden Sie wahrscheinlich nichts finden, das mit 500 kByte Flash und 64 kByte RAM geliefert wird. Bei größeren Geräten, die näher an SoC-Paketen liegen, ist selbst das kleinste mit ziemlicher Sicherheit groß genug, es sei denn, Sie planen ernsthafte Zahlenverarbeitung wie Bildverarbeitung.

In einem professionellen Umfeld ist der Schlüssel zur Auswahl des richtigen Mikrocontrollers die Verwendung historischer Daten. Sie haben eine Aufzeichnung der anderen Projekte, die Sie entwickelt haben, und wissen, welche Speicher- und anderen Siliziumressourcen erforderlich sind, um die einzelnen Funktionen zu implementieren. Sie wissen, was von dem Produkt erwartet wird, verfügen über eine gute Funktionsliste und können schnell und genau die Ressourcen berechnen, die der Mikrocontroller bereitstellen muss. Der Versuch, die Ressourcenanforderungen aus einer vorab erstellten Designspezifikation (die zu Beginn des Projekts entwickelt wird, wenn die wenigsten Informationen über das System verfügbar sind) zu erraten, ist in den besten Zeiten unzuverlässig und nur sehr erfahrene Ingenieure, die eine umfassende erstellt haben Datenbank mit historischen Daten im eigenen Kopf, werden mit dieser Methode jeden Erfolg haben.

Viele Unternehmen haben sowohl beim Software- als auch beim Elektronikdesign einen „agilen“ Ansatz gewählt, der den Aufbau einer „Bibliothek“ kleiner Feature-Boards (z. B. RS-485-Boards, ADC-Boards usw.) zusammen mit generischen Plattformboards umfasst, die die Mikrocontroller hosten , ähnlich wie bei der Verwendung eines Dev-Kits und Plug-Ins. Ein Produkt kann dann schnell (innerhalb von Stunden) als Prototyp erstellt werden, indem die für die Funktionen erforderlichen Boards ausgewählt und verbunden werden. Die Software ist ebenfalls aus Bibliotheksmodulen zusammengestellt und kann schnell portiert und getestet werden. Sobald die Größe des hardwarespezifischen Teils des Codes bekannt ist, reicht es normalerweise aus, den kleinsten Teil auszuwählen, der diesen enthält. Die Ausnahme ist die oben erwähnte, bei der die Funktionalität des Geräts Big Data oder sehr komplexe Algorithmen umfasst. Diese Methode liefert eine genaue,

(Ein weiterer Vorteil des agilen Ansatzes besteht darin, dass Software- und Elektronikentwicklung parallel durchgeführt werden können, wobei das Elektronikdesign eine Übung zur Integration des Satzes von Feature-Boards und zur gleichzeitigen Durchführung der relevanten EMV- und anderen schwierigen Aufgaben ist Anwendungssoftware wird auf den Prototypbaugruppen entwickelt. Einige Portierungen und Integrationen sind noch erforderlich, aber sie werden durchgeführt, wenn sowohl funktionierende Software als auch Elektronik verfügbar sind.)