Nabend!
Mag vielleicht dem ein oder anderen trivial vorkommen aber gerade klappt
etwas nicht und da blieb ich am AF_IO Register hängen.
Ich arbeite noch mit den StdPeriph Library, daher Nachsicht, HAL ist up
to date aber umsteigen möchte ich nicht. Das meiste was ich mit der HAL
finde ist auch ganz fix umgeschrieben.
Hier die beiden Header der SPL, der APB2 hat ein AFIO, der APB1 aber
nicht.
Alternate Function, wie ich es verstehe ich, dass man der Hardware, zb
UART, SPI die Kontrolle über Pins überlässt, also eine Art Weiche die
gestellt werden muss, damit aus General IO Pins eben die der Hardware
werden und sie von den normalen Port Register abgekoppelt werden.
Naja, meine UART2 Geschichte für den F103 läuft aber eben auch ohne.
Hatte erst Code aus dem Netz angeschaut, der war aber auch wieder
fehlerhaft, der warf die Busse durcheinander, APB2 Geschichte in einen
APB1 RCC Befehl usw. Man prüfe also, was man kopiert.
Also wann genau muss man den Clock für diese AF genau aktivieren mit
RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO) ??
Und das eben auch nur für den APB2 Bus.. weil der APB1 ja kein solches
Register hat.
Bei meiner UART2 Routine wird der Pin ja mit GPIO_Mode_AF_PP defniert,
das scheint zu reichen.
Interessant... ohne GPIO_Speed_2MHz spielt es auch nicht, dachte da wäre
ein Default drin, irgendwas muss ja drin stehen. Aber nein, ohne das
geht es nicht. Auch bei bei den GPIO Ports.
Christian J. schrieb:> Hier die beiden Header der SPL, der APB2 hat ein AFIO, der APB1 aber> nicht.
Das ist so nicht richtig. Die Alternate Function Einheit wirkt auf alle
Pins. Allerdings muss man ja an die Register kommen und ST hat die halt
auf den APB2 gelegt. Hätte aber genauso gut der APB1 sein können.
> Alternate Function, wie ich es verstehe ich, dass man der Hardware, zb> UART, SPI die Kontrolle über Pins überlässt, also eine Art Weiche die> gestellt werden muss, damit aus General IO Pins eben die der Hardware> werden und sie von den normalen Port Register abgekoppelt werden.
Grundsätzlich richtig.
> Also wann genau muss man den Clock für diese AF genau aktivieren mit> RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO) ??
Laut Manual muss der AFIO aktiviert sein beim Zugriff auf dessen
Register, z.B.: "To read/write the AFIO_EVCR,AFIO_MAPR and AFIO_EXTICRX
registers, the AFIO clock should first be enabled. Refer to Section
6.3.7: APB2 peripheral clock enable register (RCC_APB2ENR)."
> Und das eben auch nur für den APB2 Bus.. weil der APB1 ja kein solches> Register hat.
siehe oben, AFIO wirkt auf alles, am Bus hängt es nur für den
Registerzugriff.
> Bei meiner UART2 Routine wird der Pin ja mit GPIO_Mode_AF_PP defniert,> das scheint zu reichen.
Ja.
> Interessant... ohne GPIO_Speed_2MHz spielt es auch nicht, dachte da wäre> ein Default drin, irgendwas muss ja drin stehen. Aber nein, ohne das> geht es nicht. Auch bei bei den GPIO Ports.
Was die Library daraus macht, weiss ich nicht, aber Reset Default ist
jeweils Input für die Pins und 0 beim Mode und das ist Reserved, wenn
der Pin auf Output gestellt ist. Daher muss ein Mode-Bit gesetzt werden.
John Doe schrieb:> Das ist so nicht richtig. Die Alternate Function Einheit wirkt auf alle> Pins. Allerdings muss man ja an die Register kommen und ST hat die halt> auf den APB2 gelegt. Hätte aber genauso gut der APB1 sein können.
Ich danke dir ganz herzlich für diese ausführliche Antwort! Damit ist
wohl auch alles schon beantwortet! Bei der Suche im Netz vorher fand
sich jedenfalls eine Menge Falsches und so richtig verstanden wurde es
teils auch nicht. Einschalten des AF Clocks kann jedenfalls nicht
verkehrt sein, die paar uA machen den Kohl auch nicht fett.
Zitat:
Was die Library daraus macht, weiss ich nicht, aber Reset Default ist
jeweils Input für die Pins und 0 beim Mode und das ist Reserved, wenn
der Pin auf Output gestellt ist. Daher muss ein Mode-Bit gesetzt werden.
--
Nun ja, jedenfalls muss man die Pins vorher auf 0 setzen, bevor man die
Clocks einschaltet und den Struct Init für OUT(LOW) durchführt, sonst
gibt es ganz feine High-Glitches-Nadeln am Datalogger.
Der Betreff ist stark übertrieben, dieses Problem gibt es nur bei den
uralten STM32F10x, also 100, 101, 102, 103, 105 und 107. Da stecken die
Chips 410, 412, 414, 418, 420, 428 und 430 drin.
Diese Art des Alternate Function Multiplexers ist so vermurkst, die
Chips gehören als Folterwerkzeug geächtet. Mal wieder ein Fall von der
schlechteste gewinnt :(
Bauform B. schrieb:> Dieses Problem gibt es nur bei den uralten STM32F10x
Stimmt, bei den neueren Modellen ist das wesentlich eleganter und auch
besser verständlich umgesetzt worden.
Bauform B. schrieb:> Mal wieder ein Fall von der schlechteste gewinnt
Allerdings sorgen die Chinesen (mal wieder) durch ihre schlechten
Fälschungen für ein jähes Ende des STM32F103. Aktueller Nachfolger ist
der STM32F303.
Stefan ⛄ F. schrieb:> Allerdings sorgen die Chinesen (mal wieder) durch ihre schlechten> Fälschungen für ein jähes Ende des STM32F103. Aktueller Nachfolger ist> der STM32F303.
Da nahezu jedes Blue Pill Board heute ein Fake ist und meine ganz sicher
auch wird es da wohl keine Möglichkeit geben das zu prüfen. Ich schreibe
meine aktuelle Software auch Zeile für Zeile und teste sofort danach.
Für den 303 habe ich keine CMSIS und keine SPL. Leider.
Bauform B. schrieb:> Der Betreff ist stark übertrieben, dieses Problem gibt es nur bei> den> uralten STM32F10x, also 100, 101, 102, 103, 105 und 107. Da stecken die> Chips 410, 412, 414, 418, 420, 428 und 430 drin.>> Diese Art des Alternate Function Multiplexers ist so vermurkst, die> Chips gehören als Folterwerkzeug geächtet. Mal wieder ein Fall von der> schlechteste gewinnt :(
Der STM32F100 war STs Cortex-Erstlingswerk. Und das war nach den
Luminary-Vorreitern (welche nur Standard-ARM-IP für die Peripherie
einsetzten) schon recht ordentlich.
Insbesondere nach den vielen Jahren mit dem ARM7TDMI-Murks war das weit
mehr als nur ein Schritt nach vorn.
Dr. MCU schrieb:> Insbesondere nach den vielen Jahren mit dem ARM7TDMI-Murks war das weit> mehr als nur ein Schritt nach vorn.
Die habe ich 2000 "bearbeitet"... allein schon die Clocks einstellen war
Hexenwerk :-( Dabei wurde das Teil gefeiert wie sonstwas...
Dr. MCU schrieb:> Viel schlimmer noch war der ganze Interruptkram mangels> Interruptcontroller im Kern. Ich sag nur "spurious interrupt"...
Die mmc SD Schnittstelle hat keiner verstanden im Team... zehnmal
Datenbuch durchgelesen... nur Fragezeichen im Gesicht :-( War ja noch
alles neu, gab keine Beispiele und Internet war noch leer....
Thread beobachten
Seitenaufteilung abschalten