Bár nem értek a C-hez, de a .h kiterjesztés "header" (=fejléc) típusra utal, míg a .c a "C" a forrásnyelvi tartalmat, végrehajtandó utasításokat jelzi.

Én kipróbálnám virtuális gép alatt is, pl. Virtualbox-ban feltelepített XP alatt.

A C fordítók úgy működnek, hogy első körben az előfordító végigmegy mindegyik C forrásfájlon, és az abban található #include hivatkozásokat copy-paste módon bemásolja a C forrásfájlba. Ezután a fordító minden C forrásfájlból csinál 1-1 object fájlt. Az object fájlok már bináris kódot tartalmaznak, de a memóriacímek még nincsenek benne véglegesítve. Ezután megy rá a linker az object fájlokra és azok összefésülésével készíti el a végleges bináris kódot. Na mármost: mivel a C forrásfájlból szoktunk olyan függvényt hívni (esetleg adatot felhasználni) ami a másik C forrásfájlban van kifejtve, kell egy összekötő kapocs, ami a fordítónak megmondja, hogy másik C forrásfájlban milyen függvények érhetőek el, és azok milyen paraméterezéssel rendelkeznek. Erre való a header. A függvény kifejtése pedig azért nem lehet benne a headerben, mert egy headerre több C forrásfájlban is hivatkozhatunk, így a függvény több object fájlba is belekerülne ami ütközést okozna (a függvény prototípusának többszörözése nem okoz gondot).

A saját headerfájl értelme az, ha több C fájlból áll a projekted, akkor az egyik forrásból hivatkozva a másikban lévő függvényre változóra egyzserűbb hivatkozni, egyszer kell a headerba beírni a deklarációt, és ezt minden c forrás látja.
A gyári(lib) header fájl meg nyilván azért van, ne neked kelljen a deklarációt beírkálni, fejből tudni...
A headerfájlba "nem illik" programszöveget berakni, csak deklarációkat. Persze lehet, csak nem tesz jót , nem lehet akkor több fájlba behívni, mert duplikált függvények, változók lennének

Igen,ez már eléggé aggasztó...Próbáld ki,hogy virtual XP-alatt megy-e? ,talán ez segíteni fog.Sajna eléggé macerás kideríteni,hogy mi fogja meg(de próbaként ki kellene lőnöd egyesével mindent,hátha meglesz a mumus) .

Szia!

Nem véletlenül a TRACE funkció okozza ?! Ez a help szerint jelentős lassulást okoz ami gyengébb gépnél (szerintem főleg kis memóriával !), számottevő lehet !

Köszi a válaszokat!

PIC (18F4550, 20MHz kavarz) és ESP8266 (szoftveres uart) modul között hoztam létre UART kapcsolatot. PIC küld ESP felé.
Mitől van az, hogy nem minden sebességen hajlandóak kommunikálni egymással?
pl 57600-nál szinte hibátlan az adatátvitel, 9600-nál nem is fogad adatot az ESP, 115200-nál téves adatokat vesz.
Gondolom, hogy az átviteli sebességek nem passzolnak egymással ... de melyik oldal téveszt? Hogyan tudnám a megfelelő átviteli sebességet meghatározni, nem próbálgatós módszerrel?

Első körben tegyél rá egy logikai analizátort és mérd meg mennyi az annyi (ha még nem lenne, akkor meg szerezd be ezt a pár dolláros hasznos kis szerkezetet).

Szinkronizációs problémának tűnik. A 2 oldal egyforma baudrate-re van konfigolva?

Én PIC-ről 9xx kBd sebességgel, kvarc nélkül küldtem a PC felé adatokat - sebességeltérés nem okozott hibát.
AZ ESP oldalán szinkronizálási hiba szerintem elképzelhető, ha szoftveres soros porton veszel. A PIC oldalán érdemes lenne kipróbálni a lassítást, szünettel a karakterek között - az ESP8266 kezeli a WiFit is, így veszíthet biteket.

Érdekes állat a serial adatátvitel, mert elsősorban nem a sebesség a kulcskérdés, hanem az órák relatív pontossága. Ha egy konkrét BAUD értékkel van egy szisztematikus óra tévedés, és erre rájön az órák különbsége, az okozhet esetleg ilyet. Az órák közötti kb 10% eltérés már vételi hibát eredményezhet önmagában.

Amit mérni érdemes szkóppal:

* Jelforma a vételi oldalakon: ha túl nagy a vezetékek kapacitása, a soros ellenállás, stb akkor elképzelhető hogy a jelforma már nem elég jó. Szögletesnek kell lennie. Ha van egy görbülete a sarkoknál, pláne ha a két irányba nem egyforma, akkor adódhat ebből is tévesztés. A vevő többnyire a startbit éléhez szinkronizál, ha a fel/lefutás lassú, akkor bizonytalan lehet időben, hogy honnan veszi alacsonynak/magasnak. Ezzel rövid drótoknál és kis BAUD rate-nél ritka, de nem kerül semmibe ránézni azért erre is, ha már bekapcsoltuk a szkópot.
* Bitidő: olyan tesztprogramot érdemes írni, ami a kimeneti pufferbe azonnal beírja a következő bájtot, amint lehetséges. A bájt értéke pedig legyen 0xf0 vagy 0x0f. Attól függ, hogy a 0 vagy 1 oldalon van-e a startbit (nem emlékszem), de vagy az egyik, vagy a másik mintával teljesen szimmetrikus négyszögjelet kapsz. (AVR-es HW UART-tal számtalanszor csináltam, tényleg teljesen pontosan szimmetrikus négyszöget ad) Aminek a periódusa pontosan 10 BAUD lesz: start, 8 adata, stop. (Ha 1 start, 1 stopra van konfigolva az UART.) Ezt a jelet könnyű szkópon pontosan bemérni, élre triggerelve teljesen statikus képet ad.

(A 0b10101010 vagy 0b0101010101 mintákkal is szokás mérni, itt a jelváltás ideje 1 BAUD, a periódus 2 BAUD. Automatikus mérőjelnek a 0xf0/0x0f azért jobb, mert kevesebb él van benne, kevesebbszer kell leolvasni az órát. A mérés pontosságát azzal lehet növelni, ha több jelet mérünk egyszerre, mivel a leolvasási hibát nagyobb számmal osztjuk. Ez kézi szkópos mérésre, de bitidő mérésre is igaz.)

Ha mindkét adót bemérted, akkor jó esetben ebből a mérésből már látszani is fog, ha a bitidő eltér, vagy az is, ha a start/stop beállítások eltérnek. Ha nincs implementációs hiba a SW vevőben, akkor annak a bitideje egyezik az adóval. A vevőt úgye direktben nem lehet mérni...

SW vevőnél az is okozhat hibát, ha valami interrupt elrontja az SW vevő időzítését - ez nagyon implementáció függő. Ha a valódi program futása mellett ki tudod adatni az SW UART-tal a mérőjelet, és az a szkópon zizegő képet az, az utalhat arra, hogy valami interrupt vagy egyéb nem teljesen determinisztikus dolog rontja el az időzítést. De ha ilyen lenne, az tipikusan kisebb BAUD-okon lenne kevésbé zavarérzékeny. Ez ellen CHECKSUM+hiba tolerálással a kommunikációs protokollban lehet védekezni. Vagy kisebb BAUD-dal.

Most nézem, hogy szoftveres, de biztosan működik az is hiszen több éve használja az arduino kommunity. Viszont a blokkoló utasítások befolyásolhatják(pl.: delay()).

Köszönöm a válaszokat!
Egyelőre megkerültem a problémát, áttettem az ESP-nél hardveres portra, így 115200 BAUD-dal is hibátlanul megy a kommunikáció.
Analizátorral nézve a PIC jól küldi az adatot, valószínű az ESP oldalon van a gond... majd ha lesz rá időm azért megnézem hogy hogy néz ki a szoftveres porton az adás.

Srácok, tudnátok abban segíteni hogy meg mondjátok mivel tudnék programozni dspic33fj64gs606 típusjelzésű MCU-t? Úgy fest mint ha PICKit2 és 3 nem tudja. Köszi előre is.

Pickit2-ről nem tudok nyilatkozni benne van-e a Hp41C által bővített típusokban de a PicKit3-nak tudnia kell az 100%. Legalábbis elméletileg. Most kreáltam egy új projectet és a Pickit3 teljes támogatottságot mutat.

Szia megnéztem most a TRACE funkciót kikapcsoltam és így is ugyanolyan lassú sajnos.
A virtuális XP re én is gondoltam már de még nem volt időm kipróbálni.

Szia
Már gondoltam én is a virtuális gépre de idő hiányában még nem próbáltam.
De ha van esetleg pici időd itt a progim hátha nálad fut rendesen , mert egy igen furcsa dolgot vettem észre ugyanis másik régebbi progimat visszatöltve és szimulálva ott megy viszonylag jól az F7 is de ebben másik PIC proci van. A kódban vannak hibák még nincs kész de már fut egy része.
Köszi a segítséget

Kérdés, hogy ezt a projektet melyik programban nyitottad?
MBLAP X vagy esetleg a régebbiben?
Bele néztem a PK3DeviceFile.dat fájlba, ott tényleg szerepel..

Már nagyon rég az X-et használom. 5.3 verzió van fenn jelenleg.

Köszi a türelmed, megnézem hátha felismeri a PICKit3 saját programja az IC-t.

Nem tudom mit értesz saját program alatt, de ha a Pickit3 Standolne programmert akkor felejtsd el. Azt a Pickit2 programmerből buherálták össze. Az MPlab X-nek vagy IPE-nek látnia kell.

Pedig arra gondoltam.. Ezt felejtsem el?
MPLAB 8.91-et használok, X-et elég hamar töröltem mert nem működött anno.

Ez vissza butítja az PICkit 3-at.
Használd az IPE -t. Tipp: megy portable módban. Én Mikropascalban írok kódot de IPE vel írom fel.

Köszi, emlékszem tényleg erre a programra, ezzel programoztam a PIC32-őt.
Nem is értem miért nem jutott eszembe.. Köszi..

Írtam én is az IPE-t, nem olvasol?
Ám az X IDE is "tökéletesen" működik. 32-est ne akarj a régivel programozni. Illetve akarhattsz, de nem fog menni. Meg debuggolni hogy debuggolod?

Szia!
Nekem megy folyamatosan,és lépegetve is(bár az asm nem az én világom,és így a hibákat nem látom ).

Újra olvasva már látom, és ment is a mancs.. Bocs, elsiklottam felette valamiért. Figyelmetlen voltam.. Köszi a segítséget.

Debugolok egy projectet (16F1824) MPLAB8.92 - PITKIT3 -mal ill. MPLABX - PICKIT4-gyel:
MPLABX alatt kb ötször lassabb a letöltés, a single-steppel is kínlódok.
Ez normáááális?
Előre kösz. a válaszokat.

Hali! Mplabx 5.1, XC8 2.0 -val szívtam pickit4 debug közben, a program lépésenként végrehajtva, össze vissza ugrált, bolondságot csinált, visszatértem pickit3-ra, azzal ugyanaz a progi változtatás nélkül korrektül megy. Gyanús hogy erősen bugos (még?). A sebességgel nem volt bajom,
Akkor lassulnak le ha pl SFR meg van nyitva, vagy watch ablakban sok változó van, ezeket minden lépés után visszatöltögeti a pic-ből ami idő.