Megvizsgálom mi van benne!
A memcpy-t a feltelepített microchip c30 könyvtárból veszem.
Közben kijavítottam a *2, és úgy működik a saját memcpy-m.
Tehát ez működik:

A függvényem:

Szóval tuti a memcpy-vel van a baj.

Az sajnos nem jelent semmit.... Javitottam en mar hibat a mikrocsip usb stack-ben, ahogy a tcp/ip stack-nek nevezett ***-ban is...

Ez van a a W0-ban.(Semmi)

Ahogy elnezem a disassembly-t, ez nem maga a memcpy() fuggveny. Ha kikapcsolod az optimalizaciot, akkor jobban kovetheto, hogy mi miert van az assembly-ben. Mert pl. a fordito latja, hogy te a szabvanyos konyvtari memcpy() fuggvenyt akarod hivni, es azt is latja, hogy fixen csak 4 byte-ot akarsz masolni, akkor nem is forditja bele a memcpy() hivast, hanem maga megoldja a 4 byte atmasolasat, csak esetleg elrontja, mert azt hiszi, hogy mivel a forras es a cel is wchar_t tipus, mov.d-vel masolhat. Elfelejti, hogy a struktura packed. Ez konnyen elofordulhat a gcc-vel. Annyira okos fordito, hogy neha teved.

Amugy meg:

Akkor az lesz a legjobb, ha a saját függvényt használom, és kész. Egyébként hol van az mplabban megírva a függvény? Mert a string.h fileban csak a függvény deklarációja van.

A fuggvenyt magat azt hozzalinkeli, szoval a forras nem hozzaferheto. De hogy pontosan honnan veszi a .a file-t, azt nem tudom. Mellesleg lehet mondani a gcc-nek, hogy ne cserelje le ezeket a hivasokat, talan a -fno-builtin parancssori opcio erre valo. Az mplab-ban meg lehet adni. Egy probat meger. Tehat marad a memcpy() a forrasban, de -fno-builtiin opcio, es akkor meg fogja hivni a konyvtari memcpy()-t, nem kell sajatot irni.

Sajnos ezzel az opcióval is ugyan az a végkifejlett.

Akkor nem erti az opciot vagy valami ilyen gond lehet. Mert amugy a disassembly listan latszott, hogy nem hiv memcpy()-t, hanem maga masolgat. Ha fuggvenyt hivna, akkor nem lenne baj, ahogy nincs is, amikor az altalad irt memcpychr()-t hasznalod.

Mind1, marad a saját memcpy! Köszönöm a segítséget!

Sziasztok! Én először próbálom MPLAB alatt XC8-ban több fájlból összehozni a programot. Vannak még
gondok:
hozzáadtam a projekt header fájl-hoz a .h a source fájl-hoz a .c ket. Az írt header-t #include"saját.h" // ezt így elfogadja, nem tudom viszont a .c-re hogy kell hivatkozni?
A pic port beállításai például a main.c-ben vannak mégsem találja a fordító.
Hát vannak még gondjaim...

Szia!
Ha felrakod becsaomagolva az egész projektet, megnézhetem neked.

Sziasztok!
Az erre vonatkozó általános programtervezési szabályok engem is érdekelnének, most van egy viszonylag nagy, 5000 soros C-s programom, amit megpróbáltam több részre szedni, de sikertelenül. Igaz én MPLAB X -ben..
Van main.c, amiből kivettem a függvény és változó deklarációkat, #define -okat. Eddig működött. De amikor már függvényeket is ki szerettem volna tenni másik .c fájlba, akkor sehogy nem sikerült fordítható/linkelhető projectet létrehozni. Nem tudom pl. mi a teendő a globális változókkal, mert van néhány olyan tömb, amit a kiszervezett függvények is el kell hogy érjenek.
Illetve a pic24ep... .h -t minden .c -be be kellene includolni, és minden .c -hez kell hogy tartozzon .h -is? Hogy szokás?

A globális deklarációknak egy külön .h állomány, amiben a deklarációl egy extern prefix -et is kapnak.

Nézd meg ezt a két hozzászólást, meg a környékén levőket: Link1 és Link2

Köszi mindkettőtöknek!
Folyamatosan követem a fórumot, nem is értem ez hogy maradt ki. Korrekt kis összefoglalás.

Itt a projekt, nagy segítség lenne ha kiderülne a hibája. Olvasgatom magát a C dolgait a globális változókról, az XC8-ban ezt nem-tudom hogy is kell használni.

Szia!
3 hibát találtam a SED1335-pic18.c fileban. Egyik, hogy nem volt include-olva a <p18f4550.h>.
A másik dolog: csomó #define ki volt kommentezve, nem tudom miért.
És el volt írva a #define SED1335_CONROL_PORT, kimaradt a T betű.
Egyébként a main.c-ben is benne voltak a #define-k, feleslegesen.
Mostmár csak azért nem fordul le elvileg, mert nincs elég memória a PIC-ben.

Közben rájöttem, hogy nem a memória volt kevés. A memory modelt átállítottam Large-ra. Utána még hozott egy két hibát. Elírások voltak a __delay_10ms() definiálásnál. Mostmár nálam lefordult.

Szia!
Köszönöm a segítséget! Feltettem az eredeti projektet, még amit elkezdtem XC8-ra átírni - kértem a segítséget. Nálam nem akar lefordulni, máshol kell Large-ra állítani?
Hát beletettem a PIC-be a kódodat, üres maradt az lcd. A main.c ben van hogy négy grafika váltja egymást. Elnézést kérek ha hiányos projektet tettem fel!

Pedig ott kell átállítani, ahol a képen amit beraktál. Nekem lefordul úgy.

Na mindent sikerült több fájlba szétszedni, megoldani, csak a typedef union struct -ok miatt nem fordul még. Itt nem tudom értelmezni a sima változóknál leírtakat.

Itt pl. mi megy a .c be, mi a .h-ba, és hova kerül az extern, ha a ConfigArray-t több forrásból is el szeretném érni?

Szia! A típus deklaráció megy a típus deklarációs h-ba, a 12. sor megy abba a c-be ahol példányosítod, az externes h-ba pedig megy a 12. sor extern-el előtte.
Az externes h-t mindenhová be kell include-olni, ahol használni akarod az adott globális változót, a típusokat tartalmazó h-t csak oda, ahol példányosítod azt.

Az mire jó, hogy az union-on belül egy struktúra van?

Szia! Köszi!
Ez azt jelenti hogy illene egy külön típus deklarációs .h -t is létrehoznom, amiben csak azok -mármint típusdeklarációk- vannak? Így szokás?

Ezt csak gyorsan begépeltem, az eredeti ennél sokkal összetettebb, de a lényeg ezen is látszott. Nem akartam egy 50 soros union-t bemásolni.
Így elérhető ugyan az a változó egy része char-ként is:
ConfigArray.sCFG.OUT3
és uInt-ként is:
ConfigArray.uIntConfigArray [0]
meg long -ként is ha a 10. sor után ott lenne hogy long akarmi;
ConfigArray.akarmi

Értem, köszi!

És arra vonatkozóan van szabály, hogy az __attribute__((address(0x1100))) a .c -ben a definíciónál vagy a .h -ban a a deklarációnál kell megadni? Mert fordul is és jó helyre is kerül mindkét esetben, ami botrányos viszont, hogy ha mindkét helyre beteszem akár eltérő címekkel, akkor is lefordul, és a .c -ben szereplő címre pakolja a változót.
Számomra áttekinthetőbb lenne a program, ha bátran mehetne a .h -ba.

Erre nem tudok válaszolni. Én a C-be szoktam példányosítani. Ha működik h-ban is, akkor használd úgy, de két helyen nem hiszem, hogy szerencsés lenne.

Sziasztok!
Egy kicsit fura lesz, amit most írok de még én sem tértem magamhoz tőle.
Szóval a Projekt Pic18f252 lcd ds18b20 modbus rtu Hitech C18-al.
Megírtam a kódot Microchi C18-al, gyönyörűen lefut, szépen lehet olvasgatni a regisztereket modscan32-vel, szinte hibátlan.
Most átírtam a kódot Hitech c-re, egy-két módosítás kellett csak.
Most azt tapasztalom, hogy a kód sokkal rövidebb lett, ami érthető,mert a hitech c18 az pro verzió, a c18 meg student.
Viszont modscan32-vel loggolva néha nem jó regiszterértéket kapok.
Például kapnom kellene 4-es funkciókóddal 0000h-t erre néha 0505h-t kapok, úgy, hogy nem is változik a regiszter értéke.
Vagy kapnom kellene 3-as funkciókóddal 0000h-t, erre néha 1E00h jön.
Mi a túró lehet ez?
A bufferekhez hozzá sem nyúltam, sem a mutatókhoz.
Valamit tudtok tanácsolni?

Sziasztok!
Én most kezdenék C-ben programozni a PIC-et. A nyelvvel nincs igazán gondom, csak azt szeretném megtudni valahonnan, hogy milyen függvények vannak implementálva az XC8 fordítóhoz. A picxxx.h file megvan, de olyanokat mint pl. a delay nem tudom hol lehet megnézni. Hogyan kell használni stb.