[elektro] C kérdés

hg12345 hg12345 at freemail.hu
Sat Aug 28 07:47:30 CEST 2010



"hobilobi at gmail.com" <hobilobi at gmail.com> írta:
>2010.08.27. 20:59 keltezéssel, BALOGH ANTAL írta:>
> Azt már tapasztaltam, hogy néha elkeveredik a sorok között, és az>>
> utasítást tartalmazó sorra nem, de az alatta lévő üresre lehet>>
> töréspontot tenni.>>
> Igen zavaró hogy nem pont a törésponton áll meg ha nem lép még egy párat.>
>    >
Ezt is tapasztaltam. Nem is értem hogyan oldják meg a töréspontot, hogy >
ilyen előfordulhat.>
>
> Erre nekem is ahogy mások is irták pár nop segít.>
>>
>    >
Elég undorító dolog, hogy ilyeneket kelljen a C forrásba beirogatnom, >
hogy normálisan működjön.>

Amúgy tudsz jobbat ?  :-()

érdemes lenne irás elött kicsit gondolkozni...

Hogyan lehet megállítani egy program futását (BRK)???
- Az IDE kicseréli az utasításodat egy speciális utasitásra pl: BRK és ott "áll" meg a program, jobban mondva végrehajt egy nem maszkolható IT-t és az megoldja a töréspontot, persze elötte a kicserélt utasítást is végrehajtja. Hogy ez igazán müködni tudjon RAM-ban kell a programot tárolni :-()... Ez kicsit nehezkés az MCHIP eszközöknél.....
De azért megoldották az MPLAB-ban a SW töréspont lehet konfigurálni, persze minden egyes töréspontnál újra írja FLASHT-t valamit valamiért.

- Minden modern uC benne van a debug + trace HW macro, ezzel a külső emulátor készítést spórolják a gyártók, meg a fejlesztőknek egyszerűsítik az életét. Ez egy speciális áramkör ami néhány regiszterrel tudja komparálni a belső cim és adat buszt, illetve ezeknek az állapotát pl JTAG TRACE porton kiküldeni(jobb helyeken ezek publikusak, de az MCHIP nem egy jobb hely, de amugy se lehetne vele mit kezdeni :-(. A MCHIP csak DEBUG részt használja. Ha megnézed az utasítások végrehajtását, láthatód, hogy az utasítás beolvasás FETCH az előző utasítás végrehajtása alatt történik, vagyis amikor észreveszi már a következő utasát hajtja végre, tehát csak itt tud megállni.

Nem tartom az MCHIP dokumentációkat korrektnek, de breakkel kapcsolatos idözítési késleltetés ezer helyen leírták.....

MPLAB/HELP/ICD*  erre keress rá: 
"Hardware breakpoint skidding may occur on Halt"

Ettől függetlenül elég zavaró, hogy mögöttet áll meg, ezért kell goto$+ vagy bra $+ megvalósítású NOP-t használni. a magyarázata igen egyszerű, ugyan előolvasásos az utasítás feldolgozó egysége, de nincs ugrás optimalizáló és előre jelző egysége, ezért minden ugrás esetén kiüríti a előfeldolgozót, míg valódi NOP esetén nem. A kiürítés miatt minden ezen az utasításon áll meg :-)
(ugyen ezen ok miatt nem ajálják, az XLP eszközöknél időzítésre (egy utasítás 2 vagy 3 lépés) többet fogyaszt mint 2 vagy 3 nop :-))) 
Nagy kár hogy ezt a megoldást az MCHIP nem ajálja, de lehet hogy nem is gondolkodtak el rajta..... :-()

Amagy a C-ben teljesen mindegy hogy a gyári Nop() függvényt használod vagy definiálsz egy sajátot pl: DNop() csak egyszer kell egy életben, az utóbbinak van egy előnye :-() mivel nem eszköz leíró header-ben van, magad tarthatod kézben, és a DEBUG/REALASE, az utobbi esetben automatikusan semmivel helyettesítheted, vagyis a végleges változat már nem kerül bele. Ez nem csak C-ben járható.  



More information about the Elektro mailing list