Hi, ich habe ein grösseres Projekt (ca. 750Kb bei O3 reiner Code) auf dem STM32F407 gemacht. Jetzt muss ich das Projekt auf splitten (2 ähnliche Produkte) und beim neuen reicht mir aber die Leitung nicht mehr und ich wollte auf einen STM32F7 um steigen. Jetzt kommen halt die ganzen Fragen wie man am besten mit dem Projekt umzieht. Dem Compiler zu sagen das es jetzt ein M7 ist und das Linkerfile anzupassen ist nicht das Problem! Aber ich nutze die SPL und nicht die HAL, das auch noch recht viel. Für dem M7 gibt es aber die SPL nicht! Alles auf die HAL umschreiben ist doch fast Selbstmord. Wie würdet Ihr nun vorgehen? VG, Uli
Zwischen F4 und F7 gibt es in Hinblick auf Peripherie kaum Unterschiede. STM wirbt selbst damit, dass alle F4-Projekt auch auf F7 laufen, ohne den Code anfassen zu müssen. Tatsächlich ist mir aber aufgefallen, dass an manchen Stellen ein DSB nötig wird (aufgrund der Caches) und dass der I2C neu ist. Clocktree ist natürlich auch anders. SPI, UART, Timer und co sind aber identisch.
Was ist den DSB ? Das die Clock und auch die RAM aufteilung anders ist macht ja nichts, ist ja keine unlösbare Aufgabe. I2C brauche ich beim M7, hatte ich beim M4 aber nicht drin, da neu auch kein Problem. I2S, Timer, UART, Kammerainterface & Externes RAM benutze ich. Der Rest ist meistens nur IO gefummel.
Uli schrieb: > Wie umsteigen von M4 auf M7? M4-Loch aufbohren und grösseres Gewinde reinschneiden. :-)
Harald W. schrieb: > M4-Loch aufbohren und grösseres Gewinde reinschneiden. :-) War auch mein spontaner Gedanke beim Lesen der Überschrift: 3mm größer aufbohren. :-)
Mit 'F4 auf F7' wär das nicht passiert ;) Du kannst aber mit protestieren https://www.ipetitions.com/petition/SPLReinstatement
Was'n das? https://gitlab.com/caesar-lab/stm32f7-legacy-library/tree/master/STM32F7xx_StdPeriph_Driver
Uli schrieb: > HA HA! Das war ein dezenter Hinweis darauf, möglichst aussagekräftige Überschriftenzu benutzen!
Uli schrieb: > Was ist den DSB ? Data Synchronisation Barrier, Assembler-Anweisung. Alle Speicherzugriffe müssen abgeschlossen sein, bevor mit der Ausführung fortgefahren wird. Mir ist beim Umstiegt von F4 auf F7 folgende zwei Zeilen Code um die Ohren geflogen:
1 | // set DMA as owner of descriptor
|
2 | stm32eth_TransmitDescriptor.TDES0.bits.Own = 1; |
3 | // start DMA
|
4 | ETH->DMATPDR = 0xFFFFFFFF; |
DMA wurde gestartet, obwohl das own-bit noch nicht gesetzt war.
Das ich das besser hätte schreiben können habe ich doch kappiert, aber ändern kann ich es nicht mehr. Wobei wenn ich ein M4 Gewinde gemeint hätte dann wäre der Post aber auch nicht unter Compiler gelandet. Jetzt ist es zuspät und man könnte da Stundenlang drüber reden, macht nur keinen Sinn. Die stm32f7-legacy-library sieht auf den 1. Blick recht interessant aus. Muss ich noch richtig ansehen und mit der vom STM32f4 vergleichen. VG, Uli
Das mit dem DSB bei Deinem DMA Beispiel werde ich hoffentlich nicht haben, aber ich werde darauf achten. Wenn ich doch Probleme damit bekomme. Wie hast Du es denn gelöst? VG, Uli
Uli schrieb: > Wenn ich doch Probleme damit bekomme. > Wie hast Du es denn gelöst?
1 | // set DMA as owner of descriptor
|
2 | stm32eth_TransmitDescriptor.TDES0.bits.Own = 1; |
3 | // wait for memory transaction
|
4 | __DSB(); |
5 | // start DMA
|
6 | ETH->DMATPDR = 0xFFFFFFFF; |
Der Fehler ist erkennbar, wenn im normalen Programmablauf nichts gesendet wird, jedoch beim Stepping mit dem Debugger alles super funktioniert.
Little B. schrieb: > Tatsächlich ist mir aber aufgefallen, dass an manchen Stellen ein DSB > nötig wird Sicher, daß der vorher nicht auch schon nötig war? Hat jemand das ARM auswendig gelernt und kann das aus der Hand schütteln? :-)
Die DSB sollten in der HAL schon drin sein, so dass man sich damit nicht beschäftigen müsste. Auf andere Pinbelegung achten F4 <> F7 sind zumindest beim LQFP100 ein paar Pins anders.
Mit etwas Glück gibt es von ST auch einen Migration Guide der zu deiner Anwendung passt. Dieser hat mit damals bei dem Wechseln von STM32F1 zu STM32L1 sehr geholfen und viel Recherche erspart: http://www.st.com/content/ccc/resource/technical/document/application_note/31/76/e6/da/6b/c7/4c/2e/DM00032987.pdf/files/DM00032987.pdf/jcr:content/translations/en.DM00032987.pdf
STM32F74x hat mit Cortex-M7 revision r0p1 das Problem, das Interrupts bei Single stepping dazwischenfunken. Das ist recht nervig! STM32F76X hat in Revision A das Problem in Errata sheet Section 2.7.6: Ethernet erroneous data received in RMII configuration Inzwiwschen sollte die Z Revision im Umlauf sein, das sollte man aber checken.
Ich habe mir diese stm32f7-legacy-library mal angetan. 1. Test mit einem kleineren Projekt war erfolgreich. Allerdings waren die Timer alle noch falsch eingestellt. Dann habe ich mal die HAL und diese SPL angesehen, so grosse unterschiede gibt es da nicht. Manches ist sauberer, manches ist schlechter gelöst bei der HAL. Nach den DSB Stellen suche ich mal und schaue ob das auch in dieser SPL drin ist. Da ich an die SPL gewöhnt bin und diese auch recht viel benutzt habe versuche ich mein Glück mit dieser F7 SPL. Beim Testen werde ich dann schon über den einen oder anderen Fehler stolpern oder auch nicht wenn alles richtig ist. Beim 144 Pinner passen die Pins. Habe einen F746 also r0p1 Model, beim F407 hatte ich aber auch schon hier und da Probleme beim Debuggen. Hier erwarte ich nur das es nicht sonderlich schlimmer wird. VG, Uli
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.