Igen, erre már meg lett a probléma! Az volt, hogy ha a file törölve van már, akkor 0xE5 az első karakter. Ez az n vessző ascii kódja. Erre csináltam is egy if-et, ha ilyennel kezdődik, akkor ne olvassa be a file-t, viszont mivel nem unsigned char, hanem sima char tömb a file neve, ezért hiába volt 0xE5 az első karakter. Átírtam -27-re, és így már jó lett! Egyébként ez még kérdés a fejembe, mert máshol is megviccelt már hogy a változó tartalma egyenlő volt a hex számmal, mégse vette egyenlőnek a program. Talán így kellene?(bár ez nem épp ide vágó kérdés):

Na azt hiszem megvan a gond! A hxd nem fizikai címmel számol. A valóságban a 0. blokban az MBR van elvileg. Jól félrevezetett a hxd :S

Nem vezet az félre.
A programban az eszközök/lemezmeghajtó megnyitása ablakban logikai és fizikai meghajtóként is tudod olvasni a kártyát.
A csatolt képen a "KARTYA" és a "Cserélhető meghajtó 1" az sd kártya.
Üdv, és sok sikert a kártya kezeléséhez.

Basszus tényleg! De nekem ott nincs a meghajtó, csak a logikainál!
Közben sikerült az SD-vel is megtalálni a Boot sectort Az is félre vezetett, hogy c++-ban is logikai meghajtóként kezelte a program automatikusan!

Edit: Közben rájöttem, ha rendszergazdaként indítom el a hxd-t, akkor látszik az SD is fizikai meghajtóként!

Közben már rájöttem, hogy SDHC memória kártyám van, így az inicializálást átírtam ahoz. Jelenleg ott tartok, hogy a file listázás működik a gyökérkönyvtárban, csak nem tudom hogyan kellene a file neveket eltárolni. Egy nagy tömböt fogok szerintem deklarálni. De fileok olvasásánál is még bajban leszek, hogy hogyan tároljam majd a kiolvasott adatokat. GIF fileokat szeretnék majd olvasni, még ahoz is írni kell egy decodert
Ha kész leszek az SD-vel, szerintem írok róla egy cikket, hogy legyen magyarul is végre egy átfogó leírás róla.

Sziasztok!
Pár hónap után előszedtem újra a projektemet. File-ok root folderben kilistázása működik, valamint egy txt file-t is ki tudok olvasni. Az adatokat UART-on külöm el a számítógépre, így látom a kimenetet. Szóval ez szépen működik. Viszont csinálni akarok egy érzékelőt, hogy ha bedugom a kártyát akkor lefusson az inicializálás. Viszont amikor rádugom a kártyát a mikrokontroller olyan mintha reset-elné magát. Elindul előröl az egész program. Mi okozhatja? Kell valami ellenállás valahová az SD kártyához? Egy pickit3 debuger táplálja próbapanelen a cuccot. Nincs ellenállás a PIC és az SD között sem.

Nem biztos, de nem lehet, hogy amikor rádugod a kártyát, akkor hirtelen a kártya felvétele miatt leesik a feszültség és reseteli magát az MCU?

Én is erre gondoltam. Raktam egy 1000µF-os kondit, de nem lett jobb. Ma kipróbálom valami rendes táppal.

Esetleg a PIC beállításaiban állítsd ki az alacsony feszültségre történő resetet.

Üdv!
Használt már közületek valaki 4-bites SD-buszos kommunikációt SDHC kártya és mikrovezérlő között? Van egyáltalán értelme szoftveresen lekezelni ezt? (folyamatos, nyers olvasás - nagymennyiségű adathoz, pl.: zenelejátszás)

Üdv!
Szerintem nem sok értelme van ennek, mivel egy egyszerű mikrokontroller nem tudná kihasználni ezt az interfészt, ellenben SPI-n keresztül is gyorsan lehet kommunikálni az SD kártyával akár még zenelejátszás is szóba jöhet. Nekem SPI-n keresztül körülbelül 15Mbit/s sebességet sikerült elérnem egy mezei PIC18-as mikrokontrollerrel. Itt nem is az adattovábbítás sebessége volt a probléma, hanem az, hogy a mikrokontroller nem tudta elég gyorsan kezelni a bejövő adatot és ez lassította le az olvasást.

Egy SD kártyát kezelő C18-as forrást szívesen tanulmányoznék.
Régóta áhítozom rá, de eddig még nem sikerült eljutnom, hogy meg is tudjam írni és nem dobálóznak vele a neten
Esetleg, ha lenne egy PL programod SD kártya használatához ami írni és olvasni is tudna SD kártyára illetve SD kártyán létrehozott fájlba azt nagyon megköszönném.

Azt megkérdezhetem hogy hogyan érted el ezt a sebességet? A legtöbb mikrovezérlő SPI frekvenciája max. 10MHz.
(Egyébként a feldolgozással nincs is gond, ha a beolvasott - tömörítetlen - adatokat egyszerűen csak bedobáljuk egy DAC-ba. Csak az számít, hogy adatok időben érkezzenek.)

Kicsit más; FAT32, könyvtárbejegyzés:
Mire jó a "." bejegyzés? Mert a ".."-nak még van értelme; ha nem tudjuk honnan jutottunk el a jelenlegi helyre, visszalépkedve eljuthatunk a gyökérig. De a "."? Gyakorlatilag arra a clusterre hivatkozunk benne, amit épp olvasunk.
Másrészt: emlékeim szerint DOS alatt a "." az egy szinttel való visszalépést (szülő könyvtár), míg a ".." a gyökérkönyvtárba való visszalépést jelentette. (CD . és CD ..)

Én úgy emlékszem, a "." az aktuális könyvtárat jelentette és jelenti most is. (Az az értelme, hogy nem kell begépelni a 234 karakter hosszú aktuális könyvtárnevet.) A ".." a szülőkönyvtárat jelenti. A "..." nem terjedt el igazán, de tudtommal voltak olyan implementációk, ahol a gyökérkönyvtárat jelentette.

Úgy tűnik hogy rosszul emlékeztem. Viszont az 1 pontnak akkor sem látom értelmét, mert a teljes útvonalat egyébként sem kell megadni. Másrészt minek oda mutatni, ahol már úgyis vagyok. Na mindegy... Köszi!

Üdv. mindenkinek!
Nos kínozok egy 2Gb-os mikroSD kártyát. A boot szektor elvileg a 0. blokkban van, azonban ez a 0. blokk el van tolva a rejtett blokkok számával, ami viszont a boot szektorban van, róka fogta csuka.
A Hdx nevű nézegető progival meg is található a 0x1c-1d cimen.
Az SD kártya SPI üzemmódba induláskor 80 ciklus órajel hatására lép be, Nem kell semmiféle CRC kód, induláskor ki is van kapcsolva.Az én megoldásom szerint windows alatt formázva lesz, tehát nem kell az üres klasztereket keresni. Szabványos vesszővel elválasztott fájlt generál a PIC excel tábla részére (.csv kiterjesztéssel) minden nap 1 fájlt. A fájl fejlécében el kell tárolni az idő, dátumot, tehát valós óra is kell.
A blokk írás már tesztelve, pontosan a helyére teszi. C18 alatt készül a FAT16 kezelő még készül
addig is egy kis segítség:

Azt megjegyezném hogy az SD kártya 0. blokkjában a Master Boot Record van. Itt találhatók a partícióbejegyzések. A boot szektor a partíció 0-ás szektora. Ezután jön a "fenntartott" rész maradéka, majd az 1 vagy 2 FAT, legvégül pedig maga az adattároló rész clusterekre osztva.
Minden egyértelműen adódik; nincs róka fogta csuka.

elég érdekes lenne ...
A 2GB os SD-nél 8 blokk fenntartott és 135 rejtett blokk van akkor akkor a 8ból hogyis kell 135-öt kivonni? a 0. blokk Master Boot Record hol is foglal helyet?
Akár a FAT1 be akár a ROOTba, akár a memóriába írok,mindig hozzá kell adni a 135 blokkot.Az előző hozzászólásomban nem fenntartott blokkról beszéltem,hanem rejtettről.(valamilyen médialeíró lehet)és a 0x1c-1d címen van a mérete.

itt valami kérdést is akartál feltenni vagy csak szimplán közkincsé teszed a programjaid egyes részeit?
Milyen PIC-en teszteled?

ui: PIC megvan

ennyit találtam róla:
When the volume is on a media that is partitioned, this value contains the number of sectors preceeding the first sector of the volume.

18f24k50 lesz (van) FAT része is. Csak segítség,ha egyáltalán érdekel valakit.Én konkrétan adatokat gyűjtenék hónapokon át naponta új fájlt generálva.

Engem kimondottan érdekel az egész projekt.
Én éveken át szeretnék adatokat gyűjteni és ehhez akarok egy SD kártyás témát.
Memóriába meg tudnám oldani, de úgy az adatok kigyűjtésére megint csak egy eszközt kellene készítenem ami a memória lemásolását megoldaná.
Ha nem titkos érdekelne a teljes projekt amin dolgozol.

Milyen adatokat akarsz gyűjteni, szabad tudni?

Széladatok sebesség irány TX20 tipusú szélmérő.

- A MBR a média legelső (0-ás) blokkja. Itt adják meg a partíció(k) kezdetét (gyakorlatilag a rejtett blokkok száma ebből adódik) és a méretét. (A MBR az első rejtett terület része.)
- A rejtett terület után jön a fenntartott terület. Ebben van(nak) a Boot blokk(ok), ill. pár kisegítő blokk.
- Ezt követi(k) a FAT(ok)
- A FAT terület után következik az adattároló terület.
- Ezt követheti a következő partíció.

Neked van kész projekted?
Érdekelne a forrás, ha C-ben vagy még jobb esetben C18-ra van írva.
Csak az SD kártyával kapcsolatos dolgok, írás, olvasás, init...stb.
FAT16 szerintem elég is lenne, elég kicsi kártya is az adatoknak.

Nekem csakis félkész projekteim vannak.
Különben meg PIC24-re írtam, Assemblyben, SPI kapcsolattal és FAT32-vel. Én a FAT16-ot nem is javaslom senkinek, mert már nem is lehet sima SD kártyákat kapni. Az SDHC ill. SDXC kártyákhoz meg FAT32 ill. exFAT kell (hivatalosan).

Érdemes először egy konkrét SD kártyához megírni a programot (az egyszerűség miatt), aztán később lehet bővíteni, hogy több változattal és szabvánnyal is kompatibilis legyen. Ha nincs szükséged fájlrendszerre, az szintén leegyszerűsíti a dolgot, viszont a PC-n való írhatóság/olvashatóság esetenként előny lehet. Az összes lehetséges hiba lekezelése szintén csak bonyolítja a dolgot, tehát kezdetben érdemes elhagyni, amit lehet.

Egyébként meg nem fontos hogy kész programot láss adott mikrovezérlőn és nyelven. Egyedül az elv a lényeg, és hogy hogyan lehet azt megvalósítani az adott környezetben. Az inicializálás folyamatábráját megtalálod az SD fizikai specifikációjában. Az írás és olvasás idődiagrammját úgyszintén. Mikrovezérlőn érdemes az SPI-s kommunikációt választani.

Köszönöm, végiggörcsölni végig tudom én is, de minek, ha van aki elmagyarázza esetleg ad forrást? Fene fog heteket hónapokat rááldozni azért , hogy pár adatot el tudjak tárolni.
Nincs most energiám végignyálazni az egészet.
Az SD inicializálást már megírtam amúgy, az írás olvasás van vissza, de annyi mindennel foglalkozom, hogy ez most még biztos nem fog beférni..

Szóval, te arra vársz, hogy a sült galamb a szájadba repüljön...
Foxi63 nem mostanában tett fel példaprogramot?
(Nekem kb. 2 hét kellett, az SD 2.0 (phy) és a FAT32 specifikáció elolvasásához, ill. némi egyéb segédanyag tanulmányozásához.)

Akkor ez nem igaz? Bővebben: Link

Ez eléggé elrettentett a témától, de ha mégsem olyan vészes, akkor lehet belevágok (csak mindjárt vizsgaidőszak, és ááá..).