Na: Ezt a témát azért nyitottam mert agyilag elakadtam. Eredetileg a kocsimba fejlesztek új elektronikát, ECAN buszra. A jó hír számomra hogy működik az asztalon. Most jön a nehezebb része, ugyanis az ECAN szabvány csak az alsó rétegeket határozza meg.
Igazából hogy a PIC24 DMA rendszerét a váltakozó adathossz miatt ne kelljen piszkálni 16 byte hosszban határoztam meg. Egyfelől mert ez a gyári másfelől ez az MPLAB memória nézet ablakában pont egy sor, és így nem lehet összekeverni... Egy sor egy keret.

A címzést úgy csináltam hogy használtam az EID(17 bit) és a SID(10bit) részt is. EID maga az effektív cím, a SID pedig ki van maszkolva a vétel során tehát ezen a vétel igazából nem múlik. Ha az EID stimmel az adat fogadásra kerül. SID-et tehát egyfajta utasításként kezelem, ezzel is spórolok egy kereten belül a hasznos adatok javára. A SID-be írom be hogy mi a feladat. A SID 10 bitjéből A SID-en belül lenne 6 bit alkot egy visszaszámlálót ami azt mutatja hogy okay ez a keret ugyan megérkezett de ehhez a logikai adatfolyamhoz tartozik még "n" darab, tehát amíg meg nem jött a többi fölösleges nekiállni. 6 bit az 32, tehát ha a keret 32 tagú akkor 32x8 = 256 byte. Ez szerintem elég hosszú ahhoz hogy bármire lehessen használni. A maradék 5 pedig lenne az utasítás kódja. Ez mondja meg hogy az adott végpont mit csináljon. Pl: Mond meg a reflektor állapotát: "Jelentem be van kapcsolva, 3,2A áramot vesz fel az őt bekapcsoló MOSFET meg 56C fok meleg. Üzemszerű állapot."

Bocsánat a hosszú bevezető miatt ennyit úgy gondolom el kellett mondanom hogy nagyjából képbe kerüljön az aki ezt elolvassa.

ÉS itt jön ahol elakadtam. Megjön egy keret, de mondjuk még hiányzik még 4. Le kell tárolni. Persze úgy hogy ha jön közben egy másik akkor azt úgy kell elpakolni hogy az egyes beérkező keretek nehogy felülírják egymást. De hogyan... Úgy értem erre várnék "logikai" ötleteket... Tömböket használjak tartalomjegyzékkel? Lehet csak túlbonyolítom a tárolást fejben... Nos?

Na, ehhez nem annyira értek, csak szoktam kicsit programozgatni, így nem biztos az sem, hogy jól értem a kérdést.
Ha a procid a főnök, akkor elvileg nem jöhet más, mint amit ő kért. (Azaz ő a szerver, a perifériák meg várnak, amíg nem szólitja őket, cím szerint, utasítással.)

Ha az a kérdés, hogy az adatok nem 1, 2, n sorrendben jönnek, akkor azonosítás (gondolom egyedi csomag cím, vagy cím+offset) után a helyükre tedd a memóriában, azaz gyakorlatilag lefoglalsz az elején egy ismert hosszú tömböt (ahány kupac jelet vársz), és azt az érkezés sorrendjében tárolod, de tessék mindenkinek a helyére ülni.
Ha elérted a 0-t (mert gondolom annyira áll az elején a számláló, ahány jelnek jönni kell), akkor lehet nekiugrani 1, 2, n sorrendben, vagy ahogy tetszik.
Ha nem jól értettem, akkor bocs.

Hát én mindenképpen valami ringbufferes megoldásban gondolkodnék, a 24-esekben úgy is van annyi ram mint a dög.
Ezzel kizárt, hogy bármi is kimaradjon.

Érdemes megszakítással bepakoltatni az anyagokat a bufferbe.

Én így szoktam az összes bejövő adatvonalat kezelni ráadásul könnyű megállapítani, hogy van e adat a pufferben, vagy hogy történt e tulcsordulás. (mondjuk, ha több adat jön be mint amennyivel a proci meg tud bírkózni).

Köszi a tanácsokat.
Ringbuffer. Erről nem hallottam... Hogy működik? Hogy állapítod meg hogy van benne?

Általában két mutató tartozik hozzá: egyik a lepakoláshoz, a másik a kiolvasáshoz. Ha mindkettő ugyanoda mutat, akkor nincs érvényes adat. A lepakoláshoz használt mutató nem körözheti le a kiolvasási mutatót, mert akkor felülírod a még ki nem olvasott adatot. Sőt, arra is vigyázni kell, hogy a teljesen teleírt és az üres buffert meg tudd különböztetni. (Egyszerű megoldás pl.: mindig eggyel kevesebb adatot engedsz beírni, mint ahány rekeszből a ringbuffer áll, hogy a beíró mutató ne érhesse utól a kiolvasási mutatót.)

Bővebben itt olvashatsz róla.

Hú, ez nagyon jó dolog.
Ez akkor tulajdonképpen kb ugyan az mint az ECAN modul FIFO-ja, csak mivel "ott" kevés a memória, szoftveresen ki kell pakolni egy GPR, és jó nagy üres területre.

Nekem fragmentalodasi problemanak tunik.
Eloszor is tudni kellene, hogy az uzenetek sorrendben erkeznek-e meg vagy sem?
Egymas utan csak azonos feladotol erkezhet uzenet (CAN eseteben felteszem nem)?
Mi van ha elveszik egy uzenet? Meddig kell varni a hianyzo reszre.

Definialnod kellene hogy egyszerre hany kulnbozo keretet vagy hajlando fogadni. Pl 1,2,4,8 stb. Ez meghatarozza majd a lefoglalando buffer meret.
Pl egy keret nehezhet ki is (eleg pazarlo):
typedef struct _KERET{
unsigned char frameState; itt lehet jelolni a keret allapotat, pl vetel alatt all-e vagy sem meg ilyesmi
long startTime; //vetel kezdetet itt eltarolva timeOut-ot lehet generalni pl 20 s alatt ha nem erkezik meg a keret akkor torolheto (irni kell valami idomero reszt is)
unsigned char address; //valami cim pl.
unsigned char length; //length of data
unsigned char crc; //hibadeketalas
unsigned char data[256]; //maximum length of data
unsigned char receivedPartOfKeret[32]; //melyik resze erkezett meg
} KERET;

Ebbol csinalnek egy tombot:
KERET keretek[4]; //igy egyszerre pl 4 keret veheto

Csak ASM-ben vagyok otthon.... PIC miatt nem vagyyok hajlandó C-t tanulni... Lassan lassan (a főállásom miatt) azért haladok a témával...