Ako zdebugovat interupt v C ?

[Petr Labaj]

Používám to podobně.
Mám udělaná makra, která strčím na začátek a konec obsluhy IRQ (případně 
jinam).
Ta makra v debug verzi na začátku nahodí daný pin, na konci shodí. V 
release verzi se makra neuplatní.
Takže to můžu sledovat osciloskopem.

Ale protože jsem posedlý efektivitou programu a rychlostí zpracování, 
tak mám ten pin (resp. piny) zvolený tak, že funguje také jako vstup čítače.
Čítač si čítá pravidelné tiky, a tento pin funguje jako jejich hradlování.
Takže výsledkem je přesně změřené procento času, které procesor strávil 
v dané oblasti, ohraničené makry.

Defaultně to mám na začátku a konci každé IRQ rutiny (to je jeden čítač, 
společný pro všechny IRQ) a v "obsluze" stavu IDLE (druhý čítač).
Takže vím kolik výkonu seberou přerušení a kolik z toho zbytku aktivní 
běh programu. Tedy jaké mám kde rezervy.

PL

********************

Dne 8.9.2023 v 22:19 Vláďa Anděl napsal(a):
> Pro různé testování, kam program občas zabloudí, kolega používá 
> testovací ledku, která blikne při průchodu tou či onou větví programu. 
> Když mu kreslím tišťák s nějakým MCU, nesmím na ní zapomenout. Já 
> zase, protože se mi na stole válí osciloskop, se obejdu i bez té ledky 
> a těch testovacích výstupů si tam nadělám i víc. Zvlášť vhodné i k 
> sledování, jestli se provádění programu (a s jakou rezervou) vejde do 
> časového okna, pokud je program spouštěný časovačem. I tohle dokáže 
> nadělat chyby, které se jinak blbě hledají.
>
> Anděl
>
> Dne 08.09.2023 v 15:23 Petr Labaj napsal(a):
>> Omlouvám se, že jsem to nestudoval celé.
>> Ale pokud se občas vypisuje něco co nemá, tak bych udělal:
>> - v té přerušovací rutině, která má vypisovat DP,  bych otestoval, 
>> jestli posílám na port opravdu kód pro DP
>> - pokud ne, tak bych vzal ze stacku adresu, na které bylo vyvoláno 
>> přerušení, a napsal bych ji do nějakého pomocného bufferu
>>
>> Pak bych to po chvíli zastavil v debugeru (poté, co se několikrát 
>> zobrazil ten špatný segment) a zkontroloval ten seznam adres, kde se 
>> program nacházel v době přerušení.
>> Pokud by to byly stále stejné oblasti, zaměřil bych se na hledání tam.
>> Je to jednoduchý pokus na pár řádků a pár minut.
>>
>> PL
>>
>> *******************
>>
>> Dne 8.9.2023 v 15:14 Jan Waclawek napsal(a):
>>> [preposielam]
>>>
>>>
>>> Ahoj,
>>>
>>> pouzivaju sa dva buffre MUX_RawData a RawData. Raw_Data sluzi na 
>>> nastavenie
>>> bitovych masiek cislic a znakov. MUX-RawData je samotny buffer, z 
>>> ktoreho
>>> bezi multiplexovanie dat na porty, kopiruju sa jednotlive bity.
>>> Umyselne pisem porty, lebo ovladanie anod a zobrazenie znakov a 
>>> cislic nie
>>> je konzistentne na piny portov, ale su rozhadzane, tak aby bol pekny
>>> plosny spoj. Chyba sa prejavi tak, ze na prazdnej segmentovke, na 
>>> ktorej ma
>>> svietit "DP" svieti "Seg_A".  Akoby sa vykonala rotacia z 8 bitu do 
>>> 1 bitu.
>>> Neprejavuje sa to vzdy, ale z casu na cas sa to objavi a rusi to 
>>> esteticky
>>> dojem. Este ma napadlo, ci to nie je typicka chyba read-modify-write
>>> bitovych instrukcii PIC16, ktorymi ten displej ovladam. Chybu sa mi
>>> podarilo nasimulovat, ale pokazde pri inom zobrazovanom 3-cifernom 
>>> cisle.
>>> Chyba nie je staticka ale dynamicka. Ten kod, co som sem dal, 
>>> funguje na
>>> 99,9%, takze to nie je tak, ze to nefunguje vobec. Jedina tazkost pri
>>> ozivovani bola synchronizacia pri kopirovani RawData do MUX_RawData. A
>>> mozno je to aj tym 20 rocnym mcu, ktory uz pomaly dosluhuje. Ale 
>>> prist na
>>> to, co tomu je, ma dost motivuje, ale zial matam v tme.
>>>
>>> A.
>>>
>>> Skus prosim este popisat, co presne chces zobrazovat (t.j aky je obsah
>>>
>>> jednotlivych relevantnych premennych), a co tam vidis zobrazene 
>>> (t.j. ze
>>> ako sa chyba prejavuje).
>>>
>>> wek