Nekem szimpatikusabb az a megoldás hogy a programot pl. SD kártyáról töltjük be (villámgyorsan) PC helyett. Az SD kártya és a mikrovezérlő a játékkártya része, és a betöltés egy menü segítségével történik. Ehhez persze kell rá egy kisebb kijelző is, meg gombok. Az SD kártyára ráfér akár az összes létező játék is. Persze ez a koncepció nem biztos hogy megfelel a te érdekeidnek.

Ez nagy meló lenne, és nem akarok olyanba belevágni amiben nem vagyok 100%-ig biztos, hogy meg tudom csinálni.
Na már most egy SD kártya kezelés valljuk be akár milyen PIC-el is csinálom, nem egyszerű, sőt marha nehéz.
Fat tábla kezelése, fájl kezelés, SD kártya inicializálása (tán ez utóbbi a legkönnyebb része)...stb
Még egy kis kijelző akár el is férne a kazin. Még jól is mutatna, majd később lehetne vacakolni, hogy SEGA-n keresztül vezérelni a fájlkezelést és a feltöltést.
No mindegy is mert az SD kártya kezelését sajnos nem tudnám megírni..

Az SD kártya natív kezelése pofon egyszerű. A FAT32 sem nagy meló, főleg ha csak olvasol a kártyáról, nem írsz.
Tudod hogy mi a marha nehéz? Az USB használata, de még a megértése is.
A vaskos USB specifikáció önmagában is elég elrettentő, pláne ha elkezded magad beleásni...

Én is ebben bízok.
Az USB tényleg durva, szerintem nem e bolygóról származik.
De ahogy nézem, a CAN se piskóta. Legalábbis elég sok regiszter tartozik hozzá.

Mindenkinak az az egyszerű, amit már (legalább kétszer) megírt...

Az USB-nél talán Mikrochip ad is drivert amivel elvileg nem kell külön foglalkozni, kínlódni.
Jó esetben még példa programot is találhatunk, de ugyan ezt SD kártyáról nehezebb elmondani, főleg azért mert mindenki, érthető módon, őrizgeti a megírt programját.
USB-nél sokan tudnak segíteni, SD kártyánál csak kevesen vannak képben, és abból csak kevés tud segíteni.
Ilyenkor lenne jó egy ismerős, haver, barát aki ugyan ezzel a témával, de legalább is azonos a hobbink. Mennyivel egyszerűbb lenne minden

Annyi lehetőség van az adatátvitelre, hogy most kicsit bele is zavarodtam, hogy melyiket is válasszam.
Jó lenne az SD kártya is, jó lenne az USB, és jó lenne az USART is (ha gyorsabb lenne).
Kicsit meginogtam amúgy USB téren is, mert félek, hogy nem leszek képes azt sem megfelelően megírni, legalább is erre következtettek ebből:

Szeretem a kihívásokat, de azért az ősz hajszálakat, meg a kialvatlanságot kerülném

Az SD kártyához is van MC által készített driver (forráskóddal együtt), és nem túl bonyolult a felhasználása. Viszont a használatához legalább 16bites vezérlő ajánlott. Szerintem sokkal egyszerűbb a felhasználása mint az USB-nek, és talán a sebesség sem lesz akkora probléma mint az USB/CDC vagy USB/HID esetén esetén.

Ez az oldal sokat segít SD ügyben (is).

Azon belül: How to Use MMC/SD.
Hú de régen láttam már ezt a weboldalt. Ahogy nézem, szerintem írtak még hozzá, mert pár éve, mikor olvasgattam, akkor mint ha kevesebb leírás lett volna..

Most kicsit össze is zavarodtam...
Kell ülepedjen a dolog, hogy tudjak dönteni..

Egyelőre Hp41C kolléga, javaslatára megvizsgálom a 74HC574-es chip-et.
Lehet tudok a segítségével még egy kis időd kipréselni az adatátvitelből.
64MBit-es memóriához viszont biztosan kevés lesz ez a megoldás.

A FatFs is népszerű, fizetős C fordítók is licenszelik.

Ha elkerülnéd az ősz hajszálakat, akkor a legegyszerűbb a serial portnál maradás lenne, mert oda raksz egy max232-t akármelyik pic mellé, meg a pc-re rádugod az usb-rs232 átalakítót, és röhögve találsz akármilyen pic-et talán még a fiókodban is. Az egyetlen hátulütője, hogy nem kellene túl türelmetlennek lenned az írási sebességet illetően. Míg ír a cucc, elmész inni egy pohár teát, vagy valami. Ha elindulsz a teljesítmény felé vezető úton, ősz hajszálak és anyagi kiadások várnak rád minden egyes lépésnél. Az a türelmetlenség ára. Kettő közül legalább az egyikből biztosan fizetni fogsz, és a valódi fő probléma, hogy még nem döntötted el, melyikből. Ha sikerül eldönteni, utána tudunk neked tapasztalatból annyira pontos tanácsokat adni, hogy utána már félreteheted a kételyeidet. Addig pedig a kialvatlanság marad a nyakadban

Ott már az if, és a függvény érték behívás jó, de esetleg ha nézted ezt a válaszomat is, akkor elárulhatnád, pontosan miért csináltad másképpen. Konkrétan forráskód részletet kellene mellékelni, hogy láthassuk, mivel szenvedsz. Az if()-ekre azonnal másodszor is rákérdeztél, hát megválaszoltam külön csak azt a kérdésedet is.

Ha a problémád alapvetően C ismeret hiány, legalább az első két lecke blokkot javaslom elolvasni itt: c tutorial

Edit:

Maga a hibaüzenet arra utal, hogy egy függvény, amit behívni próbáltál, paramétert is vár, mert előírtad neki a paraméter átvételét is, de nem neki küldtél semmit. Hogy az pontosan mit jelent, az eddigiek alapján már nem jelenteném ki pontosan, az adott környezetben neked kellene látnod a hibásra kijelölt sor száma alapján. A fordító általában kijelzi a hivatkozott függvény fejlécének helyét is.

No igen, mindenképp szívás..
Amúgy most is USART-ot használok, de itt ügye korlát a 128000-es BautRate.
Ennyi a maximum amit átenged a PL2303-as átalakító.
Ezzel működik a 8MBites verzió is..

Üresjáratban ez a maximum amit tud USART-on.
Csatoltam a képet.

Tehát van egy működő megoldásod, amit tovább fejlesztenél. El kellene döntened, ősz hajszál, pénz, ezekből mennyit ér meg, és a költségvetés alapján tudunk majd neked segíteni.

Egy 100 lábas pic 32, aminek normálisan munkamemóriája is van a nagyobb teljesítményű buffereléshez is, latchek sem fognak mellé kelleni, mert elég sok lába van mindenhez, és amin el is tudod majd érni a 64 kbyte/sec sebességet alkalmazás szintjén is, az 1550 huf most a chipcad-nél (+áfa), de ahhoz PC oldalon a sokszálas programozásban is otthon kellene lenni, mert legalább egy 3 szálas C# alkalmazást kell majd összeraknod hozzá (egy szál lemezről olvasni, egyikről írni kifelé, egy harmadikról meg a kommunikációt kezelni a kettő között, meg visszajelzést). Ha nem boldogulsz el C# alatt sem a szálak kezelésétől (pihe-puha lágyság a C-hez képest, de azért oda kell figyelni rá akkor is), akkor felejtsd el az egészet. Csak a pic oldali problémákkal még nem szűnt meg az összes többi is. Ha mellé még 8 bites cuccot használsz, a kevés munka memória miatt az alkalmazás szintű összes sebességed vélhetően annyira le fog esni a viszonylag ideálishoz képest is, hogy nem feltétlen fogja megérni mindazt a hercehurcát, amivel az járni fog. Akkor már jobb lenne a soros portnál maradni.

Én írtam a PC programot is a mostanihoz, gondolom nem hozna zavarba egy újabb program.
De a 64Kbyte/sec az az USB lesz nem?
Mert az USART nem képes rá..
Amúgy mint mondottam, nem fog megtérülni illetve csak pénzkidobás az egész, szóval csak a magam meg pár SEGA fan szórakoztatására készül.
1500Ft körüli PIC még szerintem bele fog férni a fejlesztésbe, az nem egy eget rengető összeg, és akörül mozog az összes.
Kacsingatok ezzel: pic32mx795f512l
5-6$/db ha minimum 10db-ot veszek belőle.
Csak nem biztos, hogy van értelme...

Első körben - szerintem - az UART sebességét kellene feltornáznod maximumra, mert az eddigi 128 kBaud az kicsit kevés. Én is használok USB-UART átalakítót PC-PIC adatátvitelre és nekem minden gond nélkül megy az 1 MBaud egy FTDI FT230XS IC-vel. Ez majd' tízszer gyorsabb mint a tiéd. A cuccomban az adatfolyam több lépcsőben ér a rendeltetési helyre:
PC->FT230X : USB
FT230X->PIC24FJ64GB002 : UART 1MBaud
PIC24FJ64GB002->PIC24HJ256GP210A : SPI 5MHz 16bit

Ennek a PL2303-nak ez a vége. (csatoltam képet)
Ennek a FTDI FT230XS chip-nek a használata nehéz?
Úgy működik, hogy USB csak be van kötve ebbe a chipbe (persze az egyéb körítéssel) majd chipből RX/TX lábak mennek a PIC-be?
Vagy igényel ez valami mást is?
Mert akkor ez szinte ugyan az mint amit én is használok PL2303-as adapter, csak akkor ezek szerint sokkal gyorsabb.
Bár az ára kicsit borsos...

Hány MHz-en járatod a PIC-et?

Másik dolog a beérkezett adatok megfelelően gyors feldolgozása. Hiába villámgyors az átvitel a PC és a PIC között, ha a Flash írása meg csiga lassú soros/párhuzamos átalakítón megy. A legjobb ha soklábú 16-bites vagy 32-bites mikrovezérlőt használsz, ahol a címzás pár gépi utasítással meg is van. Az UART-nak meg a Flash-írásnak létrehozol egy-egy buffert, hogy a két művelet párhuzamosan mehessen egymás mellett. Egyikbe tolod bele a PC-ről fogyadott adatot, majd amikor megtelt, tolod a másikba. Közben az elsőből meg írod a Flash-t. Aztán csere.

Igen, ennyire egyszerű a működése. De vehetsz kész FTDI kábelt is, ha az kényelmesebb.
Az FT230X max. elméleti sebessége 3MBaud.
Sebességek:
PIC24FJ: 32MHz (16MIPS)
PIC24HJ: 80MHz (40MIPS) /Ő az ideje felét TFT frissítéssel tölti/

A Windows meghajtó lehet, hogy csak 128kb sebességet enged, de emlékeim szerint ez a hardver többre is képes.
Emlékeim szerint 9xxk feletti sebesség is elérhető, legalábbis a PIC12F1822vel sikerült. Ha jól emlékszem, a COM portot C-ben(ugye azt használod?) megnyitva meg lehet adni a "szabványos"tól eltérő sebességeket is. Ameddig a PIC, és a protokoll bírja, növelheted. Egyszerű próba lehet a PUTTY, vagy valami más terminálprogram.

Igen ezt írja: "Programmable baud rate from 75 bps to 12M bps"
Bővebben: Link
De a driver nem enged többet.
Szerinted ha PIC és PC-s programban felemelem akkor megnőhet a sebesség?
Drvier nem szól bele?

A Win7 gépemen ez működött, terminálprogrammal (TeraTerm). Úgy saccolom, más géppel is menne.

Nos a kommunikáció sebességének kérdése csak egy nézőpont. Addig emelheted, amíg a vett adatokat fel is tudod dolgozni. Azonban a címet (2*16 bit) és az adatot (16 bit) már nem egyszerű kezelni. Ahogy nézem általában két 16 bites port van a vezérlőkban, a többi port esetén egyes bitek nem használhatók. Így a címet "darabonként" kell a portbiteken beállítani. A vezérlő jeleket is állítgatnod kell, ki kell várni a minimum (előkészítési, tartási, pulzus) időket. Mindezt a csomagban levő összes adatra el kell játszani, addig, amíg a következő csomagot megérkezik.
128kbit / s sebességnél 10 bit/byte -val számolva 12.8kbyte/s, azaz 64 byte 5ms alatt érkezikmeg.

Nem feltétlenül a driver hibája, ha az alkalmazás nem kínál fel nagyobb sebességet. Ugyanazzal a PL2303 eszközzel és a hozzá tartozó meghajtóval a Tera Term csak 230400-zal kínált meg, a Hyperterminal pedig megajánlotta a 460800 és a 921600 bps sebességet is.

Igen egyelőre hiába emelem a sebességet, ha a programom úgy sem tudja kihasználni.
De az általad javasolt 74HC574-es IC-ékkel lehet elérném sőt meg tudnám haladni a mostani 74HC595 által elért átviteli sebességet. (most 9Kbyte/s)
Mivel most a 74HC595 miatt rengeteg időt fecsérlek el a bitek kiléptetésével, de ha byte-onként tudom kiküldeni az adatokat, akkor a 24cím külön bitenként bemozgatása lerövidülne 3byte és 2vezérlő lábra ami mind kódban mind pedig utasításban drasztikusan meglátszana.
Ha elérem a 11kbyte/s-os sebességet akkor viszont már lehetne emelni a küszöbön, persze csak akkor ha a driver nem szól közbe..

Amit mindjárt ki is próbálok.

2db 16-bites és 1db 8-bites port (+ pár vezérlőbit) elegendő 16MByte memória kezelésére is. A 100+ lábszámú 16-bites vezérlők mind jók erre - szerintem. A 32-biteseket nem ismerem annyira, de feltehetőleg ott is ugyanez a helyzet, ill. a hardveres támogatás is adott lehet.
PIC24HJ256GP210A-nál a 16-bites SRAM írása 5 utasításciklus.

Az egykor írt 64 mbit nor flash-el a legnagyobb baj, hogy 64kbyte-os szektorokat előbb törölni kell, és ott 0.5 sec az átlagos törlési idő. Utána lehet csak égetni a cuccost - az már gyors. Az összes sebesség egyik problémája, hogy ami adatok a törlési idő alatt érkeznek, azoknak helyet kell szerezni valami bufferben. Az utólag felvetett 8 megabit-es flash-ről nem tudok típusjelet, annak nem tudok utána lesni.

AM29F800.
Nem így működik.
Minden írás előtt törlöm az egész memóriát, így a beírás folyamatosan történhet.
A törlési időt nem számolom bele a teljes átviteli sebességbe.
A törlési (6) szekvenciák kiadása után automatikusan megy végbe a chip törlése, PIC-el csak azt vizsgálom, hogy mikor végzett.
Ha végzett a törléssel memória, akkor mehet az adatküldés, fogadás és beírás.

Na igen. Itt jól jöhet egy PIC32 pl. 128kB belső RAM-mal megáldva. És ha még hardveresen kezel megfelelő méretű külső memóriát is... Az adatátvitelek DMA-val megtámogatva... hmmm...
Meggondolandó.