Debug PicKit3 a pic32mx - čtení hodnot při normálním běhu

Zdravím, pokouším se spřátelit s pic32mx, mám k tomu Mplabx 1.9 a PicKit3. Zjistil jsem, že proměnné z reálného cpu mohu číst pouze při krokování, nebo když stopnu chod, pak se zobrazí v okně proměnných hodnoty z okamžiku stopu. Mám takový dotaz, je možné vyčítat např. každou vteřinu hodnoty vybraných dat za normálního běhu cpu, pokud ano jaké je nutné nastavení nebo něco jiného než PicKit3. Nebo jsem jenom zmlsaný z jiných systémů, kde to je normálně možné?

:arrow_right: administrator: přejmenováno z "Debug PicKit3"

cau,mozny to samozrejme je , vezmes data a posles je pres nejakou komunikacni periferii ven, nejcasteji to byva UART, tohle pouzivam bezne, bohuzel PK3 (narozdil od PK2) nema uart tool takze je potreba jeste neco pripojit , na zacatku kodu si zadefinujes napriklad …

#define debug

pak uz jen tohle kde chces neco zobrazit

#ifdef debug printf("nej_cislo=%Lu\r\n",nej_cislo); #endif

po odladeni pak jen zakomentujes tu definici …

Díky za odpověď, tohle mne moc nepotěšilo, jako elegantni práci bych si to takhle nepředstavoval. Díval jsem se do nabídky Microchip a mají tam ještě ICD a RealIce, jak to vypadá při použití něčeho takového je známo?

osobni skusenost s tim nemam , je to vesmes asi vsechno stejny, pokud to nestopnes tak se ti nic neaktualizuje,

par uzivatelu s ICD tu je snad to objasni…

Pánové, a jak byste si to jako představovali? Ono oscilátor u novějších PICů běhá v rámci megahertzů, u PIC32 dokonce desítek megaherzů, to znamená že se obsahy některých registrů můžou měnit taky v řádech megaherzů… jak byste to chtěli za běhu přenášet do PC, a taky jak byste to chtěli číst?? Myslím, že zobrazení jen při stopu nebo krokování dává celkem logiku, ne?

Zdravím, díky za názory. Asi jsem se nevyjádřil úplně jasně. Občas dělám s Freescale, tam je to postaveno tak, že cpu normálně jede třeba na 50 Mhz, ale na pc vyčítám deklarované proměnné s periodou třeba 0.1 sec, což je velká pomoc při oživování.Jedině mne se…re omezení kodu na 64 kB, dávat jejich peníze za plnou verzi mně připadá nestravitelné. Proto jsem zkusil pice, kde není omezení kódu, jen nedělá optimalizaci, což mně nevadí. Bohužel realita odlaďování piců je bůh ví kde, jak se tady ukazuje.

Zkus realitu debagingu v ARM CM3. To co chceš funguje například v KEIL UV4 + JLINK , testováno s procesorem STM32F103

Díky za radu, mám ale takový dojem , že finanční náročnost IDE Keil je asi dost vysoká, pokud by se mělo jednat o nějakou demo verzi asi ne. Navíc jsem už docela dost času strávil studiem piců, což by asi padlo vniveč.

Pokud je to na hraní tak nejsem striktním zastáncem placení plných verzí (na oplátku hlásím výrobci chyby) a pokud je pro business tak ten komfort se vrátí. (KEIL pro x51 i ARM jsme do firmy koupili) Jsou i limitované verze KEILu a kolega z práce mi říkal že když dělal diplomku, tak s takovou verzí a trochou trikování (né hacking) s překládaným kódem to obešel - zcela legálně.

Jo tak :slight_smile: No, to je pravda, debugging opravdu není silná stránka Microchipu, resp. potěšil jsi mě s tím, že u PIC32 jde aspoň to co jsi napsal prve, zrovna s nima taky začínám :smiley: Freescale, Renesas, i ST a TI mají fungující hardwarový debug, můžem si vybrat :confused: Jinak PIC32 mají JTAG (díky tomu, že to nenavrhovali sami, ale MIPS), přes to by to snad mělo jít, ovšem jak je to se softwarem a hardwarem k tomu, to netuším…

Zdravím, konečně si začínáme asi rozumět. Dlouho jsem dělal pic18 a používal jen simulaci v pc, ta mne několikrát pěkně vypekla, tak jsem hledal jiného výrobce cpu. Vše dohledat včetně použitelného IDE za lidskou cenu, plus žádoucí technické detaily, abych věděl jestli má smysl se do něčeho pouštět. Už jsem asi dost načichl picema tak nevím jestli to vše hodit pryč a zase hledat něco jiného. Kdyby se třeba ukázal nějaký uživatel s realIce od piců, bylo by asi snažší rozhodování. Podle manuálu je něco podobného mým požadavkům možné, ale …Na ST cpu jsem zkoušel Eclipse, ale asi po týdnu pokusů jsem to vzdal, takže zatím pořád nevím co a jak. normálně dělám velké systémy, tak jsem si zvykl na určitý komfort, také i efektivitu práce. JTAG s tím svým mrakem drátů se mně moc nelíbí.

—JTAG s tím svým mrakem drátů se mně moc nelíbí—
Zkus SW debuging = 2dráty + reset…

Ohledně ECLIPSE , teď to mám povině ve worku a dělám na tom SPARC LEON3 a moc vodvázanej z toho nejsem.

Osobně bych doporučil udělat ještě jednu iteraci a zůstat u ARM.

Díky za radu, ale ono to není také úplně jednoduché pro ARM. Buď typ ST tam nevím jaká je HW spolehlivost nebo Freescale Kinetic ten by spolehlivostí seděl. Zase jaké vybrat IDE, aby to bylo plně schopné a já nemusel prodat auto. Pokud projíždím různá fóra názory na prostředí jsou úplně proti sobě. Potřeboval bych to po stránce SW i HW spolehlivé, dávám to do poměrně náročných zapojení a nechci vychytávat ještě cizí chyby, stačí úplně vlastní. Takže co mně můžete doporučit?

Dělám s ST32F1xx a řek bych že dobrý (pár aplikaci v průmyslu) ale netuším co od toho očekáváš a kde to pojede. Asi to máš pro komerční použití takže pokud nevyhoví STM (a že jich je) tak je hafo dalších ATMEL, NXP, TI, SILABS a pořád je to ARM CM0-CM4. Fóra jsou bezva ale testnout si musíš sám. Někdo nedá dopustit na GCC, někdo na KEIL, někdo na IAR. Pokud Tě zajímá kvalita STM knihoven, tak nevím, používám vlastní…

Myslím, že na GCC frčia všetci, ten zvyšok sú “len” vývojové prostredia :slight_smile:

----Myslím, že na GCC frčia všetci, ten zvyšok sú “len” vývojové prostredia—

…s jen úplně jinejma kompilátorama. Se prober - proč asi lidi řeší kvallitu překladu ?

Som sa prebral :slight_smile: