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
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.