Hört sich interessant an: https://www.heise.de/newsticker/meldung/5-Dollar-Entwicklerboard-mit-RISC-V-Sipeed-Longan-Nano-4509949.html Habe die Headline hier nocht nicht gesehen. Falls übersehen, bitte löschen.
:
Bearbeitet durch User
Wurde in dem längeren Thread hier gepostet (ist leider ein bisschen im Rauschen untergegangen): Beitrag "Re: RISC-V: Wird das was?"
Wo mit programmiert man den? Was für ein Debugger benutzt man dann?
Der JLink kanns wohl. Ist jetzt nur die Frage obs die EDU Version auch kann.
Aus gewöhnlich gut unterrichten Kreise verlautbarte, dass es auch eine Version der IAR Embedded Workbench für diese Architektur gibt.
Wer nutzt denn freiwillig den IAR? Muss ich auf Arbeit nutzen den Müll von v7 auch v8 ist das ding NOCH SCHLECHTER geworden. Keine Ahnung wie die das geschafft haben, ich dachte echt das geht nicht mehr!
Ich habe in dem langen Thread nachgefragt ob den schon einer bestellt hat. Leider reagiert da keiner, die diskutieren am Thema vorbei. Laut Beschreibung soll der auch mit der Arduino IDE zu gebrauchen sein.
homa schrieb: > Ich habe in dem langen Thread nachgefragt ob den schon einer bestellt > hat. Leider reagiert da keiner, die diskutieren am Thema vorbei. Wenn Du den Status der Homepage die letzten Tage verfolgt hast, wird Dir aufgefallen sein, dass sich die "Estimated availability" von August über September bis aktuell 9. Oktober verschoben hat. Ob das nun bedeutet, dass die Teile weggehen wie warme Semmeln oder die Produktion noch Schwierigkeiten macht, kann ich nicht sagen. Ich werde bestellen, aber erst, wenn das Teil im Shop zu haben ist. Vorbestellen ist nich mein Ding. > Laut Beschreibung soll der auch mit der Arduino IDE zu gebrauchen sein. Ja, Sipeed wird die entsprechende Software zur Verfügung stellen.
Ich habe mich mal bei www.seeedstudio.com registriert. Zusatz Kosten Port in $ SZ POST (20-30 Tage) 8,57 bzw bei 2 Stück dann 9,05 etc. DHL 21,50 (1-3 Tage) Hat wer Interesse an einer kleinen Sammelbestellung (max 5 Stück) wegen der Freigrenze?
Ich habe gestern zwei bestellt, schauen wir mal, einen gebe ich weiter. Versprechen tue ich mir von den Dingern erstmal nix, das ist eher Neugier. Aber im Grunde sind die Dinger von dem was ich hier mitbekommen habe nur STM32 mit einem Risc-V Core. Und der Core ist in aller Regel das Letzte um das man sich kümmern muss, zumindest solange man da einen C-Compiler drauf wirft und in etwa weiss was man dem Core zumuten kann. homa schrieb: > Hat wer Interesse an einer kleinen Sammelbestellung (max 5 Stück) wegen > der Freigrenze? Welche Freigrenze soll das sein? Mehrwersteuer ist bis 22 Euro nicht zu entrichten, das ist aber Warenwert plus Versand. Zoll wird ab 150 Euro zusätzlich fällig. Zumindest ist das in Deutschland so, das Land hast Du ja nicht genannt. https://www.zoll.de/DE/Fachthemen/Zoelle/Zollbefreiungen/Aussertarifliche-Zollbefreiung/Sendungen-mit-geringem-Wert/sendungen-mit-geringem-wert_node.html
homa schrieb: > Laut Beschreibung soll der auch mit der Arduino IDE zu gebrauchen sein. Das heißt in China nicht viel. Ich habe schon öfters solche Versprechungen gelesen, um dann festzustellen, dass wahlweise - Es nur einen unfertigen Core für eine veraltete Arduino Version gab - Der Core praktisch nichts unterstützt, außer millis() und digitalRead/digitalWrite - Gar kein Core existiert, man könnte aber theoretisch einen anderen verwenden, patchen und mit einem nicht dafür vorgesehenen Compiler kombinieren Die Hersteller sind teilweise so dreist, dass sie "Arduino kompatibel" schreiben, sobald ein leeres Programm compilierbar ist. Bevor du dich da in Unkosten stürzt, prüfe nach, was wirklich verfügbar ist. Die richtige Anlaufstelle ist vermutlich hier: https://github.com/stm32duino/Arduino_Core_STM32 Vom GD32 steht da aber nichts mehr. Das ist komisch, denn deren Plugin heißt in der Arduino IDE "STM32F1xx/GD32F1xx boards". Vielleicht hängt es damit zusammen, dass das ganze Projekt von ST übernommen wurde.
Stefanus F. schrieb: > Die richtige Anlaufstelle ist vermutlich hier: > https://github.com/stm32duino/Arduino_Core_STM32 Du wirst wohl noch den Startup-Code austauschen müssen, Systeminit evtl. auch, alle Funktionen die irgendwo NVIC und andere Funkionen aus core_* nutzen (und durch entsprechenden RISC_V code ersetzen), und schlussendlich (eigentlich zuallererst) wird man auch irgendwo konfigurieren müssen welchen Compiler das überhaupt verwenden soll. Früher oder später wird das irgendwer forken und entsprechend umbauen. Erst mal ein Bare Metal-Projekt ohne libs from scratch hochzuziehen wird wahrscheinlich einfacher sein, auch weil man dabei lernt was man alles mindestens braucht und was alles anders ist als bei ARM.
:
Bearbeitet durch User
Benedikt S. schrieb: > Wo mit programmiert man den? Was für ein Debugger benutzt man dann? Der Controller hat ein "normales" JTAG-Interface, weshalb man OpenOCD mit einem entsprechenden Debug-Adapter nutzen kann. Gigadevices selbst hat wohl einen ST-Link-Clon im Angebot, der als GD-Link vertrieben wird. Mit dem "originalen" ST-Link (Clone selbstverständlich eingeschlossen), sollte das aber auch gehen, so lange die JTAG-Leitungen herausgeführt sind (was sie bei den "Mini"-Modellen normalerweise nicht sind). Prinzipiell kann man aber auch ein Blue-Pill-Board als ST-Link betreiben, wenn denn wirklich Not am Mann sein sollte: https://hackaday.io/project/158262-using-blue-pill-stm32f103c8t6-as-st-link Ein J-Link funktioniert natürlich auch. Ansonsten bieten sich fürs programmieren die diversen internen Bootloader an, d.h. UART (z.B. mit stm32flash), USB-DFU, etc. GD bietet Platformio-Support, so dass man VS-Code oder Atom als Editor bzw. IDE nutzen kann: https://github.com/sipeed/platform-gd32v Die entsprechenden Frameworks werden dann automagisch heruntergeladen. Wer mal einen Blick drauf werfen möchte, ohne sich pio zu installieren, der möge mal hier schauen: http://dl.sipeed.com/LONGAN/platformio/dl-packages/ Dort findet sich auch eine Version von OpenOCD, die offensichtlich den GD32V unterstützt.
Christopher J. schrieb: > Dort findet sich auch eine Version von OpenOCD, die offensichtlich den > GD32V unterstützt. Wo sind die Quellen? OpenOCD ist GPL!
Soweit ich das verstehe sind alle RISC-V vom jtag her ident weil genau spezifiziert. Damit müsste der openocd aus dem risc-v repo funktionieren: https://github.com/riscv/riscv-openocd Ansonsten scheint es auch schon einen gdb-stub zu geben den man einfach in sein projekt integriert. Also geht debuggen ohne debugger auch :) 73
Hans schrieb: > Soweit ich das verstehe sind alle RISC-V vom jtag her ident weil genau > spezifiziert. Wenn sie stattdessem cJTAG drauf gemacht hätten wäre es attraktiver und würde besser zu existierenden Adapterkabeln mit reduzierter Pinzahl passen.
:
Bearbeitet durch User
Bernd K. schrieb: > Wo sind die Quellen? OpenOCD ist GPL! Gute Frage. Ich hab im Repo von Sipeed mal ein Issue aufgemacht. Hans schrieb: > Damit müsste der openocd aus dem risc-v repo funktionieren: > > https://github.com/riscv/riscv-openocd Ich bin mir nicht sicher ob es geht. PlatformIO greift lediglich auf zwei custom-Scripte zurück, je nachdem ob J-Link oder GD-Link gewählt wurde. Ich habe sie mal angehängt. Witzigerweise firmiert der GD-Link in OpenOCD als "CMSIS-DAP" :D Die Problematische Zeile ist aber diese hier:
1 | flash bank $_FLASHNAME gd32vf103 0x08000000 0 0 0 $_TARGETNAME |
Das heißt nämlich, dass "gd32vf103" als flash-driver registriert sein müsste und ein solcher ist im riscv-openocd Repo nirgends erwähnt (egrep -R gd32 liefert nichts zurück).
Bernd K. schrieb: > Hans schrieb: >> Soweit ich das verstehe sind alle RISC-V vom jtag her ident weil genau >> spezifiziert. > > Wenn sie stattdessem cJTAG drauf gemacht hätten wäre es attraktiver und > würde besser zu existierenden Adapterkabeln mit reduzierter Pinzahl > passen. Willst du diesen Thread jetzt auch hijacken? Lies bitte einmal die doku die man so per google findet. https://wiki.segger.com/RISC-V:
1 | There is draft debug standard defined by the RISC-V foundation. However, |
2 | this debug standard defines only JTAG, no cJTAG or SWD access and is not |
3 | followed by every vendor See https://github.com/riscv/riscv-debug-spec |
https://github.com/riscv/riscv-debug-spec/releases/download/task_group_vote/riscv-debug-draft.pdf :
1 | To make it easy to acquire debug hardware, this spec recommends a connector that is compatible |
2 | with the MIPI-10 .05 inch connector specification, as described in the MIPI Alliance Recommendation for Debug and Trace Connectors, Version 1.10.00, 16 March 2011. |
3 | ... |
4 | The same connectors can be used for 2-wire cJTAG. In that case TMS is used for TMSC, and TCK is used for TCKC. |
jedenfalls scheint SiFive cjtag optional für ihren core anzubieten (https://cdn2.hubspot.net/hubfs/3020607/SiFive%202%20Series%20RISC-V%20Core%20IP%20-%20Webinar%20May%2015.pdf). Das dürfte Giga Devices einfach (noch) nicht haben. Im Forum der Debug-Gruppe hat Segger selbst auch interessantes gepostet. https://groups.google.com/a/groups.riscv.org/forum/#!topic/debug/755eoMvbHC0
1 | SWD should be possible when having also an ARM core in the same chip. |
2 | If it is possible for designs with RV only is something that ARM can answer better... |
3 | I am not sure regarding their licensing schemes. |
4 | As most went for cJTAG, it sounds a bit like that either the licensing scheme does not match or nobody really knows and they wanted to be on the safe side :) |
Im übrigen dürften deinen Aussagen nach für deine Anwendung diese chips ohnehin nicht passen (kein platz vs. riesen package)... Also mach's doch einfach wie ich: Einige Monate warten bis es die Chips und Dev-Boards auch wirklich zu kaufen gibt und dann einmal in aller Ruhe das Ecosystem bewundern. Bis dann auch wirklich ein neues Design zu machen ist, hat sich am µC Markt ohnehin alles verändert durch die üblichen An/Abkündigungswellen. Wenn ich die Presseaussendungen über den RISC-V mit ein bischen Abstand betrachte, dann dürfte sich zumindest NXP und Microchip relativ ernsthaft mit dieser Architektur beschäftigen. Zumindest Microchip hätte propritäre Debug Lösungen. Wenn ich deine Aussagen richtig interpretiere, dann wäre z.B. debugWIRE in einem RISC-V für dich noch "besser" als SWD oder zumindest eine testenswerte Alternative. Ich glaube es heißt gerade abwarten und beobachten. 73
Hans schrieb: > Wenn ich deine Aussagen richtig interpretiere, dann wäre z.B. debugWIRE > in einem RISC-V für dich noch "besser" als SWD oder zumindest eine > testenswerte Alternative. Auf jeden Fall. Wenn der dann auch von J-Link unterstützt würde (sehr wahrscheinlich) dann wäre das prächtig.
Ansaetze fuer RiscV gibt es auch fuer die Blackmagic Debug Probe: https://github.com/blacksphere/blackmagic/pull/292 Mit einem libftdi Adapter laesst sich dann gut auf einem PC testen und der Debugger weiterentwickeln.
Also verschickt hat Seeed-Studio meine 2 Exemplare jetzt, mal schauen ob der Fahrrad-Kurier bis Weihnachten hier ist.
Mittlerweile gibt es das Teil auch bei Aliexpress: https://www.aliexpress.com/item/4000221852639.html
... die Arduino API scheint im Entstehen begriffen: https://github.com/sipeed/Longduino Immerhin, die SPI Schnittstelle gibt es schon.
Meine beiden Boards sind gerade angekommen. Die Software da drauf macht schon mal nicht viel, das Display ist nur eine übergroße weiße LED und da drunter blinkt eine RGB LED. Am USB ist direkt erstmal nichts zu sehen. Wenn man den Boot-Taster gedrückt hält und dann den Reset-Taster betätigt, dann taucht ein unbekanntes USB Gerät auf.
Rudolph R. schrieb: > Am USB ist direkt erstmal nichts zu sehen. > Wenn man den Boot-Taster gedrückt hält und dann den Reset-Taster > betätigt, dann taucht ein unbekanntes USB Gerät auf. Ich gehe mal davon aus, dass das der USB-DFU Bootloader ist. Könntest du ja mal mit dfu-util testen ob da was kommt. PS: Da war der Fahrradkurrier aber flott unterwegs von Hong-Kong nach Deutschland ;)
Bisher bekomme ich nicht mal ein gültiges USB Device angezeigt mit den von Sipeed verlinkten Treibern.
Rudolph R. schrieb: > Bisher bekomme ich nicht mal ein gültiges USB Device angezeigt mit den > von Sipeed verlinkten Treibern. Du musst ein Chinesisches Windows nehmen (eins von denen, die ohne Lizenz-Key beliebig lange auf beliebig vielen Rechnern laufen) :-)
Christopher J. schrieb: > Ich gehe mal davon aus, dass das der USB-DFU Bootloader ist. Könntest du > ja mal mit dfu-util testen ob da was kommt. In der Tat ... [45769.556196] usb 10-1: new full-speed USB device number 5 using ohci-pci [45769.724501] usb 10-1: New USB device found, idVendor=28e9, idProduct=0189, bcdDevice=10.00 [45769.724506] usb 10-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [45769.724509] usb 10-1: Product: GD32 0x418 DFU Bootloade [45769.724512] usb 10-1: Manufacturer: GDMicroelectronics [45769.724514] usb 10-1: SerialNumber: 䌳䩂 [45773.735485] usb 10-1: USB disconnect, device number 5
Okay, mit welchem USB Treiber genau? Ich bekomme nur nur die Meldung, dass das USB Gerät nicht erkannt wurde und in USB Tree Viewer steht: Connection Status: 0x02 (Device failed enumeration
Rudolph R. schrieb: > Okay, mit welchem USB Treiber genau? Das waren die Ausgaben vom Linux Kernel, wenn kein Treiber geladen wird. Der käme erst danach, aber solche Geräte werden unter Linux in der Regel mit libusb (Treiberlos) angesteuert. Unter Windows vielleicht auch - ist bei vielen Programmieradaptern so. Siehe http://stefanfrings.de/avr_tools/libusb.html
Rudolph R. schrieb: > Okay, mit welchem USB Treiber genau? Zadig ist dein Freund. Einfach mal unter http://dfu-util.sourceforge.net/ schauen und der Bedienungsanleitung für Windows folgen. Ist nicht sooo schwer.
Das Ding hat sich einfach nicht richtig am USB gemeldet, da konnte auch Zadig nichts machen. Aber nach gefühlt drölfhundertmal umstöpseln und die Taster drücken kam das dann doch einmal als "GD32 Device in DFU Mode" am USB hoch. Zadig drüber und jetzt bleibt das hoffentlich stabil so.
A. B. schrieb: > [45769.724512] usb 10-1: Manufacturer: GDMicroelectronics Haben die den STM32 Bootloader genommen und nur 2 Zeichen im Binary ausgetauscht damit der Descriptor die Länge nicht ändert weil sie keinen Sourcecode davon haben? Die Firma heißt "GigaDevice"! Anders als STM haben die eigentlich kein "Microelectronics" im Namen!
Bernd K. schrieb: > Haben die den STM32 Bootloader genommen und nur 2 Zeichen im Binary > ausgetauscht damit der Descriptor die Länge nicht ändert weil sie keinen > Sourcecode davon haben? Scheint so. https://www.youtube.com/watch?v=yMR45cZbvDw Ich würde sagen: Typisch chinesisch
Stefanus F. schrieb: > Bernd K. schrieb: >> Haben die den STM32 Bootloader genommen und nur 2 Zeichen im Binary >> ausgetauscht damit der Descriptor die Länge nicht ändert weil sie keinen >> Sourcecode davon haben? > > Scheint so. Youtube-Video "Die Prinzen - Alles nur geklaut (Official > Video) (VOD)" > > Ich würde sagen: Typisch chinesisch Andererseits: Wie haben die den dann auf RISC zum laufen bekommen? Und warum zum Teufel schreiben die dann nicht auch ihren eigenen Namen rein sondern den Namen von STM mit 2 geänderten Buchstaben? Das ist doch vollkommen absurd!??
:
Bearbeitet durch User
Bernd K. schrieb: > Andererseits: Wie haben die den dann auf RISC zum laufen bekommen? Vieleicht enthält der Chip neben dem RISC-V Kern noch einen verborgenen geklauten Cortex-M Kern extra nur für den Bootloader und andere geklaute Software. Zutrauen würde ich es ihnen, nachdem die Firma schon andere Chips und Dokumente von ST zu 95% kopiert hat.
Stefanus F. schrieb: > nachdem die Firma schon andere > Chips und Dokumente von ST zu 95% kopiert hat. Naja, die Dokumentation haben sie komplett neu geschrieben, auch die Register und die ganzen Bits heißen alle anders. Und manche Peripherie enthält subtile Änderungen und Zusatzfunktionen, als wären es neuere aufgebohrte Versionen davon. Also daß die 1:1 geklaut sind davon bin ich noch nicht 100% überzeugt, ich würde auch nicht verstehen warum STM die Füße stillhält und kein Sterbenswörtchen über den rosa Elefanten im Raum verlautbaren lässt, vielleicht kaufen die auch nur beide "zufällig" bei der selben IP-Core Bude ein. GigaDevice ist ja nun auch kein namenloser Hinterhof-Chinese sondern ein Milliardenkonzern!
:
Bearbeitet durch User
Okay, nachdem ich die anderen Beispiele gebaut habe und durch ergänzen von "upload_protocol = dfu" in der platformio.ini auch übertragen konnte, blinkte nur noch die rote LED, so entweder nativ oder mit Arduino drunter, je nach Beispiel. Ist etwas lästig jedesmal die beiden Buttons drücken zu müssen, aber nun ja, man könnte ja auch einen J-Link anschliessen. Dann habe ich mal versucht das hier zu bauen: https://github.com/sipeed/Longan_GD32VF_examples Da steht in der platformio.ini: [env:sipeed-longan-nano] platform = gd32v board = sipeed-longan-nano framework = gd32vf103_firmware_library Damit baut das nicht. Ändert man das aber in: [env:sipeed-longan-nano] platform = gd32v board = sipeed-longan-nano framework = gd32vf103-sdk upload_protocol = dfu baut es und wird übertragen. Und siehe da, es blinken erstmal alle drei LEDs und das Display ist an. Wenn man dann noch die beiden Dateien "bmp.bin" und "logo.bin" auf eine micro-SD Karte packt und in den seltsamen Sockel steckt, dann spielt das Board auch die Animation ab. :-) Per Default kommt das Longan Nano also mit dieser Software, nur ist die Software nicht schlau genug ohne Karte einen Hinweis zu geben. Schon nett, eine native Anwendung mit SPI, SD, UART und I/O und gebaut per GCC. Eigentlich müsste ich Longan mal mit EVE verkuppeln. :-)
Super, jetzt bin ich wieder zurück auf "USB Device wurde nicht erkannt".
Läuft ja echt stabil.
Edit: und da isser wieder.
------ String Descriptor 0 ------
bLength : 0x04 (4 bytes)
bDescriptorType : 0x03 (String Descriptor)
Language ID[0] : 0x0409 (English - United States)
Data (HexDump) : 04 03 09 04
....
------ String Descriptor 1 ------
bLength : 0x26 (38 bytes)
bDescriptorType : 0x03 (String Descriptor)
Language 0x0409 : "GDMicroelectronics"
:
Bearbeitet durch User
Stefanus F. schrieb: > Vieleicht enthält der Chip neben dem RISC-V Kern noch einen verborgenen > geklauten Cortex-M Kern extra nur für den Bootloader und andere geklaute > Software. Sorry aber das ist doch totaler Käse. GD ist offizieller ARM-Lizenznehmer: https://olimex.wordpress.com/2015/12/21/gd32f103rbt6-the-stm32-pin-to-pin-compatible-chinese-mcus-sample-test/ Bernd K. schrieb: > vielleicht kaufen die auch nur beide "zufällig" bei der selben IP-Core > Bude ein Das halte ich für sehr wahrscheinlich. Rudolph R. schrieb: > Eigentlich müsste ich Longan mal mit EVE verkuppeln. :-) Wer ist denn bitte EVE?
Christopher J. schrieb: > Sorry aber das ist doch totaler Käse. Natürlich ist das Käse. Ich dachte, der Scherz sei offensichtlich. Nächstes mal kennzeichne ich es besser.
Christopher J. schrieb: > Wer ist denn bitte EVE? Die FT8xx Reihe von FTDI, Embedded Video Engine, oder auch EVE. Wenn man nach "EVE FTDI" googelt findet man noch das "Maskottchen", ein Comic Nerd-Girl, so wie es aussieht hält Bridgetek davon aber wohl nicht viel.
Rudolf schrieb: >Super, jetzt bin ich wieder zurück auf "USB Device wurde nicht erkannt". >Läuft ja echt stabil. Bei den STM32F103 BluePills gab es manchmal das Problem eines zu wackeligen USB-Steckers. Außerdem hatten sie den Widerstand für die USB-Erkennung falsch gewählt. Bei den ESP32 gibt es hier im Forum irgendwo einen Thread, bei dem gezeigt wird, wie man einen Kondensator an die Platine lötet, damit man zuverlässig flashen kann. Vielleicht gibt es beim Longan ja ein ähnlich geartetes Problem.
Nett, das Beispiel unter https://github.com/sipeed/Longan_GD32VF_examples wurde schon gefixt, das ging jetzt echt fix. Jetzt baut das einfach so und zeigt ohne Karte "no card found!" in 5 Zeilen mit unterschiedlicher Farbe an.
Angehängte Dateien:
-
Longan_Nano_USB.png
120 KB
Der Programm-Upload läuft über DFU. Mit den LEDs kann ich spielen. Serial.print bekomme ich nicht hin. Es meldet sich kein Device am USB Port. Danke für jeden Hinweis.
ckuehnel schrieb: > Serial.print bekomme ich nicht hin. Es meldet sich kein Device am USB > Port. Schau mal an den RX/TX Pins vom UART.
Beitrag #5999368 wurde von einem Moderator gelöscht.
Wie ist jetzt das zusammendfassende Ergebnis: Ist es jemandem gelungen das Board zu programmieren? Ich habe mittlerweile auch eines. Am PC angesteckt, blinkt die On-Board-LED in mehreren Farben. Mit lsusb wird auf Ubuntu aber kein Gerät angezeigt.
Christoph M. schrieb: > Mit lsusb wird auf Ubuntu aber kein Gerät angezeigt. Ist doch logisch wenn keine Firmware drauf ist die den USB einschaltet und bedient. Versuch doch mal es im Bootloader-Modus zu starten.
>Ist doch logisch wenn keine Firmware drauf ist die den USB einschaltet >und bedient. Versuch doch mal es im Bootloader-Modus zu starten. Ahh ... ein sehr guter Hinweis. Ich drücke also zuerst den "BOOT"-Button und dann gleichzeitig den "Reset"-Button, lasse diesen dann los und danach den Boot-Button. Tata .... und siehe da, mit lsusb ergibt sich: [114696.868633] usb 1-2.2: Product: GD32 0x418 DFU Bootloade [114696.868642] usb 1-2.2: Manufacturer: GDMicroelectronics [114696.868651] usb 1-2.2: SerialNumber: 䌳䨸
Christoph M. schrieb: > [114696.868642] usb 1-2.2: Manufacturer: GDMicroelectronics Und da ist es wieder: Eine Firma namens "GDMicroelectronics" existiert überhaupt nicht. Es würde mich wirklich interessieren was die da geritten hat ihren eigenen Namen falsch zu schreiben.
:
Bearbeitet durch User
Hat das Board schon mal jemand unter Ubuntu mit der Arduino-IDE zusammen ans laufen gebracht? Bei mir meldet die Board-Installation: riscv-nuclei-elf-gcc ist für ihr Betriebssystem nicht verfügbar.
Bernd K. schrieb: > Es würde mich wirklich interessieren was die da > geritten hat ihren eigenen Namen falsch zu schreiben. Ist das nicht offensichtlich? Das kommt dabei heraus, wenn man eine Firmware klaut und mit dem hex-Editor manipuliert weil der Quelltext nicht vorliegt.
Bernd K. schrieb: > Die Firma heißt "GigaDevice"! Anders als STM haben die eigentlich kein > "Microelectronics" im Namen! Bernd K. schrieb: > Und da ist es wieder: Eine Firma namens "GDMicroelectronics" existiert > überhaupt nicht. Es würde mich wirklich interessieren was die da > geritten hat ihren eigenen Namen falsch zu schreiben. Kann auch sein, dass der Entwickler des Bootloaders es schlicht nicht besser wusste und halt das eingetragen hat, was er für passend gehalten hat. Ich glaub, sowas wird in China auch oft nicht so genau genommen wie bei uns. Laut Datenblatt des µC heißen sie übrigens GigaDevice Semiconductor Inc.
Leider weicht der Bootloader von der DFU SpezifiKation ab, so dass man modifizierte DFU-Utils braucht.
Uwe B. schrieb: > Leider weicht der Bootloader von der DFU SpezifiKation ab, so dass man > modifizierte DFU-Utils braucht. Das war beim Maple Bootloader auch schon so. Funktioniert denn die Maple Software mit dem GD32?
Stefan F. schrieb: > Ist das nicht offensichtlich? Das kommt dabei heraus, wenn man eine > Firmware klaut und mit dem hex-Editor manipuliert weil der Quelltext > nicht vorliegt. Ja aber welche Firmware soll das sein? Seit wann stellt STMicroelectronics RISC-V Prozessoren her?
Mw E. schrieb: > Der JLink kanns wohl. > Ist jetzt nur die Frage obs die EDU Version auch kann. Hab folgendes beim Googlen gefunden: https://wiki.segger.com/SiPeed_Longan_Nano Hab es mal mit meinem J-Link EDU probiert und dem Hello World sample vom Wiki in Embedded Studio und funktioniert alles soweit. Scheint also keine Limitierung für RISCV und EDUs zu geben (wäre auch irgendwie eigenartig). Hab mir jez noch ein J-Link EDU Mini mal bestellt für knapp 20 € und wollte den im Vergleich mal testen.
Meiner Jlink v 9.3 kann keinen RISCV ansprechen... nur V10 schafft es :(
Ale schrieb: > Meiner Jlink v 9.3 kann keinen RISCV ansprechen... nur V10 schafft es :( Stimmt. Steht aber auch im Wiki Artikel welche Hardwarereveision RISC-V supportet.
>Stimmt. Steht aber auch im Wiki Artikel welche Hardwarereveision RISC-V >supportet. Da fällt mir "per Anhalter durch die Galaxis" ein: "Mit dem Bau der Hyperraum-Umgehungsstraße waren die Vogonen beauftragt. Für dieses ehrgeizige Projekt musste leider die Erde gesprengt werden. Die Pläne für die Hyperraum-Expressroute lagen 50 Erdenjahre in dem für die Erde zuständigen Planungsamt auf Alpha Centauri aus, so dass genug Zeit für eine formelle Beschwerde gewesen wäre. Doch die Erdlinge kümmerten sich nicht darum, obwohl es doch nur vier Lichtjahre entfernt liegt."
Ale schrieb: > Meiner Jlink v 9.3 kann keinen RISCV ansprechen... nur V10 schafft es :( Was ist anders an der Hardware? Ich dachte es ist JTAG? @SEGGER, bitte erklären!
:
Bearbeitet durch User
Ich hab mir ein sipeed rv debugger zulegen müssen, und damit hat programmieren geklappt. Ich musste den Treiber aber erst auf WinUSB umtauschen, dafür habe ich Zadig 2.4 nutzen müssen.
Gibt es eigentlich ein vordefiniertes Symbol für den Controller? Ein Test auf __GD32VF103VBT6, _GD32VF103VBT6_ oder GD32VF103CBT6 funktioniert schon mal nicht. Es gibt zwar __riscv, das ist mir aber schon ein wenig zu generisch. Aber der RISCV GCC aus dem PlatformIO Package wirft erstmal nichts besseres aus.
Meine Güte, gibt es jetzt eigentlich schon eine Lösung für das Problem mit dem USB? In den DFU Modus zu kommen scheint reiner Zufall zu sein.
Angehängte Dateien:
Ein Arbeitskollege hat sich jetzt auch Longan Nano bestellt und kam damit nicht weiter. Jetzt habe ich den hier zu Hause und mal versucht die Blink-Beispiele da drauf zu spielen. Beim Upload passiert immer das hier: --- Download [=========================] 100% 8268 bytes Download done. File downloaded successfully Error during download get_status *** [upload] Error 74 --- Und die LED blinkt nicht, auch nicht nach einem Reset oder abklemmen des USB-Steckers. Mit meinem älteren Modell sieht das so aus: --- Download [=========================] 100% 8268 bytes Download done. File downloaded successfully Transitioning to dfuMANIFEST state --- Und läuft dann einfach. Google brachte mich dann noch auf die Idee, es könnte sich um einen " sipeed-longan-nano-lite" lite handeln, dagegen spricht aber, dass wie bei meinem älteren Exemplar der Controller mit "...103CBT6" beschriftet ist. Auf jeden Fall führt für den "sipeed-longan-nano-lite" zu compilieren zu dem gleichen Ergebnis - läuft nicht. Die beiden Platinen sind leicht unterschiedlich. Hat Sipeed die Platine kaputt optimiert? Der neue wird ja wohl eher kein defekter Clone sein, so bei den Preisen.
Bei mir gleiches Problem, hab den Longan Nano letzte Woche bei Antratek gekauft. Download scheint zu gehen (abgesehen von "Error during download get_status"), aber dann passiert nix mehr. Vor dem ersten Flashen hat die RGB-LED aber noch munter geblinkt. Haben sie evtl. die Anschlüsse der LED geändert? Oder die aktuelle PlatformIO-Version ist kaputt? Es blinkt aber weder mit der Arduino- noch mit der gd32v-Plattform.
:
Bearbeitet durch User
Hab eben das hier gefunden: https://github.com/sipeed/platform-gd32v/issues/17#issuecomment-579270512 das hilft! (Verwenden des "offiziellen" dfu-util, wo der Patch https://sourceforge.net/p/dfu-util/dfu-util/ci/f2b7d4b1113ef6c3ada31a0654c9aefebcdb1de5/ schon drin ist) Jetzt blinkts endlich wieder! Gibt wohl verschiedene Chip-Revisions mit und ohne den Bug :-(
Thomas K. schrieb: > Jetzt blinkts endlich wieder! Das blinkt nicht nur, an der seriellen Schnittstelle kommt noch eine Fehlermeldung raus das eine Datei nicht gefunden wurde. Da gehört noch eine CF mit einem File aus dem repo mit den Demo Daten rein, dann tut sich auch was auf dem Display.
Auf dem Display tut sich auch was wenn man die aktuelle Version benutzt - siehe ganz weit oben im Thread. Thomas K. schrieb: > Hab eben das hier gefunden: > https://github.com/sipeed/platform-gd32v/issues/17#issuecomment-579270512 > das hilft! Danke, das werde ich dann mal weiter leiten. Erstaunlich daran ist allerdings, das zum einen die Dinger ja mit Software drauf ankommen, zum anderen der ältere Chip das Problem nicht hat. Also zum einen hat Sipeed das Problem wohl nicht, zum anderen ist das schon echt eine Leistung keine 20 Wochen später eine neue Revision zu bringen die dann auch noch kaputt ist. Ohne den neuen Chip irgendwie anders zu markieren. Irgendwie ist das nicht so richtig glaubwürdig.
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.