Forum: Mikrocontroller und Digitale Elektronik Padauk MCU für 0.038 USD aus Taiwan


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.
von Sebastian (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Revenue ist Gewinn, nicht Umsatz

von Tim  . (cpldcpu)


Bewertung
0 lesenswert
nicht lesenswert
Sebastian schrieb:
> Revenue ist Gewinn, nicht Umsatz

https://en.wikipedia.org/wiki/Revenue

Ich denke da hast Du nicht recht...

: Bearbeitet durch User
von Tim  . (cpldcpu)


Angehängte Dateien:

Bewertung
3 lesenswert
nicht lesenswert
Noch ein kleines Projekt mit dem PFS154:

https://cpldcpu.wordpress.com/2020/04/05/addressable-7-segment-display/

Ein anreihbares intelligentes 7-Segment Display. Jedes Segment enthält 
einen PFS154, der für die Displaykontrolle und Kommunikation zuständig 
ist.

: Bearbeitet durch User
von MaWin (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Tim  . schrieb:
> Noch ein kleines Projekt mit dem PFS154

Hmm, ja, wenn man unbedingt etwas mit dem 3ct uC tun will.

Aber so richtig taugt der nicht dafür, wie man am 1 
Widerstand,-Multiplexing sieht, 10mA Nennstrom des Display sind damit 
nicht erreichbar.

Ein DM13A STP16CP05 TLC5928 wäre nicht weniger intelligent (im 
Gegenteil, erlaubt Erkennung defekter LEDs) ebenso daisy-chainbar und 
auch nur 1 chip, und liefert nicht nur ordentlich Strom sondern sogar 
pinkompstible Verwendung bis 7-Segment Grossanzeigen mit 2 oder 3 LED 
pro Segment in Reihe.

Gibts aber zugegeben nicht für 3ct sondern eher 30ct.

von Tim  . (cpldcpu)


Bewertung
2 lesenswert
nicht lesenswert
MaWin schrieb:
> Tim  . schrieb:
>> Noch ein kleines Projekt mit dem PFS154
>
> Hmm, ja, wenn man unbedingt etwas mit dem 3ct uC tun will.
>
> Aber so richtig taugt der nicht dafür, wie man am 1
> Widerstand,-Multiplexing sieht, 10mA Nennstrom des Display sind damit
> nicht erreichbar.

Beim ausgewählten Display werden pro Segment zwei LEDs in 
Reihenschaltung verwendet. Daher ist der Spannungsabfall >3V und es war 
nicht mehr genug Headroom für die Stromquelle übrig. Leider ging das aus 
dem Datenblatt des Displays nicht eindeutig hervor. (Ja, chinazeugs 
usw.).

Leuchten tut es trotzdem. Die GPIOS begrenzen sowieso auf 10-15mA. Den 
Widerstand hätte man auch weglassen können.

> Ein DM13A STP16CP05 TLC5928 wäre nicht weniger intelligent (im
> Gegenteil, erlaubt Erkennung defekter LEDs) ebenso daisy-chainbar und
> auch nur 1 chip, und liefert nicht nur ordentlich Strom sondern sogar
> pinkompstible Verwendung bis 7-Segment Grossanzeigen mit 2 oder 3 LED
> pro Segment in Reihe.
>
> Gibts aber zugegeben nicht für 3ct sondern eher 30ct.

Ist aber auch langweiliger...

: Bearbeitet durch User
von Jochen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@ Tim

Wo hast du die Platinen zu deinem "kleinen" Projekt (PFS154) machen 
lassen? Kann dort jeder eventuell nachbestellen?

von Tim  . (cpldcpu)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Jochen schrieb:
> @ Tim
>
> Wo hast du die Platinen zu deinem "kleinen" Projekt (PFS154) machen
> lassen? Kann dort jeder eventuell nachbestellen?

Habe das PCB in EasyEDA designed. Ich werde das Projekt dort später 
teilen. Von dort aus kann man auch direkt bei JLPCB und LCSC bestellen.
Alternativ habe ich das Projekt zum Importieren angehängt.

: Bearbeitet durch User
von Jochen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@ Tim

Vielen Dank.

von Mehmet K. (mkmk)


Bewertung
0 lesenswert
nicht lesenswert
Zufaellig darüber gestolpert. Auf eevlog wird ein Programmer 
vorgestellt.
https://www.eevblog.com/forum/blog/eevblog-1306-(1-of-5)-3-cent-padauk-micro-open-source-programmer/

von W.S. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Tim  . schrieb:
> Noch ein kleines Projekt mit dem PFS154:

Ja, ist alles schön recht und gut. Ich hab auch mal bei eevblog 
geschaut, da bist du ja wohl auch recht aktiv.

Ich hänge hier mal was dran. Ds sind noch keine Projekte, sondern 
erstmal nur Fingerübungen meinerseits. Die D-Variante ist für ein LCD 
Tian-Ma-A2C00096100 (1 Zeile Alpha und ein paar Sonderzeichen), was es 
derzeit für zum Padauk preislich passende 55 Ct gibt.

Aber mir fehlt noch was, nämlich Dokumentation. Daß ihr das mit der 
Programmierung der Chips bei eevblog hingekriegt habt ist gut, aber es 
braucht noch die Beschreibung der Programmieralgorithmen und (ganz 
wichtig) des tatsächlich verwendeten  Takt-Kalibrier-Algorithmus. Das, 
was da an Laborbericht vorliegt, ist sicherlich bei intensivem 
Durcharbeiten recht informativ, aber keine wirkliche Dokumentation. Eine 
Beschreibung des Kommunikations-Interfaces zwischen PC und Brenner hab 
ich auch nicht gefunden.

Ein Padauk-Assembler scheint bei SDCC wohl mit dabei zu sein, aber es 
piept mich mal wieder an, daß sowas lediglich als Gesamtpaket und als 
.EXE (!!!) vorliegt. Wer mit SDCC arbeiten will, ist ja wohl keine 
ahnungslose Büro-Maus. Und wenn da nix ist, sondern lediglich ein 
Nachbrenner für den Compiler, dann schreibe ich mir meinen Assembler 
selber.

So, ich hab inzwischen zwar mal angefangen, eine Art 
Dokumentations-Rumpf zu schreiben, aber weit bin ich damit bislang nicht 
gekommen, es fehlen immer wieder Kleinigkeiten, die in dem mittlerweile 
riesigen Thread bei eevblog vermutlich irgendwo versteckt sind.

Frage: Kannst du dich durchringen, wenigstens die Kernbelange des 
vorliegenden Brenners (Algorithmen und Interface PC--Brenner) zu 
dokumentieren?

W.S.

von Tim  . (cpldcpu)


Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> Tim  . schrieb:
>> Noch ein kleines Projekt mit dem PFS154:
>
> Ja, ist alles schön recht und gut. Ich hab auch mal bei eevblog
> geschaut, da bist du ja wohl auch recht aktiv.
>
> Ich hänge hier mal was dran. Ds sind noch keine Projekte, sondern
> erstmal nur Fingerübungen meinerseits. Die D-Variante ist für ein LCD
> Tian-Ma-A2C00096100 (1 Zeile Alpha und ein paar Sonderzeichen), was es
> derzeit für zum Padauk preislich passende 55 Ct gibt.

Sehr schön! Das sind wohl genau die richtigen Anwendungsfelder.

> Aber mir fehlt noch was, nämlich Dokumentation. Daß ihr das mit der
> Programmierung der Chips bei eevblog hingekriegt habt ist gut, aber es

Ja, das ist bei Open-Source Projekten leider häufig ein Pferdefuss. Über 
Unterstützung in dem Bereich würden sich viele freuen.

Ein Vorteil ist aber, dass die Datenblätter von Padauk auf Englisch und 
verhältnismässig ausführlich sind.

> braucht noch die Beschreibung der Programmieralgorithmen und (ganz
> wichtig) des tatsächlich verwendeten  Takt-Kalibrier-Algorithmus. Das,
> was da an Laborbericht vorliegt, ist sicherlich bei intensivem
> Durcharbeiten recht informativ, aber keine wirkliche Dokumentation. Eine
> Beschreibung des Kommunikations-Interfaces zwischen PC und Brenner hab
> ich auch nicht gefunden.

Die Programmieralgorithmen sind teilweise hier dokumentiert.

https://github.com/free-pdk/fppa-pdk-documentation/tree/master/programming_sequence

Den Programmer hat "JS" aus dem EEVblogforum entwickelt. 
Kommunikationsinterface ist leider nur über den Sourcecode dokumentiert:

https://github.com/free-pdk/easy-pdk-programmer-software

> Ein Padauk-Assembler scheint bei SDCC wohl mit dabei zu sein, aber es
> piept mich mal wieder an, daß sowas lediglich als Gesamtpaket und als
> .EXE (!!!) vorliegt. Wer mit SDCC arbeiten will, ist ja wohl keine
> ahnungslose Büro-Maus. Und wenn da nix ist, sondern lediglich ein
> Nachbrenner für den Compiler, dann schreibe ich mir meinen Assembler
> selber.

Ich finde einen C-Wrapper deutlich angenehmer. Der Compiler erzeugt 
recht brauchbaren Code und die kritischen Bereiche kann man ohne viel 
Overhead als inline-Assembler einbinden, wie z.B. hier:

https://github.com/cpldcpu/SimPad/blob/master/Toolchain/library/PDK_softuart.c

Das ist natürlich Geschmackssache.

Den aktuellen SDCC-Source gibt es im Repository oder als Archiv:
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/

Philipp kann dazu sicherlich mehr sagen.

von W.S. (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Tim  . schrieb:
> Die Programmieralgorithmen sind teilweise hier dokumentiert.

Nö.
Da hast du mich falsch verstanden. Das ist der Laborbericht, den ich 
erwähnte - aber es ist keine Dokumentation. Ich hab dieses Papier 
bereits durchgesehen, es ist ein schwieriges Papier, insbesondere 
aufgrund der Diagramme.

Tim  . schrieb:
> Kommunikationsinterface ist leider nur über den Sourcecode dokumentiert

Das hab ich auch schon durchgesehen. Die Quelle ist durchaus mit 
ziemlicher Konsequentheit geschrieben, aber recht unkommentiert und 
nicht dafür ausgelegt, gut verstanden zu werden. Als Autor steht man 
normalerweise mittendrin und versteht die eigene Struktur, aber für 
Dritte ist das erstmal nur ein Dickicht.

Abgesehen davon sind mir beim Durchsehen der diversen Papiere einige 
Gedanken gekommen, zunächst zum Problem der beim Programmieren wild 
herumgefahrenen Spannungen Vdd und Vpp: Mir scheint, daß es zwischen Vdd 
und Vpp im Chip etwas Z-Diodenartiges gibt, das dafür sorgt, daß beim 
Hochfahren von Vpp vor Vdd eben Vdd mit einem Abstand von knapp 7 Volt 
nachgezogen wird. Wenn nun Vdd aus einer Quelle wie einem OpV kommt, 
dann gibt es einen Crash, wenn diese Spannungsdifferenz überschritten 
wird. Deshalb das Hochfahren von Vpp auf einen ersten Zwischenwert, dann 
das Nachziehen von Vdd, dann das weitere Hochfahren von Vpp auf den 
benötigten Endwert und dann das weitere Hochfahren von Vdd auf einen 
Wert, bei dem das Einschießen von Ladungen in die isolated Gates zwar 
möglichst schnell geht, dabei der Chip aber grad noch nicht abraucht.

Vielleicht ist es möglich, Vdd einfach floaten zu lassen (evtl. mit 
einem dezenten Runterzieher von 47k gegen Masse), dabei Vpp gleich auf 
Sollspannung zu fahren und dann Vdd nur per Einquadrantenquelle (also 
Spannungsquelle quasi wie ein Emitterfolger ohne Lastwiderstand) zu 
applizieren.

So, wie es derzeit ist, scheint es eher ein Problem zu sein, das der 
Padaukschen Programmierhardware geschuldet ist als daß es vom Chip her 
eine Notwendigkeit wäre.


W.S.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
0 lesenswert
nicht lesenswert
Tim  . schrieb:
>
>> Ein Padauk-Assembler scheint bei SDCC wohl mit dabei zu sein, aber es
>> piept mich mal wieder an, daß sowas lediglich als Gesamtpaket und als
>> .EXE (!!!) vorliegt. Wer mit SDCC arbeiten will, ist ja wohl keine
>> ahnungslose Büro-Maus. Und wenn da nix ist, sondern lediglich ein
>> Nachbrenner für den Compiler, dann schreibe ich mir meinen Assembler
>> selber.
>
> Ich finde einen C-Wrapper deutlich angenehmer. Der Compiler erzeugt
> recht brauchbaren Code und die kritischen Bereiche kann man ohne viel
> Overhead als inline-Assembler einbinden, wie z.B. hier:
>
> https://github.com/cpldcpu/SimPad/blob/master/Toolchain/library/PDK_softuart.c
>
> Das ist natürlich Geschmackssache.
>
> Den aktuellen SDCC-Source gibt es im Repository oder als Archiv:
> https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/
>
> Philipp kann dazu sicherlich mehr sagen.

Ja. SDCC wird im svn entwickelt (siehe oben). daneben gibt es auch noch 
Snapshots und Releases. Beide jeweils als Tarball mit Quellcode, als 
Kompilate für macOS, Windows, GNU/Linux.
Eigentlich sollte sich nirgendwo nur eine EXE finden; an allen Stellen 
an denen es Kompilate git sollte sich auch ein Quellcode-Tarball finden.

Woher kommt dieser "SDCC […] lediglich als […] .EXE"?

Der sdas-Assembler in SDCC ist ein Fork des asxxxx-Assemblers (die haben 
sich nun leider etwas auseinanderentwicklet, sie wieder zusammenzuführen 
wäre wünschenswert, aber Aufwand).

von Tim  . (cpldcpu)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Tim  . schrieb:
>> Die Programmieralgorithmen sind teilweise hier dokumentiert.
>
> Nö.
> Da hast du mich falsch verstanden. Das ist der Laborbericht, den ich
> erwähnte - aber es ist keine Dokumentation. Ich hab dieses Papier
> bereits durchgesehen, es ist ein schwieriges Papier, insbesondere
> aufgrund der Diagramme.

Ja, es ist schon verständlich, dass Du Dir hier mehr Struktur wünschnst. 
Leider ist das alles, was vorhanden ist.

> Abgesehen davon sind mir beim Durchsehen der diversen Papiere einige
> Gedanken gekommen, zunächst zum Problem der beim Programmieren wild
> herumgefahrenen Spannungen Vdd und Vpp: Mir scheint, daß es zwischen Vdd
> und Vpp im Chip etwas Z-Diodenartiges gibt, das dafür sorgt, daß beim
> Hochfahren von Vpp vor Vdd eben Vdd mit einem Abstand von knapp 7 Volt
> nachgezogen wird. Wenn nun Vdd aus einer Quelle wie einem OpV kommt,

Woraus schlussfolgerst Du das?

Generell kann wohl davon ausgehen, dass es eine ESD Struktur gibt, die 
in irgendeiner Weise VPP, VDD und GND verbindet. Da VPP höher als VDD 
sein kann, wird es wohl keine einfache Clampdiode sein, sondern eine 
Struktur, die erst bei höherer Spannungsdifferent schaltet.

> dann gibt es einen Crash, wenn diese Spannungsdifferenz überschritten
> wird. Deshalb das Hochfahren von Vpp auf einen ersten Zwischenwert, dann
> das Nachziehen von Vdd, dann das weitere Hochfahren von Vpp auf den
> benötigten Endwert und dann das weitere Hochfahren von Vdd auf einen
> Wert, bei dem das Einschießen von Ladungen in die isolated Gates zwar
> möglichst schnell geht, dabei der Chip aber grad noch nicht abraucht.

Ich hatte immer dein Eindruck, dass der Power-On-Reset genutzt wird, um 
die MCU zu resetten und in einen Zustand zu bringen, aus dem man danach 
in den Programmiermodus kommt. Dazu muss erst einmal VDD stabilisiert 
sein. Das DeltaV zu VPP initiiert dann den Programmiermodus. 
Wahrscheinlich werden viele Devices in einem Bereich mit starken hot 
carrier stress betrieben, so dass der Programmiermodus nicht all zu 
lange aktiv sein darf.

> Vielleicht ist es möglich, Vdd einfach floaten zu lassen (evtl. mit
> einem dezenten Runterzieher von 47k gegen Masse), dabei Vpp gleich auf
> Sollspannung zu fahren und dann Vdd nur per Einquadrantenquelle (also
> Spannungsquelle quasi wie ein Emitterfolger ohne Lastwiderstand) zu
> applizieren.

Dann kann man aber nicht genau kontrollieren, was der POR macht. Das 
würde ich als eher kritisch ansehen.

von Tim  . (cpldcpu)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt eine vereinfachte Version das EasyPDKProg getestet, 
welche sich fast komplett beim JLCPCB Assembly-Service fertigen lässt. 
Siehe hier:

https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg3106318/#msg3106318

Es müssen ledliglich ein paar größere Bauteile manuell bestückt werden.

Von der r0 sind keine PCBs mehr übrig, aber ich werde bald ein paar neue 
PCBs von einer finalen Version (r1) ordern. Wenn jemand interesse hat, 
bitte ich um eine PM.

: Bearbeitet durch User
von W.S. (Gast)


Angehängte Dateien:

Bewertung
-3 lesenswert
nicht lesenswert
Tim  . schrieb:
> Von der r0 sind keine PCBs mehr übrig, aber ich werde bald ein paar neue
> PCBs von einer finalen Version (r1) ordern. Wenn jemand interesse hat,
> bitte ich um eine PM.

Dann überarbeite bitte zuvor alle Footprints. Diejenigen für die 
gewöhnlichen R und C haben zu geringen Padabstand und sie sind für 0805 
etwas zu klein und für 0603 zu riesig. Ich würde ja lieber bei allen R 
auf 0603 gehen.  Und der Footprint für den STM32F072 hat viel zu lange 
Pads. Die gucken zu weit unter den Chip und das macht Probleme. Als 
nächstes sollte wenigstens die GND-Fläche auf der Bestückseite mehr 
isolate-Abstand haben. Abgesehen davon ist die ganze LP mit einer 
Unmenge von GND-Vias übersät - das ist unnötig und stört an manchen 
Stellen. Nochwas: dort wo der Fassungs-Footprint ist, lieber noch ein 
simples Hole mit so etwa 3 mm Dmr setzen, um die Drähte, die man dort 
für eine Programmier-Strippe anlöten muß, durchzuziehen und damit eine 
gewisse Zug- und Biege-Entlastung zu schaffen. Noch schöner wäre 
natürlich eine richtige Steckbuchse. Anbei ein Bild (nach Ablöten des µC 
aufgrund Kurzschluß unter dem Chip).

Tja.. und:
"Ja, es ist schon verständlich, dass Du Dir hier mehr Struktur 
wünschnst.
Leider ist das alles, was vorhanden ist."

Deswegen habe ich ja den Vorsatz gefaßt, mich schriftstellerisch zu 
betätigen. Ist aber ne Luftnummer, weil ich keinerlei OTP Typen habe und 
eigentlich auch nicht JFF ordern will und deshalb dann das meiste gar 
nicht selbst verifizieren kann.

"Woraus schlussfolgerst Du das?"

Nun, ich hab mir bei all den Diagrammen so meine Gedanken gemacht, 
offenbar floatet VDD ohnehin des öfteren beim Hochfahren und man nimmt 
ja erstmal an, daß es für ein beobachtbares Procedere irgend einen 
triftigen Grund gibt.

"Ich hatte immer dein Eindruck, dass der Power-On-Reset genutzt wird, um
die MCU zu resetten und in einen Zustand zu bringen, aus dem man danach
in den Programmiermodus kommt."

Ich kenne das alles von den PIC's her: dort gilt bei den meisten Typen, 
die einen internen RC-Oszi haben auch VPP vor VCC. Aber dort wird VPP 
sogleich auf etwa 13..14 Volt hochgerissen und später erst VCC auf 5V 
gesetzt. MicroChip gibt dafür auch einen Grund an: bei internem 
Oszillator kann es sein, daß dieser während des Ansteigens von /Reset 
schon anschwingt - offenbar reicht dann eine halbe Periode - und man 
kommt dann nicht mehr in den Programmiermodus. MicroChip scheint dabei 
die Innereien auf dem Silizium besser im Griff zu haben, so daß sie 
sogleich auf volle Kanne mit VPP gehen können.
Bei meinem PIC-Brenner hab ich deshalb auch einen Gatetreiber 
eingesetzt, der schaltet zuverlässig binnen weniger als 20 ns VPP nach 
oben. Dann kann man auch VCC vor VPP bei besagten PIC's fahren.

W.S.

von Tim  . (cpldcpu)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> Dann überarbeite bitte zuvor alle Footprints. Diejenigen für die
> gewöhnlichen R und C haben zu geringen Padabstand und sie sind für 0805
> etwas zu klein und für 0603 zu riesig. Ich würde ja lieber bei allen R
> auf 0603 gehen.  Und der Footprint für den STM32F072 hat viel zu lange
> Pads. Die gucken zu weit unter den Chip und das macht Probleme. Als

Ja, der STM32F072 lässt sich mit den aktuellen Pads in der Tat nicht gut 
löten. Die Footprints stammen allerdings alle von LCSC/JLCPCB. Daher 
gehe ich davon aus, dass sie für deren PCB-Assembly Prozess optimiert 
sind.

Die Lite-Version ist explizit dafür vorgesehen, bei JLCPCB automatisch 
bestückt zu werden. Daher würde ich von deren Footprints nicht abweichen 
wollen, auch wenn es die Handbestückung erleichtern würde. Ich habe 
daher jetzt, wenn möglich, alle Passives auch auf 0402 geändert, da so 
etwas mehr Platz für tooling-holes ist und die Kosten niedriger sind.

Der aktuelle Stand ist oben zu sehen. Ein 3mm Loch könnte ich im Prinzip 
noch einbauen.

Die ganzen Durchkontaktierungen finde ich auch etwas obskur, zumal es 
sich ja nicht um ein HF-Design handelt. Ich habe die Anzahl jetzt grob 
auf die Häfte reduziert. Allerdings scheinen es gefühlt kaum weniger zu 
werden...

W.S. schrieb:
> "Ich hatte immer dein Eindruck, dass der Power-On-Reset genutzt wird, um
> die MCU zu resetten und in einen Zustand zu bringen, aus dem man danach
> in den Programmiermodus kommt."
>
> Ich kenne das alles von den PIC's her: dort gilt bei den meisten Typen,
> die einen internen RC-Oszi haben auch VPP vor VCC. Aber dort wird VPP
> sogleich auf etwa 13..14 Volt hochgerissen und später erst VCC auf 5V
> gesetzt. MicroChip gibt dafür auch einen Grund an: bei internem
> Oszillator kann es sein, daß dieser während des Ansteigens von /Reset
> schon anschwingt - offenbar reicht dann eine halbe Periode - und man
> kommt dann nicht mehr in den Programmiermodus. MicroChip scheint dabei
> die Innereien auf dem Silizium besser im Griff zu haben, so daß sie
> sogleich auf volle Kanne mit VPP gehen können.

Evtl. nutzt Padauk auch einen leicht anderen Ansatz zur Aktivierung des 
Programmiermodus? Ich würde nicht erwarten, dass es hier zu große 
Anleihen an die PICs gibt. Man sollte auch bedenken, dass Padauk 
wahrscheinlich eine ganz anderen Speicher-IP nutzt und sich der 
Programmiervorgang daher als Ganzes unterscheiden kann. Das einfachste 
ist im Moment auf jeden Fall, dem Originalprogrammer zu folgen.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Passend zu dem Modifizierten "lite r1" Programmer habe ich ein paar 
Breakout-Boards designed, die direkt in den Programmer gesteckt werden 
können. Durch die minimale Größe können sie gut auf Breadboards 
verwendet werden.

Die flash-typen von Padauk können mit zwei pin-out Varianten abgedeckt 
werden.

Beim PFS172/PFC232-SO8 musste ich ein paar Pins vertauschen, damit die 
Programmierschnittstelle in an den richtigen Positionen liegt. Nicht 
ideal...

: Bearbeitet durch User
von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
0 lesenswert
nicht lesenswert
> Die flash-typen von Padauk können mit zwei pin-out Varianten abgedeckt
> werden.

Soweit ich weiss, gibt es den PFC161 bisher nur im S08B-Pinout (auch 
wenn es laut Datenblatt auch S08A geben sollte), das zu keinem anderen 
Flash-Typ passt. Damit bräuchten man für die 8-Pin-Flash-Typen 
mindestens 3 Layouts (wie bei meinem f-eval-boards 
https://github.com/free-pdk/f-eval-boards).

: Bearbeitet durch User
von Tim  . (cpldcpu)


Bewertung
0 lesenswert
nicht lesenswert
Philipp Klaus K. schrieb:
>> Die flash-typen von Padauk können mit zwei pin-out Varianten
> abgedeckt
>> werden.
>
> Soweit ich weiss, gibt es den PFC161 bisher nur im S08B-Pinout (auch
> wenn es laut Datenblatt auch S08A geben sollte), das zu keinem anderen
> Flash-Typ passt. Damit bräuchten man für die 8-Pin-Flash-Typen
> mindestens 3 Layouts (wie bei meinem f-eval-boards
> https://github.com/free-pdk/f-eval-boards).

Stimmt, die S08B type ist noch einmal deutlich anders. Da wird bestimmt 
die Kompatibilität zu einem Wettbewerber-IC eine Rolle spielen...

Eine weitere Variante bekomme ich leider nicht aufs panel. Allerdings 
handelt es sich bei den PFC161 ja um touch controller - die wird man 
sowieso nicht auf einem breadboard nutzen wollen, da die parasitären 
Kapazitäten die Touch-Funktion beeinträchtigen.

: Bearbeitet durch User
von W.S. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Tim  . schrieb:
> Evtl. nutzt Padauk auch einen leicht anderen Ansatz zur Aktivierung des
> Programmiermodus? Ich würde nicht erwarten, dass es hier zu große
> Anleihen an die PICs gibt.

Das mag sein. Ich hab zwar so das Gefühl, daß Padauk durchaus recht 
deftige Anleihen an die PIC's genommen hat, aber zumindest bei den 
ausgewiesenen OTP Typen geht's wohl anders - ansonsten gäbe es ja keinen 
Grund, bei vorhandenen Flash-Zellen die Chips als OTP auszuweisen.

Umso wichtiger ist eben genau das, was mir inzwischen im Magen liegt: 
eine möglichst genaue und kompakte und gründliche Zusammenfassung all 
dessen, was bislang herausgefunden wurde.

W.S.

von Tim  . (cpldcpu)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Das mag sein. Ich hab zwar so das Gefühl, daß Padauk durchaus recht
> deftige Anleihen an die PIC's genommen hat, aber zumindest bei den

Die Padauk MCUs kann man von der Architektur her als deutlich 
verbesserte PICs wahrnehmen. Von der Implementationsseite haben sie 
wenig gemein. Die neueren Padauks sind alle mit modernen Synthesetools 
in einem 0.18µm CMOS-Prozess designed, während die aus der Hochzeit der 
PICs bekannten Derivate auf Technologie der 80er Jahre beruhen - so, wie 
die Dies aussehen, auch mit full custom Layout.

Dieses ist der Grund dafür, warum die PDK-Controller so günstig und 
klein sein können. Die 0.18 µm Technologie ist heute für wenig Geld auf 
200mm Wafern verfügbar, während sie in den 90er Jahren noch nicht 
entwickelt war. Die Technologie des nichtflüchtigen Speichers wird bei 
beiden eine grundsätzlich andere sein.

Kurz - außer auf Architekturseite nach Ähnlichkeiten zu suchen liefert 
eher zufällig Ergebnisse.

> ausgewiesenen OTP Typen geht's wohl anders - ansonsten gäbe es ja keinen
> Grund, bei vorhandenen Flash-Zellen die Chips als OTP auszuweisen.

Ich gehe davon aus, dass es sich bei den OTP-Typen auch um OTP-Speicher 
handelt. Zumindest die Peripherie für den Löschvorgang wird man nicht 
integriert haben.

von W.S. (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Naja, es ist ja auch kein Wunder, daß sich in den verflossenen 30 Jahren 
die Technik weiter entwickelt hat. Meinen PIC-Assembler hatte ich so 
etwa 1992..93 geschrieben, weil mir der damalige 'PICALC' zu doof war. 
Ist alles ne Weile her.

Ich hab erstmal einen neuen STM auf die Brenner-LP gelötet und meinen 
JLink-edu herausgekramt. Geht so, aber /Reset hätte ruhig auch 
herausgeführt sein können. Man muß diese STM's ja zuerst entsperren, 
dann bulkerase und dann geht erst das eigentliche Programmieren. Mit der 
Schreiberei ist noch nichts weiter gediehen.

Aber wie schaut's bei dir mit den Padauk's aus? Pläne, wie es 
weitergehen soll?

W.S.

von Tim  . (cpldcpu)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Der Größenvergleich einer Padauk MCU mit einem PIC12C509 im Bild spricht 
Bände.

Ich kenne zwar die genauen Dimensionen des PIC-die nicht, allerdings 
kann man annehmen, dass die Bondpads eine ähnliche Größe haben und daher 
zur Skalierung hinzugezogen werden können.

Der PMS150C ist mehr als 10x kleiner als der PIC - trotz erweiterter 
Funktionalität.

von Tim  . (cpldcpu)


Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> Aber wie schaut's bei dir mit den Padauk's aus? Pläne, wie es
> weitergehen soll?

Im Moment ist im EEV-Forum viel Aktivität uns es gab Fortschritte bei 
der Toolchain und der Dokumentation.

Es gibt jetzt dank Christian aus dem Forum hier ein Update der Website:

https://free-pdk.github.io/

Die neue Website basiert auf Jekyll, so dass es relativ leicht ist, 
Beiträge im Markdown-Format zu verfassen.

Ich kümmere mich gerade um den lite r1 Programmer. Die ersten Boards 
werden gerade aufgebaut und sollten in 1-2 Wochen bei mir sein.

: Bearbeitet durch User
von W.S. (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Tim  . schrieb:
> Im Moment ist im EEV-Forum viel Aktivität uns es gab Fortschritte bei
> der Toolchain und der Dokumentation.

Nun ja, die Fortschritte bei der Dokumentation sind allerdings recht 
überschaubar. Eine echte Dokumentation zum Programmieren dieser Chips 
existiert noch immer nicht. Ein gleiches gilt für deren 
Oszillator-Kalibration. Und der Größenvergleich der Dies zwischen einem 
PIC und einem Padauk ist zwar nett, aber für die Dokumentation unnötig. 
Es soll ja kein Plausch zum Tee-Kränzchen sein, sondern eine 
Dokumentation der Programmierung dieser Chips.

Mit der Toolchain dürfte der SDCC gemeint sein, mit dem hab ich mich 
bislang noch gar nicht befaßt, ich neige bei solchen Chips eher zu 
Assembler.

Naja und der Thread bei eevblog ist tatsächlich weiter angeschwollen, 
aber es ist extrem mühsam, dort noch irgend eine nützliche Information 
herauszulesen, es ist zuviel und auch thematisch zu sehr durcheinander. 
Es geht zumeist gar nicht mehr um den Programmer und die Algorithmen, 
sondern da wird über C++ diskutiert und darüber, daß printf zu groß ist. 
Wer hätte das je gedacht?

Und als eine sehr seltsame Sache sehe ich es an, daß dort jemand so ein 
BluePill-Board hernimmt, dort den µC und andere BE herunterlötet, dann 
einen STM32F072 drauflötet, und dann eine Zusatzplatine entwirft, wo die 
brennerspezifischen Dinge drauf sind. Auch hier wäre mMn eine 
Konsolidierung nötig: den eigentlichen Brenner auf eine LP, die diversen 
Fassungen auf je eine andere LP und dazwischen ein Kabel. Also eine 
'Standard'-Schnittstelle erzeugen.

Kurzum, aus meiner Sicht hat sich in der Sache eigentlich sehr wenig 
bewegt.

Du scheinst derzeit voll beschäftigt zu sein mit der kommerziellen Seite 
der verbesserten Programmierer-Version. Und ich? Nun, irgendwann werde 
ich mich entscheiden müssen, ob ich mich (notfalls auf eigene Faust) mit 
diesen Chips (PFS1xx) weiter befasse, oder ob ich das Ganze in die Tonne 
befördere.

W.S.

von Max M. (maxmicr)


Bewertung
3 lesenswert
nicht lesenswert
Meine Güte gehst du mir auf den Geist.

von Tim  . (cpldcpu)


Bewertung
6 lesenswert
nicht lesenswert
W.S. schrieb:
>...

Nun ja, jedem seine Plaisierchen. Ich finde es auf jeden Fall nicht 
angemessen, sich ständig negativ über die Arbeit anderer auszulassen. 
Draussen scheint übrigens die Sonne!

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
> oder ob ich das Ganze in die Tonne
> befördere.

Lieber in die Tonne, dein Gift braucht keiner in diesem Projekt!

von Max M. (maxmicr)


Bewertung
2 lesenswert
nicht lesenswert
Padauk sucht einen Compiler-Entwickler für die GCC-Toolchain, vllt. gibt 
es dann in Zukunft Konkurrenz zum SDCC :D

https://www.104.com.tw/job/54bzn

: Bearbeitet durch User
von Tim  . (cpldcpu)


Bewertung
1 lesenswert
nicht lesenswert
Max M. schrieb:
> Padauk sucht einen Compiler-Entwickler für die GCC-Toolchain,
> vllt. gibt
> es dann in Zukunft Konkurrenz zum SDCC :D
>
> https://www.104.com.tw/job/54bzn

Interessant! Die Open Source Toolchain droht ja besser als deren eigene 
Tools zu werden. Jetzt müssen sie nachlegen :)

Anscheinend geht es aber nicht spezifisch um GCC, das war wahrscheinlich 
nur als Beispiel genannt. (sofern man Google-Translate hier trauen kann)

: Bearbeitet durch User
von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
2 lesenswert
nicht lesenswert
Max M. schrieb:
> Padauk sucht einen Compiler-Entwickler für die GCC-Toolchain, vllt. gibt
> es dann in Zukunft Konkurrenz zum SDCC :D
>
> https://www.104.com.tw/job/54bzn

"8/32 Bit MCU compilation and development tools."

Will Padauk in den 32-Bit-Markt einsteigen? Was käme da als Architektur 
in Frage?

Dienststelle Hsinchu.

Gehalt 40000 oder mehr.

Google translate sagt Yuan (Währung der Volksrep. China, das wären dann 
5000 € - ein überdurchscnittliches Monatsgehalt für Softwareentwickler 
dort).

Aber Dienstort ist Hsinchu in der Republik China, mit der dortigen 
Wöhrung TWD. 40000 TWD wären aber nur 1200 €, etwa die Hälfte eines 
durchschnittlichen Monatsgehalt für Softwareentwickler dort.

von Tim  . (cpldcpu)


Bewertung
1 lesenswert
nicht lesenswert
Philipp Klaus K. schrieb:
> Max M. schrieb:
>> Padauk sucht einen Compiler-Entwickler für die GCC-Toolchain, vllt. gibt
>> es dann in Zukunft Konkurrenz zum SDCC :D
>>
>> https://www.104.com.tw/job/54bzn
>
> "8/32 Bit MCU compilation and development tools."
>
> Will Padauk in den 32-Bit-Markt einsteigen? Was käme da als Architektur
> in Frage?

RISC-V? Eine 32 bit-Version der FPPA-Architektur kann man sich natürlich 
auch vorstellen. Allerdings wäre das schon ein etwas merkwürdiger 
Ansatz.

: Bearbeitet durch User
von Max M. (maxmicr)


Bewertung
1 lesenswert
nicht lesenswert
Philipp Klaus K. schrieb:
> Aber Dienstort ist Hsinchu in der Republik China, mit der dortigen
> Wöhrung TWD.

Hsinchu ist weiterhin in Taiwan. Taiwan nennt man auch "Republic of 
China (Taiwan)" während China auch "People's Republic of China" heißt.

Philipp Klaus K. schrieb:
> 40000 TWD wären aber nur 1200 €, etwa die Hälfte eines
> durchschnittlichen Monatsgehalt für Softwareentwickler dort.

Nach kurzer Google-Recherche sind 40k wohl ein durchschnittliches 
Monatsgehalt in Taiwan.

Edit: Scheint sogar etwas unterdurchschnittlich zu sein: 
https://www.statista.com/statistics/319845/taiwan-average-monthly-wage/#:~:text=Average%20monthly%20wage%20in%20Taiwan%202008%2D2018&text=This%20statistic%20depicts%20the%20average,49%2C989%20from%20the%20previous%20year.

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Max M. schrieb:
>> Aber Dienstort ist Hsinchu in der Republik China,
>> mit der dortigen Wöhrung TWD.
>
> Hsinchu ist weiterhin in Taiwan. Taiwan nennt man
> auch "Republic of China (Taiwan)" während China
> auch "People's Republic of China" heißt.

Das war schon korrekt so, der Unterschied ist zwischen "Republik China" 
(= Taiwan) und "Volksrepublik China" (= Festlandchina).

von Tim  . (cpldcpu)


Bewertung
1 lesenswert
nicht lesenswert
Ich würde es einfach neutral "Taiwan" nennen.

Hinter der Bezeichnung RoC steckt einiges an konfliktbehafteter 
Konotation:
https://en.wikipedia.org/wiki/Republic_of_China_(1912%E2%80%931949)

von Tim  . (cpldcpu)


Bewertung
1 lesenswert
nicht lesenswert
Philipp Klaus K. schrieb:
>> https://www.104.com.tw/job/54bzn
>
> "8/32 Bit MCU compilation and development tools."
> Gehalt 40000 oder mehr.
>
> Google translate sagt Yuan (Währung der Volksrep. China, das wären dann
> 5000 € - ein überdurchscnittliches Monatsgehalt für Softwareentwickler
> dort).
>
> Aber Dienstort ist Hsinchu in der Republik China, mit der dortigen
> Wöhrung TWD. 40000 TWD wären aber nur 1200 €, etwa die Hälfte eines
> durchschnittlichen Monatsgehalt für Softwareentwickler dort.

Ich denke es handelt sich hier um ein Mindestgehalt. Vielleicht muss so 
etwas in Taiwan ja angegeben werden? Ist z.B. in österreich auch so.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
1 lesenswert
nicht lesenswert
Tim  . schrieb:
> Ich würde es einfach neutral "Taiwan" nennen.
>
> Hinter der Bezeichnung RoC steckt einiges an konfliktbehafteter
> Konotation:
> https://en.wikipedia.org/wiki/Republic_of_China_(1912%E2%80%931949)

In den meisten Fällen ist das durchaus eine sinnvolle Lösung, die ich 
auch verwende.

"Taiwan" ist wie "China" und "Deutschland" gleichzeitig eine 
geographische und kulturelle Bezeichnung (und damit auch meistens dass, 
was man sagen will).
Wenn man aber von etwas spricht, bei dem es um die staatlichen Gebilde 
geht (wie hier die Währungen) ist es sinnvoll, deren Eigenbezeichnugen 
zu verwenden.

Wenn es in einem Text um "Mark" geht, und ich mich Frage, welche 
deutsche Währung gemeint ist, ist es ja auch sinnvoll, die Bezeichnungen 
"Bundesrepublik Deutschland" und "Deutsche Demokratische Republik" zu 
verwenden, wenn man von den beiden Staaten mit unterschiedlichen 
Währungen spricht.
Auch wenn "Deutsche Demokratische Republik" historisch eine umstrittene 
Bezeichnung war.

von Tim  . (cpldcpu)


Bewertung
1 lesenswert
nicht lesenswert
Philipp Klaus K. schrieb:
> Tim  . schrieb:
>> Ich würde es einfach neutral "Taiwan" nennen.
>>
>> Hinter der Bezeichnung RoC steckt einiges an konfliktbehafteter
>> Konotation:
>> https://en.wikipedia.org/wiki/Republic_of_China_(1912%E2%80%931949)
>
> In den meisten Fällen ist das durchaus eine sinnvolle Lösung, die ich
> auch verwende.
>
> "Taiwan" ist wie "China" und "Deutschland" gleichzeitig eine
> geographische und kulturelle Bezeichnung (und damit auch meistens dass,
> was man sagen will).
> Wenn man aber von etwas spricht, bei dem es um die staatlichen Gebilde
> geht (wie hier die Währungen) ist es sinnvoll, deren Eigenbezeichnugen
> zu verwenden.

Ja, das ist logisch richtig.

Gehört vielleicht nicht ganz hier hin: Nach meinem Verständnis 
impliziert "RoC" aber auch den seit dem zweiten Weltkrieg bestehenden 
Beherrschungsanspruch auf Gesamtchina.

Ich habe zumindet bisher noch nie einen Taiwaner von der RoC sprechen 
gehört, obwohl ich seit vielen Jahren unterschiedliche Kontakte dort hin 
habe.

Für mich klingt die Bezeichnung im allgemeinem Umgang höchst ungewohnt.

> Wenn es in einem Text um "Mark" geht, und ich mich Frage, welche
> deutsche Währung gemeint ist, ist es ja auch sinnvoll, die Bezeichnungen

Allerdings heisst die Währung auch "New Taiwan Dollar" (TWD).

: Bearbeitet durch User

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.