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?!?
MMM schrieb: > 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.
Harry L. schrieb: > 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?
MMM schrieb: >> 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.
Stefan F. schrieb: > 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.
MMM schrieb: > 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.
>> Da endet schon die Wiederverwendbarkeit von Code, wenn man >> das nicht von Anfang an berücksichtigt hat. Harry L. schrieb: > 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.
Stefan F. schrieb: > 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?
MMM schrieb: > 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.
MMM schrieb: > 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.
Stefan F. schrieb: > Markieren, Strg-C drücken. Dann im neuen Projekt mit Strg-V einfügen. Manuell ;-) Harry L. schrieb: > 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?
MMM schrieb: > 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.
:
Bearbeitet durch User
Harry L. schrieb: > 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.
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!
Angehängte Dateien:
-
H743_clock_bug.PNG
180 KB
Harry L. schrieb: > 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)
:
Bearbeitet durch User
MMM schrieb: > Harry L. schrieb: >> 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?
Angehängte Dateien:
Harry L. schrieb: > 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.
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
:
Bearbeitet durch User
Angehängte Dateien:
-
H7_400MHZ_ext.png
56 KB
Nachtrag: Durch manuelle Konfiguration konnte ich zumindest die 400MHz einstellen. (siehe Screenshot)
Angehängte Dateien:
-
H7_max_freq.png
110 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
Harry L. schrieb: > 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.
Harry L. schrieb: > 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.
Harry L. schrieb: > 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.
MMM schrieb: > 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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.