STM32: SPI - HAL durch eigenen code ersetzen

[Malte _. (malte)]

Hallo,
ich versuche gerade den HAL Code durch selbst geschriebenen zu ersetzen. 
Ziel ist hinterher DMA zu verwenden, was leider mit der HAL Lib nicht 
funktioniert.
Leider funktioniert aber das eigentlich recht einfache SPI ohne DMA 
schon nicht mit meinem eigenem Code. Und ich kann einfach keinen Fehler 
erkennen.
Die SPI Initialisierung ist in beiden Fällen gleich, und der unten 
auskommentierte HAL Code kommuniziert einwandfrei. Auch kann ich mir mit 
PerPrint die Register ausgeben lassen und auch diese sind gleich 
eingestellt.

Bei meinem eigenem Code mache ich folgende Beobachtung:
SPI_SR_TXE ist gesetzt, ich schicke also Daten hin. SPI_SR_RXNE hingegen 
wird nie gesetzt und "RX1\r\n" folglich nie ausgegeben. Auch ein am 
Ausgabepin angeschlossenes Oszi zeigt keine gesendeten Daten an.
Die Konfigurationsregister der SPI Schnittstelle initialisiere ich mit:

g_spi->CR1 = SPI_CR1_MSTR | SPI_CR1_SPE | SPI_BAUDRATEPRESCALER_64 | SPI_CR1_SSM | SPI_CR1_SSI;
g_spi->CR2 = SPI_CR2_DS_0 | SPI_CR2_DS_1 | SPI_CR2_DS_2| SPI_CR2_FRXTH; //8Bit, 8Bit RX threshold

Der Chip ist ein STM32L452.

SPI_TypeDef * g_spi = (SPI_TypeDef *)SPI2_BASE;

void PerPrint(void) {
  printf("CR1: %08x\r\n", (unsigned int)g_spi->CR1);
  printf("CR2: %08x\r\n", (unsigned int)g_spi->CR2);
  printf("SR : %08x\r\n", (unsigned int)g_spi->SR);
}

void PeripheralTransfer(const uint8_t * dataOut, uint8_t * dataIn, size_t len) {
#if 1
  printf("Data %u, %x %x\r\n", len, dataOut, dataIn);
  uint32_t timeStop = HAL_GetTick() + 100;
  uint32_t txLen = len;
  uint32_t rxLen = len;
  while ((HAL_GetTick() != timeStop) && ((txLen) || (rxLen))) {
    //PerPrint();
    if ((g_spi->SR & SPI_SR_TXE) && (txLen)) { //something to transmit
      //printf("Wr1\r\n");
      uint8_t data = 0;
      if (dataOut) {
        data = *dataOut;
        dataOut += sizeof(uint8_t);
      }
      *(__IO uint8_t *)g_spi->DR = data;
      txLen -= 1;
    }
    if (g_spi->SR & SPI_SR_RXNE) { //something to receive
      printf("RX1\r\n");
      uint8_t data = *(__IO uint8_t *)g_spi->DR;
      if ((dataIn) && (rxLen >= 1)) {
        *dataIn = data;
        dataIn += sizeof(uint8_t);
        rxLen -= 1;
      }
    }
  }
  //while (g_spi->SR & SPI_FLAG_BSY);
#else
  if ((dataIn) && (dataOut)) {
    HAL_SPI_TransmitReceive(&hspi2, (uint8_t*)dataOut, dataIn, len, 100);
  } else if (dataOut) {
    HAL_SPI_Transmit(&hspi2, (uint8_t*)dataOut, len, 100);
  } else if (dataIn) {
    HAL_SPI_Receive(&hspi2 ,dataIn, len, 100);
  }
#endif
}

PS: Keine Ahnung wo die ganzen Leerzeilen im Code herkommen. Im Beitrag 
Editieren Feld sind sie nicht da.

[Erwin (Gast)]

Warum sollte SPI mit DMA über die HAL nicht funktionieren?

[Kevin M. (arduinolover)]

Malte _. schrieb:
> Ziel ist hinterher DMA zu verwenden, was leider mit der HAL Lib nicht
> funktioniert.

Der funktioniert ziemlich sicher mit der HAL. Habe ich aktuell mit F2, 
F3, G4, F4, F7 und H7 in Benutzung.

Hast du alle benötigten Interrupts aktiviert?

[Malte _. (malte)]

Kevin M. schrieb:
> Der funktioniert ziemlich sicher mit der HAL. Habe ich aktuell mit F2,
> F3, G4, F4, F7 und H7 in Benutzung.

Mein Versuch endete in einer HAL Funktion, die einfach nicht zurück 
kehrte. Meine Initialisierung war wie folgt:

DMA_HandleTypeDef g_hdma_spi2_tx;
volatile bool g_lcdDmaDone;

void LcdDmaTransferComplete(SPI_HandleTypeDef *hspi) {
  printfNowait("D\r\n"); //safe from interrupt
  g_lcdDmaDone = true;
}

void LcdWaitDmaDone(void) {
  if (hspi2.State != HAL_SPI_STATE_READY) {
    while (!g_lcdDmaDone);
    g_lcdDmaDone = false;
  }
}

void LcdInit(void) {
  //Copied from the STM cube generator output:
  __HAL_RCC_DMA1_CLK_ENABLE();
  HAL_NVIC_SetPriority(DMA1_Channel5_IRQn, 0, 0);
  HAL_NVIC_EnableIRQ(DMA1_Channel5_IRQn);
  g_hdma_spi2_tx.Instance = DMA1_Channel5;
  g_hdma_spi2_tx.Init.Request = DMA_REQUEST_1;
  g_hdma_spi2_tx.Init.Direction = DMA_MEMORY_TO_PERIPH;
  g_hdma_spi2_tx.Init.PeriphInc = DMA_PINC_DISABLE;
  g_hdma_spi2_tx.Init.MemInc = DMA_MINC_ENABLE;
  g_hdma_spi2_tx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE;
  g_hdma_spi2_tx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE;
  g_hdma_spi2_tx.Init.Mode = DMA_NORMAL;
  g_hdma_spi2_tx.Init.Priority = DMA_PRIORITY_LOW;
  if (HAL_DMA_Init(&g_hdma_spi2_tx) != HAL_OK) {
    printf("Error, failed to init DMA\r\n");
  }
  __HAL_LINKDMA(&hspi2,hdmatx,g_hdma_spi2_tx);
  HAL_SPI_RegisterCallback(&hspi2, HAL_SPI_TX_COMPLETE_CB_ID, &LcdDmaTransferComplete);
}

void LcdTransfer(const uint8_t * dataOut, size_t len) {
  LcdCsOn();
  LcdWaitDmaDone();
  if (len <= 4) {
    HAL_SPI_Transmit(&hspi2, (uint8_t*)dataOut, len, 100);
  } else {
    printf("A\r\n");
    HAL_SPI_Transmit_DMA(&hspi2, (uint8_t*)dataOut, len);
    printf("B\r\n");
  }
  LcdCsOff(); //TODO: Should be done after DMA is done
}

Die Meldung "A\r\n" kommt, die "B\r\n" hingegen nicht.

[PittyJ (Gast)]

Bei meinem H7 hat SPI mit DMA über die HAL wunderbar funktioniert. 
Gerade letzten Monat erst implementiert. Keine Probleme gehabt.

[Harry L. (mysth)]

Du hast das Prinzip der Callbacks in HAL nict verstanden!

Nachlesen kannst du das u.A. hier:
https://www.st.com/resource/en/user_manual/um1786-description-of-stm32f3-hal-and-lowlayer-drivers-stmicroelectronics.pdf

Ab Seite 476 wird SPI erklärt.

Ein Beispiel von mir, wo SPI mit DMA genutzt wird, gibts hier:
Beitrag "[STM32/HAL] Treiber für ST7735 160 x 80 TFT"

[Malte _. (malte)]

Harry L. schrieb:
> Du hast das Prinzip der Callbacks in HAL nict verstanden!
Ok, ich hab jetzt DMA am laufen :)
Das Callback funktioniert wie von mir erwartet, was hingegen fehlte war

void DMA1_Channel5_IRQHandler(void)
{
  /* USER CODE BEGIN DMA1_Channel5_IRQn 0 */

  /* USER CODE END DMA1_Channel5_IRQn 0 */
  HAL_DMA_IRQHandler(&g_hdma_spi2_tx);
  /* USER CODE BEGIN DMA1_Channel5_IRQn 1 */

  /* USER CODE END DMA1_Channel5_IRQn 1 */
}

Den Code hatte ich beim Neugenerieren durch CubeMX übersehen, und so 
nicht ins eigene Projekt übernommen.

Es wäre zwecks Erkenntnisgewinn trotzdem schön zu wissen, was bei meinem 
eigenem SPI Code falsch ist.

[Harry L. (mysth)]

Malte _. schrieb:
> Den Code hatte ich beim Neugenerieren durch CubeMX übersehen, und so
> nicht ins eigene Projekt übernommen.

Verstehe ich nicht!
Der generierte Code wird doch autom. ins Projekt übernommen...

Nutzt du nicht die CubeIDE oder hast du bei den Einstellungen von CubeMX 
was zerrissen?
Wenn das alles korrekt wäre, würde da garantiert nichts fehlen nach dem 
Code generieren.

[Malte _. (malte)]

Harry L. schrieb:
> Verstehe ich nicht!
> Der generierte Code wird doch autom. ins Projekt übernommen...
>
> Nutzt du nicht die CubeIDE oder hast du bei den Einstellungen von CubeMX
> was zerrissen?
> Wenn das alles korrekt wäre, würde da garantiert nichts fehlen nach dem
> Code generieren.
Naja, aus meiner Sicht generiert CubeMX eher Samplecode. Man hat zwar in 
den Quelltexten Stellen um eigenen Code einzufügen, aber wie ich auch 
nur eine extra .c Datei oder zusätzliche Include Suchpfade im Cube 
hinzufüge habe ich nicht herausgefunden. Stattdessen wird das Makefile 
einfach immer überschrieben. Selbiges gilt für Anpassungen im 
Linkerskript. Also verwalte ich mein Projekt lieber in einem separatem 
Verzeichnis.

Ich hätte die Änderungen natürlich leicht bemerkt, wenn ich das 
Ausgabeverzeichnis des CubeMX mit GIT o.ä. getrackt hätte. Dann hätte 
ein git diff direkt alle relevanten CubeMX Änderungen aufgelistet.

[Harry L. (mysth)]

Malte _. schrieb:
> Naja, aus meiner Sicht generiert CubeMX eher Samplecode. Man hat zwar in
> den Quelltexten Stellen um eigenen Code einzufügen, aber wie ich auch
> nur eine extra .c Datei oder zusätzliche Include Suchpfade im Cube
> hinzufüge habe ich nicht herausgefunden. Stattdessen wird das Makefile
> einfach immer überschrieben. Selbiges gilt für Anpassungen im
> Linkerskript. Also verwalte ich mein Projekt lieber in einem separatem
> Verzeichnis.

Vollkommen falsche Vorgehensweise!
Einfach in der IDE im Project-Explorer eine neue C-Datei erzeugen und 
fertig.
Alle C-Files in deinem Projekt werden autom. verwendet.
Um das makefile musst du dich überhaupt nicht kümmern.

Und nein!
CubeMX erzeugt keinen "Sample-Code" sondern alles, was du brauchst.

Du solltest dich erstmal mit dem Umgang mit CubeIDE beschäftigen!

[STK500-Besitzer (Gast)]

Harry L. schrieb:
> Einfach in der IDE im Project-Explorer eine neue C-Datei erzeugen und
> fertig.

Und selbst da kann man einen Zielordner angeben.

[Harry L. (mysth)]

STK500-Besitzer schrieb:
> Harry L. schrieb:
>> Einfach in der IDE im Project-Explorer eine neue C-Datei erzeugen und
>> fertig.
>
> Und selbst da kann man einen Zielordner angeben.

Ja natürlich!

Muß man sogar.
Re-Klick auf den gewünschten Ordner -> New -> Source-File

[Malte _. (malte)]

Um das Rätsel nach 3 Jahren zu lösen (und für den Fall das hier jemand 
auf der Suche nach Hilfe auf den Thread stößt):

Im obigen Code wird der falsche Pointer eingetragen, aus:

*(__IO uint8_t *)g_spi->DR = data;

muss

*(__IO uint8_t *)&(g_spi->DR) = data;

werden. Das selbe beim Auslesen der Daten. Die Casterei ist notwendig, 
weil DR als 32 Bit Register in dem Struct definiert ist. Ohne Cast liest 
und Schreibt der Code 16 Bit in das FIFO Register (beim STM32L452, beim 
STM32F411 ist DR hingegen kein FIFO). Entsprechend ist dann jeder 2. 
Transfer eine 0 auf dem Bus...

Mit eigenem DMA Code habe ich es jetzt auch am laufen. Ergebnis der 
tagelangen Debuggerei:
3KiB Codeersparnis bei 6,4% höherer Geschwindigkeit gegenüber der HAL 
Lib.
Vielleicht helfen ja jemandem die angehängten Dateien.

[Harry L. (mysth)]

Malte _. schrieb:
> Mit eigenem DMA Code habe ich es jetzt auch am laufen. Ergebnis der
> tagelangen Debuggerei:
> 3KiB Codeersparnis bei 6,4% höherer Geschwindigkeit gegenüber der HAL
> Lib.

Und dafür hast du jetzt 3 Jahre gebraucht?
Glückwunsch!

3kB Code-Ersparnis - geschenkt! (KiB ist im übrigen keine gültige 
Einheit für Speichergröße)
Dann lieber ordentlicher wart- portier- und lesbarer Code.

Wie du auf die 6,4% Geschwindigkeitsgewinn bei der Nutzung eines DMA 
kommst, ist mir schleierhaft.
Bei identischer Clock-Konfiguration spielt der Code absolut keine Rolle.

Achja; HAL ist keine "Lib"(du meintest sicher Library), sondern eine 
Sammlung nützliche Codeschnipsel, die bedarfsgerecht eingebunden werden.

[Cyblord -. (cyblord)]

Auch wenn das nach 3 Jahren keine Rolle mehr spielen sollte: Ich habe 
gute Erfahrungen mit der Nutzung der Low-Level APIs gemacht, wenn man 
die HAL nicht komplett nutzen möchte.

Das ist letztlich ein Aufguss der StdPeriphLib aber offiziell und 
gepflegt Teil des HAL Repos.

Es ist eine gute Mischung aus übersichtlicher APIs und wenig bis gar 
kein verstecktes oder undurchsichtiges Verhalten. Perfekt um das meiste 
selbst zu implementieren. Es bringt auch kein Interrupt Handling mit.

[Bauform B. (bauformb)]

Malte _. schrieb:
> Die Casterei ist notwendig,
> weil DR als 32 Bit Register in dem Struct definiert ist.

Sollte man nicht lieber die Struct korrigieren, z.B. so für den 
STM32L431?

[Malte _. (malte)]

Harry L. schrieb:
> Und dafür hast du jetzt 3 Jahre gebraucht?
> Glückwunsch!
Na ich hab 3 Jahre den HAL Code verwendet und noch andere Sachen im 
Real-Life gemacht. Bis mir bei einem Programm ungefähr noch die Menge an 
Speicher fehlte, also habe ich das Problem wieder aufgegriffen.

> 3kB Code-Ersparnis - geschenkt! (KiB ist im übrigen keine gültige
> Einheit für Speichergröße)
https://en.wikipedia.org/wiki/Kilobyte#Binary_(1024_bytes)

> Wie du auf die 6,4% Geschwindigkeitsgewinn bei der Nutzung eines DMA
> kommst, ist mir schleierhaft.
> Bei identischer Clock-Konfiguration spielt der Code absolut keine Rolle.
Du hast recht die 6,4% sind eine unbrauchbare Angabe. Dies waren der 
Prozentsatz der gesparten CPU Zyklen bei meiner Display 
Neuzeichenfunktion (Display an SPI) samt Rendern des Framebuffers. Da 
die reine Datenübertragung tatsächlich gleich schnell ist, kommt der 
Geschwindigkeitsvorteil durch anderen Code beim Aufsetzen des DMA und 
warten auf den fertigen Transfer zustande. Der sollte aber konstant 
sein, unabhängig von der Transferlänge. Ein besseres Maß wäre daher 
gesparte CPU Zyklen pro Transfer.

Bauform B. schrieb:
> Sollte man nicht lieber die Struct korrigieren, z.B. so für den
> STM32L431?
Stimmt, die Lösung finde ich auch eleganter. Naja, das Struct war so 
auch von ST.