Dit het alles begin met die skrywer wat 'n interessante toestel op die sekondêre mark gekoop het - Smart Response XE (). Dit is bedoel vir skole: elke student in die klas ontvang 'n toestel soortgelyk aan 'n elektroniese notaboek of 'n vertaler uit die negentigerjare, die onderwyser vra 'n vraag, en die studente tik die antwoorde op die sleutelborde van die toestelle, wat ontvang word via 'n radiokanaal (802.15.4) na 'n ontvanger wat aan die onderwyser se rekenaar gekoppel is.
Hierdie toestelle is etlike jare gelede gestaak, en wat skole vir $100-$200 elk gekoop het, verskyn nou op eBay vir $10 of minder. Die hardeware daar is baie geskik vir geeky eksperimente:
- 60 sleutel sleutelbord
- vertoon met 'n resolusie van 384×136, 2 bisse per pixel - soortgelyk aan BC, CGA, maar 4 nie kleure nie, maar gradasies van helderheid
- mikrobeheerder ATmega128RFA1 (128 kB flitsgeheue, 4 kB ROM, 16 kB RAM, 802.15.4 transceiver)
- eksterne (in verhouding tot die mikrobeheerder, nie die hele toestel nie) 1 megabit (128 kilogreep) flitsgeheue met SPI-koppelvlak
- kompartement vir 4 AAA-elemente.
Uit die naam van die mikrobeheerder is dit duidelik dat dit aan die AVR-familie behoort, wat beteken om die toestel Arduino-versoenbaar te maak is 'n meer as onbenullige taak ...
Van die nuus af die skrywer het uitgevind wat dit is (dieselfde skakel vertel jou waarheen om aan te sluit), met die geleentheid om speletjies vir Arduboy uit te voer:
Maar die skrywer is meer geïnteresseerd in die geleentheid om nie op die toestel te speel nie, maar om te studeer:
- flitsgeheue met seriële SPI-koppelvlak
- selflaailaaiers vir AVR
- standaard 802.15.4
Die skrywer het begin deur te skryf (GPL v3), wat jou toelaat om die skerm te inisialiseer, teks en reghoeke uit te voer en toegang tot SPI-flitsgeheue te kry. Toe begin hy met idees vorendag kom vir praktiese gebruik van die toestel: 'n VT-100-versoenbare sakterminaal, multiplayer-speletjies. Nadat hy drie toestelle herbou het, het hy besluit om hulle te "leer" om sketse "oor die lug" te ontvang. Wat nie net interessant sou wees nie, maar ook baie gerieflik: die toestelkas is moeilik om elke keer oop te maak, en onder die batterykompartement se deksel is daar net gate wat jou toelaat om 'n JTAG-programmeerder aan die bord te koppel.
Dit is genoeg om die Arduino selflaaiprogram op te laai, maar nie die skets nie - die reekspoort is nie daar gekoppel nie, so jy kan steeds nie klaarkom sonder om die kas oop te maak nie. Die TX0- en RX0-lyne van die eerste seriële poort word ook gekombineer met die stemlyne van die sleutelbordmatriks, naamlik dié wat die funksiesleutels aan die kante van die skerm ondersoek. Maar wat kan jy doen - die skrywer het dit gebou:
Hy het die JTAG-lyne soontoe gebring, en nou is dit nie nodig om die batterykompartement oop te maak nie. En sodat sketse opgelaai kon word, het ek albei seriële poorte aan dieselfde aansluiting gekoppel, en ook 'n skakelaar bygevoeg, want met die batterye geïnstalleer is dit fisies onmoontlik om die toestel op enige ander manier af te skakel.
Dit het nogal lank geneem om met 'n soldeerbout, 'n nutsmes en 'n gompistool te werk. Oor die algemeen is die oplaai van sketse "oor die lug" baie geriefliker; ons moet dringend iets hiervoor uitvind.
Arduino IDE gebruik die program om sketse op te laai . Dit is in wisselwerking met die mikrobeheerder deur die protokol te gebruik , wat jou toelaat om lêers in beide rigtings oor te dra. Dit is swak versoenbaar met kanale waar veranderlike vertragings, vervorming en dataverlies moontlik is. As iets in die reekskanaal loskom of ritsel, kan jy mal raak op soek na die oorsaak. Eenkeer het die skrywer 'n halwe dag lank gely totdat hy besef het dat die probleem 'n slegte kabel was, sowel as 'n wispelturige CP2102-koppelvlak-omskakelaar. Selfs 'n mikrobeheerder met 'n ingeboude koppelvlak-omskakelaar, byvoorbeeld ATmega32u4, kan soms so optree. Elke Arduino-gebruiker het opgemerk dat foute tydens die oplaai van sketse nie so skaars is nie. Soms verloop die opname goed, maar tydens 'n toetslees word 'n fout bespeur. Dit beteken nie dat daar 'n fout was tydens skryf nie - daar was 'n mislukking tydens lees. Stel jou nou voor dat wanneer jy "oor die lug" werk, dieselfde ding sal gebeur, maar baie meer dikwels.
Nadat die skrywer verskillende maniere probeer het om hierdie probleem te oorkom, het die skrywer die volgende uitgekom. Die toestel het 'n 128 KB-flitsgeheue met 'n SPI-koppelvlak - ons ontvang data oor die drade (onthou dat die skrywer reeds een toestel met 'n aansluiting aan die kant het), gebruik hierdie geheue as 'n buffer, en stuur die data oor die radio kanaal na 'n ander toestel. Hallo van Cybiko.
Nadat die kode geskryf is om met die radiokanaal te werk, sowel as die lettertipe, het die laaier langer as 4 kilogrepe geword. Daarom moes die HFUSE-waarde van 0xDA na 0xD8 verander word. Nou kan die selflaaiprogram tot 8 kilogrepe lank wees, en die beginadres is nou 0x1E000. Dit word in die Makefile weerspieël, maar moet ook in ag geneem word wanneer dit gevul word via avrdude.
Die 802.15.4-senderontvanger in die ATmega128RFA1 is oorspronklik ontwerp om met die protokol te werk , wat nogal ingewikkeld is, so die skrywer het besluit om eerder pakkies te stuur. Dit word in hardeware in die ATmega128RFA1 geïmplementeer, so min kode is nodig. Ook, vir eenvoud, het die skrywer besluit om 'n vaste kanaal te gebruik, sodat jy dit nie eers met die hand kan kies nie. Die 802.15.4-standaard ondersteun 16 kanale met nommers van 11 tot 26. Hulle is redelik vol, sommige oorvleuel ook WiFi-kanale (rooi is ZigBee-kanale, blou, groen en geel is WiFi).
Dit het geblyk dat kanale 15 en 26 die minste vatbaar is vir inmenging van WiFi.Die skrywer het die tweede daarvan gekies. Vrywaring: die vertaler weet nie of dit toegelaat word om ZigBee op hierdie manier te vereenvoudig nie. Miskien moet ons 'n bietjie meer programmering doen en dit heeltemal implementeer?
Op die eerste toestel is dit nodig om 'n eindige toestand masjien te implementeer wat data via die STK500 protokol oordra. Die boodskappe wat versend en ontvang is, is meestal selfversorgend, maar sommige is gekoppel aan dié wat vroeër deur die kanaal gegaan het. Beskrywing van die dialoog word gegee .
'n Belangrike komponent van hierdie dialoog is die oordrag van pakkies wat bedoel is om na die flitsgeheue van die bestemmingstoestel geskryf te word. Vir eenvoudige mikrobeheerders van die AVR-familie is die bladsygrootte 128 grepe, maar vir die ATmega128RFA1 is dit 256. En vir die flitsgeheue wat via die SPI-protokol gekoppel is, is dit dieselfde. Die program in die eerste toestel, wanneer 'n skets oplaai, dra dit nie onmiddellik na die tweede oor nie, maar skryf dit na hierdie geheue. Wanneer die Arduino IDE die korrektheid van die inskrywing kontroleer, word dit gestuur wat daar geskryf is. Nou moet ons die ontvangde data via radiokanaal na die tweede toestel oordra. Terselfdertyd vind oorskakeling van ontvang na versend en terug baie gereeld plaas. Die STK500-protokol is onverskillig teenoor vertragings, maar duld nie dataverlies nie (vreemd, maar daar is hierbo gesê dat vertragings ook data-oordrag beïnvloed). En verliese tydens draadlose transmissie is onvermydelik. Die ATmega128RFA1 het 'n ingeboude hardeware-implementering van herhaalde versoeke wanneer daar twyfel is oor die korrektheid van die oordrag, maar die skrywer het besluit om dieselfde in sagteware self te implementeer. Hy het 'n protokol ontwikkel waarin baie meer data op die een manier vloei as die ander.
Dit is nie perfek nie, maar dit werk. Die bladsy van 256 grepe word in vier segmente verdeel, wat elk as 'n pakkie oor die lug versend word. 'n Pakkie kan tot 125 grepe data plus een grepe vir lengte en twee grepe vir CRC hou. Dus word fragmente van 64 grepe lank saam met bladsy- en segmentnommers (van 0 tot 3) daar geplaas. Die ontvangstoestel het 'n veranderlike wat dit toelaat om op te spoor hoeveel segmente ontvang is, en wanneer al vier arriveer, ontvang die stuurtoestel bevestiging dat die hele bladsy ontvang is. Geen bevestiging (CRC stem nie ooreen nie) - stuur die hele bladsy weer. Die spoed is selfs groter as wanneer dit via kabel uitgesaai word. Sien:
Maar in die algemeen sou dit nodig wees om 'n gerieflike manier te bied om die kabel aan die toestelle te koppel vir die oplaai van sketse en daardeur. Plaas byvoorbeeld binne so 'n koppelvlakomskakelaar op die CP2102, soos op die foto, en plak dit op die bord vas sodat dit die krag kan weerstaan wanneer die Mikro USB-kabel aan- en ontkoppel word.
Dit het ook 'n 3,3-volt-stabilisator (en hoe om dit te gebruik in 'n toestel met 'n 6-volt-kragbron - as dit net dieselfde stabiliseerder het, en jy kan twee diodes byvoeg om outomaties te kies watter van hulle die toestel sal aandryf) . Al drie LED's moet losgesoldeer word van die koppelvlakomskakelaarbord, anders sal hulle die batterye bykomend laai wanneer hulle daarop werk, en ook inmeng met sleutelbordpeiling en werk met flitsgeheue met 'n SPI-koppelvlak.
Om 'n doel na te streef, was selfs interessanter as om dit te bereik (en het nie daardie grap oor die bus nodig nie). Die skrywer het baie geleer oor AVR-selflaaiers, SPI-flitsgeheue, die STK500-protokol en die 802.15.4-standaard.
Alle ander kode bykomend tot die biblioteek hierbo beskryf is − , en dit is ook onder GPL v3. Skrywer se Twitter - .
Bron: will.com