Egy újabb furcsa hiba. Az eddigi viszonylag gyors program hirtelen belassul ha átírom a PWM prescalet 1:4-ről 1:1-re. Ami azért érdekes, mert a timer0 hoz létre egy megszakítást 0,33mp-ként ami eddig kb annyi is volt + amíg a megszakításban van. Semmi mást nem csinálok csak átírom a PWM prescalet 1:1-re és csak 1-2mp-ként reagál a program bármilyen változásra, mármint ami a pwm-hez és a megszakításhoz köthető.

Valószínű, hogy a programod össze-vissza kóricált eddig is, csak most még kevesebb ideje maradt. Ezt sejtetei a korábban leírt jelenség is, hogy megáll a debugg közben és nem látszik hol...

És ezzel mit lehet kezdeni?
Bár azt nem értem mi köze van a pwm prescalenek ahhoz hogy még kevesebb ideje maradt? Semmi más nem változott ugyan annyi időközönként lép be a megszakításba csak a pwm prescale lett átírva 1:4-ről, 1:1-re. Eddig úgy tudtam ez hardveres pwm.

Pár utasítással kevesebbre fordul, nem sok, de nagy mennyiség esetén ez is számít.
Egész jól sikerült optimalizálnom a kódot.

Ha a printf-et használod kicsit nehéz lesz optimalizálni !
Lassú is és sokkal növeli a kódot.
Én sosem használom !
Helyett uin8_t-re :

Ha megérted a működést könyedén átírhatod 16 vagy 32 bites-re.

Itt találsz megoldást a printf-re ! Bővebben: Link

Az sprintf stringbe ír ! Ezt könnyű manipulálni !

Csak puszta kíváncsiságból kipróbáltam egy nagyon primitív programot:
#include "config.h"
#include <delays.h>

ini_port(void){
LATA = 0;
TRISA = 0X00;
//PORTB INITIAL
LATB = 0x00;
TRISB = 0X00;
//PORTC INITIAL
LATC = 0x00;
TRISC = 0X0F;
//PORTD INITIAL
LATD = 0x00;
TRISD = 0X00;
//PORTE INITIAL
LATE = 0x00;
TRISE = 0X00;
}

void main(void) {
ini_port();
while(1){
LATD=1;
Delay10KTCYx(250);
Delay10KTCYx(250);
Delay10KTCYx(250);
Delay10KTCYx(250);
LATD=0;
Delay10KTCYx(250);
Delay10KTCYx(250);
Delay10KTCYx(250);
Delay10KTCYx(250);
}
}

Lefordítom, debug és sehol egy árva nyíl, a disassembly lista 178 sor, de ott sem látok semmi mozgást. Pedig megállítottam a debugot és nyomtam egy resetet, majd lépkedtem, de semmi.

SFR direkt hozzáférés hi-tech PIC18 C ben én így csinálom pl.:
static BYTE RXB0[13] @ &RXB0SIDH;
static BYTE RXB1[13] @ &RXB1SIDH;
static BYTE TXB0[13] @ &TXB0SIDH;
static BYTE TXB1[13] @ &TXB1SIDH;
static BYTE TXB2[13] @ &TXB2SIDH;
Nézd meg a fordító proci.h file-ben hogyan definiálja a regisztereket.

Simulátort bekapcsoltad ? Töréspontot enged letenni ?
Watchdog ???????
Ha valahol bennragadasz egy hosszú időzítésnél törölni kell !7

Tettél break pontot valahová, megáll ott? Szimulációban működik, vagy a PIC-en futtatod?

Ha leteszek egy breakpointot meg sem áll azt írja broken break point. Watchdog van, de próbáltam kikapcsolva is. Eddig csak proteusban próbáltam ki a picen még nem.

Ne tegyél töréspontot deklarációra (int x = 66. Megtörténhetett az is, hogy azt a sort, amire a töréspontot tetted, az optimalizáció "eltüntette".

Az egyik Delay sorra teszel megszakítást, akkor annak élnie kéne. Gondolom akkor egyik sorra sem tudsz élő töréspontot tenni? Elég fura dolgok történnek nálad! Valami beállítási probléma lehet. A szimulátornál beállítottad, hogy milyen órajellel megy a PIC? Biztosan ki van választva a szimulátor, nem valamelyik égető-debugger véletlen?

Szia, ez jó hír, örülök neki!

Tettem én máshova is, de azt írta:
Not resolvable to a valid memory address.
Minden sornál ezt írja, ki.
Egyébként a furcsa hiba oka, meglett ha a prescale-t 1-re állítom 4-ről miért "rángat". A proteusban be volt téve egy digitális skóp, és a frekvenciák gyors változását nem szerette. A szkópot kivettem és ismét gyorsan reagál az lcd kijelző. Így talán mégsem lehet annyira rossz a program, csak a 0-25 khz közötti gyors jelek kirajzolása nehézkes a proteusnak, vagy a gépemmel van valami.

Wezuv a szimulátor van kiválasztva és be van állítva a 40MHz-es órajel. Lehet nálam van valami elállítva. Esetleg feltehetem a progit és megpróbálhatod hogy neked működik e a breakpoint. Lehet újra kéne rakni az mplab-ot?
Egyébként a Delay sorra is egyből broken breakpointot tesz. Pedig ismét nyomtam egy szünetet és egy resetet.

Kapcsold ki az optimalizációt.

Délután ki tudom próbálni, de egy ilyen progival, amit próbának dobtál össze, minden további nélkül működnie kéne. Lehet, hogy tényleg az optimalizálás viccelődik, bár nem tudom, hogy egy időzítés kérést, hogyan lehet teljesen eltüntetni. Valahol csak vissza kellene találnia a programnak a forrás valamelyik sorára, ha lépteted. Melyik verziójú mplab-ot használod?

v3.25-os Mplab xide.
A project tulajdonságokban kikapcsoltam az optimalizációt, de ugyan az.
Mellékeltem a mostani verziót a configgal együtt.

Nekem 3.26, de tuti nem ez a baj. Itt simán fordul, fut a szimuláció, pontos a Delay stb. (10MHz-et kell beállítani, ha az osci 40...) C18 v3.47.
Telepítsd újra a dolgokat, fordítót is.

Értem, kösz.

Ezt próbáltam én is, csak a címképző operátor lemaradt.
Nagyon köszönöm.

Meg még lehetne is, nem? Nincs sajnos most a közelemben lehetőség kipróbálnom, és ezekkel a const pointerekkel nem vagyok mindig 100% tisztában, de mintha így lehetne.

Igen, ha még const is, akkor maga a tömb const lesz. De ez nem befolyásolja a működést. A volatile viszont fontos, mert pl. egy ilyen
ciklust egy valamirevaló C fordító teljesen kioptimalizal és egyetlen *tomb[2] = 10; lesz helyette, ami egy HW regiszternél nem túl szerencsés. Ha a tömbben volatile elemekre mutató pointerek vannak, akkor nem optimalizálhatja ki a velük végzett műveleteket.

Olyan megtiszteltetésben van részem, hogy örömmel jelenthetem be:
A Microchip C18 -as fordítója nem "valamirevaló C fordító".

A C18-rol tudjuk, hogy nem valamirevalo, ami mar abbol is latszik, hogy volatile valtozok cimet (felteszem, az FSR valtozok volatile-nak vannak deklaralva) siman engedi beletenni egy olyan tombbe, ami nem volatile *-nak van deklaralva. Egy rendes fordito ezert szol, es nem sziv az ember ket napot, mert nem talalja a hibat..

Egyebkent meg neztem jo 10 percig, mert latszolag kiszedte a for() belsejebol a tomb[2] = i reszt. Aztan jobban nezem, hogy a disassembly listaban nem sorba jonnek a cimek. Ez nekem már túl mikrocsipes... Persze ettol meg nem ertem, hogy a BRA 0x68 utani sorok mit is csinalnak pontosan, de nyilvan az a tomb[2] = i; Minek tolt a W-be 5-ot, aztan 6-ot, amit semmire nem hasznal? Azon felul az 'i' valtozot egy fix memoriacimen tárolja, ez sem igazan arra utan, hogy ez egy rendes C fordito lenne. Magyarun nem tamogatja a rekurziot, ami a C nyelv egyik igen fontos tulajdonsaga. Persze ertem en, stack nelkul, RAM nelkul nehez...

És ha kiteszed a két {}, akkor is ilyen béna? Melyik verzió?

Én 15 éves PIC múltal tudnék mesélni a Microchip csodáiról.
Ezért tervezem az áttérést az STM32-re !
Tavaly upgradeltem az ICD2-imet ICD3-ra. A csodás mérnökök az uj Rev4 verzióban biztosan spóroltak a tulajoknak 1 dollárt. Niztosan kifejlesztettek belőle valami védelmet vagy gyengép alkatrészt tettek bele.
A régi ICD3 Rev3 évek óta használom több 100 vagy inkább 1000x programoztam vele...jelentem műkszik.
A Rev4-ből már 3 db jobb létre szenderült !!! Microchip ingyen cseréli, de a postát Irországba én fizetem.
Könyörögtem, hogy valami old stok Rev3-at küldjenek....majd kiderül.
A Nucleo kártya 2 eFt és letörhető programozó, debugger van rajta.
Mennyi is egy ICD3 ? Nekem van eladó ha valakit érdekel !

A megfejtés:


Használja a konstansokat a "verem" eléréséhez. (Hogy miért 5 ill. 6, arra a deklaróció ad magyarázatot.) Miután nincs a 18F -en HW támogatás a verem kezelésére, az FSR2 segítségével kezel egy vermet.

Értem, szóval a 0xfdf az nem csak egy RAM byte (ahogy en hittem), hanem az az INDF2. Azert lehetne szimbolikus a disassembly lista, hogy legalabb ezeket kiirja. Most sem csalodtam a mikrocsipben. De igy mar vilagosabb a helyzet. Igazabol nem ertem, hogy miert kellett ilyen processzort fejleszteni. A kezdeti 16-osok olyanok voltak, amilyenek, ~25 evvel ezelott. Akkor is leteztek mar jobb 8 bites architekturak, de mikrokontroller nem sok volt. De hogy evekkel kesobb is csak ezt tudjak magukbol kipreselni, az azert eleg szanalmas. Mar 15 eve sokkal jobbak voltak az ATmega-k, mint ez a 18-as sorozat. Legalabbis arhitekturalisan.

Sziasztok. Először kell lebegőpontos számokkal dolgoznom, és már az elején nem értem, hogy mit rontok el. Egy egyszerű értékadás után a Watch ablakban a float típusra teljesen más értéket kapok vissza. A fordító Hi-tech C.
Mire nem figyelek? Köszi.

Nagy valószínűséggel az MPLAB IDE nem olyan formátumú számábrázolást feltételez, mint amilyet a fordítód használ. Az idevágó GyIK szerint jobklikk a változónévre, s a tulajdonságoknál 24 bites IEEE forátumot kell választani.
Bővebben: Link