Jaký ARM na ADC a zpracování signálu

Nikoho od ničoho neodradzujem :slight_smile:
Každý je zvyknutý na “svoje” vývojové prostredie. Viem, že debuger, JTAG a kde čo mnohí úspešne využívajú a šetrí im to kopec času. To je úplne v poriadku a tak to má byť.

Osobne som používanie debugera zavrhol pred mnohými mnohými rokmi po tom, čo mi jeho použitie zabralo cca mnoho dní života pri snahe rozchodiť komunikáciu s LCD displejom. Pri krokovaní cez debuger mi všetko fungovalo, pri spustení sw “naostro” sa na displeji nič nezobrazilo. Chyba bola samozrejme medzi klávesnicou a stoličkou. Nedodržiaval som správne povinné časy čakania medzi zápismi jednotlivých príkazov. No tak som bol upnutý na to, že debuger mi pomôže, že som nad tým tých pár dní s nervami strávil a hľadal chybu kde kade len nie na správnom mieste. Jasné, že to v konečnom dôsledku bola moja chyba.

Odvtedy som si povedal, že sa budem maximálne vyhýbať pri ladení sw niečomu, čo mi do aplikácie zavedie náhodilý podstatný časový prvok, ktorý mi môže podstatne ovplyvniť správanie periférií a teda aj celej aplikácie.

Preto som si vyvinul iné metódy, ktoré veľmi úspešne využívam a v konečnom dôsledku mi doteraz nikdy debuger pri vcelku efektívnej práci ani nechýbal. Nakoniec som vždy tie piny procesora určené napríklad pre JTAG radšej zužitkoval na niečo užitočnejšie ako na ladenie aplikácie. Lebo pinov má MCU vždy málo a väčšie púzdro z viacerými pinmi sa už málokedy do aplikácie zmestí :slight_smile:

Základom je “testovacia” LEDka, ktorú sw ovláda tak, že mi pravidelne bliká v nastavenej striede a frekvencii. Hociktorá časť sw môže rutine starajúcej sa o LED vnútiť na niekoľko periód inú striedu a frekvenciu. Tak napríklad viem vidieť, že bol prijatý nejaký bajt. Po krátkej zmene blikania LED znovu bliká “po starom” až do ďalšieho vnútenia zmeny. Naraz viem takto sledovať viac rôznych stavov, ktoré môžu nastávať asynchrónne a teda aj súčasne bez toho, aby bol nejaký vizuálne premaskovaný inými stavmi.

UART nevyužívam na výpis nejakých ladiacich správ. To sa mi vidí ako veľmi zahlcujúce pozornosť človeka, teda mňa. A takýto prístup často používaný vo svete PC sa mi vidí vo svete MCU ako veľmi neefektívny a zdĺhavý, obzvlášť keď sa sústredím len na jeden bajt, ktorý mi niečo indikuje - teda indikuje či sa niečo posra… alebo nie. Pri výpise hlásení je tam príliš veľa balastu, ktorý jednak zdržuje komunikáciu a jednak je zbytočný. Okrem toho je potrebné zahlcovať pamäť zariadenia ďalším protokolom okrem natívneho (napríklad MODBUS) a ešte by bolo treba aj nejaký mechanizmus, kedy sa má ktorý protokol aktivovať, pričom protokol na výpis ladiacich správ považujem za kvalitatívne nič neprinášajúci.

Na ladenie používam normálny protokol podobný MODBUSu a len pozerám hodnoty nejakých premenných vo vybranej oblasti pamäte ktoré mi indikujú, čo sa mi v systéme deje. Napríklad či driver včas a či vôbec odpovedal na požiadavku a ktorej časti sw konkrétne, ako bežia čítače, atď. Často si interné testovanie nechávam aktívne aj v živej aplikácii. Potom mám možnosť si z odstupom času pozrieť, čo prapodivnoúchvatné sa v aplikácii dialo za dlhšie obdobie ak má klient nejaké výhrady či podozrenia voči správaniu zariadenia.

Moje zariadenia buď musia bežať v sieti (najčastejšie RS485), alebo môžu bežať v sieti. Takže UART na komunikáciu používam vždy.

Nepotrebujem vedieť kedy presne sa čo udialo. Stačí mi iba koľko krát a v akom mieste programu. Pri zmene (ale nie častejšie ako 1x za sekundu) sa táto prepíše aj do EEPROM, takže po reštarte mám info zachované. Samozrejme nemá zmysel počítať, že sa niečo stalo 2^56 krát. Úplne stačí počítadlo do jedného bajtu. Ak sa niečo stalo za rok 255x a viac, je to už na pováženie. Hlavne sa tým nezoderie EEPROMka. Dôležité je tiež zapísať, z ktorého miesta programu prišlo hlásenie, že niečo nie je v poriadku (napríklad premenná mala hodnotu mimo očakávaný rozsah). Tam sa potom môžem sústrediť na hľadanie problému.

Ak chcem odpamätať nejaký stav viacerých premenných pri nejakej udalosti, jednoducho si ich v rámci normálneho behu programu odkopírujem do poľa prístupného cez protokol a pozerám sa na ne. Aj tak treba deje ktoré trvajú kratšie ako sekundu nejak predspracovať, lebo moje oko kratší dej na monitore ani nezachytí. Zatiaľ sa mi darí pre moje potreby veľmi úspešne.

Pri preprogramovávaní sw to mám spravené tak, že môj vlastný bootloader posiela do mcu iba tú časť programu, v ktorej sa zmenil kód a to porovnaním s predchádzajúcim HEXom. Občas musím dolaďovať aplikáciu podľa nových požiadaviek užívateľa i cez vzdialený prístup. Potom je celkom dobré mať rovnaké “vývojové prostredie” pre použitie na stole i na diaľku. A tak u mňa moc debuger miesto nemá :slight_smile:

Samostatná kapitola je ladenie protokolov a hw pôsobenia perifériami na okolie. Tam nejaké krokovanie sw asi toho moc neporieši. Tu je základom aspoň informačný osciloskop a pre použitie s MCU dobrý logický analyzátor so sw výbavou analýzy protokolov. Používam ZEROPLUS Logic Analyzer LAP-C a okrem osciloskopu k PC (potrebu použiť ho mám zriedkavú) hlavne malý prenosný osciloskop DSO quad. Okrem trochu “zvláštneho” ovládania dvoma multifunkčnými prepínačmi tlačítkami som s ním veľmi spokojný.

Na vyhodnotenie správania vstupov používam buď nasoftené “zrkadlové” zariadenie, alebo pri zložitejších signáloch dvojkanálový generátor priebehov s možnosťou zvoliť fázový posun medzi kanálmi, generovať periodické priebehy až s 8192 vzorkami na periódu a s ďalšími fičúrami.

Takže aby som to zhrnul.
Za roky práce som si vytvoril “debugovacie” prostredie v ktorom hrajú hlavnú rolu:

  • LEDka vyhradená na testovacie účely

  • Načítanie premenných cez UART protokolom (napríklad) MODBUS

  • základné sw jadro, ktoré vie spravovať hlásenia neštandartných stavov v samotnej aplikácii vrátane zápisu do EEPROM a počítania času behu aplikácie či voľného času MCU v relevantných časových intervaloch

  • bootloader umožňujúci prepísať iba časť pamäte v ktorej bola po preklade zmena s nejakou rozumnou granularitou, napríklad 32B alebo 128B.

  • Laboratórne prístroje ako log. analyzér, osciloskop, generátor, alebo “zrkadlové” zariadenie