8-Bit-Breadboard-Computer auf Basis einer 6502-CPU - Clock-Modul upgraden
Bisherige Artikel dieser Serie - hier könnt ihr nochmal alle Grundlagen nachlesen, falls ihr jetzt erst einsteigt:- Digitale Logik und Logikgatter einfach erklärt
- Verwendung des 555-Timer als Taktgeber / Clock
- Das Clock-Modul: Taktgeber für unseren Breadboard-Computer
- Speichertypen und Zugriff auf Speicher
- Erste Schritte mit der CPU
- Eine echte WDC W65C02-CPU
- Das Speicher-Modul: Anbindung von RAM und ROM
- Erstes Programm in Maschinensprache: RAM-Test
- Das Sniffer-Modul: Ein Arduino/STM32 zeigt an, was auf dem Bus los ist.
- Erstes Ausgabegerät: Adressierung und Ausgabe auf 8 LEDs
- Programmiersprache-Evolution: von Maschinensprache zu Assembler
- 3-fach 7-Segment-Anzeige als dezimale Ausgabe, Teil 1: Taktungsprobleme
- 3-fach 7-Segment-Anzeige als dezimale Ausgabe, Teil 2: 20 Nanosekunden, die nicht sein sollten
- 3-fach 7-Segment-Anzeige als dezimale Ausgabe, Teil 3: Assembler-Programme
- 3-fach 7-Segment-Anzeige als dezimale Ausgabe, Teil 4: neue Adressierungsarchitektur mit 74HC688 und 74HC138
- 3-fach 7-Segment-Anzeige als dezimale Ausgabe, Teil 5: Programmierung in Assembler
- 3x16 Zeichen LCD DOGM163 als Textausgabe-Gerät, Teil 1: Breadboard-Aufbau und erste Programmversion
- 3x16 Zeichen LCD DOGM163 als Textausgabe-Gerät, Teil 2: Debugging
- Clock-Modul upgraden
Also wechsle ich den für den Takt zuständigen Elko mit 1 µF (im Bild vorne rechts das blaue Bauteil)
mit einem Kerko mit 47 nF aus. Das sollte die Frequenz um den Faktor 1000 / 47 = 21.3 anheben von 500 Hz auf ungefähr 10 KHz, ein Zyklus dauert etwa 0.1 ms. Ich bin überrascht, dass die Ausgabe auf das LCD damit immer noch einwandfrei funktioniert. Die eingebauten Pausen im Code scheinen auch für diese Frequenz ausreichend zu sein.
Allerdings muss ich schnell bemerken, dass das jetzt zu schnell für den Sniffer ist. Ich optimiere den STM32-Code, dass er nun nur rund 30 mal das Sniffer-Display aktualisiert und keine Zeit mit unnötigen Updates verschwendet. 30 Frames pro Sekunde reichen aus, niemand braucht die bisherigen 1000 fps. Dennoch: Bei einer Taktfrequenz von 10 KHz machen die IRQ auf dem STM32 nicht mehr mit. Das erkenne ich schon daran, dass die interne LED nicht mehr blinkt (bzw. bei dieser hohen Frequenz eher durchgehend leuchtet). Das heißt, dass die IRQ-Ereignisse nicht mehr ankommen bzw. verarbeitet werden.
Ich versuche herauszufinden bis zu welcher Frequenz der Sniffer noch zuverlässig arbeitet und komme auf 0.3 ms, also 3 KHz. Da ich aber möchte, dass in den Begrenzungen des Poti-Taktes auch der Sniffer noch korrekt arbeitet, muss ich die Frequenz verringern bzw. die Kapazität des Kondensators erhöhen. Zur Auswahl habe ich noch 100 nF, 200 nF und 220 nF. Ich wähle den 220 nF-Kondensator, denn der bringt noch einen weiteren Vorteil mit sich.
Denn mit dem 220 nF-Kondensator kommen ich ziemlich genau auf 0.5 ms (ganz genau 0.489 ms) pro Zyklus und das bedeutet, dass ein NOP-Befehl, der 2 Taktzyklen dauert, genau 1 ms dauert. Mit der Regel 1 NOP = 1 ms im Hinterkopf tue ich mich beim programmieren leichter, wenn ich irgendwelche Timings implementieren muss.
Und die 0.5 ms pro Takt iegen weit genug über den 0.3 ms, bei dem der Sniffer noch arbeitet. Ich kann also mit dem Sicherheitsabstand davon ausgehen, dass der in allen Lagen, die ich mit dem Poti einstellen kann, gut funktioniert.
Zudem ist die einstellbare Minimalfrequenz mit ca. 7 Hz noch niedrig genug, um den durchlaufenden Code grob zu erfassen und an der richtigen Stelle zu stoppen. Bei den 47 nF war das zu schnell.
Den über Potentiometer einstellbarer Takt ist also jetzt optimal. Trotzdem möchte ich doch wissen, wieviel ich meinen LCD-Modul denn jetzt zumuten kann und ab wann es aussteigt.
Aber ich habe ja noch mein Frequenzgenerator-Modul, das einen sauberen Takt von 1 Hz bis 160 KHz abliefern kann. Da das Modul in einem nichtleitenden Bumper-Case aus 3D-gedrucktem PLA-Kunststoff sitzt und über Jumper-Kabel angeschlossen wird, brauche ich dafür eigentlich nur ein freies Plätzchen auf dem Breadboard und finde es über den 7400er ICs.
Mit einem mit dem Seitenschneider zurechtgeschnittenem Plastikteil aus einem missglückten 3D-Druck als Stütze und etwas Klebeknete wird es auf dem Breadboard befestigt und dann über Jumper-Kabel verdrahtet:
Mit dem Schalter oben links kann ich den Frequenz-Generator nun an und ausschalten. Schön dabei ist auch, dass sich das Modul die letzte Frequenz merkt und ich sie nicht immer wieder neu einstellen muss.
Und mit dem neuen, kleinen Schalter links oben neben dem grünen Einzeltakt-Button kann ich dann den automatischen Takt zwischen Poti-Takt und Frequenzgenerator-Takt umschalten.
Im Bild oben steht er gerade auf 40 KHz. Und selbst damit funktioniert die Ausgabe auf das DOGM163-LCD tadellos. Der Text steht damit fast unmittelbar da. Sogar mit 100 KHz (im nachfolgenden Video sage ich fälschlicherweise 10 KHz, richtig sind aber 100 kHz) funktioniert das LCD - in den meisten Fällen. Der Takt von 40 KHz ist aber sicherer, solange ich nicht das Timing in der Software angepasst habe.
Bei 160 KHz hat das Modul dann seine Grenze, mehr geht damit nicht. Aber ich sehe momentan auch keine Notwendigkeit dafür; das sollte fürs erste ausreichen. Ansonsten hätte ich auch noch Oszillatoren zu 1, 2, 4, 6, 8, 10 und 14 MHz im petto, wenn ich mal Lust bekomme, meinen Breadboard-Computer auf Geschwindigkeit zu trimmen. Aber dazu ist jetzt noch nicht der Zeitpunkt. Aber wenn es soweit ist, wird das Nachrüsten kein großes Problem darstellen, die Oszillatoren sind einfach zu handhaben und liefern direkt den aufgedruckten Takt.
Mit dem verbauten Frequenzgenerator sieht mein Breadboard Computer wieder ein Stück spaciger aus und ist besser bedienbar geworden.
Video
Natürlich gibt es auch diesmal wieder ein Video. Diesmal allerdings ein wenig verwackelt, weil aus der Hand gefilmt. DAfür nicht weniger interssant: