Splinter - Padauk Programmer mit CH32V003

Tim  . schrieb:

Ich habe mich einmal damit auseinander gesetzt, wie man einen sehr einfacher Programmer für Padauk Microcontroller mit einem CH32V003 umsetzen kann:

https://github.com/cpldcpu/Splinter

Aktuell ist das eher als test zu verstehen, eine komplette Toolchain gibt es noch nicht. Immer funktioniert das schreiben und auslesen.

Die Hauptherausforderung war die minimalistische Generierung der nötigen Spannungen.

Schön!

Mal ne Frage: Du machst die Boost-Regelung im uC. Kommt es da nicht zu Spitzen, wenn die abgehenden „Lasten“ geschaltet werden?

Harald A. schrieb:

Mal ne Frage: Du machst die Boost-Regelung im uC. Kommt es da nicht zu Spitzen, wenn die abgehenden „Lasten“ geschaltet werden?

Ja klar, das muss man mit einer Regelung des Boosters und genug Overhead abfangen. Der Opamp kann mit Schwankungen der Versorgungsspannung umgehen.

Und die Motivation dahinter war vermutlich die Verwendung von möglichst Standard-Bauteilen? Ich meine so ein TLV61046 kostet bei LCSC ja auch nur 17ct, ne China-Version vermutlich nochmal die Hälte.

Harald A. schrieb:

Und die Motivation dahinter war vermutlich die Verwendung von möglichst Standard-Bauteilen? Ich meine so ein TLV61046 kostet bei LCSC ja auch nur 17ct, ne China-Version vermutlich nochmal die Hälte.

Der 2N7002 clone kostet 1ct und ist bei JLCPCB als basic component verfügbar. D.h. 5ct vs. 5$ für einen Assembly-run. (ok, 11ct mit Diode)

Was mich aber eher genervt hat, ist die wechselnde Verfügbarkeit von Booster-ICs. Der aus dem vorherigen Minimalprogrammer war zwischendurch nicht mehr verfügbar. (https://github.com/free-pdk/easy-pdk-programmer-lite-hardware)

... und natürlich war das Projekt so viel Interessanter :)

Tim  . schrieb:

Was mich aber eher genervt hat, ist die wechselnde Verfügbarkeit von Booster-ICs. Der aus dem vorherigen Minimalprogrammer war zwischendurch nicht mehr verfügbar. (https://github.com/free-pdk/easy-pdk-programmer-lite-hardware)

... und natürlich war das Projekt so viel Interessanter :)

Smile, ich habe mir das ganze einmal angesehen und bin gespannt, was daraus werden wird. Ich hatte ja vor einiger Zeit (in der Pandemie) einen Programmer gemacht gehabt mit Arduino, sogar mit einem Startausgangspunkt von dir und hatte auch zuerst versucht gehabt, Spannungen für den Padauk direkt über den Arduino zu erzeugen und war gescheitert (ohne Operationsverstärker).

Dann hatte ich schlichtweg einen uralten MC34063 genommen gehabt. Ich glaube die Kombination mit Boost aus dem Controller und OP habe ich nicht versucht.

Ich bin sehr gespannt, was aus deinem Projekt werden wird, wobei mein "innerer Hype" um den PFS154 deutlich abgenommen hat und umso stärker jetzt mit CH32V003 ein Hype zurück gekommen ist.

Von daher hoch faszinierend, wenn dir hier ein Programmer glückt. Für mich verwende ich, wie du wohl auch, einen eigenen EASY-PDK-Programmer bei dem ich die Programmierspannungen und Datenleitungen mit Schiebeschalter umschalten kann, so dass ich einen Programmiersockel in ein Steckbrett oder auf ein entsprechend gerouetetes Board stecke kann.

Auf github gibst du an, dass "rvusb as a later step" angedacht ist, auch darauf bin ich sehr gespannt. :-) auch wenn ich da mittlerweile meinem Clone des EASY-PDK verhaftet bin (einfach weil in der Handhabung pragmatischer).

Vllt. wird dein Programmer ja so gut, dass ich da noch einmal eine kleinere Schaltung hinbekomme.

Gespannt bin ich wie das mit den Programmierspannungen für den PFS hinhauen wird. Ich weiß aus Erfahrung, dass das bei diesen Chips hochkritisch ist und ich habe es bspw. nicht geschaft, diese Spannung mittels Analogschalter an den Chip zu führen so, dass diese zwischen Programmiermodus und Runmodus umschaltbar sind.

Viel Erfolg !

Ralph S. schrieb:

Gespannt bin ich wie das mit den Programmierspannungen für den PFS hinhauen wird. Ich weiß aus Erfahrung, dass das bei diesen Chips hochkritisch ist und ich habe es bspw. nicht geschaft, diese Spannung mittels Analogschalter an den Chip zu führen so, dass diese zwischen Programmiermodus und Runmodus umschaltbar sind.

Das programmieren usw funktioniert schon:

https://github.com/cpldcpu/Splinter/blob/master/Design/README.md

Ralph S. schrieb:

Ich bin sehr gespannt, was aus deinem Projekt werden wird, wobei mein "innerer Hype" um den PFS154 deutlich abgenommen hat und umso stärker jetzt mit CH32V003 ein Hype zurück gekommen ist.

Ja, ich bin auch etwas hin- und hergerissen. Eigentlich wollte ich den programmer nutzen, um mit dem PML100 herumzuspielen. Allerdings scheint der einen sehr merkwürdigen Programmieralgorithmus zu verwenden, für den man Pegelwandler braucht...

Mal schauen, wann ich wieder dazu komme.

Man kann die Spannung auch mit Kapazitiver Ladungspumpe vervielfachen Da braucht man keine Regelung. Es reichen dazu zwei PWM Ausgänge die genau invertiert zueinander arbeiten. Ich nutze das in meinem PIC/AVR Programmer auf Basis vom CH552.

Schlagwort Dickson Charge Pump

Hallo Tim,

ich habe mir das ganze jetzt einmal genauer angesehen und ich bekomme da auch schon etwas hin. Nehme ich mein "Protokoll" meines Arduinoprogrammers und verbinde das mit deinen Sachen, dann funktioniert da schon etwas. Leider allerdings nur, wenn ich eine Ch340N USB2UART Bridge verwende.

Der Reiz des Ganzen liegt aber eher darin, den Ch32V003 mittels V-USB zu bedienen, so dass ein Singlechip-Programmer für den PFS154 dann möglich ist.

Leider bekomme ich keine Kommunikation mittels V-USB von PC zu Mikrocontroller hin. Bist du da schon etwas weiter?

Viele Grüße,

Ralph

Ralph S. schrieb:

Leider bekomme ich keine Kommunikation mittels V-USB von PC zu Mikrocontroller hin.

Mit "V-USB" meinst Du das hier, oder? https://github.com/cnlohr/rv003usb

Zwar bietet das auch die Möglichkeit, CDC für serielle Datenübertragung zu implementieren, das aber ist nicht USB-spezifikationskonform und wird von etlichen Betriebssystemen nicht unterstützt. rv003usb macht wie V-USB auch nur "low-speed"-USB mit 1.5 MBit/sec, für spezifikationskonformes CDC aber ist "full-speed"-USB mit 12 MBit/sec erforderlich.

Oder nutzt Du HID als Protokoll? Dann vergiss meinen Einwand.

Ralph S. schrieb:

Hallo Tim,

ich habe mir das ganze jetzt einmal genauer angesehen und ich bekomme da auch schon etwas hin. Nehme ich mein "Protokoll" meines Arduinoprogrammers und verbinde das mit deinen Sachen, dann funktioniert da schon etwas. Leider allerdings nur, wenn ich eine Ch340N USB2UART Bridge verwende.

Spannend! Wenn Du eine platine zum Experimentieren haben willst, sag Bescheid. Ich habe noch ein paar über, es fehlt nur die MCU und die pinheader. Das gilt auch für Andere.

Der Reiz des Ganzen liegt aber eher darin, den Ch32V003 mittels V-USB zu bedienen, so dass ein Singlechip-Programmer für den PFS154 dann möglich ist.

Ja, beziehungsweise mit rv003usb. Eine etwas einfachere Möglichkeit wäre es, einen CH32X033 zu verwenden. Der kostet auch nur $0.20 und hat dafür genug Speicher, um das userprogram komplett zu buffern. Beim V003 müsste man das in mehreren Schritten machen. Außerden lässt der sich ber USB-Bootloader programmieren.

Leider bekomme ich keine Kommunikation mittels V-USB von PC zu Mikrocontroller hin. Bist du da schon etwas weiter?

Nein, hatte bisher noch keine Zeit, daran weiter zu arbeiten. Eine andere Möglichkeit besteht allerdings auch darin, das user program über den LinkE Monitor zu schreiben. Dauert allerdings etwas.

Tim  . schrieb:

Eine etwas einfachere Möglichkeit wäre es, einen CH32X033 zu verwenden.

Der würde einen deutlichen Unterschied mit sich bringen, da er --anders als der CH32V003-- einen USB-Device-Controller enthält, und Full-Speed-USB in Hardware unterstützt. Damit lässt sich darauf ein spezifikationskonformes CDC implementieren, was das Leben deutlich vereinfachen sollte.

Prinzipiell könnte man damit auch ein MSD implementieren, was das Übertragen zu programmierender Firmware nochmal einfacher macht - das ginge dann nämlich für den Anwender ohne Verwendung irgendwelcher Programme, die mit seriellen Schnittstellen o.ä. hantieren, einfach durch ein Kopieren einer Datei auf einen Datenträger.

Es gibt diverse Geräte, die ihre eigenen Firmwareupdates dergestalt handhaben; ich wüsste nicht, was dagegenspricht, so ein Verfahren für ein Programmiergerät anzuwenden. Praktisch wäre dann vielleicht ein Display am Programmiergerät, das Dateinamen/Größe/Prüfsumme o.ä. der übertragenen Firmwaredatei anzeigt.