mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 5-Dollar-Entwicklerboard mit RISC-V: Sipeed Longan Nano


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Mikro 7. (mikro77)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Wurde in dem längeren Thread hier gepostet (ist leider ein bisschen im 
Rauschen untergegangen):
Beitrag "Re: RISC-V: Wird das was?"

Autor: Benedikt S. (benedikt_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo mit programmiert man den? Was für ein Debugger benutzt man dann?

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der JLink kanns wohl.
Ist jetzt nur die Frage obs die EDU Version auch kann.

Autor: Kriseninterventionsspezialist (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aus gewöhnlich gut unterrichten Kreise verlautbarte, dass es
auch eine Version der IAR Embedded Workbench für diese
Architektur gibt.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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!

Autor: homa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: John Doe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: homa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Dort findet sich auch eine Version von OpenOCD, die offensichtlich den
> GD32V unterstützt.

Wo sind die Quellen? OpenOCD ist GPL!

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Christopher J. (christopher_j23)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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:
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).

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
There is draft debug standard defined by the RISC-V foundation. However, 
this debug standard defines only JTAG, no cJTAG or SWD access and is not 
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 
:
To make it easy to acquire debug hardware, this spec recommends a connector that is compatible
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.
...
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
SWD should be possible when having also an ARM core in the same chip.
If it is possible for designs with RV only is something that ARM can answer better...
I am not sure regarding their licensing schemes.
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

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Quellen für OpenOCD für den GD32V liegen wohl hier:
https://github.com/riscv-mcu/riscv-openocd

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also verschickt hat Seeed-Studio meine 2 Exemplare jetzt, mal schauen ob 
der Fahrrad-Kurier bis Weihnachten hier ist.

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Mittlerweile gibt es das Teil auch bei Aliexpress:
https://www.aliexpress.com/item/4000221852639.html

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... die Arduino API scheint im Entstehen begriffen:

https://github.com/sipeed/Longduino

Immerhin, die SPI Schnittstelle gibt es schon.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bisher bekomme ich nicht mal ein gültiges USB Device angezeigt mit den 
von Sipeed verlinkten Treibern.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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) :-)

: Bearbeitet durch User
Autor: A. B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Rudolph R. (rudolph)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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. :-)

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ckuehnel (Gast)
Datum:
Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.