Auch wenn auf meinen letzten Beitrag leider bisher niemand geantwortet hat möchte ich hier nochmal fragen. Ich habe ein ganz einfaches Programm einmal für den STM32 F303 und einmal für den STM32 F030 erstellt. Falls ich das Datenblatt richtig verstanden habe sollten beide, falls nichts anderes eingestellt wird in der Default Konfiguration mit 8MHz (HSI) arbeiten. Als IDE verwende ich CooCox. Da selbst mein einfaches Programm unterschiedlich schnell auf den beiden µC arbeitet habe ich mal das Clock control Register ausgelesen. Leider passt das nicht mit dem Reset Value des Reference Manuals(RM) zusammen. Das Clock control register (RCC_CR) ist laut RM für beide identisch aufgebaut. Der Reset value: 0x0000 XX83 where X is undefined. laut RM Binär sollte das folgendes sein 0000 0000 0000 0000 xxxx xxxx 1000 0011 Das Auslesen aus dem F030 ergibt folgendes 0000 0000 0000 0001 0100 1000 1000 0011 Und das Auslesen aus dem F303 0000 0011 0000 0011 0100 0101 1000 0011 Warum weicht der Registerinhalt vom Reset Value des RM ab? Ich hoffe jemand kann mir helfen Danke *RM F303 RCC Register Seite 115 http://www.st.com/web/en/resource/technical/document/reference_manual/DM00043574.pdf *RM F030 RCC Register Seite 89 http://www.st.com/web/en/resource/technical/document/reference_manual/DM00091010.pdf
Im RCC_CR steht nur drin, ob eine bestimmte Taktquelle aktiviert und bereit ist, nicht aber, ob sie auch tatsächlich benutzt wird, oder auch noch Teiler aktiviert sind. Da hat RCC noch ein paar mehr Register zu bieten. Ah, und dann wären da noch Prefetch und Latency, die man auch noch konfigurieren kann.
Hallo, die Initialisierung des Taktes wird üblicherweise im Startup-Code erledigt - schau da mal nach Unterschieden.
Anbei mal die beiden Startup Dateien. Ich kenne mich zwar nicht wirklich mit dem ARM Assembler aus, aber ich denke da wird bei beiden ein SystemInit aufgerufen. Fragt sich dann nur welches. Denn laut der jeweiligen system_stm32fxxx.c würde der F303 mit 72MHz laufen und der F030 mit 48MHz. Wenn ich nach dem Aufruf von SystemCoreClockUpdate(); Die Variable SystemCoreClock aufrufe hat der F303 auch tatsächlich seine 72MHz aber der F030 hat 8MHz statt 48MHz. Irgendwie passt das doch nicht zusammen, oder? Danke
Das mit dem SystemInit passt schonmal, aber wenn ich mich beim Überfliegen nicht verlesen habe, finde ich in der system_stm32f0xx.c nur ein "SystemInit1". Da muss also irgendwo im Projekt eine "SystemInit" herumfliegen. Btw: Wenn kein externer Quarz angeschlossen ist, dann wird mit dem HSI weitergearbeitet - die PLL wird dann garnicht angeworfen (zumindest im angehängten Code).
Die Taktgenerierung in der STM32 - Familie ist der Hammer. Es gibt aber ein Hilfsmittel. Wenn Du die Homepage von ST bemühst kannst Du dir die Stand-Alone Version von STM32CubeMX laden und installieren. 1. Für alle Familien kanst Du dir dann den Code vorbereiten lassen. 2. Die Pinbelegung je nach Package optimieren. 3. Die komplette Konfiguration überprüfen lassen und.... 4. ...per Übersichtsbild die Taktgenerierung veranschaulichen. Da hatte ST wohl ein schlechtes Gewissen.... Gruß T.
Die system_stm32xxx.c Dateien wurden automatisch von CooCox so angelegt. Sie sehen auch irgendwie anders aus als die wo man von der ST Seite runterladen kann. Das mit dem SystemInit1 SetSysClock1 usw. verstehe ich auch nicht. Das ist in den Files direkt von ST auch nicht drin. Am Ende des Files steht auch jeweils z.B. #pragma weak SystemInit = SystemInit1 Was macht denn dieser Ausdruck? Marvin M schrieb: > Btw: Wenn kein externer Quarz angeschlossen ist, dann wird mit dem HSI > weitergearbeitet - die PLL wird dann garnicht angeworfen (zumindest im > angehängten Code). Genau das möchte ich ja erreichen, aber irgendwas verändert scheinbar die Default Einstellungen, irgendwie total komisch?? FPGASchubser schrieb: > Die Taktgenerierung in der STM32 - Familie ist der Hammer. > > Es gibt aber ein Hilfsmittel. Wenn Du die Homepage von ST bemühst kannst > Du dir die Stand-Alone Version von STM32CubeMX laden und installieren. > > 1. Für alle Familien kanst Du dir dann den Code vorbereiten lassen. > 2. Die Pinbelegung je nach Package optimieren. > 3. Die komplette Konfiguration überprüfen lassen und.... > 4. ...per Übersichtsbild die Taktgenerierung veranschaulichen. > > Da hatte ST wohl ein schlechtes Gewissen.... Danke das werde ich mir mal ansehen.
Das Teil ist wirklich gut. Außerdem kann man: 5. FreeRTOS einbinden 6. LWIP - Stack einbinden (incl. code für DP83848 PHY) 7. FATFS einbinden 8. STEMWIN (=Segger-EMWIN) einbinden incl. LCD-Ansteuerung (nur für nicht kommerzielle Anwendungen) 9. Untertützung für die serielle Debug - Ausgabe über den JTAG (das genaue Kürzel dafür habe ich vergessen!) Bei der Ausgabe der Projekt Dateien kann man zwischen Keil, Atollic usw. wählen. Natürlich musst Du für GNU dann noch Anpassungen vornehemen, aber das hat hier einer gemacht und gut beschrieben: Beitrag "STM32-Toolchain mit Eclipse CDT 4.3, GnuArmEclipse, OpenOCD 0.8.0, Gnu Arm GCC 4.8, STM32CubeMX" und das Ganze bereits mit der CMSIS 3.0 .... man muss dann aber auch mal erst mal wieder durchblicken.... Gruß T.
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.