PIC32MM esete az errata Retention Sleep mód bejegyzéssel. Bővebben: Link
Ha a program elején Retention Sleep módba lép, a programozó nem tudja felvenni vele a kapcsolatot. Az errata bejegyzés szerint az MCLR reset nem ébreszti fel.

Szuper. Gratulálok microchip.
Gondolom eflszik az asztalodon döglött chip.

A nevek karakterei egy kétdimenziós char tömbben lesznek. Így elég az elemeket sorban karakterenként összehasonlítani. Az összehasonlítás max hosszát (ciklusát) a rövidebbik név határozza meg. A név tömbökben nem fogok mozgatni semmit, a hozzá tartozó indexeket fogom sorba rendezni...
Nem biztos, hogy csak 16 névnek foglalok helyet, lehet, hogy 100-nak, vagy többnek, ez részletkérdés, mert mindent szinte ugyanúgy kell csinálni, csak kevesebbszer kell végigolvasni a FAT-ot.

Azért nem "ugyanaz" a két sorba rendezés, mert az egyiknél elég egy összehasonlítás tömb elemenként, a "stringeknél" egy nem elég, sokszor több karaktermélység után lehet eldönteni, hogy "kisebb", vagy "nagyobb" a név.
Ha ettől eltekintünk, akkor valóban ugyanaz.

Logikailag ugyanaz a ket rendezes, mert a rendezendo lista ket elemet kell osszehasonlitani. Az, hogy az elemek szamok, stringek, vagy akarmilyen mas objektumok, az a rendezes szempontjabol mindegy. A legtobb gyari sort fuggveny ugy van megirva, hogy meghiv egy a user altal megadott kulso foggvenyt, ami osszehasonlit ket elemet. Es altalaban ennek az osszehasonlito fuggvenynek a ket elem index-et adja at, es azt varja visszatereskor, hogy melyik a nagyobb, illetve egyenlo-e a ketto. negativ, nulla, pozitiv.

Ide irhatsz egy olyan fuggvenyt is, ami ket szamot hasonlit ossze:

es irhatsz olyat is, ami ket stringet:

Elso esetben a 'tomb' szamokat tartalmaz, masodik esetben a tomb[ x ] a stringek kezdocimet adja. A lenyeg ugyanaz. A listad áadik és béedik elemet hasonlitja ossze egymassal. Az strcmp() meg egy C konyvtari fuggveny, pont arra valo, hogy ket string-et osszehasonlitson. Azt viszont nem tudom, hogy az ekezetes betukkel mit kezd.

Oké, összehasonlít két stringet, de nem mondja meg, melyik van előrébb az ABC-ben. A kis és nagybetűket a windows nem kezeli külön, csak a megjelenítésben, itt is vannak megoldandó részek, mert először mindent nagybetűsíteni kell. Az általad említett ékezetes betűket is külön kell kezelni, pl. úgy, hogy ugyanannak a kódnak feleltetem meg, mint az ékezet nélküli párja, de a párja előrébb van nála a sorban. Sok dolog van még, amit a gyári függvényekkel nem lehet megoldani, nem is fogom őket használni, csak az elemieket. Eg egyszerű összehasonlításra van szükség karakterenként kiértékelve, erre meg elég egy ciklusba zárt if...

Hat akkor mit mond meg? Pont azt mondja meg, hogy melyik van elorebb az (angol) ABC-ben, mert erre valo. Pont ugyanazt csinalja, mint amit te is meg akarsz irni. Pontosabban, ha te nagybetusre akarod konvertvalni a neveket es az ekezetes karaktereket specialisan akarod kezelni, akkor valoban nem. Az strcmp() az egyik legelemibb string fuggveny, mar vagy 30 eve benne van a std C konyvtartban.

Tehát akkor még is csak nekem kell megírni és ezek szerint mindenki másnak, aki ilyet szeretne, mert ez nem alkalmas.

Igen, ha csupa nagybetuket akarsz, meg ekezeteket, akkor neked kell megirni. De ettol meg az strcmp() arra valo, amire mondtam. Amikor eloszor mondtam az strcmp()-t (mint megoldast a rendezeshez szukseges komparalasra), akkor meg nem volt szo errol a nyakatekert kisbetu/nagybetu dologrol.

Gyártanod kellene egy átalakított ascii táblát, amivel újrarendezed a betűk sorrendjét. A 8 bites ascii tartalma maradhat ugyan az, csak a karakterek pontos pozícióját kellene átalakítanod. Egy statikus táblát ha gyártasz, abból indirekt címzéssel mindegyik karaktert egyszerűen "lefordíthatod", és azokat a stringeket már az strcmp()-vel is össze lehet hasonlítani bináris érték alapon.

Már megint én.
Hamar kiderült, hogy van olyan PIC-em, amit nem ismer a régebbi környezet, így továbbléptem. Most a 3.10-es MPLAB X és az 1.40-es XC32 van fent, mert az 1.40-eshez külön letölthető még az mx-ekhez való library. Mivel zavart a sok warning, ami lényegében csak azt jelezte, hogy ezek külön lettek feltéve, hát kitöröltem ezeket a sorokat.
És lenne egy kérdésem is! Ti hová teszitek azt az "include" könyvtárat, amibe az általatok írt olyan források vannak, amiket több projektben is fel akartok használni? És be lehet-e valahol állítani, hogy ezeket a fordító meg is találja? Vagy az ilyen forrásokhoz teljes elérési utat adtok meg az include-ban?

Wezuv jól emlékszem, hogy tft-t is vezérelsz?
Én 320x240-es (ili9341) kijelzővel próbáltam ki a teljes kijelzőre kép kirajzolását const array-ból direket és dma-val a dma úgy van megírva, hogy először a legkisebb részt rajzolja ki és a végén meg a maradék két rész 65536 többszörösével. Van három eredményem
1. 29.58ms direkt függvénnyel
2. 17.86ms DMA megvártam míg a 3 részben ki rajzolja a képernyőre a képet
3. 10.24ms DMA ez első rész amit kiszámol a µC + 65536 byte és a 3. 65536 byte-ot csak elindítom, de ez alatt tud mással tevékenykedni az µC persze ha megint a kijelzőre kell rajzolni akkor várni kell.

És ha megint jól emlékszem te 5" vagy 7" kijelzőt vezérelsz te használtál DMA-t?
Ha esetleg összekeverlek egy másik kollégával. ne haragudj

Ez a nagykarakteres dolog nem az én igényem, ez egy kényszer. Ha megnézel egy fájlkezelőt, akkor a nagy és a kisbetűs neveket egymás után listázza. Mivel az "a" és az "A" kódja nem azonos, ezért nyílván valamilyen konvertálást kell alkalmazni, az összehasonlítás előtt. Erről tényleg nem beszéltem előtte, de a feladatból következik a szükségessége. Ugyanez a helyzet az ékezetes betűkkel is. Ezért kérlek ne rám haragudj!

Jól emlékszel (sajnos én is sűrűn elfeljtem, hogy kivel miről hogyan). 800x480 felbontással használom, egy teljes kép SQI Flash-ből DMA-val 64k-s pufferrel 0,1sec körüli. Ha a két felbontás arányát nézem, (ami 5) és hogy nem külső eszközről beolvasva nyomod ki a képet, a 10ms reális sebességnek számít (nálam ez 20ms-re jön ki az SQI esetében a tiéddel azonos méretű kép esetén). Ugyanez SD kártyáról, sokkal lassabb lesz, de még használható nálad. Nálam SD-ről elég lassúnak látszik a teljes méretben...

Az ötlet tetszik, ez lesz a leghatékonyabb! Köszönöm!

Tovább gondolva, nem tartom meg a karakterek sorrendjét a hagyomásos sávban sem, hanem egymás után pakolom pl. az "a", "A", "á", "Á" kódokat és más kódokat akár saját sorrendbe is tehetek (pl. @, + stb.), így ezek egymás után értékelődhetnek ki.
Ha ez megvan, jöhet a strcmp() és mindenkinek igaza lesz (ha ez számít egyáltalán! )

Be lehet állítani ezeket a utakat a project tulajdonságoknál a fordítónál két helyen is. Van egy általános és van csak a fordítóra (gcc) vonatkozó. Most nem tudok képet küldeni, ha nem találnád meg, majd délután felteszem...

Találtam ebay-en én is 5"(800x400) vagy 7"(800x480) pxieles kijelzőt ami kompatibilis láb kiosztással van mint a jelenlegi 320240-es tft-m. Valószínűleg én is belevágok majd a nagyobb kijelzők világába.

A kép megjelenítésre én SD-t akarok használni (engem ez az SQI nem fogott meg), egyenlőre jár az agyam, hogy hogy lehetne szépen SD-ről gyorsan képet kiolvasni. Gondolkoztam azon is, hogy veszek egy nagyobb tömböt és ez "cache"-eli az SD-t. Majd ez a tömb kimegy DMA-val és amikor elkezdi kiírni a 65536 byte-os részt akkor az SD elkezdi tovább olvasni a tömböt és reménykedek benne, hogy a DMA gyorsabb mint az SD olvasás (ami több mint valószínű) és nem lesz memória ütközés.

Szerk.:
És egy fill screen nálad körülbelül mennyi idő?

Kétféle módon íratok ki SD-ről. Fájlkezelőn keresztül, illetve direkt eléréssel (megnézem a fájl fizikai kezdőcímét, és onnan folyamatosan olvasom. Ez csak töredezetlen disk esetén működik!). Az első esetben nagyon lassú, a második esetben is lassú, de képnézegetőnek elmenne, olyan 400ms, de ha pontosan érdekel, megmérhetem. Az SQI 4 biten 20MHz-el tolja, ami 10MBájt/sec, ami azért nem rossz. Az SD 25MHz-el jó ha 3-at tud. Ekkora képekhez ez elég lassú vizuálisan. Ha lehetne használni a 4bites SD protokollt, akkor növelhető lenne a sebesség, de sajnos az SQI nem tudja kezelni, esetleg szoftveres keveréssel lehetne valamit alkotni, de nem egyszerű, így inkább betolok 2db 16MBájtos Flasht és az elég kell legyen. Egy teljes kép ugye 768000 Bájt, ami több mint 32 teljes kép. Ezzel szinte minden vezérlő alkalmazást fel lehet építeni, főleg, ha nem teljes képeket tárolok és ez valószínű így is lesz. Sőt elfér mellettük egy webszerver is simán, bár az az SD-ről is elég jól futott, mert a böngészőben valahogy nem zavar annyira, hogy lassan jön be egy oldal, megszoktuk. Remélem nemsokára kijön a microchip is egy olyan MZ-vel, amin lesz SDRAM és SD protokoll támogatás!

Ha már úgyis átkódolással csinálod meg:
Az állománynevek egyforma hosszúak, a rövidebbek betűközökkel kiegészítve.
Ha kijelenthetjük, hogy a nevek 8.3 kompatibilisek, egy három 32 bites szóból álló változó elég a kód tárolásához. Az átkódolás a szöveg elejéről indul, de a legfelső 32 bites szó legfelső (3.) byte -jára teszi a kódot. a következő a 2. byte - jába, stb. A legalsó szó legalsó byte -ja 0 legyen. Ekkor a strcomp 11 byte ellenőrzése helyett 3 db 32 bites kivonás elég:
Esetek (2. név - 1. név):
- az 1. név előrébb van a névsorban: A 2. névben magasabb helyiértéken alacsonyabb kód szerepel, a 96 bites kivonás eredménye >0,
- az 2. név előrébb van a névsorban: A 2. névben magasabb helyiértéken alacsonyabb kód szerepel, a 96 bites kivonás eredménye <0,
- a két név azonos: a 96 bites kivonás eredménye ==0.

Én is gondoltam valamilyen átkódolásra (a string ABC-ben elfoglalt helyének megfelelő érték generálására), de nem tudtam hogyan. Érdekel a megoldás, de sajnos hosszú fájlneveket is kezelni kellene. Bizonyára ki lehet bővíteni hosszabb nevekre is az eljárást. Igyekszem megérteni amit leírtál, mert túlzás lenne állítani, hogy most teljesen értem. Köszi!
szerk: Esetleg létezik erről valamilyen irodalom a neten?

És ha minden egyes kép megjelenítést keresztül tolsz a flash-en, számításaid szerint mennyi idő múlva fog kikopni?

Valamit félreértettél, biztosan rosszul fogalmaztam.

Nem ismerem annyira az SQI-t, de nem lehet csak annyira használni, hogy a clock-ot adja és valami és írod ki rá az adatokat? Valami TX RX reg van nem?

(Most az SD kártya 4bites vezérléséről beszélgetünk, ugye?)
Nem, mert az SD-nek nem csak a 4 adatvezetéke van, hanem van egy 5. commant vezetéke is, amin külön kell kiadni a parancsokat.

Feltettem 25MHz-re az SD-t. Kicsit hezitált, de aztán detektálta. Az eredmény 1ms javulás! Letettem 10MHz-re, az eredmény 10ms romlás. Tehát itt nem az SD fizikai kiolvasása tart több ideig, az kb. 20ms lehet, a többit az eljárások emésztik, olyan 60ms-et. (1000 db 8.3 fájl)

És az CMD az soros? (Képen úgy láttam Bővebben: Link)
Meg van a megoldás SQI soft SPI kombó

Persze, ez értettem a szoftveres kutyulmány alatt.

Lehet nem is kéne sw-sen bajlódni fogni egy HW SPI-t SDO megy a CMD-re SQI 4-bit az adatra és a kettőnek a CLK-ját egy OR kapun átnyomni, ebbe egy csúnyaság lehet nem tudom, hogy van e olyan diszkrét kis 40xx OR kapu ami bírja az 50 vagy 25 MHz.

Most jelenleg SPI-sre van kialakítva a panel, de régen abban a hitben éltem, hogy az SQI az SD kártyához van, úgyhogy kivezettem az SQI-s lábakat, lehet veszek valami adapter aztán kipróbálom. Még a végén csak csak csinálunk egy SDIO így a PIC-be

Ez érdekes feladat, kíváncsian várom az eredményeket!

Megmértem az időket. Egy teljes kép SQI-ről
Optimalizáció nélkül: 153ms
S optimalizációval: 129ms

3-mas optimalizációval nézd az S méretre optimalizál, nem tudom mennyivel lesz másabb, de O3-ban néha úgy láttam disassy-ban, hogy inline-á tesz függvényeket, de biztos van még benne amitől "gyorsabb".