
Alles begann mit dem Erwerb eines interessanten GerĂ€ts auf dem SekundĂ€rmarkt â dem Smart Response XE (). Es ist fĂŒr Schulen gedacht: Jeder SchĂŒler in der Klasse erhĂ€lt ein GerĂ€t, das wie ein elektronisches Notizbuch oder ein Ăbersetzer aus den 90ern aussieht. Der Lehrer stellt eine Frage, und die SchĂŒler geben ihre Antworten ĂŒber die Tastaturen der GerĂ€te ein, die per Funk (802.15.4) an einen EmpfĂ€nger verbunden sind, der am Computer des Lehrers angeschlossen ist.
Die UnterstĂŒtzung dieser GerĂ€te wurde vor einigen Jahren eingestellt, und das, was Schulen fĂŒr 100-200 Dollar pro StĂŒck gekauft haben, wird jetzt auf eBay fĂŒr 10 Dollar oder weniger angeboten. Die Hardware eignet sich hervorragend fĂŒr geekige Experimente:
- 60-Tasten-Tastatur
- Display mit einer Auflösung von 384Ă136, 2 Bit pro Pixel â Ă€hnlich wie bei BK, CGA, aber 4 nicht Farben, sondern Helligkeitsstufen
- Mikrocontroller ATmega128RFA1 (128 kB Flash-Speicher, 4 kB EEPROM, 16 kB RAM, Transceiver nach Standard 802.15.4)
- externer Flash-Speicher von 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 die Aufgabe, ein Arduino-kompatibles GerĂ€t zu erstellen, mehr als trivial machtâŠ
Aus der Nachricht auf erfuhr der Autor, dass das (in diesem Link wird auch erklĂ€rt, wo was angeschlossen wird), sodass Spiele fĂŒr Arduboy gestartet werden können:

Aber der Autor interessiert sich weniger dafĂŒr, auf dem GerĂ€t zu spielen, als fĂŒr das Lernen:
- Flash-Speicher mit SPI-Schnittstelle
- Bootloader fĂŒr AVR
- der Standard 802.15.4
Der Autor begann mit dem Schreiben (GPL v3), das die Initialisierung des Displays, das Ausgeben von Text und Rechtecken sowie den Zugriff auf den Flash-Speicher mit SPI-Schnittstelle ermöglicht. AnschlieĂend begann er, Ideen fĂŒr die praktische Nutzung des GerĂ€ts zu entwickeln: ein tragbares, VT-100-kompatibles Terminal, Mehrspieler-Spiele. Nachdem er drei GerĂ€te umgebaut hatte, beschloss er, sie zu «lehren», Sketche «over-the-air» zu empfangen. Das wĂ€re nicht nur interessant, sondern auch sehr praktisch: das GehĂ€use des GerĂ€ts jedes Mal zu öffnen, ist schwierig, und unter dem Deckel des Batteriefachs befinden sich nur Ăffnungen, die den Anschluss eines JTAG-Programmers an das Board ermöglichen.

Das reicht aus, um den Arduino-Bootloader zu flashen, aber nicht den Sketch â der serielle Port ist nicht herausgefĂŒhrt, ohne das GehĂ€use zu öffnen, kommt man daher nicht weiter. AuĂerdem sind die TX0- und RX0-Leitungen des ersten seriellen Ports mit den Leitungen zur Abfrage der Tastaturmatrix kombiniert, und zwar mit denen, die fĂŒr die Abfrage der Funktionstasten an den Seiten des Displays zustĂ€ndig sind. Aber was soll man machen â der Autor hat Folgendes konstruiert:

Dort hat er die JTAG-Leitungen herausgefĂŒhrt, und jetzt ist es nicht mehr notwendig, das Batteriefach zu öffnen. Damit man auch Sketches hochladen kann, hat er auch beide seriellen Ports an denselben Anschluss gelegt und einen Schalter hinzugefĂŒgt, da das GerĂ€t mit eingesetzten Batterien physisch nicht anders abgeschaltet werden kann.
Es war notwendig, recht lange mit Lötkolben, Cuttermesser und HeiĂklebepistole zu arbeiten. Im Allgemeinen ist es deutlich bequemer, Sketches âĂŒber die Luftâ hochzuladen, man muss dringend etwas in dieser Hinsicht erfinden.
Die Arduino IDE verwendet fĂŒr das Hochladen von Sketches das Programm . Es kommuniziert mit dem Mikrocontroller ĂŒber das Protokoll , der den beidseitigen Dateitransfer ermöglicht. Er ist schlecht kompatibel mit KanĂ€len, in denen variable Latenzen, Verzerrungen und Datenverluste auftreten können. Wenn in einem seriellen Kanal etwas knistert oder andere Störungen auftreten, kann man verrĂŒckt werden, auf die Ursache zu kommen. Einmal hat der Autor ein halbes Tag geflucht, bis ihm klar wurde, dass es an einem schlechten Kabel und einem launischen CP2102-Interfacewandler lag. Selbst ein Mikrocontroller mit integriertem Interfacewandler, wie zum Beispiel der ATmega32u4, kann sich manchmal so âbenehmenâ. Jeder Arduino-Nutzer hat bemerkt, dass Programmierfehler beim Hochladen von Sketchen alles andere als selten sind. Manchmal verlĂ€uft der Schreibvorgang reibungslos, doch beim anschlieĂenden Lesen wird ein Fehler gefunden. Das bedeutet nicht, dass bei der Aufnahme ein Fehler aufgetreten ist â der Fehler trat beim Lesen auf. Und jetzt stellen Sie sich vor, dass im âDrahtlosâ-Betrieb genau dasselbe, jedoch viel hĂ€ufiger passiert.
Nachdem der Autor verschiedene AnsĂ€tze zur Lösung dieses Problems ausprobiert hat, hat er Folgendes ausgeklĂŒgelt. Das GerĂ€t verfĂŒgt ĂŒber 128 Kilobyte Flash-Speicher mit SPI-Schnittstelle â Daten werden ĂŒber Kabel empfangen (wir erinnern uns, dass der Autor bereits ein GerĂ€t mit einer Anschlussbuchse hat), wir nutzen diesen Speicher als Puffer und senden die Daten ĂŒber das Funkkanal an ein anderes GerĂ€t. Ein GruĂ von Cybiko.
Nach dem Schreiben des Codes zur Bedienung des Funkkanals und der Schriftart wurde der Bootloader lĂ€nger als 4 Kilobyte. Daher musste der Wert von HFUSE von 0xDA auf 0xD8 geĂ€ndert werden. Jetzt 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 berĂŒcksichtigt werden. mit avrdude.
Der 802.15.4 Sender/EmpfĂ€nger im ATmega128RFA1 ist ursprĂŒnglich fĂŒr den Betrieb mit dem Protokoll vorgesehen. , der ziemlich komplex ist, daher entschied sich der Autor, stattdessen einfach Pakete zu ĂŒbertragen. Dies ist hardwareseitig im ATmega128RFA1 implementiert, sodass nur wenig Code benötigt wird. Um es zudem zu vereinfachen, entschied sich der Autor, einen festen Kanal zu verwenden, ohne die Möglichkeit zu bieten, ihn sogar manuell auszuwĂ€hlen. Der Standard 802.15.4 unterstĂŒtzt 16 KanĂ€le mit Nummern von 11 bis 26. Diese sind stark ausgelastet, einige ĂŒberlappen auch mit WiFi-KanĂ€len (ZigBee-KanĂ€le sind rot markiert, WiFi-KanĂ€le blau, grĂŒn und gelb).

Es stellte sich heraus, dass die KanĂ€le 15 und 26 am wenigsten anfĂ€llig fĂŒr Störungen durch WiFi sind. Der Autor wĂ€hlte den zweiten. Hinweis: Der Ăbersetzer weiĂ nicht, ob es erlaubt ist, ZigBee auf diese Weise zu vereinfachen. Vielleicht sollte man noch etwas programmieren und es vollstĂ€ndig implementieren?
Auf dem ersten GerĂ€t muss ein Zustandsautomat implementiert werden, der Daten ĂŒber das STK500-Protokoll ĂŒbertrĂ€gt. Im GroĂen und Ganzen sind die gesendeten und empfangenen Nachrichten eigenstĂ€ndig, aber einige hĂ€ngen von zuvor ĂŒber den Kanal gesendeten ab. Eine Beschreibung des Dialogs ist angefĂŒhrt. .
Ein wichtiger Aspekt dieses Dialogs ist die Ăbertragung von Paketen, die zur Speicherung im Flash-Speicher des ZielgerĂ€ts bestimmt sind. Bei einfachen Mikrocontrollern der AVR-Familie betrĂ€gt die SeitenkapazitĂ€t 128 Byte, wĂ€hrend sie bei dem ATmega128RFA1 256 Byte betrĂ€gt. Das ist auch der Fall fĂŒr den Flash-Speicher, der ĂŒber das SPI-Protokoll angeschlossen wird. Wenn das Programm im ersten GerĂ€t den Sketch hochlĂ€dt, wird dieser nicht sofort an das zweite GerĂ€t ĂŒbertragen, sondern zunĂ€chst in diesen Speicher geschrieben. Wenn die Arduino IDE die Richtigkeit der Speicherung ĂŒberprĂŒft, werden die aufgenommenen Daten gesendet. Jetzt mĂŒssen die empfangenen Daten ĂŒber den Funkkanal an das zweite GerĂ€t ĂŒbertragen werden. Dabei erfolgt der Wechsel vom Empfang zum Senden und zurĂŒck recht hĂ€ufig. Das STK500-Protokoll ist gegenĂŒber Verzögerungen gleichgĂŒltig, toleriert jedoch keinen Datenverlust (es ist komisch, dass zuvor erwĂ€hnt wurde, dass Verzögerungen bei der DatenĂŒbertragung ebenfalls Auswirkungen haben). Datenverluste bei der drahtlosen Ăbertragung sind jedoch unvermeidlich. Im ATmega128RFA1 gibt es eine hardwareseitige Implementierung fĂŒr erneute Anfragen im Fall von Zweifeln an der Ăbertragungsgenauigkeit, doch der Autor entschied sich, dies selbst programmatisch zu realisieren. Er entwickelte ein Protokoll, bei dem in eine Richtung deutlich mehr Daten ĂŒbertragen werden als in die andere.
Es ist nicht perfekt, aber alles funktioniert. Eine 256-Byte-Seite wird in vier Segmente unterteilt, von denen jedes ĂŒber einen Funkkanal als Paket ĂŒbertragen wird. Ein Paket fasst bis zu 125 Byte Daten plus ein Byte fĂŒr die LĂ€nge und zwei fĂŒr die CRC. Die Fragmente mit einer LĂ€nge von 64 Byte zusammen mit den Seiten- und Segmentnummern (von 0 bis 3) werden dort untergebracht. Im EmpfangsgerĂ€t ist eine Variable vorgesehen, die es ermöglicht, die Anzahl der empfangenen Segmente zu verfolgen. Sobald alle vier ankommen, wird an das sendende GerĂ€t eine BestĂ€tigung gesendet, dass die gesamte Seite empfangen wurde. Gibt es keine BestĂ€tigung (CRC stimmt nicht ĂŒberein) â wird die gesamte Seite erneut gesendet. Die Geschwindigkeit ist sogar höher als bei der Ăbertragung ĂŒber Kabel. Siehe:

TatsĂ€chlich sollte man einen praktischen Weg vorsehen, um GerĂ€te ĂŒber ein Kabel fĂŒr das Hochladen von Sketchen anzuschlieĂen. Zum Beispiel könnte man einen solchen CP2102-Schnittstellenwandler wie auf dem Foto innen anbringen und so an der Platine befestigen, dass er den ZugkrĂ€ften beim Ein- und Ausstecken des Micro-USB-Kabels standhĂ€lt.

Es gibt auch einen 3,3-Volt-Spannungsregler (und wie man ihn in einem GerĂ€t mit 6-Volt-Stromversorgung verwendet â vorausgesetzt, es gibt einen solchen Regler, und man kann zwei Dioden hinzufĂŒgen, um automatisch auszuwĂ€hlen, von welchem er die Versorgung beziehen soll). Von der Schnittstellenplatine mĂŒssen alle drei LEDs entfernt werden, da sie sonst die Batterien zusĂ€tzlich belasten, wĂ€hrend sie davon betrieben werden, und die Abfrage der Tastatur sowie die Arbeit mit dem Flash-Speicher ĂŒber das SPI-Interface stören können.
Das Verfolgen des Ziels stellte sich als sogar interessanter heraus als dessen Erreichung (und das ist kein Witz ĂŒber den Bus). Der Autor hat viel ĂŒber Bootloader fĂŒr AVR, Flash-Speicher mit SPI-Interface, das STK500-Protokoll und den Standard 802.15.4 gelernt.
Der gesamte restliche Code, zusĂ€tzlich zu der oben beschriebenen Bibliothek â , und dieser steht ebenfalls unter GPL v3. Der Twitter-Account des Autors â .
Quelle: habr.com
