OTA-Loader für ATmega128RFA1 (im Gerät Smart Response XE) schreiben

Alles begann mit dem Erwerb eines interessanten Geräts durch den Autor auf dem Sekundärmarkt — Smart Response XE (kurze Beschreibung). Es ist für Schulen gedacht: Jeder Schüler in der Klasse erhält ein Gerät, das einer elektronischen Notizbuch oder einem Übersetzer aus den 90ern ähnelt, der Lehrer stellt eine Frage, und die Schüler geben ihre Antworten über die Tastaturen der Geräte ein, die kabellos (802.15.4) an einen Empfänger gesendet werden, der mit dem PC des Lehrers verbunden ist.

Die Unterstützung dieser Geräte wurde vor einigen Jahren eingestellt, und das, was Schulen für 100-200 Dollar pro Stück kauften, taucht jetzt für 10 Dollar oder weniger auf eBay auf. Die Hardware ist sehr gut für Geek-Experimente geeignet:

• 60-Tasten-Tastatur
• Display mit einer Auflösung von 384×136, 2 Bit pro Pixel — ähnlich wie BK, CGA, aber 4 keine Farben, sondern Helligkeitsstufen
• Microcontroller ATmega128RFA1 (128 kB Flash-Speicher, 4 kB EEPROM, 16 kB RAM, Transceiver vom Typ 802.15.4)
• externer (bezüglich des Mikrocontrollers, nicht des gesamten Geräts) Flash-Speicher mit 1 Megabit (128 Kilobyte) mit SPI-Schnittstelle
• Fach für 4 AAA-Batterien.

Der Name des Mikrocontrollers deutet darauf hin, dass er zur AVR-Familie gehört, was bedeutet, dass es mehr als trivial ist, das Gerät mit Arduino kompatibel zu machen...

Aus einer Nachricht auf Hackaday erfuhr der Autor, dass dies bereits gemacht wurde (der gleiche Link erklärt auch, wohin was angeschlossen werden muss), wodurch die Möglichkeit entstand, Spiele für Arduboy zu starten:

Der Autor ist jedoch mehr an der Möglichkeit interessiert, nicht auf dem Gerät zu spielen, sondern es zu erforschen:

• Flash-Speicher mit serieller SPI-Schnittstelle
• Bootloader für AVR
• Standards 802.15.4

Der Autor begann mit dem Schreiben von Bibliothek (GPL v3), das die Initialisierung des Displays ermöglicht, Text und Rechtecke anzuzeigen und Zugriff auf den Flash-Speicher über die SPI-Schnittstelle zu erhalten. Dann begann er, Ideen für die praktische Nutzung des Geräts zu entwickeln: ein tragbares VT-100-kompatibles Terminal, Mehrspielerspiele. Nachdem er drei Geräte umgebaut hatte, beschloss er, sie "zu lehren", Sketche "über die Luft" zu empfangen. Was nicht nur interessant, sondern auch sehr praktisch wäre: Das Gehäuse des Geräts jedes Mal zu öffnen, ist schwierig, und unter der Abdeckung des Batteriefachs befinden sich nur Löcher, die den Anschluss eines JTAG-Programmierers an die Platine ermöglichen.

Das reicht aus, um den Arduino Bootloader zu flashen, aber nicht den Sketch – der serielle Port ist dafür nicht bereitgestellt, ohne das Gehäuse zu öffnen, wird es trotzdem nicht gehen. Auch die TX0- und RX0-Leitungen des ersten seriellen Ports sind mit den Abtastleitungen des Tastaturrasters verbunden, und zwar genau den, über die die Funktionstasten an den Seiten des Displays abgefragt werden. Aber was soll man machen – der Autor hat Folgendes gemacht:

Er hat die JTAG-Leitungen herausgeführt, und jetzt ist es nicht mehr nötig, das Batteriefach zu öffnen. Um auch Sketches zu laden, hat er ebenfalls beide seriellen Ports an diesen Anschluss gelegt und zusätzlich einen Schalter hinzugefügt, da das Gerät mit installierten Batterien physisch nicht anders ausgeschaltet werden kann.

Es war notwendig, ziemlich lange mit dem Lötkolben, einem Cutter und einer Heißklebepistole zu arbeiten. Insgesamt ist das Laden von Sketches „über die Luft“ viel bequemer, dafür muss dringend etwas erfunden werden.

Die Arduino IDE verwendet für das Flashen von Sketches ein Programm avrdude. Es interagiert mit dem Mikrocontroller über das Protokoll STK500, das den Datenaustausch in beide Richtungen ermöglicht. Es ist schlecht kompatibel mit Kanälen, in denen variable Verzögerungen, Verzerrungen und Datenverluste möglich sind. Wenn im seriellen Kanal etwas stört oder knistert, kann man wahnsinnig werden auf der Suche nach der Ursache. Einmal hat der Autor einen halben Tag damit gekämpft, bis er verstand, dass es am schlechten Kabel lag, sowie am wählerischen Interface-Wandler CP2102. Sogar Mikrocontroller mit integriertem Interface-Wandler, wie zum Beispiel der ATmega32u4, können manchmal so „zicken“. Jeder Arduino-Nutzer hat festgestellt, dass Fehler beim Flashen von Sketches nicht so selten sind. Manchmal läuft das Schreiben normal, und beim Überprüfen wird ein Fehler entdeckt. Das bedeutet nicht, dass beim Schreiben ein Fehler war – der Fehler trat beim Lesen auf. Und jetzt stellt euch vor, dass beim Arbeiten „über die Luft“ dasselbe viel häufiger passieren wird.

Nachdem er verschiedene Möglichkeiten ausprobiert hat, um dieses Problem zu überwinden, hat der Autor Folgendes erfunden. Das Gerät verfügt über einen 128-Kilobyte-Flashspeicher mit SPI-Schnittstelle – Daten werden über Leitungen empfangen (wir erinnern uns, dass der Autor bereits ein Gerät mit seitlichem Anschluss hat), wir verwenden diesen Speicher als Puffer und senden die Daten über den Funkkanal an ein anderes Gerät. So eine Grüße von Cybiko.

Nach dem Schreiben des Codes für die Arbeit mit dem Radio-Kanal sowie dem Schriftarten wurde der Bootloader länger als 4 Kilobyte. Daher musste der Wert von HFUSE von 0xDA auf 0xD8 geändert werden. Nun kann der Bootloader bis zu 8 Kilobyte lang sein, und die Startadresse beträgt 0x1E000. Dies ist im Makefile vermerkt, muss jedoch auch beim Flashen beachtet werden. Bootloader mit avrdude.

Der 802.15.4 Sender-Empfänger im ATmega128RFA1 ist ursprünglich für die Arbeit mit dem Protokoll ZigBee, das ziemlich komplex ist, daher entschied der Autor, stattdessen einfach Pakete zu übertragen. Dies ist im ATmega128RFA1 hardwaremäßig implementiert, sodass nur wenig Code benötigt wird. Auch zur Vereinfachung entschied der Autor, einen festen Kanal zu verwenden und es nicht einmal manuell auswählen zu lassen. Der Standard 802.15.4 unterstützt 16 Kanäle mit den Nummern 11 bis 26. Diese sind ziemlich überlastet, einige überlappen auch mit WiFi-Kanälen (rote Kanäle sind ZigBee, blaue, grüne und gelbe – WiFi).

Es stellte sich heraus, dass die am wenigsten störanfälligen von WiFi-Kanälen 15 und 26 sind. Letzteren wählte der Autor aus. Disclaimer: Der Übersetzer weiß nicht, ob es erlaubt ist, ZigBee auf diese Weise zu vereinfachen. Vielleicht sollte man noch ein wenig programmieren und es vollständig umsetzen?

Auf dem ersten Gerät muss ein finite State Machine implementiert werden, die Daten über das STK500-Protokoll überträgt. In der Regel sind die übertragenen und empfangenen Nachrichten eigenständig, aber einige hängen von zuvor über den Kanal gesendeten ab. Eine Beschreibung des Dialogs ist beigefügt. hier.

Ein wichtiger Bestandteil dieses Dialogs ist die Übertragung von Paketen, die zur Speicherung im Flash-Speicher des Zielgeräts vorgesehen sind. Bei einfachen Mikrocontrollern der AVR-Familie beträgt die Seitenlänge 128 Byte, während sie bei der ATmega128RFA1 256 Byte beträgt. Bei dem Flash-Speicher, der über das SPI-Protokoll angeschlossen wird, ist sie ebenfalls gleich. Das Programm im ersten Gerät überträgt den Sketch nicht sofort auf das zweite Gerät, sondern schreibt ihn in diesen Speicher. Wenn die Arduino IDE dann die Korrektheit der Speicherung überprüft, erhält sie die Daten, die dorthin geschrieben wurden. Nun müssen die erhaltenen Daten über den Funkkanal an das zweite Gerät übertragen werden. Dabei erfolgt der Wechsel von Empfang auf Sendung und zurück ziemlich häufig. Das STK500-Protokoll ist unempfindlich gegenüber Verzögerungen, verträgt jedoch keinen Datenverlust (seltsam, denn zuvor wurde gesagt, dass Verzögerungen bei der Datenübertragung auch Auswirkungen haben). Aber Verluste bei der drahtlosen Übertragung sind unvermeidlich. In der ATmega128RFA1 ist eine Hardware-Implementierung von Wiederholungsanforderungen bei Zweifeln an der Korrektheit der Übertragung eingebaut, doch der Autor entschloss sich, das gleiche programmatisch selbst umzusetzen. Er entwickelte ein Protokoll, bei dem in eine Richtung deutlich mehr Daten übertragen werden als in die andere.

Es ist nicht ideal, aber alles funktioniert. Eine 256-Byte-Seite wird in vier Segmente unterteilt, von denen jedes über den Funkkanal als Paket übertragen wird. Das Paket fasst bis zu 125 Byte Daten plus ein Byte – für die Länge und zwei – für CRC. So werden Fragmente mit einer Länge von 64 Byte zusammen mit den Seiten- und Segmentnummern (von 0 bis 3) dort untergebracht. Im empfangenden Gerät gibt es eine Variable, die verfolgt, wie viele Segmente empfangen wurden, und wenn alle vier eintreffen, geht eine Bestätigung an das sendende Gerät, dass die gesamte Seite empfangen wurde. Wenn keine Bestätigung erfolgt (CRC stimmt nicht überein), wird die gesamte Seite erneut gesendet. Die Geschwindigkeit ist dabei sogar höher als bei der Übertragung über Kabel. Siehe:

Aber eigentlich sollte man eine bequeme Möglichkeit vorsehen, ein Kabel zum Hochladen von Sketches an die Geräte anzuschließen. Zum Beispiel könnte man einen solchen Schnittstellenwandler auf CP2102, wie im Foto, in das Gehäuse einbauen und so auf der Platine befestigen, dass er die Kraft beim Anschluss und Trennen des Micro-USB-Kabels aushält.

Es gibt auch einen 3,3-Volt-Spannungsregler (und wie er in einem Gerät mit 6-Volt-Stromversorgung angewendet werden kann - falls es einen ähnlichen Spannungsregler gibt, können zwei Dioden hinzugefügt werden, um automatisch auszuwählen, von welchem der beiden das Gerät gespeist wird). Alle drei LEDs auf der Schnittstellenwandlerplatine müssen entfernt werden, da sie sonst die Batterien zusätzlich belasten, wenn das Gerät von ihnen betrieben wird, und das Abfragen der Tastatur sowie die Arbeit mit dem Flash-Speicher über die SPI-Schnittstelle behindern.

Das Verfolgen des Ziels war sogar interessanter als dessen Erreichung (und das mit dem Bus muss nicht erwähnt werden). Der Autor hat viel Neues über Bootloader für AVR, Flash-Speicher mit SPI-Schnittstelle, das STK500-Protokoll und den Standard 802.15.4 gelernt.

Der gesamte übrige Code zusätzlich zur oben beschriebenen Bibliothek - hier, und er steht ebenfalls unter GPL v3. Der Twitter des Autors - hier.

Quelle: habr.com