STM32 mit AVR/FAT32 Bibliothek

[Nils H. (nilsho)]

Hallo,

Ich möchte mit meinem STM32f103 gerne auf eine Micro SD Karte schreiben, 
die in Fat32 formatiert wurde. Dabei habe ich mich nun für die AVR Fat32 
Bibliothek entschieden (siehe Anhang oder Link).

https://www.mikrocontroller.net/articles/AVR_FAT32

Allerdings benutze ich nicht die main.c aus dem Ordner der Bibliothek, 
sondern das Beispielprogramm, dass auf der Website etwas weiter unten 
steht. (natürlich auch im Anhang befindlich)

Dafür habe ich zunächst in der "mmc_config.h" anstelle der avr/io.h, die 
stm32f1xx.h eingebunden, wie es ja auch direkt angeboten wird, falls man 
mit dem STM32 arbeiten möchte. Außerdem habe ich in der mmc.c/h den 
Hardware abhängigen Teil an meinen STM32 angepasst, genauso wie in der 
uart.c/h.

Es kompiliert auch alles Problemlos und die UART Schnittstelle läuft 
fehlerfrei. Leider hängt er sich immer auf, beim  Versuch die SD-Karte 
zu initialsieren und kommt nicht mehr weiter.

Habe ich irgendwas bei der SPI Schnittstelle vergessen oder falsch 
initialisiert? Oder muss ich generell noch mehr verändern, damit die 
Bibliothek funktioniert?

Hier mal noch mein Hardwareabhängiger Teil zur SPI Schnittstelle aus der 
mmc.c:

// beginn -> hardware abhaengiger teil !
#define MMC_CS_LOW     GPIOA->ODR &= ~(1<<4)    // Setzt SS auf 0
#define MMC_CS_HIGH    GPIOA->ODR |= (1<<4)    // Setzt SS auf 1

static void       spi_init(void);
static void       spi_maxSpeed(void);
static void       spi_write_byte(uint8_t byte);
static uint8_t       spi_read_byte(void);

// *****************************************************************************
static void spi_init(void){
  GPIOA->CRL = 0xB8B44444;  //MOSI(PA7) und SCK(PA5) auf alt. func. out, MISO(PA6) auf input
  SPI1->CR1 = 0x0374;      //SSI und SSM, SPE, BR = /128, Master Mode
  GPIOA->ODR |= (1<<4);       // Chip Select auf High -> Slave nicht angewählt
}


#if (MMC_MAX_SPEED==TRUE)
// *****************************************************************************
static void spi_maxSpeed(){
  SPI1->CR1 &= ~((1 << 3) | (1 << 4) | (1 << 5));  //Löscht alle Bits, die die Baudrate teilen -> /2
}
#endif
// *****************************************************************************
static void spi_write_byte(uint8_t byte){
    SPI1->DR = byte;          //Schreibt Byte in Datenregister
    while((SPI1->SR & (1 << 1))==0){}  //Wartet bis TxE gesetzt wird und dadurch alle Daten übertragen wurden
}
// *****************************************************************************
static uint8_t spi_read_byte(void){
    SPI1->DR = 0xFF;          //Sendet nur Einsen
    while((SPI1->SR & (1 << 0))==0){}  //Wartet bis RxNE gesetzt wird, also Daten empfangen wurden
    return (SPI1->DR);          //Gibt die Daten zurück
}
// ende <- hardware abhaengiger teil !

[Pieter (Gast)]

moin,

>>Löscht alle Bits, die die Baudrate teilen -> /2
Bis die SD-Card erkannt wurde, muss die Baudrate < 400kHz sein.
Ist das bedacht?

VG
Peter

[Robert Goldner (Gast)]

Servus,

ohne jetzt tiefer einsteigen zu wollen, aber warum verwendest Du die 
AVR-Implementierung für die SD-Card bzw. FAT32 für den STM32?
Wenn man mal Tante Google nach STM32 SDCARD FAT32 frägt, dann kommt 
ziemlich viel.
Aus dem Bauch heraus fände ich das einen besseren Start.

Viel Erfolg trotzdem

Robert

[Stefan F. (Gast)]

Pieter schrieb:
> Bis die SD-Card erkannt wurde, muss die Baudrate < 400kHz sein.
> Ist das bedacht?

spi_init() muss erstmal langsam starten. spi_maxSpeed() wird aufgerufen, 
nachdem die Karte initialisiert wurde.

[Nils H. (nilsho)]

Ich kann verstehen, dass das sehr komisch wirkt, aber der Hintergrund 
ist der, dass die gleiche Bibliothek auch auf dem Atmega 2560 laufen 
soll. Ich brauchte also eine Bibliothekt die sowohl auf dem STM32, als 
auch auf dem Atmega2560 läuft.

[dummschwaetzer (Gast)]

el chams fatfs geht doch auf beiden

[Jens G. (jensg)]

Vielleicht ist das ein guter Start.
http://elm-chan.org/fsw/ff/00index_e.html

[Nils H. (nilsho)]

Hat denn jemand schon mal mit dem STM32 und FatFS richtig gearbeitet? 
Ich finde leider kein funktionsfähiges Beispiel für meinen STM32f103

[Mike R. (thesealion)]

@Nils: wie wäre es einfach mit http://elm-chan.org/fsw/ff/ffsample.zip
das STM32F100 Beispiel sollte sich einfach auf den 103er portieren 
lassen.

[Stefan F. (Gast)]

Nils H. schrieb:
> Auf dem ATmega2560
> läuft das ganze auch ohne Probleme, aber auf dem STM32 läuft leider nur
> das initialisieren der Karte, aber am Ende erscheint weder Datei, noch
> Text. Ich vermute stark, dass "ffopen" fehlschlägt und es dadurch zu
> Problemen kommt.

Du solltest mal den Debugger benutzen, anstatt zu vermuten. Der Debugger 
zeigt dir, wo das Programm hängt (wenn du auf Pause drückst) und dann 
kannst du den Inhalt sämtlicher Variablen und Register kontrollieren.

[Guido L. (guidol1970)]

Falls es mit der von Dir ausgesuchten Bibliothek nicht klappt schau Dir 
evtl.
mal die SDFat von https://github.com/greiman/SdFat
an.

Gibt es auch als Fork von AdFruit:
https://github.com/adafruit/SdFat

Zitat der Webseite:
======================================================================== 
======
SdFat Version 2 supports FAT16/FAT32 and exFAT SD cards. It is mostly 
backward compatible with SdFat Version 1 for FAT16/FAT32 cards.

exFAT supports files larger than 4GB so files sizes and positions are 
type uint64_t for classes that support exFAT.

exFAT has many features not available in FAT16/FAT32. exFAT has 
excellent support for contiguous files on flash devices and supports 
preallocation.
======================================================================== 
======

Die wird bis jetzt erfolgreich im CP/M-Emulator RunCPM
( https://github.com/MockbaTheBorg/RunCPM )
genutzt mit STM32 und Arduino (Due).

[HALunke (Gast)]

>http://elm-chan.org/fsw/ff/00index_e.html
Also bei STM32CubeMX ist doch genau diese FAT Library dabei.

/*---------------------------------------------------------------------- 
------/
/  FatFs - Generic FAT file system module  R0.12c 
/
/----------------------------------------------------------------------- 
------/
/
/ Copyright (C) 2017, ChaN, all right reserved.



Häkchen setzten und es geht.
Warum das Rad neu erfinden, wenn es doch die HAL gibt :)

[Jörg W. (dl8dtl) (Moderator)]

Nils H. schrieb:
> Hat denn jemand schon mal mit dem STM32 und FatFS richtig gearbeitet?

Nicht STM32, aber SAM4E und SAME70. Auf beiden mit Elm Chan FatFS, die 
in diesem Falle allerdingns von Atmel bereits mit einer 
Hardwareanpassung auf deren MMC versehen worden sind. Das wird 
kommerziell genutzt, auch mit größeren Datenmengen (Logging).

Soll heißen: Chans FatFS an sich bereitet dir keine Probleme, du musst 
also nur den "glue layer" zur Hardware in den Griff bekommen.

Kann mir aber nicht vorstellen, dass es dafür nichts im Netz geben 
sollte.

[K. H. (hegy)]

Nils H. schrieb:
> Hat denn jemand schon mal mit dem STM32 und FatFS richtig gearbeitet?
> Ich finde leider kein funktionsfähiges Beispiel für meinen STM32f103

Mit STM32 und Elm Chans FatFS habe ich mich auch lange mit rumgeschlagen 
aber jetzt auf einem STM32F030 lauffähig und benutze den Treiber zum 
loggen, was ich schon über 10 Tage gemacht habe und es hat einwandfrei 
funktioniert, das Text Log-File war am Ende 72 MB groß.

Allerdings ist das jetzt ein paar Monate her und ich müsste daher 
nochmal tiefer in den Code von mir eintauchen. Ich hatte anfangs z. B. 
das Problem, wie ich das Hardware-Interface (SPI) an den Treiber bekomme 
und dass die SD-Karte erkannt wird und ein paar kleinere 
Verständnisproblemchen. Es gibt da auch nicht wirklich Anleitungen dazu, 
wie ich finde. Deswegen mal meine Frage: Was ist jetzt Stand der Dinge? 
Deine Frage ist ja auch schon 8 Tage alt, vllt. hast du das Problem ja 
schon gelöst.

[Ingo S. (ingo-s)]

Elm Chans FatFS funktioniert einwandfrei. Ein Beispiel für den STM32F100 
ist auf seiner Seite:
http://elm-chan.org/fsw/ff/00index_e.html
in dem FatFs sample enthalten. Es enthält auch eine Terminal 
Schnittstelle zum "Spielen" mit den Befehlen.

Ich habe es seit über 2 Jahren auf einem STM32F051 (mit der STL) für 
eine Sprachausgabe eines Fernsteuer-Senders per DMA->DAC in Betrieb.

Vor einem Jahr habe ich auf die LL Driver mit einer zusätzlichen 
Portierung auf den STM32L4xx umgestellt und gleichzeitiges Logging in 
Verbindung mit dem CoOS RTOS implementiert. Es funktioniert also auch 
das gleichzeitige Öffnen von zwei Files, eines zum Lesen und eines für 
das Logging.
Dank dem schlanken CoOS passte alles noch in die 8K RAM des F051.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Nils H. schrieb:
> Hat denn jemand schon mal mit dem STM32 und FatFS richtig gearbeitet?

Sischer dat. Der SD Card Support ist in meinem Projekt zwar im Moment 
ausgeschaltet, aber im Host Modus schreibt der F429 mit FatFS auf USB 
Sticks.
Ich habe dazu allerdings eine Lib von Uwe B. benutzt:
https://mikrocontroller.bplaced.net/wordpress/?page_id=519
da mir der SPL Aufbau sehr entgegenkam.