Úgy tűnik egymásba ágyazott struktúrák esetén hal meg a történet...

Szerintem a 10. sor egyszerűen hibás ott
Ott vagy a struct kell elé, vagy typedef a struktúra definíciójához!

Ha nincs typedef akkor kell a struct, ahogy Tanszka is írta, az első példádban ez a hiba.

Az nem az én példám!!
Csak bemásoltam a szemléltetés végett valahonnan, hogy miről van szó...!

A GCC-ben itt a leírás:
Bővebben: Link

Igen, innen vettem én is a név:érték megadást...

Akkor ezért nem árultad el a fordító hibaüzenetét ,
pedig lehet hamarabb kiderült volna

Mi???!!! Nem érted, hogy az nem az én példám, csak neked másoltam ide be, hogy értsd mit akarok ?!! Az én példáimhoz oda van írva, hogy az az enyém!

Most kiabálsz velem? Egyáltalán nem értem, hogy beírsz egy példát, hogy nem tudod lefordítani, utána meg azt mondod, nem a te példád. 17óra 16perc.
Na mindegy, hagyjuk, részemről téma lezárva, örüljünk ha működik.

Istenem..., még mindig nem érted!
Van egy bonyi struktúrám, amit szeretnék feltölteni, de nevesített módon a fentebb jelzett okok miatt! Nem működik valamiért annál ez a módszer. Ekkor vetettem fel a kérdést!
Mivel te nem értetted, mit szeretnék("mert hogy azt nem úgy szokás"), erre reagálva mutattam meg azt a kis(egyébként hibás/hiányos) kódrészletet a netről letöltve! Nem az én kódom az, és végképp nem is arról beszéltem egész idő alatt, csak egyszer, neked bemásoltam ide, hogy lásd...

A többi példa a móricka nevekkel, na azok azok, amiket már én írtam teszt céljára. Ki is derült, hogy támogatja az xc16 fordító ezt a formát is..., ám ez még mindig nem oldotta meg a gondomat, mert a reális struktúrámmal még mindig nem fordul le!

Ezt magyarázom már több hozzászóláson keresztül..., bocs, ha kissé türelmetlen vagyok emiatt.

Megvan a hiba
Korábban létrehoztam pár definiciót az #define -n keresztül. Akkor praktikus módon a neveket a struktúrám azonos nevű tagjaitól kapta.
Most kiderült, ha az értékadáskor olyan a tag neve, ami létezett már definiálva a fenti módon, akkor keletkezett a probléma. Sajnálatos módon az első tag, amellyel teszteltem a feltöltést, pont egy ilyen elem volt, ami definiálva volt már. Kínomban elkezdtem próbálgatni más tagokkal is, és észrevettem, hogy van, amelyiknél nem akad ki, lefordul. Na innen már nem volt nehéz kideríteni, mi a gond...

Nekem mindegy lenne, honnét szedek ki használható függvényeket, csak ami a harmony-t illeti ad1: hasznavehetetlen bughalmaz, ad2: nem veszel ki belőle semmit se, mert egy előrefordított feketedoboz.

Az mla bugmentes, és open source. Ha mégis hiba lenne benne, ki tudom javítani. De azt a community a kb 10 év alatt teljesen kicsiszolta. Nincsen abban már hiba.

Az ok, hogy hibamentesebb, de mit érsz vele, ha nincs benne implementálva minden?! Magad írod meg ? Akkor még ez se kell neked...ha pedig ezt akarod elkerülni(nyilván), akkor talán arrafelé kell keresgélni, ahol a neked kellő dolgok is benne vannak.
Egyébként mindenben van hiba, ami bonyolultabb, mint egy hello world program!

Én a gyakorlatban első lépésben mindig a stabilitás mellett teszem a voksomat. Akkor is, ha pár dolgot újra kell majd írnom. Második lépésben pedig győz a lustaság, és inkább újratervezem szerényebb igényekhez, hogy ne kelljen újraírni semmit

Persze nem lett volna rossz, ha véletlenül szerencsém van, de a jelek szerint ennyire azért nincsen karácsony

Az olimex pic32web panelen (Bővebben: Link) be van kötve az eth modul párhuzamos vonalakhoz is. Lehet vele használni psp-t is meg spi-t is. Extra tapasztalatgyűjtés gyanánt megkérdezném, hogy ami nálad megy 8 éve, abban a projectben ethernet adatátvitelnek mit configoltál be (spi-t? psp-t? ha psp-t, melyik módot?) ?

A weboldal meg spiflash-ban
SST SST25VF016B (16Mbit/2Mbyte).

Próbált már valaki ethernet trafós csati / enc vezérlőkkel pont-pont összekötni pic-eket? Működnek azok az enc vezérlők úgy is, vagy a stack megköveteli már ip packet szintjén is, hogy host vezérlő legyen a túloldalon?

Hali!
Nekem nem világos mit kérdezel, és milyen host vezérlőre gondolsz.

Ez a kérdés a webszervertől teljesen külön téma, másik probléma.

Ahogy most adatátvitel működik, két eszközt bedugok router-be, és etherneten keresztül ip címekkel a kettő eléri egymást. Ha valahol tuti biztosan nem lesz több, mint kettő eszköz, esetleg a router kihagyható lenne. Nem mintha +5k huf földhöz vágna, viszont a +1 eszköz az +1 hibalehetőség. (Épületen belül kell vagy 65 méter kábel, rs485 olyan távolságban már lomha, és a földhurok nagyon kellemetlen. Kell az a dupla trafós csatlakozó a kábel két végén.)

Hali!
Kell hogy működjön, a switch/router hardweresen "nem csinál semmit" ami az adatátvitelbe beleszólna. Persze ilyenkor fix ip kell, azonos címtartományban és cross/keresztkötésű utp kábel.

Mennyire lomha az RS485 65 meteren? En siman elvittem 1 megabit/s jelet 100+ meter UTP kabelen RS485-on. A galvanikus levalasztas az egy mas kerdes, az valoban nagyon hasznos. Amugy ha csak ket eszkozt akarsz osszekotni Etherneten keresztul, akkor meg IP sem kell, egyszeruen Ethernet csomagokat kuldesz az egyiktol a masikig. Pontosabban akarhany eszkoz is lehet, az IP akkor sem fontos. De, ha kettonel tobb eszkoz van, akkor kell egy Ethernet switch (vagy egy HUB). Ha csak ketten vannak, akkor egyszeruen egy megfelelo kabellel osszekotod a ket eszkozt. MAC address alapjan az egysegek cimezhetok. Es akkor nem kell a mikrocsip TCP/IP stack-jevel kinlodni...

Valójában a galván leválasztás a nagyobbik előny. Néha csak amiatt optozni kell, és optos cuccokból az olcsóbbak meg nem visznek akkora sebességet. 19.2-t adnak stabilan, azt kell szeretni. És még azok sem tényleg olcsók.

Aminek igazán örülnék, az egy olyan asic, amit sima uarttal tudok pic-hez kötni (nem is kell rá más, mint egy tx, rx, keret szervezésnek meg lehet mondjuk a 3 millisec, mint a modbus rtu-nál), meghajthatom 115-el, maximum tized annyi áramot kajál, mint egy ethernet phy (és azt is csak akkor, ha tolok rajta adást kifele), ráköthetem a trafós csatlakozót galván leválasztásnak, és nem kerül egyetlen dollárba sem. Vakarom is a buksit, hogyhogy senki sem csinált még olyat?

En CPLD-vel csinaltam az 1 megabit/s atvitelt. Sima 75179 driver-rel hajottam a kabelt. A vevo oldalon volt trafo is, es utana szinten 75179 IC. De a trafon akarmi nem megy at. A Manchester kodolas az egyik legegyszerubb, es az atmegy trafon. Persze az Ethernet trafon nem megy el az 1 megabit/s, oda nagyobb sebesseg kell. De egy 10 Ft-os ferrit gyuru es 2x10 menet mar jo volt trafonak. Mellesleg a 115.2 kbit/s opton rohogve atmegy, csak maceras a DC/DC levasztas miatt. Optinak a TLP118 eleg jo. A problemadra van sok megoldas, de egyik sincs ingyen.

Fogsz egy 5 es egy 10 Mhz jelet, amit a UART jellel kapcsolgatsz. Mondjuk 1 eseten 10MHz, 0 eseten 5MHz megy a kimenetre. Akkor ezt mar at tudod vinni az Ethernet trafon. Dekodolni sem olyan nagyon bonyolult, mert kb. egy monostabil multivibrator meg egy D tarolo kell hozza. Ez sima FM kodolas. Ezt lehet kicsit komplikalni, hogy ha nincs az adas oldalon jel egy darabig, akkor lekapcsolja a differencial adot, igy energiat sporolsz. A vevo meg, ha nem jon semmi egy ideig, akkor 1-et ad a PIC fele. Ezzel a modszerrel a 2-300 kbit/s aszinkron sorosvonal siman atmegy az Ethernet trafon, kabelen. RS422 differencial transceiver (75179) felhasznalasaval.

Bocsanat, elkapkodtam a tervezest. A 10 MHz nem fog atmenni a 75179-en. Valami jobb driver kell, 65LVDS179 vagy ilyesmi. De az elmelet mukodik, es eleg egyszeru.

Igen, én is egyszerű dolgokban gondolkodom, mert ha egyszerűen (és olcsón) nem tudom kihozni, előrébb vagyok az enc424-essel spi porton.

dsPIC33EP család...
Írni szeretném a flash memóriát. A törlés megy, viszont az írással meggyűlt a bajom. Alapvetően két mód közül választhatnék, az egyik a szokott módon, 64 utasításnyi adatot tölt fel az FA0000h címen lévő átmeneti tárolóba, majd onnan égeti a program memóriába..., míg a másik módban az adatmemóriában adhatok meg egy címet, ahol elhelyezkedik az a 64 utasításnyi adat, amit be szeretnék égetni.
Namost azt tapasztalom, ha előbb törlést hajtok végre, és utána írni szeretném bármelyik módon is a memóriát, semmi nem történik. Ha nem hajtok végre törlést előtte, akkor a közvetlenül a memóriából égető verzió működik(ilyenkor simán 0-at írok mindenhová, így nem érdekes mi volt előtte ott), a másik viszont ekkor sem.
Kipróbáltam már egy jópár verziót, egyik sem megy. Az adatlap idevonatkozó részében vannak példaprogramok is, de eléggé hanyagul vannak megírva, így kissé meg van rendülve a bizalmam az iránt, hogy abból értelmesen lehetne kiindulni, ráadásul ugyanazt próbáltam én is, "természetesen" úgy sem ment.
Jelzem nem ez az első programom, ami a flasht írja, elég sokszor megoldottam már, igaz egyik sem volt konkrétan ez a család(a legközelebbik PIC24H, és dsPIC33FJ volt). Ennél létezik egy dual particiós mód is, ebben különbözik a többitől..., de nem látok sehol konkrét utalást arra, hogy ez okozná e a helytelen működést...
Tapasztalt már valaki hasonlót ? Vagy van ötlete, hogy mi lehet a háttérben ?

Hali!
Ha word-os írás-olvasás segít, nézd meg Bővebben: Link a CE417 bootloadert.

Sajnos a Dwordos írás nekem nem jó, mert sokat kell írni(olykor majdnem a teljes flasht), és így igen lassú lenne. De köszi, áttanulmányozom..., hátha kiderül belőle az ok...