Összefoglaló válasz: nincs.

Ismered a Hanoi Tornyai játékot? Ha több karikát kell helyre tenned, és kevesebb oszlopod van, sokkal több lépés kell.

Jelen esetben annyit kell majd olvasgatni az SD-ről, hogy nem csak átléped az emberi reflexek korlátjait, hanem kivárhatatlanul hosszúra nyújtod a folyamatot még a legtürelmesebb embernek is. Amit tenni tudsz (fentebb már te is fejtegetted), hogy elkezdesz ciklusban olvasni, és megjegyzed mindig az abc szerinti legkisebb ascii értékű file-t, aztán ha a directory végére értél (nincs már több vizsgálható file), kiírod azt, mint legelsőt. Utána mész újra ciklusban megint a legelejéről, és megkeresed a következő file-t, ami a legkisebb plussz érték volt az előzőhöz képest. Pontosan annyiszor kell majd végigolvasnod a teljes directory-t, ahány file van. Mindig csak a következő 1-et tudod majd lelistázni annyi olvasási művelet árán.

A fentebbi adataid nem tudom, honnét származnak, de ami legközvetlenebb korlátot én találtam, hogy a legtöbb közkézen forgó (és eredeti) fat32 filesystem-ben a fat tábla méretileg bele kellett férjen 16 megabyte-ba (kicsit kevesebbe), ami 4 byte-os cluster azonosítókkal számolva maximum 4 millió clustert jelentett, és az minimálisan 1 cluster per file esetén 4 millió file ( forrás ).

Néhány közkézen forgó fat32 filesystem driver már az után keletkezett, hogy a winXP végleg lecserélte a win2k / w98 párost, és azóta a Microsoft nem igazán tett semmit a fat32 driverrel, de az embedded module gyárosok igen. Temérdek sok fat32 driver született és került ki közkézre, amiknek a legkülönfélébb gyengeségeik vannak - amik az eredeti driverben még nem voltak benne. Lehetnek olyan driverek is, amiknek a fentebbi (eredeti) gyengeségét is kiküszöbölték már. Bármi előfordulhat. Bármilyen driver-t is használsz, az valószínűleg barkácsolt, és lesz egy leírása a korlátozásaival együtt. Ha valaha is olyan fat32 drive kerül a kezeid közé, ami bármelyik korlátozását átlépi, filesystem error lesz a következménye.

Vannak más rendezési elvek is, mint pl. itt: Bővebben: Link Nem biztos, hogy annyiszor kell végigolvasni a mappát, ahány fájl van benne, főleg akkor nem, ha a képernyőre csak 10 fájlnév fér el. Ha megvan az első 10, azonnal ki kell írni, és keresni a 11-et, innentől már a proci is tud "pihenni", nem is kell mindent a memóriában tartani, csak ha végiggörgettük az egész mappa listát, vagy még akkor sem, mert pl. elég csak az előző és a következő néhány fájlnevet megtalálni, és így dinamikusan lehet haladni a mappában. Be is lehet korlátozni ezt a módszert, én kipróbálnám, hogy melyik gyorsan tudok sorba rendezni, és mennyi memóriám van. Ha találok egy mappát, ami ennél több memóriát igényelne, akkor egyszerűen közölném a felhasználóval, hogy túl sok fájl a sorba rendezéshez, és egyszerűen kilistáznám. Persze ha keresni szeretne benne, azt megtehetné, de alapból nem lesz abc sorrendben. Érdekes egyébként a feltevés, érdekelne egy megoldási elv.

"és keresni a 11-et" - helyett: "és keresni a 11.-et". Csak dátumnál kell elhagyni a pontot, mint 23-a.

Az természetes, hogy ha van több ram, lehet rá optimalizálni. De ha pontos adatokat nem tudni, csak a worst case-ből indulhatok ki.

Ezért ajánlottam a dinamikus sorbarendezést. Pl. az első 10-et ki tudod keresni egymillió hossz listából is. A következő 10-et is. Innentől kezdve mozoghatsz dinamikusan a listában. Te határozod meg, hogy a kijelzőn hány fájlnév látszik, és hány darabot olvasol be előre. Innentől a RAM használat korlátozva van bármilyen hosszú listánál! A sebesség pedig jobb lesz, mint ha az egész mappának az összes fájlnevét sorba kellene rendezni.

Hogyan követed, hogy hol tartasz a listában az összes index tárolása nélkül?
Honnan tudod, hogy megvan-e a 10 hosszabb csak számokban eltérő fájlneveknél, ha nem olvasod végig az összeset?

Tudod, hogy hány fájl van a listában, nem? Ha tudod, és elölről indulsz, tehát az elsőtől, akkor tudod követni, hogy a 78. mondjuk a labortap.pdf, és innen bármilyen irányba el tudsz indulni. De én csak az ötletet adom, én nem készítek ilyen fájlrendszer listázó programot.
Pl. ha a következő 10-et keresed, akkor veszel egy 10 elemű tömböt, és elindulsz a mappában. Amelyik fájlnév az aktuálistól később van, belerakod a tömbbe. Amikor feltöltődött a tömb, sorba rendezed őket, tovább keresel, mégpedig olyan fájlneveket, amik a 10 között vannak, így az utolsó mindig kiesik. Mire végigérsz a mappán, már csak a következő 10 marad bent a tömbben.

Persze, köszönöm! Közben szerkesztettem, megvárom, arra mit írsz...

Ez a módszer szerintem ilyen 100 elemig még gyors. Az a mappa, amiben ennél több elem van, az speciális esetként kell kezelni, mint írtam. De lehet nem is 100 a határ, hanem 1000. Ezt majd a proci és a kereső fv.-ed hatékonysága mondja meg.
A legfontosabb, hogy a felhasználó ne vegye észre a lassúságot. Ezért kell kitalálni olyan módszert, ami gyorsan behozza az első 10 fájlnevet, a háttérben pedig keresi a következőket. De el is mentheted ezt a listát a fájlrendszerben. Kell hozzá egy ellenőrző kulcs, pl. a mappa tartalma alapján készítesz egy számot, ha változik a mappa tartalma, akkor ismét sorba kell rendezni a fájlneveket. Vagy csak az első 10 fájlnevet mented el egy txt fájlba, a többit majd megkeresed. A lényeg, hogy gyorsnak látsszon, ne kelljen várni, mert annál idegesítőbb nincs.

Elvileg a fájlba listázás nem rossz ötlet, de flash háttértárak esetén nem biztos, hogy hosszú életű. Bár ha ezek a listák elkészülnek, csak akkor változnak, ha változik a mapparendszer az pedig nem olyan nagy számú eset, viszont hamarabb eléri a határt a lista fájl területén, mint a flash teljes területén. Ellenben ezeket a fájlokat létre kéne hozni minden SD-n, amit beteszel, ami először lassú és nem is tudom, mennyire elfogadható. Az a fránya SDRAM kezelés hiánya...

A dinamikus helycserés keresés ettől függetlenül működhet, bár nem tudom mennyire gyorsan olvasható ki 1000-nél több fájlnév, ezt tesztelni fogom. Egyetértek, hogy nem lenne jó, ha várni kellene a következő lista megjelenésére.

Nem muszáj egyből azzal kezdeni, hogy letapogatod az SD-t. Mehet az a háttérben is. Közben meg menjen az eredeti funkció. Ha mégis belépne a mappákba, akkor azt a mappát kell letapogatni, amire szükségünk van. Ha túlságosan nagy, akkor csak dinamikusan/gyorsan, aztán majd a háttérben fel lesz dolgozva. Ha tudsz programozni, akkor meg kell keresni a kiskapukat, amivel a korlátok áthághatóak. Én 16MHz-es prociból indultam ki, szerintem azzal is bőven el lehet érni használható sebességet, te pedig ha jól emlékszem, 50-100MHz-es procit használsz. Sima ügynek kellene lennie. Én nem nagyon találkoztam olyan mappával, ahol 200-nál több fájl található. Az már a PC-t is megakasztja kicsit. Meg egyébként is, meg is tilthatod, hogy ilyen sok fájl legyen egy mappában, vagy figyelmen kívül hagyhatod, esetleg máshogy dolgozod fel. A Lehetőségek tárháza végtelen.
Ha van egy pár GB-os SD kártyád, nehogy ne férjen el pár Kb-nyi információ pluszban...

Nem a mag sebessége az ami korlátoz, inkább az SPI 20MHz-e. Nem a hely kevés az SD-n, hanem attól lehet tartani, hogy ha sokat módosítasz egy helyen egy fájlt, akkor ott 100ezer írás hamar összejöhet, ami megöli a flasht. Nekem szimpatikusabb, hogy csomagonként olvasom ki a fájlneveket és a csomagot RAM-ba tárolom és onnan jelenítem meg. Ha megfelelő sebességgel lehet kiolvasni az egész fájl listát, akkor nem kell sokat várni.
Egyetértek abban is, hogy korlátozásokat is lehet rögzíteni, de inkább olyat, hogy ha túl sok a fájl, ami megakasztaná a listázást, akkor nem rendezné sorba.
Hálás vagyok, hogy foglalkoztatok a kérdéssel, de ezzen nem lezárni akarom az ötletládát, csak megköszönni az eddigieket!

Tégy egy próbát, mennyi ideig tart 100 vagy 1000 fájl nevének kiolvasása SD kártyáról? Csak kíváncsiságból is érdekelne. Közben ne csináljon semmit a proci, csak az adatot várja. Bőven elég csak egy sorosporti 340mS-ig tartott üzenet, nem kell visszaírni a fájlok nevét, mert akkor már a soros porti üzenetküldés is lassít. Szerintem a FAT32 figyel arra, hogy ne mindig ugyanazt a helyet írd. Főleg, ha növekszik a lista. Úgy tudom, ha letörölsz egy fájlt, az fizikailag ott marad, csak meg van jelölve a helye, hogy felülírható. Új fájl mentésekor másik helyen kezdődik a lista. Ezért működik/működött az undelete, unformat parancs.

Ki tudom íratni a kiolvasás időtartamát a TFT-re, de majd csak holnap. Ha lesz eredmény, megírom.
Ehhez az időhöz jön majd a sorbarendezés időtartama, ami erősen függ a fájlnevek hosszától és hasonlóságától, ha jól sejtem.

Azt is figyelembe kell venni, hogy sok fájl (több száz hosszú fájlnevű - FAT32) esetén nem egyszerű visszafele lépkedni a fájlrendszerben. Próbáld meg nagy méretű mappában az előző fálj nevét megkeresni.

Nem szükséges (és nem is támogatott a jelenlegi függvényekben) visszafelé lépkedni, mindig az elejétől a végéig megy a keresés. Egy keresési futam alatt a neveket tároló tömb méretétől függő számosságú nevet kell kiemelni a FAT-ból. A következő futam alatt a következő kezdő feltétel (utolsó név) szerint kell a tömböt újra feltölteni a soron következő nevekkel. Előbb utóbb sorra kerül mind. De a kijelzésnél lehet vissza is lépni (bár én első körben csak előre lapoznék, mint a DOS-ban), csak a kezdő nevet kell beállítani a keresés előtt. A csoport kezdő neveknek talán van hely még (ha nagyobb a csoport, kevesebb a kezdő név is, memória függő, hogy mekkora csoportot tudunk kezelni egyszerre. A csoport neveinek nem kell mind megjelenniük a kijelzőn...). Az viszont biztos, hogy egy futam alatt végig kell olvasni a neveket mind, ez okozhat sebességi problémát, de majd délután tudok erről többet...

Üdv!
A teszt ereménye engem is meglepett.

1000db nnnnnnnn.xxx (n 8 hosszú) nevű fájl kiolvasása, 70ms. A kiolvasás alatt azt kell érteni, hogy a név karakterei bekerültek egy tömbbe. A kiolvasás mindig ugyanabba a tömbbe történt. Más művelet nem történt, de vélhető, hogy nem a műveletek "lassúak", sokkal inkább az SD elérése.

500db, különböző hosszúságú fájlnevek esetén, 50ms. (A C:\Windows\SysWOW64 mappából másoltam ki az első 500-at.

Úgy gondolom, normál használatnál még az ezer fájlt sem éri el egy könytáron belül a fájlok száma, legalább is nekem a windows könytárain kívül nincsenek ilyen nagy elemszámú mappáim. A 32MZ-vel szóba kerülő alkalmazások esetén se hinném, hogy ez másképp lenne, így azt hiszem 1000 lesz a korlát a sorba rendezéshez.

Ezek nagyon jó eredmények. Egy átlagos, 100 fájlt tartalmazó könyvtár 10mS-ot igényel. 10db fájlnévhez maximum 10x10mS, vagyis 100mS. A képernyőn csak egy villanás fog látszódni, szinte azonnal betölt. Szerintem lehet még tovább fejleszteni a rendező fv.-t. 1000 fájlnál még a fél mp is elfogadható, hiszen mégiscsak rengeteg adatról van szó...

Milyen sebességgel kezelted az SD kártyát?

Leírom szavakban az algoritmus működését: 10 fájlnevet akarsz egyszerre kiíratni a kijelzőre. Veszel egy 10 elemű tömböt. Feltöltöd az SD kártyán található fájlnevekkel, amit elsőre visszkapsz (bejegyzési sorrendben, vagy fene tudja). Sorba rendezed őket. A 11. fájlnevét megnézed az SD kártyán, hogy az abc szerint hamarabb van-e tömböd utolsó, vagyis 10. eleménél. Ha igen, akkor a 10. elemet törlöd, helyére berakod ezt a fájlnevet, sorba rendezed ismét, és mész tovább. Ha a 10. elemedhez képest hátrébb van az abc-ben a fájlnév, akkor nem csinálsz semmit. Ha ezzel a feltétellel végigmész a mappán, akkor meg lesz a 10 első fájlneved egy átolvasás alatt, tehát 1000 fájlnál 70mS, ha a sorba rendezés nem igényel többlet időt, mint az SD kártya SPI kommunikációja. Ez csak az első 10-et keresi meg. Ha a lista közepén akarsz keresni, akkor kell egy plusz feltétel, hogy csak egy bizonyos elemnél későbbi (kijelzett lista utolsó eleme) fájlnevek az érvényesek.

Ez jó megoldásnak tűnik, próbálom megoldani ezek alapján. Köszi!
Úgy vettem észre, hogy a létrehozás sorrendjében olvasódik ki.

SPI 20MHz

25M-át nem visz a kártya? Mert asszem a normál SD 400kHz init 25MHz data és a high speed (vagy valami ilyesmi a neve) 400kHz init és 50MHz data.

Én úgy tudom a sima SD max 20MHz, de utána nézek!

Tettem még egy próbát bekapcsolt optimalizálással:
1000 fájl, 55ms
500 fájl , 34ms

Én ezt a samsung specifikációt néztem, de minden más kártya is ment 25MHz el.

Igazad van, máshol is ezt találtam. Régebbről 20-ra emlékeztem és a microchip is ezt a beállítást dobja fel a Harmony-ban, ezért nem gondoltam emelni, de így még gyorsabb lehet.
Ezt a high performance módot is megnézem még, hogy mit takar, esetleg tusz erről konkrét dolgot? (Az SPI ha jól emlékszem tud 50-et is...)

Ok, es mit csinalsz, ha a szazadik elemtol kell 10 nev? Mi az a "plusz feltetel"?

Úgy gondolom, hogy a "plusz feltétel" a 100. elem neve, amihez képest a listázás folytatódik. A listázást mindig az eléjétől vagyunk kénytelenek kezdeni első alkalommal, ezért mindig tudjuk melyik volt az utolsó, amitől folytatjuk. Ha letárolnánk minden 10. nevet(feltéve, ha 10-es csoportokba listázunk), akkor az első végiglistázás után már bármelyik 10-es csoportot ki tudjuk listázni, de szerintem ennek nincs gyakorlati haszna, kivéve a visszafelé lépést , de a DOS sem törődik ezzel a funkcióval...
Most azon gondlkodok, hogy melyik sorbarendezést használjam. A legszimpatikusabb a kupac rendezés, ami számokkal nagyon egyszerű lenne, de stringekkel...

Körbe néztem egy kicsit most én se tudom mit mondjak

Ebben a pdf-ben 16. oldaltól hasznos infók vannak és a 34. oldaltól van a CSD (CardSpecificData) leírása és itt van egy TRAN_SPEED ha azt kiolvasod biztosan tudod mi a maximális sebesség.

Ami kicsit összekavart eddig én azt hittem, hogy 25MHz normál és van speckó kártya ami tud 50MHz SPI-t, de azt olvastam, hogy az 4 bites SDIO-val megy csak, de már ebben se vagyok biztos tiszta leírást nem találtam.

Igen, vegulis megoldhato a dolog. Amikor mesz vegig a neveken, akkor minden nevet, ami a szazadiknal "nagyobb", azt beteszed a kis tizes tombodbe, de ugy, hogy a tombot folyamatosan rendezve tartod (search, insert). Igy a "tul nagyok" majd a vegen kipotyognak. Mondjuk, ennel lassabbra nem nagyon lehetne megcsinalni, de keves memoriaval hirtelen nincs jobb otletem.

Szamokat es stringeket pont ugyanugy kell rendezni. Ket feladat van: osszehasonlitani ket elemet es felcserelni ket elemet. Osszehasonlitani tudsz az strcmp()-vel. Cserelgetni meg ugy erdemes, hogy a szoveget leteszed valahova, es a tizes tombben pedig csak a szovegre mutato pointer van, es azt cserebereled, nem pedig a 10-20 byte-os stringet magat.