Tijek razvoja softvera za CPLD i MCU

Programiranje CPLD-a

Za programiranje EPM570 (kao i raznih drugih FPGA i CPLD čipova) namijenjen je programski softver Quartus II (Intel Quartus Prime), a programski jezik za opis hardvera (HDL) zove se Verilog. Quartus II omogućuje cijeli proces razvoja FPGA, od pisanja koda i crtanja logičkih shema do simulacije, optimizacije i konačnog prebacivanja dizajna na hardver. Softver također uključuje alate za analizu i sintezu (pretvaranje koda u logička vrata), analizu vremena (timing analysis) te programiranje samog uređaja.

Za programiranje EPM570 morate kupiti i namjenski USB Blaster Programmer koji košta oko 3 eura. Ovaj programator se s jedne strane spaja na USB port računala, a s druge strane na 10-pinski JTAG konektor na razvojnoj pločici EPM570. Jednostavnije ne može biti.

Verilog je kao što smo već spomenuli jezik za opis hardvera (HDL) koji se koristi za modeliranje i simulaciju elektroničkih sustava. Ovaj programski jezik se bitno razlikuje od standardnih programskih jezika (poput C-a) jer ne opisuje slijedne naredbe za MCU (softver) nego opisuje strukturu i ponašanje hardvera, odnosno kako su žice povezane i kako logička vrata međusobno komuniciraju. U tipičnom radnom procesu, Verilog se koristi za pisanje koda koji opisuje kako bi digitalni sklop trebao raditi, a zatim se koristi Quartus II kako bi taj kod kompajlirao i fizički implementirao u FPGA/CPLD čip.

Sve ovo na prvi pogled djeluje komplicirano, odnosno djeluje kao nešto čemu treba posvetiti ogromno vremena za učenje. Međutim, jednostavno programiranje kao ovo za naš projekt u potpunosti može za vas odraditi AI. Uz pomoć AI meni su bila dovoljna 2-3 sata da naučim rad u Quartus II do dovoljne razine da konfiguriran I/O pinove i programiram CPLD pomoću Verilog koda kojeg mi je u potpunosti generirala AI.

Za programiranje svih onih diskretnih logičkih čipova za svaki pojedinačni senzor (Schmitt inverteri, RS Latchevi, multipleksori) treba napisati svega 30-tak linija Verilog koda. Osim toga, unutar CPLD također je sada programirana logika koja detektira promjenu stanja na bilo kojem senzoru kao prolazak metka. Time ESP32 ne mora stalno brzo skenirati sve senzonske linije ne bi li otkrio prolaz metka, već to za njega neusporedivo brže radi sam CPLD i informacije prema ESP32 šalje samo kada postoji neka promjena na senzorima.

Ovime smo dobili izuzetno brz detektorski sustav kojeg ćemo u ESP32 u jednom dijelu morati i znatno usporiti jer bi jedna dijabola (zbog svog oblika) mogla izazvati nekoliko brzih detekcija.

Osnovne upute za rad sa Quartus programom

Sučelje programa Quartus za programiranje našeg CPLD-a EPM570. Evo kratkih uputa kako se vrši samo programiranje kad imate gotovu datoteku s programom (.pof):

• Kreiranje novog projekta (New Project)
• Odabir EPM570 uređaja u projektu (Assignments -> Device)
  • Family -> MAX II
  • Available devices -> EPM570T100C5
• Postavljanje USB Blastera u Programatoru (Tools -> Programmer)
  • Hardware Setup
  • Currently selected hardware -> USB-Blaster
  • Auto Detect
• Programiranje
  • Add File -> odabir .pof datoteke
  • Program/Configure -> čekiraj polje (označi kvačicu)
  • Start

Programiranje je dakle vrlo jednostavno i ne razlikuje se puno od programiranja u mnogim drugim sličnim programatorima. A sada evo jednostavnog vodiča kako napraviti datoteku s programom (.pof) za EPM570T100C5 pločicu koristeći Verilog jezik, koji ste napisali sami ili uz pomoć AI:

• Izrada projekta u Quartusu (File -> New Project Wizard)
  • Odredite mapu gdje će projekt biti spremljen i naziv projekta -> Next
  • Family & Device Settings
    • Family -> MAX II
    • Available devices -> EPM570T100C5
  • Finish
• Pisanje koda
  • File -> New -> Verilog HDL File (kreiranje datoteke sa programom)
  • Nakon što je kod napisan (ili kopiran) datoteka se sprema (File -> Save) pod istim nazivom kako je odabrano u nazivu projekta s time da će ekstenzija datoteke biti .v

Vidimo da je i ovo posve jednostavno, no CPLD još uvijek ne zna na kojim I/O pinovima je fizički spojeni vanjski hardver. To mu morate reći:

• Dodjela pinova (Pin Planner)
  • Prvo se klikne na ikonu Start Compilation (ili pritisne Ctrl+L) da Quartus analizira kod
  • Nakon što analiza uspješno završi, ide se na Assignments -> Pin Planner
  • U donjoj tablici vidjet će se nazivi kojima treba odrediti I/O pinove i ostale atribute poput ulaznog Schmitt trigera za senzorske pinove
  • Nakon definiranja pinova Pin Planner se zatvara (automatski sprema unose) i ponovno se pokrene Start Compilation

Nakon što imamo spremljenu programsku datoteku, programiranje se vrši kako smo opisali na početku:

• Spojite USB Blaster na PC i na JTAG konektor pločice. Uključite napajanje pločice.
• Idite na Tools -> Programmer.
• Provjerite piše li gore desno USB-Blaster. Ako ne, kliknite Hardware Setup i odaberite ga.
• Kliknite Auto Detect. Trebao bi se pojaviti EPM570 na slici.
• Ako datoteka nije automatski učitana, kliknite na nju (ili Add File) i odaberite .pof datoteku iz mape output_files.
• Označite kvačicu pod Program/Configure i kliknite Start.

Napomena: Ako se bilo što mijenjate u programu ili Pin Planneru, morate ponovno pokrenuti kompilaciju (plava strelica Start Compilation  u glavnom prozoru Quartusa). Tek tada će te promjene biti upisane .pof datoteku koju šaljete na čip.

Programiranje Verilog koda za CPLD MAX II EPM570

Iako u osnovnim uputama za Quartus sve izgleda jednostavno, tijekom programiranja i definiranja pinova može se dogoditi niz grešaka i problema koje je onda potrebno sustavno rješavati. Tako je bilo i tijekom kreiranja programa za našu elektroničku metu. Program ima svoje „mušice“ i neke radnje je potrebno vršiti po točno određenom protokolu i hijerarhiji.

U Verilogu i Quartusu, hijerarhija nije samo način organizacije koda, već temelj načina na koji softver vidi hardver. Stoga su mi se često događale frustrirajuće situacije gdje prvi put neka naredba ili radnja prvi put prođe bez problema, a nakon modifikacija ili promjena u kodu (ili čak kod izrade nove verzije programskog koda) iste naredbe više ne prolaze.

Quartus uvijek traži jedan Top-Level Entity. Ako napravite novi modul ili promijenite ime postojećeg, a niste ga u postavkama postavili kao “Top-Level” (Hierarchy -> Set as Top-Level Entity), Quartus će uporno kompajlirati staru verziju ili javiti grešku jer ne vidi put do vaših novih naredbi. Quartus pokušava uštedjeti vrijeme tako da ne kompajlira sve ispočetka. Ako promijenite nešto duboko u hijerarhiji (npr. u nekom malom modulu koji se poziva unutar pet drugih), Quartus ponekad ne prepozna tu promjenu ispravno. Na primjer, ako dodate novu programsku datoteku u mapu projekta, ali ju ne dodate u “Files” listu unutar Quartusa, on će koristiti staru verziju datoteke koju još uvijek ima u memoriji, dok vi gledate u novi kod i pitate se zašto nema promjena.

Za razliku od klasičnog programiranja, u Verilogu svaki put kad pozovete modul, vi stvarate fizičku kopiju tog hardvera. Ako promijenite logiku unutar modula, to utječe na svaki dio projekta gdje se taj modul koristi. Ako imate grešku u hijerarhiji (npr. krivo spojene žice/portove između modula), program će možda proći analizu, ali će pasti na “Fitteru” (smještanju na čip) jer fizički ne može povezati te dijelove.

Iako je moj programski kod relativno jednostavan (da ne kažem malen) tijekom razvoja i testiranja radio sam dosta promjena i preinaka. Prvi put je sve prošlo „od prve“, a što sam više kasnije modificirao Verilog kod to sam i sve više vremena trošio na traženje načina kako da Quartus i u potpunosti prihvati taj novi kod.

Nakon što nekoliko desetaka puta izmijenite raspored pinova i promijenite osnovni Verilog kod, stvari počinju sjedati na mjesto i naučite kako i gdje najbolje raditi promjene tako da programiranje svaki puta prođe ispravno.

Meni je Verilog kod 99% pisao AI, međutim, prvi kod posve sigurno nikad neće raditi dobro. Bilo je potrebno nekoliko desetaka izmjena koda, a također i nekih izmjena na hardveru, kako bi dobio stabilan sustav detekcije.

Arhitektura Verilog koda za elektroničku metu 

Prvo sam radio program za kontrolu samo 64 senzora preko jednog EPM570 i ESP32, no na puno stvari se ipak trebalo gledati unaprijed, dakle za buduću kontrolu svih 128 (2×64) senzora.

Arhitektura prvog rješenja je bila slijedeća:

• 64 interna Schmitt triggera (Assignment Editor -> Input Termination -> Schmitt Trigger).
• 64 RS Latcha (svaki ulaz ima svoj registar koji se postavlja na 1 čim senzor okine)
• Reset linija (ESP32 će poslati jedan signal na EPM570 koji istovremeno briše svih 64 latch-eva nakon čitanja)
• SPI-like Protokol – Umjesto sporog I2C-a, koristi se jednostavan Shift Register (posmični registar). ESP32 će slati “Clock” impulse, a EPM570 će izbacivati bit po bit (64 bita u nizu).

EPM570 pločica ima dostupnih 72 I/O pinova. 64 pina ide na senzore, 6 pinova je komunikacija sa ESP32, a 2 pina ostaju slobodna (kasnije ćemo iskoristiti još jedan pin za Alarm). Ručni unos 70 pina u Pin Planneru bi bio dugotrajan pa sam koristio Tcl skriptu koju mi je generirao AI (View -> Utility Windows -> Tcl Console). Učitavanjem ove skripte svi pinovi se definiraju istog trenutka.

Naravno, ne možete puno toga provjeriti ako ne pišete paralelno kodove za EPM570 i ESP32. Također, s obzirom da će se podaci bežično slati preko LoRa Modula (usko grlo), onda je već na samom početku potrebno razvijati kod tako da paketi podataka koji se šalju budu što manji. Na ovo se ne može puno utjecati jer se mora slati 64/128 bita podataka, međutim, sustav se može optimizirati tako da potreba za slanjem tih podataka bude minimalna, odnosno samo kad se dogodi neka promjena (kad metak aktivira zavjesu).

Osnovna arhitektura sustava, kako smo i prikazali u uvodnoj objavi, izgleda ovako:

• Na Meti: EPM570 (detekcija) -> ESP32 (obrada) -> LoRa Modul (slanje)
• Kod Strijelca: LoRa Modul (Prijem) -> ESP32 (obrada) -> Elecrow CrowPanel 7.0″ ESP32 Display (prikaz rezultata)

Pozitivna ili negativna senzorska logika

Nakon što opisani sustav proradio, trebalo se konačno odlučiti o senzorskoj logici, odnosno da li će aktivno stanje slati logičku nulu ili logičku jedinicu. Odlučio sam da senzori rade u negativnoj logici (1 = mirno, 0 = metak). Sve bi zapravo isto funkcioniralo i u suprotnoj logici, no ako se otpornici nalaze na masi (umjesto na plus polu napajanja) onda oni stalno drže I/O linije EPM570 na masi (pull-down) što doprinosi stabilnosti I/O ulaza kad su laseri isključeni. U slučaju pozitivne logike morali bi uključiti interne pull-up otpornike unutar EPM570 tako da pinove drže u nekom određenom stanju kad su senzori isključeni.

Trebalo je dakle prilagoditi Verilog kod tako da reagira na padajući brid, odnosno da detektira logičku nulu kao prolaz projektila. Međutim, postoji još jedan problem sa tom pozitivnom ili negativnom logikom, a to je odluka da li ću koristiti interne Schmitt triggere ili ne. Uobičajeno bi ih bilo dobro koristiti ali kako smo već opisivali u objavi o senzorima, za male kalibre od 4,5 mm sigurnija detekcija bi bila bez Schmitt triggera (zbog većeg naponskog praga promjene stanja u logičku nulu).

Ako ne koristim interne Schmitt triggere (koji su također i inverteri) onda negativnu logiku sa senzora mogu promijeniti u pozitivnu korištenjem if naredbe u Verilogu koja provjerava da li je senzor 0. Međutim, puno bolji je drugi način uz upotrebu internih invertera gdje se na samom početku invertira cijeli 128-bitni bus u pozitivnu logiku (1 = pogodak, 0 = mirno stanje) te interni RS latchevi rade dalje s čistom pozitivnom logikom. Ovo je bio također jedan od razloga zašto sam se odlučio na pull-down senzorski otpornik jer sam svakako želio koristiti interne Schmitt triggere.

Optimizacija upravljanja RS latchevima

Kad smo već spomenuli RS latcheve, kako što smo opisali u objavi o senzorima, oni služe za ispravnu detekciju nepravilnih impulsa koje ostavlja projektil prolazeći kroz 4 svjetlosne zavjese (dvije horizontalno i dvije vertikalno). Oblik dijabole (pješčani sat) i zračni vrtlozi iza nje mogu uzrokovati “titranje” signala (optički bounce). Također, zbog dvije dvostruke zavjese s razmakom od 7,2 mm znači da će ista dijabola aktivirati senzore u najmanje dva vala.

RS Latch pristup unutar EPM570 je savršeno rješenje za ovaj problem, međutim mora se implementirati na razini svakog pojedinačnog bita. U Verilog kodu svaki od 128 senzora ima svoj neovisni RS latch:

• Prvi kontakt (glava dijabole): Senzor pada na 0, latch skače na 1 i ostaje na 1.
• Prolazak “struka” dijabole: Senzor se na trenutak vrati na 1 (svjetlo prođe), ali latch to ignorira jer je već “zaključan”.
• Prolazak druge zavjese (7,2 mm kasnije): Čak i ako isti senzor ponovno padne na 0 zbog drugog reda zavjese, latch je već na 1 od prvog reda.

EPM570 će dakle zabilježiti “sjenu” (siluetu) dijabole kao uniju svih pogođenih senzora u oba dvostruka reda, bez obzira na titranje signala. Međutim, ovdje moramo biti sigurni da je dijabola potpuno napustila sve zavjese prije nego što se RS latchevi resetiraju za čekanje nove dijabole. Stoga je potrebno dodati softverski delay na ESP32 strani:

• Metak prolazi -> EPM570 digne trigger_alarm.
• ESP32 detektira alarm -> Odmah očita 128 bita (to traje < 1ms).
• ESP32 šalje podatke preko LoRa-e.
• Wait (100 ms): ESP32 čeka da metak fizički napusti prostor mete, 100 ms je više nego dovoljno i za najsporije projektile, a s druge strane čak ni rafalna paljba ne šalje dva projektila za redom tom brzinom.
• Reset: ESP32 šalje kratki impuls na pinRESET.

U ESP32 je dakle dodan kod za čekanje od 100 ms, a u Verilog je dodan kod koji osigurava da jednom postavljeni bit (pogodak) ne može biti poništen ničim osim hardverskim resetom.

Raspored funkcija

Tijekom razvoja i testiranja projekta događale su se različite nadogradnje sustava kao i promjene osnovnog funkcioniranja detektorske elektronike. Uvedena je dvosmjerna LoRa komunikacija, a funkcije su u konačnici raspoređene na CPLD-ove i ESP-32 na ovaj način:

Što se vrši na CPLD-ovima (brzi hardverski nivo, reda ns)

CPLD moduli (za X-os i Y-os identično) rade na taktu od 50 MHz (20 ns) i izvršavaju tri kritične funkcije koje se ne smiju oslanjati na (spori) softver:

Brzo “hvatanje” i trajno zaključavanje pogotka (sjene)

Projektil koji leti visokom podzvučnom ili nadzvučnom brzinom presijeca laserske zrake foto-rešetke u iznimno kratkom vremenu (par mikrosekundi). CPLD provjerava stanje svih 64 senzora svakih 20 ns. Ako projektil baci sjenu na senzor makar i na jedan jedini takt oscilatora, CPLD tu sjenu trajno zaključava (latcha) u registar. Ta sjena ostaje zapamćena sve dok je ESP32 ne pročita i zatim namjerno obriše preko reset linije.

Automatska selekcija geometrijske plohe (START okidač) za mjerenje brzine projektila

Senzorske rešetke za X i Y os ne leže u istoj ravnini. Laseri za svaku os (2×64 komada) raspoređeni su u dvije ravnine međusobno razmaknute 7,2 mm. To znači da su 32 senzora svake osi u jednoj plohi, a druga 32 senzora u drugoj plohi. Treća svjetlosna zavjesa koja služi samo za mjerenje brzine (STOP zavjesa) nalazi se 100 mm iza prvih zavjesa (START zavjese), odnosno 107,2 mm iza prve zavjese i 100 mm iza druge zavjese.  Kod mjerenja brzine ovo može biti problem jer za svaku os može biti aktivirana prva ili druga zavjesa, a razlika od 7,2 mm na ukupnoj udaljenosti između START i STOP zavjese unosi preveliku pogrešku u mjerenju.

Sustav za mjerenje brzine stoga mora registrirati na kojoj zavjesi se dogodio START prekid i na osnovu toga prilagoditi račun za mjerenje brzine.

Prva zavjesa sadrži neparne senzore za X-os u rasponu 1-63 i parne senzore za Y-os u rasponu 2-64. Druga zavjesa sadrži parne senzore za X-os u rasponu 2-64 i neparne senzore za Y-os u rasponu 1-63. CPLD preko parnih i neparnih logičkih maski prepoznaje je li projektil aktiviralo Plohu A (parni senzori sa geometrijskom bazom 107,2 mm) ili Plohu B (neparni senzori sa geometrijskom bazom 100,0 mm).

Kronometar visoke rezolucije (mjerenje vremena leta)

U trenutku kad prva ploha (A ili B) detektira sjenu, CPLD u roku od 20 ns pokreće unutrašnji 32-bitni brojač. Brojač broji impulse oscilatora sve dok projektil ne presiječe treću zavjesu (STOP). Rezultat je određeni broj taktova (tikova) koji predstavlja čisto vrijeme leta projektila između START i STOP zavjesa, izmjereno s točnošću od ±20 ns.

Paralelno-serijska SPI pretvorba (96 bita)

CPLD na kraju pakira sve podatke (64 bita sjena + 1 bit odabira plohe + 31 bit tajmera = 96 bita) u jedan veliki paket. Kada ESP32 podigne load_data, CPLD te podatke zaključa u pomični registar (shift_reg), te ih preko jedne linije (spi_out) šalje u ESP32 u ritmu frekvencije takta (spi_clk).

Što se vrši na ESP-32 (spori softverski nivo, reda ms)

Nakon što CPLD odradi brzo (ns) hvatanje stanja, ESP32 se budi i preuzima računakni i komunikacijski dio posla kroz svoj programski kôd.

 Upravljanje SPI sabirnicom i iščitavane podataka sa CPLD-a (96 Bita)

ESP-32 na znak CPLD-a da je došlo do promjene stanja (alarm) počinje proces čitanja podataka sa CPLD-a.

Ocjena ispravnosti detekcije

U prvom koraku ESP-32 mora prepoznati da li je promjenu stanja izazvao prolazak projektila ili neki drug kvar na senzorima (trajna sjena uslijed otkaza senzorske linije, uslijed pada nekog predmeta na senzore i slično). Stoga, nakon što pročita 64 bita podataka o senzorima sa svakog CPLD-a, ESP-32 radi logičku provjeru tih podataka. Provjera se radi na način da se nakon svakog čitanja novih podataka, CPLD-ovi resetiraju, a zatim se nakon 100 ms ponovno čitaju podaci sa CPLD-ova. Ukoliko je promjenu (sjenu) izazvao brzi projektil, drugo čitanje podataka će se razlikovati od prvog (bit će pročitane sve nule). Ukoliko pak drugo čitanje bude isto kao i prvo, to znači da postoji neka trajna sjena, odnosno kvar. U tom slučaju ESP-32 automatski ažurira masku kvarova i šalje paket tipa 4 (Kvar) na CrowPanel kod strijelca, kako bi se na ekranu detektirao kvar.

Fizikalni proračun brzine projektila

ESP32 iz CPLD-a dobiva samo sirove tikove (broj impulsa u određenom vremenu) i zastavice (da li je aktivirana prva ili druga START zavjesa). Stoga, za točan izračun brzine, ESP-32 prvo provjerava koja je START baza okinuta te na temelju toga postavlja bazu za duljinu na 0,1000 m ili na 0,1072 m. Nakon toga pretvara broj tikova u sekunde kako bi se dobila vremenska baza (vrijeme = broj tikova x 0,00000002 s). Iz ovih podataka računa brzinu (brzina = duljina / vrijeme). S obzirom da podaci dolaze sa oba CPLD-a neovisno, ESP-32 izračunava brzinu na oba CPLD-a, a zatim računa srednju vrijednost kako bi mjerenje bilo točnije. Na kraju ESP-32 taj prosjek pretvara u format formule kako bi ga spakirao u 32-bitnu varijablu za LoRa slanje.

Prikupljanje telemetrije i bežično odašiljanje (LoRa upravljanje)

ESP32 periodički (svake sekunde) očitava vanjske senzore za brzinu i smjer vjetra (anemometre), senzore za temperature sistema (DS18B20), te na ADC ulazu mjeri napon akumulatora. Sve te podatke pakira u točnu definiranu strukturu od 32 bajta i preko LoRa podatke šalje na CrowPanel.

Prihvat naredbi sa CrowPanela (Ventilator, Kalibracija, Reset)

U unutrašnjosti loop() petlje, ESP32 neprekidno provjerava dolazne podatke sa LoRa. Kada sa CrowPanela stigne paket koji počinje s 0xBB, ESP32 provjerava Checksum i na osnovu toga inicira paljenje određenih elektroničkih releja ili pokreće automatsku kalibraciju lasera preko digitalnog potenciometra.

ESP32-WROOM-32D vs ESP32-S3-WROOM-1

Projekt sam počeo razvijati za ESP32-WROOM-32D, no pokazalo se da ipak trebam MCU sa više GPIO pinova. Stoga sam prešao na prvi jači ESP-32 razvojni model naziva ESP32-S3-WROOM-1.

Razlika između ESP32-32D i naprednijeg ESP32-S3 je prilično velika. Iako oba čipa dolaze iz iste tvornice (Espressif) i imaju dvojezgrene procesore na 240 MHz, ESP32-32D koristi stariji Xtensa LX6, dok ESP32-S3 koristi napredniji Xtensa LX7 procesor. Ovaj procesor je razvijen s potpuno novom arhitekturom, većim brojem pinova i namjenskim hardverom za grafiku, umjetnu inteligenciju i bežičnu stabilnost.

Glavna prednost LX7 za moj projekt je ugradnja vektorskih uputa (vektorska proširenja). To znači da S3 može unutar samo jednog takta procesora izvršiti teške matematičke operacije nad više brojeva odjednom, što je poželjno primjerice za moj proračun brzine iz CPLD tikova.

Ipak, glavni razlog prelaska na ESP32-S3 je taj što ESP32-32D ima premali broj iskoristivih GPIO pinova. Fizički ih na modulu ima 25, međutim, 4 pina su samo ulazna i ne mogu generirati nikakav izlazni napon. Također, 6 pinova su strapping pinovi koji moraju prilikom boota biti u određenom logičkom stanju, inače procesor ulazi u neki drugi mod rada ili je boot blokiran na drugačiji način. To znači da je kod ESP32-32D pločice na raspolaganju svega 15 „čistih“ GPIO pinova. ESP32-S3 pak ima na modulu 36 GPIO pinova, od čega je 5 pinova strapping, a još dva su rezervirana za Flash i PSRAM. To znači da je na raspolaganju 29 „čistih“ GPIO pinova ili 14 više nego kod ESP32-32D.

“Sigurni” GPIO pinovi na ESP32-WROOM-32D.

“Sigurni” GPIO pinovi na ESP32-S3-WROOM-1.

Kritični “Strapping” pinovi na ESP32-WROOM-32D:

• GPIO 1 (TX0 – Transmit) – Preko njega ESP32 šalje podatke na Serial Monitor. Ovaj pin treba izbjegavati za drugo korištenje.
• GPIO 2 – Kod početnog paljenja uvijek mora biti na LOW ili ostavljen nepovezan (standardni način rada i način programiranja). Ako je ovaj pin povučen na HIGH tijekom paljenja, ESP32 će pokušati ući u nepostojeći mod rada ili će se “zamrznuti” i programski kod se uopće neće pokrenuti. Obično je na njega spojena ugrađena LED dioda.
• GPIO 3 (RX0 – Receive) – Preko njega ESP32 prima novi program s računala. Ovaj pin treba izbjegavati za drugo korištenje.
• GPIO 5 – Kod početnog paljenja mora biti na HIGH (standardni način rada). Ako je ovaj pin povučen na LOW tijekom paljenja, ESP32 pokušava ući u mod za “SDIO slave” (komunikacija s SD karticama na poseban način). To obično uzrokuje da se ESP32 uopće ne pokrene ili uđe u “boot loop”. Budući da ovaj pin ima interni pull-up otpornik, on će sam otići u HIGH, međutim treba paziti da ga spojeni izlaz ne povuče na LOW.
• GPIO 12 – Kod početnog paljenja mora biti na LOW. Ako je HIGH kod paljenja, može doći do problema s naponom flash memorije (pokušat će raditi na 1,8V umjesto 3,3V), što će spriječiti podizanje sustava.
• GPIO 15 – Kod početnog paljenja mora biti na HIGH. Šalje debug poruke na Serial portu pri paljenju. Budući da ovaj pin ima interni pull-up otpornik, on će sam otići u HIGH, međutim treba paziti da ga spojeni izlaz ne povuče na LOW. U tom slučaju će se spriječiti ispis na Serial monitoru, no obično se normalan start ipak pokrene.
• GPIO 34, 35, 36, 39 – isključivo ulazni pinovi

Kritični “Strapping” pinovi na ESP32-S3:

• GPIO 0: Kod početnog paljenja mora biti na HIGH. Kontrolira hoće li se čip pokrenuti u normalnom radnom načinu (HIGH) ili u modu za flashanje koda s računala (LOW). Na ploči obično postoji vanjski otpornik (Pull-up) koji ga drži na HIGH, međutim treba paziti da ga spojeni izlaz ne povuče na LOW.
• GPIO 3: Određuje način rada JTAG debuggera pri podizanju sustava.
• GPIO 45: Izuzetno opasan pin! Kontrolira napon napajanja same unutrašnje Flash/PSRAM memorije (odabir između 3.3V i 1.8V). Ako ga vanjski čip pri paljenju povuče na HIGH, procesor će postaviti pogrešan napon i trajno izgubiti vezu s vlastitom memorijom programskim kodom.
• GPIO 46: Mora strogo biti LOW (uzemljen) u trenutku paljenja kako bi čip uopće dopustio podizanje sustava iz ROM memorije. Ako je u trenutku paljenja na HIGH, boot proces propada.
• GPIO 15 (ili u nekim dokumentacijama označen i kroz OTP postavke): Može utjecati na slanje kontrolnih logova pri podizanju sustava.
• GPIO 47 i 48 – Iako tehnički nisu strapping pinovi, kod velikog broja tvorničkih ESP32-S3 modula (pogotovo onih koji imaju ugrađen ultra-brzi Octal PSRAM) ovi pinovi su interno čvrsto ožičeni za rad same memorije unutar metalnog kućišta. Njihovo korištenje u kodu kao obični ulaz ili izlaz trenutno uzrokuje hardverski krah (Crash/Panic). Zato ih je najbolje izbjegavati za bilo kakvo spajanje.

Wi-Fi komunikacija

Što se tiče bežične Wi-Fi komunikacije, ESP32-WROOM-32D podržava stariji Wi-Fi 4 (802.11 b/g/n) i Bluetooth 4.2 / BLE standard. PCB antena je integrirana na pločici i iznimno je osjetljiva na položaj unutar metalnog ili plastičnog kućišta mete. ESP32-S3 donosi moderniji Wi-Fi 4 sa stabilnijim protokolima i napredni Bluetooth 5.0 / BLE 5.0 s proširenim dometom (Long Range). Modul dolazi s ugrađenim IPEX/U.FL konektorom za vanjsku antenu omogućuje da se koaksijalnim kabelom izvuče antena izvan metalnog kućišta mete. Wi-Fi planiram koristiti za bežično spajanje anemometara.

Raspoloživa memorija

Što se tiče memorija, ESP32-WROOM-32D ima 520 KB unutrašnjeg SRAM-a, a ESP32-S3 ima 512 KB SRAM-a. Iako na papiru ima 8 KB manje od starog ESP32 (512 naspram 520), ova memorija kod S3 modela je konstruirana na potpuno novoj arhitekturi i izravno je povezana s unutrašnjom Cache memorijom. To znači da procesor može komunicirati s radnim prostorom i vanjskim PSRAM-om neusporedivo brže i bez stvaranja uskih grla, što u mojem konkretnom slučaju osigurava da paralelno čitanje 96 bita s CPLD-a prolazi puno brže. Također, memorija od 520 KB unutar ESP32-WROOM-32D je rascjepkana na tri bloka: SRAM0, SRAM1 (koji služe za sustav i drajvere) te SRAM2 (oko 328 KB) koji je zapravo jedini stvarno slobodan prostor za odvijanje programskog koda.

ESP32-WROOM-32D ima 448 KB ROM memorije, a ESP32-S3 ima 384 KB ROM memorije. ROM memorija kod ESP32-S3 je smanjena jer su drajveri optimiziraniji i zauzimanju manje memorije. Ovdje je zapravo bitan dodatni unutrašnji RTC RAM za Deep Sleep mod (čuvanje podataka u modu za uštedu energije) koji je kod ESP32-S3 dvostruko veći, 16 KB u odnosu na 8 KB kod ESP32-WROOM-32D.

Neki ESP-32 moduli imaju dodatni vanjski PSRAM memorijski čip (WROVER modeli). Za stranu mete (TX kôd), gdje nema teške LVGL grafike, velikih jezičnih matrica niti slikovnih buffer-a, vanjski PSRAM čip nije potreban. Čistih 512 KB unutrašnjeg SRAM-a unutar samog ESP32-S3 čipa je i više nego dovoljno za paralelno čitanje CPLD-a i slanje LoRa paketa. Ipak spomenuti ćemo da i ovdje postoje razlike kod dvije razvojne pločice koje uspoređujemo. Kod starijeg ESP32 čipa, veza između procesora i vanjskog PSRAM-a izvedena je preko standardne Quad SPI (4-bitne) sabirnice sa tipičnim radnim taktom od 40 MHz ili maksimalno 80 MHz, ali uz velika unutrašnja kašnjenja (latenciju). Kod S3 modela uveden je napredni Octal SPI (8-bitni) podsustav. Sabirnica radi na stabilnih 80 MHz do 120 MHz, no koristi DDR (Double Data Rate) tehnologiju. To znači da se podaci šalju i na uzlazni i na silazni rub takta, čime se efektivna brzina u praksi penje na ekvivalent od 240 MHz. Kod ESP32-32D Flash i PSRAM dijele istu unutrašnju sabirnicu, dok ESP32-S3 ima potpuno odvojen Cache sustav za Flash i PSRAM. To znači da bi za našu primjenu mogao istovremeno čitati balističke podatke iz Flasha i pisati po PSRAM-u, bez ikakvog međusobnog čekanja ili zagušenja sabirnice.

Razlika u cijeni između ESP32-32D i ESP32-S3 je nekoliko eura (4 eura naspram 8 eura) pa ako radite nešto ozbiljniji projekt ili vam treba ESP32 pločica za različite eksperimente, onda je svakako noviji ESP32-S3 bolji izbor.

Za elektroničku metu GPIO pinove sam definirao na slijedeći način:

Arduino programi za ESP32

Već smo vidjeli kod razvoja Verilog koda da nije moguće potpuno odvojeno programiranje EPM570 modula i ESP32 modula za stranu mete (predajnik) i stranu strijelca (prijemnik). Sustavi moraju međusobno komunicirati te se moraju i paralelno razvijati.

AI je kreirala prve programske kodove za EPM570 i ESP32 prema mojim zahtjevima. Odmah je implementirano i bežično slanje preko LoRa modula. Arduino kodovi za oba ESP32 imaju Debug logove i Serial print naredbe kako bi se mogao provjeriti rad programa jer nije realno očekivati da će sve proraditi od prve.

Trebalo je desetak većih dorada i nadogradnji koda, nekoliko izmjena hardvera te nekoliko desetaka rješavanja raznih bugova da se dobije prvi funkcionalni programi.

Prvi testni kodovi

Općenito gledano, bilo je više “prvih testnih kodova” koji su profunkcionirali u raznim fazama razvoja projekta. Prvi kodovi su uključivali samo komunikaciju između jednog EPM570 CPLD-a i jednog ESP32. U toj fazi svjetlosna zavjesa još uvijek nije bila kompletirana. Mogao sam raditi samo simulaciju okidanja senzora, a i to se moglo izvesti samo probno, na nekoliko senzora. Jednostavno je nemoguće „u zraku“ stabilno povezivati i simulirati sve 64 senzorske linije. Brzina CPLD-a je 50 MHz i bilo kakve nepotrebno duge žice, parazitski kapaciteti i slične pojave mogu izazvati lažna i nasumična okidanja. Kod ovakvih sustava, testiranje koje možete napraviti na testnim pločicama i sa priručnim napajanjima su vrlo ograničena.

Tek kada sam napravio PCB-ove za metu (iako sam znao da to nije konačna verzija istih) mogao sam nastaviti sa proširenim i detaljnijim testovima.

U početku sam bilježio kronologiju razvoja softvera, međutim, gotovo svaka nadogradnja je  generirala različite softverske i hardverske probleme koje je trebalo sustavno rješavati. Pojedinačno opisivanje svakog takvog problema bilo bi preopširno, no to su sigurno posve očekivani problemi sa kojima se susreće svaki programer sličnih kodova. U konačnici sam došao do stabilnih inačica koda za CPLD-ove (Verilog), koda za ESP32-S3 (Arduino) na meti i koda za ESP32-P4 za monitor strijelca koji sadrži preko 5000 linija čistog koda. Vjerojatno će i dalje trebati manje dorade ovih kodova, no mogu reći da sustav već i sada radi posve funkcionalno i ispunjava sve postavljene zahtjeve.

Prve PCB 

Tiskane pločice (PCB) za EPM570 vjerojatno će zadržati ovakav dizajn i u finalnoj inačici razvoja.

Tiskane pločice za povezivanje dva EPM570 i LoRa modula sa ESP32-32D. S obzirom da sam morao zamijeniti LoRa SX1278 (Ra-2) sa LoRa SX1262 te proširiti broj GPIO pinova i preći na ESP32-S3, ova tiskana pločica će se bitno mijenjati.   

Prvo realno testiranje

Kad su programi bili dovoljno razvijeni i PCB kompletirane, napravio sam prvo „sobno“ testiranje detekcije sa zračnim pištoljima na dijabole 4,5 mm i kuglice 6 mm.

Očekivano, dijabole od 4,5 mm u cca 40% slučaja ne prekinu obje zavjese, odnosno dijabola se provuče između dvije laserske zrake bez da ih dovoljno zakloni. Kuglice od 6 mm imaju detekciju od 100%, a vjerujem da bi tako bilo i za kalibar 5,5 mm.

Sada već imam ideju kako poboljšati svjetlosnu zavjesu tako da detektira kalibar 4,5 mm, no ako u tome i ne uspijem, ovo je ipak „long range“ meta predviđena za kalibre 5,5 mm i veće. Problem je u tome što sve laserske zrake trebaju biti cijelom dužinom na međusobnom razmaku od točno 4 mm i svi laseri moraju biti temperaturno stabilizirani tako da daju konstantnu snagu. Ovo tehnički nije lako postići, no radim na tome.

Elektronička meta je prilično složen projekt gdje je potrebno paralelno razvijati i stalno međusobno prilagođavati pojedine hardverske i softverske dijelove. Sam sistem lasera i foto-senzora je sustav kod kojeg treba rješavati niz praktičnih problema. To su problemi svjetlosnih polusjena koji mogu dovesti do nedovoljnog pada napona za promjenu logičkog stanja, problemi temperaturne ovisnosti i drugih nestabilnosti jačine zračenja lasera, problemi same geometrije svjetlosnih linija i tako dalje. Neke problemi se mogu riješiti ili barem ublažiti softverski, neke probleme je treba rješavati isključivo hardverski.

Zbog visoke frekvencije rada detektorskog sustava potrebno je izraditi kvalitetne tiskane pločice, a njih nije baš tako jednostavno i jeftino mijenjati kako se naiđe na neki problem. Stoga je puno stvari treba predvidjeti unaprijed, a ako negdje postoje dvojbe, onda svakako treba ostaviti prostora i osmisliti pločice za što lakšu prenamjenu i mogućnost testiranja što više mogućnosti.