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 ;)
Angehängte Dateien:
-
Vergleich_Register.JPG
67 KB
:
Bearbeitet durch User
Einen Moment, ich geh schnell Popcorn kaufen...
:
Bearbeitet durch User
heute ist anscheinend keine Vorstellung :-)
Wer billig kauft, kauft doppelt. 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?
Peter L. schrieb: > CAN läuft bei mir mit 1 Modul auf 103,303,405,412,413, 446. auf einem STM oder auf einem GD? Auf dem STM läuft es bei mir auch. Wenn es auf einem GD läuft, gibt es da einen Beispielcode? Wastl schrieb: > Wer billig kauft, kauft doppelt 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 ...
:
Bearbeitet durch User
Hochsitz C. schrieb: > 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: https://easyelectronics.ru/img/ARM_kurs/STvsGD/Migration/compatibility%20sumup%20between%20GD32%20and%20STM32_V2.0.pdf > Leider gibt es zu dem GD32F303RCT6 nur sehr wenige Codebeispiele und die > laufen ebenfalls nicht auf meiner Hardware (ein Bafang BLDC Controller) Müssen sie das? Wurde der Controller ohne Firmware ausgeliefert? Hochsitz C. schrieb: > Wobei der GD ja ein deutlicher Fortschritt ist gegenüber dem > STM32F103. 120MHz statt 72, M4 statt M3, Hardware FPU... Kein Wunder, denn du vergleichst Äpfel mit Birnen: xx32F1yy -> Cortex M3 xx32F3yy -> Cortex M4 (xx ∈ {STM, GD}) > 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 :)
Das mit den identischen Registern zum STM32F103 habe ich mir nicht ausgedacht, das kann man an verschiedenen Stellen lesen, z.B. hier: https://www.eevblog.com/forum/microcontrollers/psa-gd32f303-is-not-a-drop-in-substitute-for-stm32f303/ 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).
Hochsitz C. schrieb: > https://www.eevblog.com/forum/microcontrollers/psa-gd32f303-is-not-a-drop-in-substitute-for-stm32f303/ In dem Thread steht doch auch "RTFM". Warum sollten Quellcodes des einen Herstellers auf Controllern eines anderen "einfach so" funktionieren?
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...
:
Bearbeitet durch User
Hochsitz C. schrieb: > 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. Hochsitz C. schrieb: > 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. Hochsitz C. schrieb: > (currently tested: usb, adc, timer, dma, interrupts). Dann trifft die Aussage möglicherweise auch / wohl offensichtlich nicht auf die komplette Peripherie zu. Hochsitz C. schrieb: > 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...
Hochsitz C. schrieb: > 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.
Roland E. schrieb: > 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.
1. ich verwende nur STM-MCs. 2. in deinem Registervergleich ist ein CAN_CTL angegeben. Das kenne ich bei STM nicht. 3. was sagt der Debuger? 4. 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. 5. Da es Robodyn nicht mehr gibt, ist der STM32F303 für mich tot. Bei den BlackPills ersetze ich STM32F401CD -> STM32F412CE STM32F401RC -> STM32F446RE 6. Können die 120MHz für USB mit 2,5 geteilt werden?
Rahul D. schrieb: > Das Posten deines Quellcodes könnte bei der Fehlersuche helfen... https://github.com/stancecoke/BionX_Minimal_Translator/tree/BAFANG_Hubmotor_Controller Der Code läuft auf dem STM32F103. Ganz unbeschlagen bin ich der Materie nicht ;) 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...
:
Bearbeitet durch User
Hochsitz C. schrieb: > Ganz unbeschlagen bin ich der Materie nicht ;) Dann sollte dir der Umstieg ja eigentlich leichtfallen.
Rahul D. schrieb: > 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." https://www.st.com/content/ccc/resource/legal/legal_agreement/license_agreement/group0/eb/8e/f9/c1/9e/64/49/95/SLA0048/files/SLA0048.txt/jcr:content/translations/en.SLA0048.txt
:
Bearbeitet durch User
Nemopuk schrieb: > 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.
Nemopuk schrieb: > die Lizenbedingungen der Tools 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 :(
Rahul D. schrieb: > Die sind doch alls kommerziell nutzbar. Lies mal den von mir zitierten Absatz aus der Lizenz.
Hochsitz C. schrieb: > Zu denen gibt es so gut wie keine Dokumentation und nur > sehr wenig Beispielcode. Nun siehst du, warum die Chips von ST mehr Wert sind. Du bezahlst beim Kauf nicht nur die Hardware, sondern auch die Dokumentation und Tools.
Nemopuk schrieb: > Lies mal den von mir zitierten Absatz aus der Lizenz. Hättest du früher posten müssen... Punkt 4 ist schon mal verletzt, wenn man STM-Software auf anderen Controllern laufen lassen will... Zack! Abmanung ist raus! Kommerziell darf man sie trotzdem verwenden...Sonst wären STM-Controller ziemlich schnell von der Bildfläche verschwunden.
:
Bearbeitet durch User
Hochsitz C. schrieb: > Und ich lerne auch jederzeit gern dazu, 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.
Um auszuschließen dass es an Unterschieden beim GD32 liegt: hast Du schon versucht den Code auf einem STM32F303 zum Laufen zu bringen?
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.)
Dieter S. schrieb: > auf einem STM32F303 zum Laufen zu bringen Das macht ja keinen Sinn, der GD32F303 ist eben kein Clone des STM32F303, sondern ein aufgemotzter F103. Siehe meinen Link weiter oben. Ich werde berichten, wenn ich mit dem Thema weiterkomme.
Du könntest es eventuell mit dem hier ausprobieren: https://github.com/embeddedalpha/STM32F103_CAN_Project 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).
:
Bearbeitet durch User
Ich habe es jetzt mit dem GDEmbeddedBuilder hinbekommen, so hingebogen, daß der STLink zum Flashen und Debuggen direkt aus der Anwendung läuft. https://github.com/stancecoke/BAFANG_HUB_GD32F303RCT6 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?
Angehängte Dateien:
-
Screenshot.JPG
140 KB
Peter schrieb: > 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 Beispiele: https://gd32mcu.com/en/download/8?kw=GD32F3
:
Bearbeitet durch User
Peter schrieb: > HAL ist doof? 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.
:
Bearbeitet durch User
Lothar M. schrieb: > 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. Dann wäre doch ein Ansatz auf 72 Mhz zu takten.
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.