Eingebettete Software ohne Hardware schreiben

Bedenken Sie, dass das Hardware-Team 2 Monate braucht, um Hardware zu entwickeln, aber zu diesem Zeitpunkt muss ich die Software fertig haben.

Meine Frage ist, wie kann ich die Software schreiben und testen, ohne die Hardware zu haben?

Gibt es Standards, die befolgt werden müssen? Wie machst du das?

Je nachdem, wie komplex die Hardware wird, könnten Sie einen Simulator ausprobieren. Das ist durchaus machbar, wenn es nur ein Mikrocontroller mit einfacher Peripherie ist. Mehr als das, und Sie haben Pech auf dieser Route.
Versuchen Sie, Entwicklungsplatinen für das Mikro und andere Peripheriegeräte zu finden, die Sie verwenden, und versuchen Sie, sie alle so anzuschließen, dass sie dem Design Ihres Hardwareteams am nächsten kommen. Es wird groß und hässlich, aber Sie sollten in der Lage sein, ein System zusammenzustellen, das der Realität nahe genug kommt - zumindest soweit Ihre Firmware das beurteilen kann ...
Wenn Sie die Hardware nicht richtig simulieren können, haben Sie im schlimmsten Fall eine Möglichkeit, sie zu deaktivieren. Erst vor ein paar Wochen wollte ich die Netzwerkkommunikation mit einem anderen Programm testen, nur um festzustellen, dass dies möglich war, exit()weil es versuchte, fest codierte Adressen in /dev/mem zu mmappingen.
Tatsächlich ist es in vielen Fällen vorzuziehen, einen Simulator für die Entwicklung eingebetteter Software zu verwenden – viel einfacher zu debuggen. Das Problem ist natürlich, dass Sie einen anständigen Simulator benötigen. Manchmal gibt es eine generische, die angepasst werden kann, manchmal kann ein cleverer Praktikant in einem koffeinbefeuerten Programmierrausch eine schreiben.

Antworten (6)

Es kommt vor, dass in den Anfangsstadien der Firmware-Entwicklung keine Hardware vorhanden ist. Gängige Strategien, um damit umzugehen, sind:

  1. Verbringen Sie Zeit damit, das System sorgfältig zu entwerfen, bevor Sie Code schreiben. Natürlich sollten Sie das trotzdem tun, aber in diesem Fall ist es noch wichtiger als sonst. Es ist viel einfacher, eine gut durchdachte Software zu debuggen als ein auf Nudeln basierendes Durcheinander.

  2. Modularisieren Sie alles richtig und minimieren Sie die Schnittstellen zwischen den Modulen. Dies hilft, Fehler in einzelnen Modulen einzudämmen und ermöglicht ein einfacheres Testen einzelner Module.

  3. Schreiben Sie Code von unten nach oben, hardwareberührende Treiber beginnen zuerst, Anwendungslogik auf hoher Ebene zuletzt. Architekturbedingte Unannehmlichkeiten lassen sich so frühzeitig erkennen. Scheuen Sie sich nicht, die Architektur zu ändern, wenn Hardware-Realitäten ans Licht kommen, aber stellen Sie sicher, dass die gesamte Dokumentation entsprechend aktualisiert wird.

  4. Simulieren. Die meisten Mikrocontroller-Unternehmen bieten Software-Simulatoren ihrer Mikrocontroller an. Diese können nur so weit gehen, aber dennoch sehr nützlich sein. Das Simulieren der Eingänge und das Messen der Ausgänge der Hardware kann schwierig sein, aber die Überprüfung der Logik auf höherer Ebene auf diese Weise sollte nicht zu schwierig sein.

    Hier hilft wieder der modulare Aufbau. Wenn Sie einige Hardwareinteraktionen auf niedriger Ebene nicht vernünftig simulieren können, verwenden Sie eine andere Version des Moduls, die diese Hardware berührt, aber ihre eigenen simulierten Aktionen an die oberen Ebenen weitergibt. Die oberen Ebenen werden nicht wissen, dass dies geschieht. Sie werden auf diese Weise nicht das Low-Level-Modul überprüfen, sondern fast alles andere.

Kurz gesagt, verwenden Sie gute Software-Design-Praktiken, was Sie natürlich sowieso tun sollten.

Möchte hinzufügen: Holen Sie sich so schnell wie möglich Entwicklungsboards (ja, mehrere, weil Sie wahrscheinlich mindestens eines töten werden ...) und bringen Sie die Low-Level-Treiber an Ort und Stelle. Testen Sie so viel von Ihrem Code wie möglich. Ja, Sie können den hardwareberührenden Code vereinen. Nein, Sie können die Hardware nicht vollständig simulieren, aber Sie können 90% der Funktionalität schon vor dem ersten Flashen richtig machen. Ich habe all dies bei einem kürzlichen Projekt durchgeführt, und wir hatten 99% Funktionalität vorhanden und funktionierten, als die echte Hardware eintraf. Es war großartig.

Ohne einen Einblick in das, was Sie entwickeln oder auf welcher Familie von Mikrocontrollern Ihre Hardware letztendlich basieren wird, verfügen die meisten Familien von Mikrocontrollern über kostengünstige Entwicklungssysteme, die über eine Reihe gängiger Peripheriegeräte verfügen, mit denen Sie dies möglicherweise tun können Simulieren Sie zumindest einen Teil Ihrer eventuellen Zielhardware.

Einverstanden. Ich würde es stärker formulieren. In einer solchen Situation, in der die Software gleichzeitig mit der Hardware fertiggestellt werden muss, würde ich nur einen Mikrocontroller verwenden, der über ein geeignetes Entwicklungs- oder Evaluierungsboard verfügt.
Selbst wenn Sie Einblick in die Entwicklung des OP hatten, stehen für die meisten Mikrocontroller-Familien immer noch Simulatoren zur Verfügung.
Ich verwende beide Methoden. Allerdings behalte ich zusätzlich die benötigte Testausrüstung für die Produktionslinie im Auge. Sie können sich mit den Produktionsingenieuren zusammensetzen und Hardware entwerfen, um Ihre Treiber zu testen, die dann Teil der Produktionstests sein können. Wenn Sie Glück haben, können sie sogar Hardware für ein Entwicklungsboard / einen Prototyp bauen, damit sie dem Prozess auch einen Schritt voraus sind. Es hängt alles davon ab, wie Sie die Bitte um Hilfe stellen ...
Dies ist die beste Antwort auf diese Frage, da ich immer ein Entwicklungsboard habe, um zuerst die Kernfunktionen zu programmieren, bevor ich es auf der Platine probiere.

Je nachdem, wie hardwareabhängig die Anwendung sein wird, können Sie das Projekt einfach auf einem Standard-PC (Windows, Linux ...) implementieren. Die meisten peripheren Zugriffe sollten sowieso abstrahiert werden, daher ist es keine große Sache, einige Dummy-Funktionen zu implementieren, die später ersetzt werden. Wenn es nicht möglich ist, ein Verhalten zu simulieren, könnten Sie zumindest ein Mockup des Systems (API ...) erstellen, sodass die tatsächliche Implementierung viel schneller und klarer ablaufen wird, sobald die Hardware fertig ist.

Natürlich gibt es viele Dinge, die nicht simuliert werden können, wie Echtzeitverhalten oder komplexe Hardwaretreiber. Andererseits kann ein Interrupt-gesteuerter ADC einfach simuliert werden, indem ein Thread verwendet wird, der Werte aus einer Datei oder einem Netzwerkport liest.

All dies hängt natürlich stark von verschiedenen Faktoren ab:

  • Können Sie die gleiche/ähnliche Toolchain auf Controller und PC verwenden (z. B. gcc)?
  • Wie hardwareabhängig ist das System?
  • Wie erfahren sind Sie in der PC-Programmierung?

Ich für meinen Teil entwerfe so ziemlich jedes Firmware-Modul zuerst auf einem PC.

Hier gilt das gleiche. Einige Unterschiede zwischen Compilern (Intrinsik, spezielle Schlüsselwörter, Closed-Source-Betriebssystem und Netzwerkstack, die nicht ganz mit BSD kompatibel sind) und Fehlern (mit C++), die eine starke Verwendung von dateispezifischen voreingeschlossenen Dateien und Präprozessoren erzwingen, aber der Code selbst kann zwischen DSP fast identisch sein und PC. Für die PC-Version kann ich eine starke und schwere Laufzeitfehlerprüfung (CodeGuard) verwenden, und seine Debugging-Funktionen können auf eingebetteten Plattformen nicht erreicht werden. Ein zusätzlicher Bonus ist, dass ich einige zusätzliche virtuelle Geräte für Netzwerk- und Lasttests haben kann.
Mit der Verfügbarkeit von Raspberry Pi und BeagleBone könnte Ihre Entwicklungsumgebung genauso gut Ihre Laufzeitumgebung sein – keine Probleme mit der Toolchain usw. Außerdem können Sie valgrind/helgrind, gdb usw. verwenden.

Versuchen Sie, einen Simulator für Ihren Chip zu bekommen. Sie sollten alle erwarteten Eingaben und auch einige unerwartete simulieren. Modularisieren/abstrahieren Sie so weit wie möglich und schreiben Sie Unit-Tests. Wenn Sie können, können diese Tests Teil Ihres eigentlichen Codes werden und sich in ein Feature verwandeln (Board-Selbsttest).

Wenn Sie keinen Simulator bekommen können, abstrahieren Sie so viel wie möglich durch eine HAL (Hardware Abstraction Layer). Alle Fahrer stehen dahinter. Versuchen Sie, alle plattformspezifischen Assemblys hinter einem C-Funktionsaufruf zu abstrahieren, und stellen Sie sich diese auch als Treiber vor. Schreiben Sie den Rest als portablen C/C++-Code und erstellen Sie eine dünne HAL für x86 und führen Sie sie mit allen Testfällen auf Ihrem Computer aus.

Auf diese Weise müssen Sie, wenn Sie die Hardware erhalten, nur die HAL debuggen. Je dünner es ist, desto schneller werden Sie es debuggen und alles funktioniert. Denken Sie daran, dass Sie, wenn Sie plattformspezifische Assemblierung für schnellere Operationen verwenden, SEHR VIEL Bit -genaue Tests erhalten möchten .

Bit-Genauigkeit ist besonders wichtig, wenn Festkomma-DSP verwendet wird.
Es kann auf einen bestimmten Fall zutreffen oder nicht, aber im Allgemeinen hat Bit-Genauigkeit ihren Preis. QEMU hat sich kürzlich (vor 2 Jahren) entschieden, eine bitgenaue FPU zu implementieren, und raten Sie mal, was mit der Leistung passiert ist ?
Bit-Genauigkeit ist bei der Verwendung einer FPU nicht so wichtig. Es ist jedoch äußerst wichtig, wenn Festkomma verwendet wird. Vor allem, weil Software-Festkomma überall zusätzliche Prüfungen benötigt.
Was auf schlechte Codierungspraktiken zurückzuführen ist. Die Leute haben gelernt, Vorsichtsmaßnahmen zu treffen, wenn sie a == bVergleiche mit Floats verwenden, aber sie verwenden sie immer noch gedankenlos mit Festkommazahlen.
Während schlechte Codierungspraktiken ein ziemliches Problem darstellen, gibt es viele andere Probleme, insbesondere in Grenzfällen. Überläufe kommen einem schnell in den Sinn, ebenso Präzisionsverlust , Rundung , Sättigung und Breite vs. Bitverschiebung . Bei all dem ist es leicht, einen gewissen Genauigkeitsverlust in gängigen Testfällen zu ignorieren. Das Problem besteht darin, dass Ihre App kleinere Fälle erreicht und die Fehler von den gebrochenen zu den ganzzahligen Bits wechseln, was passiert, wenn der Bereich falsch berechnet wird. Sehen Sie sich einfach die Funktionsseite des Fixed-Point-Designers von MATLAB an, um auf einen Blick zu sehen, was sonst noch schiefgehen könnte.

Deine Frage ist etwas weit gefasst. Hardware (HW) kann eine vollständig kundenspezifische ASIC / FPGA-Entwicklung, Assembler-programmierte DSPs oder "nur" ein typisches eingebettetes System bedeuten, das auf handelsüblichen Mikroprozessoren / Mikrocontrollern / SoC usw. basiert (natürlich kann ein SoC auch einen DSP enthalten die Sie vielleicht programmieren möchten....). Bei hohen Verkaufsmengen ist es nicht ungewöhnlich, es zu einem ASIC zu machen.

Aber für ein 2-monatiges Projekt erwarte ich, dass es auf einem Mikrocontroller basiert:

In jedem Fall sollten Sie das Hardware-Team drängen, Ihnen einen Prototypen zu geben, mit dem Sie Ihren Code vor der absoluten Frist testen können - dies könnte nur aus einem generischen Entwicklungsboard bestehen, wie einige Leute bereits erwähnt haben, aber meiner Meinung nach ist es ihr eigenes Aufgabe, Ihnen das Richtige zur Verfügung zu stellen, und möglicherweise auch einige erforderliche/ähnliche Peripheriegeräte zum Testen.

Simulatoren sind bis zu einem gewissen Grad auch möglich, aber Sie müssen möglicherweise noch einige Sensoren / Daten aus der realen Welt charakterisieren, die Sie möglicherweise erhalten. Auch hier muss Ihnen das Hardware-Team zumindest behilflich sein.

Abgesehen davon kann das Softwaredesign bereits durchgeführt werden und alle High-Level-Module können (und sollten) ohne die echte Hardware implementiert und einheitengetestet werden. Idealerweise definieren Sie auch eine API zusammen mit dem Hardware-Team, und sie werden Ihnen die Funktionen auf der niedrigsten Ebene zur Verfügung stellen, sodass jede Änderung, die sie dort auf der Hardwareseite vornehmen (z. B. einfach neu definieren, welche Port-Pins sie verwenden), nicht immer der Fall ist sei dir gegenüber kritisch.

In allen Fällen ist die Kommunikation der Schlüssel.

Ja, Sie können Ihren Code für Ihr Zielboard entwickeln, bevor das Board hergestellt wird.

Wie ?

Zuerst müssen Sie das Hauptziel dieses Systems kennen. So können Sie den Controller entsprechend aus einer großen Verfügbarkeitsquelle wie Digikey, Mouser auswählen.

Und wählen Sie einen Simulator wie Proteus. Dadurch wird der genaue Prozessor/Controller simuliert, jetzt können Sie mit der Codierung beginnen. Aber Sie können nicht die Genauigkeit wie in der Hardware erwarten.

Warum ablehnen? Darf ich wissen, was an dieser Antwort falsch ist?
Eingebettete Software ohne Hardware schreiben
AntwortenHierDatenschutz-Bestimmungen1y, 0v