Maga ez a FatFs amit használnék, ha szépen végig debugolom és javítom a hibákat, akkor beírja a 0x20-at, erre volt hivatott a kép, hogy ezt bemutassa.
Az az SD és FAT kezelő rutin is megteszi ezt, amit én írtam meg saját magamnak PIC-re, ezért is kerestem. Még nem láttam az általad 0x00 értékű fájlt, hiszen pont ezt a bit-et kell vizsgálni, mert ha pl. könyvtár, akkor abba be kell lépni, ha file akkor meg kell nyitni, ... és így tovább.
Ettől független értem amit írsz..

Nem hiszem, hogy ertenéd.

Akkor áruld el nekem, mi alapján döntőd el, hogy a bejegyzés könyvtár e vagy esetleg más?
Hát persze, hogy erről a bitről.
Szóval értem, max te nem érted, azt, hogy én értem..
ui: de mindegy is, mert dobtam ezt a változatot, keresek egy másikat, ami hajlandó írni is nem csak olvasni.

Az attributum byte 8 bitje a kovetkezo:

0x01 - read only file (csak olvashato)
0x02 - hidden file (a DOS DIR parancs nem mutatja a file-t vagy dir-t)
0x04 - system file
0x08 - DISK VOLUME LABEL
0x10 - DIRECTORY
0x20 - Archive file (semmi ertelme normalis hasznalat kozben)
0x40 - device file, disken soha nem fordul elo
0x80 - nem hasznalt

Ezek alapjan az attributum byte a kovetkezot jelenti:

Ha az ertek == 0x0f, akkor ez egy LFN bejegyzes
Ha nem 0x0f, akkor, ha 0x10 bit all benne, akkor ez egy konyvtar, ha a 0x08 bit all benne, akkor ez egy Volume Label, minden mas esetben sima file.

Akkor már csak a egy működő kód kellene..
Kiakaszt ez a FatFs, tetszik az STM, de PIC-el minden olyan egyszerűnek néz ki.. (most)

Egy FAT fs megirasa PIC-re vagy ARM-re hajszal pontosan ugyanaz a munka. Csak erteni kell, hogy hogyan mukodik. A Wikipedian eleg reszletesen le van irva, en az alapjan csinaltam meg. Persze nem art némi programozoi ismeret, esetleg mas FS-ek irasaban szerzett tapasztalat.

Az STM-et nem ismerem, nem lennék képes megírni alapról.
STM ismeretem csak nagyon felületes, 1-2 hete kezdtem el vele foglalkozni.

Egy FAT fs megirásához kizárólag általános programozói ismeretekre van szükség és a FAT FS dokumentációra. Simán C-ben megírható, mindenféle processzor- vagy mikrokontroller ismeret nélkül.

A FatFS könyvtár maga platformfüggetlen. Neked a platformfüggő részt kell implementálnod. Ennek a munkának a nagy részét szerencsére már elvégezte az ST helyetted, gyakorlatilag csak az interface-t kell leprogramoznod a FatFS és a kész SDIO könyvtár között. Ez nekem anno STM32F103 esetén kemény 180 sor volt.

Áhh, kizárt, hogy meg tudjam még írni a drivert hozzá.
Mert a FatFs, letölthető, de ettől az még nem működik.
Az összes végrutint nekem kellene megírnom hozzá, ehhez meg még puding vagyok.
Ezzel a HAL-al sem boldogulok, pedig itt csak elvileg össze kell válogatni, SD most megy, de az SRAM-ot már nem tudom hozzá párosítani. Egyszerűen nem is értem mi a fenéért nem működik, tutkó benézek valamit.

Amúgy látok ilyen SDIO példákat, úgy nevezett uSD, ez kell a FatFs meghajtásához?

Gyakorlatilag a diskio.h fájlban deklarált pár függvényt kell implementálni.

Ezt nézted? http://stm32f4-discovery.net/2014/07/library-21-read-sd-card-fatfs-...vices/


SRAM-ot szintén csak STM32F103-assal használtam, valóban könnyű benézni vmit. Minden paraméter számít és elég sok van belőlük.

Jaja, próbáltam ezt a TM féle kódot is.. Sajna nem működik.
STM32F103 lesz a következő, valszeg a végleges hardver is az lesz.
SD-t arra még nem próbáltam, de az SRAM szépen megy rajta..
Lehet le kell mondanom az SD írásról, tesztelésre kellett volna, de megoldom másként.

Arra figyelj, hogy az STM32F103 kissé korlátozottabb, mint az újabb sorozatok. Például ha használod az FSMC buszt, akkor nem használhatod az AF funkciókat azokon a lábakon amelyek ugyan nem kellenek neked épp az aktuális FSMC megoldáshoz (pl. extra címbitekhez tartozó lábak, stb.) más perifériához (nem létezik itt az az AF választó regiszter, amivel kiválasztható melyik perifériát akarod elérni AF módban az adott lábnál).

A mellékletben egy kis infó a CUBE/HAL-os FAT/SD rétegeiről.

Kezdjük azzal, hogy mi az az AF választó?
FatFs kell a fájlok listázásához, SRAM kezelés, esetleg NorFlash, de ez egyben van az SRAM címbitekkel, csak más a chipselect, majd később még USB, pár gomb, LED és kb. ennyi.
Úgy gondolom talán erre elég lesz az F103-is, legalább is a 144 lábú.

Alternative function. A legtöbb lábhoz tartozhat többféle periféria és pl. az F4-es sorozatnál egy regiszterrel lehet megmondani melyik perifériát akarom az adott lábon használni.

Ha többféle perifériát is akarsz kezelni FSMC buszon akkor erősen javasolt a min. 144 lábú verzió használata. Az SRAM kezeléshez pedig kifejezetten javallott, hogy ne kelljen külső logikai IC-t használni a címbitek kiterjesztéséhez (ugye 100 láb estén nincs elég), ami ráadásul még lassítja is a működést.

Itt puskázhatsz bekötési lehetőségre (nézd át a moduljaikét is):
https://www.waveshare.com/wiki/Open103Z

Igen, ezen a részen sokat molyoltam. 144 lábú jöhet csak szóba, most is olyanokat használok, mind 407 mind 103 esetében. Kell a közvetlen címzéshez.

Köszi a kiegészítést, ezt nem tudtam eddig.

Nézegettem ezt a sebesség dolgot. (sdcard.c)

Azt vettem észre, hogy ha kézzel a kritikusabb függvényekbe (debug módban) belépek és végig lépkedek, akkor megtörténik a file beírása.
Az adatokat átnézve aztán kikalkuláltam az elvileg megfelelő beállításokat, de nem tudom, hogy jól e értelmezem.
168MHz-en ketyeg az STM32F407, jók szerinted a beállítások?
A program továbbra is, ha nem léptetem végig, akkor nem tud beírni.

Ne feledd az írási sebességet jelentősen befolyásolja az SD kártyád. 4 bit szélességű módban 24MHz-en 12Mbyte-ot tolsz rá másodpercenként. Ez még egy Class10-es memóriakártyának is bőven sok. Szerintem vedd vissza jelentősen a sebességet és nézd meg akkor is rossz-e az írás.

Már kimaszkoltam mind a kettőt.
Mind a két értéket feltettem 0xFF-re, de ugyan ez a helyzet.
Ha kézzel végig kísérem, akkor beírja az adatot és lezárja a fájlt, de magától kiakad, illetve hibával tér vissza. Hol van még mód a sebesség csökkentésre?
Feltettem az sdcard.c fájlt.
Ott látod, hogy most miképpen fut.
Jó lehet minden beállítás?

Szerintem ne az SDIO_INIT_CLK_DIV-et növeld, mert az csak addig számít, amíg a kontroller megszólítja az SD kártyát (jellemzően 400 kHz az ajánlott sebesség), majd ha már tudja milyen a kártya típusa, akkor kapcsol nagyobb sebességre, amit az SDIO_TRANSFER_CLK_DIV határoz meg. Próbálj ide a 0x06-nál nagyobb értéked megadni, hátha ez segít.

Kipróbáltam 0xff-ig növelni.
Nincs változás.

Ez igy ezzel az ertekkel szamolva 658.823 kHz, nem 400. Amugy a kommentek nem jo sorrendben vannak. Az ossz ertek nem tud nagyobb lenni mint 255 az uint8 miatt. Tehat ezt az erteket novelni mar nem tudod. Ha tovabb akarod osztani, akkor az ezt meghajto orajelet kell elobb elosztani. APB1,2 CLK?

Ez a számítás valóban hibás. Az SDIO_CLK a PLL48CLK-on alapszik. A PLL Q osztója alapján max 48MHz-en futhat. Tehát a 400kHz-hez tartozó osztó 118 ha a max frekvencián fut.

Igen, elfelejtettem a komplimentbe átírni, az eredmény valóban 658KHz lesz, ezt tudtam, és próbáltam előosztani is, de változást nem tapasztaltam.
Ha van valakinek ilyen 32F407-es STM MCU-ja, az esetleg kipróbálhatná a kódot.
Csatolom, sajna mivel én IAR-t használok, így az implementálással kicsit foglalkozni kell.
teszt.zip csatolva, ez működik olvasásra és debug módban végig lépkedve (a kritikus függvényekben) működik írásra is.
168MHz-en vagy is maxon jár az MCU.
SPL szükséges hozzá, hátha valaki gyakorolna..

Ne már! Te tényleg ennyire naiv vagy?

Ha azt akarod, hogy kipróbáljuk?
Akkor rakd fel az Atollic-ot és implementáld nekünk, hiszen a te érdeked, neked kellene gyakorolnod.

Nem értelek, miért lennék az.
Számtalan esetben írtam meg már másnak a kért programot, teljesen evidens módon, hogy tanuljon belőle. Nem vertem a fejem a falba és nem kértem hozzá még kódost sem. Ennyire egyszerű, egyéne válogatja, hogy ki mennyit szeretne, képes, vagy tud segíteni a másikon.
Ha neked ez nem megy, megértem és nem várja el senki, de azt se, hogy feleslegesen oltásokat írjál be.
Vannak kivételek, és bár továbbra sem várom el senkitől, hátha még is valaki szeretne és tud is segíteni. Ennyi, nem több.. Szép idegeskedés mentes napot kívánok neked.

Már nem tudom, hányadszóra kéred ezt a tesztet, hiába?

Különben akarat lenne, csak időm nincsen!

Én is már szenvedek ezen a boardon 1 hete.
USART6 Tx to DMA2 átvitel projectel. Egyszer lefut az átvitel, de utána váltott szöveg pufferel többet nem. (Jól jönne, ha valaki megcsinálná helyettem! )
Sajnos nekem így túl a 70-en már nem megy egyszerre több projectre figyelni!

Szóval felajánlottam a segítséget, a fenti feltétellel.?

Egyelőre nem térnék át más környezetre.
Később még választhatom ezt az utat, de egyelőre maradok az IAR-nál.
Azért sem kapkodom, mert amire fel szeretném használni azt meg tudom így is oldani, hogy nem képes tisztességesen írni. (tehát csak olvasnia kell és az prímán működik)
Közben természetesen több projektet viszek, ez csak amolyan tanulás, belekezdtem, elakadtam és majd lassan szépen türelmesen átlépek ezen a hibán is.

Úgy gondolom olyan nagy baja nincs a programnak, sebességen kell majd alakítani, mert szerintem a 168MHz túl gyors neki.

Ok! Akkor részemről tovább tárgytalan a témád!