Het begon allemaal toen de auteur een interessant apparaat op de secundaire markt kocht: Smart Response XE (). Het is bedoeld voor scholen: elke leerling in de klas krijgt een apparaat dat lijkt op een elektronisch notitieboekje of een vertaler uit de jaren negentig, de leraar stelt een vraag en de leerlingen typen de antwoorden op de toetsenborden van de apparaten, die via een radiokanaal (802.15.4) naar een ontvanger die is aangesloten op de pc van de docent.
Deze apparaten zijn enkele jaren geleden niet meer leverbaar, en wat scholen voor $100-$200 per stuk kochten, verschijnt nu op eBay voor $10 of minder. De hardware daar is zeer geschikt voor nerdexperimenten:
- Toetsenbord met 60 toetsen
- beeldscherm met een resolutie van 384×136, 2 bits per pixel - vergelijkbaar met BC, CGA, maar 4 geen kleuren, maar gradaties van helderheid
- microcontroller ATmega128RFA1 (128 kB flashgeheugen, 4 kB ROM, 16 kB RAM, 802.15.4 transceiver)
- extern (in relatie tot de microcontroller, niet het hele apparaat) 1 megabit (128 kilobyte) flashgeheugen met SPI-interface
- compartiment voor 4 AAA-elementen.
Uit de naam van de microcontroller blijkt duidelijk dat deze tot de AVR-familie behoort, wat betekent dat het Arduino-compatibel maken van het apparaat een meer dan triviale taak is...
Vanaf het nieuws de auteur heeft ontdekt wat het is (dezelfde link vertelt je wat je waar moet aansluiten), met de mogelijkheid om games voor Arduboy uit te voeren:
Maar de auteur is meer geïnteresseerd in de mogelijkheid om niet op het apparaat te spelen, maar om te studeren:
- flashgeheugen met seriële SPI-interface
- bootloaders voor AVR
- standaard 802.15.4
De auteur begon met schrijven (GPL v3), waarmee u de weergave kunt initialiseren, tekst en rechthoeken kunt uitvoeren en toegang kunt krijgen tot SPI-flashgeheugen. Toen begon hij ideeën te bedenken voor praktisch gebruik van het apparaat: een VT-100-compatibele pocketterminal, multiplayer-spellen. Nadat hij drie apparaten had herbouwd, besloot hij ze te ‘leren’ schetsen ‘via de ether’ te ontvangen. Wat niet alleen interessant zou zijn, maar ook erg handig: de behuizing van het apparaat is elke keer moeilijk te openen en onder het deksel van het batterijcompartiment zitten alleen gaten waarmee je een JTAG-programmeur op het bord kunt aansluiten.
Dit is voldoende om de Arduino-bootloader te uploaden, maar niet de schets - de seriële poort is daar niet aangesloten, dus je kunt nog steeds niet zonder de behuizing te openen. Ook worden de TX0- en RX0-lijnen van de eerste seriële poort gecombineerd met de pollinglijnen van de toetsenbordmatrix, namelijk de lijnen die de functietoetsen aan de zijkanten van het scherm pollen. Maar wat kun je doen - de auteur heeft dit gebouwd:
Hij heeft de JTAG-lijnen daarheen gebracht en nu is het niet nodig om het batterijcompartiment te openen. En zodat schetsen konden worden geüpload, heb ik beide seriële poorten op dezelfde connector aangesloten en ook een schakelaar toegevoegd, omdat het met de geïnstalleerde batterijen fysiek onmogelijk is om het apparaat op een andere manier uit te schakelen.
Het kostte nogal wat tijd om met een soldeerbout, een mes en een lijmpistool te werken. Over het algemeen is het veel handiger om schetsen “via de ether” te uploaden, hier moeten we dringend iets voor verzinnen.
Arduino IDE gebruikt het programma om schetsen te uploaden . Het communiceert met de microcontroller via het protocol , waarmee u bestanden in beide richtingen kunt overbrengen. Het is slecht compatibel met kanalen waar variabele vertragingen, vervorming en gegevensverlies mogelijk zijn. Als er iets losraakt of ruist in het seriële kanaal, kun je helemaal los gaan op zoek naar de oorzaak. Eens leed de auteur een halve dag totdat hij zich realiseerde dat het probleem een slechte kabel was, evenals een wispelturige CP2102-interfaceconverter. Zelfs een microcontroller met een ingebouwde interfaceconverter, bijvoorbeeld ATmega32u4, kan soms zo werken. Elke Arduino-gebruiker heeft gemerkt dat fouten bij het uploaden van schetsen niet zo zeldzaam zijn. Soms gaat de opname goed, maar tijdens een testuitlezing wordt er een fout ontdekt. Dit betekent niet dat er een fout is opgetreden tijdens het schrijven; er is een fout opgetreden tijdens het lezen. Stel je nu voor dat bij ‘over the air’ hetzelfde zal gebeuren, maar veel vaker.
Nadat hij verschillende manieren had geprobeerd om dit probleem op te lossen, kwam de auteur met het volgende. Het apparaat heeft een flashgeheugen van 128 KB met een SPI-interface - we ontvangen gegevens via de draden (onthoud dat de auteur al één apparaat heeft met een connector aan de zijkant), gebruiken dit geheugen als buffer en verzenden de gegevens via de radio kanaal naar een ander apparaat. Hallo van Cybiko.
Na het schrijven van de code om met het radiokanaal te werken, evenals het lettertype, werd de lader langer dan 4 kilobytes. Daarom moest de HFUSE-waarde worden gewijzigd van 0xDA in 0xD8. Nu kan de bootloader maximaal 8 kilobytes lang zijn en het startadres is nu 0x1E000. Dit zie je terug in de Makefile, maar hier moet ook rekening mee gehouden worden bij het vullen via avrdude.
De 802.15.4-transceiver in de ATmega128RFA1 is oorspronkelijk ontworpen om te werken met behulp van het protocol , wat behoorlijk ingewikkeld is, dus besloot de auteur om in plaats daarvan alleen maar pakketten te verzenden. Dit is hardwarematig geïmplementeerd in de ATmega128RFA1, waardoor er weinig code nodig is. Om het eenvoudig te houden heeft de auteur besloten een vast kanaal te gebruiken, zodat je dit zelfs niet handmatig kunt selecteren. De 802.15.4-standaard ondersteunt 16 kanalen met nummers van 11 tot 26. Ze zijn behoorlijk druk, sommige overlappen ook WiFi-kanalen (rood zijn ZigBee-kanalen, blauw, groen en geel zijn WiFi).
Het bleek dat de kanalen 15 en 26 het minst gevoelig zijn voor interferentie van WiFi, de auteur koos voor de tweede. Disclaimer: de vertaler weet niet of het op deze manier toegestaan is om ZigBee te vereenvoudigen. Misschien moeten we wat meer programmeren en het volledig implementeren?
Op het eerste apparaat is het nodig om een eindige toestandsmachine te implementeren die gegevens verzendt via het STK500-protocol. Voor het grootste deel zijn de verzonden en ontvangen berichten zelfvoorzienend, maar sommige zijn gekoppeld aan de berichten die eerder door het kanaal zijn gegaan. Er wordt een beschrijving van de dialoog gegeven .
Een belangrijk onderdeel van deze dialoog is de verzending van pakketten die bedoeld zijn om naar het flashgeheugen van het bestemmingsapparaat te worden geschreven. Voor eenvoudige microcontrollers uit de AVR-familie is de paginagrootte 128 bytes, maar voor de ATmega128RFA1 is dit 256. En voor het flashgeheugen dat via het SPI-protocol is aangesloten, is het hetzelfde. Het programma op het eerste apparaat brengt deze bij het uploaden van een schets niet onmiddellijk over naar het tweede, maar schrijft deze naar dit geheugen. Wanneer de Arduino IDE de juistheid van de invoer controleert, wordt verzonden wat daar is geschreven. Nu moeten we de ontvangen gegevens via een radiokanaal naar het tweede apparaat verzenden. Tegelijkertijd komt het vaak voor dat er wordt overgeschakeld van ontvangen naar zenden en terug. Het STK500-protocol staat onverschillig tegenover vertragingen, maar tolereert geen gegevensverlies (vreemd, maar hierboven werd gezegd dat vertragingen ook de gegevensoverdracht beïnvloeden). En verliezen tijdens draadloze transmissie zijn onvermijdelijk. De ATmega128RFA1 heeft een ingebouwde hardware-implementatie van herhaalde verzoeken wanneer er twijfel bestaat over de juistheid van de overdracht, maar de auteur besloot hetzelfde zelf in de software te implementeren. Hij ontwikkelde een protocol waarbij veel meer data de ene kant op stroomt dan de andere.
Het is niet perfect, maar het werkt. De pagina van 256 bytes is verdeeld in vier segmenten, die elk als pakket via de ether worden verzonden. Een pakket kan maximaal 125 bytes aan gegevens bevatten plus één byte voor lengte en twee bytes voor CRC. Dus fragmenten van 64 bytes lang samen met pagina- en segmentnummers (van 0 tot 3) worden daar geplaatst. Het ontvangende apparaat heeft een variabele waarmee kan worden bijgehouden hoeveel segmenten zijn ontvangen, en wanneer ze alle vier aankomen, ontvangt het verzendende apparaat een bevestiging dat de hele pagina is ontvangen. Geen bevestiging (CRC kwam niet overeen) - stuur de hele pagina opnieuw. De snelheid is zelfs groter dan bij verzending via de kabel. Zien:
Maar over het algemeen zou het nodig zijn om een gemakkelijke manier te bieden om de kabel aan te sluiten op de apparaten voor het uploaden van schetsen en er doorheen. Plaats bijvoorbeeld een dergelijke interface-converter op de CP2102, zoals op de foto, en lijm deze op het bord, zodat deze de kracht kan weerstaan bij het aansluiten en loskoppelen van de micro-USB-kabel.
Het heeft ook een stabilisator van 3,3 volt (en hoe je deze kunt gebruiken in een apparaat met een voeding van 6 volt - als het maar dezelfde stabilisator heeft, en je kunt twee diodes toevoegen om automatisch te selecteren welke het apparaat van stroom zal voorzien) . Alle drie de LED's moeten van de interface-converterkaart worden losgemaakt, anders zullen ze de batterijen extra belasten als ze erop worden gebruikt, en ook de polling van het toetsenbord verstoren en werken met flash-geheugen met een SPI-interface.
Een doel nastreven bleek nog interessanter dan het behalen ervan (en heb dat grapje over de bus niet nodig). De auteur heeft veel geleerd over AVR-bootloaders, SPI-flashgeheugen, het STK500-protocol en de 802.15.4-standaard.
Alle andere code naast de hierboven beschreven bibliotheek is − , en het valt ook onder GPL v3. Twitter van de auteur - .
Bron: www.habr.com