CircuitPython

Salut, sunt Alex de la DEV STORIES DOT EU. CircuitPython, episodul 1 din 7. Dacă vii din lumea sistemelor embedded tradiționale, configurarea unui toolchain durează de obicei mai mult decât scrierea primului program. Petreci ore întregi chinuindu-te cu compilatoare, drivere și utilitare de flashing dedicate doar pentru a testa o singură linie de logică. Drive-ul CIRCUITPY ocolește complet toate acestea. Dezvoltatorii embedded caută adesea instinctiv un flash tool, un compilator sau un Integrated Development Environment specific atunci când încep un proiect nou. Cu CircuitPython, nu ai nevoie de ele. Nu există niciun pas de compilare. Sistemul de fișiere al sistemului de operare se ocupă de procesul de deploy. Când conectezi un microcontroler compatibil cu CircuitPython la computer folosind un cablu USB, placa se prezintă sistemului de operare ca un dispozitiv USB mass storage standard. Acest drive detașabil se montează automat și se numește CIRCUITPY. Pentru computerul tău, indiferent dacă folosești Windows, macOS sau Linux, arată exact ca un stick USB standard. Îl poți deschide în file explorer, îi poți vizualiza conținutul și îl poți modifica. În interiorul acestui drive, cel mai important fișier este un fișier text denumit de obicei code dot py. Acest fișier acționează ca entry point pentru aplicația ta. Îl poți deschide în orice editor de text standard. Nu necesită o aplicație specializată; un editor de text de bază funcționează perfect. Când scrii un program simplu - poate o buclă care afișează text sau interacționează cu placa - și dai save, ciclul de deploy începe automat. Iată ideea cheie. Nu trebuie să dai click pe un buton de build sau să rulezi un utilitar din command line pentru a trimite codul către hardware. În momentul în care salvezi fișierul, microcontrolerul detectează activitatea sistemului de fișiere prin conexiunea USB. Acest comportament este controlat de un mecanism numit auto-reload. CircuitPython monitorizează activ starea conexiunii USB mass storage. Când inițiezi o operațiune de salvare în editorul tău de text, computerul scrie date pe drive-ul CIRCUITPY. CircuitPython așteaptă până când scrierea în sistemul de fișiere este completă. Odată ce scrierea fișierului se termină, sistemul de auto-reload declanșează un soft reboot al microcontrolerului. Acest soft reboot este extrem de rapid. Întrerupe orice făcea microcontrolerul în acel moment, închide în siguranță starea curentă și șterge complet memoria. Apoi, parsează și execută imediat fișierul code dot py nou salvat, de la început. Mecanismul de auto-reload creează o buclă de iterație foarte strânsă. Editezi codul, salvezi fișierul și urmărești cum răspunde hardware-ul în mai puțin de o secundă. Dacă există o eroare de sintaxă în codul tău nou salvat, execuția se oprește în siguranță. Poți vizualiza output-ul erorii printr-o conexiune serială. Corectezi typo-ul, salvezi din nou fișierul, iar placa repornește instantaneu pentru a încerca codul actualizat. Drive-ul CIRCUITPY este, de asemenea, mecanismul pentru gestionarea dependențelor. Dacă proiectul tău necesită cod auxiliar extern pentru un anumit hardware, nu folosești un package manager din command line. Pur și simplu dai drag and drop la fișierele library necesare direct într-un folder desemnat numit lib de pe drive-ul CIRCUITPY. Sistemul de auto-reload urmărește și modificările din acest director. Înainte de a încheia, dacă îți plac aceste episoade tehnice și vrei să susții emisiunea, poți căuta DevStoriesEU pe Patreon. Schimbarea fundamentală aici este că sistemul de fișiere în sine acționează ca un deployment pipeline, transformând orice mașină cu un editor de text de bază și un port USB într-un workstation de dezvoltare embedded complet capabil, fără a instala niciun driver. Asta e tot pentru acest episod. Mulțumesc pentru audiție și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. CircuitPython, episodul 2 din 7. Scrii un script pentru a aprinde o lumină, salvezi fișierul, iar lumina clipește pentru o fracțiune de secundă înainte de a se stinge imediat. Codul tău este perfect în regulă. Problema este că atunci când un script ajunge la final și se termină, sistemul resetează automat starea hardware. Pentru a menține un dispozitiv în funcțiune, trebuie să împiedici finalizarea scriptului. Aici intervine conceptul de Hardware as Code. În programarea tradițională, codul tău manipulează date în memorie. În programarea embedded, codul tău manipulează semnale electrice fizice. CircuitPython abstractizează această complexitate folosind trei module built-in: board, digitalio și time. Nu trebuie să le instalezi. Sunt integrate direct în firmware. Modulul board acționează ca o hartă hardware pentru microcontrolerul tău specific. Știe ce rutare internă corespunde pinilor fizici. Când faci referire la board dot LED, obții adresa hardware corectă pentru lumina built-in, indiferent de modelul fizic de placă pe care îl ai efectiv în mână. Modulul digitalio oferă clasele necesare pentru a controla fluxul de electricitate. Acesta traduce obiectele Python în semnale digitale. În cele din urmă, modulul time se ocupă de ritm. Microcontrolerele execută milioane de instrucțiuni pe secundă. Fără modulul time care să pună pe pauză execuția, o lumină care clipește ar face toggle atât de repede încât ar părea doar continuu estompată pentru ochiul uman. Iată cum funcționează împreună aceste trei module pentru a face să clipească un LED onboard. Mai întâi, imporți board, digitalio și time. Apoi, configurezi hardware-ul. Creezi un obiect nou folosind clasa DigitalInOut din modulul digitalio și îi pasezi pinul board dot LED. Acum ai un obiect Python care reprezintă acea conexiune fizică specifică. Pinii pot fie să asculte electricitatea care intră, fie să trimită electricitate în exterior. Trebuie să îi spui explicit lui CircuitPython ce ar trebui să facă acest pin. Setezi proprietatea direction a noului tău obiect pin pe output. Asta îi spune microcontrolerului să împingă tensiune către LED. Iată ideea cheie. Odată ce pinul este configurat ca output, controlul semnalului electric fizic este exact ca atribuirea unei variabile. Pentru a aprinde LED-ul, setezi proprietatea value a obiectului tău pin pe True. În spate, CircuitPython traduce acea simplă atribuire boolean într-un semnal de înaltă tensiune, împingând electricitatea prin circuit și aprinzând LED-ul. Pentru a-l stinge, setezi proprietatea value pe False, ceea ce scade tensiunea la zero. Acum, înapoi la problema cu care am început. Dacă doar setezi valoarea pe True, apoi pe False, scriptul se termină. CircuitPython face clean up resetând toți pinii, iar placa ta se oprește. Pentru a face LED-ul să clipească continuu, trebuie să blochezi secvența de execuție. Îți pui comenzile într-un loop infinit while True. În interiorul acelui loop, setezi valoarea pinului pe True. Apoi, folosești time dot sleep pentru a pune scriptul pe pauză pentru o jumătate de secundă. Setezi valoarea pinului pe False. Pui pe pauză pentru încă o jumătate de secundă. Deoarece este un loop infinit, scriptul nu ajunge niciodată la final, hardware-ul nu se resetează niciodată, iar LED-ul continuă să clipească atâta timp cât placa este alimentată. Când scrii hardware as code, nu doar muți bytes. Deschizi și închizi fizic porți electrice prin atribuirea valorilor True și False către obiecte Python. Mulțumesc că ne-ai ascultat. Pe data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. CircuitPython, episodul 3 din 7. Majoritatea debugging-ului embedded implică modificarea unei linii de cod, așteptarea unui recompile, flash-uirea plăcii și speranța că output log-ul tău va prinde bug-ul. Dar cum ar fi dacă ai putea pune pe pauză execuția și să dai comenzi hardware-ului live? Exact asta îți permit să faci Serial Console și REPL. Când conectezi o placă CircuitPython la computer, aceasta stabilește o conexiune serială bidirecțională prin USB. Poți accesa asta folosind un program de terminal precum PuTTY pe Windows, sau comanda screen pe macOS și Linux. Multe conexiuni seriale îți cer să potrivești un anumit baud rate, de obicei 115200. CircuitPython chiar ignoră această setare prin USB, dar este o practică standard să îți configurezi terminalul la acea viteză oricum. Serial console-ul este principala ta fereastră bazată pe text către placă. Ori de câte ori scriptul tău execută un print statement, output-ul apare aici. Mai important, dacă codul tău întâmpină o eroare fatală și dă crash, traceback-ul Python este printat în această consolă. Fără o conexiune serială deschisă, o placă care a dat crash nu îți oferă nicio informație de diagnostic. Pur și simplu nu mai funcționează. Serial console-ul este, de asemenea, poarta ta de acces către REPL. REPL vine de la Read, Evaluate, Print, Loop. Este un prompt interactiv Python care rulează direct pe cipul microcontrolerului. Dezvoltarea tradițională de firmware necesită scrierea codului pe un host machine, compilarea acestuia și transferul binary-ului. REPL schimbă complet această dinamică. Tastezi o comandă, placa o citește, evaluează logica, printează rezultatul și face loop înapoi pentru a aștepta următoarea ta comandă. Ia în considerare un scenariu practic. Ai un script care rulează pe placa ta, dar trebuie să afli ce pin hardware controlează LED-ul încorporat. Deschizi terminalul serial și apeși Control C. Asta întrerupe instantaneu scriptul care rulează. Ți se cere să apeși orice tastă, ceea ce te duce în REPL. Știi că ești în locul potrivit când vezi promptul standard Python, care este format din trei paranteze unghiulare. Acum, tastezi import board. Pentru a descoperi ce hardware este disponibil, treci modulul board în funcția built-in dir. REPL printează o listă cu fiecare nume de pin activ pentru hardware-ul tău specific. Vezi pinul LED în listă. Chiar acolo, la prompt, imporți modulul digital IO. Creezi un pin object pentru LED, îi setezi direcția pe output și îi setezi valoarea pe true. LED-ul fizic de pe biroul tău se aprinde instantaneu. Tocmai ai dat comenzi hardware-ului manual, linie cu linie. Iată ideea cheie. Codul tastat în REPL este efemer. Există doar în memoria activă a acelei sesiuni curente. Dacă deconectezi placa sau o repornești, tot ce ai tastat dispare. REPL este un instrument exploratoriu. Este un sandbox unde poți testa limitele hardware-ului, verifica numele pinilor sau verifica syntax-ul din mers. Odată ce găsești secvența exactă de comenzi care îți atinge obiectivul, trebuie să recreezi manual acea logică în fișierul code dot py de pe unitatea USB pentru a o face permanentă. După ce ai terminat testarea, ieși din REPL și îți repornești codul salvat apăsând Control D. Asta declanșează un soft reboot, reîncărcând fișierul code dot py de la zero. REPL schimbă dezvoltarea hardware-ului de la un ciclu lent de ghicire la o explorare instantanee și interactivă. Mulțumesc pentru ascultare, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. CircuitPython, episodul 4 din 7. Microcontrollerele au o memorie RAM incredibil de limitată, ceea ce înseamnă că un script relativ scurt poate da crash brusc board-ului tău, lăsându-l complet out of memory înainte de a executa o singură comandă. Vinovatul este adesea modul în care board-ul procesează codul extern pe care îl aduci, iar rezolvarea acestui bottleneck de memorie este exact scopul The Library Ecosystem. CircuitPython vine cu core modules built-in în firmware, dar pentru hardware specific, cum ar fi senzorii de temperatură sau display-urile LED, ai nevoie de librării externe. Spre deosebire de un environment Python standard de desktop, nu există un package manager. Nu rulezi o comandă ca să faci fetch automat la un driver. Partea de dependency management aici este manuală by design. Când conectezi microcontrollerul prin USB, apare ca un flash drive. În root-ul acestui drive se află un directory numit pur și simplu lib. Acest folder este locul dedicat pentru toate dependencies-urile tale externe. Ca să îl populezi, descarci Adafruit Library Bundle, o arhivă ZIP masivă care conține sute de drivere oficiale și module helper. Aici e ideea de bază. Când vrei să descarci acest bundle, vei vedea mai multe versiuni disponibile. O eroare frecventă este pur și simplu să descarci cel mai nou bundle de pe pagină. Dacă board-ul tău rulează CircuitPython versiunea opt, dar tu descarci bundle-ul pentru versiunea nouă, codul tău va da fail. Major version-ul bundle-ului trebuie să facă match exact cu major version-ul firmware-ului CircuitPython instalat pe board-ul tău. Dacă nu fac match, sistemul aruncă erori de incompatible bytecode și refuză să ruleze. În interiorul acelui bundle care face match, vei găsi librăriile oferite în două formate de fișiere distincte: fișiere dot py standard și fișiere dot mpy. Fișierele dot py sunt raw, adică source text Python human-readable. Deși board-ul tău le poate rula, microcontrollerul trebuie să încarce tot acel raw text în spațiul lui minuscul de RAM și să îl compileze în bytecode on the fly. Acest overhead de compilare îți mănâncă memoria incredibil de repede. Fișierele dot mpy rezolvă problema asta. Ele sunt pre-compiled bytecode. Pasul greu de traducere a fost deja făcut pe un computer înainte ca tu să descarci fișierul zip. Când microcontrollerul încarcă un fișier dot mpy, execută instrucțiunile direct, dând bypass complet la faza de text parsing. Să zicem că vrei să conectezi un LED strip NeoPixel la board-ul tău. Îți scrii scriptul de control, dar sistemul are nevoie de hardware driver ca să știe cum să comunice cu acele LED-uri specifice. Deschizi library bundle-ul cu versiunea corectă, localizezi fișierul numit neopixel dot mpy și îi dai drag direct în directory-ul lib de pe board. Dacă i-ai fi dat drag fișierului raw neopixel dot py în schimb, microcontrollerul tău ar fi putut rămâne ușor out of memory doar încercând să interpreteze codul driverului. Folosind fișierul dot mpy pre-compiled, board-ul salvează RAM critic pentru application logic-ul tău propriu-zis și aprinde pixelii imediat. Făcând dependency management manual, ești forțat să fii foarte intenționat cu privire la ce cod trăiește pe device-ul tău. Să te bazezi pe pre-compiled bytecode este singura modalitate de a face abstract away la operațiunile hardware complexe fără a epuiza instantaneu memory footprint-ul minuscul al unui microcontroller. Asta e tot pentru acest episod. Mersi că m-ai ascultat și keep building!

Salut, sunt Alex de la DEV STORIES DOT EU. CircuitPython, episodul 5 din 7. Uneori, ștergerea unui library de pe microcontrolerul tău face ca proiectul tău să ruleze mai bine. Elimini o dependență mare de pe drive, dai restart la placă, și codul tău încă funcționează ca prin magie. Asta se întâmplă datorită unui feature numit Frozen Libraries. Microcontrolerele, în special cele mai mici, cum ar fi Circuit Playground Express, operează sub limitări hardware extreme. Fiecare fișier de library standard din folderul tău lib ocupă spațiu fizic de stocare pe micul flash drive. Mai important, atunci când codul tău rulează, device-ul trebuie să încarce tot acel fișier în memoria RAM. Dacă încarci prea multe fișiere, sau fișiere prea mari, rămâi fără memorie și programul dă crash. Developerii de firmware rezolvă asta prin înghețarea acelor core libraries direct în build-ul de CircuitPython. În loc să existe ca un fișier independent pe USB drive-ul tău vizibil, codul din library este precompilat și împachetat direct în fișierul de firmware de bază pe care îl încarci inițial pe placă. Asta oferă un avantaj masiv. Aceste frozen libraries ocupă zero spațiu pe filesystem-ul tău vizibil. Pentru că fac parte din imaginea de core system, microcontrolerul execută codul direct din memoria flash. Sare complet peste procesul de copiere a acelui library în memoria RAM. Asta duce la o capcană comună. Mulți developeri descarcă un bundle masiv de libraries, copiază tot ce cred ei că au nevoie în folderul lor lib, și duplică accidental libraries care sunt deja frozen în firmware-ul lor. Asta irosește spațiu prețios pe filesystem. Dacă ștergi un library din folderul tău lib și proiectul tău continuă să ruleze impecabil, acel library era frozen. Aici este ideea cheie. Pentru a înțelege cum să eviți această suprapunere, trebuie să înțelegi ordinea de prioritate la import, controlată de system path. Când codul tău dă import la un modul, CircuitPython nu ia pur și simplu prima potrivire pe care o vede. Caută în locații într-o secvență strictă. În primul rând, verifică root directory-ul de pe drive-ul tău. În al doilea rând, verifică folderul lib. În al treilea rând, și doar dacă nu reușește să găsească acel library în primele două locații, verifică acele frozen libraries ascunse în firmware. Această ordine de prioritate înseamnă că orice fișier pe care îl pui pe drive-ul tău dă override la versiunea frozen. Dacă pui o versiune învechită sau custom a unui library în folderul tău lib, CircuitPython rulează acel fișier. Ignoră complet versiunea frozen, optimizată și eficientă din punct de vedere al memoriei, din firmware. Plătești costul de memorie pentru un fișier pe care nu era nevoie să-l oferi. În cadrul acestor directoare, extensiile de fișiere respectă și ele o regulă strictă de prioritate. Un fișier sursă plain text câștigă mereu în fața unui fișier compilat. Dacă ai atât un fișier text standard, cât și o versiune compilată a aceluiași library în exact același director, CircuitPython încarcă fișierul text necompilat. Dacă vrei să știi exact ce este integrat în placa ta, poți deschide prompt-ul interactiv și poți tasta cuvântul help, pasând cuvântul modules între paranteze. Asta va printa o listă completă cu fiecare frozen library disponibil pentru tine out of the box. Cel mai inteligent mod de a gestiona memoria pe un device constrâns este să lași firmware-ul să facă greul. Să știi exact ce este deja frozen previne fișierele duplicate, oprește override-urile accidentale și îți păstrează memoria disponibilă liberă pentru logica aplicației tale. Mulțumesc că m-ați ascultat. Aveți grijă de voi, tuturor.

Salut, sunt Alex de la DEV STORIES DOT EU. CircuitPython, episodul 6 din 7. Te uiți la un proiect hardware și vezi că developerii au eliminat în mod deliberat funcții avansate, cum ar fi hardware interrupts, din limbajul de bază. Ai putea crede că asta a limitat platforma, dar de fapt a făcut-o mult mai de succes. Asta este divergența arhitecturală dintre CircuitPython și MicroPython. Developerii presupun adesea că aceste două platforme sunt identice. Ambele rulează Python pe microcontrolere, iar CircuitPython a început inițial ca un fork de MicroPython. Cu toate acestea, ele servesc unor filozofii complet diferite. MicroPython este conceput pentru a expune puterea brută și feature-urile specifice ale microcontrolerului de la bază. CircuitPython este conceput pentru a impune un standard strict și unificat pe tot hardware-ul. Prima diferență pe care o vei observa este standard library. MicroPython folosește o convenție de naming care prefixează modulele standard cu litera u pentru a indica o versiune micro. Imporți uos sau utime. CircuitPython renunță complet la asta. Impune convenția standard de naming din CPython de desktop. Pur și simplu imporți os sau time. Dacă ești un developer care portează un script de MicroPython pe CircuitPython, va trebui să redenumești acele import-uri. În schimbul acestei mici ajustări, codul tău devine extrem de portabil. Acel nivel de portabilitate este feature-ul de bază din CircuitPython. MicroPython expune regiștri hardware specifici și numere de pini specifice cipului. CircuitPython abstractizează complet hardware-ul folosind un API unificat centrat în jurul unui modul numit board. În loc să scrii cod care dă toggle la pinul GPIO 15 pe un ESP32, îi spui lui CircuitPython să dea toggle la board punct D4. Dacă muți exact acel script pe o arhitectură de microcontroler complet diferită, cum ar fi un cip ARM Cortex standard, codul hardware rulează complet neschimbat. Pentru a menține această consecvență, CircuitPython forțează anumite alegeri arhitecturale pe care MicroPython le lasă opționale. De exemplu, MicroPython îți permite să compilezi firmware fără suport pentru numere floating-point, ca să economisești memorie. CircuitPython impune suportul floating-point în absolut fiecare build. Operațiile matematice se comportă exact la fel, indiferent de cât de limitat este hardware-ul. CircuitPython standardizează, de asemenea, mesajele de eroare, oferind text localizat și detaliat, în loc de erori de memorie scurte, de tip bare-metal. Iată ideea cheie. Cea mai polarizantă diferență este modul în care cele două gestionează partea de concurrency. MicroPython oferă suport complet pentru hardware interrupts. Un interrupt permite ca o schimbare fizică a unui pin să pună imediat pe pauză programul principal, să execute o funcție specifică, și apoi să își reia execuția. Asta oferă un timing de înaltă performanță, dar introduce și race conditions complexe și stări de memorie imprevizibile, care sunt incredibil de greu de făcut debug. CircuitPython elimină în mod deliberat suportul pentru hardware interrupts. Nu poți declanșa cod Python direct de la un pin de hardware interrupt. În schimb, impune un cooperative multitasking. Gestionezi partea de concurrency folosind feature-uri standard din asyncio sau verificând stările secvențial în main loop-ul tău. Prin abandonarea acestor interrupts, CircuitPython se asigură că fluxul de execuție rămâne complet previzibil și elimină o categorie masivă de silent crashes. MicroPython îți oferă cheile către bare metal, prioritizând performanța brută și controlul hardware. CircuitPython dă la schimb acel control pentru un mediu în care codul tău este complet portabil, previzibil și se comportă exact ca Python-ul standard pe care îl rulezi pe un desktop. Mulțumesc pentru audiție, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. CircuitPython, episodul 7 din 7. Petreci zile întregi scriind și testând cod de interacțiune hardware pentru un senzor pe un microcontroler minuscul de cinci dolari. Mai târziu, cerințele proiectului se schimbă și ai nevoie brusc de puterea de procesare a unui computer Linux complet pentru a face log la acele date într-o bază de date remote în cloud. În mod normal, trecerea de la un microcontroler bare-metal la un sistem de operare complet înseamnă rescrierea completă a codului hardware. Platforma ta țintă are acum un kernel de sistem de operare care gestionează accesul la hardware, necesitând drivere și librării complet diferite. Dar dacă exact același script Python ar putea rula neschimbat pe ambele platforme? Exact asta îți permite Adafruit Blinka să faci. Înainte de a explica cum funcționează, hai să clarificăm o concepție greșită des întâlnită. Blinka nu înlocuiește sistemul de operare Linux de pe Raspberry Pi, BeagleBone sau alt single-board computer. Nu dai flash unui fișier firmware CircuitPython pe un card SD, așa cum faci cu un microcontroler. În schimb, Blinka este pur și simplu un pachet Python. Îl instalezi folosind pip standard. Acționează ca un compatibility layer care rulează în cadrul unui desktop CPython standard. Singura sa sarcină este să traducă API calls din CircuitPython în system calls standard de Linux, necesare pentru a controla hardware-ul. Când scrii cod hardware pe un microcontroler, CircuitPython gestionează accesul direct la hardware. Pe un sistem Linux, kernelul sistemului de operare controlează hardware-ul, iar programele userilor trebuie să solicite acces. Blinka acoperă acest gol. Când codul tău importă modulul board sau folosește modulul digitalio pentru a da toggle unui pin, Blinka interceptează aceste comenzi. Mapează numele pinilor din CircuitPython la configurația hardware specifică a single-board computer-ului tău, rutând request-ul prin subsistemele Linux necesare. Gândește-te cum arată acest lucru în practică cu senzorul nostru de temperatură. Pe micul microcontroler, codul tău importă board, configurează un I2C bus și citește continuu valorile temperaturii. Pentru a scala această operațiune la un Raspberry Pi 5, conectezi fizic senzorul la header pins de pe Pi. Apoi, în terminalul tău Linux, folosești pip pentru a instala Adafruit Blinka și driverul Python specific pentru senzorul tău de temperatură. Copiezi scriptul Python original, fără a modifica nicio linie. Când execuți scriptul folosind Python 3 standard, modulul board detectează dinamic că rulează pe un Raspberry Pi 5. Furnizează automat definițiile corecte ale pinilor pentru acel board specific. Modulul busio traduce perfect request-urile tale de citire I2C în device calls standard de I2C pe Linux. Scriptul tău citește datele senzorului exact așa cum o făcea înainte. Aici devine interesant. Deoarece acum rulezi CPython standard pe o mașină Linux completă, nu mai ești constrâns de limitele de memorie ale unui microcontroler. Scriptul tău poate citi senzorul hardware folosind acel translation layer din Blinka și apoi poate pasa imediat acele date către librării de desktop complexe. Poți folosi network requests standard pentru a da push la metrici către o bază de date în cloud, pentru a procesa telemetria cu tool-uri de data science sau chiar pentru a o servi printr-un web framework local. Iată ideea cheie. Codul de interacțiune hardware rămâne identic pe arhitecturi de calcul complet diferite. Prin decuplarea logicii senzorului de sistemul de operare subiacent, Blinka îți permite să prototipezi ieftin pe bare-metal și să scalezi la medii Linux complete, cu zero rescrieri de cod hardware. Asta încheie seria noastră despre CircuitPython. Te încurajez să citești documentația oficială, să încerci să configurezi un senzor cu Blinka hands-on sau să vizitezi devstories dot eu pentru a sugera subiecte pentru seriile viitoare. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!