Schreiben von eingebetteter Software ohne Hardware

Bedenken Sie, dass das Hardware-Team 2 Monate brauchen wird, um Hardware zu entwickeln, aber bis dahin muss ich die Software bereit 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?

In der Anfangsphase der Firmware-Entwicklung ist keine Hardware vorhanden. Übliche Strategien, um damit umzugehen, sind:

1. Nehmen Sie sich Zeit, um das System sorgfältig zu entwickeln, bevor Sie Code schreiben. Natürlich sollten Sie dies trotzdem tun, aber in diesem Fall ist es noch wichtiger als gewöhnlich. Es ist viel einfacher, gut durchdachte Software zu debuggen als ein auf Pasta basierendes Durcheinander.

2. Modularisieren Sie alles richtig und minimieren Sie die Schnittstellen zwischen den Modulen. Dies hilft dabei, Fehler in einzelnen Modulen einzudämmen und das Testen einzelner Module zu vereinfachen.

3. Schreiben Sie den Code von unten nach oben, die Hardware berührenden Treiber stehen an erster Stelle, die Anwendungslogik auf hoher Ebene an letzter Stelle. Dies ermöglicht es, die durch die Architektur verursachten Unannehmlichkeiten frühzeitig zu entdecken. Haben Sie keine Angst, die Architektur zu ändern, wenn Hardware-Realitäten zutage treten, aber stellen Sie sicher, dass die gesamte Dokumentation entsprechend aktualisiert wird.

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

   Hier hilft der modulare Aufbau wieder. Wenn Sie einige Hardware-Interaktionen auf niedriger Ebene nicht vernünftigerweise 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 wissen nicht, dass dies geschieht. Sie werden das Low-Level-Modul nicht auf diese Weise überprüfen, sondern fast alles andere.

Kurz gesagt, verwenden Sie gute Software-Design-Praktiken, die Sie natürlich trotzdem anwenden sollten.

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 mit einer Reihe gemeinsamer Peripheriegeräte, die dies möglicherweise ermöglichen Simulieren Sie mindestens einen Teil Ihrer eventuellen Zielhardware.

Abhängig davon, 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 bestimmtes Verhalten zu simulieren, können Sie zumindest ein Modell des Systems (API ...) erstellen, sodass die eigentliche Implementierung viel schneller und klarer wird, sobald die Hardware bereit ist.

Es gibt natürlich viele Dinge, die nicht simuliert werden können, wie Echtzeitverhalten oder komplexe Hardwaretreiber. Andererseits kann ein Interrupt-gesteuerter ADC einfach mithilfe eines Threads simuliert werden, der Werte aus einer Datei oder einem Netzwerkport liest.

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

• Können Sie dieselbe / ähnliche Toolchain für Controller und PC verwenden (z. B. gcc)?
• Wie hardwareabhängig ist das System?
• Wie erfahren sind Sie mit der PC-Programmierung?

Zum einen entwerfe ich so ziemlich jedes Firmware-Modul zuerst auf einem PC.

Versuchen Sie, einen Simulator für Ihren Chip zu bekommen. Sie sollten alle erwarteten und einige unerwartete Eingaben 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 eine Funktion verwandeln (Board-Selbsttest).

Wenn Sie keinen Simulator erhalten können, abstrahieren Sie so viel wie möglich über eine HAL (Hardware-Abstraktionsschicht). Alle Fahrer stehen dahinter. Versuchen Sie, alle plattformspezifischen Assemblys hinter einem C-Funktionsaufruf zu abstrahieren, und betrachten Sie diese auch als Treiber. Schreiben Sie den Rest als portablen C / C ++ - Code, 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 nur die HAL debuggen, wenn Sie die Hardware erhalten. Je dünner es ist, desto schneller werden Sie es debuggen und alles funktioniert. Denken Sie daran , dass , wenn Sie plattformspezifische verwenden Montage für eine schnellere ops, Sie DO sehr wünschen Bit-genaue Tests zu erhalten .

Ihre Frage ist etwas weit gefasst. Hardware (HW) kann eine vollständige benutzerdefinierte 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 dass Sie vielleicht programmieren möchten ....). Bei hohen Verkaufsmengen ist es nicht ungewöhnlich, es zu einem ASIC zu machen.

Für ein zweimonatiges Projekt erwarte ich jedoch, dass es auf einem Mikrocontroller basiert:

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

In gewissem Umfang sind auch Simulatoren möglich, aber Sie müssen möglicherweise noch einige reale Sensoren / Daten charakterisieren, die Sie möglicherweise erhalten. Hier muss Ihnen auch das Hardware-Team zumindest weiterhelfen.

Ansonsten kann das Software-Design bereits durchgeführt werden und alle High-Level-Module können (und sollten) ohne die echte Hardware implementiert und getestet werden. Im Idealfall definieren Sie auch zusammen mit dem Hardwareteam eine API, die Ihnen die Funktionen der untersten Ebene bietet, sodass Änderungen, die sie auf der Hardwareseite vornehmen (z. B. einfach neu definieren, welche Port-Pins sie verwenden), nicht immer erfolgen sei kritisch für dich.

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

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

Wie ?

Zuerst müssen Sie das Hauptziel dieses Systems kennen. Daher können Sie den Controller entsprechend aus einer Vielzahl verfügbarer Quellen wie digikey, mouser auswählen.

Und wählen Sie einen Simulator wie Proteus. Dies simuliert den genauen Prozessor / Controller, jetzt können Sie mit der Codierung beginnen. Aber Sie können die Genauigkeit wie bei der Hardware nicht erwarten.