Kako zagotoviti zanesljivo delovanje? – AVR, ESP, PIC in drugi, ko gre zares (9)

Koncept dober, delovanje nezadostno!
Eden na videz preprostih problemov je detekcija gibanja oseb v prostoru. Za marsikoga so še najbolj zanesljivi staromodni analogni senzorji z vgrajenim elektronskim vezjem s tipalom in preklopnim relejem, pri katerih občutljivost in trajanje vklopa po zaznavi gibanja nastavljamo s trimerji. Saj ne da omenjenega ne bi mogli bolje in zanesljiveje sprogramirati v ugnezdeni programski opremi mikrokontrolerja, a smo pri njenem načrtovanju pogosto premalo analitični in pozabimo na številne marginalne možnosti in varovalke, ki so implicitno ugnezdene v dobro preizkušeno iz testirano serijsko analogno vezje. Mikrokontroler z ugnezdeno programsko opremo ni čudežna rešitev vseh problemov z zaznavanjem gibanja, ampak samo drug način za njihovo reševanje, ki je lahko uspešnejši samo z dobrim načrtovanjem in dobro implementacijo.

Tudi izgradnja elektronike za krmiljenje dronov predstavlja enega izmed težjih problemov, ne toliko zato, ker dron z močnimi elektromotorji in baterijami ne bi mogel z lahkoto poleteti, temveč zato ker se pri kakršnihkoli težavah z delovanje elektronskih vezij tudi z lahkoto zruši in raztrešči po tleh. Pa ne pišem o napakah pri upravljanju, ampak o napakah v elektroniki in njeni programski opremi.

Pred meseci sem na mini dron-helikopterček, ki z 3,7-voltno litijevo baterijo tehta vsega 43 gramov, obesil še ESP32-CAM. Pa mislite, da je delovalo? Z dodatno obtežitvijo 11 gramov je bil dron precej blizu maksimalne obremenitve, pri kateri še lahko dovolj hitro pridobiva višino. Zato je bilo več kot očitno, da se bo morala napajati kar iz dronove baterije. A delovalo je le dokler, nisem zagnal motorjev. Potem mrk, ne glede na to, ali je imel ESP32-CAM vklopljen WiFi, ali ne..

A to ni edini primer! Ko sem se pred dvema letoma in pol na osnovi ESP32 lotil izdelave spletnega radija (SE287), v začetku ni dobro deloval, saj sem zaradi večje varnosti pa tudi v izogib motnjam zaradi neštetih WiFi omrežij v naši soseski dodal še modul za povezavo z ožičenim nternetom, zaradi česar sem moral v precejšnji meri nadgraditi ugnezdeno programsko opremo.

Potem smo dobili korona virus, zaradi katerega so se morali naši otroci šolati na daljavo. Tako je spletni radio čez noč dobil novo ugnezdeno programsko opremo in postal usmerjevalnik med WiFi in ožičenim internetom. A treba je bilo narediti še nešteto popravkov vzorčne Espressif Systemsove programske kode, da je začel naposled solidno sodelovati z Raspberry Pi 3 pri šolanju na daljavo. A svoje WiFi zmogljivosti so okrepili tudi sosedje in je na koncu vsaj pri nas doma zmagal ožičeni internet, na zato, ker prek WiFi nikakor ne bi šlo, ampak zato, ker je ožičeni dostop hitrejši in veliko manj občutljiv.

Skratka, na nezanesljivost delovanja naprave lahko vplivajo notranji ali zunanji dejavniki, pomembno je, da jih predvidimo tudi v programski in strojni opremi.

Zanesljivo zaznavanje oseb v prostoru
Upoštevati moramo marsikaj, denimo polje zaznavanja tipala, šum tipala in možnost odpovedi delovanja tipala ali prekinitve njegove podatkovne povezave z mikrokontrolerjem ter spreminjanje razmer v prostoru, v katerem je lahko poleg ljudi še kaka naprava s toplotnim odtisom. Praviloma počasno spreminjanje toplotnega ozadja ne bi smemo povzročiti zaznava gibanja, lahko pa spremeni občutljivost tipala, zato se mu moramo na primer bistveno bolj približati kot običajno ali obratno.
Programska oprema mora vse našteto upoštevati in se sproti prilagajati. Šume tipala lahko odpravimo z zakasnilnimi vezji in nizkoprepustnimi frekvenčnimi filtri, ki jih v programski opremi realiziramo s programskimi funkcijami za povprečenje in natančnim merjenjem časovnih intervalov s časovniki.

V preteklem nadaljevanju v SE305 smo pri reševanju vklopa in izklopa zaslona vremenske postaje glede na zaznavo gibanja v prostoru predpostavili, da tipalo zanesljivo zazna gibanje v prostoru, zato se lahko zaslon vklopi takoj in ostane vklopljen določen časovni interval (npr. 2 minuti), vendar se izkaže, da se včasih nepričakovano pojavi vlak impulzov z razmikom nekaj sekund tudi, ko ni nikogar v sobi in tako je zaslon prižgan tudi čez noč, ko bi moral biti ugasnjen.

Prvi ukrep je vgradnja povprečenja izmerjenih vrednosti s tipala v kratkem časovnem intervalu (npr. 100 ms), tako ena sama vrednost 1 ali vrednost 0 ne more vplivati. Namesto povprečenja lahko uporabimo tudi druga pravila, denimo kolikokrat se lahko v časovnem intervalu pojavi vrednost 0, da je interval še upoštevamo kot zaznavo gibanja, in obratno, koliko vrednosti 1 je lahko največ v časovnem intervalu meritve, da smatramo, da gibanja ni. Poglejmo še implementacijo omenjene programske kode:

if(digitalRead(PIR)){
PIR_1++;
} else {
PIR_0++;
}
PIR_cnt=PIR_1+PIR_0;
if(PIR_cnt>=PIR_samp_size){
if(PIR_1>PIR_min_1){
PIR_avg=1;
} else {
PIR_avg=0;
}
if(PIR_0>PIR_max_0){
PIR_avg=0;
}
PIR_0=0;
PIR_1=0;
}

Kot vidimo, smo za štetje vrednosti 0 in vrednosti 1 v časovnem intervalu, ki smo ga opredelili kar z velikostjo vzorca PIR_samp_size (vsaj kakih 100 vzorcev), uporabili števca PIR_1 in PIR_0. Ob koncu časovnega intervala se odločamo, katero vrednost dobi spremenljivka PIR_avg, ki jo nato uporabimo za prižiganje in ugašanje zaslona, ki je odvisno od vrednosti spremenljivke PIR_status:

if(PIR_avg){
PIR_start_ts=millis(); 
if(!PIR_status){
PIR_status=true; 
PIR_log();
}
} else {
if(PIR_status){
if((uint32_t)((millis())-PIR_start_ts)>PIR_ms){ 
PIR_status=false; 
PIR_log(); 
} 
}
}

Kot vidimo, začnemo meriti čas vsakokrat, ko ima PIR_avg vrednost 1, ko hkrati tudi PIR_status dobi vrednost 1, kar v nadaljevanju kode (SE305) pozroči vklop OLED prikazovalnika. Ko ima PIR_avg vrednost 0, počakamo še nekaj sekund, preden dobi PIR_status vredost 0 in sproži sekvenco za ugašanje OLED prikazovalnik. Ugašanje je narejeno konzervativno, saj želimo, da se prikazovalnik ugasne le potem, ko v prostoru že nekaj časa ni zaznanega gibanja.

Odpravimo težave z napajanjem
Baterijsko napajanje predstavlja pluse in minuse, saj lahko po eni strani napravo uporabljamo izven domačega okolja in tudi takrat, ko zmanjka elektrike, po drugi pa potrebujemo krmilnik polnjenja, ki skrbi za stalno napolnjenost baterij. V vozilu lahko napravo povežemo tudi prek 12-voltne vtičnice. A tu se rado zaplete, saj je bila vtičnica v začetkih avtomobilizma namenjena predvsem električnemu vžigalniku za cigarete, zato vtikač z združljivim priključkom med vožnjo iz nje med tresenjem nemalokrat izpade, napajanje pa se pri večini avtomobilov prekine tudi, ko zaganjamo motor. Odlična rešitev je, če lahko napravi dodamo lastno polnilno baterijo, kot jo imajo denimo navigacijske naprave, ki jih lahko uporabljamo v vozilih ali v plovilih. A v tem primeru moramo napetostnemu regulatorju dodati še regulator polnjenje litijeve ali druge akumulatorske baterije.

Kaj pa ko zaradi nihanja napajalne napetosti naprave pogosto preneha delovati? Denimo, nihanja napajalne napetosti baterije drona ali robotskega vozila ne moremo v celoti predvideti, saj je to odvisno tudi od pogojev letenja, oziroma vožnje po terenu. Ena izmed možnosti je uporaba akumulatorske baterije s sorazmerno visoko napajalno napetostjo, tako da napetostna nihanja zaradi elektromotornih pogonov ne vplivajo na delovanje krmilne elektronike. Tak pristop smo uporabili pri robotskem traktorčku, o katerem lahko več preberete v 3. nadaljevanju v SE299.

Vendar pa to še posebej pri dronih vedno ne gre, saj je potrebno težo baterije zmanjšati na minimum. Tu si pomagamo z zmogljivejšim in bolje stabiliziranim napetostnim regulatorjem, ki je zaradi zmogljivejših kondenzatorjev resda nekoliko težji ob običajnega, a še vedno veliko lažji od dodatne baterije, ki bi napajala zgolj krmilno elektroniko.

Dodatno lahko zanesljivost delovanja povečamo na ravneh ugnezdene programske opreme in strojne opreme. Veliko sodobnih mikrokontrolerjev lahko meri lastno napajalno napetost. Ko slednja pade pod prag zanesljivega delovanja (t.i. brownout voltage), se preklopijo v samoohranitveni način delovanja, tako da ohranjajo le še najnujnejše funkcije, obenem pa preko kontrolnih LED ali zaslona uporabnika obvestijo o težavah z napajanjem, oziroma o izpraznjenosti baterije.

Preprečevanje, odkrivanje okvar med delovanjem in zasilna zaustavitev
Letenje in terenska vožnja zaradi morebitnih tresljajev in udarcev vsekakor nista prijazna do drona ali robotskega vozila. Zato plošča za prototipiranje vsekakor ne more biti del zares uporabnega izdelka. Potrebujemo dobro sestavljeno tiskano vezje s kakovostnimi in zanesljivimi zunanjimi žičnimi povezavami. Pri tem moramo upoštevati, na primer, da se med premikanjem vozila ali letalnika lahko slabo pritrjena žica ali neprimeren konektor sname iz s tem onemogoči delovanje naprave. Po drugi strani, lahko premalo vzdržljiv konektor ali nepravilno uporabljen konektor razpade že po nekaj desetkratni uporabi.

Prav to se mi je zgodilo pri že omenjenem helikopterskem dronu, na katerega sem se sekundnim lepilom prilepil doma izdelano enovrstično vtičnico za napajanje ESP32-CAM modula. Vtičnica je razpadla, saj kontakte z zadnje strani nisem prispajkal na tiskano vezje. Pri drugi različici vtičnice sem namesto tega uporabil majhen košček tiskanega za prototipiranje, s katerim sem povezal kontakte.

Tudi strojno opremo in ugnezdeno programsko opremo moramo načrtovati tako, da upoštevamo tudi možnost pretrganja določenih napajalnih, podatkovnih ali kontrolnih povezav, ali njihovega nezanesljivega delovanja. Pri večjih porabnikih, kot so motorni pogoni, lahko za preverjanje delovanja uporabljamo elektronske merilnike toka, ki delujejo po principu padca napetosti na z električnim porabnikom (npr. elektromotorjem) zaporedno vezanim uporom majhne vrednosti (npr. 1 Ohm). Na ta način krmilnik zazna premajhen ali prevelik tok in lahko samodejno prepreči poškodovanje krmilne elektronke ali poskrbi za varno zaustavitev v primeru, ko gre kaj narobe.

To pomeni, da moramo pri dobro načrtovanem krmilnem vezju vselej predvideti tudi možnost pretrganja katerekoli pomembne žične povezave, ali slabih kontaktov na njej. Denimo, s stalnim preverjanjem smiselnosti podatkov z analognih tipal lahko odkrijemo anomalijo in podatke s tipala prenehamo uporabljati. Denimo, če digitalni signal tipala za zaznavanje gibanja v prostoru sorazmerno hitro preklaplja med vrednostima 0 in 1 daljši čas, je skoraj gotovo nekaj narobe, saj take spremembe signala prej ustrezajo naključnemu preklapljanju kot pa signalu iz tipala. Podobno, pri analognem vhodu zaznamo anomalijo, če je z A/D pretvornikom pridobljena vrednost izven pričakovanega obsega. Nepravilno delovanje ali pretrganje žičnih povezav veliko enostavneje zaznamo pri SPI ali I2C vodilu, saj je najdaljši čas za odziv tipala na zahtevo po posredovanju podatkov navadno reda nekaj milisekund do nekaj sekund. A kaj, ko se nemalo ljubiteljskih programerjev ugnezdene programske opreme v Arduino razvojnem okolju in nemalokrat se celo večji proizvajalci ljubiteljskih razvojnih ploščic požvižgajo na zanesljivost. Tako se je treba nemalokrat lotiti mukotrpnega popravljanja številnih programskih knjižnic.

Sodelovanje elektronskih in mehanskih sklopov
Daljinsko voden modeli drona-helikopterja z dvema nasproti se vrtečima glavnima rotorjema in repnim rotorjem za nagibanje v želeni smeri letenja (naprej ali nazaj) je odličen primer, kakor z dobrim načrtovanjem mehanskih in elektronskih sklopov dosežemo visoko zanesljivost delovanja. Denimo, čeprav zgoraj omenjeni dron ne ve, ali morda kateri od treh motorjev ne deluje, je zgrajen tako, da lahko za silo leti in bolj ali manj varno pristane tudi brez repnega rotorja, ki omogoča predvsem premikanje naprej in nazaj, medtem ko za obračanje na levo ali desno uravnavamo z razliko hitrosti vrtenj glavnih rotorjev. Do nevarne situacije za letenje drona lahko pride le v primeru, ko skozi repni rotor zaradi okvare steče prevelik tok in preobremeni baterijo, kar odvzame moč tudi motorjema glavnih rotorjev. Povejmo še, da je elektronika omenjenega helikopterskega drona enostavna tudi zato, ker uporablja mehanski giroskop, ki spominja na palico za lovljenje ravnotežja, ki jo uporabljajo vrvohodci. Kljub temu so vsi kontakti za žične povezave motorjev in baterije sorazmerno veliki, saj se le tako ne uničijo ob morebitnem trku drona z oviro in posledičnem padcu z višine do nekaj metrov.

Enostavne rešitve pa vedno ne pridejo v poštev. Prvi droni za domačo rabo so bili brez zapletene elektronike inherentno nestabilni kvadkopterji. Seveda, je elektronski giroskop lažji od mehanskega, a je za stabilen let potrebna tudi hitro odzivna elektronika, ki uravnava hitrosti vrtenj štirih rotorjev. K sreči se izkaže, da jih lahko upravljamo v parih, s čemer dronu omogočimo gibanje v vse smeri. A to drži le, če vsi motorji delujejo brezhibno in če smo pred prvim poletom (predvsem pri večjih dronih) vse natančno umerili. Kljub temu večina krmilnikov ni kos situaciji, ko pride do okvare ali odpovedi enega od rotorjev, kateri praviloma sledi strmoglavljanje.

V praksi lahko hitro odzivnost in dobro vodljivost zagotovimo z 32-bitnimi mikrokontrolerji. Zato ne preseneča, da nainternetu najdemo, kar nekaj primerov uspešnih dronov na osnovi Rapberry Pi in podobnih mikroračunalniških plošč, ki jim dodamo posebej zanje izdelano močnostno krmilno elektroniko, ki bere podatke s tipal, upravlja motorje, preverja napolnjenost baterij in se v skrajnem primeru lahko odloči tudi za zasilni pristanek.

Zanesljivo daljinsko vodenje in varnostni elementi
Daljinski upravljalnik je sprogramiran tako, da začne oddajati osnovni signal že, ko ga vklopimo. Dron signal prepozna in se odzove, kar je pomembno predvsem upravljalnikih, ki podpirajo več frekvenčnih območij, saj je tako mogoče hkrati upravljati več istovrstnih dronov. Krmilniki enostavnih dronov zahtevajo stalen sprejem signala iz krmilnika, če med letenjem signal izgine, dron skuša tako ali drugače samodejno pristati, je pa res da enostavni droni nimajo višinomera in ne zaznavajo ovir v zraku in na tleh, zato se navado poskus samodejnega pristanka konča dokaj klavrno. Stalen signal s krmilnika zahteva tudi večina daljinsko vodenih vozil in plovil (razen avtonomnih), a je pri teh samodejna zaustavitev preprosta.

Čeprav so droni zaenkrat bolj za zabavo in snemanje fotografij z zraka kot zares, najdemo veliko podobnih primeru tudi v vsakdanjem življenju – v vse bolj z elektroniko natrpanih sodobnih avtomobilih. Denimo, če se lotimo razstavljanja na videz preprostega krmilnika ABS osebnega avtomobila, hitro opazimo, kako se je moral proizvajalec potruditi, da je vgradil vse varnostne elemente, ki omogočajo, da se krmilnik ob okvari samodejno izklopi in na to voznika tudi jasno opozori. Kontrola vključuje tako pravilnost delovanja vseh tipal za hitrost vrtenja koles in stopalko za plin, kot tudi aktivatorjev, oziroma električnih zapornih ventilov, ki ob zdrsovanju posameznega kolesa samodejno zmanjšajo zavorni učinek nanj.

Vremenska postaja v vsakdanjem življenju
Tudi pri vremenski postaji, ki smo jo izdelali v preteklih nadaljevanjih v SE304 in SE305, lahko izpostavimo problem zanesljivosti delovanja, ki je še izražen pri WiFi komunikaciji z oddaljenim modulom. Kaj naj stori vremenska postaja, ko oddaljeni modul ne deluje? Kaj, če se komunikacija nenadoma prekine? Koliko časa in kako hitro naj poskuša vzpostaviti povezavo nazaj, če se dlje časa ne more povezati z oddaljenim merilnim modulom?

Vremenska postaja deluje po principu odjemalec-strežnik, pri čemer deluje oddaljeni modul kot strežnik, vremenska postaja pa je odjemalec. Tako lahko bere podatke s poljubnega števila oddaljenih modulov, pri čemer je lahko neposredno hkrati stalno povezana z do štirimi. A kar gre za sorazmerno počasne povezave, slednje povsem zadošča. Kakorkoli, ob porušitvi ene ali več povezav z oddaljenimi moduli, mora vgrajena programska oprema najprej ugotoviti, katere povezave so porušene in plast internetnega protokola, na kateri je povezava porušena.
Pri popolni odpovedi povezave, ko odjemalec in strežnik nista več povezana prek WiFi protokola in je za ponovno vzpostavitev povezave potrebno izvesti podoben postopek kot pri prvi vzpostavitvi ob zagonu vremenske postaje in oddaljenih modulov.

Če pa je porušitev v aplikacijski plasti internetnega protokola, odjemalec še vedno komunicira s strežnikom, le da strežniška aplikacija v strežniku preneha procesirati njegove zahteve. Tu moramo uporabiti drugačen pristop in nekako obvestiti strežnik, da mora ponovno vzpostaviti pravilno delovanje strežniške aplikacije, lahko pa to samodejno zazna sam. Ena izmed možnosti je tudi vgradnja dodatne strežniške aplikacije, prek katere lahko odjemalec obvesti strežnik o težavah.

Kako se lotiti hroščev v Arduino programskih knjižnicah?
Zanesljivost delovanja doma narejene vremenske postaje ogrožajo tudi številni hrošči v Arduino programskih knjižnicah, ki se pokažejo šele v kompleksnejših aplikacijah. Kaže, da se snovalci nekaterih Arduino programskih knjižnic za WiFi komunikacijo niso kaj dosti ukvarjali s porabo RAM-a in puščanjem pomnilnika. Resda, da ga ima ESP32 sorazmerno veliko, a ga nekatere funkcije v programskih knjižnicah po nepotrebnem razsipajo. Če se želimo povezati s spletno storitvijo telnet, FTP(S) ali HTTP(S) na (oddaljenem) internetnem strežniku, lahko to storimo s pomočjo funkcij in podatkovnih struktur programske knjižnice WiFiClient.h, v katero so ugnezdene tudi funkcije za tokovno komunikacijo, na moč podobno tisti prek RS232 protokola.

Pri prenosu podatkov prek telnet protokola, je dobro pred začetkom izprazniti čakalno vrsto, tako kot pri RS232, saj so v njej lahko nepotrebni znaki ali sistemska sporočila, ki jih ne potrebujemo. Praznjenje čakalne vrste lahko pri enostavnejših aplikacijah izvedemo s programskim stavkom if(client.available())client.flush(), če smo prej definirali objekt: »WiFiClient client«.

A pred nekaj več kot mesecem dni sem se mukotrpno ukvarjal z vprašanjem, zakaj je omenjena funkcija v moji aplikaciji na lepem preprosto prenehala delovati, posledično pa je tudi vremenska postaja ob zagonu po uspešni vzpostavitvi osnovne povezave na lepem izgubila WiFi povezljivost.

Po vztrajnem brskanju po programerskih blogih in programski kodi knjižnice sem končno prišel do zaključka, da je očitno kriva rezervacija pomnilnika, ki jo funkcija client.flush() izvede glede na to, koliko znakov še čaka v čakalni vrsti. Pomnilnik torej potrebuje za odlaganje »smeti«, saj se navezuje na funkcijo za hiter masovni prenos podatkov, ki je očitno vezana na delovanje in način uporabe DMA krmilnika v ESP32. Ker se v slednje nisem hotel poglabljati, sem zgornji programski stavek preprosto nadomestil z naslednjim:

while(client.available())client.read();

Mogoče včasih deluje za spoznanje počasneje, a težave so s tem odpravljene. Tudi rezervacija pomnilnika v ozadju ni več potrebna. Naj omenim še to, da se v izravnalniku navadno ne nabere prav veliko odvečnih znakov, kar pomeni, da lahko prikazana rešitev deluje celo hitreje (npr. za 10 odvečnih znakov).

Kako ponovno vzpostaviti WiFi povezavo s strežnikom v Arduino kodi?
Primeri Arduino programske kode v veliki večini obravnavajo vzpostavitev komunikacije z WiFi strežnikom in programskim strežnikom za izbrano spletno storitev, ki jo ta poganja (denimo HTTP server), pri čemer ni razdelana možnost nenadnega izpada WiFi povezave ali strežnika spletne storitve in koraki, ki jih je potrebno izvesti za samodejno ponovno vzpostavitev povezave. Čeprav se zdi na videz preprosto, moramo programski kodi marsikaj postoriti, preden lahko zaženemo programa za ponovni vzpostavitev spletne povezave. Pri tem je zelo pomembno pravilno obveščanje morebiti zataknjenih čakalnih zank programu, kakor tudi ponastavitev spremenljivk, ki opredeljujejo stanje WiFi povezave. Ker strežnik omogoča hkratne povezave več klientov, se lahko delovna postaja vselej prijavi kot nov klient, pri čemer ji ni potrebno čakati, da bi se stara povezava samodejno sprostila po preteku vseh najdaljših čakalnih časov. Drugače je na strani odjemalca, saj moramo podatkovne strukture odjemalca za povezavo z izbranim strežnikom najprej odstraniti in ponastaviti, da lahko poskusimo ponovno vzpostaviti povezavo. Dostikrat pri tem naletimo na težave tudi zaradi v programskih knjižnicah skritih programskih struktur za shranjevanje podatkov, zaradi katerih imamo lahko težave, denimo pri samodejnem določanju naslova IP za komunikacijo s strežnikom, ali pri nastavljanju MAC naslova, ki ga lahko nastavimo samo pod določenimi pogoji – v Arduino razvojnem okolju praviloma le ob zagonu. Poglejmo še izsek iz programske kode funkcije, ki ciklično bere podatke z oddaljenega modula vremenske postaje:

if((!tm_srv_connected)||(!client.connected())||(reconnect_cnt>0)){
if(reconnect_cnt==50){
client.stop(); // also stop application
client, if WiFi 
connecton breaks
WiFi.mode(WIFI_OFF); // turn off WiFi
tp_val_ready=false...// also reset other
system variables
tm_srv_connected=false;
} else if(reconnect_cnt>55){ 
connect_telnet(); // try to reconnect to
telnet
tp_val_ready=false... // also reset other
system variables
reconnect_cnt=0; // start reconnection counter
}
reconnect_cnt++;
return -301; // error - not connected
} else {... // normal operation}

Kot vidimo, je programska koda zasnovana za prvo vzpostavitev ter kasnejšo detekcijo prenehanja delovanja povezave in njeno ponovno vzpostavitev.

Prihodnjič
Ukvarjali se bomo z uporabniškim vmesnikom, ki mora biti intuitiven, hkrati pa tudi jasno obveščati uporabnika, ko gre kaj narobe in je nujno potrebna njegova intervencija. Na koncu še nekaj o hitrem prenosu podatkov, kot ga pozna večina naprav z USB priključki, denimo digitalni fotoaparat. Slednji se po priklopu na USB vtičnico navadno preklopi v način za polnjenje ali v način za prenos podatkov. Zanimal nas bo slednji, saj želimo imeti možnost hitrega kopiranja podatkov na kartici (mikro) SD, ne ga bi jo odstranili iz naprave…

Vir:
https://sites.google.com/site/pcusbprojects

Vstopna