Liebe Leute, kennt sich jemand mit https://github.com/stm32duino/Arduino_Core_STM32 aus? Ich wüsste gern, wo und wie dort für mein Nucleo-F303K8 (https://www.st.com/en/evaluation-tools/nucleo-f303k8.html) die clock-domains konfiguriert werden. Hintergrund ist, dass ich versuche, https://github.com/nopnop2002/Arduino-STM32-CAN/tree/master/stm32f303 zum Laufen zu bekommen, und dabei feststelle dass CANInit(CAN_125KBPS,0) mit BTR 0x1C0011 (SJW=1, BRP=18, TS1=13, TS2=2) auf dem CAN-Bus zu einer Rate von 110.8 kbps führt. Die in dieser Quelle benutzten Werte für CAN_bit_timing_config_t sind anscheinend für eine tPCLK (also APB1) von 36MHz berechnet. Siehe auch http://www.bittiming.can-wiki.info/. Auf meinem Board scheint APB1 aber mit knapp 32MHz zu laufen, denn wenn ich BTR auf 0x1B0010 stelle (SJW=1, BRP=17, TS1=12, TS2=2), dann ergeben sich bei mir laut Logikanalysator auf dem CAN-Bus die gewünschten 125.2 kbps! LG, Sebastian
ist im DB unter 31.7.7 Bit timing erklärt.
Pieter schrieb: > ist im DB unter 31.7.7 Bit timing erklärt. Ja, das hab ich gelesen. Ein tQ-Quantum ist BRP*tPCLK. Aber bei mir scheint tPCLK, also APB1, knapp 32MHz zu sein, nicht die für STM32F303 anscheinend "üblichen" 36MHz. Ich hab bisher herausgefunden, dass auf den Nucleo-Boards für den Hauptprozessor kein Quarz drauf ist, und der per Default also mit dem internen HSI-Oszillator läuft. Die Konfiguration ist anscheinend in https://github.com/stm32duino/Arduino_Core_STM32/blob/main/variants/STM32F3xx/F303K(6-8)T_F334K(4-6-8)T/variant_NUCLEO_F303K8.cpp und führt mit /2*16/2 zu einem Systemtakt von 64MHz und einem APB1-Takt von 32MHz. Man kann anscheinend mit einer Jumper-Brücke aus dem ST-LINK-Teil des Nucleo Quarz-basierte 8MHz extern in PF0 (SB4) einspeisen. Dann sollte man mit /1*9/2 den Systemtakt auf 72MHz und den APb1-Takt auf 36MHz konfigurieren können ... LG, Sebastian
Wozu braucht man bei STM32-Controllern den Arduino-Wrapper? STM liefert doch CubeMx zur Konfiguration des Controllers. Sogar mit einem schönen Diagramm für die Clock-Einstellungen. Für NUCLEOs etc. gibt es auch Vorlagen. Arduino ist ja als Einstieg ganz nett, weil man schnell zu einem Ergebnis kommt, aber sobald man "dichter" an die Hardware will, hat man doch verloren.
>>Ja, das hab ich gelesen.
Aber nix verstanden.
Wenn der APB1Clock 32 Mhz ist, rechnet man sich aus, wie die 3 Werte
sein müssen.
(SJW+BS1) / (SJW+BS1+BS2) ~0,75
APB1Clock ( khz ) / ((SJW+BS1+BS2)* BitRate ( Khz ) ) -> BTR
Sebastian W. schrieb: > Ich hab bisher herausgefunden, dass auf den Nucleo-Boards für den > Hauptprozessor kein Quarz drauf ist, und der per Default also mit dem > internen HSI-Oszillator läuft. Was heisst da "per Default"? Der Controller läuft mit dem Takt mit dem er konfiguriert wird. Ich bin mit den Nucleo-Boards anfangs hereingefallen und meinte auch dass die STM-Designer den Quarz fahrlässig weggelassen haben. Somit "könnte" man gar nicht mit externem Quarz fahren. Aber: es führt eine Taktleitung vom OnBoard-ST-Link zum Controller. Dort werden standardmässig immer 8 MHz ein- gespeist sodass der man den Controller so konfigurieren kann dass er wie mit einem externen Quarz von 8MHz arbeitet. Wäre doch zu schade und unter Umständen sogar riskant (Takt- Abweichungen) den Controller mit HSI laufen zu lassen.
Sebastian W. schrieb: > Man kann anscheinend mit einer Jumper-Brücke aus dem ST-LINK-Teil des > Nucleo Quarz-basierte 8MHz extern in PF0 (SB4) einspeisen. Dann sollte > man mit /1*9/2 den Systemtakt auf 72MHz und den APb1-Takt auf 36MHz > konfigurieren können ... Ich habe jetzt SB4 gebrückt und RCC wie folgt konfiguriert:
1 | void SystemClock_Config(void) { |
2 | RCC_OscInitTypeDef RCC_OscInitStruct; |
3 | /* Extern strong clock signal on PF0/OSC_IN */ |
4 | RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE; |
5 | RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS; |
6 | RCC_OscInitStruct.HSEPredivValue = RCC_HSE_PREDIV_DIV1; |
7 | RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON; |
8 | RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE; |
9 | RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL9; |
10 | if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK) { |
11 | Error_Handler(); |
12 | } |
13 | |
14 | RCC_ClkInitTypeDef RCC_ClkInitStruct; |
15 | RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_SYSCLK |
16 | | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2; |
17 | RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK; |
18 | RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1; |
19 | RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2; |
20 | RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1; |
21 | if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2) != HAL_OK) { |
22 | Error_Handler(); |
23 | } |
24 | [...] |
25 | } |
Jetzt funktionieren auch die im CAN-Beispiel vorgegebenen CAN_bit_timing_config_t-Werte sauber. Ich habe übrigens im UM1956 von ST (https://www.st.com/resource/en/user_manual/um1956-stm32-nucleo32-boards-mb1180-stmicroelectronics.pdf) einen Fehler gefunden, siehe Anhang. Macht es Sinn denen davon zu berichten, und wenn ja wie? Oder ist das verlorene Liebesmüh? LG, Sebastian
STM Apprentice schrieb: > Was heisst da "per Default"? Er meint wahrscheinlich die Lötbrücken. Bei diesem Nucleo32 Board mit STM32Fxxx ist das so. Bei anderen Nucleo Boards ist der HSE Eingang jedoch in der Regel mit dem 8 MHz Taktausgang des ST-Link verbunden. Man beachte die Fußnote 1.
STK500-Besitzer (Gast) >Wozu braucht man bei STM32-Controllern den Arduino-Wrapper? Die Welt hat der Mikrocontroller hat sich in den letzten zwei Jahrzehnten seit der Erfindung des STK500 schon etwas weiter entwickelt. Der lange Wunsch nach "wiederverwendbarem Code" wird mit dem Arduino Framework langsam erfüllt. Nicht jeder möchte gerne eine der folgenden 200 Arduino Libraries noch mal selber schreiben: https://www.arduinolibraries.info/architectures/stm32 >Arduino ist ja als Einstieg ganz nett, weil man schnell zu einem >Ergebnis kommt, aber sobald man "dichter" an die Hardware will, hat man >doch verloren. Nicht verloren, es wird nur anstrengender. Was meinst du wohl verwenden die Entwickler von STM32Duino als Entwicklungsumgebung? https://github.com/stm32duino/Arduino_Core_STM32
Franz schrieb: > Der lange Wunsch nach "wiederverwendbarem Code" wird mit dem Arduino > Framework langsam erfüllt. Widerliche Arduinopropaganda.
Franz schrieb: > STK500-Besitzer (Gast) >>Wozu braucht man bei STM32-Controllern den Arduino-Wrapper? > > Die Welt hat der Mikrocontroller hat sich in den letzten zwei > Jahrzehnten seit der Erfindung des STK500 schon etwas weiter entwickelt. > Der lange Wunsch nach "wiederverwendbarem Code" wird mit dem Arduino > Framework langsam erfüllt. LOL Ja, langsam... Hat Arduino es inzwischen geschafft, ein RTOS zu implementieren? > Nicht jeder möchte gerne eine der folgenden 200 Arduino Libraries noch > mal selber schreiben: > https://www.arduinolibraries.info/architectures/stm32 Oder die von python. Es gibt bereits von STM Libraries. Meine Erfahrung sagt mir, dass mit zunehmender Abstraktionsebene, Libraries immer unbrauchbarer werden, da man dann immer vom Interesse des jeweiligen Entwicklers abhängig ist. Warum sollte man sich in eine Library einarbeiten, wenn man das zu Fuß schneller hinbekommt und an seine eigenen Bedürfnisse anpassen kann? >>Arduino ist ja als Einstieg ganz nett, weil man schnell zu einem >>Ergebnis kommt, aber sobald man "dichter" an die Hardware will, hat man >>doch verloren. > > Nicht verloren, es wird nur anstrengender. Was meinst du wohl verwenden > die Entwickler von STM32Duino als Entwicklungsumgebung? > > https://github.com/stm32duino/Arduino_Core_STM32 Wozu brauche ich die, wenn ich sowieso nach dem Datenblatt / Reference Manual arbeite? Letztens hat hier jemand den Wunsch nach einer Arduino-Library geäußert, die sowohl auf AVR, als auch ESP läufen sollte. Das Probleme: Es wäre nötig gewesen, Hardwaretimer zu verwenden. PS: Meinen Namen habe ich aus historischen Gründen gewählt, da ich mit einem STK500 in die "einfache" Controllerprogrammierung eingestiegen bin. (Angefangen habe ich mit 8051).
STK500-Besitzer schrieb: > Hat Arduino es inzwischen geschafft, ein RTOS zu implementieren? Ja, mit dem Mbed core. Gibt es mittlerweile seit ca. 2 Jahren, leider wird der nicht besonders gut gepflegt. Ansonsten wird wie bei CubeMX auch FreeRTOS verwendet. In den ESP ist das als Basis schon seit Ewigkeitkeiten drin, für andere Plattformen kann es optional hinzugefügt werden.
J. S. schrieb: > Ansonsten wird wie bei CubeMX auch FreeRTOS verwendet. Geht da der Trend nicht zu Azure?
STK500-Besitzer >Meine Erfahrung sagt mir, dass mit >zunehmender Abstraktionsebene, Libraries immer unbrauchbarer werden, da >man dann immer vom Interesse des jeweiligen Entwicklers abhängig ist. Meine Erfahrung sagt, dass die Anzahl der Programmierer, die alle Libraries selber geschrieben haben kleiner 0.001% ist. Wer meint, alles selber machen zu können, liegt falsch.
es gibt sehr viele RTOS, das wird der Beliebtheit von FreeRTOS keinen Abbruch tun. Azure kenne ich nur als MS Cloud, die Clients dafür nutzen RTOS. Da gibt es viele Lösungen mit verschiedenen RTOS. Da wird auch Politik dabei sein, FreeRTOS gehört ja Amazon und MS möchte da sicher etwas eigenes haben. Und FreeRTOS funktioniert, wer sich da eingearbeitet wird nicht einfach so etwas anderes einsetzen.
Franz schrieb: > Wer meint, alles selber machen zu können, liegt falsch. Wer verallgemeinert, liegt nicht falsch?
Ich möchte ergänzen, dass die ganzen RTOS Varianten für Arduino weder von Arduino kommen noch von Arduino integriert wurden. Entsprechend gibt es von Arduino Seite auch keinen Support dafür. Das ist alles 3rd Party Kram. Jeder sein eigenes Süppchen.
Ich habe es nicht ausprobiert, aber das letzte Update ist vor 5 Monaten: https://github.com/stm32duino/STM32FreeRTOS
Stefan F. schrieb: > Ich möchte ergänzen, dass die ganzen RTOS Varianten für Arduino weder > von Arduino kommen noch von Arduino integriert wurden. Nö, der 'offizielle' Mbed core ist von Arduino CC und enthält ein RTOS.
Stefan F. schrieb: > Ich möchte ergänzen, dass die ganzen RTOS Varianten für Arduino weder > von Arduino kommen noch von Arduino integriert wurden. Entsprechend > gibt es von Arduino Seite auch keinen Support dafür. Das ist alles 3rd > Party Kram. Jeder sein eigenes Süppchen. Der ganze STM32duino-Kram ist doch third-party-Zeug. Wird aber wohl besser supportet als manch anderes.
STK500-Besitzer schrieb: > Der ganze STM32duino-Kram ist doch third-party-Zeug. > Wird aber wohl besser supportet als manch anderes. Das ist wohl so. Als Einstiegsdroge taugt das ganz gut :-) , mit einem fließenden Übergang zum Professionellen. Das ist der Punkt, den ich bei Arduino mag. Du bekommst einen vollwertigen C/C++ Compiler und kannst ihn fast uneingeschränkt nutzen. Bei einigen Modellen (STM32, ESP32, ...) bekommst du außerdem einen leichten Zugang zur Bibliothek des Herstellers, die du später (vielleicht) auch ohne Arduino weiter verwenden wirst.
STK500-Besitzer schrieb: > Der ganze STM32duino-Kram ist doch third-party-Zeug. Das ist von STM Leuten. ST investiert da viel und hat mit dem STM32Duino ja die Australier verdrängt die zuerst einen STM32 core am Start hatten.
Stefan F. schrieb: > Das ist der Punkt, den ich bei > Arduino mag. Du bekommst einen vollwertigen C/C++ Compiler und kannst > ihn fast uneingeschränkt nutzen. Bei einigen Modellen (STM32, ESP32, > ...) bekommst du außerdem einen leichten Zugang zur Bibliothek des > Herstellers, die du später (vielleicht) auch ohne Arduino weiter > verwenden wirst. Da stimme ich dir zu. Das Problem, weswegen der TO den Thread hier eröffnet hat, liegt aber leider genau in dieser Abstraktionsebene: Man muss sich erst duch die Library "quälen", um die Ursache zu finden. Von wegen "portierbarer Code": Wenn ich einen STM32 verwende, werde ich wohl kaum auf einen AVR wechseln (eher auf einen kleineren STM). Außerdem muss man bei sowas immer Kompromisse eingehen, weil der eine Controller was kann, was der andere nicht kann; und umgekehrt. Die ESP verwende ich (bis jetzt) auch nur mit Arduino, weil ich sonst keine (professionelle) Anwendung dafür habe.
STK500-Besitzer schrieb: > Von wegen "portierbarer Code": Wenn ich einen STM32 verwende, werde ich > wohl kaum auf einen AVR wechseln (eher auf einen kleineren STM). Das ist halt so, da darf man sich nicht von Werbung gepaart mit eigenem Wunschdenken veräppeln lassen. Es erwartet ja auch niemand, dass man den Motor eines BMW einfach so durch einen von Mitsubishi austauschen kann. Schön wäre das, aber dann würden die Autos auf unseren Straßen in etwa das Bild abgeben, dass man vor vielen Jahren in der DDR hatte. Will man das? Dann doch lieber die Vielfalt.
Stefan F. schrieb: > Es erwartet ja auch niemand, dass man den Motor eines BMW einfach so > durch einen von Mitsubishi austauschen kann. Da "vergleichst" du Äpfel mit Birnen: die Rolls-Royce Motor Cars Ltd gehört zum BMW-Konzern. Und in den Wagen stecken BMW-Motoren ;). Und Mitsubishi gehört zur *Renault*-Nissan-Mitsubishi-Allianz...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.