STM32F466: kein CLK/DATA an SPI1

Nachdem es in der Source <stm32f4xx_hal_spi.c> kein explizites Schreiben von einzelnen Bytes (weder als Makro noch als Funktion) gibt, wird es dringend empfehlensert sein die vorhandenen Funktionen zu nutzen (in diesem Fall dann <HAL_SPI_Transmit(...)>. Wenn du dir die Funktionen anschaust gibt es da eine Menge von zusätzlichen Code der ggf. abgearbeitet wird bzw abgearbeitet werden muss. Schon allein wegen dieser Unübersichtlichkeit benutze ich grundsätzlich die LL-Libraries mit denen ich ähnlich der Bare- Metal-Programmierung noch wunderbar auf die Register zugreifen kann und damit genau weiss was ich mache (oder unterlasse). Jeden- falls ist die gemischte Verwendung von HAL und Direktzugriffen auf die Register eine schlechte Idee da man überhaupt nicht mehr die Übersicht hat was passiert.

Zwischen dem Glauben, alles sei korrekt initialisiert (inkl. Clocks) und dem Wissen, alles ist korrekt initialisiert, besteht ein wichtiger Unterschied. Im Zweifel muss man halt alle relevanten Bits in den ganzen Registers händisch gegen RM vergleichen. Also das, was in den Registern tatsächlich drin steht (mit Debugger auslesen!), und nicht, was man meint, hineingeschrieben zu haben.

Andreas B. schrieb:

Zwischen dem Glauben, alles sei korrekt initialisiert (inkl. Clocks) und dem Wissen, alles ist korrekt initialisiert, besteht ein wichtiger Unterschied.

Dem HAL Code würde ich schon vertrauen zudem es eine (F4-) Architektur betrifft die es schon lang gibt. Aber - ich hatte es schon angedeuted - muss man sich dann schon komplett an die Regeln der HAL-Programmierung halten und nicht auf die Register direkt zugreifen. Soviel ich abschätze (ich schaue jetzt nicht nach da ich keine HAL-Implementierung habe) wird man Interrupts abarbeiten müssen die sich in einem oder mehreren Callbacks bemerkbar machen. Die Callbacks sind vermutlich bereits Teil der HAL-Initialisierung für das SPI, existieren also schon aber müssen noch mit "Leben" erfüllt werden.

Ich benutze auf den STMs nur den HAL-Code und keine direkten Registerzugriffe. Das funktioniert für I2C, SPI, I2S... Die Jungs von STM, die die sich auskennen, haben das für mich programmiert.

Und wenn es 5% langsamer ist, was solls. Damit kann ich leben. Bevor ich mich aber tagelang an das Debuggen auf der Registerebene begebe .... da kann ich mit der Zeit was besseres anfangen.