forum.mcontrollers.com - hlavní stránka forum.mcontrollers.com - fórum

 

.: fórum - hlavní stránka :.
Technology Stronghold by Rudolf Vesely
How to build Microsoft System Center hosted cloud series
FAQFAQ HledatHledat Seznam uživatelůSeznam uživatelů Uživatelské skupinyUživatelské skupiny RegistraceRegistrace
ProfilProfil StatistikaStatistika Soukromé zprávySoukromé zprávy PřihlášeníPřihlášení

 
Jaký ARM na ADC a zpracování signálu
Jdi na stránku Předchozí  1, 2, 3  Další
 
Přidat nové téma   Zaslat odpověď    Obsah fóra mcontrollers.com -> ARM
 
Radius
Profesionál
Profesionál


Založen: 22.2.2013
Příspěvky: 478

PříspěvekZaslal: 21 listopad 2016, 13:49    Předmět: Citovat

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.
_________________
x51 , ARM , XILINX
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Odeslat e-mail Zobrazit autorovy WWW stránky
 

 
Martin
ATmega pouzivatel
ATmega pouzivatel


Založen: 5.1.2008
Příspěvky: 1460

PříspěvekZaslal: 24 listopad 2016, 2:48    Předmět: Citovat

Nikoho od ničoho neodradzujem 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í 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á 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
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Radius
Profesionál
Profesionál


Založen: 22.2.2013
Příspěvky: 478

PříspěvekZaslal: 24 listopad 2016, 19:53    Předmět: Citovat

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.

_________________
x51 , ARM , XILINX
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Odeslat e-mail Zobrazit autorovy WWW stránky
 

 
Martin
ATmega pouzivatel
ATmega pouzivatel


Založen: 5.1.2008
Příspěvky: 1460

PříspěvekZaslal: 24 listopad 2016, 21:24    Předmět: Citovat

Ďakujem za trpezlivosť a prečítanie 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 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 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 Smile

Avšak každému kto cíti, že by ho mal používať, fandím.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Radius
Profesionál
Profesionál


Založen: 22.2.2013
Příspěvky: 478

PříspěvekZaslal: 25 listopad 2016, 2:33    Předmět: Citovat

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á.

_________________
x51 , ARM , XILINX
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Odeslat e-mail Zobrazit autorovy WWW stránky
 

 
kuto
Profesionál
Profesionál


Založen: 13.7.2010
Příspěvky: 120
Bydliště: Varnsdorf

PříspěvekZaslal: 25 listopad 2016, 13:07    Předmět: Citovat

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.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Martin
ATmega pouzivatel
ATmega pouzivatel


Založen: 5.1.2008
Příspěvky: 1460

PříspěvekZaslal: 27 listopad 2016, 9:27    Předmět: Citovat

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.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
vladoxxx
Nováček
Nováček


Založen: 20.3.2016
Příspěvky: 9
Bydliště: Brno

PříspěvekZaslal: 02 prosinec 2016, 17:40    Předmět: Citovat

Martin napsal:
S STM32 som zatiaľ robil nejaké pokusy.

Robil som s F103 a L476.


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:
http://www.st.com/en/evaluation-tools/32l476gdiscovery.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ší??
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Radius
Profesionál
Profesionál


Založen: 22.2.2013
Příspěvky: 478

PříspěvekZaslal: 04 prosinec 2016, 23:24    Předmět: Citovat

Ž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

_________________
x51 , ARM , XILINX
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Odeslat e-mail Zobrazit autorovy WWW stránky
 

 
vladoxxx
Nováček
Nováček


Založen: 20.3.2016
Příspěvky: 9
Bydliště: Brno

PříspěvekZaslal: 05 prosinec 2016, 8:53    Předmět: Citovat

Radius napsal:

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...
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Mahoney
Profesionál
Profesionál


Založen: 26.12.2013
Příspěvky: 111

PříspěvekZaslal: 06 prosinec 2016, 9:48    Předmět: Citovat

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): https://github.com/rebelbot/OptimizerLesson/tree/master/Drivers/BSP/STM32L476G_EVAL
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
vladoxxx
Nováček
Nováček


Založen: 20.3.2016
Příspěvky: 9
Bydliště: Brno

PříspěvekZaslal: 06 prosinec 2016, 10:43    Předmět: Citovat

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...
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
Mahoney
Profesionál
Profesionál


Založen: 26.12.2013
Příspěvky: 111

PříspěvekZaslal: 06 prosinec 2016, 11:05    Předmět: Citovat

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?
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
vladoxxx
Nováček
Nováček


Založen: 20.3.2016
Příspěvky: 9
Bydliště: Brno

PříspěvekZaslal: 06 prosinec 2016, 11:21    Předmět: Citovat

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 Sad

Tak jsem musel přesedlat...

pdf se mi podařilo najít, je zde:
http://www.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...
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

 
vladoxxx
Nováček
Nováček


Založen: 20.3.2016
Příspěvky: 9
Bydliště: Brno

PříspěvekZaslal: 08 prosinec 2016, 21:43    Předmět: Citovat

Tak už mi nikdo neporadíte??

Rád bych dostal nějaké kontakty na školitele, apod....
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
 

Zobrazit příspěvky z předchozích:   
Zobrazit předchozí téma :: Zobrazit následující téma  
Přidat nové téma   Zaslat odpověď    Obsah fóra mcontrollers.com -> ARM Časy uváděny v GMT + 2 hodiny
Jdi na stránku Předchozí  1, 2, 3  Další
 
Strana 2 z 3
Přejdi na:  
Můžete přidat nové téma do tohoto fóra.
Můžete odpovídat na témata v tomto fóru.
Nemůžete upravovat své příspěvky v tomto fóru.
Nemůžete mazat své příspěvky v tomto fóru.
Nemůžete hlasovat v tomto fóru.
Můžete k příspěvkům připojovat soubory
Můžete stahovat a prohlížet přiložené soubory
 



Num Lock Holder - app to hold Numlock
Copyright © 2017 Rudolf Veselý, mcontrollers.com.
Je zakázáno používat části tohoto webu bez souhlasu autora. || Powered by phpBB © 2001, 2002 phpBB Group - with RedSquare DoubleJ(Jan Jaap)