Ich habe ein Cube projekt für den F1 nun möchte ich diesen auf den F4 portieren. Pinbelegung der GPIO ports identisch (also alle ports etc können gleich bleiben). Wie wähle ich beim Cube einen anderen uC? Im IOC kann ich die zwar auflisten aber nicht wählen?!?
Wie wähle ich beim Cube einen anderen uC? Im IOC kann ich die zwar auflisten aber nicht wählen?!?
Das geht leider nicht. Da bleibt nur, das Projekt neu anzulegen. Sich vorher in CubeMX einen Report als PDF zu erzeugen kann dabei sehr hilfreich sein.
Das geht leider nicht.
WTF ?!?
o_O
Echt? (War ein Witz oder?) Das wäre ja das bescheuertste was ich seit langem gehört habe! Das ist ja die Grundidee/Grundlage eines jeden HALs. Das eine Portierung zu anderen Herstellern nicht unterstüzt wird - ok. Aber wechsel von ST internen targets?
Gast
#7345941
Das geht leider nicht.
WTF ?!? War ein Witz oder?
Leider nicht. Da endet schon die Wiederverwendbarkeit von Code, wenn man das nicht von Anfang an berücksichtigt hat.
Da endet schon die Wiederverwendbarkeit von Code, wenn man das nicht von Anfang an berücksichtigt hat.
Blödsinn! Natürlich kannst du deinen Code wiederverwenden. Daß jede MCU eine individuelle Konfiguration benötigt sollte ja wohl klar sein, und genau die und nichts Anderes steckt in der .ioc-Datei.
Echt? (War ein Witz oder?) Das wäre ja das bescheuertste was ich seit langem gehört habe!
Es zwingt dich doch keiner Cube zu verwenden. Du kannst es ja mal von Grund auf selber machen und dann das target wechseln. Ich wünsche viel Spaß.
Ich hab hier im übrigen Cube Projekte die auf 4 verschiedenen Serien laufen, die teilweise nicht mal Pin-kompatibel sind, das geht schon wenn man das Projekt entsprechend aufbaut.
Gast
#7345973
Da endet schon die Wiederverwendbarkeit von Code, wenn man das nicht von Anfang an berücksichtigt hat.
Blödsinn! Natürlich kannst du deinen Code wiederverwenden.
Ich habe geschrieben, dass man Probleme bekommt wenn man es nicht von Anfang an berücksichtigt hat. Die bedeutet, dass es geht. Du bist der Einzige, der daraus Blödsinn gelesen hat.
Leider nicht. Da endet schon die Wiederverwendbarkeit von Code, wenn man das nicht von Anfang an berücksichtigt hat.
Ja ok, ist in meinem Fall nicht weiter schlimm. Mach ich halt das neue projekt. Wie kann ich allen user code exportieren und beim neuen Projekt (mit dem neuen target) importieren?
Gast
#7345978
Wie kann ich allen user code exportieren und beim neuen Projekt (mit dem neuen target) importieren?
Markieren, Strg-C drücken. Dann im neuen Projekt mit Strg-V einfügen.
Wie kann ich allen user code exportieren und beim neuen Projekt (mit dem neuen target) importieren?
Indem du einfach alle Dateien, die Code von dir enthalten in dein neues Projekt kopierst, und anschließend von CubeMX einmal den Code neu generieren lässt.
Schau dir mal nested Projects an.
Markieren, Strg-C drücken. Dann im neuen Projekt mit Strg-V einfügen.
Manuell ;-)
Indem du einfach alle Dateien, die Code von dir enthalten in dein neues Projekt kopierst, und anschließend von CubeMX einmal den Code neu generieren lässt.
Schon komfortabler :-)
Noch was: ich habe gerade den Cube und die Projekte upgedatet, und nun ist bei einem längst abgeschlossenen H7 Projekt bei den Clocks im IOC die hälfte rot?!?, was hat dies nun zu bedeuten? Bugs in der neuen library/cube? (STM32H743) Können diese fehler bedenkenlos ignorieret und der code generiert werden, oder besteht Gefahr dass die neue codegeneration dann auch "mist" erzeugt?
Noch was: ich habe gerade den Cube und die Projekte upgedatet, und nun ist bei einem längst abgeschlossenen H7 Projekt bei den Clocks im IOC die hälfte rot?!?, was hat dies nun zu bedeuten?
Dann ist die Clock-Configuration fehlerhaft. Einfach den Solver starten - der sollte das autom. korrigieren. Am einfachsten geht das, indem du in dem Feld HCLK (ziemlich in der Mitte) einen zu deiner MCU passenden Wert einträgst, oder oben auf "Resolve Clock Issues" klicken.
Dann ist die Clock-Configuration fehlerhaft.
Ist sie nicht, hat ja früher funktioniert und wurde früher auch nicht als fehlerhaft angezeigt. Clock resolver macht Käse: 100MHZ anstelle 480 core, SPI noch 75MHz... Wenn ichs manuell wieder erhöhe wirds rot.
Clock resolver macht Käse: 100MHZ anstelle 480 core,
Nein, macht er nicht! Du musst deinen gewünschten Takt in das Feld HCLK eintragen!
MMM schrieb:
Clock resolver macht Käse: 100MHZ anstelle 480 core,
Nein, macht er nicht! Du musst deinen gewünschten Takt in das Feld HCLK eintragen!
Bitte sehr siehe Anhang. 240 ist max. 240 sind bei HCLK drinn: ROT!
(rot mit fehlermeldung: muss unter 100MHZ sein)
Angehängte Dateien:
-
H743_clock_bug.PNG
(180 KB)
MMM schrieb:
Clock resolver macht Käse: 100MHZ anstelle 480 core,
Nein, macht er nicht! Du musst deinen gewünschten Takt in das Feld HCLK eintragen!
Bitte sehr siehe Anhang. 240 ist max. 240 sind bei HCLK drinn: ROT!
Stimmen denn die 25MHz Basistakt? Wie sieht das aus, nachdem der Solver drüber gelaufen ist?
Wie sieht das aus, nachdem der Solver drüber gelaufen ist?
siehe anhang.
Ja ist ein 25MHZ oszi am HSE Pin. Die orriginalkonfiguration war auch vor dem update vom Cube akzeptiert.
Kannst es gerne reproduzieren: STM32H743 mit dem neusten CUBE/Library versuchen auf 480MHZ (mit 240HCLK) zu bringen.
Angehängte Dateien:
-
H743_clock_bug_nach_solver.PNG
(220 KB)
Also, ich glaube inzw. auch an einen Bug im CubeMX. Mir ist es auch nicht gelungen, mit einem ext. Takt auf 480MHz zu kommen.
Einen wichtigen Hinweis habe ich hier: https://community.st.com/s/question/0D53W00001B11UhSAJ/stm32hz-mx-clock-configuration-480mhz gefunden, aber VSO kann ich gar nicht auf 0 stellen. Da ist aktuell nur 1-3 möglich. In der Konfiguration 1 sind max. 400MHz möglich, und die erreicht der Solver auch, ABER, er benutzt dazu den internen Takt.
Dazu gibts hier noch einen hilfreichen Beitrag: https://community.st.com/s/question/0D53W00000hPphXSAS/stmh743zi2-cubemx-clock-setup-max-frequency-not-allowed
Nachtrag: Durch manuelle Konfiguration konnte ich zumindest die 400MHz einstellen. (siehe Screenshot)
Angehängte Dateien:
-
H7_400MHZ_ext.png
(56 KB)
Noch ein Nachtrag: Die 480 MHz kann man nur verwenden, wenn man gleichzeitig Tjmax 105°C zulässt - will man das?
Datenblatt S. 212: https://www.st.com/resource/en/datasheet/stm32h743bi.pdf
Angehängte Dateien:
-
H7_max_freq.png
(110 KB)
Gast
#7346096
Die 480 MHz kann man nur verwenden, wenn man gleichzeitig Tjmax 105°C zulässt - will man das?
Naja, wenn daneben Elkos und Leuchtdioden auf dem Board sind, will man sowieso deutlich darunter bleiben. Es sei denn, man will, das das Gerät möglichst schnell kaputt geht.
will man das?
ja will man! und wenns thermisch kritisch wird will man einen kühlkörper draufsetzen. Da die meisten Anwendungen Netzbetrieben und Kühlkörper im vergleich zu uC kosten gering, machts sinn wenn so ein uC eingesetzt wird seine performance auch genutzt wird. Wirds nicht benötigt genügt ein langsamerer uC.
Bug im CubeMX.
bin nun zurück auf cube 1.10.1 - dort gehts/giengs ohne probleme.
Übrigens: der uC wird zwar warm aber nicht super heiss (geschätz ca 60C bei 25C Umgebung und meiner Applikation) anyway vermutlich lässt sich schon irgend ein benchmark programm zusammenstellen, welches wesentlich mehr verlustleistung generiert (und im worst case die 105C erreicht).
Anyway kann zumindest sagen, dass zumindest dieses projekt keinerlei stabilitätsprobleme oder ausfälle zu verzeichnen hat, und ich empfehle (sofern Netzbetrieb) die gekaufte Performance des uC nicht künstlich einzuschränken.
Ich habe ein Cube projekt für den F1 nun möchte ich diesen auf den F4 portieren.
Es geht nur zwischen Derivaten aus derselben Serie. Hier im Dokument UM1718 im Kapitel "11.9 Switching to another MCU" ist es beschrieben: https://www.st.com/resource/en/user_manual/um1718-stm32cubemx-for-stm32-configuration-and-initialization-c-code-generation-stmicroelectronics.pdf
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.