Puuh, es ist vollbracht und ich war an etwas wieder länger gesessen als ich das gewollt hatte, aaaber: Etwas funktioniert! Eigentlich hatte ich vor, das zuerst in einem Nachbarthread zu posten (weil ich dort Fragen zu einem Problem gestellt hatte), aber nachtdem der Bootloader nun fertig ist, glaube ich, dass er in die Rubrik "Projekte und Code" besser passt. Doku habe ich noch keine geschrieben (zumindest noch nicht richtig), aber wenn ich das gemacht habe (ich möchte noch andere Dinge zum CH32V003 aufschreiben), werde ich das in dem "Getting started" Thread einfügen. Vor allen Dingen muß ich dann dort die Makefiles anpassen, damit der neue Bootloader auch mittels es nun notwendigen Hostprogramms geflasht werden kann. Zum Bootloader: das hat mich etwas Nerven gekostet und einen Chip hat es mir zerstört, bei dem ich nicht weiß weshalb. Auch ein "unbrick" funktioniert nicht mehr. Vielleicht habe ich den Bootloaderbereich zu oft beschrieben (von dem ich nicht weiß, ob der genauso oft beschrieben werden kann, wie der "normale" Flashbereich). Wie dem auch sei: Im Anhang sind alle Dateien enthalten (inkl. dem CH32FUN) um den Bootloader zu compilieren. Im Ordner uart_bootload_page: "make build" compiliert den Bootloader "make flash" flasht zuerst den Bootloader in den Bootloaderbereich und setzt danach die entsprechenden Optionbytes Im Ordner host: liegt ein Binary v003flash und die Source v003flash.pas. Ja, richtig gelesen: das Hostprogramm für den Bootloader ist in FreePascal geschrieben, nicht in C, C++, Python oder Rust, sondern in FreePascal. Warum? Weil ich seit schier anbeginn der Zeit (noch unter DOS irendwann Ende der 80er Jahre) ein Uploadprogramm geschrieben hatte (damals für E-Prom Simulator und meinen allerersten selbstgebauten MCS-51 InCircuitEmulator) und ich bis heute das eben immer nur an die neuen Gegebenheiten anpasse. Grundsätzlich ist es doch egal, in welcher Sprache ein Hostprogramm geschrieben ist, das einen Programmer / Bootloader füttert. Die Syntax von v003flash ist: v003flash serialport firmware.hex Beispiel: v003flash /dev/ttyUSB0 blink.hex Was ist das "besondere" an einem Bootloader (und prinzipiell haben diejenigen Recht die nicht verstehen können, wie man damit "arbeiten" will, wenn man doch keinen Debuger hat und es viele andere Gründe gibt, die richtig sind)? Das "besondere" daran ist, dass man ohne irgendwelche zusätzlichen Sachen eine Schaltung aufbauen kann (siehe Foto) und mit einem einzigen (USB-)Kabel zugleich die Kommunikation dabei hat und das ganze dazu mittlerweile "abartig" billig ist. Demnächst werde ich wohl endlich eine PCB routen mit den Spielzeugen zum CH32V003 und dann wird auch diese Schaltung mit darauf kommen, ich werde sie wohl "Arduino ch32nano" nennen :-)
Angehängte Dateien:
Ralph S. schrieb: > glaube ich, dass er in die Rubrik > "Projekte und Code" besser passt. Aber sicher doch. Auch wenn ich den Bootloader sicherlich nicht benötigten werde: Lob für Dein Projekt, aus dem man viel interessantes lernen können wird. Find' ich gut, daß sich hier jemand so gründlich mit den WCH-Risc-µCs auseinandersetzt.
Harald K. schrieb: > Find' ich gut, daß sich hier jemand so gründlich mit den WCH-Risc-µCs > auseinandersetzt. "Gründlich" ist das wahrscheinlich nicht, ich kratze wohl nur an der "Oberfläche" und weiß das auch. Aber hier das erste "Update" zum Bootloader: Ich habe das Hostprogramm minimal überarbeitet. Antwortet der Bootloader nicht oder wählt man den falschen seriellen Port, bricht das Hostprogramm jetzt ab, als ewig in einer Schleife zu hängen.
Im Anhang jetzt hoffentlich "vorerst" das letzte Update, auch hoffentlich keine gröberen Fehler mehr: In der vorherigen Version hatte das Hostprogramm den Flashvorgang des Bootloaders auch dann gestartet, wenn auf demselben seriellen Port, auf dem geflasht werden soll, bereits ein Terminal geöffnet war (in meinem Falle entweder picocom oder putty). Das hatte dazu geführt, dass nicht nur vom Host, sondern auch vom Terminal Bytes geschickt wurden, was verherende Folgen haben kann, denn 2 Bytes geben die Anzahl der zu flashenden Pages an, in einem - nicht seltenen Fall - werden dann so viele Pages geschrieben, dass auch der Bootloader zerstört wird. Das jetzige Hostprogramm unterbindet den Flashvorgang, wenn auf der anderen Schnittstelle bereits ein Programm aktiv ist. Puuuh Viele Grüße und viel Spaß Ralph
Ralph S. (jjflash) 11.06.2025 18:04 >2 Bytes geben die Anzahl der zu flashenden Pages an, in einem - nicht >seltenen Fall - werden dann so viele Pages geschrieben, dass auch der >Bootloader zerstört wird. Ähm .. willst du nicht einen Limit-Check einbauen?
Christoph M. schrieb: > Ralph S. (jjflash) > 11.06.2025 18:04 >>2 Bytes geben die Anzahl der zu flashenden Pages an, in einem - nicht >>seltenen Fall - werden dann so viele Pages geschrieben, dass auch der >>Bootloader zerstört wird. > Ähm .. willst du nicht einen Limit-Check einbauen? Der Limit-Check ist da schon drin, aaaaaber wenn der Bootloader die Anzahl der Pages abfrägt, aber das Terminal und nicht der Host etwas schickt, dann löscht er zuviele Pages. Das ist jetzt dadurch gefixt, dass der Host die Schnittstelle ganz alleine hat. Dieser sendet garantiert nicht mehr als die 256 erlaubten Pages. Ich habe jetzt mit dem Ding bestimmt 2 stunden mit unterschiedlichen Szenarien gespielt. Der Bootloader blieb stabil
Ärgerlich: Doch noch einen Fehler gefunden (relativ übel sogar): Flasht man den Bootloader auf einen fabrikneuen Chip, auf dem noch nie ein Programm gelaufen ist, funktioniert der Loader nicht. Dem bin ich jetzt begegnet in dem nach dem Flashen des Bootloaders und dem Schreiben der Optionbytes der Loader automatisch aktiviert wird. Vorgehensweise: - make - make flash - make optionbytes Flashen und schreiben der Optionbytes können sowohl mit einem WCH-LinkE, dem Selbstbauprogrammer oder mit dem ArduLink gemacht werden. Für ArduLink im Makefile entsprechend den Programmer auswählen Gruß, Ralph
Nachdem mich ein freundliches Forenmitglied privat angeschrieben hat (der das hier wirklich nutzt), ist nun immer noch ein Bug im Makefile aufgetreten: die Variable zur Nutzung eines ArduLink ist beim Funktionsaufruf kleingeschrieben und gehört groß geschrieben. Um hier jetzt nicht mit Unnötigem Datenmüll noch ein Archiv hochzuladen hier jetzt nur das korrigierte Makefile im Anhang. Sorry für den Fehler!
Ralph S. schrieb: > Ärgerlich: Doch noch einen Fehler gefunden (relativ übel sogar): Flasht > man den Bootloader auf einen fabrikneuen Chip, auf dem noch nie ein > Programm gelaufen ist, funktioniert der Loader nicht. Was genau führt zu diesem Problem? D.h. worin unterscheidet sich ein Chip (mit dem Bootloader) auf dem nie ein Programm gelaufen ist, von einem Chip (ebenfalls mit dem Bootloader) auf dem schon mal ein Programm gelaufen ist? Wie merkt sich der Chip, daß schon mal ein Programm gelaufen ist?
F. P. schrieb: > Was genau führt zu diesem Problem? D.h. worin unterscheidet sich ein > Chip (mit dem Bootloader) auf dem nie ein Programm gelaufen ist, von > einem Chip (ebenfalls mit dem Bootloader) auf dem schon mal ein Programm > gelaufen ist? Wie merkt sich der Chip, daß schon mal ein Programm > gelaufen ist? Ganz ehrlich: ich kann es mir nicht genau erklären! Ursprünglich hatte ich in Verdacht, dass mein Linkerscript Interruptvektoren in den "Nicht-Bootbereich" hineinragen läßt. Das habe ich überprüft und dem ist nicht so. Zudem bin ich dann hergegangen und habe den Bootloader so geschrieben, dass er überhaupt keine Interrupts benötigt und das ganze schlicht per Polling erledigt. Danach habe ich mir den Systemticker genauer angesehen und das System nicht über ein "SystemInit" von CH32FUN gestartet, sondern bspw. die Takteinstellung über Bare-Metall Direktprogrammierung der Register gemacht. Dasselbe Verhalten. Im Moment sind mir leider die fabrikneuen Chips ausgegangen. Gehe ich her und lösche den gesamten Flashbereich, den gesamten Boot-Bereich und schreibe die Optionbytes neu, braucht es kein zuvor geflashtes Programm auf dem Chip. Irgendwann nächste Woche bekomme ich neue Chips (bei der Erstbestellung hatte ich mir nur 5 Chips 20 pol. und 5 Chips 16 pol. beschafft, weil ich nicht gedacht hätte, dass mich der Controller so sehr beschäftigen wird, ich wollte ihn einfach nur ausprobieren). Zur Erklärung: Der User-Flashbereich geht von Adresse 0x08000000 bis 0x08003fff, der Bootloaderbereich ist komplett vom User-Flashbereich abgetrennt und beginnt physikalisch ab 0x1ffff000, wird aber auf 0x00000000 gemappt und ist 1920 Byte lang. RAM-Bereich ist von 0x20000000 bis 0x20000800. Dann hatte ich in Verdacht, dass irgendwo CH32FUN mir hineinspuckt und es ein Programm sein muß, das mit CH32FUN erstellt worden ist. Um das zu evaluieren habe ich mir ein Binary-Blink-Programm erstellt mit MounRiver herunter geladen und mit dem Bootloader geflasht ... und das hat auch funktioniert. Warum jetzt also der Bootloader mit einem Fabrikneuen Chip nicht will? Wenn ich neue Chips habe, werde ich neue "Untersuchungen" machen.
F. P. schrieb: > Was genau führt zu diesem Problem? In Bezug auf deinen Nachnamen "Peinlich": Wenn du andeuten magst, dass mir das ganze peinlich sein sollte kann ich dir sagen: Es ist mir nicht peinlich! Sollte das ganze keine Andeutung sein betrachte den Text hier jetzt als nicht geschrieben!
Ralph S. schrieb: > Warum jetzt also der Bootloader mit einem Fabrikneuen Chip nicht will? Ich fragte, weil ich ein ähnliches Problem habe, allerdings mit Code Flash, nicht mit System Flash. Ich hatte ja neulich im anderen Thread vorgeschlagen, einen 64-pin CH32V305 zu nehmen, BOOT0 hochzulegen und dann die Original-WCH-LinkE-Firmware per USB (wchisp) einzuspielen, ganz ohne weitere Hardware. Da inzwischen ein 12-MHz-Quarz eingetroffen ist, habe ich das mal ausprobiert. Das Einspielen der Firmware auf einem fabrikneuen Chip funktioniert, aber die Firmware will nicht. Genauer: die beiden Load Switches werden aktiviert (d.h. etwas tut sich), aber der HSE springt nicht an, also keinerlei USB. Auch nicht, wenn ich die seltsame Hardware des WCH-LinkE nachbaue und die internen Verbindungen (z.B. PA8=PC9) des CH32V305F nachbilde. Mit meiner eigener Test-Software schwingt der HSE und USB geht. Entweder ich habe etwas übersehen oder die Firmware braucht noch etwas, das einem fabrikneuen CH32V305 fehlt. Die Chips des CH32V305F und des CH32V305R müßten dem Datenblatt nach identisch sein. Die Option Bytes sind beim CH32V305 uninteressant, bleiben eigentlich nur die Vendor Bytes, der System Flash (boot loader), oder eben etwas, das mit dem von Dir beobachteten Effekt zusammenhängt. OSC_OUT wie mit dem Mode-Taster auf GND kurzzuschließen, habe ich mir bisher nicht getraut.
F. P. schrieb: > Nö, **ich** bin peinlich. Okay... :-) ... niemand ist peinlich, der sich mit den Dingen hier beschäftigt. Bei der Komplexizität der Chips, obwohl das im Falle von CH32v003 noch halbwegs übeschaubar ist, macht man Fehler, wenn man darin noch neu ist. Peinlich wäre, etwas heftig zu verlautbaren und zu vertreten, aber keine wirkliche Ahnung hat. Mit dem danachfolgenden Post von dir, zeigst du, dass du eben nicht peinlich bist. F. P. schrieb: > Entweder ich habe etwas übersehen oder > die Firmware braucht noch etwas, das einem fabrikneuen CH32V305 fehlt. Ich beschäftige mich zwar (noch) nicht mit dem V305 (und wahrscheinlich werde ich das so intensiv wie ich das mit dem V003 jetzt mache nicht wieder tun, aber bei den vielen Infos die ich für den V003 zusammensuche, habe ich den Verdacht, dass genau das der Fall ist: Es fehlt einem fabrikneuen Chip etwas. Natürlich habe ich noch nicht alles verstanden (und werde das wohl auch niemals tun), aber in manchen Beschreibungen stehen, für mich nur Andeutungen, darüber drin, was es benötigt den Bootsektor zu aktivieren. Jetzt hat der V305 einen anderen RISCV-Kern als der V003, aber wahrscheinlich ist WCH dann doch hergegangen und ist bei ihren Produkten überall ähnliche Wege gegangen etwas zu realisieren. Okay, das alles ist ein "im Nebeln stochern", solltest du etwas mehr herausfinden wäre das für mich interessant zu wissen, was das ist. Grundsätzlich bin ich mit dem Bootloader wie er jetzt ist zufrieden, was nicht heißt, dass ich das nicht verbessern mag. Allerdings liegt da mittlerweile mein Hauptaugenmerk auf der Geschwindigkeit. Für mich erschließt es sich bspw. nicht, warum das Schreiben eine Flashpage (64 Byte) so lange dauert:
1 | while( FLASH->STATR & FLASH_STATR_BSY ); // warten bis Schreibvorgang fertig |
Beachtet man, das ich für den Bootloader mit 57600 Baud / 8N1 arbeite
und nach jeder Page zur Bestätigung ein Zeichen ('o') geschickt wird so
werden für ein komplettes Beschreibung insgedamt 16384 Bytes + 256
(Bestätigungbytes) vom Host geschickt. Das macht somit (bei 10 Bits per
Byte) 16640 / 57600 = 2,88s für die Datenübertragung. Das erklärt also
nicht, warum ein Flashvorgang mit meinem Bootloader für einen kompletten
Flashvorgang fast 20 Sekunden braucht (okay, ArduLink benötigt fast 90
Sekunden), ein Vorgang mit dem WCH-LinkE jedoch nur 4 Sekunden.
Irgendwie sollte es noch etwas schnelleres geben, als ein Pagewrite,
denn der LinkE kann das ja auch schneller und die Frage ist: Wieso kann
der das ?
"Nur mal so" zur Funktionsfähigkeit des Bootloaders: Wenn ich in Arduino den Core aus https://github.com/openwch/board_manager_files/raw/main/package_ch32v_index.json installiere und dann diesem Packet meinen Bootloader "unterjubele" (durch erweiterte Dateien platform.txt und boards.txt und das Flasherprogramm v003flash nach ~/.arduino15/packages/WCH/tools/openocd/1.0.0/bin kopiere, funktioniert der Bootloader auch dort (gerade ausprobiert). Hiermit kann man dann den CH32V003 absolut genauso programmieren, über nur diese eine USB-Buchse, wie man das von einem Arduino-UNO / Nano gewohnt ist.
Ralph S. (jjflash) 17.06.2025 07:26 >Hiermit kann man dann den CH32V003 absolut genauso programmieren, über >nur diese eine USB-Buchse, wie man das von einem Arduino-UNO / Nano >gewohnt ist. Wenn es wirklich funktioniert, ist das super. Eigentlich will ich die MCU schon die ganze Zeit mal testen.
Beitrag #7893663 wurde vom Autor gelöscht.
Christoph M. schrieb: > Wenn es wirklich funktioniert, ist das super. Eigentlich will ich die > MCU schon die ganze Zeit mal testen. Das ganze funktioniert, aber unter Linux. Dem Bootloader selbst ist das Betriebssystem das ihn füttert egal, aber das Hostprogram "v003flash" habe ich für Linux (in FreePascal) geschrieben. Dort gibt es u.a. einen Systemaufruf von "fuser" den es so in Windows wohl nicht gibt. Aber unter Linux funktioniert das einwandfrei. Die Frage ist hier jedoch, wieviel Sinn es macht, den CH32V003 unter Arduino zu programmieren. Ein einfaches Blinkprogramm belegt schon 4971 Byte und ich weiß, ich kann es gerade im Moment nicht konkret ausprobieren, dass ein nicht so aufwändiges Demoprogramm mit 7-Segementanzeigetreiber über 9000 Byte belegt, dann stellt sich schon die Frage was man damit machen möchte. Für kleine Dinge mag das dann funktionieren, aber mit den 16384 Byte Flash insgesamt wird es mit Arduino dann schon eng. Aber es funktioniert. Für kleine Dinge kann man bestimmt damit leben. Wenn du also Linux hast, befolgst du die Anweisungen in Beitrag "Re: CH32V003: serieller Bootloader" und downloadest das korrigierte Makefile des Chatverlaufes, Downloadest die Dateien "platform.txt" und "boards.txt" ebenfalls aus diesem Chatverlauf. Hast du die Dateien, dann erweiterst du die Einträge bei: Datei - Voreinstellungen - Zusätzliche Boardverwalter URLs. um https://github.com/openwch/board_manager_files/raw/main/package_ch32v_index.json Im Boardverwalter selbst installierst du jetzt ein neues Board (dort suchst du nach CH32) Wenn das funktioniert hat, kopierst du die gedownloadeten Dateien "platform.txt" und boards.txt nach ~/.arduino15/packages/WCH/hardware/ch32v/1.0.4/ Dann folgst du den Anweisungen des Textes in der PDF: - einen Arduino zum Programmer für CH32V003 machen (siehe Text) - PIN 6 (PD6) Arduino über einen 2,2kOhm Widerstand mit SWDIO von CH32V003 verbinden - den Bootloader über Arduino flashen. Hierfür vor dem Flashen im Makefile des Bootloader-Ordners eintragen: USE_ARDULINK = 1 - make - make flash - make optionbytes im Verzeichnis host: - make es entsteht das Hostprogramm für den Bootloader und heißt : v003flash Diese Datei kopierst du nach ~/.arduino15/packages/WCH/tools/openocd/1.0.0/bin Nach einem Start von Arduino solltest du jetzt zum einen ein CH32V003-Board auswählen können und als Flashing-Programm v003flash Hinweis zur Hardware. In meinem Schaltplan habe ich noch einen 22 nF Kondensator vom Ausgang des RTS-Anschlusses einer USB2UART-Bridge gewählt. Das war zu "optimistisch" und manchmal funktioniert das nicht. Dieser 22 nF Kondensator ist durch 100 nF zu ersetzen. (Jetzt gerade im Moment sitze ich an der Hardware und sinniere darüber nach, wie man die Resetschaltung des CH32V003 besser gestalten könnte, denn: Um den zu reseten muß man ihm die Betriebsspannung abschalten. Ist der Chip einmal unter Betriebsspannung gelaufen, löst ein Reset einen Neustart eines Firmwareprogrammes aus, aber startet nicht den Bootloader) Das hört sich jetzt sehr kompliziert an, aber die "Arduino-Jünger" , glaube ich, wissen ganz genau was da zu tun ist (Arduino mache ich halt nicht wirklich).
Dein Bootloader wäre super für einen CH32V003 Arduino-Nano-Clone geeignet. Den könnte man auf direkt auf das Experimentierbrett stecken und hätte auch gleich eine serielle Schnittstelle. >Das hört sich jetzt sehr kompliziert an, aber die "Arduino-Jünger" , >glaube ich, wissen ganz genau was da zu tun ist Deine Ausdrucksweise "Arduino-Jünger" stört mich, da sie negative konnotiert ist. Du könntest das lassen.
Christoph M. schrieb: > Dein Bootloader wäre super für einen CH32V003 Arduino-Nano-Clone > geeignet. > Den könnte man auf direkt auf das Experimentierbrett stecken und hätte > auch gleich eine serielle Schnittstelle. Genau das ist die Intension und genau dafür route ich auch eine PCB dafür! Christoph M. schrieb: > Deine Ausdrucksweise "Arduino-Jünger" stört mich, da sie negative > konnotiert ist. Du könntest das lassen. Oha, fühlst du dich da "negativ konnotiert"? Ich gehe niemals her und bewerte jemanden danach, wie er oder sie etwas bewerkstelligt. Weder hier im Forum noch im "wahren Leben". Wenn sich also jemand an einem Wort "Jünger" stört ist das seine (und nicht meine) Sache. Prinzipiell ist ein "Jünger" von etwas zu sein nicht "negativ konnotoert" sondern impliziert, dass jemand Fan, Anhänger oder sonstwie von etwas ist (und sich dort dann in aller Regel gut auskennt). Sicherlich lasse ich mir nicht vorschreiben, in welcher Ausdrucksweise ich etwas schreibe, solange es nicht beleidigend ist. Würde ich hier etwas negativ "konnotieren", hätte ich sicherlich in meiner Anleitung nicht explizit Arduino einen Abschnitt gewidmet!
Ralph S. schrieb: > Für mich erschließt es sich bspw. nicht, warum das Schreiben eine > Flashpage (64 Byte) so lange dauert: > >
1 | > while( FLASH->STATR & FLASH_STATR_BSY ); // warten bis |
2 | > Schreibvorgang fertig |
3 | > |
> > [...] Das erklärt also > nicht, warum ein Flashvorgang mit meinem Bootloader für einen kompletten > Flashvorgang fast 20 Sekunden braucht (okay, ArduLink benötigt fast 90 > Sekunden), ein Vorgang mit dem WCH-LinkE jedoch nur 4 Sekunden. Vielleicht liegt es daran, daß Dein Code im Flash läuft wohingegen beim Programmieren mit dem WCH-LinkE die CPU vermutlich stillgelegt ist? Hilft es, den Code ins RAM zu kopieren?
F. P. schrieb: > Vielleicht liegt es daran, daß Dein Code im Flash läuft wohingegen beim > Programmieren mit dem WCH-LinkE die CPU vermutlich stillgelegt ist? > Hilft es, den Code ins RAM zu kopieren? Das ist der nächste Versuch, den ich machen werde. Hierfür muß ich das Linkerscript anpassen. Puuuh
Mit -fPIC übersetzen und den Boot-Loader sich selbst zu Beginn ins RAM kopieren lassen und dann dort hinspringen.
F. P. schrieb: > der HSE springt nicht an Habe eben bei einem WCH-LinkE gemessen: der HSE wird gar nicht verwendet! Vielleicht wurde der Quarz mal von einer früheren Firmware-Version benutzt. Ich suchte also bisher an der falschen Stelle. Seltsamerweise beschreibt WCH-LinkUserManual.PDF ein Problem mit dem WCH-LinkE das durch Neulöten des Quarzes behoben werden können soll.
:
Bearbeitet durch User
Bitte entschuldigt die Entführung dieses Threads. Hier schreibt jemand, daß der Quarz in Version 1.3 des WCH-LinkE hinzukam und vermutet, daß dies für eine (zukünftige) High-Speed-USB-JTAG-Firmware gemacht wurde: https://en.eeworld.com.XX/Reference_Designs/detail/80614 (XX ist durch cn zu ersetzen, wegen Spam-Filter der Forums-Software.) Dort gibt es auch eine weitere Version der Firmware und mit dieser wird mein CH32V305R zu einem WCH-LinkE! Nur mit Kondensatoren und Spannungsregler. Bisher habe ich aber nur "wlink status" ausprobiert. Wenn das wirklich funktioniert, werde ich wohl besser einen eigenen Thread für eine Bauanleitung aufmachen.
F. P. schrieb: > https://en.eeworld.com.XX/Reference_Designs/detail/80614 > > (XX ist durch cn zu ersetzen, wegen Spam-Filter der Forums-Software.) Ich wußte nicht, dass chinesische Seiten hier mittels Spam-Filter blockiert werden, eigentlich schade. F. P. schrieb: > Dort gibt es auch eine weitere Version der Firmware und mit dieser wird > mein CH32V305R zu einem WCH-LinkE! Nur mit Kondensatoren und > Spannungsregler. Ist in sich sehr interessant, leider bin ich nicht im Besitz eines V305, weil ich eigentlich nur dem V003 verhaftet bleiben will (auch wenn sich beim V305 128k Flash und 32k Ram sehr interessant anhören, ist mir hier ein STM32F4 dann doch lieber. interessant hier ist dann für mich lediglich das TSSOP-20 Gehäuse... mit so viel Flash). F. P. schrieb: > Bisher habe ich aber nur "wlink status" ausprobiert. > Wenn das wirklich funktioniert, werde ich wohl besser einen eigenen > Thread für eine Bauanleitung aufmachen. Schmunzeln muß: Wenn du das dann wirklich am Laufenhast und eine Bauanleitung einstellst, würde ich doch glatt über meinen Schatten springen und V305 besorgen, nur um das nachzubauen. Der Programmer im Nachbarthread: Beitrag "CH32V003: serieller Bootloader" kann zumindest einen V203 flashen, einen V305 weiß ich nicht, da ich wie gesagt, keinen zur Verfügung habe (und natürlich hat er auch keine USB2UART-Bridge). Aber: ich bin auf Deine Bauanleitung gespannt.
Ralph S. schrieb: > würde ich doch glatt über meinen Schatten > springen und V305 besorgen, Ich könnte dir zum Selbstkostenpreis einen oder zwei V305RBT6 (LQFP-64M 10x10) schicken, wenn du möchtest. Habe z.Zt zehn Stück von LCSC auf Lager.
Ralph S. schrieb: > Ist in sich sehr interessant, leider bin ich nicht im Besitz eines V305, > weil ich eigentlich nur dem V003 verhaftet bleiben will (auch wenn sich > beim V305 128k Flash und 32k Ram sehr interessant anhören, ist mir hier > ein STM32F4 dann doch lieber. interessant hier ist dann für mich > lediglich das TSSOP-20 Gehäuse... mit so viel Flash). Interessant ist auch High-Speed USB mit eingebautem PHY. Bei den STM32 haben das nur ganz wenige. > Der Programmer im Nachbarthread: > > Beitrag "CH32V003: serieller Bootloader" > > kann zumindest einen V203 flashen, einen V305 weiß ich nicht Den CH32V305R kann man ganz ohne Programmer programmieren, direkt per USB, da BOOT0 herausgeführt ist.
Ich habe den Selbstbau-WCH-LinkE (nur) mit CH32V305R nun hier beschrieben: Beitrag "WCH-LinkE selbst gebaut mit CH32V305RBT6 und sonst fast nichts"
Johannes F. schrieb: > Ich könnte dir zum Selbstkostenpreis einen oder zwei V305RBT6 (LQFP-64M > 10x10) schicken, wenn du möchtest. Habe z.Zt zehn Stück von LCSC auf > Lager. ganz lieben Dank, aber im Moment habe ich so viele Projekte am Start, dass ich keine weiteren neuen mehr aufmachen möchte, V203 wollte ich auch noch austesten und glaube, das werde ich mal auf Eis legen. Doku für V003 wird erst mal weiter bearbeitet ... und dann kümmere ich mich um meine STM32 Sachen... und das auch erst dann, wenn ich wieder aus dem Krankenhaus bin.. F. P. schrieb: > Ich habe den Selbstbau-WCH-LinkE (nur) mit CH32V305R nun hier > beschrieben: Beitrag "WCH-LinkE selbst gebaut mit CH32V305RBT6 und sonst > fast nichts" werde ich mir jetzt ansehen... und bin gespannt
Die Ursache des Problems war einfach nur eine falsche Firmware. Keine Ahnung, warum FIRMWARE_CH32V305_v2.8.bin und FIRMWARE_CH32V305_v2.15.bin nicht gehen.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.