Gibt es gute (und preiswerte) Lösungen, um STM32 Projekte - möglicherweise innerhalb STM32CubeIDE zu simulieren? Ich stieß auf Wokwi und Proteus.
Nemopuk schrieb: > Wozu soll das gut sein, ohne die Hardware drumherum? Simulation ist ein nützliches Element des Design Workflows. Wer eine solche Frage stellt, disqualifiziert sich selbst
Genau. Algorithmen und andere Codeteile, die keinen Zugriff auf die Peripherie brauchen, kannst Du genauso nativ auf einem Pi oder einem Olimex Olinuxino oder Beaglebone entwicklen. Für alles andere brauchst Du eh die reale Hardware und einen - idealerweise schnellen - Debugger. Da ist der STLINK V3 mit seiner High-Speed USB-Anbindung und dem STM32F7 schon nicht schlecht - vor allem für den Preis. Wenn Du mehr brauchst, gibts ETM, die Embedded Trace Macrocell. Das hier ist z.B. die Version für Cortex M7: https://developer.arm.com/documentation/ddi0494/d/?lang=en Die größeren STM32 haben die natürlich auch. Die Events kommen aus einem Interface mit 4 Bit Datenbus plus Clock raus. Dafür hat ARM einen 20-poligen Steckverbinder im 0.05" Raster definiert, der SWD/JTAG und ETM kombiniert und eine Erweiterung des 10-poligen Cortex Debug-Connectors ist. https://documentation-service.arm.com/static/5fce6c49e167456a35b36af1 Dafür brauchst Du dann einen JTrace Pro oder ULink Pro. Nicht ganz günstig. fchk
Mit QEMU sollte die Simulation möglich sein. Edit: siehe https://www.qemu.org/docs/master/system/arm/stm32.html
:
Bearbeitet durch User
Ich werfe mal noch `renode` rein. Basiert im Grunde auf qemu-Technologie, es ist nur deutlich einfacher, virtuelle Hardware fuer die eigene Firmenplattform ranzuflanschen.
Christoph K. schrieb: > Simulation ist ein nützliches Element des Design Workflows. Wer eine > solche Frage stellt, disqualifiziert sich selbst Nicht im Embedded Umfeld. Solche Controller werden selten Simuliert. Wenn dann werden einzelne Algorithmen simuliert, hat dann aber mit dem Controller selbst nichts zu tun.
:
Bearbeitet durch User
Cyblord -. schrieb: > Christoph K. schrieb: >> Simulation ist ein nützliches Element des Design Workflows. Wer eine >> solche Frage stellt, disqualifiziert sich selbst > > Nicht im Embedded Umfeld. Solche Controller werden selten Simuliert. > > Wenn dann werden einzelne Algorithmen simuliert, hat dann aber mit dem > Controller selbst nichts zu tun. Das stimmt nicht (mehr). Simulation und Emulation sind stark auf dem aufsteigenden Ast. Renode wurde schon genannt, ARM liefert mit ihren lizenzierten Compilern ebenfalls Simulatoren mit siehe https://www.arm.com/products/development-tools/simulation/fixed-virtual-platforms, und Correlium hat virtuelle Modelle für komplette embedded Systeme, siehe https://www.corellium.com/ Ziel: Test und Validierung so schnell, so früh, so parallel, und so wenig wie möglich auf Hardware ausführen. So wird das heutzutage gemacht…
Cyblord -. schrieb: > Nicht im Embedded Umfeld. Solche Controller werden selten Simuliert. Und wie in Embedded. Gerade da erst recht, weil man oft ein OS/Programm gegen Hardware zyklengenau und signalecht simulieren koennen muss, um die korrekte Funktion vorab gegen simulierte Stimuli zu testen. Frueher war das einfach recht teuer oder mit GPL infiziert, inzwischen nicht mehr. Beispiele: Generelles Debugging/Tracing, Unitialisierte Register, Verhinderung von Seitenkanalattacken, Timingverhalten von Hardware-Steuerungen. Wer jetzt schreit, das braucht's nur fuer SILx: Inzwischen kann man von jedem Lieferanten erwarten, dass er Code abliefert, fuer den er haften kann.
Martin S. schrieb: > Beispiele: Generelles Debugging/Tracing, Unitialisierte Register, Fällt unter statische Codeanalyse und hat mit Simulation nichts zu tun. > Verhinderung von Seitenkanalattacken, Timingverhalten von > Hardware-Steuerungen. Sehr schwer zu simulieren weil man das Peripherievehalten ebenfalls simulieren müsste. > Wer jetzt schreit, das braucht's nur fuer SILx: Inzwischen kann man von > jedem Lieferanten erwarten, dass er Code abliefert, fuer den er haften > kann. Niemand braucht Simulation oder gar STM32 Emulation für irgendein SIL. Jan K. schrieb: > So wird das heutzutage gemacht… Macht halt keiner.
:
Bearbeitet durch User
Cyblord -. schrieb: > Niemand braucht Simulation Weshalb weißt du so sicher, dass das niemand braucht? Da bist du ziemlich auf dem Holzweg. Das ist vielleicht für dich so. In mehreren Projekten habe ich die Simulation entweder von einzelnen SW-Blöcken oder auch vollständige Systeme simulieren dürfen und es war eine große Hilfe. Alleine schon weil man auf funktionierende HW nicht angewiesen ist. Es erleichtert wirklich vieles. Das waren alles Raumfahrt-Projekte. Und die funktionieren trotz Simulation ;) Und für andere die das verwenden, ist das sicher auch eine große Hilfe und Erleichterung. Wenn du es nicht für notwendig erachtest,OK. Aber dann erzähle hier bitte nicht, niemand braucht das. Damit wirst du unglaubwürdig. Cyblord -. schrieb: > Macht halt keiner. Das ist wirklich an der Realität vorbei. Mach dich mal schlau.
900ss schrieb: >> Niemand braucht Simulation Das Zitat ist entstellt. Sowas macht man nicht. 900ss schrieb: > oder auch vollständige > Systeme simulieren dürfen Welchen STM32 hast du dort simuliert bzw. emuliert?
:
Bearbeitet durch User
Cyblord -. schrieb: > Welchen STM32 hast du dort simuliert bzw. emuliert? Das ist völlig irrelevant, was für eine Architektur das ist. Das ist das schöne wenn man die Simulation gut macht und das SW Design gut ist Wenn man Zyklen zählen muss, wird es schwieriger aber auch das sollte man beim Design schon vermeiden und geht meistens. Cyblord -. schrieb: > 900ss schrieb: >>> Niemand braucht Simulation > > Das Zitat ist entstellt. Sowas macht man nicht. Auch bezogen auf STM32 wird die (deine) Aussage nicht besser. Auch in den Bereichen, wo STM32 überwiegend eingesetzt wird, lässt sich Simulation gewinnbringend einsetzen. Wie gesagt, das ist Architektur unabhängig. Sehr sehr oft jedenfalls. Und auch Peripherie lässt sich inzwischen hilfreich (gut) simulieren.
:
Bearbeitet durch User
900ss schrieb: > Cyblord -. schrieb: >> Welchen STM32 hast du dort simuliert bzw. emuliert? > > Das ist völlig irrelevant, was für eine Architektur das ist. Nun es geht im Thread um den STM32, steht sogar in der Überschrift. > Auch bezogen auf STM32 wird die (deine) Aussage nicht besser. Auch in > den Bereichen, wo STM32 überwiegend eingesetzt wird, lässt sich > Simulation gewinnbringend einsetzen. Lässt sich, hätte, könnte. Ich habe das noch nie in typischen STM32 Embedded Projekten gesehen. Das wird schon irgendwo vorkommen, aber flächendeckend wird es halt nicht gemacht. > Wie gesagt, das ist Architektur unabhängig. Sehr sehr oft jedenfalls. Nur wenn man hardwareunabhängige Softwarestücke simuliert. Diese Anwendung habe ich weiter oben selbst beschrieben. Darum geht es hier aber nicht. Hier geht es aber um explizite Simulation eines STM32. Wobei der TE zwar Simulation schreibt, in Wirklichkeit aber wohl Emulation meint.
:
Bearbeitet durch User
900ss schrieb: > In mehreren Projekten habe ich die > Simulation entweder von einzelnen SW-Blöcken oder auch vollständige > Systeme simulieren dürfen und es war eine große Hilfe. Wirklich nur aus Neugier: Was genau testest Du damit? Den Compiler, die Laufzeit des Codes? Also was genau von der Prozessor-HW. Und welche IO bzw. IO-Emulation hast Du dafür? Bei den PICs habe ich das mit Assembler genutzt (ist eben nicht Plattform-unabhängig).
Cyblord -. schrieb: > Hier geht es aber um explizite Simulation eines STM32. Gut wenn man auf Registerebene runter muss, wird es schwieriger. Nicht nur beim STM sondern generell. Aber auch machbar. Der Aufwand ist halt irgendwann hoch und dann muss man schauen, ob es sich lohnt. Und was du noch nicht gesehen hast, gibt es nicht? Ziemlich gewagt oder?
900ss schrieb: > Und was du noch nicht gesehen hast, gibt es nicht? Ziemlich gewagt oder? Habe ich nicht geschrieben. Im Gegenteil: Ich schrieb das kann es durchaus irgendwo geben, aber ich Maße mir an sehr viele Embedded Projekte an verschiedenen Firmen mit STM32 gesehen zu haben. Und niemand hat dort auf Controllerebene simuliert und gar emuliert.
Bruno V. schrieb: > die Laufzeit des Codes Kann man selbstverständlich schwer simulieren. Geht aber schon wenn der Simulator dafür gemacht ist. War es bei mir nicht. Es war nicht notwendig. Die SW war so designed, dass Laufzeiten großzügig genug waren und es gut funktionierte. Und trotzdem war es ein Echtzeit-System. Es war nicht notwendig, die Prozessor-HW zu testen. Der wurde als funktionierend vorausgesetzt. IO (Peripherie) Simulation wurde tatsächlich gemacht. Das Verhalten der verschiedenen Peripherie-Gruppen wurde simuliert (programmiert). Soweit "runter" dass auch die Protokolle z.B. auf einem MilBus1553 genutzt werden können weil der Controller dafür auch simuliert wurde. Es ist viel Aufwand aber an Ende lohnte es sich. Die Simulation wurde sogar für offizielle Tests genutzt. Das hat entgültige Systemtests auf der realen HW an Ende natürlich nicht ausgeschlossen. Grundsätzlich hat Simulation auch Grenzen und ist kein Wundermittel. Aber sehr hilfreich.
Cyblord -. schrieb: > 900ss schrieb: >> Und was du noch nicht gesehen hast, gibt es nicht? Ziemlich gewagt oder? > > Habe ich nicht geschrieben. Im Gegenteil: Ich schrieb das kann es > durchaus irgendwo geben, aber ich Maße mir an sehr viele Embedded > Projekte an verschiedenen Firmen mit STM32 gesehen zu haben. Und niemand > hat dort auf Controllerebene simuliert und gar emuliert. Das möchte ich nicht in Zweifel ziehen. Heißt aber auch nicht, dass das niemand macht. Ich kann das deswegen jedenfalls nicht ausschließen.
900ss schrieb: > Es war nicht notwendig, die Prozessor-HW zu testen. Der wurde als > funktionierend vorausgesetzt. > > IO (Peripherie) Simulation wurde tatsächlich gemacht Nur zur Klarstellung: War es ein Controller, dessen interne Peripherie getestet wurd? Oder habt Ihr externe IO und den Zugriff darauf emuliert oder simuliert? Das wäre natürlich nicht unüblich sondern oftmals hilfreich. Aber etwas anderes als ich den TO verstanden habe.
:
Bearbeitet durch User
Cyblord -. schrieb: > Martin S. schrieb: >> Beispiele: Generelles Debugging/Tracing, Unitialisierte Register, > > Fällt unter statische Codeanalyse und hat mit Simulation nichts zu tun. > Nein. Weder Trace noch irgend eine Coverage kannst du mit SCA erledigen. Und die SCA hat in die Registerstruktur keine Einsicht. >> Verhinderung von Seitenkanalattacken, Timingverhalten von >> Hardware-Steuerungen. > > Sehr schwer zu simulieren weil man das Peripherievehalten ebenfalls > simulieren müsste. > Genau das mache ich tagtaeglich und finde a) eine Menge Fehler in den Binaerlibraries von Dritten, b) beschleunigt es die die Entwicklung der Eigenanteile immens. Nennt sich auch Co-Simulation, da reale Software gegen virtuelle Hardware zyklengenau simuliert wird. Kann eine Weiterbildung zum Thema renode und Verilator nur empfehlen.
Bruno V. schrieb: > Oder habt Ihr externe IO und den Zugriff darauf emuliert oder simuliert? Das war es eher, also Simulation externer IO. Aber schon recht detailvertieft. Bruno V. schrieb: > Das wäre natürlich nicht unüblich sondern oftmals hilfreich. Eben. Meine ich ja. Bruno V. schrieb: > Aber etwas anderes als ich den TO verstanden habe. Das will ich jetzt nicht ausschließen. Aber da hier auch allgemeiner über Simulation geschrieben wurde, hab ich meinen Senf mal dazugeschrieben. Ich bin halt ein Freund davon :)
900ss schrieb: > Aber da hier auch allgemeiner > über Simulation geschrieben wurde Du meinst NACHDEM du das speziell auf STM32 bezogene Zitat so gekürzt hast, dass es allgemeine Simulation adressiert hat?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.