Ich habe lange rumprobiert. Die Peripherie Register der beiden Prozessoren sind identisch, ein einfacher Blink Code läuft auch problemlos mit dem STM32F103 Code. Ein Blinken auf dem CANTx Pin kommt am CAN Transceiver an.
Leider gibt es zu dem GD32F303RCT6 nur sehr wenige Codebeispiele und die laufen ebenfalls nicht auf meiner Hardware (ein Bafang BLDC Controller) Auf dem CAN Tx kann ich mit dem Oszi keinerlei Aktivität sehen. Daß das Timing ggf. nicht passt, würde ich wegen der unterschiedlichen Clock-Konfiguration ja noch einsehen.
Ich weiß, daß man in Reference Manuals alle nötigen Informationen findet (siehe Bild) Ich weiß, daß die HAL Bibliotheken doof sind. Ich weiß auch, daß der eine Cortex M3 und der andere Cortex M4 ist ;)
Lieber stunden-, tagelang herumfrickeln und herumärgern anstatt
was Vernünftiges zu verwenden. Zudem die Controller ja mit
Goldbarren aufzuwiegen sind.
moin,
CAN läuft bei mir mit 1 Modul auf 103,303,405,412,413, 446.
Immer identisch .. bis auf 412,413 die haben bei CAN1 AF8!
CAN hat gefühlte 100 Register, alle verglichen?
Der Controller war keineswegs billig, warum ein Clone verwendet wird und kein Original, musst du Bafang fragen, nicht mich ;) Wobei der GD ja ein deutlicher Fortschritt ist gegenüber dem STM32F103. 120MHz statt 72, M4 statt M3, Hardware FPU...
Wer aus Hobby selber Firmware für einen BLDC Controller schreibt und sich nicht einfach einen VESC, einen ASI, einen Sabvoton, einen Kelly kauft, muss schon ein bisschen nerdig sein ...
Ich habe lange rumprobiert. Die Peripherie Register der beiden
Prozessoren sind identisch,
Wie kommst du darauf? Dia haben ja nicht einmal die gleichen Namen,
weder die Register als Ganzes noch die einzelnen Bits. Die I/O- und
damit die CAN-Funktionalität ist vermutlich an den STM32 /angelehnt/,
was aber noch lange nicht heißt, dass der GD32 und der STM32 bis ins
Detail kompatibel sind. Oder wird das im Datenblatt des GD32 etwa
zugesichert? Natürlich nicht.
Hier werden ein paar von den Unterschieden beschrieben:
Wer aus Hobby selber Firmware für einen BLDC Controller schreibt und
sich nicht einfach einen VESC, einen ASI, einen Sabvoton, einen Kelly
kauft, muss schon ein bisschen nerdig sein ...
Nerdig sein alleine reicht nicht, vor allem sollten seine
Softwarefähigkeiten etwas über die bloße Copy/Paste-Programmierung
hinausreichen :)
Don't know about the M4 vs M3 part though but binaries built for STM32F103 run on the GD32F303 with no modifications including the peripherals (currently tested: usb, adc, timer, dma, interrupts).
Früher wurde einem hier neben den üblichen Stänkereien noch geholfen. Die Leute mit Ahnung schlafen wohl noch. :-)
GD nennt seinen CAN je nach Ausführung CAN0 oder nur CAN, dieser Differenzierung muss ich wohl intensiver nachgehen, ggf. gibt es da doch Unterschiede in den Registern, die ich noch nicht gefunden habe...
GD nennt seinen CAN je nach Ausführung CAN0 oder nur CAN, dieser
Differenzierung muss ich wohl intensiver nachgehen, ggf. gibt es da doch
Unterschiede in den Registern, die ich noch nicht gefunden habe...
Das machen andere Hersteller genauso.
Wenn ein Controiller nur eine (CAN-) Schnittstelle hat, braucht die wohl kaum einen Index zur Unterscheidung.
Früher wurde einem hier neben den üblichen Stänkereien noch geholfen.
Die Leute mit Ahnung schlafen wohl noch. :-)
Was erwartest du? Wenn du einen Baustein verwenden willst, für den es keine Beispiele gibt, wirst du dich - wie jeder andere - durchs Handbunh hangeln müssen.
Da hilft es wohl kaum, Beispiele anderer einfach so übernehmen zu wollen und sich auf (unbestätigte) Aussagen in irgendwelchen Foren zu verlassen, nur weil es einem so gefällt.
Auf dem CAN Tx kann ich mit dem Oszi keinerlei Aktivität sehen. Daß das
Timing ggf. nicht passt, würde ich wegen der unterschiedlichen
Clock-Konfiguration ja noch einsehen.
Das Posten deines Quellcodes könnte bei der Fehlersuche helfen...
Früher wurde einem hier neben den üblichen Stänkereien noch geholfen.
Die Leute mit Ahnung schlafen wohl noch. :-)
GD nennt seinen CAN je nach Ausführung CAN0 oder nur CAN, dieser
Differenzierung muss ich wohl intensiver nachgehen, ggf. gibt es da doch
Unterschiede in den Registern, die ich noch nicht gefunden habe...
Nunja. Wenn der Fragende beim zusammenkopieren von Code scheitert und sich dann beratungsresistend zeigt, was die möglichen Problemursachen an geht, ist es nicht verwunderlich wenn der Ton rauer wird.
Lese die Datenblätter und lerne (selbst) programmieren. Dann klappt auch mit CAN auf (beliebigen) Controllern.
Nunja. Wenn der Fragende beim zusammenkopieren von Code scheitert und
sich dann beratungsresistend zeigt, was die möglichen Problemursachen an
geht, ist es nicht verwunderlich wenn der Ton rauer wird.
Wenn es schon sonst keiner tut dann muss man sich eben selbst
beweihräuchern indem man sich als "nerdig" bezeichnet.
in deinem Registervergleich ist ein CAN_CTL angegeben. Das kenne ich bei
STM nicht.
was sagt der Debuger?
aus deinem Link:
Other psa: the samc21 chips do not have usb... (difference between a d20 and d21 is essentially usb. Difference between c20 and c21 is... CAN.
Da es Robodyn nicht mehr gibt, ist der STM32F303 für mich tot.
Bei den BlackPills ersetze ich
STM32F401CD -> STM32F412CE
STM32F401RC -> STM32F446RE
Und ich lerne auch jederzeit gern dazu, sonst würde ich hier ja nicht fragen, obwohl ich weiß, das hier gern gespottet und gelästert wird, daß man überhaupt keine Ahnung hat und sich einfach das Reference Manual anschauen muss...
Das Posten deines Quellcodes könnte bei der Fehlersuche helfen...
Wahrscheinlich käme dann heraus, dass er die Lizenbedingungen der Tools und Libraries von ST missachtet hat.
"This software package or any part thereof, including modifications and/or derivative works of this software package, must be used and execute solely and exclusively on or in combination with a microcontroller or a microprocessor devices manufactured by or for STMicroelectronics."
Wahrscheinlich käme dann heraus, dass er die Lizenbedingungen der Tools
und Libraries von ST missachtet hat.
Die sind doch alls kommerziell nutzbar.
Die auf Github veröffentlichen Projekte habe ich mir nicht näher angeguckt.
Könnte natürlich sein, dass die Copy-Paste-Programme sind.
Wenn ich es mit den Libraries von GD hinbekommen hätte, würde ich auch nicht fragen. Zu denen gibt es so gut wie keine Dokumentation und nur sehr wenig Beispielcode. Und selbst das Wenige habe ich nicht zum Laufen bekommen, lande selbst bei einfachen Blink Codes immer im hardfault handler :(
Grundsätzlich: der GD-Nachbau lädt den Code ins RAM und führt ihn von dort dann ohne Waitstates schneller aus als das STM-Original. Wenn der Code timingmäßig "so hingefrickelt" wurde, kann es sein, dass "schneller" einfach "zu schnell" ist und irgendwelche Raceconditions und Blokaden auftreten. BTDT.
Wenn das nur ein einzelnes Gerät für private Spielereien ist, würde ich ja kurzerhand einfach den GD32 per Heissluft raus- und einen richtigen STM32 reinmachen um meine Nerven zu schonen.
Wenn das keine private Spielerei ist, hätte ich da etwas Bedenken dabei, Code auf einen anderen µC zu werfen, bei dem ich nicht das Gefühl habe, den gut genug verstanden zu haben. (Zusätzlich zu der o.g. Lizenzproblematik.)
Das eigentliche Binary ist nur ca. 5 KByte groß (die ELF Datei ist dabei, das Binary kann man daraus erzeugen) und es werden kontinuierlich CAN Frames mit 1 MBit/s verschickt.
Auf einem STM32F103 funktioniert es und zum Testen ohne CAN Transceiver reicht es wenn PA12 (CANTx) mit PA11 (CANRx) verbunden ist (sonst passiert ohne CAN Transceiver nichts).
Warum der ST-Code nicht läuft, ist mir aber immer noch rätselhaft, ich habe noch mal die CAN Register überprüft und keine Unterschiede gefunden auch der CAN0 hat die gleiche Basisadresse wie der CAN1 bei ST...
STM liefert doch eine HAL mit, so dass man gar nicht an die Register muss.
Jedenfalls mache ich das bei SPI, I2C, USB und Ethernet.
Ich finde die STM HAL sehr hilfreich, weil sie einem die ganzen Bitspielereien erspart. So hat man fix einen lauffähigen I2C Master.
Gibt es keine entsprechende HAL bei GD32.. . So mit Beispielen und etwas Anwendungscode? Da muss es doch auch Hilfe für Einsteiger geben?
HAL ist doof???? Ist eine doofe Aussage, wenn man es selber auch nicht hin bekommt?
Ist eine doofe Aussage, wenn man es selber auch nicht hin bekommt?
Die Aussage sollte gewisse Experten hier davon abhalten, über die Verwendung der HAL Bibliotheken zu lästern, das kommt regelmäßig in solchen Threads ;)
Es ist angeblich viel einfacher, direkt in die Register zu schreiben, ist viel schneller in der Ausführung und spart Speicher.
Mag ja sogar richtig sein, wenn man das Reference Manual auswendig gelernt und verstanden hat.
GD hat für einige Prozessorfamilien HAL Bibliotheken, für den GD32F303 funktioniert aber leider weder die Code Generierung aus dem graphischen Tool zum Peripherie Setup, noch gibt es HAL Bibliotheken, siehe Screenshot.
Es gibt prozessorspezifische Peripheral Libraries, so dass man nicht selber in die Register schreiben muss.
Findet man alles zum Download auf der GD-Homepage. Und funktioniert alles sehr ähnlich der STM CubeIDE, genauso aufgesetzt auf Eclipse.
IDE und Peripheral Libraries:
https://gd32mcu.com/en/download/7?kw=GD32F3
Weder HAL, noch LL oder die Zugriffe auf Registerebene sind doof – man muss halt wissen, was wann sinnvoll ist, es einzusetzen und zu gebrauchen. Bei mir ist es ein Mix aus allen drei Bereichen und der Schwerpunkt liegt auf LL und Registerebene, aber den eigenen Schwerpunkt muss schon jeder selbst herausfinden oder entsprechend seiner Fähigkeiten setzen. Man sollte sich auch darüber im Klaren sein, dass sowohl HAL als auch LL – je nach IDE-Version – Fehler enthalten können, was in der Vergangenheit vorgekommen ist. Eigene Registerzugriffe können selbstverständlich auch fehlerhaft sein, vor allem dann, wenn man nicht weiß, wie man es nicht machen sollte – manche „Superhelden” verwenden z.B. Zahlen für Adressen und Bitzusammensetzungen, statt auf die zur Vefügung gestellten Definitionen zurückzugreifen. Der Gebrauch von eigenen Macros ist in diesem Zusammenhang auch wichtig, weil man den Code dann deutlich einfacher schreiben und – was noch wichtiger ist – besser lesen kann.
Vergleich_Register.JPG
(67 KB)
