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

ja sa živím dlhodobo čistým C-čkom. O C++ som ani nezavadil, lebo mi doteraz v embeded nechýbalo nič, na čo by som potreboval C++.
Okrem toho, ak sa embeded chceš zaoberať seriózne, tak si pozri pravidlá MISRA a tiež pravidlá na písanie bezpečného sw. Tam si s takým malloc ani len neškrtneš.
Napríklad si aspoň pozri odkazy z

en.wikipedia.org/wiki/Safety_integrity_level

Takže ak sa svet rozdelil na C++ VHDL, ja rozhodne nepatrím ani do jednej skupiny.

Všetky STM32L/F majú zabudovaný bootloader cez UART. Nepotrebuješ preto exaktne žiaden programovací nástroj.
k Debugovaniu sa mi doteraz neosvedčilo nič lepšie ako LED zavesená na nejakom pine MCU. Rôznym blikaním ma informuje o rôznych stavoch pokiaľ nerozchodím UART. A cez UART získam z MCU ďaleko viac reálnych údajov ako cez bárs aký debuger.
Ale to je moja osobná skúsenosť a postupy, kde kto používa zas tie svoje.

STM32 (skús pozrieť špeciálne STM32F3) majú solídne vlastnosti čo sa týka presnosti (16bit) a rýchlosti AD prevodu. Trochu otázna je kvalita AD referencie. Zas navzorkovať určitý priebeh a cez FFT zistiť fázový posun s presnosťou lepšou ako je frekvencia vzorkovania by viac menej malo ísť celkom hravo.

Udělal jsi mi radost :wink:

Díky :slight_smile:

Teď se dívám na Farnell…

A nenašel jsem tam žádnej STM32M3F

Trochu jsem to procházel a strašně se mi zalíbil tento:
cz.farnell.com/stmicroelectronic … dp/2503304

(Jen nikde není vývojovej kit :frowning:((
Přitom je fakt top…

Ty kity pro mě nejsou vůbec žádná sláva… Asi to budu muset jedině namalovat…

Martine, Ty s těma STM32 děláš, že ho tak zrazuješ od debuggeru ? Oni jsou přeci jen o dost složitější než AVR8. Ty metody pro analýzu chodu programu, které doporučuješ, jsou samozřejmě naprosto v pořádku, ale pokud uživatel tu platformu nezná, tak myslím, že něco preciznějšího by mu jen pomohlo. Jako profík, jistě uznáš, že kvalitní (adekvátní) vybavení šetří čas a tudíš i peníze. Pokud bude programovat a současně vypisovat přes UART, bude to dost nepohodlené. Kdyby si pořídil J-LINK (čínská kopie stojí $15), tak kromě programování a debuggování, lze přes něj a GDB server normálně tisknout do konsole/terminálu a ušetří jeden fyzickej UART.

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

Já jsem po Tobě nechtěl takový vyčerpávající elaborát, ale když už si to napsal tak děkuji. Přečet jsem si to celé. Nic méně si mi neodpověděl na otázku :wink:

To, že si chybně vyhodnotil používání jakéhosi nástroje (jehož kvalitu ani nemohu posoudit) a zatvrdil si se proti jeho používání je podle mě šloda. Podle mě jsi buď moc konzervativní, nebo máš extrémně specifické aplikace a nebo obojí.

Doba pokročila, a ty nástroje se hodně zlepšili.

Ohledně logování hlášek přes uart anebo na sdkartu v lidsky čitelné podobě jako cas-udalost-data , tak to leckdy může být jediná možná metoda jak dlouhodobě monitorovat a testovat hodně koplexní software aniž by u toho člověk zešedivěl.

Ďakujem za trpezlivosť a prečítanie :slight_smile:

Myslím, že som na Tvoju otázku odpovedal hneď na začiatku, aspoň to vnímam ako odpoveď na ňu:

"Nikoho od ničoho neodradzujem :slight_smile: "

Je mi úplne jasné, že minimálne 2^255 ciest vedie k riešeniu. A nástroje ako JTAG, či rôzne debugery (aj 1 wire) sa hojne používajú bez pochyby preto, lebo sa osvedčujú.

To je v absolútnom poriadku a tak je to správne, tak to má byť a mám z toho radosť.

No jednoducho pri riešení mojich problémov pri programovaní som postupne nasadzoval väčší a väčší kaliber na riešenie, až kým som problém nevyriešil. K debugeru ako k nástroju bezpochyby skvelému u mňa jednoducho doteraz nikdy neprišlo. Skrátka, nepotreboval som ho.

Kým by som nad ním ako nad možným nástrojom na hľadanie problému začal uvažovať, niektorá iná mnou hojne používaná metóda zabrala skôr.

To je všetko. Nie je to ani dobré, ani zlé, ani konzervatívne a ani progresívne.

A či by som s debugerom odhalil chybu skôr ako s mojimi naučenými (schválne nepíšem konzervatívnymi, lebo len preto že metódy fungujú ešte nemusia byť hneď konzervatívne :slight_smile: ) metódami?

Ťažko povedať, koľko času by som potreboval venovať tej ktorej platforme aby som vedel debuger efektívne používať. Až po dôkladnom naučení práce s ním, by som (možno) vedel moje problémy riešiť. To do toho celého treba zarátať. No zatiaľ som nemusel prekročiť osobný “Rubikon”, aby som sa musel zaoberať niečím takým ako je debuger :slight_smile:

Avšak každému kto cíti, že by ho mal používať, fandím.

Ta otazka byla jestli už jsi stěma ARM procesorama seriózně pracoval.
A ptal jsem se proto, že Tebou používané metody na odhalování chyb v kódu jsou sice funkční, ale jen v případě, že tou ledkou jsi schopen blikat, čož u těch armů nebudeš, pokud správně nenastavíš některé věci a to nezjistíš bez spolehlivého debuggeru. Hlavně ten program nejspíš sletí a zůstane hnít v hartfaultu aniž by programátor tušil proč.
O tom celá ta debata vlastně je/byla. To proto, že zakladatel vlákna řešil jak začít a já nabyl dojmu, že s mcu asi nic nedělal a tudíš bude potřebovat lepší vybavení a Ty jsi napsal, že to vlastně ani moc nepotřebuje. Když už danou mcu platformu znáš a umíš napsat kód na jistotu a máš dost zkušeností, tak je to trochu jiná situace, než když někdo začíná.

Souhlasím s Radiusem. Dokud jsem dělal s AVR, tak mi taky stačilo pár ledek nebo uart na výpisy. Rozčarování ale přišlo s ARMama, když jsem těmahle metodama vůbec neměl šanci zjistit že mi program spadl do hard faultu, natož abych věděl proč, což je celkem běžná událost při vývoji. Složitější aplikaci např. s RTOSem si bez debugeru už neumím představit. Nakonec jsem za pár korun koupil z ebay ST-LINK a podařilo se mi ho rozchodit kromě STM32 i se Stellarisama.

S STM32 som zatiaľ robil nejaké pokusy.
Zvukový prehravač, disk pre PC cez USB, ovladač PC, práca s SD kartou a FAT, samozrejme blikanie LEDkou a ešte nejakých pár vecí. Robil som s F103 a L476.

Keďže to buď bolo buď na školeniach ST-čka v ich výcvikovom centre, alebo podľa nejakého kurzu step by step, kódy boli predžuté a robil som v nich iba úpravy, respektíve som staval na niečom funkčnom čo som potom rozkošatel do želaného stavu podľa potreby. Aj preto veci fungovali relatívne rýchlo a bez zásadných problémov. Naposledy som s nimi robil pred rokom či dvoma. Nie je to (zatiaľ) moja kľúčová pracovná doména.

Martine, díky moc za vyčerpávající reakce!! (téma jsem založil já)

… zaujalo mě ale nejvíc to, že jsi něco dělal s L476…
já jsem si právě teď koupil tohle:
st.com/en/evaluation-tools/3 … overy.html

Znáš to??
…dost by se mi hodil nějaký vzorový projekt (ideálně to, co je nahrané na vývojové desce) Když rozjedu začátek, tak už to pak bude OK (na piny a extra složité časování ani moc nechci šahat)

  • jaké vývojové prostředí je nejlepší??

Že Ty nečteš dokumentaci ? :wink:

The demonstration software is preloaded in the STM32L476VGT6 Flash memory. The latest
version of the demonstration source code
and associated documentation can be
downloaded from www.st.com/stm32l4-discovery

Tuhle větu už jsem četl i někde jinde…

Jenže jsem asi úplně blbej a nikde tam nevidím žádný kód/ vzorový projekt, apod…

Tak to jsme blbý už dva, taky tam nic nevidím.

Našel jsem tohle, tak aspoň něco málo. Snad ti to pomůže aspoň trošku (hned první položka v tabulce).

Edit: A ještě tohle (GitHub): github.com/rebelbot/OptimizerLesson/tree/master/Drivers/BSP/STM32L476G_EVAL

Dík!
Aspoň něco…
Ještě jsem našel i nějaký pdf, kde je krok za krokem popsané, jak se generují ty počáteční kódy s definicema pinů a časovače v STM32 Cube… zkusím to dát nějak dohromady…

(v druhém odkazu jsou asi bezcenné knihovny…jsou totožné s knihovnami, které se mi automaticky vkládají do projektu, když ho zakládám v STM32 Cube)

Ještě bych se od vás rád dozvěděl, jaké vývojové prostředí na tohle používáte ?!?

  • nemá STM nějaké dobré zastoupení v čr? Školení taky někdo dělat musí… kontakt bych moc ocenil…

Já osobně ještě žádný, zatím se rozhlížím jakej kit si pořídit a tak. Mám pár věcí od NXP, v tomto ohledu jsou na tom líp (prostředí + dokumentace + examples), jenže mám takovej subjektivní pocit, že ty jejich čipy narozdíl od ST nic moc nevydrží a jsou navíc dražší. Ani jsem nevěděl že nějaký STM32 Cube existuje, počítal jsem klasicky s Eclipse nebo C::B nastavovacím masochismem.

Můžeš to PDFko prosímtě taky linknout?

Taky mám LPC1768…rozjel jsem na tom dost věcí…
Jenže teď potřebuju AD převodník a v tom je STM daleko před NXP :frowning:

Tak jsem musel přesedlat…

pdf se mi podařilo najít, je zde:
emcu.it/SILICA-STDay-2016/X/HO/Demo1/CUBE-HAL-LL-L4DiscoveryStartUp.pdf

Na straně 26 a dál je vidět, že by příklady měly existovat…v adresáři je magické slovo examples…ale ve skutečnosti to zřejmě není součástí ani toho programu…

Tak už mi nikdo neporadíte??

Rád bych dostal nějaké kontakty na školitele, apod…

V Prahe je školiace centrum ST. Napíš priamo pánovi Pokornému. Sú tam všetci veľmi ochotní a ústretoví. Bavia sa normálne česky. Posielam Ti torzo pozvánky na školenie na L476, ktoré bolo vo februári tohto roku.

Ďalej Ti posielam odkazy na nejaké ich tréningové prezentácie.
Na Tvojom mieste by som Tvoje otázky komunikoval priamo s výrobcom. Veď tie procesory sem nepadli z neba že by o nich nikto nič nevedel. Ale to platí úplne vo všetkom. Doteraz iba z FTDI boli tak “povznesení”, že sa neobťažovali s odpoveďou. A tu máš možnosť pýtať sa v rodnej reči. Tak prečo to nevyužiť.

Maximálne narazíš na problém, ako to celé vyvíjať na nejakom Open Source.
Skús si rozchodiť Eclipse. Veľa ľudí v ňom robí a sú spokojní, veľa ľudí ho neznáša. A mnoho ďaľších vrátane Coocoxu. Nerobím, neviem poradiť.


STM32 L4 Hands on Workshop - Prague

Organizátor:

Tomas POKORNY <tomas.pokorny@st.com>

Popis:

Dear Attendee,

we are pleased to welcome you in this STM32 L4 hands on workshop

The event will happen here:

STMicroelectronics
IBC building
Pobrezni 3, 18600
Prague, Czech Republic
We are looking forward to meeting with you.

Kind regards,

STM32 L4 hands workshop


st.com/content/st_com/en/sup … ining.html

Potvrzuju, že ačkoliv ECLIPSE nemám rád, tak jsem ji rozjel asi během 2h s JLINK a GCC a několika pluginy tak, že překládá, nahrává kód a debuguje. Otestováno na STM32F10x