Pick and Place: Teil2 JUKI Placemat 460 Retrofit Board

Wie im Podcast schon erwähnt, haben wir uns überlegt den 286er der JUKI Placemat 460 durch einen STM32F4 zu ersetzen. Also gesagt getan. Erst war die Überlegung das Steuerboard inkl. PC zu ersetzen und die neue Flachbaugruppe an die gleiche Stelle wie die alte Steuerplatine zu possitionieren. Sozusagen ein Retrofit Board. Alle alten Stecker sollten verwendet werden. Als dann die alten Schaltunterlagen gesichtet wurden, wurde diese Entscheidung kurzerhand überdacht und verworfen. Es wurde ein Board entwickelt, welches zwar den 286er ersetzt, aber nicht die Steuerplatine. Dazu musste einfach nur die 3V3 Welt des STMs in die 5V Welt der Steuerplatine umgesetzt werden.

Wie es so ist, wurden noch ein paar Interfaces neu ergänzt. Da noch Unsicherheit besteht, welches das Richtige ist, sind hier mehrere zum Einsatz gekommen. Es wurden Interfaces für eine µSD Karte, ein 100MBit LAN und ein USB zu UART bereitgestellt. Da auch die Überlegung besteht, den Bestückkopf um mehr als nur 90° drehen zu lassen wurden auch noch 2 Polulu Steckplätze vorgesehen. Alles in allem ist die Platine doch sehr kompakt geworden. Geradeeinmal 100x85mm.

So in der Art soll das Board später mal eingebaut sein. Im Idealfall werden nur die 2 Flachbandkabel benötigt und das Board ist fertig zur Verwendung. Bei den Bauteilen wurde darauf geachtet, möglichst wenig Varianz zu haben. Für das komplette Board, kommen nur 15 verschiedene SMD und nur 5 verschiedene THT Bauteile zum Einsatz. Alle Bauteile waren bei JLCPCB  bzw LCSC bestellbar. Genug Bauteile für 2 Flachbaugruppen, 5 Rohleiterplatten und eine Schablone haben zusammen nur ca. 80€ gekostet. Sobald alles da ist wird es spannend. Mal sehen ob die Flachbaugruppe als erste mit dem Bestückautomat herzustellen geht.

Pick and Place: Teil1

Wir haben uns einen Bestückautomat gekauft. Wie das mit unseren Käufen meistens so ist, spontan. Chris hat den Automat bei ebay Kleinanzeigen gesehen und 2 Tage später haben wir ihn in den Keller von Basti gebracht. Der Automat wiegt stolze 300kg und besteht hauptsächlich aus Stahl.

Der Automat  besitzt einen Transformator, der die Eingangsspannung von 230VAC in 100VAC umwandelt. Dieser wiegt stolze 12 kg und besteht aus ziemlich viel Kupfer. Die 100VAC Spannung wird im Automat in zwei DC Spannungen konvertiert. 24V und 5V. Bei Kauf und Erst-Inbetriebnahme im Keller zeigt der Steuerungsrechner eine Fehlermeldung an. Diese war leider in den Unterlagen nicht dokumentiert und lautete „Notstop betätigen! PWB-Stecker nicht verbunden.“ Der Steuerungsrechner ist ein 286er der mit dem Automaten über parallele Schnittstellen kommuniziert. Die parallelen Schnittstellen sind zwei Einsteckkarten in den ISA-Bus des Rechners. 

Bei der Fehlersuche wie wir die Fehlermeldung loswerden, hat Chris herausgefunden, dass die LED des 5VDC Nezteil nicht leuchtet. Wir haben uns mit einem Labornetzteil an den 5V Kreis gehängt, nachdem wir mit einem Multimeter auf Kurzschluss nach Masse getestet haben. Die Stromaufnahme war ca. 500mA und die Fehlermeldung verschwand. Also haben wir uns entschlossen das Netzteil zu reparieren. Bei näherer Untersuchung hat sich gezeigt, dass einer der Elektrolyt -Kondensatoren ausgelaufen ist und das ganze Netzteil mit klebriger Pampe verschmiert hat. Das hat wohl zu einem Kurzschluss geführt. Ziemlich erstaunlich, dass in einem 30 Jahre alten Gerät die Elkos noch flüssiges Elektrolyt haben. Spricht für deren Qualität.

Wir haben also eins der super kleinen 230VAC auf 5VDC/2A Netzteile anstelle des alten Netzteils eingebaut und siehe da, die Kiste läuft und reagiert auf Steuerbefehle vom Rechner. Beeindruckend ist auch der Unterschied in der Bauform der Netzteile. Das kaputte Netzteil konnte aus den 100VAC 5VDC mit 1A Strom erzeugen. Das neue Netzteil ist ist ungefähr so groß wie eine Briefmarke, hat einen breiteren Eingangsspannungsbereich und kann den doppelten Strom am Ausgang liefern.

Wir haben einen Initialisierungstest durchgeführt uns alle Funktionen einmal getestet. Wie nicht anders zu erwarten ist die Bedienung etwas umständlich. Es gibt kein USB (Verison 1.0 wurde erst 4 Jahre nach Baujahr der Maschine veröffentlicht) und eine serielle Schnittstelle ist auch nicht zu finden, also werden wir um ein Update nicht herum kommen wenn das Teil sinnvoll eingesetzt werden soll. Denn irgendwie wollen wir unsere Daten automatisch vom PC in den Bestückautomaten bekommen.

Wir haben uns entschlossen die Kiste auf eine aktuelle Hard-/ und Software zu bringen. Dazu werden wir ein neues Interface-Board entwickeln, dass so aufgebaut ist, dass es mit den originalen Bedingungen des Bestückautomats herstellbar ist. Quasi ein selbst replizierendes Ersatzteil. Das soll später an die gleiche Stelle wie die aktuelle Interface Karte, und mit den gleichen Steckern arbeiten.

Wie genau müssen wir noch besprechen. Das ist dann eine Sache für den nächsten Eintrag.

Knöpfchenspiel 1 – Systemübersicht

Heute beschreibe ich das Knöpfchenspiel. Wie bereits im Podcast erzählt, ist das primäre Ziel das Spiel bis April fertig zu bekommen. Daher gibt es bereits einige fertige Komponenten.

Das originale Knöpfchenspiel steht meistens in Spielhallen und kann dort gegen Geldeinwurf gespielt werden. Dazu müssen die leuchtenden Knöpfe gedrückt werden. Jeder Knopfdruck gibt einen Punkt. Wenn ein nicht leuchtender Knopf gedrückt wird, wird ein Punkt abgezogen. Das sieht dann so aus:

Das von mir geplante System ist ähnlich aufgebaut. Nur dass die Spieler nicht gegenüber, sondern nebeneinander spielen und dass die Punkteanzahl an einem großen Fernseher dargestellt wird und nicht auf einer 7-Segementanzeige. Dazu wird das System in mehrere Submodule aufgeteilt.

 
  • System-Controller (Raspberry-Pi)
  • Bus-Interface (Differenzieller I²C Bus Treiber)
  • Knöpfchen-Controller (STM32F030)
  • Knöpfchen
  • LED-Band-Controller
  • Power Supply

System-Controller

Der Raspberry Pi übernimmt die Steuerung des Spiels und die Anzeige der Punkte am Bildschirm. Dazu wird das HDMI Interface in maximaler Auflösung (1920×1080) betrieben. Weiterhin hängt am Pi noch eine Webcam (USB) mit der die Spieler für die High-score Liste fotografiert werden.
Auf dem Raspberry steckt die DIIC Baugruppe. Das Bus-Interface Board
Bus-Interface

Bus-Interface

Um einen stabilen I2C Bus über alle Baugruppen zu bekommen, habe ich mich für einen Differenziellen Bustreiber entschieden. Dieser ist in der Lage die Eindraht-Signale der I2C Strecke auf zwei differenzielle Signale aufzuteilen. Diese sind wesentlich unempfindlicher gegenüber elektromagnetischer Störung. Das Bus-Interface Board besitzt die nötigen Stecker für den Knöpfchenspiel Bus, ein RJ45 Stecker, der über normale LAN-Kabel miteinander verbunden werden kann.

Knöpfchen

Das Knöpfchen ist ein 60mm durchmessender Plastik Druckknopf (Schließer), der von hinten beleuchtbar ist. Die Beleuchtung wird von einer weißen LED übernommen.

 

Knöpfchen Controller

Die 16 Knöpfchen sind an dem Knöpfchen-Controller angeschlossen. Der Controller ließt den Schaltzustand der Knöpfchen ein und vergleicht ihn mit den Lampen. Wenn die Lampe an war, wird der Punktestand um eins erhöht, wenn die Lampe aus war, wird der Punktestand reduziert, bis er bei 0 angekommen ist.
Auf dem Knöpfchen-Controller Board ist ein DC/DC Wandler, der die 12V Bus-Spannung auf 5V herab setzt. Die 5V werden dann mit einem linear Regler auf 3,3V für den Controller heruntergesetzt. Die Knöpfchen und Lampen in den Knöpfchen können mit 12V, 5V, oder 3,3V versorgt werden.
Der Controller besitzt ein I2C Slave-Interface, dass die Spielinformationen an den Spiel-Controller übertragen kann.

LED-Band-Controller

Um das Spiel von Außen attraktiver zu gestalten, habe ich vor eine LED-Leiste an der Kante anzubringen, ähnlich wie bei der oben gezeigten Variante. Dafür habe ich WS2812 LEDs als Leitungsband vorgesehen. Gesteuert werden die LEDs von einem eigenen Controller. Wahrscheinlich der Arduino Nano, den ich schon für die Bühnenkulisse verwendet habe. Den kann man über die USB -> UART Brücke auf dem Arduino vom Raspberry Pi ansprechen.
Für das System werden zwei AC/DC Netzteile eingesetzt. Ein 5V und ein 12V Netzteil. Das 5V Netzteil ist für die Versorgung des Raspberry Pis und LED-Band vorgesehen. Das 12V Netzteil übernimmt die Versorgung des Bus-Systems, Knöpfchen-Controller Boards und der Knöpfchen. Beide werden über den gleichen Kaltgeräte-Stecker angeschlossen und abgesichert.

World Smallest 3D Printer Hardware/Software Part1

So… es ist soweit. Die erste Platine bzw. Platinen sind gekommen. Da mir Bestückung für eine Prototypen Platine noch zu teuer ist heißt es gleich ran an`s Werk. Die Platinen incl. Bauteile hab ich bei JLCPCB bzw.  bei LCSC. Diese kammen innerhalb von 10 Tagen nach Bestellung bei mir an. Was ich sehr gut finde ist, dass JLCPCB die Ware ordentlich deklariert hat, wodurch die Post das Paket ohne Probleme weitergegeben hat. Gegen eine Extrazahlung von nochmal 19% habe ich dann das Paket vom Postboten bekommen. Naja, kam zwar ohne Probleme, aber war dann doch sehr verwirrend. Am Morgen kam ein Brief von der Zoll Stelle Leipzig, dass ich doch bitte einen Haufen Unterlagen hinschicken soll, meinen Firmennamen usw. Mittags kam dann das Paket trotzdem an. Komisch aber ich will mich nicht beschweren.

Jetzt gehts an`s Bestücken. Ich hab alles in allem für die erste Platine zwei Stunden gebraucht. Jedoch hatte ich bei den Stepperdrivern meine Probleme. Ich werde mir wohl einen Reflow Ofen zulegen müssen um diese ordentlich löten zu können.


Nachdem die Platine dann bestückt war ging es an den Bootloader vom Arduino. Was ich nicht wusste: Der Bootloader findet sich in nahezu jeder Arduinoinstallation unter *:\Arduino\hardware\arduino\avr\bootloaders. Ich habe zu Beginn versucht den Bootloader per BusPirate zu flashen. Nach mehreren Versuchen und auch mehrmaliger Kontrolle der Verbindung habe ich es nicht geschafft den Bootloader mit dem BusPirate zu flashen. Basti hat zum Glück noch einen AVRISP MK2. Nachdem ich diesen angeschlossen habe, ging das flashen ohne Probleme. Jetzt ist der Bootloader drauf und es kann losegehen. Also ein Microusb-Kabel angeschlossen und im Gerätemanager nach dem COM-Port gesucht. Bei mir wird der FDTI Driver sofort installiert und als COM13 bekannt gegeben. Ich hab dann erst mal den µSD Karten Test von Arduino aufgespielt. Eine µSD Karte gesucht und das ganze im Serialmonitor von Arduino angesehen. Und siehe da, die µSD Karte hatte ich wohl mal genutzt um einen Octopie zu booten. Sie wird direkt erkannt.

Jetzt will ich einen Port mal wackeln lassen, den H0 Pin. Da dieser der einzige ist, der eine LED hat. Also habe ich in den gleichen Sketch folgende Befehle eingebaut.

digitalWrite(H0, HIGH);
delay(500);
digitalWrite(H0, LOW);
delay(500);

Als ich den Sketch hochladen wollte hat sich Arduino nicht mit dem Bootloader verbunden. Nachdem ich mit dem AVR wieder den Bootloader geflashed habe, ging das dann wieder. Und siehe da die LED blinkt nun im Sekunden Takt. Also geht der H0 Ausgang auch schonmal. Jetzt mal sehen, warum das flashen nicht direkt funktioniert. Und siehe da, ich hab vergessen den DTR Pin mit dem RESET zu verbinden. Erst hab ich gedacht „Warum hab ich den vergessen ich hab doch alles soweit wie möglich übernommen“ doch ich weiß jetzt warum ich den nicht verbunden habe. Der FTDI230x hat diesen Pin nicht. ABER ich kann den CTS Pin hierfür nutzen. Jetzt habe ich einen Kondensator an den Reset gelötet und das hat auch „fast“ funktioniert. Der RESET wurde nicht stark genug auf Masse gezogen. Das liegt daran, dass der Chip eine 3V3 I/O Spannung hat. Da ich nicht einen zusätzlichen IC bestücken will nur um einen Pegel zu wandeln hab ich micht für einen einfachen MOSFET Pegelwandler entschieden. Einen N-KAN MOSFET habe ich schon auf der Platine, dadurch brauch ich kein extra Bauteil. Da aber beim wechsel auf High der Pegel am RESET Pin auf 5V*2 ansteigen kann, brauche ich noch eine Diode um diese Spannung abzuleiten. Da ich keine Dioden (außer LEDs) auf der Platine habe, hab ich auch hier vor einen weiteren MOSFET zu nehmen und die interne Bodydiode zu nutzen. Diese Schaltung habe ich dann mit Fädeldraht auf der Platine realisiert wodurch das Flashen jetzt ohne Probleme klappt.

Jetzt habe ich mir das Marlin runtergeladen und in einer groben Erstkonfiguration auf den MEGA geflashed. Ab jetzt kann ich mit den G-Codes arbeiten. Also fix den Befehl M105 abgesendet um die Temperaturen zu bekommen. Die Platine hat eine Temperatur von um die 20°C was in etwa dem entspricht, wass ich mit meinen Fingern ertaste. Dann hab ich die Platine mal an eine Kerze gehalten. Ja…..  also Kerze macht warm. In wie fern die Temperaturen der Realität entspricht muss ich noch ermitteln.

 Jetzt hab ich den Befehl G28 abgesendet um den Drucker „zu Homen“. Eigenltich wollte ich nur das ein Motor zuckt, ist aber nicht passiert. Also muss ich mir die Stepperdriver nochmal überprüfen.

Zusammenfassend funktioniert:
* USB => UART
* LED an H0
* µSD Interface
* NTC auf der Platine
Was noch nicht funktioniert oder noch nicht getestet ist:
* Stepper Driver
* NTC auf dem Hotend
* Ventilator Ausgang
* Hotend betreiben

Soviel erst mal

World Smallest 3D Printer


Ich hatte vor einiger Zeit die Idee, den Welt kleinsten 3D-Drucker zu entwickeln. Dieser darf nicht zu teuer werden. Er sollte für nahezu jeden, der einen Lötkolben richtig halten kann einfach zusammen zu bauen sein.

Also günstig ABER funktionstüchtig.

Da ich nicht die komplette Software neu entwickeln will, versuche ich mich auf vorhandene Software zu stützen. Meine Wahl fällt auf Marlin, was auf Arduino basiert. Die Hoffnung ist, dass ich mit geringstem Softwareaufwand den Drucker in Betrieb nehmen kann. Da ich den ATmega2560 verwenden möchte, dessen Gehäuse relativ groß ist (warum kommt später) möchte ich mich an dem Rumba orientieren. Diesen Schaltplan nehme ich als Referenz und schon habe ich das Pinout für den Controller.

Also gesagt getan. Die neuste Version von KiCad runtergeladen und los geht’s.

Erst mal den Schaltplan soweit wie nötig erstellt und „neue“ Bauteile aussuchen. Da der Drucker per USB betreiben werden soll, müssen die Stepper, Heizer, Lüfter usw. mit 5V laufen.

Als Stepper Driver wird der STSPIN220 von ST verwendet. Dieser ist super klein und läuft mit dem gewohnten Pololu Interface (STEP, DIR, EN). Als Heizelement werde ich Widerstände verwenden. In diese Flachbaugruppe schraube ich die Nozzle.

Weiter geht’s mit dem Layout. Warum ich ein großes Gehäuse nehmen möchte? Ich möchte ein „beheiztes“ Druckbett. Da liegt es nah den vorhanden µC zu nehmen. Also mir liegt dies nah ;).

Der Controller wird also das Zentrum der Leiterplatte, und der Rest muss versuchen darauf zu passen. Durch diese Einschränkung der „Druckbettgröße“ haben sich die restlichen Maße ergeben und der Drucker bekommt eine Seitenlänge von 7cm.

Da ich auch versuche in der 3D Modellierung besser zu werde, hab ich mit dem Tool FreeCAD versucht den Drucker in 3D zu modellieren.

So oder so ähnlich soll er später mal aussehen. Da ich keine Fräße habe, möchte ich alle Teile aus Flachbaugruppen erstellen und als Verbindungen keine Schrauben wählen, sondern die Teile sollen verlötet werden. Also Lötzinn als Verbindungselement nutzen. Mal sehen wie gut das funktioniert.

RGB LED Uhr

Als ich über diese RGB-LED Ringe bei AliExpress gestolpert bin habe ich mir gedacht, dass die 60 LEDs eine hervorragende Uhr abgeben würden. Angesteuert werden die LEDs von einem Arduino Nano. Angesteuert werden die LEDs mit der Adafruit NeoPixel Bibliothek. Die Uhrzeit speichert eine DS1302 Echtzeituhr.

Alles schön verpackt in einem 3D gedruckten Gehäuse habe ich ein schöne Uhr für die Wand. Energiesparend ist das ganze nicht, daher das Netzteil und keine Batterie.

Arduino Sketch | Thingiverse Modelle

Using the ‚Console‘ to talk to the Yún MCU from Python

Playing around with the Yún led me to the problem that I had a Sketch up and running on the MCU that could be controlled from the Arduino serial console. To move the commanding part to a python script all I had to do was to do this communication from the Linux side of the Yún-Bridge system.

To initialize the Bridge all you have to do is call the Bridge.begin(); function in the setup part of the sketch. After that we initialize the Console with Console.begin(). To stop the execution of further commands we can poll the Console to become ready.
void setup() {
// put your setup code here, to run once:
Bridge.begin();
Console.begin();
while (!Console) {
;
}
}
You can now use the print functions as usual:
  if(Console.available()) {
c = Console.read();
.
.
.
}
On the Linux side we have a python script that will conncet to the bridge server and do the same as the Arduino serial console.
import telnetlib, time

tn = telnetlib.Telnet("localhost", 6571)

while True:
print "w"
tn.write("test")
print tn.read_eager()
time.sleep(1)

WLANKaffee Code Repository

Wir haben vom Hersteller der Maschine die Auflage bekommen, die Informationen nicht öffentlich zur Verfügung zu stellen. Daher wird das Projekt und der Quellcode nicht mehr zur Verfügung stehen.

Ich habe den Code für den Arduino auf einer Google Code Projektseite hochgeladen. Der Code ist teilweise ungetestet, da die Kaffeemaschine noch nicht vollständig verdrahtet ist. Diese Arbeit wir nächste Woche beendet. Der Zeitpunkt für den ersten Release ist dann auch der nächste Dienstag.
Aktuell sind für den ersten Release diese Funktionen geplant:

  • Yún
    • Arduino
      • Firmware die über die Console Klasse gesteuert werden kann.
      • Steuerung der Menüknöpfe am HID
      • Drehencoder wird ausgewertet
      • Drehencoder Impulse werden simuliert
    • Linino
      • Python mit Django
      • Webseite mit Benutzerverwaltung
      • Steuerung über Console Klasse des µController
  • Dokumentation
    • Python
      • SPI Protokoll für Display Frames

Arduino Yún, Linux mit Arduino auf einem Board

Für unsere Projektarbeit haben wir entschieden, dass ein Linux fähiges Board und ein Arduino Mikrocontroller zum Einsatz kommen soll. Um das ganze möglichst klein zu halten haben wir den Arduino Yún ausgewählt. Der Yún hat neben den Funktionen, die auch ein Leonardo mitbringt zusätzlich einen voll funktionsfähigen Computer an Board, der mit einem speziellen openWRT Distribution läuft. Das Besondere ist, dass die beiden Geräte miteinander kommunizieren können und somit beide Geräte direkt miteinander verbunden sind. Auf der Linuxseite bietet die Linino Distribution einiges an Funktionalität, wie zum Beispiel eine REST-Full API um die Pins des Arduinos direkt anzusteuern. Eine weitere großartige Funktion wird in der Bridge Bibliothek zur Verfügung gestellt. Die Kommunikation zwischen Mikrocontroller und Programmen auf der Linuxseite.

SSH Konsole des Yún mit Erweiterung für die Kaffeemaschine

In unserem Falle wird der Mikrocontroller die Ansteuerung der Kaffeemaschine übernehmen und bestenfalls den SPI Bus abhören und die übertragenen Displaydaten in einen seriellen Bytestream umwandeln. Die Linuxseite wird die komplette Benutzerschnittstelle bereitstellen, also ein Webinterface mit dem die Kaffeemaschine gesteuert werden kann. Außerdem wird die Webseite den Inhalt des Displays darstellen. Wie die Daten von der Maschine in ein Bild gewandelt werden, habe ich letzte Woche schon beschrieben.

Diese Woche habe ich mich mit dem SPI Interface beschäftigt. Die Displaydaten werden über den SPI Bus vom Benutzerpanel an den Displaycontroller gesendet. Diese Daten können vom Arduino aufgezeichnet werden. Um klein anzufangen, habe ich verschiedene Ansätze ausprobiert. Die Grundvoraussetzung war, dass der Bustakt von 1 MHz eingehalten wird. Dann werden alle 0,1 Sekunden 541 Bytes übertragen. Der genaue Aufbau des Protokolls lässt sich relativ kurz beschreiben. Zuerst bekommt das Display den Wert 0x89 übertragen. In den Datenblättern, die etwas mit dem Display zu tun haben könnten habe ich diesen Befehl leider nicht finden können. Weiter geht es mit dem Byte 0xB4 was laut Datenblatt die Speicherseite 4 als Startadresse angibt. Darauf folgen 134 Bytes mit Bilddaten, bis dann 0xB5 (page 5) übertragen und die nächste Speicherseite ausgewählt wird. Nach weitern 134 Bytes folgt 0xB6 (page 6) und nach weiteren 134 Bytes folgt 0xB7 (page 7). Die abschließende Speicherseite und somit die letzte ‚Zeile‘ des Displays hört auch hier nach genau 134 Bytes auf. Da das Display auf dem Benutzerpanel auf dem Kopf stehend eingebaut ist, sind auch die Daten ‚gekippt‘ Eine einfache Spiegelung hilft das Bild wieder sichtbar zu machen.

Der Arduino Yún

Um mit dem SPI Bus zu arbeiten, ohne die Maschine dabei zu haben, habe ich die Daten eines Frames in ein Arduino-Sketch geladen. Dieser Arduino macht nichts als ein und dasselbe Bild immer und immer wieder alle 0,1 Sekunde über den SPI Bus zu übertragen. Die nächste Aufgabe ist jetzt, die Daten mit dem Yún zu empfangen und zu verarbeiten. Da ich bis jetzt nur einen funktionierende SPI Kommunikation mit Yún als Master und einem Nano als Client zum Laufen gebracht habe, kann ich noch nicht davon berichten, in wieweit sich die Idee mit der Bildgenerierung verwirklichen lässt.

Das SPI Protokoll für das Kaffeemaschinen Display

Dieses Wochenende haben wir im Projektteam die Kommunikation vom Controller auf dem Benutzerboard zum Display genauer unter die Lupe genommen. Da wir keine genauen Informationen über die verwendeten Bauelemente hatten sind wir mit google auf die Suche nach Datenblättern von Displays ähnlicher Bauart gegangen. Die meisten Displays mit SPI Interface verstehen das gleiche Protokoll zum Setzen der Kofigurationswerte und Übertragene der Daten. Die Daten haben wir mit Hilfe des Logic Analyser ja schon das letzte mal aus der Maschine extrahiert. Nach einigen Anläufen haben wir im Datenbaltt eines Displaycontrollers (ST7565R) die Konfiguration des Display RAMs gefunden. Mit dem Wissen wie das Bild, das im Display angezeigt wird zu übertragen ist, gelang es uns den Datenstream so zu formatieren, dass wir das Bild des Displays gespiegelt auf dem Bildschirm sehen konnten. Mit ein wenig Bearbeitung der
Daten ist es gelungen das Bild, das am Display angezeigt wird zu rekonstruieren.

Der Inhalt des Datenstreams in serieller Formatierung

Datenübertragung in der Maschine

Die Maschine kommuniziert einmal mit der Steuerplatine und dann mit dem Display. Dabei ist die Verbindungsleitung zwischen den Platinen mit einem Enable
Signal verehen. Wenn dieses Signal High ist, ignoriert die Steuerplatine die Daten; wenn der Pin auf Low gelegt wird, sind die Daten am Bus für die Steuerplatine.
Vom Controller gehen, neben der Datenleitung MOSI, nicht nach Außen geführte Leitungen an das Display. Es ist also anzunehmen, dass dort auch eine Enable und/oder
Clock Leitung dabei ist. Die Daten, die über den SPI Bus bei dauerhaftem High Zustand auf Enable an der Controllerplatine gehen sind somit aller Wahrscheinlichkeit
nach an das Display gerichtet. Genauer betrachtet wurden jedes Paket 541 Bytes übertragen. Das Display hat eine Bildmatrix von 128 * 32 Pixeln, somit werden
4096 Bit zum Darstellen eines monochromen Bildes benötigt. Die übertragenen Bytes beinhalten diese Datenmenge und zusätzlich noch einige Steuerbefehle.

Das Bild steht noch auf dem Kopf und die Page-Select Befehle sind noch links sichtbar

Display RAM

Wichtig ist dabei zu beachten, dass die Pixelreihen des Display nicht wie erwartet seriell mit Daten bestückt werden, sondern der serielle Kommunikationsport nur vor den parallelen geschaltet wurde. Dadurch ergibt sich die Eigenschaft, dass die Daten ‚Zeilenweise‘ in den Speicher des Displays geladen werden. Zeilenweise
bedeutet dabei, dass der Speicher in 8 bit breite Pages eingeteilt wird. Jede Page wird zuerst ausgewählt und dann von Spalte 0 an aufgefüllt. Dadurch erscheinen die Bilddaten nicht waagerecht, sondern senktrecht und werden so zusammen gesetzt. Nachdem der Aufbau des Speichers bekannt war, konnten wir unsere Software danach ausrichten und haben den Displayinhalt ‚CAPPUCCINO‘ in den sortierten Matrxwerten erkennen können. Jede Zeile oder Page begann mit einem Page-Select Befehl, der getroßt ignoriert werden konnte. Der letzte Schritt war es, die Matrix der Bilddaten in ein PNG zu gießen um es später als Bild in einer Webseite verwenden zu können.

Die rekonstruierte Grafik des Maschinendisplays

Analyse des Protokolls zur Maschinensteuerung

Nachdem jetzt die Übertragung der Displaydaten bekannt ist, müssen noch die vorherigen 10 Bytes der Maschinensteuerung in einen Kontext gebracht werden. Mit Hilfe eines kleinen Scripts habe ich die Logic Analyser Mitschnitte in Kommando- und Bildabschnitte zerlegt. Das Bild wird generiert und die Kommandodaten werden daneben in einer Tabelle abgebildet. Jetzt müssen wir nur die passenden Befehle herausfinden. Dazu gibt es dann nächste Woche mehr.