Szerintem nagyobb pic-et használni még nem a világ vége, a file system lib egyébként is meg fog követelni nagyobb program memóriát, az kicsi pic-ekbe bele sem fér, nagyobb pic-en meg (32 bitesek) mindegyiken van több spi / i2c. Mazohista dolog multimédiás alkalmazást 8 bites pic-re rakni. Azok nem arra vannak kitalálva.

A tápfesz lekapocsra nem egyértelműen azt javasoltam, hogy ne csináld, hanem hogy gondold át. Egy mai sd készenléti üzemben 25-35 uA körül fogyaszt (adatlapján megtalálod). Ha mellette ott van valami áramkör, ami viszont folyamatosan működik, és mA kategóriában fogyaszt, kicsit nevetséges kínlódni pár10 uA miatt.

Ha mégis kapcsolgatod az sd-t, arra vigyázz, hogy nem kapcsolhatod le addig a tápfeszt, amíg kimeneti jelekkel meghajtod a kártyát, tönkre teheted vele. Az összes felé küldött pic kimenetet át kell állítanod bemenetre, és legalább az nCS lábon kell legyen külső felhúzó ellenállás. Miután azokat átkapcsoltad, kivártál legalább 10 uSec-et a parazita lecsengésekre, utána kapcsolhatod ki a tápfeszt, és akkor cserélheted a kártyát is.

Egyébként az sd tipikusan hot swap. Semmi baj nincsen azzal, ha raksz az alkalmazásodra +1 gombot, meg két színű ledet ami jelzi a "kiadás" gomb megnyomása után piros / sárga / zöld színekkel, hogy mi a szitu az eltávolíthatósággal. Ha nagyobb pic-et használsz, és kényelmesen van mindenféle erőforrásod (szabad láb, program memória), igazán nem ügy megoldani.

Nem akarok túl nagy PIC-et erre elpazarolni.
Minél olcsóbb annál jobb, SD kártyát meg úgy is meg kellene oldanom 8bit-re is.
Van vagy 1000-1500db PIC-em, a legtöbb 18-as szériából, szóval ami ingyen van az jó...
Ezt most 18F24K20-ra írom.
Ha nem megy, akkor más megoldás kell..

Agyaltam egyébként azon is, hogy kellene egy SD kártya modult készíteni aminek van saját kis parancssora. SPI-n vagy USART-on lehetne vele kommunikálni.
Kiváltana sok szórakozást és program memóriát..

Talán hasznos lehet, ha tudsz az OpenLog projektről. Bár eredetileg nem PIC... Soros vonalon kommunikál, 64GB kártyát kezel.

Segítek linket kutatni: Open Log

Apropó fat32-ből a 64 gb egyébként már "nem biztonságos". Létezhetnek olyan filesystem driverek, amik normálisan kezelik, de túl sok van közkézen olyanokból, amik nem. Bővebben: Link

Úgy látszik nem csak nekem jutott eszembe ez a megoldás.
Szuper, de mivel van már ilyen a piacon le is hajlott a szám széle..

Úgy gondolom, hogy a teljes SD kezelésre a kisebb PIC-ek nem alkalmasak, erre ott vannak a nagyobb tesók mint amire én is írom 32MX795 vagy 460.
De kisebb leredukált kóddal (csak éppen arra amire kell) meg lehetne írni az SD kezelést, kisebb PIC-re is.
Igazából itt amire szükségem van az nem más mint időközönként kiírni a letárolt adatokat.
A legjobb az lenne, ha minimum 512byte-os buffer tudnék létrehozni, ami talán a linker állomány kicsi módosításával elérhető lesz. Fájlkezelés, mappa kezelés nem igen kell.
Úgy gondolom az alap SD inicializálás és az SD alap adatok begyűjtése mellett a FAT tábla olvasása elegendő lesz az újabb fájlok beírásához. Ha ezt mind megírom, akkor egy letisztul átlátható kicsi kis kódot fogok kapni.. (legalább is remélem)

Bár már agyalok rajta, hogy lehet még sem ez a PIC lesz a megfelelő, olyan kellene amiben legalább 2 MSSP modul van. Azt hiszem 18F46K22 lesz a nyerő..
De még kicsit kínlódom, mert ide már kelleni fog szintillesztés, már mint a 3v-os SD miatt.

Ti hogy oldjátok meg az 5v-ról való SD hajtást?

Eleve a FAT magában nem kicsi. Nekem van egy adatgyűjtőm ami SD-re gyűjt, onnan USB-n olvasom ki az adatokat, amikor akarom. 18F2550-en fut, de nincs FAT, csak direkt SD címkezelés. Így is meg lehet oldani és akkor az SD-t ki se kell venni. Hátránya, hogy lassú a kiolvasás, de a használhatósága függ az adatok méretétől. FAT-ot nem tennék 8 bitesre, ha nem muszáj, bár vannak kis méretűek, körül kell nézni, mert ezt magad elég nehezen írnád meg, semmi értelme...

Mire gondolsz, akkor amikor a FAT tábláról írsz?
A FAT tábla csak addig kell, míg megvizsgálom melyik Klaszter szabad, és a foglaláskor ebbe írok be, de másra most jelenleg nem használom.
File olvasásnál is csak arra, hogy kiszámoljam, hogy ha nagyobb egy klaszternél a fájl mérete, hol folytatódik a fájlom.

A PIC18F46K22-re nem kell szintillesztés, üzemel 3.3V-ról, és 16MIPS-en is fut (64MHz).
Ezzel már akár MP3 lejátszó is építhető (VS1053-al).

Nem tudom mit válaszoljak arra, hogy mit jelent a FAT tábla. Talán azt, hogy neked mit jelent? Ha ki akarod venni az SD-t és kártyaolvasóval áttölteni az adatokat a PC-re, akkor FAT, vagy FAT32 formázás szükséges. Ha ennek megfelelően akarod kezelni, akkor teljes FAT kezelésre lesz szükséged. Ha módosítasz egy fájlt, a FAT bejegyzéseken is módosítanod kell...

Azért kérdeztem mert nem értettem, hogy mitől lenne olyan nagy a FAT kezelése.
FAT bejegyzést csak akkor kell módosítanod, ha kicsúszol a klaszterméretből.
Ha nem, akkor nem kell.

De most amúgy is arról beszélünk, hogy ki írjuk SD-re a letárolt adatot.
Itt nem módosítunk semmit, hanem létrehozunk egy új fájlt.
Innen már egyértelmű, hogy ez az utolsó FAT bejegyzés utáni címre fog kerülni és a fájl méretének megfelelő klasztert le is foglaljuk.

Módosításra nincs szükség, legalább is ebben az esetben nem, ha lenne akkor persze már bonyolódik a helyzet..

Idézet:
„Ezzel már akár MP3 lejátszó is építhető”

Ez talán egy kicsit erős példának tűnhet, így utólag belegondolva.
Az biztos, hogy megoldható vele, de csak a kihívás miatt fogna bele az ember.
Erre már nagyobb teljesítményű mikrovezérlőt használnak.
Az egésszel csak arra akartam utalni, hogy ilyen kisebb adatgyűjtő alkalmazás megoldható vele (SD kártyára írás FAT fájlrendszerrel).
Bár írtam PIC18-ra FAT16 és FAT32 kezelést, már én is inkább 16 bites PIC-et használnék ilyesmire.

Megtekintve az adatlapját, nem volt annyira egyszerű ez a Chip.
Kell a kihívás és csípem a 8bit-es PIC-eket..

Én is, sok minden megoldható velük.
Kicsit el is ragadtattam magam, és ezért írtam az MP3 lejátszós dolgot.
Aztán belegondoltam, hogy nem mindenki kezd el pont 8 bites pic-el MP3 lejátszót
építeni, főleg assembly-ben.
Én belefogtam, de nem fejeztem be...

Nagyon állat.
Assemblyben gondolom még nehezebb, már mint az SD kártya kezelése...
PIC18 forever

Ha szabad érdeklődnöm, hogy a pékbe csináltad?

Bejegyzések a fat táblában, a főkönyvtárban, olvasni a file-t, dekódolni pcm-re az mp3 frameket, túl sok munkamemória az mind, hogyan volt arra elég egy 8 bites pic memóriája? Bocsi, de egy kicsit hitetlenkedem.

Az MP3 dekódolást egy VS1053 végzi (Ezt írtam az eredeti hozzászólásomban, csak az idézetből kimaradt a vége. Bocs, ha félreérthető volt.)
Maga a fájl olvasási sebesség (rendesen FAT táblát használva) elég a dekódernek, de az mp3 frame-ek megszámolása, "tekerés" előre/hátra már nagyon sok időbe telt, ezért ezeket ki is kerültek a programból. ID3 adatokat is csak a fájl elejéről dolgozza fel (ID3v2-t), ID3v1-et nem.

don_peter:
Köszönöm.
Hát... nekem C-ben lenne nehezebb, mert csak assemblyben tudok programozni.
Tudom, hogy nem szerencsés dolog leragadni benne. Majd próbálok mást is megtanulni.

A bal oldali nagyobbik tok micsoda a panelen? Sajnos a fotón nem látszik a pontos típusjel A jobb oldalit a lábszám alapján be lehetett azonosítani, az a vs.

Az egy PIC18F67K22.
Kellett a nagy lábszám.
Külön SPI buszon van az sd kártya, meg a vs1053. A kijelzőt 8bites párhuzamos módban használtam, hogy minél gyorsabban tudjam küldeni neki az adatot. Van még egy uart is hibakeresésre vagy bővítésre, és néhány io kivezetve főleg a nyomógomboknak.
Azóta készült egy nagyobb nyák pic24ep512gp806-al, meg színes tft kijelzővel.

Annó pár éve én is csináltam ilyet.
PIC18F67K22 + VS1053 + SD kártya + RS-485 + 2x16os kijelző + 2 gomb ( túrista tájékoztató 23 nyelven)
Én C-ben csináltam. Nem mondom hogy egyszerű volt, de működött(működik).

Én is nagy fába vágtam a fejszémet, amikor belekezdtem.
Kevés tapasztalatom volt még a programozásban.
Nem nagyon tudtam, hogy miket tudok majd megvalósítani azokból a funkciókból,
amiket terveztem bele. Ahogy haladtam az egésszel, úgy kezdtek kirajzolódni a határok.
A vége felé meg már agyaltam a 16 bites mikrovezérlőkön, és arra jutottam, hogy inkább újrakezdem az egészet.
Tanulásnak azért jó volt.

Kicsit ismerkednem kellene jelenkori SD kártyák gyakorlati paramétereivel, és keresném a kényelmesebb utat. A laptopomban van sd kártya olvasó, és azon filozom, hogy az abba rakott kártya CSD registerét (Card Specific Data) hajlandó lehet-e kiolvasni a win 7 valami diagnostic tool-al? Ismer valaki arra handy módszert / programot?

Ennek a kérdésnek semmi köze a PIC-ekhez. Tedd fel olyan témában, amibe illik!

Srácok, ti azt hogyan oldottátok meg, azt ha csak egy meghatározott típusú fájlt akartok csak listázni? Mondjuk csak ".txt"-ket.
Van erre valami ami csak a kiterjesztést tárolja?
Vagy valami kiterjesztés azonosítót?
Természetesen a ".txt" lehet akár ".bin", ".lot", ".akarmi"-is.

Kiolvasod sorban a fájl neveket és keresed a végükön a 4, vagy több karaktert (nem csak 3 betűs kiterjesztések vannak. Az első a pont). Ha egyezik, megjeleníted.

Így csinálom most is.. Nem a legjobb megoldás.
Gondolom akkor ennél nincs egyszerűbb.
Amúgy ha hosszú fájlneves, akkor pont sincs.. (mert a rövid fájlneveket szűröm)

Én egyetlen filesystemről sem hallottam olyan híreket, hogy sorba rendezné a file neveket kiterjesztés alapján. Persze lehet rá olyan drivert írni, ami elkezdi rendezgetni a könyvtárban a file neveket, és végül jellemzően sorrendben fogod megtalálni, amit keresel, de az általános gyakorlat olyat nem csinál. Ha file nevet keresel, sajnos végig kell olvasni a teljes könyvtárat, és végigparsingolni az összes hosszú filenevet is.

Itt inkább a kiterjesztésre való szűrés a lényeg, hogy olyat ami nem engedélyezett ne tudjon majd listázni a rendszer. Marad a feltételes szűrés. Rövid fájlnév utolsó három (maradjunk a 3 karakteres kiterjesztéseknél) karaktere adja meg, hogy mi a kiterjesztés, tehát ezt a 3 mat vizsgálom. Nem szép, de működik.
Hosszú fájlnév szűrését kihagyom, mert ott végig kellene futtatni a tényleges karakter sor, pontot keresve és a rákövetkező karaktereket vizsgálni.. Ez hosszabb folyamat lenne mint a rövid fájlnév vizsgálata.. No mindegy, ez marad most...

Butaság lenne végigfuttatva keresni a pontot, főleg, hogy több pont is lehet a fájlnévben. Megvan, hogy milyen hosszú a fájlnév (len), így a végétől visszafelé kell keresni a pontot. Szerintem nem sokkal könnyebb a rövid fájlnevekkel, mert ott is meg kell állapítani a hosszát, mert nem feltétlenül 8 hosszú, lehet rövidebb is. Ha meg megvan a hossz, akkor onnan már ugyanaz a művelet mindkét esetben. Egyébként az az egyszerűbb része a dolognak, hogy mit ne listázzon, az sokkal bonyolultabb, hogy mindezt esetleg névsorba is tegye...

Részemről nem lennék annyira derűlátó, hogy azt higgyem, annyira egyszerű lesz.

A rövid file nevek szabályaira ha emlékszünk még anno 1995 előtti időkből, kb úgy nézett ki, hogy az angol abc nagybetűi, semmi ékezet, nagyon kevés spec karakter, maximum 8 karakter file név, egy darab pont, utána maximum 3 karakter kiterjesztés - kizárólag nagybetűvel minden.

A mai filesystemeknek ha csak annyit írsz "readme.txt", azt némelyik már hosszú file névbe fogja átkódolni, mert a kicsi betű nem volt megengedett. Nem fogja átforgatni "README.TXT"-be. A win 7 még azt is ellenőrzi, hogy lehetséges kicsi betű konverzió után ne legyen ott azonos filenév, de azt sem azért, mert végig nagy betűsre konvertálta volna. Nem, ugyanúgy bepakolja a hosszú filenevet, és még a "(2)", "(3)" és többit is hozzáragasztja. A rövid filenév helyett pedig olyat fogsz találni, mint "1~" (kiterjesztés meg minden nélkül), és utána vfat szerint leírva a filenév.

Mielőtt bármilyen feltételezéssel élnél a kiválasztott filesystemedet illetően, csinálj pár file meg mappa nevet, másold rá az egészet egy sd kártyára (arról könnyebb lba szektor szintjén olvasni), és nézd meg a saját szemeddel, mi kerül a directory szektorokba.

... és a pontot nem is tároljuk (mint a IEEE float -nál az "örökké" 1 bitet).