Skip to content

Dokumentation

Jonathan edited this page Apr 27, 2021 · 22 revisions

Dokumentation PicSim

Allgemein

Grundsätzliches zu einem Simulator

Ein Simulator versucht die Realität nachzubilden. Da die Realität allerdings sehr komplex ist, muss diese abstrahiert werden. Dazu werden Modelle gesucht, welche bestimmte Spezifikationen besitzen, die wichtig für den Anwendungszweck der Simulation sind. Für den PIC-Simulator ist das Ziel schon vorgegeben. Es soll ein PIC simuliert werden.
Simulationen können unterteilt werden in Simulationen mit oder ohne der Verwendung Informationstechnik. Eine Simulationen ohne Informationstechnik ist z.B. der Auto-Crashtest, bei welchem ein Verkehrsunfall wird.[^SimulationWiki] Damit keine Menschen dabei gefährdet werden sollen, werden dafür Crashtest-Dummys verwendet. Da die Realität bei einem Crashtest sehr vereinfacht wird, ist es möglich verschiedene Autos beim Crash besser vergleichen zu können. Simulationen mit Informationstechnologien sind besser bekannt als Computersimulationen. Dazu zählen z.B. Fahrsimulatoren, Flugsimulatoren usw. Es gibt verschiedene Gründe eine Simulationen zu entwickeln. Oft wären Test am realen System zu teuer oder ethisch nicht vertretbar. Es kann aber auch sein, dass das reale System noch gar nicht existiert (z.B. Strömungsmodelle bei einem neuen Flugzeug) oder zu komplex oder noch zu unverstanden ist (z.B. Urknall) um es an einem realen System zu testen.[^SimulationGründe]

Vor- und Nachteile einer Simulation

Vorteile einer Simulation sind hauptsächlich die oben genannten Gründe (Grundsätzliches zu einem Simulator). Für den PIC-Simulator sind nur zwei Gründe wirklich relevant: Aufwand und Kosten. Durch eine Simulation werden immer gleiche Bedingungen erzeugt. Dadurch lässt sich das Programmieren mit einem PIC einfacher lernen. Denn es wird keiner Hardware aus einem Computer vorausgesetzt. Es gibt keine Hardwarefehler und der ausgeführte Programmcode lässt sich einfacher überwachen.
Da ein Simulator das Verhalten eines Systems nur vereinfacht darstellt, kann ein Simulator nicht das gesamte System repräsentieren. In diesem Fall wäre ein Emulator wesentlich besser geeignet. Dieser emuliert sowohl Software als auch Hardware.

Realisierung

Konzept

Gliederung

Struktur

Nachdem ddie LST Datei ausgewählt und in den PICSim geladen wurde, zeigt die GUI durch einen Highlighter den nächsten Befehl an der abgearbeitet wird. Im Hintergrund wurden bis dahin, wie im Ablaufdiagramm zu sehen, die Instructions in das Programm-Array geladen, die Variablen initalisiert und das Programm wartet auf die User Eingabe. Sobald der User den Start-Button klickt startet das Programm mit dem ersten Befehl, analysiert die Instruction, arbeitet diesen Befehl ab, der Programm Counter wird angepasst, der Highlighter springt zum entsprechenden Befehl und der nächste Befehl wird ausgeführt. Sollte jedoch der Stop Button geklickt worden sein wartet das Programm bis zum nächsten Start, bevor der nächste Befehl ausgeführt wird. Beim Step wartet das Programm vor jedem Befehl auf die nächste Eingabe.

GUI

Ablaufdiagramm

Um einen PIC zu simulieren müssen dessen Komponenten Softwere mäßig nachgebildet werden. Hierfür wird der Hauptspeicher mit seinen Regisstern als String Array abgespeichert. In jeder "Speicherzelle" steht ein String mit 8-Zeichen. Initialisiert werden diese Speicherzellen mit 8x0. Alle Speicherzellen können angeklickt und manuell als Hex oder Binär beschrieben werden. Der Wert wird immer als Hex angezeigt. Intern wird jedoch ein 8-Zeichen String verwendet.

GUI-Top_Speicher

Das Programm wird aus der LST Datei ausgelesen. Dabei wird die Instruction extrahiert und als Program-Array abgespeichert. Auf diese Speicherstellen zeigt der Programmcounter (PCL). Dieser wird als Int-Wert realisiert welcher auf den auszuführenden Befehl zeigt. Nach jedem duchgeführten Befehl wird dieser hochgezählt. Sprungbefehle geben den absuluten Wert an an den gesprungen werden soll. Der Stack wurde wie das Programm als Array mit dazugehörigem Stack-Pointer realisiert. Dies ermöglicht, dass bei einem Überlauf über den Inhalt von 8 wieder das erste Element überschriben werden kann. Der Stack ist mit Null initalisiert und wird bei jedem CALL weiter gefüllt und bei jedem RETURN wieder geleert. Der Stack wird in der GUI als Hex-Zahl angegeben, wie in der folgenden Abbildung zu sehen, intern jedoch als 8 Zeichen String gespeichert.

GUI-Top_Stack

Um die Runtime zu ermitteln wird unsere globale Runtime Variable (Int) bei jedem Befehl um die jeweilige Anzahl Cyles hochgezählt. Je nach eingestellter Quarzfrequenz wird die absolute Zeit ermittelt und in der GUI ausgegeben. Das FRS-Register, das W-Register, der PCL ds PCLatch und das Status-Register werden auch in der GUI ausgegeben. Alle sowohl als 8-Zeichen-String als auch zur einfachen Lesbarkeit als Hex-Zahl. Die Anzeige ist in der folgenden Abbildung farblich Markiert. Das wReg ist nicht Teil des Storage sondern wird als eigene String Variable realisiert. Der PCL wird wie oben beschriben als Int verwendet, für die Ausgabe in der GUI wird er in einen, auf 8 Stellen normalisierten, Binären-Sting und eine Hex-Zahl umgewandelt. FSR ist Teil des Storage und seht dort an Stelle 4. Es wird als speicher für die indirekte Adressierung verwendet Das PCLatch ist ebenso Teil des Storage, es steht an Stelle 10. Verwendet wird es um die Programm-Page umzuschalten. Alle Register können manuell, durch anklicken, als Hex oder Binär beschriben werden.

Ebenso ist in der Abbildung Einstellbare Quarzfrequenz, die Runtime sowie der Button Runtime Reset zu sehen. Die Runtime wird intern als Int-Variable bei jedem Befehl hochgezählt. Pro Cycle den ein Befehl benötigt um 1. Diese Cycle Anzahl wird dann mithilfe der Quarzfrequenz in die tatsächliche Runtime umgerechnet und ausgegeben. Der Button Reset Runtime setzt den Wert wieder auf 0.

GUI-Top_wReg+Runtime

Das Tris A & B Register stellt die In/Out-Schnittsstellen dar. Dieses Register ist Teil des Storage an Stelle 5. Hier werden die PINs auf Input oder Output gesetzt. Die Werte können auch manuell eingestelt werden.

GUI-Top_Tris

Klassendiagramm:

class-diagram

Dart als Programmiersprache für den Simulator

Da die Programmiersprache für den PIC-Simulator frei wählbar war, entschieden wir uns relativ schnell für die Sprache Dart. Dart bietet eine sehr einfache Syntax, die vergleichbar mit Typescript und Kotlin ist. Ein weiterer Grund der für Dart spricht ist das UI-Framework Flutter. Mit Flutter lassen sich sehr einfach ansprechende User Interfaces entwickeln. Da Flutter und Dart außerdem auf vielen verschiedenen Geräten laufen können, lag es nahe auch die Crossplatform-Möglichkeiten zu nutzen.

Einige Beispiele

Realisierung der Flags und wie sie funktionieren

Interrupts

Funktion des TRIS-Registers

Zusammenfassung

(Wie weit konnten die Funktionen des Bausteins per Software nachgebildet werden?)

Fazit

Literatur

[^SimulationWiki]: "Simulation" https://de.wikipedia.org/wiki/Simulation 27.04.2021 [^SimulationGründe]: "Simulationen" https://javainformatikblog.wordpress.com/simulationen/ 27.04.2021

Clone this wiki locally