ARM Blue Pill STM32F103 ChanFat StdperiphLib SD Treiber gesucht!

[Christian J. (Gast)]

Hallo,

es ist sehr speziell aber ich suche jemand, der exakt mal das realisiert 
hat und mir den Source Code der Datei mmc_stm32F1.c und .h schicken 
kann.

Und zwar geschrieben mit der veralteten StdPeripheral Library für den 
STM31F1xx, weil ich EmBitz 1.1 benutze als IDE, mich nur mit dieser 
auskenne und im reinen Hobby Bereich HAL nicht neu "lernen" möchte (weil 
alles ja auch so geht), CubeMX gilt das gleiche für. ChanFatFs hat zwar 
selbst Code dafür veröffentlicht aber dieser basiert auf 
Registeraufrufen einer stm31F1xx.h und ist mit EmBitz nicht 
kompilierbar, weil das eben eine IDE ist, die eine eigene Umgebung 
mitbringt. Vermutlich hat er das als normales GCC Projekt geschrieben 
mit make File, Linker File usw. ohne eine IDE sondern rein Konsole.

In Kürze:
ChanFatFs Treiber für SD Karten
Datei mmc_stm32F1.c
kompiliert unter EmBitz IDE 1.1. durch
benutz die StdPeripheral Librarys als Unterbau

Ich möchte nur eine SD Karte dran pappen und wissen dass es läuft :-)

Christian

Diese Routinen von ihm sind IMHO falsch, sie berücksichtigen nicht die 
Abfrage von wesentlichen Flags der SPI. Das läuft nur durch, solange die 
CPU "langsamer" ist als die SPI, z.b. bei O0 Optimierung, mit O3 klappt 
es dann oft nicht mehr. Daran habe ich mich mal totgesucht früher. Vor 
dem Eintritt in eine SPI Routine muss der Status abgefragt werden, oder 
nachher. Jedenfalls so nicht.

/* Receive multiple byte */
static
void rcvr_spi_multi (
  BYTE *buff,    /* Pointer to data buffer */
  UINT btr    /* Number of bytes to receive (even number) */
)
{
  WORD d;


  SPIx_CR1 &= ~_BV(6);
  SPIx_CR1 |= (_BV(6) | _BV(11));  /* Set SPI to 16-bit mode */

  SPIx_DR = 0xFFFF;
  btr -= 2;
  do {          /* Receive the data block into buffer */
    while (SPIx_SR & _BV(7)) ;
    d = SPIx_DR;
    SPIx_DR = 0xFFFF;
    buff[1] = d; buff[0] = d >> 8; 
    buff += 2;
  } while (btr -= 2);
  while (SPIx_SR & _BV(7)) ;
  d = SPIx_DR;
  buff[1] = d; buff[0] = d >> 8;

  SPIx_CR1 &= ~(_BV(6) | _BV(11));  /* Set SPI to 8-bit mode */
  SPIx_CR1 |= _BV(6);
}


#if _USE_WRITE
/* Send multiple byte */
static
void xmit_spi_multi (
  const BYTE *buff,  /* Pointer to the data */
  UINT btx      /* Number of bytes to send (even number) */
)
{
  WORD d;


  SPIx_CR1 &= ~_BV(6);
  SPIx_CR1 |= (_BV(6) | _BV(11));    /* Set SPI to 16-bit mode */

  d = buff[0] << 8 | buff[1];
  SPIx_DR = d;
  buff += 2;
  btx -= 2;
  do {          /* Receive the data block into buffer */
    d = buff[0] << 8 | buff[1];
    while (SPIx_SR & _BV(7)) ;
    SPIx_DR;
    SPIx_DR = d;
    buff += 2;
  } while (btx -= 2);
  while (SPIx_SR & _BV(7)) ;
  SPIx_DR;

  SPIx_CR1 &= ~(_BV(6) | _BV(11));  /* Set SPI to 8-bit mode */
  SPIx_CR1 |= _BV(6);
}
#endif

[jo mei (Gast)]

Christian J. schrieb:
> Diese Routinen von ihm sind IMHO falsch, sie berücksichtigen nicht die
> Abfrage von wesentlichen Flags der SPI.

Da magst du sehr Recht haben.

Wenn man gugelt findet man schon 2017 Einträge von dir, richtig?

Christian J. schrieb:
> Vor dem Eintritt in eine SPI Routine muss der Status abgefragt
> werden, oder nachher.

Sehr richtig. Daher mach ich das wie im Anhang dargestellt, das
sollte funktionieren. Tatsächlich muss "man" mehr warten als
man vermuten sollte, auch wenn es unplausibel erscheint. Man
muss auch immer das SPI-Datenregister lesen, auch wenn man
SPI schreiben möchte, sonst kommt die Maschine ausser tritt.

Daher nur eine universelle Byte-Routine für Lesen und Schreiben.
Paar kleine Anpassungen für deinen Zweck wirst du machen müssen,
aber das wirst du schon schaffen. 16-Bit Transfers sind hier
nicht nötig und machen die Sacher nur komplizierter aber nicht
spürbar schneller.

[Christian J. (Gast)]

Hi,

ja gut, aufgepasst, 2017 habe ich das Thema schonmal bearbeitet aber die 
Sache im Zuge eines Umzuges ausser Sicht verloren. Jezt erst greife ich 
sie wieder auf und versuche wieder ins Thema zu kommen. Da war damals 
mal was...es klappte nicht.

Und damit hatte es zu tun, weil die CPU nicht einfach in eine laufende 
Prime Cell eingreifen kann, wenn die sich in einem Zustand befindet, der 
völlig  unbekannt ist. Nur mit den Flags gab es Debatten, diese ominöse 
BSY Flag, RXE war da noch und TXE.

  while ((SPI1->SR & SPI_I2S_FLAG_TXE ) == 0)   { /*  wait  */  };
  while ((SPI1->SR & SPI_I2S_FLAG_BSY)  != 0)   { /*  wait  */  };

Danke erstmal für den Code, schaue ich mir an.

Bei mir sieht es etwas komplexer aus, möglicherweise auch auch nicht 
richtig eben. Und die xmit ist auch anders.

/* Exchange a byte */
static uint8_t xchg_spi (uint8_t dat)  /* Data to send */
{
    while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) == RESET);   /* Wait for SPIz Tx buffer empty */
    SPI_I2S_SendData(SPI1,dat);                                       /* Send SPI1 data */
    while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE) == RESET);   /* Wait for SPI1 data reception */
    return SPI_I2S_ReceiveData(SPI1);                                  /* Read SPI1 received data */
}

#if _USE_WRITE
/* Send multiple byte */
static void xmit_spi_multi ( const uint8_t *buff,  /* Pointer to the data */
                             uint32_t btx)      /* Number of bytes to send (even number) */
{
  uint16_t d;

    SPI_16Bit();

   d = buff[0] << 8 | buff[1];
    /* Erstes Word senden */
    while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) == RESET);
    SPI1->DR = d;

  buff += 2;
  btx -= 2;

  do { /* Receive the data block into buffer */
    d = buff[0] << 8 | buff[1];

    /* Receive Words auslesen aber verwerfen */
    while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE) == RESET); /* Wait for SPI1 data reception */
    SPI1->DR;

        /* Word senden */
        while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) == RESET);
    SPI1->DR = d;

    buff += 2;
  } while (btx -= 2);

    while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_RXNE) == RESET); /* Wait for SPI1 data reception */
    SPI1->DR;

    while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_BSY) == SET);

    SPI_8Bit();
}
#endif

[jo mei (Gast)]

Das SPI_I2S_FLAG_BSY Flag dominiert, daher ist es beim Lesen
der Datenregisters unnötig und "fehlerschwanger" nur das
SPI_I2S_FLAG_RXNE Flag auszuwerten. Bei "not busy" ist dagegen
garantiert dass das gelesene Byte bereits zur Verfügung steht
und die Maschine für weitere Operationen bereit ist.

[Christian J. (Gast)]

Ok.... ich habe es mal "umgeschrieben" für die API, auch wenn der 
Compiler da den gleichen Senf draus macht, ich kann es leichter lesen

/* Exchange a 16 Bit Value */
inline __attribute__((__always_inline__))  uint8_t xchg_spi (uint16_t dat)  /* Data to send */
{
    SPI_I2S_SendData(SPI1,dat);                                       /* Send SPI1 data */
    while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) == RESET);   /* Wait for SPI1 data reception */
    while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_BSY) == RESET);   /* Wait for SPIz Tx buffer empty */
    return SPI_I2S_ReceiveData(SPI1);                                  /* Read SPI1 received data */
}

Und Du hast das getestet? das läuft so? Denn es vergeudet ja eigentlich 
Zeit, wenn die CPU wartet, bis etwas raus ist und dann erst weitermacht. 
Es wäre besser das alles nur beim Eintritt zu prüfen. Aber der Return 
Wert steht ja erst zur Verfügung, wenn der State durchgelaufen ist... 
also doch warten.... glaube man kann nur beim Senden zeit sparen, wenn 
man den Empfang nicht auswertet.

habe noch keine Hardware, alles nur Code ohne Prüfung am Objekt....

[jo mei (Gast)]

Christian J. schrieb:
> Denn es vergeudet ja eigentlich
> Zeit, wenn die CPU wartet, bis etwas raus ist und dann erst weitermacht.

Ich habe lang genug damit gespielt und kann mich nur wiederholen.

jo mei schrieb:
> Tatsächlich muss "man" mehr warten als
> man vermuten sollte, auch wenn es unplausibel erscheint. Man
> muss auch immer das SPI-Datenregister lesen, auch wenn man
> SPI schreiben möchte, sonst kommt die Maschine ausser tritt.

Und ich habe oft genug die SPI Maschine ausser Tritt gebracht
ohne es zu verstehen.

[Christian J. (Gast)]

Weil das ist ja schon falsch, du verwendest numbytes im while aber 
decremenierst es nicht.

static  void xmit_spi_multi
(
  uint8_t *buff,      /* Pointer to data buffer */
  uint16_t numbytes   /* Number of bytes to receive (even number) */
)
{
  uint16_t ii;

  SD_CS_LOW;
  ii = 0;
  do          /* send data block into buffer */
  {
    spi_xfer(*(buff+ii));
    ii++;
  } while (numbytes > 0);
  SD_CS_HIGH;

} /* --- xmit_spi_multi --- */

[jo mei (Gast)]

Christian J. schrieb:
> auch wenn der Compiler da den gleichen Senf draus macht

Wenn du die SPL Calls verwendest kannst du tatsächlich Pech
haben und das Zeug läuft langsamer ..... wenn der Compiler
nicht optimiert oder wenn er es nicht rafft bei Optimierung
da ausreichend Inline-Code draus zu machen.

[jo mei (Gast)]

Ja ok, dekrementieren vergessen.

[Christian J. (Gast)]

jo mei schrieb:
> Ja ok, dekrementieren vergessen.

Also ist der Code nicht aus einer laufenden Anwendung heraus genommen? 
Sorry,wenn ich bohre aber meist findet sich dann leider noch mehr (ich 
war früher beim TÜV, angeboren :-)

Außerdem würde die Routine wohl einmal zu wenig durchlaufen, die holt 
nur numbytes-1 Daten rein aber das habe ich jetzt nicht geprüft.

Die SPL Calls werden aufgelöst, das sieht man im ASM beim Debuggen. Man 
darf aber nicht size opt einstellen, sondern maximale Geschwindigkeit. 
Sonst nimmer er sie rein.

[Christian J. (Gast)]

Das ist die aktuelle Chan Routine

do {/* Receive the data block into buffer */
    d = buff[0] << 8 | buff[1];
    while (SPIx_SR & _BV(7)) ;
    SPIx_DR;
    SPIx_DR = d;
    buff += 2;
} while (btx -= 2);
while (SPIx_SR & _BV(7)) ;
SPIx_DR;

Nachgucken:

#define SPI_I2S_FLAG_RXNE               ((uint16_t)0x0001)
#define SPI_I2S_FLAG_TXE                ((uint16_t)0x0002)
#define I2S_FLAG_CHSIDE                 ((uint16_t)0x0004)
#define I2S_FLAG_UDR                    ((uint16_t)0x0008)
#define SPI_FLAG_CRCERR                 ((uint16_t)0x0010)
#define SPI_FLAG_MODF                   ((uint16_t)0x0020)
#define SPI_I2S_FLAG_OVR                ((uint16_t)0x0040)
#define SPI_I2S_FLAG_BSY                ((uint16_t)0x0080)

Nr.7 ist das BSY Flag, das benutzt er als einziges und zum Abschluss 
nochmal.

Was ist mit SPI_DR; Das wird doch weg optimiert, wenn es nicht volatile 
ist.

Doof, dass an dem bisschen das Funktionieren des gesamten Code hängt, 
weil das ganz unten läuft... stimmt das nicht klappt gar nichts. Da 
kommt es auf jedes Bit und jede Mikrosekunde an.