Időt mérni az Mplab X-ben lehet a stopwatch-al, ami nem pont időt mutat, hanem utasítás ciklust, de abból vissza lehet számolni.
A + idő csúszás szerintem abból van, hogy szerintem a C18 az XC8-al hasonlóan működik, tehát a megszakítás nem csak az amit te beírsz, ment egy pár változót a megszakítás elején, ami lehet pont az az idő veszteség.

Mire a programod elér a T1CONbits.TMR1ON=0; utasításra, a TMR1L regiszter értéke már nem nulla. Ki kellene olvasni és a kiolvasott értékkel korrigálni kellene a beírandó értéket.

Szia!

megtalálod: Debugger->stopwatch.
A timer 1 utsítással megállítható és elindítható, tehát leállítod, beírod az értéket és ahonnan kell mérnie ott elindítod. ekkor 100n sec a hiba, de még ez is korrigálható.
üdv.:Foxi

Én is valami hasonlóra gyanakodtam, viszont ez az új mplab nekem elég idegen. Pár éve asm-ben kezdtem a programozást és az a felület sokkal átláthatóbb volt, itt a debug projectre kattintva nem látom egyáltalán a nyilat hogy hol jár a program, hiába léptetem egyesével sehol semmi. A disassembly listingben sem látom hol jár a program. MPLAB X IDE v.3.35 van fent.
Majd nézek pár tutorialt, mert mióta C-ben próbálkozok eddig csak mint fordítót használtam az mplabot, de legalább a csúszás okát megtudtam köszönöm mindenkinek a segítséget!

Kapcsolj ki minden optimalizációt a fordítónál.

Sziasztok!
Le szeretném fagyasztani a picet, hogy lehet olyan programrészletet beszúrni, hogy ez bekövetkezzen? Ki akarom próbálni élesben is a watchdogot, de eddig nem sikerült annyira összekevernem valamit, hogy lefagyjon a pic. Mit kellene csinálnom?

Probalkozhatsz hűtőspray-vel, de egy vegtelen ciklus is megteszi. C-ben: Assembly-ben egy jump, ami onmagara ugrik.

Ok, kösz.

Szép napot! Nekem a C nyelv "Óhéber"...
Letöltöttem egy projektet az Aeropassionról -JEDICUT habvágó géphez. Elkészítettem az USB-LPT átalakítót, ami a teszt .HEX-el működik. A működtető program C-ben megvan, de a fordításkor a következő hibát adja:

A eredeti (Microchip honlapról letöltött) usbdsc.c file-be belerondítottam egy .pdf-ben megtalált VID és PID értéket. Az eredeti értékkel ugyanaz volt a hiba.

Az előzőhöz csak annyit, hogy a 280-as sorban ez van:

A HID_RPT01_SIZE definíciója nem egyezik meg a megadott tömb méretével (63 byte).

Köszönöm a segítséget! (Mint kiderült egy másik asbdsc.c file kellett hozzá.) Lefordítani sikerült, valami már megy, de még nem az igazi. Jó lenne érteni hozzá.

Srácok 1 byte rotálására mi a legegyszerűbb megoldás?
Én most feltétellel oldottam meg, miszerint vizsgálom az első bitet és ennek megfelelően változtatom az utolsót.
pl:Vagy
Van erre gyorsabb és egyszerűbb megoldás, C18 és C30-as fordítókra?

Itt is megkérdem, hátha:
Én rontok el valamit, vagy az atof() függvény működik rosszul?

Az atof() fv. double tipust ad vissza, nem tudom van-e ennek jelentősége.

Átírtam a típusát double-re de így is ez a végeredmény. Érdekes továbbá, hogy a Variables ablakban az "a"-nak a típusához továbbra is azt írja hogy float.

Ha az a, az double, akkor az sprintf format részébe próbálj %lf-et írni a %f helyett.

Érdemes lenne megnézni nálad hány bites a float 24 vagy 32 és a double 32 vagy 64 próbálj beírni long double-t asszem az 16 és 32 biten a 64 bites (gépes) C double.

Na kipróbáltam mindent amit lehetett de sehogy nem adott vissza normális értéket az atof(). Most már teljesen biztos vagyok benne hogy hibás a gyári atof() függvény! Írtam egy sajátot, az teljesen jól működik.

eredmény: 12,2........

Én az a-t csak az első tizedesig szeretném felhasználni, hogyan oldható meg hogy az 3-as legyen?

123-at 10-zel osztva hogyan lehetne 12.2...? Esetleg 12.30000 lehetne, más nem.

Melyik fordító? Chip típus? Szimulátorban vagy valamin megjelenítve ennyi az eredmény?
Ennyi infóból: valami nem úgy működik, ahogy azt elképzeled.

egész rész: b/10
"tizedes" rész: b%10 ez a modulo ha utána akarsz nézni

PIC24FJ256GB106-os PIC-ről van szó ... CCS-C fordító ...
Soros potron küldöm ki az adatot egy Nextion kijelzőre, meg 4 bites módban egy 2x16-os LCD kijelzőre. Az LCD kijelzőn megjelenített érték, ha négy tizedest jelenitek meg akkor: 12,2999. A soros vonalon a Nextionon egy tizedes kiküldésével 12,2.
Még szimulátorban nem volt időm megnézni, hogy már az osztáskor bukik a mutatvány, vagy az fprint parancs környékén lesz a hiba.

Köszi, de pont az lenne a lényeg, hogy az eredményt float-ban kapjam meg!

Ne csodálkozzunk a pontatlanságon, az 1/10 egy végtelen szakaszos "kettedes" tört...
A kiíratás előtt a pontossági igények figyelembe vételével kerekíteni kell.

Akkor ez kerekítési hiba, a stringre alakító függvényed fixen lefelé kerekít. Ha egy tizedesre van szükséged, akkor a stringre átalakítás előtt adj hozzá 0.05-t.

Hogyan lehet jelezni a fordítónak, hogy hagyja ki az optimalizálásból az adott sorokat (Nop-okat) ?
Vagy, hogyan lehet úgy várakozni egy-két program lépést, hogy azt ne optimalizálja ki a fordító?
XC32

Találtam megoldást, igaz soronként, vagy egy kód részletre még nem tudom hogyan lehet alkalmazni, de egy eljárásra már működik:

Deklaráld volatile-nek, és futtass egy for ciklust, amíg várni akarsz. Ekkor biztosan nem lesz kioptimalizálva a várakozásod.