Igen, ez egy TCP/IP, harmony "segítség". Próbálom elszeparálni, ami sikerült is, csak ezt nem értettem miért. Köszönöm a magyarázatot!

De erre az xc32-ld alatt a remove unsued sections is jó (mármint a nemhasznált fv.-kre).

Ha csak az volt bepipálva, nagy lett a kód.

Az ha jól tippelek, csak azokat szedi ki, amiről a fordító is el tudja dönteni, hogy nem lesz használva. Azt, hogy másik modulból egy függvény fel lesz-e használva, arról csak a linker fog tudni, így azt kell felokosítani.

Vagy van olyan eset, ahol indokolt a programmemóriát feleslegesen foglaló kódrész? Talán akkor, ha több fejlesztő akarja egymás függvényei használni, de akkor nem a lefordított kódot küldik el. Nem tudom miért nincs ez alapértelmezésben beégetve a fordítóba...

Igazabol mindkettot meg kell adni ahhoz, hogy kidobalja oket. A linker csak akkor tudja kiszedni a nem hasznalt fuggvenyeket, ha mindegyik kulon-kulon section-ben van. Kulonben nem tudna, hogy meddig tart a fuggveny.

Azert mert nem szokas 220 kilobyte-nyi felesleges kodot irni. Minek irnal ennyi felesleges fuggvenyt? Az ilyesmit konyvtarakkal szokas megoldani, nem pedig ugy, ahogy a mikrocsip csinalja. Ennek meg az a modja, hogy minden fuggveny egy file, es a sok leforditott fuggvenyt egy konyvtarba osszerekja a konyvtaros (librarian vagy archiver, valoszinuleg: xc32-ar.exe). Ezek utan, egyreszt nem kell minden alkalommal az osszes fuggvenyt ujbol leforditani, masreszt a linker csak azokat teszi a vederedmenybe, amire a programod hivatkozik. Az osszes strcpy, strcat, sin, cos, es tarsai ilyen konyvtarbakban vannak. Igy kellett volna megcsinalniuk a tcp/ip, usb es egyeb reszeket is.

Az a baj a libbel, hogy majd minden chiphez külön libet kellene csinálni, mert ahány típus annyi féle periféria (azért is van ennyi #ifdef a forrásban), nem beszélve arról, hogy rengeteg dolog van, amit nekünk kell beállítani (pl. USB-nél milyen osztály, mekkora buffer stb.). Így sajnos lehetetlenség LIB-be befordítani, mert úgy járunk, mint pl. az XLCD könvtári függvényeivel, ahova bedrótozták melyik lábakhoz kell kötni a kijelzőt.

Abban egyetértünk, hogy lehetnének ügyesebbek is a microcipnél, de ha már ilyenek, akkor ez a funkció ha alapból be lenne kapcsolva, semmit nem zavarna, mert ha ügyesen írjuk a progit, akkor nem kotor bele, ha nem, akkor pont jól teszi, ha belekotor. Szóval én ez nem kapcsolnám ki és nem is fogom még a saját kódjaimnál sem. Legfeljebb kíváncsiságból mert ha nagyobbat fordít kikapcsolva, akkor béna kódot írtam, pontosabban valamit megírtam, amit nem is használok.

Igen, ebben lehet igazsag. Nem mindent lehet megoldani driver-ekkel. Ettol fuggetlenul, azert lehetne sokkal jobbat is csinalni. Volt szerencsem hibakat javitani mind a TCP/IP, mint az USB stack-jukben. Borzalmas nagy takolmany az egesz, se fule, se farka.

Ennel vannak rosszabbak is. Pl. en mindent -Wall -Werror gcc opciokkal forditok (ARM-re, AVR-re, Linuxra), ami annyit tesz, hogy minden aprosagert szol a fordito, ami nagyon hasznos. Ezt probaltam mplab alatt is annakidejen, de nem lehetett, mert a gyari mikrocsip kodban tobbszaz warning volt. Ha nem kellett a kodba mikrocsip cucc, akkor igy forditottam. Eleinte zavaro, hogy mindenert szol, aztan kiderul, hogy megeri, mert nagyon sok debuggolast lehet megsporolni vele. Persze van par dolog, amit nem hagyok neki, pl. a nem hasznalt valtozokert nem akarom, hogy szoljon, megadom -Wno-unused opciot, es mar nem is szol erte. Ha egy fuggveny static, es nem hasznalja senki, akkor a gcc magatol is kiszedi, ha be van kapcsolva az optimalizacio. Ha nem static, akkor a C fordito nem szedheti ki, mert nem tudhatja, hogy mas forrasbol fogjak-e hasznalni. Ezert es masert is erdemes a fuggvenyeket static-nak deklaralni, ha mas forrasbol nem hasznalod.

Nálam is be van kapcsolva minden hiba és figyelmeztetés, nincs is gond, ha fokozatosan felépítve készül a progi, de amikor össze kell fésülni egy ilyen stack-el, az már tud generálni jó néhány fegyelmeztetést. Erre még az is jön, hogy nem mindegy melyik fordítóval fordítom. Az v1.40 warning nélkül fordítja a TCP/IP forrást, az 1.42 már nem hagyja szó nélkül a memset és társait, mondván, nem kopatibilis. Saját forrásuk könyörgöm!

A hibauzenet lenyegeben azt jenelti, nincs prototype a memset() fuggvenyhez (implicit declaration) , azaz hianyzik az #include <string.h> a forras elejerol. Az implicit declaration az, amikor egy fuggvenyt ugy deklaralsz, hogy meghivod. Ez megengedett a C nyelvben, de nem javasolt.

Attól eltekintve, hogy látszik, vannak ilyen jellegű hiányosságaim a C nyelv ismeretében, felmerül a kérdés, a két eltérő verziójú fordító miért nem egyformán kezeli azt, ami ezek szerint alap kérdés? Valamint a microchip fejlesztők miért nem ismerik a C alapjait, vagy ha igen, miért nem mutatnak példát annak mintaszerű használatáról? A kérdés, természetesen költői...
Pótoltam a gyári forrásban a hiányokat (#include <string.h>
#include <stdio.h>), Köszi!

Van egy ilyen programrészletem:

A "ProgramInfo" egy struktúratömb és mellesleg így néz ki:

A fenti ciklusban a PIC a struktúratömbböt beleírja az EEPROM-ba, annak 50. memóriacímétől kezdve. A DataEEWrite() függvény u8 típusú (unsigned char) értéket vár, az "m" nevű mutató ezért u8 típusú. A dolog szuperül működik a gyakorlatban, viszont a fordító warningot dob a "m=&ProgramInfo;" sorra:

Hogyan kellene ezt megoldani warning nélkül?

Esetleg próbáld meg az m = &ProgramInfo[0]-al.

A "Programinfo" az "EgysegTipusInfo_type *" tipusu, amit nem toltheto be "u8 *" valtozoba. Ezert kell egy cast-olas:

Es nem kell az &, mert ha tombrol van szo, akkor a tomb neve siman leirva (sem [], sem &) a tomb cimet jelenti.

Az char * lesz, ami meg mindig nem u8 *.

Bocs, ez nem igaz, ezt elirtam. Az "&Programinfo[0]" tipusa ugyanaz, mintha csak annyit irnal, hogy "Programinfo" mindenfel & es egyebek nelkul. Es az tovabbra sem "u8 *". Mindenkeppen cast-olni kell, hogy ne legyen warning.

Most, hogy olvasom a castolást, lehet előbb rendesen végig kellet volna olvasnom, valahogy kimaradt a típus dolog a fejemből.

Köszönöm, így már jó!

A következő kérdésem:
Van egy kétdimenziós tömbböm, mely így néz ki:

Jelenleg ő egy globális változó, és szeretném ha ez nem így lenne. Két függvényen belül van használva, a Menu() függvényben és a vlcd2tft() függvényekben. A vlcd2tft() függvény kizárólag a Menu() függvényben van meghívva, ezért azt szeretném ha a kétdimenziós tömb deklarációja átkerülne a Menu() függvényen belülre. Azt nem tudom csak, hogy ebben az esetben hogyan kellene átadni a tömb adatait a vlcd2tft() függvénynek?
Tehát szerintem kb így nézne ki az egész:

A program így lefordul ugyan, de hülyeségeket csinál.

Én csináltam egy kis kódot


Nálam hibátlanul ment.
Kicsit nálad belekavarodtam VLCD-kbe, nem lehet hogy valahol scope probléma van?

Ennek mennie kéne, más baj lesz ott.

Ha a Menu() fuggvenyben igy deklaralod a VLCD tombot, akkor az a stack-en lesz eloallitva. Biztos, hogy ez a cel? Elegendo a vlcd2tft(VLCD); nem kell az & meg a ket 0-s index.
A vlcd2tft() deklaraciojaba meg nem kell a *, mert akkor az azt jelentene, hogy a kapott pointer (VLCD) egy char mutatokat tartalmazo tomb cime. De a valosagban egy char-okat tartalmazo tombrol van szo. Elvileg erre hibauzenetet kellett volna kapnod. A warning is hibauzenet, nem szabad folotte elsiklani. Es eleg csak megadni a masodik indexet, tehat:

static void vlcd2tft(char VLCD[][MAX_SZELESSEG+1])

Az attól függ, hogy a függvényen belül mire használja. Ha egy pointernek ad értéket, akkor kell a *.

Jelen esetben a VLCD parameter mindenkeppen pointer a [] jelek miatt, a * csak azt donti el, hogy pointerekre mutato pointer vagy char-okra mutato pointer. Az viszont nagyon nem mindegy.

Pontosan úgy van ahogy írtad. Köszönöm ismét!

Használhatok-e ilyen függvényhívást?



Magyarul azt szeretném elérni, hogy ha hibás a kiolvasott érték ( pl DS18B20 CRC hiba, vagy egyéb érzékelőnél mondjuk túl nagy az eltérés az előző méréshez képest) akkor a függvény visszatérési értéknek a paraméterként megkapott értéket, azaz az előző értéket adja vissza!

Én ilyesmiket úgy szoktam csinálni hogy a függvény visszatérési értéke signed char, és hiba esetén negatív számmal tér vissza. A negatív szám egyben hibakód is lehet. Ha nincs hiba akkor pedig a mérési eredmény a visszatérési érték. Azaz:

De úgy is lehet hogy a függvénynek a változó címét adod át (amúgy is azt kell ha azt szeretnéd hogy a függvény megváltoztathassa!) és a függvényt úgy írod meg hogy hiba esetén ne módosítsa a változót. Ez esetben nem is kell egyenlővé tenni a változót a függvény visszatérési értékével hiszen a függvény 'magától' átírja:

És azt is lehet amit te írtál, azaz hiba esetén azzal tér vissza a függvény amit kapott, ha nincs hiba akkor pedig mással.

Sziasztok!

Egy MAX7219-es ict próbálok működésre bírni, de sehogy sem akar össze jönni. Segítene valaki? Az adatlap alapján ezt a kódot sikerült össze raknom:


A kapcsolás pedig Proteusban készült. Feltöltöm.

Előre is köszönöm!