Hallo, hat jemand schon Erfahrungen mit z.B. GD32E230 gesammelt? Ich würde den gerne in einem neuen Design einsetzen weil er einen 2 MSPS ADC hat und eine neue Energie-effiziente Architektur. Und 90 Cent als Einzelstück ;) Die Dokumentation gibt es unter http://gd32mcu.21ic.com/documents Dort vermisse ich ein praktisches Tool wie das STM32CubeMx. Ich habe keine Lust das Ding zu initialisieren wie ein Tier aus dem Wald. Ist der GD32E230 auch mit einem äquivalenten Typ von ST zu initialisieren? Bei denen habe ich nichts mit Cortex-M23 Architektur gefunden. Unter https://smdprutser.nl/blog/stm32f103-vs-gd32f103/ gibt es Hintergrundinfos zu der Entstehungsgeschichte des STM32F103 Clones und warum das Ding 0 Waitstates hat. Unter https://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices sieht man hübsche Die Shots
Ist das ein kommerzielles Design? Traust Du einem Chinesen eine Lieferfähigkeit von mehr als 3 Jahren zu? fchk
Anon Y. schrieb: > Dort vermisse ich ein praktisches Tool wie das STM32CubeMx. Darum kostet der auch nur 90 Cent / Stück :-) Ich würde die Finger davon lassen, vor allem für ein komerzielles Projekt.
Frank K. schrieb: > Ist das ein kommerzielles Design? Traust Du einem Chinesen eine > Lieferfähigkeit von mehr als 3 Jahren zu? Das ist ein kommerzielles Design, aber auch ein Versuchsballon und Kleinserie. Also eine extrem gute Situation für mich :) Die Lieferfähigkeit ist nicht kritisch. Das Layout kann jederzeit geändert werden.
Random .. schrieb: > Anon Y. schrieb: >> Dort vermisse ich ein praktisches Tool wie das STM32CubeMx. > > Darum kostet der auch nur 90 Cent / Stück :-) > > Ich würde die Finger davon lassen, vor allem für ein komerzielles > Projekt. Ja das ergibt Sinn, auch wenn ich das nicht hören wollte. Preis bei 100 Stück ist übrigens eher 50 Cent: https://lcsc.com/search?q=gd32e230
Beitrag #5968929 wurde von einem Moderator gelöscht.
Anon Y. schrieb: > Preis bei 100 Stück ist übrigens eher 50 Cent: Das ist bei einer Kleinserie doch wurscht. Auf der einen Seite redest Du vom E230, verlinkst aber Testberichte zum F103 kompatiblen Typ. Nicht Äpfel mit Birnen vergleichen! > Ich würde den gerne in einem neuen Design einsetzen weil er einen 2 MSPS > ADC hat Wenn das Dein ausschlaggebenes Argument ist: ein STM32G071 bietet 2,5 MSPS. Die Entwicklungsumgebung ist die gewohnte von STM. > Ich habe > keine Lust das Ding zu initialisieren wie ein Tier aus dem Wald. Das kann somit entfallen ;-)
m.n. schrieb: > Das ist bei einer Kleinserie doch wurscht. > Auf der einen Seite redest Du vom E230, verlinkst aber Testberichte zum > F103 kompatiblen Typ. Nicht Äpfel mit Birnen vergleichen! Das ist eher ein Versuch, ob es möglich ist. Erfahrungsberichte würden mir helfen. Und weniger Kosten sind immer schön - wenn die Entwicklungszeit gleich bleibt. Der Link auf den GD32F103 Clone war damit Mitleser einschätzen können, was das ist und worüber gesprochen wird. Ich weiß z.B. dass die STM32 stattliche Errata haben und die ersten Revisionen nur schwer benutzbar waren. Wieviel mehr Kopfschmerzen handel ich mir mit Giga Devices ein?
Bei einer Kleinserie werden nach meiner Schätzung 80% der Projektkosten Entwicklungskosten sein, und nur 20% Stückkosten. Es ist daher völlig kontraproduktiv, auf geringe Produktionskosten zu optimieren. Was Du brauchst, ist ein guter Herstellersupport, gute Lieferfähigkeit und gute Dokumentation. Ich verwende in vielen Projekten PICs - alles querbeet von 6-Pinnern bis hin zu dicken PIC32MZ. Microchip hat seine Eigenarten, aber eines muss man ihnen lassen: Ich kann heute noch problemlos 25 Jahre alte PIC16-Typen kaufen. Sie haben nie irgendwas abgekündigt. Manchen Kunden ist es wichtig, dass sie Designs 20 Jahre lang unverändert fertigen lassen können, weil auch kleinste Änderungen eine komplette Neuqualifizierung nach sich ziehen würden. Ja, da zahlt man für einen aktiken 8-Bitter mehr als für einen aktuellen 32 Bitter, aber der Kunde hat das für sich durchgerechnet und will das so. Nur aus diesem Grund gibts überhaupt noch ATMEGA8, 8L und 8A als separate Produkte, plus ATMEGA88, 88A und 88PA, vom 88PB ganz zu schweigen. Mit Chinesen habe ich so meine speziellen Erfahrungen. Schon bei so banalen Sachen wie TL431. Ich hatte da Boards, die mit TL431 in SOT23 von TI, NXP und Diodes problemlos funktionierten, mit irgendwelchen Chinateilen aber nicht mehr. In meiner Verzweiflung habe ich dann TL431 in SOT363 eindesignt, weil da die Einkäuferin, die auf dem Gemüsemarkt in Shenzhen die Teile besorgt hat, da westliche Ware kaufen musste. Die haben bei den üblichen Kondensatoren 10nF und 100nF in 0402 recyclete Teile gekauft. Nicht wegen Umweltschutz, sondern weil die 6000'er Rolle dann ein paar Cent billiger war. Und Chef hat sich gewundert, warum die CR1610 Uhrenbatterien bei den Prototypen mit Teilen von Digikey Jahre hielten, bei den Serienboards aber innerhalb von 2 Monaten leer waren. Falsch gelabelte oder leere Bauteile (also quasi nur Gehäuse ohne was drin) hatte ich auch schon gehabt. Meine Lehren daraus: Wenn ich kann, mache ich um Chinesen den größtmöglichen Bogen. fchk
Anon Y. schrieb: > Ich habe > keine Lust das Ding zu initialisieren wie ein Tier aus dem Wald. Zieh Dir das .svd und die Beispielcodes. Da ist Startup code für Keil drin den kannst Du nach gcc portieren oder nimm nen Startup für STM32 und änder die Sachen die geändert werden müssen. Linkerscript ebenso. SystemInit() wird mitgeliefert, also diesen harten Brocken musst Du eigentlich nicht anfassen, das kann man direkt verwenden und dann gibts noch die Examples die man auch irgendwo auf deren Seite runterladen kann. Das ist nichts für Anfänger (es sei denn sie sind sehr zäh) aber danach ist man mit einigen Sachen per Du von denen man vorher nicht mal wußte das sie überhaupt existieren. Für einen fortgeschrittenen Bare-Metaler der schon eine Handvoll Cortexe am Gürtel hängen hat ist das allerdings keine große Herausforderung, von so jemandem erwarte ich ein lauffähiges Blinky in deutlich weniger als 4 Stunden und da hat der noch Zeit gemütlich ne Kanne Kaffe zu trinken. Problematisch ist momentan immer noch für einige GD32-Typen die kein exaktes STM32-Gegenstück haben der Umgang mit dem J-Link, da muss man eventuell noch tricksen, aber wenn man es hinbekommt geht es gut. Einige von deren .svd-Dateien sind nicht wohlgeformt, das hindert den Registerbrowser von GNU-MCU-Eclipse daran irgendwas anzuzeigen. Beim GD32F350 zum Beispiel waren 2 überflüssige Leerzeichen ganz am Anfang, die mussten weg, dann gings.
:
Bearbeitet durch User
Frank K. schrieb: > Ich hatte da Boards, die mit TL431 in SOT23 > von TI, NXP und Diodes problemlos funktionierten, mit irgendwelchen > Chinateilen aber nicht mehr. Danke für deinen Erfahrungsbericht. Das habe ich nicht bedacht. Teilweise funktionieren wäre für mich viel schlimmer als gar nicht funktionieren. Bei ST bekomme ich dafür Support, bei Giga Devices nichts. Bernd K. schrieb: > Problematisch ist momentan immer noch für einige GD32-Typen die kein > exaktes STM32-Gegenstück haben der Umgang mit dem J-Link, da muss man > eventuell noch tricksen, aber wenn man es hinbekommt geht es gut. > > Einige von deren .svd-Dateien sind nicht wohlgeformt, das hindert den > Registerbrowser von GNU-MCU-Eclipse daran irgendwas anzuzeigen. Beim > GD32F350 zum Beispiel waren 2 überflüssige Leerzeichen ganz am Anfang, > die mussten weg, dann gings. Genau so etwas habe ich befürchtet. Das bekomme ich zwar hin, aber es kostet am Ende immens Zeit wenn man sich an einer Stelle fest gefressen hat. Ich bin da schon bei einem Chinesischen ADC von Nuvoton auf die Nase gefallen, weil das Ding sich nicht so verhält wie im Datenblatt beschrieben. Da werde ich wohl tatsächlich die Entwicklungszeit vs. Produktkosten scharf durch rechnen müssen. Danke!
Wenn dir die Headerdateien nicht gefallen und du dein Projekt komplett ohne DriverLib aufziehen willst, baue dir selbst ein CMSIS konformes Headerfile mit SVDConv: SVDConv.exe Device.svd --generate=header
:
Bearbeitet durch User
Random .. schrieb: > Wenn dir die Headerdateien nicht gefallen und du dein Projekt komplett > ohne DriverLib aufziehen willst, baue dir selbst ein CMSIS konformes > Headerfile mit SVDConv: > > SVDConv.exe Device.svd --generate=header Dann muss er die SystemInit() neu schreiben denn die passt nur zu deren komischen mitgelieferten Headern. Und auch deren Beispielcode wird nicht mehr gehen. Ich habs mal nen Tag lang probiert, bin dann aber entnervt wieder zurück. Schließlich ist die ganze Peripherie im chaotischen STM32-Stil gehalten und deshalb extrem schmerzhaft auf Registerebene zu programmieren. Dazu mommt noch daß deren svd ein altes Format ist das noch nicht mehrere Instanzen für identische Peripherie kennt. Da wird dann das gleiche Bit x mal definiert, jededmal unter einem anderen Namen. Das ist alles ein riesengroßer inkonsequenter halbgarer Krampf. Freiwillig würde ich nur die zu STM32 100% binärkompatiblen von GD32 nehmen und dann 100% mit STM32 Headern und Libs arbeiten.
:
Bearbeitet durch User
Bernd K. schrieb: > Freiwillig würde ich nur die zu STM32 100% binärkompatiblen von GD32 > nehmen und dann 100% mit STM32 Headern und Libs arbeiten. Das ist auch mein Fazit. Den Cortex-M23 werde ich nur nehmen, wenn ich viel Zeit habe.
Der GD32E230 ignoriert das SYSRESETREQ Bit. Das hat zur Folge daß nvic_system_reset() bis zum St.-Nimmerleinstag (oder bis zum Watchdog) in der Endlosschleife wartet. Und ob wenigstens der Watchdog funktioniert, das hab ich noch nicht getestet. Wer also beabsichtigt per Software einen Reset auslösen zu können (zum Beispiel um auf Kommando in einen Bootloader zu springen oder dergleichen) sollte hier hellhörig werden. Ebenso gibt es aus diesem Grunde leichte Unregelmäßigkeiten oder WTF-Momente beim Debugging mit J-Link, man wundert sich zum Beispiel daß beim Neustart aus der IDE heraus die Peripherie nicht zurückgesetzt wird. Wer den unbedingt einsetzen will sollte also auf jeden Fall den Reset-Pin an seinem SWD-Anschluss nicht aus Platzgründen wegrationalisieren und die Resetstrategie des J-Link explizit auf 2 stellen (default ist nur SYSRESETREQ).
Kommando zurück, hat sich erledigt, auf dem Board war ein Schluss zw. Reset und Vcc. Softwarereset geht jetzt.
Wenn es noch aktuell ist. Das betrifft zumindest F103 und F130. Viele übersehen in der Doku den Satz: Für F103: «No waiting time within first 256K bytes when CPU executes instructions. A long delay when CPU fetches the instructions out of the range.» Für F130: «No waiting time within first 32K bytes when CPU executes instructions. A long delay when CPU fetches the instructions out of the range.» Aus meiner Erfahrung mit den beiden: "A long delay" ist noch untertrieben. Der Code aus den langsamen Bereichen ist SEHR langsam. Zum Beispiel, meine Terminalunterstüztung (über UART) im Programm für ST32F051K8 ist im oberen Bereich vom Flash gelandet. Das führte dazu, dass bei GD32F130K8 die Zeilenausgabe auf das Terminal mit 115200bps gefühlsmässig wie mit 1200bps läuft: langsam Zeile für Zeile, während der selbe Code auf dem ST32F051K8 bei der Terminalausgabe so schnell ausgibt, dass die ganze Seite vom Text einfach augenblinklich komplett erscheint. Mein Fazit: die obigen Serien von GD nur dann nutzen, wenn der Code nicht grösser als die Hälfte vom Flash ist bzw. wenn der obere Bereich nur für irgendwelche Einstellungen á la EEPROM verwendet wird.
Nur mal kurz ein Reality-check.. nur STM scheint hier das Wahre zu sein.. Was ist mit den anderen Herstellern? TI? AD?, NXP?, ... Benutzt Ihr die Alle mit STM Software?? Gruß, Pille
Was ist unter STM Software gemeint? Während Cortex M0, M3 und M4 Architekuren von den genannten Herstellern angeboten werden, wird die Firmware nicht interoperabel sein, weil die Produkte sich in der Peripheriearchitektur sehr unterscheiden. Wenn es STMCubeIDE gemeint ist, konnte ich darunter auch mit GD32F103 arbeiten/debuggen. Man muss nur an einer bestimmten Stellen eine Konfigurationsdatei modifizieren, damit die IDE nicht auf STM-Zugehörigkeit des Prozessors prüft. Ob unter STMCubeIDE die Geschwister von TI, NXP, etc.... laufen würden, habe ich nicht ausprobiert.
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.