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


von Tim  . (cpldcpu)


Lesenswert?

Es geistert gerade ein Mikrocontroller für 0.03 USD durchs Netz:

https://www.youtube.com/watch?v=VYhAGnsnO7w
http://www.eevblog.com/forum/blog/eevblog-1132-the-3-cent-microcontroller!/


Hersteller:

http://www.padauk.com.tw/en/product/index.aspx

Distributor:

https://lcsc.com/products/PADAUK_11011.html?q=padauk

Den PMS150C gibt es in einer SOC23-6 Version für 0.03 USD/pc:

Datenblatt:
http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf

Die Architektur erinnert etwas an die kleineren PICs.

Die Hersteller sitzt in Taiwan und ist damit einigermaßen 
Vertrauenswürdig. Sämtliche Dokumentation ist auch auf Englisch 
verfügbar.

Hat damit schon jemand Erfahrungen gesammelt? Ist das Angebot echt, oder 
handelt es sich um einen Ausverkauf.

von Flash (Gast)


Lesenswert?

Ist zu teuer!

OTP war ja mal OK - aber heute?


Wenn du sub-$1 Spielzeug in Massen in .cn produzieren lässt: warum 
nicht?

von Christopher J. (christopher_j23)


Lesenswert?

Es gibt noch einen älteren Thread im EEVBlog-Forum: 
http://www.eevblog.com/forum/microcontrollers/interesting-microcontrollers-from-china-no-one-heard-about-how-to-use-them/?all

Und hier gibt es auch noch einen, der in etwa zeitgleich gestartet 
wurde:
Beitrag "Unbekannter Assembler erzeugt große Änderungen bei kleinem Programm"

Angeblich ist der PMS150C Bit-kompatibel zum PIC10F200 (von OTP va Flash 
abgesehen).

von Vka (Gast)


Lesenswert?

Die Frage ist nur: Warum?
Klar, Geiz ist geil. Aber sich da als Bastler drauf zu stürzen finde ich 
nur in wenigen Fällen sinnvoll.. z.B. wenn man selbst irgendwelche 
Massenware billig raushauen will. Ansonsten ist das Ding doch nur 
umständlich.

von Zero V. (Firma: Freelancer) (gnd)


Lesenswert?

Was kostet am meisten bei der Chipherstellung unabhängig von den 
Einmalkosten?
Ist es eher das Material wie Silizium oder Bonddrähte?
Oder die Arbeitszeit/Nutzungszeit der Maschinen beim Chiphersteller zum 
Belichten/Bonden/Verpacken?

Hat jemand dazu Infos?

Die 3 Cent erscheinen mir unrealistisch wenn ich das mit simplen 
Transistoren/Dioden vergleiche.
Aber die sparen wohl an der Werbung.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

Vka schrieb:
> Die Frage ist nur: Warum?

Aus dem gleichen Grund warum es Leute gibt die den Vatikan mit 
Streichhölzern nachbauen: Weil sie es können.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Mit den Biestern hat sich hier im Forum schon vor einiger Zeit jemand 
auseinandergesetzt:

Beitrag "Unbekannter Assembler erzeugt große Änderungen bei kleinem Programm"

von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
> Hat damit schon jemand Erfahrungen gesammelt? Ist das Angebot echt, oder
> handelt es sich um einen Ausverkauf.

Man kann zwar nicht ausschließen, dass es sich auf Seiten des 
Distributors LCSC um einen Ausverkauf handelt, aber:

* Die Preisrelationen stimmen - der PMS150C ist der einfachste im 
Sortiment von Padauk, einer mit doppelt so viel RAM, OTP, Takt kostet 
etwas das doppelte.
* der PMS150C ist auch im aktuellen (Q32018) Katalog von Padauk 
aufgeführt, ohne irgendeinen EOL-Vermerk.

Philipp

P.S.: Leider führt LCSC wohl nur die OTP-Varianten der Padauk-µC, und 
nur einen der Padauk Dualcore-µC.

P.P.S.: Das datenblatt des PMS150C wurde zuletzt im Januar diesen Jahres 
aktualisiert. Aus das spricht dafür, dass Padauk den noch länger 
anbieten will.

: Bearbeitet durch User
von Clemens L. (c_l)


Lesenswert?

D. C. schrieb:
> Was kostet am meisten bei der Chipherstellung unabhängig von den
> Einmalkosten?

Das Testen. Und eines der chinesisches Klischees ist, dass gerade dort 
gespart wird.

(Und wie wird ein OTP-µC getestet?)

von hinz (Gast)


Lesenswert?

Clemens L. schrieb:
> (Und wie wird ein OTP-µC getestet?)

Man kann den auch in ein Keramikgehäuse mit Quarzfenster setzen, dann 
ist der löschbar.

von Tim  . (cpldcpu)


Lesenswert?

Es scheint sich im Wesentlichen um eine PIC10F200 Nachbau zu handeln. 
Allerdings werden 10 Bit sprünge unterstützt und die Anzahl der Befehle 
ist größer. Anscheinend wurde die Befehlslänge etwas erhöht.

von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
> Es scheint sich im Wesentlichen um eine PIC10F200 Nachbau zu handeln.
> Allerdings werden 10 Bit sprünge unterstützt und die Anzahl der Befehle
> ist größer. Anscheinend wurde die Befehlslänge etwas erhöht.

Allein diesen Unterschieden nach würde ich nicht von einem Nachbau 
sprechen. Und dann gibt es noch zu bedenken:

* Die Padauk haben einen 8-bit Stapelzeiger, während der PIC einen 
Hardwarekeller mit nur 2 Einträgen hat.
* Die Padauk haben einen einheitlichen 8-bit-Adressraum für RAM.
* Bei Padauk gibt es interessantere Varianten (Dualcore).
* Für Padauk gibt es wohl keinen richtigen C-Compiler (nur so ein 
"Mini-C" oder so).

Philipp

von Philipp Klaus K. (pkk)


Lesenswert?

Padauk hat wohl große Pläne: idxm / ldxm erlauben den Zugriff auf einen 
16-bit-Adressraum für RAM. Und am Anfang des ROM wäre Platz für 
Startvektoren für bis zu 16 Cores.

Aber: Verglichen mit dem PIC mag Padauk ja eine schöne Architektur 
haben. Aber an einen STM8 oder Z80 kommt es halt doch nicht heran.
Irgendwie erinnert mich Padauk da an MCS-51: Es fehlt ein effizienter 
Zugriff auf den Kellerspeicher, und auch die Verwendung des 
16-bit-Adressraums ist umständlich.

Philipp

von Astronaut (Gast)


Lesenswert?

Zwar Interessant, macht preislich für Privatanwender und Firmen die 
nicht 10-tausende davon verbauen trotzdem keinen praktisch relevanten 
Unterschied im Vergleich zu ATtinys o.ä. (grob 25 €cent).

Und ob der Preis letztendlich real ist oder eher Marketing, bleibt 
abzuwarten.

von Werner S. (wernertrp)


Lesenswert?

... gibt es da auch eine Entwicklerversion für 30 Cent mit kleinem Flash 
?
Da könnte man Gehversuche machen bevor man die ersten 10 Millionen Stück 
bestellt.

von Philipp Klaus K. (pkk)


Lesenswert?

Werner S. schrieb:
> ... gibt es da auch eine Entwicklerversion für 30 Cent mit kleinem Flash
> ?
> Da könnte man Gehversuche machen bevor man die ersten 10 Millionen Stück
> bestellt.

Es gibt Varianten mit "MTP (Multiple Time Programmable)"-Speicher; aber 
selbst die kleinsten haben 50% mehr Programmspeicher als der PMS150C.
Leider scheinen sie bei LCSC nicht im Sortiment zu sein.

Aber abgesehen davon sieht der PFC151 nach einem Flash-Gegenstück zum 
PMS150C aus.

Philipp

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

Es gibt von Padauk zwei Patentapplikationen zu einem multi-threaded 
Microcontroller.

https://patents.google.com/patent/US20070067605
https://patents.google.com/patent/US20080126754A1

Das sieht dem XMOS-Konzept sehr ähnlich. Alle Cores/Threads teilen sich 
die Execution Pipeline per time-slicing. Um den Overhead so gering wie 
möglich zu halten, ist es von Vorteil, die States pro Thread zu 
reduzieren. Dafür bietet sich eine Akku-Speicher Architektur an, was 
wohl der Grund für die Anlehnung an den PIC ist.

Merkwürdig ist, dass beide Patente noch nicht erteilt wurden. Leider 
konnte ich nicht herausfinden warum. Evtl. war XMOS schneller?

Eigentlich eine sehr interessante Sache.

: Bearbeitet durch User
von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
> Es gibt von Padauk zwei Patentapplikationen zu einem multi-threaded
> Microcontroller.
>
> […]
>
> Eigentlich eine sehr interessante Sache.

Padauk hat auch schon 10 µC, die das implementieren (alle als 
Dualcore-Variante) im Sortiment, aber LCSC führt davon bisher nur den 
PMC232.

Philipp

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

Philipp Klaus K. schrieb:
> Tim  . schrieb:
>> Es gibt von Padauk zwei Patentapplikationen zu einem multi-threaded
>> Microcontroller.
>>
>> […]
>>
>> Eigentlich eine sehr interessante Sache.
>
> Padauk hat auch schon 10 µC, die das implementieren (alle als
> Dualcore-Variante) im Sortiment, aber LCSC führt davon bisher nur den
> PMC232.

Auf der Website finde ich nur den MCS11 mit 8 cores im 10 Pin Gehäuse.

http://www.padauk.com.tw/en/product/show.aspx?num=78
http://www.padauk.com.tw/upload/doc/MCS11_datasheet_v0%2020_20180420.pdf

Ich frage mich, was die 8 Threads machen sollen, wenn sie nicht nach 
"draussen" kommunizieren können?

Der MCS11 entählt interessanterweise auch einen Multiplier. Die 
Operanden und ein Teil des Ergebnisses sind allerdings auf (Speicher-) 
Register gemappt. Wie werden da Kollisionen von mehreren Threads 
verhindert?

von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
> Auf der Website finde ich nur den MCS11 mit 8 cores im 10 Pin Gehäuse.

Den MCS11 hatte ich nicht gefunden.

Ich schaue meist zuerst ins Katalog-.pdf 
(http://www.padauk.com.tw//upload/SelectionGuide/selection_guide_2018Q3..pdf),bevor 
ich mich zum Datenblatt durchklicke.

Philipp

von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
> Der MCS11 entählt interessanterweise auch einen Multiplier. Die
> Operanden und ein Teil des Ergebnisses sind allerdings auf (Speicher-)
> Register gemappt. Wie werden da Kollisionen von mehreren Threads
> verhindert?

Tim  . schrieb:
> Ich frage mich, was die 8 Threads machen sollen, wenn sie nicht nach
> "draussen" kommunizieren können?

Warum können sie nicht nach draußen kommunizieren? Sie können doch 
I/O-Pins lesen/schreiben, etc. Und sie können untereinander über den 
Speicher kommunizieren. Sieht nach einer brauchbaren Lösung für mehrere 
zeitkritische Aufgaben auf einem µC aus.

> Der MCS11 entählt interessanterweise auch einen Multiplier. Die
> Operanden und ein Teil des Ergebnisses sind allerdings auf (Speicher-)
> Register gemappt. Wie werden da Kollisionen von mehreren Threads
> verhindert?

Im Katalog gibt es Multiplizierer nur bei den Single-Core-µC.
Seltsamerweise fehlt im MCS11-Datenblatt der mul-Befehl, obwohl der Rest 
der Dokumentation des Multiplizierers vorhanden ist.

Philipp

P.S.: Man könnte im Speicher ein Spinlock für den Multiplizierer 
implementieren.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

>
> Warum können sie nicht nach draußen kommunizieren? Sie können doch
> I/O-Pins lesen/schreiben, etc. Und sie können untereinander über den
> Speicher kommunizieren.

Nun ja, es gibt 8 I/O pins und 8 Threads. Da bekommt jeder einen pin.
Allerdings ist der Hardwareoverhead pro Thread minimal, so dass es kaum 
verschwenderisch ist, die Option auf 8 Threads vozuhalten.

von Philipp Klaus K. (pkk)


Lesenswert?

Philipp Klaus K. schrieb:
> P.S.: Man könnte im Speicher ein Spinlock für den Multiplizierer
> implementieren.


lock:
mov a, spin_lock
ceqsn a, #0
goto lock
mov a, sp
mov spin_lock, a
ceqsn a, spin_lock
goto lock

…

unlock:
clear spin_lock

Overhead für lock: 6 Takte (falls kein anderer Thread den Multiplizierer 
nutzt), für unlock: 1 Takt.

Philipp

von Jack (Gast)


Lesenswert?

Clemens L. schrieb:
> Das Testen. Und eines der chinesisches Klischees ist, dass gerade dort
> gespart wird.
>
> (Und wie wird ein OTP-µC getestet?)

Der Test ist ganz einfach. Wenn das Produkt in dem der µC eingebaut wird 
funktioniert, dann funktioniert der µC. Wenn nicht wird das Produkt 
weggeworfen oder auf Aliexpress vertickt.

µC Testen, Eingangskontrolle oder gar Nacharbeiten ist alles zu teuer. 
Lieber gelegentlich etwas Ausschuss produzieren.

Astronaut schrieb:
> Und ob der Preis letztendlich real ist oder eher Marketing, bleibt
> abzuwarten.

Der Preis ist real und in China für direkte Abnehmer noch niedriger. 
LCSC ist ein Händler der selber noch etwas dran verdienen muss.

Was glaubst du, was in 2 Euro Spielzeugautos mit vielleicht 25 Ct 
Produktionskosten zum Blinken von ein paar LED und ein bisschen 
Geräusche machen verbaut wird? Kein 25 Cent Atmel.

Mysteriöse 8-Pin µCs der 3 Cent-Klasse mit fragwürdiger Zuverlässigkeit 
findest du zu Hauf in chinesischen Gadgets und Spielzeug. Schau dir mal 
ein paar Teardowns von Gadget-Bloggern an. Wenn irgendwas nur ein paar 
Knöpfe oder LEDs hat, dann ist so ein µC drin.

https://youtu.be/PYPk-60-MfQ?t=196 £5 für drei fernsteuerbare LED-Lampen 
und eine Fernbedienung. Herstellungskosten der Fernbedienung vielleicht 
50 Cent (egal ob Euro-Cent, US-Cent oder £-Cent). Mysteriöser 8-Pin µC 
in der Fernbedienung. Ob das jetzt ein PMS150C ist weiß man nicht, aber 
sehr wahrscheinlich was vergleichbares.

Bevor die ganzen Snobs hier so meckern sollten sie vielleicht mal eine 
Tour durch die eigenen Wohnung machen und sich ansehen was sie an 
Gadgets und Spielzeugen haben.

Bei der nächsten Diskussion warum man heutzutage alles mit einem µC 
machen muss, schließlich tut es der NE555 zum Blinken von LEDs auch, 
einfach mal auf dem Preis schauen und den Stromverbrauch nicht 
vergessen.

von Tim  . (cpldcpu)


Lesenswert?

Das könnte man mit dedizierten Befehlen noch deutlich vereinfachten. 
XMOS scheint da besser durchdacht zu sein. Der Charme liegt bei Padauk 
in der minimalen Implementation der MCU.

von Astronaut (Gast)


Lesenswert?

Jack schrieb:
> Der Preis ist real und in China für direkte Abnehmer noch niedriger.
> LCSC ist ein Händler der selber noch etwas dran verdienen muss.


Es sind dort aktuell aber keine auf Lager und der Preis richtet sich 
auch nach der Nachfrage - kann sich also durchaus ändern. Auch später, 
nachdem der Chip in genug Produkten eingesetzt wird. Das meinte ich 
damit.

von Philipp Klaus K. (pkk)


Lesenswert?

Jack schrieb:
> Clemens L. schrieb:
>> Das Testen. Und eines der chinesisches Klischees ist, dass gerade dort
>> gespart wird.
>>
>> (Und wie wird ein OTP-µC getestet?)
>
> Der Test ist ganz einfach. Wenn das Produkt in dem der µC eingebaut wird
> funktioniert, dann funktioniert der µC. Wenn nicht wird das Produkt
> weggeworfen oder auf Aliexpress vertickt.
>
> µC Testen, Eingangskontrolle oder gar Nacharbeiten ist alles zu teuer.
> Lieber gelegentlich etwas Ausschuss produzieren.


Und warum gibt es dann im Organigramm von Padauk 
(http://www.padauk.com.tw/en/about/index.aspx?kind=12) Abteilungen 
"Quality Assurance" und "Product & Testing Engineering"?

Philipp

von MaWin (Gast)


Lesenswert?

Vka schrieb:
> Klar, Geiz ist geil. Aber sich da als Bastler drauf zu stürzen finde ich
> nur in wenigen Fällen sinnvoll

Wie kommst du darauf, dass hier nur Bastler sind ?

Für DICH ist ein OTP unsinnig, ok, nimm den PIC.

D. C. schrieb:
> Was kostet am meisten bei der Chipherstellung unabhängig von den
> Einmalkosten

Chipfläche, Anzahl der Metallisierungslagen, spezielle 
Herstellungsmethoden (FinFET).

Wenn der Chip so klein wie ein MOSFET ist (z.B. GS2304 on SOT23), kann 
er auch so wenig kosten wie ein MOSFET.

von Harald A. (embedded)


Lesenswert?

Vka schrieb:
> Die Frage ist nur: Warum?
> Klar, Geiz ist geil.

Du nennst im ersten Atemzug genau das Argument, was sicherlich keiner 
der Interessenten auf dem Schirm hat...

Es tut sich m.E. nach derzeit eine Menge im Chipmarkt. Seit zig Jahren 
scheint es völlig klar, wer aktive Halbleiter baut bzw. entwickelt: 
Amerikaner, Japaner und Europäer. Wer in diesen Tagen aktuelle 
chinesische Produkte analysiert, stellt fest, dass einem immer weniger 
der bekannten Herstellerlogos unter die Lupe kommen. Neben 
Billigst-Gadgets sind auch schon „höherwertige“ Produkte wie 
Bluetooth-Geräte aus China vollkommen frei von bekannten Herstellern. 
Dave Jones hat ja im Video gezeigt, was sich so bei LCSC an Herstellern 
tummelt und was es da alles an Komponenten gibt. Beliebtes Beispiel für 
mich ist z.B. der PT4115, ein LED-Treiber für bis zu 30W Leistung für 
<4Cent. Suche das mal bei den Etablierten...

Kurzum: Für mich macht eine Auseinandersetzung mit der für uns „neuen 
Welt“ absolut Sinn, da gibt es zahlreiche Beispiele an sinnloseren 
Hobbies. Der Reiz ist doch, ein Verständnis dafür zu entwickeln, wie es 
möglich ist, Elektronik für 1/10 oder 1/100 der uns bekannten Kosten auf 
die Beine zu stellen.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

Clemens L. schrieb:
> D. C. schrieb:
>> Was kostet am meisten bei der Chipherstellung unabhängig von den
>> Einmalkosten?
>
> Das Testen. Und eines der chinesisches Klischees ist, dass gerade dort
> gespart wird.
>
> (Und wie wird ein OTP-µC getestet?)

Harald A. schrieb:
> Wer in diesen Tagen aktuelle
> chinesische Produkte analysiert, stellt fest, dass einem immer weniger
> der bekannten Herstellerlogos unter die Lupe kommen. Neben
> Billigst-Gadgets sind auch schon „höherwertige“ Produkte wie
> Bluetooth-Geräte aus China vollkommen frei von bekannten Herstellern.


An dieser Stelle ist es wahrscheinlich sinnvoll, darauf hin zu weisen 
dass Padauk eine Firma aus Taiwan und nicht China ist. Aus Taiwan kommen 
schon seit über 30 Jahren qualitativ hochwertige Halbleiter. U.A. sitzt 
die weltgrößte Foundry dort, TSMC.

Die Taiwanesischen Fabless Firmen stehen allerdings gerade unter 
massivem Druck aus China, da ihnen dort lokale Firmen ihren Hauptmarkt 
streitig machen.

: Bearbeitet durch User
von Mehmet K. (mkmk)


Lesenswert?

Harald A. schrieb:
> Beliebtes Beispiel für mich ist auch der PT4115

Wobei ich mit diesem keine so prickelnde Erlebnisse hatte. Ein HV9910 
tat das, was im Datenblatt stand. Der PT4115 begann stets zu flackern, 
wenn die Spannung über 22V stieg. Und da konnte ich noch so sehr andere 
Spulen einsetzen wie ich wollte.
Dasselbe mit BL8530: unschlagbarer Preis. Aber hin und wieder 
sporadisches Stottern. Bin wieder ganz schnell zum MCP1640DT 
zurückgekehrt.

Was ich damit sagen will: man muss schon wissen, was man beim Chinesen 
einkauft.
Und wer keine grösseren Mengen umsetzt und den Groschen nicht zweimal 
wenden muss, faehrt vermutlich mit den etablierten Herstellern 
sorgenfreier durchs Leben.

von Harald A. (embedded)


Lesenswert?

Ja, das ist richtig, Taiwan ist technologisch ne ganz andere Liga als 
China.

Der Bluetooth-Chipsatz-Hersteller, den ich oben anführte, kommt aber 
z.B. tatsächlich aus Shenzhen. Noch vor wenigen Jahren dominierte hier 
der Hersteller CSR aus England, heute sieht man fast nur noch den 
Hersteller, dessen ICs mit „JL“ gebrandet sind.

von Harald A. (embedded)


Lesenswert?

Mehmet K. schrieb:
> Harald A. schrieb:
>> Beliebtes Beispiel für mich ist auch der PT4115
>
> Der PT4115 begann stets zu flackern,
> wenn die Spannung über 22V stieg. Und da konnte ich noch so sehr andere
> Spulen einsetzen wie ich wollte.

Gerade noch ein Projekt gemacht, wo allein 48 Stück davon auf einem 
Board sind. Systemspannung ist hier 24V. Auch im Klimaschrank -30...+70 
nicht auffällig. Dimming wurde auch genutzt.

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


Lesenswert?

Harald A. schrieb:
> Ja, das ist richtig, Taiwan ist technologisch ne ganz andere Liga als
> China.

Wobei streng genommen ja beides China ist.
China == "Volksrepublik China"
Taiwan == "Republik China".

von MaWin (Gast)


Lesenswert?

S. R. schrieb:
> Wobei streng genommen ja beides China ist

Das sieht China auch so.

https://de.m.wikipedia.org/wiki/Taiwan-Konflikt

von Tim  . (cpldcpu)


Lesenswert?

MaWin schrieb:
> S. R. schrieb:
>> Wobei streng genommen ja beides China ist
>
> Das sieht China auch so.
>
Das sieht nur China so.

von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
> MaWin schrieb:
>> S. R. schrieb:
>>> Wobei streng genommen ja beides China ist
>>
>> Das sieht China auch so.
>>
> Das sieht nur China so.

Aber da Taiwan ja auch China ist, sieht auch Taiwan das so.

Von außen betrachtet mag das anders aussehen.

Philipp

P.S.: Soweit ich weiß, sehen formal beide sich jeweils als "China" und 
die anderen als abtrünnig. Aber schließlich ist die Frage so müßig wie 
die ob BRD bzw. DDR "Deutschland" waren.

: Bearbeitet durch User
von Mach (Gast)


Lesenswert?

Ich weiss noch, dass in den 90ern sehr viele Artikel (nicht nur 
Elekronik) aus Taiwan waren. Made in China war da noch gar nicht so 
verbreitet. Heute gibts fast nichts mehr aus Taiwan bei uns in den 
Regalen. Das Kapital ist weitergezogen...

von Mehmet K. (mkmk)


Lesenswert?

Harald A. schrieb:
> Systemspannung ist hier 24V.

Der Strom waere noch von Interesse. Bei mir waren's 300mA.

von S. R. (svenska)


Lesenswert?

Tim  . schrieb:
>>> Wobei streng genommen ja beides China ist
>> Das sieht China auch so.
> Das sieht nur China so.

Und damit so ziemlich jedes Land der Welt, was mit der Volksrepublik 
diplomatische Beziehungen pflegen will.

Philipp Klaus K. schrieb:
> Soweit ich weiß, sehen formal beide sich jeweils als "China" und
> die anderen als abtrünnig.

Taiwan beansprucht Festlandchina schon länger nicht mehr. Sie schreiben 
es aber auf Druck von China nicht offiziell fest, weil das von Seiten 
der Volksrepublik als Akt der Abtrünnigkeit gesehen würde.

Mach schrieb:
> Ich weiss noch, dass in den 90ern sehr viele Artikel (nicht nur
> Elekronik) aus Taiwan waren.

Das ist auch nach wie vor so. Aber ein Land von der Größe 
Baden-Württembergs kann gegen das Monsterwachstum von China (und Indien) 
nicht gerade anstinken.

Clemens L. schrieb:
> D. C. schrieb:
>> Was kostet am meisten bei der Chipherstellung
>> unabhängig von den Einmalkosten?
> Das Testen. Und eines der chinesisches Klischees ist,
> dass gerade dort gespart wird.

Dort wird nur gespart, wenn die Kosten für den Test größer sind als die 
Kosten eines gelegentlichen Ausschussprodukts. Das ist eine rein 
marktwirtschaftliche Abwägungssache - Apple produziert auch in China und 
hat (dort!) definitiv eine bessere Endkontroller als viele andere.

Davon abgesehen habe ich bisher noch kein komplett totes China-Gerät 
erhalten. Fälschungen (im Sinne von: so gepatcht, dass es richtig 
aussieht) schon, aber auch die haben (teilweise) funktioniert. Dank 
der kleinen Preise sind die Margen geringer und damit auch die Skrupel.

> (Und wie wird ein OTP-µC getestet?)

Wie andere Chips auch. Wenn die Ausschussquote klein genug ist 
(Stichprobenkontrolle), dann reicht ein kurzer Test für die gröbsten 
Probleme. Ich kann mir irgendwie nicht vorstellen, dass z.B. jeder Timer 
jeden Controllers auf jede erdenkliche Art geprüft wird - sowas frisst 
Zeit.

Während der Herstellung kommt man zudem noch an interne Testpunkte ran, 
mit denen man die Funktionsfähigkeit prüfen kann - und könnte das EPROM 
auch wieder löschen. :-)

von Harald A. (embedded)


Lesenswert?

Mehmet K. schrieb:
> Harald A. schrieb:
>> Systemspannung ist hier 24V.
>
> Der Strom waere noch von Interesse. Bei mir waren's 300mA.

Hallo Mehmet, bei mir waren es ca. 100mA, allerdings habe ich das Ding 
auch schon in zahlreichen Arbeitsleuchten verbaut gesehen (daher kannte 
ich den auch ursprünglich), die arbeiten auch mit 350 oder 700mA und 
funktionieren auch hervorragend.
Wollen wir es dabei belassen, dann können wir uns alle wieder dem 
eigentlichen Thema widmen...

von Harald A. (embedded)


Lesenswert?

Hat schon jemand den Compiler installiert? Bei Dave im Video schien die 
Installation ja recht überschaubar. Ich werde mir das mal anschauen.

von Harald A. (embedded)


Lesenswert?

Astronaut schrieb:
> Jack schrieb:
>> Der Preis ist real und in China für direkte Abnehmer noch niedriger.
>> LCSC ist ein Händler der selber noch etwas dran verdienen muss.
>
>
> Es sind dort aktuell aber keine auf Lager und der Preis richtet sich
> auch nach der Nachfrage - kann sich also durchaus ändern. Auch später,
> nachdem der Chip in genug Produkten eingesetzt wird. Das meinte ich
> damit.

Habe gerade mal etwas auf 1688.com recherchiert, taobao.com will leider 
plötzlich ne Registierung, bevor die Suche startet (schade)

https://s.1688.com/selloffer/offer_search.htm?keywords=pms150c

Hier entdeckt man den teilweise ab 1 Stück(!) für 0,1RMB an, das sind 
dann sogar nur 1,2 Eurocent. Totaler Wahnsinn.


Update:
Den PMS132 mit 12x 12bit ADC gibt es dort ebenfalls für 1,2Cent:
https://detail.1688.com/offer/571529949541.html

: Bearbeitet durch User
von Harald A. (embedded)


Lesenswert?

Also die IDE ist wirklich sehr kompakt (3.9MB) und direkt startbar. 
Alles wie gewohnt, "New Project", Prozessor einstellen, Takt, BrownOut 
usw, dann erscheint das erste Grundgerüst in "Mini-C"

Unter Code-Generator gibt es fertige Snippets für SPI, UART, I2C usw., 
die man in die Zwischenablage kopiert.

Mit Build wird dann aus dem "Mini-C" wird dann ein Assembler-File 
compiliert.

Leider kommt ich noch nicht weiter mit den Definitionen aus dem 
Code-Generator. Die Definitionen werden als nicht korrekt angemeckert.

Einfach mal ausprobieren, tut nicht weh.

von Christopher J. (christopher_j23)


Lesenswert?

Harald A. schrieb:
> Hier entdeckt man den teilweise ab 1 Stück(!) für 0,1RMB an, das sind
> dann sogar nur 1,2 Eurocent. Totaler Wahnsinn.

Bei den Preisangaben muss man immer auch die Versandkosten mit 
berücksichtigen. Bei Taobao habe ich schon öfter mal absurd günstige 
Angebote gesehen, bei denen die Versandkosten ebenso absurd hoch waren.

von Harald A. (embedded)


Lesenswert?

Christopher J. schrieb:

> Bei Taobao habe ich schon öfter mal absurd günstige
> Angebote gesehen, bei denen die Versandkosten ebenso absurd hoch waren.

Yo, das stimmt wohl. Aber es gibt in der Liste ja zahlreiche Angebote, 
die den Chip auch in niedrigen Summe in beliebigen Stückzahlen anbieten. 
Das entkräftet ja zumindest die Sichtweise, dass es sich nur um einen 
Marketing-Gag handelt. Schließlich ist der Chip auch schon ein paar 
Jahre alt.

Ich habe jetzt kein konkretes Interesse an einer Bestellung, aber man 
könnte das bei einem Kaufagenten wie Yoybuy.com mal durchspielen, wie 
hoch die tatsächlichen Kosten inkl. Domestic-Versand sind. 
International-Versand und Yoybuy-Provision käme dann auch noch oben 
drauf. Könnte man den Programmer gleich mitbestellen.

*Update:
Habe die Seite mit den 0.1RMB mal übersetzt: Es handelt sich um einen 
"Referenzpreis", man soll für den Realpreis den Anbieter direkt mit 
einer konkreten Stückzahl anfragen. Also sind die anderen Preise in der 
Liste realer. Da sind aber auch die <= 3 Cent realistisch.

: Bearbeitet durch User
von 0804 (Gast)


Lesenswert?

Harald A. schrieb:
> Vka schrieb:
>> Die Frage ist nur: Warum?
>> Klar, Geiz ist geil.
>
> Du nennst im ersten Atemzug genau das Argument, was sicherlich keiner
> der Interessenten auf dem Schirm hat...
>
> Es tut sich m.E. nach derzeit eine Menge im Chipmarkt. Seit zig Jahren
> scheint es völlig klar, wer aktive Halbleiter baut bzw. entwickelt:
> Amerikaner, Japaner und Europäer. Wer in diesen Tagen aktuelle
> chinesische Produkte analysiert, stellt fest, dass einem immer weniger
> der bekannten Herstellerlogos unter die Lupe kommen. Neben
> Billigst-Gadgets sind auch schon „höherwertige“ Produkte wie
> Bluetooth-Geräte aus China vollkommen frei von bekannten Herstellern.
> Dave Jones hat ja im Video gezeigt, was sich so bei LCSC an Herstellern
> tummelt und was es da alles an Komponenten gibt. Beliebtes Beispiel für
> mich ist z.B. der PT4115, ein LED-Treiber für bis zu 30W Leistung für
> <4Cent. Suche das mal bei den Etablierten...
>
> Kurzum: Für mich macht eine Auseinandersetzung mit der für uns „neuen
> Welt“ absolut Sinn, da gibt es zahlreiche Beispiele an sinnloseren
> Hobbies. Der Reiz ist doch, ein Verständnis dafür zu entwickeln, wie es
> möglich ist, Elektronik für 1/10 oder 1/100 der uns bekannten Kosten auf
> die Beine zu stellen.

Wohne selber in Taiwan und wir haben wirklich eine tolle Infrastruktur 
im Elektronik Bereich.
Zudem können wir auch noch auf China zum Spottpreis und mit einer super 
Lieferzeit zurückgreifen.
Als Techniker ist man in Taiwan besser aufgehoben als in Europa, dafür 
ist Europa wieder ein einfacherer Absatzmarkt.
Taiwan lebt ja mehr oder weniger vom Export, man schaue sich nur an 
welche und wie viele Autos in Taiwan unterwegs sind - diese werden alle 
importiert und das Geld muss auch irgendwo herkommen.

Ein großer Pluspunkt für die Gesellschaft ist dass der Staat die kleinen 
Unternehmen nicht so abwürgt wie in Deutschland, man lässt sie einfach 
machen und dann gibt's halt mal Unternehmen oder kleine Selbstständige 
welche keine Steuern zahlen - immer noch besser als Arbeitslose. Für die 
Gesellschaft finde ich diese Struktur sehr wichtig. Seit ich das kenne 
empfinde ich Deutschland nur noch kalt, euch werden ohne Ende Steine in 
den Weg geworfen. Natürlich kann man in Deutschland auch gut leben, aber 
warum sollte man es sich so schwierig machen im Leben.
Vielleicht sind das noch die Gene der ehemaligen Monarchie die sich in 
Deutschland nicht ausrotten lassen.

von Stromverdichter (Gast)


Lesenswert?

Mich würde viel eher ein Controller interessieren, den ich normal in C 
programmieren kann. Compiler sollte auch frei verfügbar sein, z.B. gcc 
oder sdcc. Da fällt mir im Moment nur der Nuvoton N76 mit 18kB FLASH und 
1kB RAM für 25Cent ein. Damit kann man den ganzen Kleinkram erschlagen. 
Kennt da jemand etwas günstigeres mit freiem C-Compiler 
programmierbares?
https://direct.nuvoton.com/en/n76e003at20

von Harald A. (embedded)


Lesenswert?

Stromverdichter schrieb:
> Nuvoton N76 mit 18kB FLASH und 1kB RAM für 25Cent ein.

Wird bei 1688.com mit etwas über 1RMB gehandelt:
https://s.1688.com/selloffer/offer_search.htm?keywords=nuvoton+n76

Billiger wird es aufgrund der ARM-Lizenz vermutlich nicht mehr. Aber ARM 
war ja auch nicht dein Kriterium, oder?

*Update: Sorry, ist ja kein ARM. Damit hatte ich Nuvoton schon 
automatisch in Verbindung gebracht. Aber 8051 geht ja auch mit dem SDCC 
Compiler, der ist ja mittlerweile nicht mehr so schlecht.

: Bearbeitet durch User
von Philipp Klaus K. (pkk)


Lesenswert?

Stromverdichter schrieb:
> Mich würde viel eher ein Controller interessieren, den ich normal in C
> programmieren kann. Compiler sollte auch frei verfügbar sein, z.B. gcc
> oder sdcc. Da fällt mir im Moment nur der Nuvoton N76 mit 18kB FLASH und
> 1kB RAM für 25Cent ein. Damit kann man den ganzen Kleinkram erschlagen.
> Kennt da jemand etwas günstigeres mit freiem C-Compiler
> programmierbares?
> https://direct.nuvoton.com/en/n76e003at20

MCS-51-Derivate gibt es auch billig von STC und SiLabs. Den AVR gibt es 
auch noch.

Die kleineren STM8 kosten auch nicht viel, und sind deutlich 
C-freundlicher als die MCS-51-Derivate.

Philipp

von Max M. (maxmicr)


Lesenswert?

Versandkosten von Yoybuy.com sind ca. 10€ mit der günstigsten 
Versandoption. Ich hab 150 Stück des PMS150C hier, nebst ICE und 
Programmiergerät. Der ICE funktioniert einwandfrei und damit lässt sich 
die Software gut testen bevor man sie auf einen OTP uC überspielt. 
Leider relativieren ICE und Programmer den sehr günstigen 
Controller-Preis wieder etwas da beide jeweils ca 70€ kosten, sofern ich 
das von damals noch richtig im Kopf hab.

Leider bin ich mangels Zeit aufgrund von Praxissemester noch nicht dazu 
gekommen, eine einfache Starter-Platine zu designen und einen PMS150C 
mal zu programmieren.

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

Hannes J. schrieb:
> Vka schrieb:
>> Die Frage ist nur: Warum?
>
> Aus dem gleichen Grund warum es Leute gibt die den Vatikan mit
> Streichhölzern nachbauen: Weil sie es können.

Meinst du vielleicht den Petersdom?

von Harald A. (embedded)


Lesenswert?

Max M. schrieb:
> Versandkosten von Yoybuy.com sind ca. 10€ mit der günstigsten
> Versandoption. Ich hab 150 Stück des PMS150C hier, nebst ICE und
> Programmiergerät. Der ICE funktioniert einwandfrei und damit lässt sich
> die Software gut testen bevor man sie auf einen OTP uC überspielt.

Das hört sich gut an!

> Leider relativieren ICE und Programmer den sehr günstigen
> Controller-Preis wieder etwas da beide jeweils ca 70€ kosten, sofern ich
> das von damals noch richtig im Kopf hab.
>

Tja, aus Kostengründen kann man sich das sowieso nicht antun, bevor man 
nicht vorhat, irgendeine Stückzahl >10..100k aufzulegen. Wenn nicht aus 
reinem Interesse - warum sollte man sich freiwillig in die 90er 
zurückkatapultieren? Für die meisten dürfte es reine Befriedigung der 
Neugier sein, wie weit man mit einem 3Cent Controller kommen kann.

von Philipp Klaus K. (pkk)


Lesenswert?

Max M. schrieb:
> Versandkosten von Yoybuy.com sind ca. 10€ mit der günstigsten
> Versandoption. Ich hab 150 Stück des PMS150C hier, nebst ICE und
> Programmiergerät. Der ICE funktioniert einwandfrei und damit lässt sich
> die Software gut testen bevor man sie auf einen OTP uC überspielt.
> Leider relativieren ICE und Programmer den sehr günstigen
> Controller-Preis wieder etwas da beide jeweils ca 70€ kosten, sofern ich
> das von damals noch richtig im Kopf hab.
>
> Leider bin ich mangels Zeit aufgrund von Praxissemester noch nicht dazu
> gekommen, eine einfache Starter-Platine zu designen und einen PMS150C
> mal zu programmieren.

Statt des ICE eine Flash-Variante des Padauk für 4 Cent zu nehmen dürfte 
da die Kosten deutlich senken.

Philipp

P.S.: Aber ein Entwicklungsboard zu haben wäre schon gut.

: Bearbeitet durch User
von Philipp Klaus K. (pkk)


Lesenswert?

Astronaut schrieb:
> Jack schrieb:
>> Der Preis ist real und in China für direkte Abnehmer noch niedriger.
>> LCSC ist ein Händler der selber noch etwas dran verdienen muss.
>
>
> Es sind dort aktuell aber keine auf Lager und der Preis richtet sich
> auch nach der Nachfrage - kann sich also durchaus ändern. Auch später,
> nachdem der Chip in genug Produkten eingesetzt wird. Das meinte ich
> damit.

Nun sind sie wieder verfügbar. Der Preis ist um 21% auf 0.046$ 
gestiegen.

Philipp

von Tim  . (cpldcpu)


Lesenswert?

Ich habe mir die Padauk und PIC-Architektur noch einmal im Vergleich 
angeschaut. Es gibt schon einige Unterschiede, vor allem um den Core 
"Multithreading"-tauglich zu machen.

 - Die Registeranzahl es ähnlich. Es gibt Accu (W beim PIC), Flags (C, 
DC, Z), PC und SP
 - RAM und I/O area wurden getrennt und lassen sich über separate 
Befehle ansprechen.
 - Indirekte Speicherzugriffe werden nicht mehr über die Registerbank 
sonder über einen dedizierten Behehl ausgeführt (ldxm). Die Adresse wird 
dazu an einer anderen Position im Speicher abgelegt.
 - Tabellenzugriffe im Codespeicher: Funktionieren beim PIC mit RETLW. 
Bei Padauk gibt es einen ähnlichen Befehler. Im Unterschie ist 
allerdings der PC nicht über I/O gemappt, sondern es gib einen Befehl 
für indizierte Sprünge (pcadd a)
 - Um Unterschied zum PIC, hat der Padauk einen ins RAM gemappten Stack 
und einen echten Stack Pointer. Zusätzliche lassen sich akku und flags 
auf dem Stack speichern (das geht erst bei den größeren PICs). 
Merkwürdigerweise lässt sich der SP nur über die I/O Area adressieren. 
Es ist unklar, ob sich alle Threads einen SP teilen, oder ob jeder einen 
eigenen hat.

Abgesehen von den Änderungern zum Multithreading ist der Befehlssatz 
eher mit den midrange PICs zu vergleichen. Da es noch einige zusätzliche 
Befehle gibt, würde ich von einen 15 oder 16bit instruction encoding 
ausgehen.

Prinzpiell bekommt man eine Menge fürs Geld, wenn man mit einem 
PIC-artigen µC arbeiten mag.

von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
> Es ist unklar, ob sich alle Threads einen SP teilen, oder ob jeder einen
> eigenen hat.

Aus dem "Hardware and Timing Diagram of FPP units" in den Datenblättern 
ist ersichtlich, dass jede FPP unit einen eigenen SP hat.

Was mir bei Padauk am meisten fehlt, ist ein SP-relativer 
Adressierungsmodus. Es gibt außer A keine für lokale Variablen nutzbaren 
Register; dadurch werden reentrante Funktionen sehr ineffizient.

Philipp

von Tim  . (cpldcpu)


Lesenswert?

Philipp Klaus K. schrieb:
> Was mir bei Padauk am meisten fehlt, ist ein SP-relativer
> Adressierungsmodus. Es gibt außer A keine für lokale Variablen nutzbaren
> Register; dadurch werden reentrante Funktionen sehr ineffizient.

Im Vergleich zum PIC ist die aktuelle Implementierung allerdings schon 
ein großer Fortschritt. Der PIC verwendet einen getrennten HW-Stack  mit 
sehr wenigen Eintragen für die Rücksprungadressen. Das Speichern von 
Akku und Flags auf einem getrennten Softwarestack ist erst in den 
größeren Varianten möglich.

Insgesamt ist mir beim Vergleich noch einmal die Gesamte Grausamkeit des 
PICs klar geworden. Wie sich so etwas in dem Maße durchsetzen konnte, 
bleibt (mir) rätselhaft.

von neuer PIC Freund (Gast)


Lesenswert?

>Wie sich so etwas in dem Maße durchsetzen konnte, bleibt (mir) rätselhaft.

Frei nach Pispers: "Es liegt am Preis"

;-)

von Dr. Sommer (Gast)


Lesenswert?

neuer PIC Freund schrieb im Beitrag #5611725:
> Frei nach Pispers: "Es liegt am Preis"

Wie kommt das eigentlich? Bewirken die genannten Einschränkungen 
(Hardware-Stack usw.) so eine drastische Einsparung bei der Produktion?

von neuer PIC Freund (Gast)


Lesenswert?

Naja. Wenn ich als Kleinunternehmer z.B. bei digikey einkaufen muss, 
sortier ich halt erstmal alle aktiven und lieferbaren Controller. Dann 
wähl ich 100Stück aus, sortier nach Preis und finde einen µC, welcher 
mächtig genug ist, mein Problem zu lösen. Bei vielen Aufgaben ist das 
halt kein Cortex-M7, sondern ein kleiner 8-bitter, der von Atmel/MCHP 
kommt.

Und das der krokelige PIC-Kern rumröteln muss, stört auch nicht, wenn 
man weiß, dass die Amateure an dieser Stelle alles mit _delay_ms() 
zupflastern.

Nimmt man dann noch einen der neueren PICs, freut man sich über PPS beim 
layouten.

von Dr. Sommer (Gast)


Lesenswert?

neuer PIC Freund schrieb im Beitrag #5611740:
> Kleinunternehmer

neuer PIC Freund schrieb im Beitrag #5611740:
> Amateure

Na sowas :-)

von Harald (Gast)


Lesenswert?

Tim  . schrieb:
> Wie sich so etwas in dem Maße durchsetzen konnte, bleibt (mir)
> rätselhaft.

Aus damaliger Sicht war es zunächst einmal der sehr günstige Preis, für 
kleine Aufgaben waren die genial. Alternative waren die 8051, 68HC11 
usw. - allesamt mit extra Speicher und 100cm2 Fläche auf dem Board.

In ähnlicher Sicht muss man vielleicht auch die Padauk sehen. Derjenige, 
der mal so 3 Tasten und 3 LEDs steuern will wird sich wenig Gedanken 
über die genaue Architektur machen. Mini-C aus der IDE wird verwendet 
und gut ist. Wenn die Kiste nicht reicht wird halt ein besserer 
Controller genommen.

von W.S. (Gast)


Lesenswert?

Tim  . schrieb:
> Insgesamt ist mir beim Vergleich noch einmal die Gesamte Grausamkeit des
> PICs klar geworden. Wie sich so etwas in dem Maße durchsetzen konnte,
> bleibt (mir) rätselhaft.

Du hast einfach nur die innere Eleganz des PIC-Ansatzes nicht 
verstanden.

Die kleinen PIC's sind für Assembler-Programmierung gedacht. Und da sind 
sie wirklich erste Klasse: kein load-modify-store sondern Operationen 
direkt im RAM, ein supersauschneller Stack dank Hardware und eine in 
vielen Details sehr pfiffige Peripherie. Und eben ein 
Maschinen-Befehlssatz, der angenehm übersichtlich und dennoch recht 
effektiv ist.

Wer jedoch um alles, was Assembler heißt, einen weiten Bogen macht und 
partout auf allen Plattformen nur C gelten läßt, dem verschließt sich 
die Architektur der kleinen PIC's.

Das ist klar.

Es ist heutzutage auch ein bissel anders geworden in der µC Szene, 
schließlich sind seit dem breiten Aufkommen der PIC's rund 25 Jahre ins 
Land gegangen und man kriegt jetzt nen 32 Bitter für weniger Geld als 
damals nen PIC16Cxxx.

Dennoch bleiben einige HW-Merkmale der PIC's, die man auch heutzutage 
noch mit der Lupe suchen muß. Der asynchrone Vorteiler vor dem Timer0 
zum Beispiel, der geradezu einlädt, um damit Frequenzzähler zu bauen - 
weil er eben asynchron zählt und kein samplender Eingang ist wie ein 
gewöhnlicher Counter-Eingang, bei dem deshalb das Abtast-Theorem 
zuschlägt. Ebenso die ungewöhnlich kräftigen Pintreiber, die mühelos mal 
eben 25 mA oder noch etwas mehr vertragen.

Kurzum, diese inzwischen recht alte Architektur ist von einer 
Versatilität und "Knuffigkeit", die man woanders vergeblich sucht. Aber 
man muß sich eben drauf einlassen wollen. An diesem Punkte scheiden sich 
die Geister.

W.S.

von Tim  . (cpldcpu)


Lesenswert?

W.S. schrieb:
> Kurzum, diese inzwischen recht alte Architektur ist von einer
> Versatilität und "Knuffigkeit", die man woanders vergeblich sucht.

Aber die gibt es doch in der 0.03 USD von Padauk.

Hat eigentlich inzwischen jemand eine dieser MCU tatsächlich in Betrieb 
nehmen können?

Bei LCSC gibt es inzwischen wieder Nachschub. Mir fehlt leider noch der 
Programmer.

: Bearbeitet durch User
von Harald (Gast)


Lesenswert?

Tim  . schrieb:

> Hat eigentlich inzwischen jemand eine dieser MCU tatsächlich in Betrieb
> nehmen können?

Den Beitrag auf eevblog.com kennst du?

von Tim  . (cpldcpu)


Lesenswert?

Harald schrieb:
> Den Beitrag auf eevblog.com kennst du?

https://www.youtube.com/watch?time_continue=11&v=4Zw_W0iaGFM

Kannte ich noch nicht. Sehr interessant!

von Harald (Gast)


Lesenswert?

Ich meinte auch vor allem die Beiträge #1140 und #1141

von Harald (Gast)


Lesenswert?

Auf eevblog2 gibt es auch noch ein paar weitere Beiträge

von Tim  . (cpldcpu)


Lesenswert?


von Tim  . (cpldcpu)


Lesenswert?


von Klaus (Gast)


Lesenswert?

Dr. Sommer schrieb:
> Wie kommt das eigentlich? Bewirken die genannten Einschränkungen
> (Hardware-Stack usw.) so eine drastische Einsparung bei der Produktion?

Nun, es gibt zwei Faktoren, die massgeblich den Preis bestimmen: das 
Gehäuse und die Diegröße.

Früher hat die Anzahl der Transistoren die Größe des Dies bestimmt. Das 
hat sich mit kleiner werdenden Strukturen aber geändert. Heute bestimmen 
die I/Os die Größe. Für sie muß Platz genug auf dem Umfang sein.

An den PICs kann man das gut erkennen. Während früher Timer gerne 
mehrfach genutzt wurden, als Baudratetimer, für PWM oder Capture, hatten 
die plötzlich eigene und auch ziemlich lange Timer. Auch die Peripherie 
ist wesentlich komplexer geworden. Das zeigt, daß die dafür gebrauchten 
zusätzlichen Gatter bzw. Flipflops keinen wesentlichen Einfluß auf den 
Preis mehr haben.

Heutzutage bestimmt eigentlich nur die Anzahl der I/Os den Preis. Einmal 
durch den Umfang des Dies vorgegeben durch die Bondingpads und zum 
anderen durch das Gehäuse.

MfG Klaus

von Tim  . (cpldcpu)


Lesenswert?

Habe mal einige der Befehlskodierungen rekonstruiert.
Die Befehle sind als 14bit-Wort kodiert, ähnlich PIC16. Das Encoding ist 
allerdings nicht binärkompatibel.
1
goto a        x x 1 1  0 a a a  a a a a  a a a a 
2
nop           x x 0 0  0 0 0 0  0 0 0 0  0 0 0 0 
3
ret           x x 0 0  0 0 0 0  0 1 1 1  1 0 1 0 
4
reti          x x 0 0  0 0 0 0  0 1 1 1  1 0 1 1 
5
ret #i        x x 0 0  0 0 1 0  i i i i  i i i i 
6
pcadd a       x x 0 0  0 0 0 0  0 1 1 0  0 1 1 1 
7
mov a,#i      x x 1 0  1 1 1 1  i i i i  i i i i 
8
mov MEM,a     x x 0 0  1 0 1 1  1 a a a  a a a a 
9
mov a,MEM     x x 0 0  1 1 1 1  1 a a a  a a a a

von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
> Habe mal einige der Befehlskodierungen rekonstruiert.
> Die Befehle sind als 14bit-Wort kodiert, ähnlich PIC16. Das Encoding ist
> allerdings nicht binärkompatibel.
>
>
1
> goto a        x x 1 1  0 a a a  a a a a  a a a a
2
> nop           x x 0 0  0 0 0 0  0 0 0 0  0 0 0 0
3
> ret           x x 0 0  0 0 0 0  0 1 1 1  1 0 1 0
4
> reti          x x 0 0  0 0 0 0  0 1 1 1  1 0 1 1
5
> ret #i        x x 0 0  0 0 1 0  i i i i  i i i i
6
> pcadd a       x x 0 0  0 0 0 0  0 1 1 0  0 1 1 1
7
> mov a,#i      x x 1 0  1 1 1 1  i i i i  i i i i
8
> mov MEM,a     x x 0 0  1 0 1 1  1 a a a  a a a a
9
> mov a,MEM     x x 0 0  1 1 1 1  1 a a a  a a a a
10
>

Ist die Kodierung einheitlich über alle µC hinweg? Die Beschränkung auf 
7-bit-Adressen bei mov und 11 Bit-Adressen bei goto finde ich seltsam. 
Schließlich gibt es auch Varianten mit mehr Speicher (bis zu 256 B RAM, 
bis zu 4K-Adressraum im ROM) und der Befehlssdatz ist auch nicht ganz 
einheitlich (z.B. sind ldtabh, ldtabl, mul, pushw, popw nur bei manchen 
im Datenblatt aufgeführt).

Philipp

P.S.: Laut Datenblättern ist der Programmspeicher 16 bit breit.

: Bearbeitet durch User
von Philipp Klaus K. (pkk)


Lesenswert?

Klaus schrieb:
> Dr. Sommer schrieb:
> […]
> Heutzutage bestimmt eigentlich nur die Anzahl der I/Os den Preis. Einmal
> durch den Umfang des Dies vorgegeben durch die Bondingpads und zum
> anderen durch das Gehäuse.
>
> MfG Klaus

Andererseits sehen wir ja hier gerade, dass ein kleiner 
Halbleiterhersteller, dennoch sehr günstig µC anbieten kann, die wohl 
mit wenigen Transistoren auskommen (einfacher Kern, wenig Peripherie), 
obwohl die Kosten für die I/O-Pins ähnlich wie bei anderen Herstellern 
liegen dürften. Die verwendeten Prozesse sind "< 0.5 µm" und "< 0.18 
µm".

Philipp

von W.S. (Gast)


Lesenswert?

Tim  . schrieb:
> Habe mal einige der Befehlskodierungen rekonstruiert.

Irgendwie piept mich sowas an: Da gibt es nen µC, der zwar relativ 
knuffig auszusehen scheint (bis auf den Umstand, daß er OTP ist), aber 
der Hersteller macht ein Riesengeheimnis um sämtliche Informationen, die 
zum tatsächlichen Benutzen nötig sind.

Sogar die erzeugten Asm- oder Objectcode-Files werden noch 
verschlüsselt, von der Darlegung des Maschinenbefehlssatzes und des 
Programmieralgorithmus ganz abgesehen.

OK, wenn jemand hier Sherlock Holmes spielen will, ist sowas ja eine 
nette Gelegenheit, aber für's normale Benutzen? Da sind die ganz kleinen 
PIC's nun auch nicht so unsäglich teuer - dafür aber wohldokumentiert.

W.S.

von Philipp Klaus K. (pkk)


Lesenswert?

W.S. schrieb:
> Tim  . schrieb:
>> Habe mal einige der Befehlskodierungen rekonstruiert.
>
> Irgendwie piept mich sowas an: Da gibt es nen µC, der zwar relativ
> knuffig auszusehen scheint (bis auf den Umstand, daß er OTP ist),

Es gibt auch Varianten mit Flash. Kosten aber wohl einen Cent mehr.

> aber
> der Hersteller macht ein Riesengeheimnis um sämtliche Informationen, die
> zum tatsächlichen Benutzen nötig sind.

So sieht es mir nicht aus. Eher danach, dass er nur das nötige für die 
Zeilmärkte macht (und da reicht wohl die IDE, die Padauk bereitstellt). 
Ausführliche Dokumentation ist Aufwand, erst recht, wenn sie in einer 
Fremdsprache wie Englisch erstellt werden muss.

> Sogar die erzeugten Asm- oder Objectcode-Files werden noch
> verschlüsselt,

Das ist in der Tat etwas unverständlich. Möglicherweise ist es eher ein 
verunglückter Versuch einer Prüfsumme?

> von der Darlegung des Maschinenbefehlssatzes und des
> Programmieralgorithmus ganz abgesehen.

Siehe oben. Aufwand, der sich wohl aus Herstellersicht für die 
Zielmärkte nicht lohnt.

>
> OK, wenn jemand hier Sherlock Holmes spielen will, ist sowas ja eine
> nette Gelegenheit, aber für's normale Benutzen? Da sind die ganz kleinen
> PIC's nun auch nicht so unsäglich teuer - dafür aber wohldokumentiert.

Die kleinen PIC haben aber doch eine deutlich unschönere Architektur. 
Und bei freien Tools dafür sieht es auch nicht so gut aus. Gut möglich, 
dass es in ein, zwei Jahren brauchbare Unterstützung der Padauk durch 
freie Tools gibt - also manche etwas Reverse-Engineering betreiben, und 
dann flash-tools, Assembler, Simulator, Compiler schreiben.

Philipp

von W.S. (Gast)


Lesenswert?

Philipp Klaus K. schrieb:
> Die kleinen PIC haben aber doch eine deutlich unschönere Architektur.
> Und bei freien Tools dafür sieht es auch nicht so gut aus.

Ach wo. Sowas ist EASY. Ich selber benutze schon seit Ewigkeiten meinen 
eigenen Crossassembler, hab meine eigene Gleitkommabibliothek, und hab 
auch meine eigenen PIC-Brenner. Früher am Druckerport (ist ausgestorben) 
und inzwischen hab ich mir auf Basis des kleinen Bastel-Projektes mit 
einem STM32F103C8T6 (hatte ich mal hier gepostet, LP per Eagle und 
Firmware in Basisausstattung) einen halbintelligenten PIC-Brenner 
gemacht: Basisalgorithmen im STM32, General-Algorithmen im PC, das Ganze 
per USB. Sollte eigentlich ausreichen, um auch PIC32 zu brennen, hab da 
aber bislang noch garnix vorangetrieben.

Wenn es ne saubere Beschreibung des Maschinencodes gäbe und dito 
Programmieralgo, dann wäre das ein Klacks, meine seit den 90er Jahren 
vorhandenen Tools drauf einzurichten.

Aber wenn der Hersteller sich sämtliche Knopflöcher vehement zuhält, 
dann piept's unsereinen zu sehr an, als daß ich mich da in die Spur 
begeben würde.

W.S.

von Philipp Klaus K. (pkk)


Lesenswert?

W.S. schrieb:
> Philipp Klaus K. schrieb:
>> Die kleinen PIC haben aber doch eine deutlich unschönere Architektur.
>> Und bei freien Tools dafür sieht es auch nicht so gut aus.
>
> Ach wo. Sowas ist EASY. Ich selber benutze schon seit Ewigkeiten meinen
> eigenen Crossassembler, hab meine eigene Gleitkommabibliothek, und hab
> auch meine eigenen PIC-Brenner. […]

Warum nicht gputils als Assembler verwenden?

Aus meiner Sicht sieht es so aus:
Es gibt mit gputils und dem pic14-backend in SDCC eine freie Toolchain, 
die aber bei weitem nicht auf dem Niveau ist, das man bei anderen 
Architekturen kennt.
Ob das Hauptproblem die (aus meiner Sicht) unschöne Architektur oder ein 
anderes ist, weiß ich nicht.

Philipp

von Tim  . (cpldcpu)


Lesenswert?

Philipp Klaus K. schrieb:
> Ist die Kodierung einheitlich über alle µC hinweg? Die Beschränkung auf
> 7-bit-Adressen bei mov und 11 Bit-Adressen bei goto finde ich seltsam.
> Schließlich gibt es auch Varianten mit mehr Speicher (bis zu 256 B RAM,
> bis zu 4K-Adressraum im ROM) und der Befehlssdatz ist auch nicht ganz
> einheitlich (z.B. sind ldtabh, ldtabl, mul, pushw, popw nur bei manchen
> im Datenblatt aufgeführt).

Ich habe bisher nur das Encoding für den PFS154 angeschaut. 
Möglicherweise ist es für andere Devices anders. Die 7 und 11 bit 
entsprechen dem PFS154 Speicherbereich. Beim "Goto" Befehl ist 
möglicherweise noch ein Bit frei. Beim Speicher sieht es nicht so aus.

Philipp Klaus K. schrieb:
> P.S.: Laut Datenblättern ist der Programmspeicher 16 bit breit.

Leere Speicherzellen sind mit 0x3fff kodiert. Ebenso habe ich keine 
Befehle gefunden, bei denen die oberen beiden Bits gesetzt sind. Gehe 
daher von 14 Bit aus.

von Tim  . (cpldcpu)


Lesenswert?

Hier ist übrigens mein Testprogram. Die Assemblerprogrammierung ist in 
der IDE nicht gut dokentiert. Bei mir funktioniert das Hilfsfile auch 
nicht richtig.

Leider "denkt" der Assembler zu viel mit. Ohne Codegeneratoren und Macro 
ließ sich nichts assemblieren.

test.asm

Dekodierung des erzeugten ".PDK"-Files mit dem dem oben verlinkten 
Programm.
1
.chip PFS154
2
3
//{{PADAUK_CODE_OPTION
4
  .Code_Option  Comparator_Edge  All_Edge
5
  .Code_Option  LCD2    Disable    // At ICE, LCD always disable, PB0 PA0/3/4 are independent pins
6
  .Code_Option  LVR    2.5V
7
  .Code_Option  Bootup_Time  Fast
8
  .Code_Option  Drive    Normal
9
  .Code_Option  Security  Disable    // Security Disable
10
//}}PADAUK_CODE_OPTION
11
12
13
14
.ramadr 0x31
15
byte  datx
16
17
18
.romadr  0x00
19
lop:
20
  .ADJUST_IC  SYSCLK=IHRC/8, IHRC=16MHz, VDD=3.3V;
21
    //  WatchDog Disable, RAM 0 ~ 0xF temporary be used
22
  //  You can add the follow code :
23
  //    CLKMD.En_WatchDog  =  1;    // WatchDog Enable
24
25
  goto prog
26
.romadr  0x80
27
prog:
28
  mov  a,129
29
  mov  datx,a
30
  mov  a,datx
31
  goto prog

von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
>
> Ich habe bisher nur das Encoding für den PFS154 angeschaut.
> […]
>
> Philipp Klaus K. schrieb:
>> P.S.: Laut Datenblättern ist der Programmspeicher 16 bit breit.
>
> Leere Speicherzellen sind mit 0x3fff kodiert. Ebenso habe ich keine
> Befehle gefunden, bei denen die oberen beiden Bits gesetzt sind. Gehe
> daher von 14 Bit aus.

Beim PFS154 steht tatsächlich nichts von einem 16 Bit breiten 
Programmspeicher (im Gegensatz zu PMC251 und MCS11).

Philipp

von Tim  . (cpldcpu)


Lesenswert?

Philipp Klaus K. schrieb:
> Beim PFS154 steht tatsächlich nichts von einem 16 Bit breiten
> Programmspeicher (im Gegensatz zu PMC251 und MCS11).

Der MCS11 scheint tatsächlich 16 bit encoding zu nutzen. Alles ist ein 
bischen anders:
1
MCS11
2
mov a,#i      0 0 0 1  1 1 1 1  i i i i  i i i i 
3
mov MEM,a     0 1 0 1  1 1 0 ?  a a a a  a a a a 
4
mov a,MEM     0 1 0 1  1 1 1 ?  a a a a  a a a a 
5
goto a        1 1 0 ?  ? a a a  a a a a  a a a a

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

Bei den PICS gewinnt man den Eindruck, dass Microchip diese selbst 
langsam ausphasen will.

Am unteren Ende der Preisskale sind fast nur noch AVRs zu finden. Und 
die neuen ATtiny 402/412 können es locker mit jedem Midrange-PIC 
aufnehmen. Der Umfang der Peripherie ist inzwischen ziemlich 
beeindruckend.

von Ralph S. (jjflash)


Lesenswert?

Philipp Klaus K. schrieb:
> Warum nicht gputils als Assembler verwenden?
>
> Aus meiner Sicht sieht es so aus:
> Es gibt mit gputils und dem pic14-backend in SDCC eine freie Toolchain,
> die aber bei weitem nicht auf dem Niveau ist, das man bei anderen
> Architekturen kennt.

Smile, gerade du weißt wohl besser als alle anderen, dass der SDCC als 
Backend für pic14 wirklich sehr unvollständig ist (leider).

Ich mag den SDCC sehr für MCS-51 und STM8, für PIC14 (und auch PIC16) 
ist er einfach unvollständig.

Aber dennoch: super großes Lob für die heftige Arbeit die du und deine 
Mitstreiter in den SDCC stecken.

By the way: wie heißt denn der Padauk MCU mit Flash ?

von Philipp Klaus K. (pkk)


Lesenswert?

Ralph S. schrieb:
> Philipp Klaus K. schrieb:
>> Warum nicht gputils als Assembler verwenden?
>>
>> Aus meiner Sicht sieht es so aus:
>> Es gibt mit gputils und dem pic14-backend in SDCC eine freie Toolchain,
>> die aber bei weitem nicht auf dem Niveau ist, das man bei anderen
>> Architekturen kennt.
>
> Smile, gerade du weißt wohl besser als alle anderen, dass der SDCC als
> Backend für pic14 wirklich sehr unvollständig ist (leider).
>
> Ich mag den SDCC sehr für MCS-51 und STM8, für PIC14 (und auch PIC16)
> ist er einfach unvollständig.

Das pic16-Backend ist aber wohl in deutlich besserem Zustand als pic14. 
Aber jemand, der sich mit den PIC etwas auskennt, und sich dafür 
interessiert könnte die Probleme beider backends sicher beheben (auch 
wenn zur Zeit etwas die Hälfte der offenen Bugs in SDCC sich auf die 
pic-Backends bezieht). Das gbz80-Backend was vor Jahren sogar in 
schlechterem Zustand als die pic heute. Das gbz80-backend heute mag 
nicht immer so gut optimierten Code erzeugen wie z80 oder stm8, aber im 
Großen und Ganzen funktioniert es heute ähnlich gut wie die anderen.

>
> Aber dennoch: super großes Lob für die heftige Arbeit die du und deine
> Mitstreiter in den SDCC stecken.
>
> By the way: wie heißt denn der Padauk MCU mit Flash ?

Zur Zeit gibt es wohl PFC154, PFX154, PFS173. Angekündigt sind noch 
PFC151, PFX232, PGC233 und PGC234. Die '2' als erste Ziffer kennzeichnet 
bei Padauk Dualcore-µC.

Philipp

von Philipp Klaus K. (pkk)


Lesenswert?

Philipp Klaus K. schrieb:
> Zur Zeit gibt es wohl PFC154, PFX154, PFS173. Angekündigt sind noch
> PFC151, PFX232, PGC233 und PGC234. Die '2' als erste Ziffer kennzeichnet
> bei Padauk Dualcore-µC.

"PFX" sollte jeweils "PFS" sein.

Philipp

von Philipp Klaus K. (pkk)


Lesenswert?

Auf github gibt es nun eine Übersicht der 14-Bit Befehle:

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

Philipp

von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
> Philipp Klaus K. schrieb:
>> Beim PFS154 steht tatsächlich nichts von einem 16 Bit breiten
>> Programmspeicher (im Gegensatz zu PMC251 und MCS11).
>
> Der MCS11 scheint tatsächlich 16 bit encoding zu nutzen. Alles ist ein
> bischen anders:
>
>
1
> MCS11
2
> mov a,#i      0 0 0 1  1 1 1 1  i i i i  i i i i
3
> mov MEM,a     0 1 0 1  1 1 0 ?  a a a a  a a a a
4
> mov a,MEM     0 1 0 1  1 1 1 ?  a a a a  a a a a
5
> goto a        1 1 0 ?  ? a a a  a a a a  a a a a
6
>

Wie ich von Padauk erfahren habe, gibt es wohl insgesamt 3 Befehlssätze: 
14-Bit, 15-Bit, 16-Bit. Letzterer wird für die Multicore-µC verwendet, 
während bei den Singlecore-µC alle 3 vorkommen.

Philipp

P.S.: Es hieß, der 15-Bit-Befehlssatz komme bei µC mit 2 Kiloworten 
Programmspeicher vor.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

Philipp Klaus K. schrieb:
> P.S.: Es hieß, der 15-Bit-Befehlssatz komme bei µC mit 2 Kiloworten
> Programmspeicher vor.

Tja, irgendwo muss das zusätzliche Bit für "Goto" und "call" her kommen.

Beim instruction set encoding wundert mich, dass eine unbeschriebene 
Speicherzelle (0x3ff) als call 0xfff interpretiert wird. Damit hängt 
sich die MCU erst einmal auf, wenn  uninitialiserte Speicherbereiche 
angesprungen werden. Beim AVR ist 0xffff=NOP, was für bootloader o.Ä. 
recht nutzlich ist.

Philipp Klaus K. schrieb:
> https://free-pdk.github.io/PADAUK_FPPA_14_bit_instruction_set.html

Prima, damit könnte man eine benutzbare OSS Toolchain erstellen. Fehlt 
nur noch das Programmierprotokoll. Da scheint noch niemand weiter zu 
sein, oder?

von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
> Philipp Klaus K. schrieb:
>> P.S.: Es hieß, der 15-Bit-Befehlssatz komme bei µC mit 2 Kiloworten
>> Programmspeicher vor.
>
> Tja, irgendwo muss das zusätzliche Bit für "Goto" und "call" her kommen.

Inzwischen vermute ich, dass das ein Tippfehler war; es sieht mir doch 
eher nach 13 Bit, 14 Bit und 16 Bit aus. Die 11 Bit bei goto / call 
reichen ja für 2 Kiloworte, und die größeren verwenden wohl den 
16-Bit-Befehlssatz.

> Beim instruction set encoding wundert mich, dass eine unbeschriebene
> Speicherzelle (0x3ff) als call 0xfff interpretiert wird. Damit hängt
> sich die MCU erst einmal auf, wenn  uninitialiserte Speicherbereiche
> angesprungen werden. Beim AVR ist 0xffff=NOP, was für bootloader o.Ä.
> recht nutzlich ist.

0xfff liegt am Ende des Programmspeichers, in einem reservierten 32 
Worte großen Bereich. Möglicherweise liegt dort irgendwelcher 
Selbsttestcode, der dann bei einem unbeschriebenen µC ausgeführt wird.

>
> Philipp Klaus K. schrieb:
>> https://free-pdk.github.io/PADAUK_FPPA_14_bit_instruction_set.html
>
> Prima, damit könnte man eine benutzbare OSS Toolchain erstellen. Fehlt
> nur noch das Programmierprotokoll. Da scheint noch niemand weiter zu
> sein, oder?

Nicht dass ich wüsste. Die µC mit Flash kommen könnte da einfacher sein: 
Immerhin ist dort dokumentiert, welche Signale (VDD, GND, ICVPP, ICPDA, 
ICPCK) an welchen Pins zum Programmieren verwendet werden; vermutlich 
gibt es dort auch weniger verschiedene Spannungen (und die höchste liegt 
laut Dokumentation auch nur bei 8 V an ICVPP).

Für das Reverse-Engineering braucht man halt erstmal einen Brenner; ich 
habe vor, mir den 5S-P-003 zu beschaffen, wenn der wieder verfügbar ist 
(LCSC wird wohl demnächst eine Lieferung bekommen). Aber eigentlich 
wollte ich eher am Compiler arbeiten als am Brenner. Selbst freie 
Software, die mit dem 5S-P-003 arbeitet, wäre schon ein Fortschritt.

Philipp

von Harald A. (embedded)


Lesenswert?

Philipp Klaus K. schrieb:
> Aber eigentlich wollte ich eher am Compiler arbeiten als am Brenner.

Also gibt es eine Hoffnung, dass man den Padauk irgendwann im 
SDCC-Projekt sehen wird? In dem Fall könnte ich mir vorstellen, dass 
dich der Hersteller vielleicht sogar direkt unterstützt, z.B. mit 
Programmer-Hardware. Das wäre für die ja ein Durchbruch.

Philipp Klaus K. schrieb:
> ich habe vor, mir den 5S-P-003 zu beschaffen

Ansonsten, kennst du den Beschaffungsweg über 1688.com, wo man via Agent 
wie z.B. Yoybuy.com einkaufen kann? Yoybuy kauft das Lokal für dich, 
bekommt dafür ein paar Prozent und organisiert dann den Versand. Ich 
habe das mit anderen Teilen schon gemacht, hat gut funktioniert.

von Gerd E. (robberknight)


Lesenswert?

Harald A. schrieb:
> Philipp Klaus K. schrieb:
>> Aber eigentlich wollte ich eher am Compiler arbeiten als am Brenner.
>
> Also gibt es eine Hoffnung, dass man den Padauk irgendwann im
> SDCC-Projekt sehen wird? In dem Fall könnte ich mir vorstellen, dass
> dich der Hersteller vielleicht sogar direkt unterstützt, z.B. mit
> Programmer-Hardware. Das wäre für die ja ein Durchbruch.

Hmm. Das würde voraussetzen daß die erkennen, daß das für die ein klarer 
Mehrwert ist. Viele Firmen tun sich mit dieser Erkenntnis sehr schwer 
und meinen, daß ihre Kunden mit den von ihnen offiziell supporteten 
Werkzeugen (Toolchain und Programmer) besser fahren. Und dann immer noch 
die Angst, daß durch offenen Quellcode der Konkurrent irgendwas 
einfacher abschauen kann.

Denk an Microchip mit den PICs, ich hab das Gefühl daß die konkret 
Verantwortlichen das bis heute nicht wirklich eingesehen haben.

Ich fürchte daß ein asiatischer Hersteller da noch schwerer tut, da die 
Mitarbeiter wegen der Sprachbarriere nicht so leicht mitbekommen, was in 
den westlichen Foren, Mailinglisten etc., in denen sowas entwickelt 
wird, passiert.

von Philipp Klaus K. (pkk)


Lesenswert?

Harald A. schrieb:
> Philipp Klaus K. schrieb:
>> Aber eigentlich wollte ich eher am Compiler arbeiten als am Brenner.
>
> Also gibt es eine Hoffnung, dass man den Padauk irgendwann im
> SDCC-Projekt sehen wird?

Ja, aber wohl eher schrittweise. Vermutlich werden zuerst die Padauk mit 
14-Bit-Befehlssatz unterstützt, 13-Bit und 16-Bit käme später. 
Insbesondere gute Unterstützung für das hardwareseitige Multithreading 
wird aufwendig.

Philipp

von Fred R. (Firma: www.ramser-elektro.at/shop) (fred_ram)


Lesenswert?

Hat die jetzt schon jemand ausprobiert, oder bezogen?

von Tim  . (cpldcpu)


Lesenswert?

Philipp Klaus K. schrieb:
> Nicht dass ich wüsste. Die µC mit Flash kommen könnte da einfacher sein:
> Immerhin ist dort dokumentiert, welche Signale (VDD, GND, ICVPP, ICPDA,
> ICPCK) an welchen Pins zum Programmieren verwendet werden; vermutlich
> gibt es dort auch weniger verschiedene Spannungen (und die höchste liegt
> laut Dokumentation auch nur bei 8 V an ICVPP).

Also ICVPP für die Programmierspannung, ICPDA für die Daten, ICPCK für 
die Clock. Sollte sich mit den Anhaltspunkten eigentlich mit 
vertretbarem Aufwand reverse engineeren lassen. So lange nicht auf 
Protokolllevel verschlüsselt wird. Aber das erscheint eher 
unwahrscheinlich.

Damit fehlt nur noch der Programmer... Padauk hat Dave vom EEVblog 
anscheinend einen geschickt, aber er scheint mit der Entschlüsselung des 
Protokolls nicht weiter gemacht zu haben.

: Bearbeitet durch User
von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Tim  . schrieb:
> aber er scheint mit der Entschlüsselung des Protokolls nicht weiter
> gemacht zu haben.

Vermutlich sorgt der Umzug des "Labs" in neue Räume für (vorübergehende) 
Prioritätsverschiebungen.

von Philipp Klaus K. (pkk)


Lesenswert?

Harald A. schrieb:
> Also gibt es eine Hoffnung, dass man den Padauk irgendwann im
> SDCC-Projekt sehen wird?

Ein erster Anfang:

https://svn.code.sf.net/p/sdcc/code/branches/pdk/sdcc

Verwenden mit -mpdk14 (der erzeugte Code solte aber noch unabhängig vom 
Padauk-Befehlssatz sein, da nur Befehle, die auch von den 13-Bit und 
16_but Padauk unterstützt werden, verwendet werden). Allerdings 
funktioniert bisher noch fasts nichts. Man erhält am Ende sehr 
ineffizienten asm-Code. Besonders auffällige Einschränkungen:

* Keine Zeiger, Arrays, Struct, Union, Float, etc.
* Keine Funktionsparameter.
* Rückgabewerte nur bis zu 1 Byte (also nur void, bool, char, signed 
char, unsigned char).
* Keine bitweisen Operationen und Shifts.
* Keine multiplikativen Operationen
* Funktionen sind nicht reentrant.
* Nur == und != zum Vergleich. <, <=, >, >= gibt es nicht.

Philipp

von Philipp Klaus K. (pkk)


Lesenswert?

Nach einem zweiten Tag Arbeit am Padauk-backend für SDCC wird nun 
deutlich mehr vom C-Standard unterstützt, als in Padauks "Mini-C".

Dennoch verbleiben deutliche Einschränkungen:

* Variablen liegen immer im RAM, nicht im ROM.
* Globale und statische Variablen sindnicht initialisiert.
* Keine Gleitkommatypen und Bit-Felder.
* Funktionen können nur bis zu 2 Byte zurückgeben (also kein long oder 
long long).
* Keine multiplikativen Operatoren (*, /, %)
* Funktionen sind nicht reentrant.
* Keine variablen Argumente (...)
* Keine Standardbibliothek
* struct / union können nicht zugeweisen, übergeben oder zurückgegeben 
werden.
* Keine compound literals.
* Kein I/O von C her.

Auch ist es bisher in reiner Compiler, ohne Verbindung zu Assembler und 
Linker, so dass die Ausgabe nur aus Asemblerocde besteht.

Der erzeugte Code ist sehr ineffizient, aber das werde ich demnächst 
noch ein wenig verbessern.

Philipp

von W.S. (Gast)


Lesenswert?

Philipp Klaus K. schrieb:
> Dennoch verbleiben deutliche Einschränkungen:

Warum eigentlich?
Warum der Versuch, eine Hardware, die ganz deutlich auf Assembler 
ausgerichtet ist, mit Gewalt auf C zu trimmen?

Klar, ich könnte bei Vorliegen einer wirklich verläßlichen und 
vollständigen Maschinencode-Dokumentation eine Gleitkomma-Bibliothek 
incl. Ausganekonverter beisteuern - sofern diese Padauk's sich im 
Wesentlichen an die generellen Funktionalitäten der PIC16 halten.

Aber wozu? So etwas ist aus einem Assembler-Programm wirklich bequem und 
elegant zu benutzen - es ist dazu jedoch nötig, sich eben in ASSEMBLER 
auszudrücken. Aber mit Gewalt C hier durchzudrücken? Damit Leute, die es 
nicht für nötig halten, sich näher mit dem Silizium und dessen Assembler 
zu befassen, es a la Arduino benutzen können?

Alles nur ne Art Sport?

W.S.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

W.S. schrieb:
> Warum eigentlich?
> Warum der Versuch, eine Hardware, die ganz deutlich auf Assembler
> ausgerichtet ist, mit Gewalt auf C zu trimmen?

Gegenfrage: Warum nicht?

von S. R. (svenska)


Lesenswert?

W.S. schrieb:
>> Dennoch verbleiben deutliche Einschränkungen:
> Warum eigentlich?

Weil man einen Compiler nicht in ein paar Stunden auf eine neue 
Architektur portiert. Da steckt schon Arbeit dahinter.

Philipp Klaus K. schrieb:
> Nach einem zweiten Tag Arbeit am Padauk-backend für SDCC wird nun
> deutlich mehr vom C-Standard unterstützt, als in Padauks "Mini-C".

Find ich genial! Danke!

von ghost (Gast)


Lesenswert?

W.S. schrieb:
> Alles nur ne Art Sport?

"Weil es geht" ist eine völlig ausreichende Antwort.

Warum musst Du eigentlich alles hier im Thread kritisieren?

von Philipp Klaus K. (pkk)


Lesenswert?

W.S. schrieb:
> Philipp Klaus K. schrieb:
>> Dennoch verbleiben deutliche Einschränkungen:
>
> Warum eigentlich?
> Warum der Versuch, eine Hardware, die ganz deutlich auf Assembler
> ausgerichtet ist, mit Gewalt auf C zu trimmen?

Die Hardware der Singlecore-µC von Padauk erscheint mir ähnlich gut oder 
schlecht für C geeignet wie MCS-51 - besser als pic14 und pic16, 
schlechter als z80 und stm8.

Die Einschränkungen liegen in erster Linie daran, dass diese 
Funktionalität halt noch nicht implementiert wurde, nicht an 
Einschränkungen der Hardware.

Lediglich Zeiger, die auch ins ROM zeigen können und reentrante 
Funktionen lassen sich wirklich nicht effizient auf den Padauk 
realisieren - aber das ist bei MCS-51 auch nicht viel besser.

Philipp

von Tim  . (cpldcpu)


Lesenswert?

Inzwischen bin ich stolzer Besitzer von mehreren hundert Padauk 
Controllern. Leider fehlt immer noch der Programmierer.

Ist es inzwischen gelungen, einen Programmiervorgang der Flash-Varianten 
mitzuloggen? (xx154)?

Mit einem USB Logikanalyzer sollte das eigentlich kein Problem sein. Die 
Programmierspannung müsste man evtl. über einen Komparator abgreifen.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

Zum Programmierinterface gibt es in den Datenblättern ja bereits 
hinreichende Informationen.

Das Interface der OTP (PMx) und MTP (PFx)-Varianten scheint 
grundsätzlich unterschiedlich zu sein.

Die MTP-Varianten nutzen ein einfaches zweidraht-Interface mit Clk und 
Datenleitung. Zusätzlich muss an einen dritten Pin eine 
Programmierspannung angelegt werden. Prinzipiell sollte sich der 
Programmiervorgang also sehr einfach über einen Logikanalyzer mitloggen 
lassen.

Die Programmierung der OTP-Variante scheint etwas komplexer zu sein. 
Anscheinend wird hier auch VDD während des Schreibens auf 6.5V 
angehoben. Vermutlich ist das lediglich eine Maßnahme um die 
Write-Margins zu erhöhen und 5V sind trotzdem ausreichend.

von W.S. (Gast)


Lesenswert?

Philipp Klaus K. schrieb:
> Die Hardware der Singlecore-µC von Padauk erscheint mir ähnlich gut oder
> schlecht für C geeignet wie MCS-51

Ich habe mir jetzt mal die Datenblätter der PFS154 und PFS173 
heruntergeladen. Glücklicherweise stehen da wenigstens die 
Assembler-Mnemoniks drin. Leider fehlen die dazu gehörigen 
Maschinenbefehls-Formate.

Also, so wie ich das jetzt anhand dieser Datenbläter sehe, kann man 
diese Chips IM GEGENSATZ ZU DEN PIC16xxx auch in der Load-Modify-Store 
Technologie programmieren. OK, das gibt Freiheiten, die über 8051 und 
PIC hinausgehen. Das hatte ich bislang nicht gesehen.

Ob das auch bei den OTP-Typen gilt, weiß ich nicht - aber die sind mir 
aus meiner Sicht ohnehin nicht interessant.

Also, so wie ich das jetzt sehe für die PFSxxx:
- die Dinger gibt es in 8, 14 und 16 poligen Gehäusen.
- Kostenpunkt ist etwa bei 10..13 US-Cent pro Stück
- es gibt ne IDE und ein Brennprogramm
- der Brenn-Algorithmus ist nicht offengelegt
- es gibt einen teuren Programmier-Adapter
- der eigentliche Maschinencode ist nicht offengelegt
- einen dedizierten Assembler gibt es nicht

Diese Chips sind durchaus interessant, aber momentan fehlt es ganz 
deutlich an näheren Informationen dazu. Es wird erst dann wirklich was 
draus, wenn sowohl Maschinencode also auch Brenn-Algorithmus bekannt 
sind.

Meine kleine Gleitkomma-Arithmetik ließe sich ohne allzu große Probleme 
an diese Chips anpassen, ebenso mein PIC-Crossassembler. Aber sowas muß 
ausprobiert werden und das geht nur mit Brenner.

Teuer Geld will ich dafür jedoch nicht ausgeben.

Falls der Algo bekannt ist, kann ich oder jemand anderes ihn auch in 
meinen kleinen PIC-Brenner einbauen. Der basiert auf einem 
STM32F103-Board, das ich hier schon mal gepostet hatte. Einstellbare 
Programmierspannungen bis ca. 14 Volt sind drin.

So stellt sich mir der Stand der Dinge zur Zeit dar.

W.S.

von Tim  . (cpldcpu)


Lesenswert?

Etwas verwirrend: Es gibt eine Firma in Shenzhen, die MCUs basierend auf 
der Padauk-FPPA Architektur vertreibt.

http://www.puolop.com/products/category/mid/2/sid/15.html

von Johnny B. (johnnyb)


Lesenswert?

Philipp Klaus K. schrieb:
> Dennoch verbleiben deutliche Einschränkungen:
> * Variablen liegen immer im RAM, nicht im ROM.
> ...

Wo sollten Variablen denn sonst liegen?

von Cyblord -. (cyblord)


Lesenswert?

Johnny B. schrieb:
> Philipp Klaus K. schrieb:
>> Dennoch verbleiben deutliche Einschränkungen:
>> * Variablen liegen immer im RAM, nicht im ROM.
>> ...
>
> Wo sollten Variablen denn sonst liegen?

Er meint wohl diese speziellen Variablen die in exotischeren Teilen der 
Welt als Konstanten bezeichnet werden. ;-)

von Weihnachtsmann (Gast)


Lesenswert?

Cyblord -. schrieb:
>> Wo sollten Variablen denn sonst liegen?
>
> Er meint wohl diese speziellen Variablen die in exotischeren Teilen der
> Welt als Konstanten bezeichnet werden. ;-)


Also die nichtvariablen Variablen... ;)

von Philipp Klaus K. (pkk)


Lesenswert?

Nun ja, in C gibt es Variablen, Zeichenketten und konstante Ausdrücke. 
Letztere benötigen üblicherweise keinen Speicherplatz. Manche Variablen 
sind unveränderlich (z.B. Variablen mit File-Scope und Qualifier const). 
Die und Zeichenketten kann ein Compiler im ROM ablegen (und SDCC macht 
es auch für die anderen Backends).

Viele µC mit einem einheitlichen Adressraum können effizient sowohl auf 
RAm als auch auf ROm zugreifen (STM8, Z80). Anderen benötigen 
verschiedene Befehle, je nachdem, wo die Variable liegt (MCS-51, 
Padauk). Letzteres macht Zugriffe über Zeiger ineffizienter (soweit der 
Compiler nicht im Vorraus feststellen kann, in welchem Teil des 
Speichers die Variable liegt).

Bei Padauk kommt noch hinzu: Die µC haben verschiedene Breiten des ROM 
(13, 14, 15, 16 Bit). Bei manchen gibt es keinen effizienten Zugriff auf 
den ROM. Als workaround kann man aber einen 8-bit-Wert im ROM als ret nn 
(13 oder 14 Bit) speichern, und dann die Variable lesen, indem man an 
ihre Adresse springt. Die ist allerdings in SDCC noch nicht 
implementiert.

Philipp

von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
> Etwas verwirrend: Es gibt eine Firma in Shenzhen, die MCUs basierend auf
> der Padauk-FPPA Architektur vertreibt.
>
> http://www.puolop.com/products/category/mid/2/sid/15.html

Ich habe gerade mal die Datenblätter von Padauk PMC131/PMCS131 mit 
Puolop PTBO131XC/PTBO131SC verglichen. Die gleichen sich ja bis auf die 
Versionsnummern und Änderungsdaten.
Ansonsten hat Puolop wohl nur OTP, während es bei Padauk auch Flash 
gibt. Puolop hat nur µC mit 1 und 2 Cores, bei Padauk gibt es auch 
welche mit 8 Cores.
Allerdings gibt es bei Puolop auch 1-Core OTP µC, zu denen es 
anscheinend kein direktes Paduak-Äquivalent gibt (der PTBO164SX ist mir 
aufgefallen - im Datenblatt heißt er PTB164, es scheint sich um einen im 
Vergleich zu den anderen Puolop-µC recht neuen zu handeln, die erste und 
einzige Version des Datenblatts stammt von 2017).

Philipp

von Cyblord -. (cyblord)


Lesenswert?

Weihnachtsmann schrieb:
> Cyblord -. schrieb:
>>> Wo sollten Variablen denn sonst liegen?
>>
>> Er meint wohl diese speziellen Variablen die in exotischeren Teilen der
>> Welt als Konstanten bezeichnet werden. ;-)
>
>
> Also die nichtvariablen Variablen... ;)

Genau. "Konstante" darf man heute wegen politischer Korrektheit nicht 
mehr sagen. Man sagt "vermindert Variabel".

Ähnlich "Zombie". Darf man auch nicht mehr sagen. man sagt korrekt: 
"vermindert Lebender".

Bitte für nächstes Jahr merken. Wir wollen im Forum ja keine politische 
Unkorrektheit aufkommen lassen.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Cyblord -. schrieb:
> "Konstante" darf man heute wegen politischer Korrektheit nicht mehr
> sagen. Man sagt "vermindert Variabel".

Nein, das Wort "vermindert" ist nicht korrekt. Das drückt ja eine 
Wertigkeit aus, das geht gar nicht.

Besser, weil wertneutraler, heißt es also "anders variabel" oder 
"alternativ variabel" oder auch "nicht festgelegt variabel".

Das gleiche trifft natürlich auf Deinen Zombie zu, der ist eine 
"alternative Lebensform".

von Milpa (Gast)


Lesenswert?

Rufus Τ. F. schrieb:
> Cyblord -. schrieb:
>> "Konstante" darf man heute wegen politischer Korrektheit nicht mehr
>> sagen. Man sagt "vermindert Variabel".
>
> Nein, das Wort "vermindert" ist nicht korrekt. Das drückt ja eine
> Wertigkeit aus, das geht gar nicht.
>
> Besser, weil wertneutraler, heißt es also "anders variabel" oder
> "alternativ variabel" oder auch "nicht festgelegt variabel".
>
> Das gleiche trifft natürlich auf Deinen Zombie zu, der ist eine
> "alternative Lebensform".

Ihr schafft es jeden Thread auf euer Niveau herunter zuziehen.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Tatsächlich darf in diesem Forum auch mal geblödelt werden. Sofern das 
nicht das einzige ist, was Forenmitglieder von sich geben, ist das 
durchaus auch mal in Ordnung.

Anders sieht es aus, wenn Leute unflätig beleidigt werden (was wir hier 
leider auch des öfteren haben).

von Harald A. (embedded)


Lesenswert?

Dann lasst uns doch ab jetzt wieder mit Niveau weitermachen! Vielleicht 
ist es auch mal an der Zeit, den Mitwirkenden (insbesondere Philipp) an 
dieser Stelle zu danken! Wenn das so weitergeht, haben wir bald eine 
very-low-cost Plattform inkl. C Compiler am Start.

von Philipp Klaus K. (pkk)


Lesenswert?

Harald A. schrieb:
> Dann lasst uns doch ab jetzt wieder mit Niveau weitermachen! Vielleicht
> ist es auch mal an der Zeit, den Mitwirkenden (insbesondere Philipp) an
> dieser Stelle zu danken! Wenn das so weitergeht, haben wir bald eine
> very-low-cost Plattform inkl. C Compiler am Start.

Ich habe nun seit über zwei Wochen nicht am pdk14-Backend in SDCC 
gearbeitet; vermutlich finde ich erst im Januar wieder Zeit dafür.
Es könnte durchaus sein, dass das pdk14-Backend zum SDCC-Release 3.9.0 
noch nicht wirklich brauchbar ist. Das ebenfalls neue ez80_z80 Backend 
(für den eZ80 im Z80-Modus) ist da schon deutlich weiter (das war aber 
auch deutlich weniger Arbeit, da es auf dem bestehenden z180-Backend 
basiert, und Hynek Sladký die nötigen Änderungen im Assembler sdasxxxx 
erledigt hat).

Philipp

von Frank B. (foobar)


Angehängte Dateien:

Lesenswert?

Ich habe den "Writer", wie die ihren Chip-Programmierer nennen, und 
einen ICE (in circuit emulator). Vom ICE gibt es zwei Versionen, einen 
für die einfachen Chips wie PMS150C und einen extra ICE für die 
Multicore Chips, wie den PMC884. Da sind 8 Cores drin, hier das 
Datenblatt:

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

Wobei es sind keine richtig parallelen Cores, sondern es wird immer ein 
Befehl reihum abgearbeitet und nur der Stack und PC pro Takt gewechselt. 
Dennoch sinnvoll für manche Anwendungen.

Anbei ein kleines Beispielprojekt für den PMC884. Folgendes habe ich an 
den Pins damit gemessen:

PB0: 203 kHz
PB1: 44 kHz
PB2: 5 kHz
PB3: 508 Hz
PB4: 50.8 Hz
PB5: 5.08 Hz
PB6: 0.5 Hz
PB7: 0.05 Hz


Der Code dazu ist in Project2.C zu sehen, die anderen Dateien sind 
Initialisierungen und Projektdateien.

von Alexander S. (esko) Benutzerseite


Lesenswert?

Artikel angelegt: Padauk

von Philipp Klaus K. (pkk)


Lesenswert?

Alexander S. schrieb:
> Artikel angelegt: Padauk

Wenn ich mich recht erinnere, waren in dem inzwischen gelöschten 
deutschen Wikipedia-Artikel auch noch ein paar Informationen , die man 
übernehmen könnte.

Philipp

von Alexander S. (esko) Benutzerseite


Lesenswert?

Philipp Klaus K. schrieb:
> Wenn ich mich recht erinnere, waren in dem inzwischen gelöschten
> deutschen Wikipedia-Artikel auch noch ein paar Informationen , die man
> übernehmen könnte.

Gute Idee!
Man kann sich einfach von einem Wikipedia-Administrator den letzten 
Artikelstand jeden gelöschten Artikels schicken lassen, am einfachsten 
von dem, der ihn gelöscht hat.
Das habe ich getan und die Informationen eingearbeitet: Padauk.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Im übrigen ist die englischsprachige Gemeinde im eevblog-Forum mit der 
Analyse des Programmierprotokolls wohl etwas weitergekommen:

https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/?all

von Philipp Klaus K. (pkk)


Lesenswert?

Philipp Klaus K. schrieb:
> Nach einem zweiten Tag Arbeit am Padauk-backend für SDCC wird nun
> deutlich mehr vom C-Standard unterstützt, als in Padauks "Mini-C".
>
> Dennoch verbleiben deutliche Einschränkungen:
>
> * Variablen liegen immer im RAM, nicht im ROM.
> * Globale und statische Variablen sindnicht initialisiert.
> * Keine Gleitkommatypen und Bit-Felder.
> * Funktionen können nur bis zu 2 Byte zurückgeben (also kein long oder
> long long).
> * Keine multiplikativen Operatoren (*, /, %)
> * Funktionen sind nicht reentrant.
> * Keine variablen Argumente (...)
> * Keine Standardbibliothek
> * struct / union können nicht zugeweisen, übergeben oder zurückgegeben
> werden.
> * Keine compound literals.
> * Kein I/O von C her.
>
> Auch ist es bisher in reiner Compiler, ohne Verbindung zu Assembler und
> Linker, so dass die Ausgabe nur aus Asemblerocde besteht.
>
> Der erzeugte Code ist sehr ineffizient, aber das werde ich demnächst
> noch ein wenig verbessern.
>
> Philipp

Inzwischen gab es ein paar Verbesserungen. Globale und statische 
Variablen werden nun initalisiert, sehr einfache reentrante Funktionen 
und einfache Funktionen mit variablen Argumente funktionieren nun. I/O 
geht inzwischen auch. Der erzeugte Code ist nun etwas besser (aber da 
gibt es natürlich noch viel zu tun). Die meisten Funktionen der 
Standardbibliothek kompilieren nun immerhin ohne Compilerfehler (nahezu 
alle, die nicht mehr als 16 Bit zurückgegeben).

Als nächstes will ich die Unterstützung für reentrante Funktionen und 
Funktionen mit variablen Argumenten fertigimplementieren und die 
Verbindung zwischen Compiler, Assembler und Linker herstellen.

Der SDCC mit pdk14-Backend liegt wie bisher unter 
https://svn.code.sf.net/p/sdcc/code/branches/pdk/sdcc. Obwohl es pdk14 
heißt, habe ich es bisher so geschrieben, dass der erzeugte 
Assemblercode auf allen Varianten (pdk13 / SYM_84B, pdk14 / SYM_85A, 
pdk15 / SYM_86B, pdk16 / SYM_83A) des Padauk-Befehlssatzes assemblierbar 
sein sollte und nur dokumentierte Befehle verwendet.

Philipp

von Harald A. (embedded)


Lesenswert?

Habe gerade festgestellt, dass LCSC.COM jetzt auch das Programmiergerät 
und den Simulator im Angebot hat. Oder war das schon immer so? 
Allerdings etwas teuer, 1688.com und taobao.com waren da deutlich 
günstiger, wobei man da dann noch den Agent und relativ teuren Versand 
tragen muss.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?


von Tim  . (cpldcpu)


Lesenswert?


: Bearbeitet durch User
von Philipp Klaus K. (pkk)


Lesenswert?

Hier mal ein erster Versuch eines einfachen "Hello, World!" das von SDCC 
auch bereits in recht brauchbaren Assemblercode übersetzt wird (ja, der 
String liegt jetzt im ROM):

1
#include <stdbool.h>
2
#include <stdio.h>
3
4
volatile unsigned char sendcounter;
5
volatile unsigned int senddata;
6
volatile bool sending;
7
8
__sfr __at(0x04) inten;
9
__sfr __at(0x05) intrq;
10
__sfr __at(0x10) pa;
11
__sfr __at(0x11) pac;
12
__sfr __at(0x1c) tm2c;
13
__sfr __at(0x17) tm2s;
14
__sfr __at(0x09) tm2b;
15
16
void send_bit(void) __interrupt
17
{
18
  if(!(intrq & 0x40))
19
    return;
20
21
  if(!sending)
22
    return;
23
24
  pa = senddata & 1;
25
  senddata >>= 1;
26
27
  if(!--sendcounter)
28
  {
29
    sending = false;
30
31
    inten &= ~0x40;
32
  }
33
}
34
35
int putchar(int c)
36
{
37
  while(sending);
38
39
  senddata = (c << 1) | 0x200;
40
41
  sendcounter = 10;
42
43
  sending = true;
44
45
  inten |= 0x40;
46
47
  return (c);
48
}
49
50
void main(void)
51
{
52
  // TODO: Clock calibration for 8 Mhz.
53
54
  // Set timer 2 for interrupt at 9600 baud.
55
  tm2c = 0x10; // Use CLK (8 Mhz)
56
  tm2s = 0x61; // Divide by 64 ~> 125 kHz
57
  tm2b = 104;  // Divide by 104 ~> 9600 Hz
58
  inten = 0x00;
59
__asm
60
  enggint
61
__endasm;
62
63
  pac = 0x01;
64
65
  for(;;)
66
  {
67
    printf("Hello World!\n");
68
    for(unsigned long int i = 0; i < 150000; i++); // Wait approx. 3s.
69
  }
70
}

Philipp

von Harald A. (embedded)


Lesenswert?

Vielen Dank für den massiven Arbeitseinsatz, der Einstieg wird immer 
interessanter.

Wo und wie wird im SDCC printf mit putchar verknüpft? Ist das immer so?

von S. R. (svenska)


Lesenswert?

Harald A. schrieb:
> Wo und wie wird im SDCC printf mit putchar verknüpft? Ist das immer so?

Das ist die libc, die tut das so.

von Philipp Klaus K. (pkk)


Lesenswert?

Harald A. schrieb:
> Vielen Dank für den massiven Arbeitseinsatz, der Einstieg wird
> immer
> interessanter.
>
> Wo und wie wird im SDCC printf mit putchar verknüpft? Ist das immer so?

Da bei den üblichen µC nicht klar ist, was die Standardausgabe sein 
soll, überlässt SDCC dies dem Anwender, der ein putchar() bereitstellt, 
dass dann von allen Funktionen, die auf die Stadnardasugabe schreiben, 
verwendet wird.

Auch andere Compiler für µC (z.B. IAR, Cosmic, Raisonance) handhaben das 
so.

Philipp

von Harald A. (embedded)


Lesenswert?

Danke für die Erklärung, ich hatte es mittlerweile auch nachgeschlagen. 
Ich mache schon viele viele Jahre was mit C, die serielle Ausgabe habe 
ich mir aber immer anders hingebastelt. Aber ich lerne gerne immer dazu.

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


Lesenswert?

Interessant, dass der SDCC das durch ein Ersetzen von putchar handhabt 
und nicht durch ersetzen von _write.

von Philipp Klaus K. (pkk)


Lesenswert?

Weiterer Beispielcode für SDCC für pdk14:

https://github.com/free-pdk/sdcc-pdk-code-examples

Die Anbindung des Assemblers funktioniert inzwischen schon recht gut 
(dank Nicolas Lesser, der diesen geschrieben hat). An einfachen 
Evaluationsboards bin ich auch gerade dran. Und im EEVblog-Forum 
arbeiten andere fleißig daran, eine Alternative zum Padauk-Programmer zu 
schaffen.

Philipp

von Tim  . (cpldcpu)


Lesenswert?

Sehr schön, mit dem Update funktioniert mein Assembler-Blinky jetzt ohne 
Änderungen am Binärfile und Patch-script :) Mal schauen, ob das auch 
noch für die C-Version gilt.

von Tim  . (cpldcpu)


Lesenswert?

Wenn ich C-code compiliere, entsteht leider immer noch ein hexfile, in 
dem sich sektionen überlappen. Auch ein --code-loc 0x80 hat keine 
Abhilfe geschaffen.

von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
> Wenn ich C-code compiliere, entsteht leider immer noch ein hexfile, in
> dem sich sektionen überlappen. Auch ein --code-loc 0x80 hat keine
> Abhilfe geschaffen.

Hab' gerade 'mal das "Hello, world!" von 
https://github.com/free-pdk/sdcc-pdk-code-examples/tree/master/hello-pfs154 
kompiliert.

hello.map sagt:

* PDATA bei 0
* DATA bei 2

Sieht ok aus: Die liegen an den Adressen, wo sie hingehören (im RAM, 
hoffe ich).

* HOME bei 0x22
* GSINIT bei 0x24
* GSFINAL bei 0x38
* CODE bei 0x3a
* CONST bei 0x156

Sieht auch ok: Die liegen an den Adressen, wo sie hingehören (im ROM, 
hoffe ich).

Dann gibt es noch:

* HEADER1 bei 0
* HEADER3 bei 0

Sieht auf den ersten Blick seltsam aus. Im asm gibt es zweimal HEADER 
(ABS), einmal für den Code bei 0, einmal für den Code bei 0x20.

Was siehst Du im .ihx?

Philipp

P.S.: Auf den ersten Blick sieht bei mir das hello.ihx ok aus.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

Philipp Klaus K. schrieb:
> Sieht auf den ersten Blick seltsam aus. Im asm gibt es zweimal HEADER
> (ABS), einmal für den Code bei 0, einmal für den Code bei 0x20.
>
> Was siehst Du im .ihx?

Wenn ich das aus "Hello.c" genierte ihx File versuche zu laden, passiert 
untiges. Anscheinend uberlappt der Interrupt-Handler bei 0x20 mit einer 
anderen Sektion. Habe mein Makefile angehängt.
1
  File "/home/tim/.local/lib/python2.7/site-packages/intelhex/__init__.py", line 145, in _decode_record
2
    raise AddressOverlapError(address=addr, line=line)
3
intelhex.AddressOverlapError: Hex file has data overlap at address 0x20 on line 3
4
make: *** [cinclude] Error 1

: Bearbeitet durch User
von Philipp Klaus K. (pkk)


Lesenswert?

Ja, in Deinem .ihx überlappt GSINIT (0x16 Bytes ab 0x13) mit dem 
Interrupt-Handler. In meinem .ihx liegt GSINIT bei 0x24.

Das sieht aus, wie von einem SDCC von von ein paar Tagen.

Ist dein SDCC ein aktueller (rev. 10888)? Aber auch mit rev. 10887 hätte 
es (aber dort nur mit --code-loc) eigentlich schon funktionieren sollen.

Philipp

von Tim  . (cpldcpu)


Lesenswert?

Philipp Klaus K. schrieb:
> Ja, in Deinem .ihx überlappt GSINIT (0x16 Bytes ab 0x13) mit dem
> Interrupt-Handler. In meinem .ihx liegt GSINIT bei 0x24.
>
> Das sieht aus, wie von einem SDCC von von ein paar Tagen.
>
> Ist dein SDCC ein aktueller (rev. 10888)? Aber auch mit rev. 10887 hätte
> es (aber dort nur mit --code-loc) eigentlich schon funktionieren sollen.

Ok, hatte noch die 10887. Dabei hatte ich das SVN nach Deinem letzten 
Post upgedated. War evtl. zu schnell. Mit 10888 geht es jetzt.

Allerdings gibt es eine andere Merkwürdigkeit:
1
0140  00 17 40 18 0A 30 81 03 7A 00 72 00 C2 01 FF 28  |..@..0..z.r....(|
2
0150  80 13 80 03 7A 00 48 65 6C 6C 6F 20 57 6F 72 6C  |....z.Hello Worl|
3
0160  64 21 00 -- -- -- -- -- -- -- -- -- -- -- -- --  |d!.             |

Das ihx hört auf einer ungerade Addresse auf. Anscheinend wird der 
String byte- und nicht wortweise abgelegt.

: Bearbeitet durch User
von PPB (Gast)


Lesenswert?

Tim  . schrieb:
> Das ihx hört auf einer ungerade Addresse auf. Anscheinend wird der
> String byte- und nicht wortweise abgelegt.

Wieso ist das Merkwürdig? Ist dein String denn als int16_t * definiert? 
Dann wäre es das auf jeden Fall, sieht aber nicht so aus, bei dem 
Hexdump.

von Tim  . (cpldcpu)


Lesenswert?

PPB schrieb:
> Wieso ist das Merkwürdig? Ist dein String denn als int16_t * definiert?
> Dann wäre es das auf jeden Fall, sieht aber nicht so aus, bei dem
> Hexdump.

Der Speicher ist in 14bit-Worten organisiert. Ein String ließe sich in 
der Form in einem echten Device gar nicht ablegen.

von Philipp Klaus K. (pkk)


Lesenswert?

Bytes im ROM sollen für pdk14 erstmal als 14-Bit-Befehle ret k 
gespeichert werden. Die werden dann durch Sprung zur Adresse gelesen (da 
das ret k sein Argument in den Akkumulator legt, dann zurückkehrt).

Allerdings ist das im Assembler für .ascii und .db noch nicht 
implementiert.

Die offiziell von Padauk empfohlene Vorgehensweise zu Daten im ROM ist 
eine dieser Möglichkeiten zu verwenden:

1) ldtabl / ldtabh, das unterstützen aber nur die µC mit 15- und 16Bit 
Befehlssatz
2) Sequenz von ret k, mit pcadd a davor. Das ergibt etwas oberhead bei 
den Daten, ermöglicht aber schnelles [] (sofern der Index im Bereich 
0…253 liegt). Das wäre als Optimierung in SDCC eventuell später für 
manche Arrays im ROM sinnvoll.

Daneben gibt es noch die undokumentierten ldsptl / ldspth, bei denen ich 
aber nicht weiß, welche µC diese unterstützen.

Philipp

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

blinky.c wird jetzt auch mit nicht überlappenden segmentadressen 
compiliert und gelinkt. Leider ensteht trotzdem noch kein 
funktionierender Code.

Ein wesentlicher Punkt scheint zu sein, dass Sprungadressen über 
Segmente nicht richtig berechnet werden. Der Startupcode endet z.B. in 
einer Endlosschleife.
1
      000000 00 00                   66 nop
2
      000002 01 13                   67   clear  p+1
3
      000004 00 2F                   68   mov  a, #s_DATA
4
      000006 01 28                   69   add  a, #l_DATA + 1
5
      000008 6A 00                   70   sr  a
6
      00000A 6B 00                   71   sl  a
7
      00000C 82 01                   72   mov  sp, a
8
      00000E 00 38                   73   call  __sdcc_external_startup
9
      000010 00 30                   74   goto  __sdcc_gs_init_startup
10
                                     75   .area  GSINIT

: Bearbeitet durch User
von Philipp Klaus K. (pkk)


Lesenswert?

Das betrifft anscheinend alle Symbole, nicht nur Sprungadressen: #s_DATA 
und #l_DATA sehen auch nicht richtig aus.

Philipp

P.S.: Für blinky passen die beiden (da dort beide 0 sind), aber im 
"Hello, world!" nicht.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

Philipp Klaus K. schrieb:
> Das betrifft anscheinend alle Symbole, nicht nur Sprungadressen: #s_DATA
> und #l_DATA sehen auch nicht richtig aus.

Komischerweise hat es im Assembler-Blinky funktioniert. Daher nahm ich 
an, dass das Problem hauptsächlich bei Referenzen über Segmentaddressen 
besteht.

von Tim  . (cpldcpu)


Lesenswert?

Ich habe übrigens Experimente und Ergebnisse zu den Padauk MCUs hier 
abgelegt:

https://github.com/cpldcpu/SimPad

Mit einem ATmega168PA mit externem Boost-Converter ist inzwischen 
möglich den PMS150C, PFC154 und PFS154C zu programmieren. Allerdings ist 
der Aufbau noch weit von einem produktiven Programmierer entfernt.

Wie sich inzwischen zeigt, ist man für eine zuverlässige Programmierung 
darauf angewiesen, sowohl die Programmierspannung (Vpp ~ 5.5V - 13V) 
also auch die Versorgungspannung (Vdd ~ 2V-6.5V) zu kontrollieren.

Hat evtl. jemand eine gute Idee, auf welche existierende Platform man 
hier aufsetzen könnte?

Mir erschien zunächst der PicKit3 als gute Option, da es hier günstige 
Clones aus China gibt. Allerdings scheint Vdd auf 5.5V beschränkt zu 
sein. Außerdem gibt es wohl keine open source Firmware dafür, die man 
modifizieren könnte.

von Gerd E. (robberknight)


Lesenswert?

Tim  . schrieb:
> Hat evtl. jemand eine gute Idee, auf welche existierende Platform man
> hier aufsetzen könnte?

Für die Programmierspannung etc. kommst Du glaube ich kaum um 
spezifische Hardware herum. Höchstens noch sowas wie der TL866, aber da 
ist die Firmware komplett closed und es wäre erst mal massig 
reverse-engineering angesagt, inkl. dem CPLD.

Wenn man also eh schon eine eigene Platine dafür macht, kann man auch 
gleich alles mit draufpacken und braucht nicht noch irgendwelche 
Arduino-, Bluepill-,...-Boards zum aufstecken.

Was spricht also gegen die hier vorgeschlagene Hardware:
https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg2104882/#msg2104882

von Tim  . (cpldcpu)


Lesenswert?

Gerd E. schrieb:
> Was spricht also gegen die hier vorgeschlagene Hardware:
> 
https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg2104882/#msg2104882

Nichts - allerdings wäre es natürlich bequemer, eine existierende 
Hardware umzuwidmen.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Gerd E. schrieb:
> Höchstens noch sowas wie der TL866, aber da ist die Firmware komplett
> closed und es wäre erst mal massig reverse-engineering angesagt, inkl.
> dem CPLD.

Was für ein CPLD? Im TL866 ist ein PIC18F87J50 verbaut, der Schaltplan 
von dem Ding ist bekannt, und auch das Protokoll, das auf der 
USB-Schnittstelle verwendet wird.

Es dürfte dennoch mindestens problematisch werden:

- Die Hardware kann je acht unterschiedliche Werte für Betriebs- und 
Programmierspannungen erzeugen. Welche das sind, lässt sich mit eienm 
Datenblatt des MC34036 und etwas Rechnerei anhand des Schaltplans 
herausfinden.

Sind die für die Padauk-Chips benötigten Spannungen nicht darunter, ist 
das Projekt gestorben.

- Die Gerätefirmware enthält etwa 40 unterschiedliche 
Programmieralgorithmen. Es kann mit Sicherheit davon ausgegangen werden, 
daß der für die Padauk-Chips nicht enthalten ist, man müsste also neue 
Firmware für das Ding schreiben.

Das ist nicht unmöglich, da das Gerät recht gut dokumentiert ist, aber 
es ist verdammt viel Arbeit.

http://static.minipro.txt.si/mirror/docs/TL866_design.pdf
http://static.minipro.txt.si/mirror/docs/TL866_schematic.pdf

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

Gerd E. schrieb:
> Was spricht also gegen die hier vorgeschlagene Hardware:
> 
https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg2104882/#msg2104882

Vermutlich spricht NICHTS dagegen.

Wahrscheinlich würde auch eine dezent abgewandelte Version eines 
PIC-Brenners funktionieren, den ich mal vor einiger Zeit aus einer 
Minimalplatine für den STM32F103.. gemacht habe. Genauer gesagt waren es 
zwei Versionen, eine über den USB versorgt und die andere aus einem 15V 
Steckernetzteil von Pollin (falls man bei der VCC Lasten zu treiben 
hat).

Ich häng hier mal ne Geschmacksprobe beider Versionen dran. Wenn 
Interesse besteht, dann gibt's auch Eagle-Files und C Quellen. Und ja, 
da sind auch Dateien dabei, die schon bei der Lernbetty gedient haben.

Der Knackpunkt bei all sowas sind die Algorithmen:

Wenn es fix gehen soll, dann müßten diese im Adapter vorgehalten werden. 
Aber damit ist man extrem unflexibel, weil man für jede Detailänderung 
die Firmware ändern müßte.

Wenn man hingegen die Algorithmen im PC vorhält und den Adapter 
sozusagen 'dumm' macht, dann wird's langsam, weil ja alles und jedes im 
Detail über die Verbindung zum Adapter geschleift werden müßte. Dafür 
ist sowas aber universell.

Ich hatte da einen Mittelweg versucht. Es gibt sowohl Primitivkommandos 
für den Adapter als auch Zusammenfassungen für Zeugs, was sonst Zeit 
verbraucht, wie z.B. das serielle Hineintakten von Programmierkommandos 
und Daten und das Auslesen von Daten. Dabei ist die Bitbreite vom PC aus 
wählbar. Als Kommandoformat vom PC zum Adapter hatte ich die altbekannte 
Form Parameter zuerst, dann als Abschluß ein Kommandobuchstabe. Da sowas 
am PC zu längeren Strings zusammengefaßt werden kann, wird das dann auch 
recht schnell per USB zum Adapter befördert und damit wird das Ganze 
einigermaßen schnell.

W.S.

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


Lesenswert?

@W.S.:
Oder den Minimaladapter zur Laufzeit mit einem passenden Firmwareblob 
füllen.
Der kommt ins STM32F103 RAM und läuft dann da.
Schon hat man für jeden Padauk die passenden Algos im Progadapter.

von W.S. (Gast)


Lesenswert?

Mw E. schrieb:
> Oder den Minimaladapter zur Laufzeit mit einem passenden Firmwareblob
> füllen.

OK, mach mal.

W.S.

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


Lesenswert?

Momentan kann ich nur blöde Vorschläge machen, bin schon noch ne Weile 
ausgelastet mit eigenen Projekten.

von Tim  . (cpldcpu)


Lesenswert?

Vielen Dank für den Hinweis auf TP866. Sieht generell recht interessant 
aus, vor allem als "Retro-Programmer".

Rufus Τ. F. schrieb:
> Was für ein CPLD? Im TL866 ist ein PIC18F87J50 verbaut, der Schaltplan
> von dem Ding ist bekannt, und auch das Protokoll, das auf der
> USB-Schnittstelle verwendet wird.
>
> Es dürfte dennoch mindestens problematisch werden:
>
> - Die Hardware kann je acht unterschiedliche Werte für Betriebs- und
> Programmierspannungen erzeugen. Welche das sind, lässt sich mit eienm
> Datenblatt des MC34036 und etwas Rechnerei anhand des Schaltplans
> herausfinden.

>..

> http://static.minipro.txt.si/mirror/docs/TL866_design.pdf
> http://static.minipro.txt.si/mirror/docs/TL866_schematic.pdf

Nach meinen Berechnungen scheint der Minimalwert für Vpp 9.6V zu sein. 
Das ist zumindest für den PFS154 zu viel. Ärgerlich. Die OTP devices 
könnte man allerdings damit programmieren, die benötigen VPP>10V.

von Tim  . (cpldcpu)


Lesenswert?

W.S. schrieb:
> Wahrscheinlich würde auch eine dezent abgewandelte Version eines
> PIC-Brenners funktionieren, den ich mal vor einiger Zeit aus einer
> Minimalplatine für den STM32F103.. gemacht habe. Genauer gesagt waren es
> zwei Versionen, eine über den USB versorgt und die andere aus einem 15V
> Steckernetzteil von Pollin (falls man bei der VCC Lasten zu treiben
> hat).

Vielen Dank! Prinzipiell ist das sehr ähnlich zu dem Programmer, der 
gerade im EEV-Forum entwickelt wird. Viel einfacher scheint es also 
nicht zu werden.

> Der Knackpunkt bei all sowas sind die Algorithmen:
>
> Wenn es fix gehen soll, dann müßten diese im Adapter vorgehalten werden.
> Aber damit ist man extrem unflexibel, weil man für jede Detailänderung
> die Firmware ändern müßte.

Die Programmieralgorithmen sind recht einfach. Ich hätte keine Bedenken, 
dass es zu kompliziert würde, die in einer Firmware zu kombinieren. 
Problematisch ist eher, dass es eine Vielzahl an unterschiedlichen 
Interfaces gibt und jedes Device etwas anders gehandhabt wird.

von Tim  . (cpldcpu)


Lesenswert?

Ein paar mehr Codebeispiele in Assembler mit der opensource-Toolchain 
(SDCC/SDASPDK):

https://github.com/cpldcpu/SimPad/tree/master/PFS154Examples

von Philipp Klaus K. (pkk)


Lesenswert?

Philipp Klaus K. schrieb:
> Das betrifft anscheinend alle Symbole, nicht nur Sprungadressen: #s_DATA
> und #l_DATA sehen auch nicht richtig aus.
>
> Philipp
>
> P.S.: Für blinky passen die beiden (da dort beide 0 sind), aber im
> "Hello, world!" nicht.

Das sollte inzwischen besser funktionieren. Auch bei den Variablen im 
ROM / Flash wurden noch Bugs behoben (die werden nun als je ein 
14-Bit-Befehl ret k pro Byte gespeichert).

Philipp

von Tim  . (cpldcpu)


Lesenswert?

Yay! Mit SDCC 10908 wird tatsächlich der Blinky-code in ein auf dem 
PFS154 funktionierendes Executable compiliert!

https://github.com/cpldcpu/SimPad/tree/master/PFS154Examples

Ein paar Kleinigkeiten:

- In der Init-Routine könnte man die Sequenz "SR A, SL A" mit einem "AND 
a,#$FE" ersetzen.

- Anscheinend wird ein überflüssiges "RET" erzeugt, wenn funktionen 
einen Wert zurück geben:
1
      000000                        108 __sdcc_external_startup:
2
                                    109 ;  blinky.c: 13: clkmd = 0x78; // Disable ILRC, watchdog, clock= IHRC/64
3
      000000 78 2F                  110   mov  a, #0x78
4
      000002 83 01                  111   mov  _clkmd, a
5
      000004 00 02                  113   ret  #0x00
6
      000006                        114 00101$:
7
      000006 7A 00                  116   ret          <-----

- Bei CALL und GOTO tauchen im .lst-File im Hexcode überflüssige 
Buchstaben auf "r"?
1
      00000C 82 01                   72   mov  sp, a
2
      00000Er00r38                   73   call

- Ich weiss nicht, ob es ein Problem ist, oder nicht: Das "p"-register 
nutzt die gleichen Speicherstellen ($00), wie die Programmvariablen.

von Tim  . (cpldcpu)


Lesenswert?

Habe übrigens inzwischen auch den "echten" 0.03USD Microcontroller 
(PMS150) mit meinem programmer und der SDCC Toolchain programmieren 
können. Bisher allerdings nur in Assembler. Die Integration meiner 
Patches für PDK13 ist nicht ganz trivial, aber ich habe gesehen, dass 
Philip daran arbeitet.

PMS150C Beispiele:

https://github.com/cpldcpu/SimPad/tree/master/PMS150CExamples

von Tim  . (cpldcpu)


Lesenswert?

Das IRQ-Blinky sample habe ich jetzt auch erfolgreich auf echter 
Hardware testen können. Es gab noch einige Bugs, habe die Fixes direkt 
in den Master-Branch gepushed:

https://github.com/free-pdk/sdcc-pdk-code-examples/tree/master/timer_irq_blink

Philipp, hast Du einen Vorschlag, wie die Prozessorspezifischen 
include-files für SDCC aussehen könnten? Wie wird das bei SDCC 
normalerweise gehandhabt?

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

Tim  . schrieb:
> Die Programmieralgorithmen sind recht einfach. Ich hätte keine Bedenken,
> dass es zu kompliziert würde, die in einer Firmware zu kombinieren.
> Problematisch ist eher, dass es eine Vielzahl an unterschiedlichen
> Interfaces gibt und jedes Device etwas anders gehandhabt wird.

Eben. Ich geb dir mal was zum Lesen, das ich vor etwa 2 Jahren dazu 
gemacht habe. Normalerweise fange ich ein Projekt immer zuerst mit einer 
Planung an, die ich dann per PDF festnagele, um beim anschließenden 
Codieren den Überblick zu behalten. Ist ja immer ein "pas de deux" 
zwischen Pascal/Delphi auf dem PC und C auf dem µC.

Also, vielleicht ist das Ganze ne Anregung, wie man das auch bei diesen 
Padauk's handhaben kann. Auf so einem BluePill-Dingens sollte es auch 
laufen, da muß man dann aber die nötige Peripherie dazubasteln.

W.S.

von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
> - Ich weiss nicht, ob es ein Problem ist, oder nicht: Das "p"-register
> nutzt die gleichen Speicherstellen ($00), wie die Programmvariablen.

Das ist ein Problem. Anscheinend fehlt da noch etwas im Linker. Die 
Programmvariablen sollten eigentlich so liegen, wie im .map-File zu 
sehen (also insbesondere nicht an den Adressen 0 und 1).

Philipp

von Philipp Klaus K. (pkk)


Lesenswert?

Tim  . schrieb:
> - Bei CALL und GOTO tauchen im .lst-File im Hexcode überflüssige
> Buchstaben auf "r"?
>       00000C 82 01                   72   mov  sp, a
>       00000Er00r38                   73   call

Das .lst wird wohl vom Assembler, vor dem Linken erzeugt. An den 
Stellen, wo die r stehen, hat der Linker noch etwas zu tun (also die 
richtigen Zieladressen einzusetzen).

Philipp

von Tim  . (cpldcpu)


Lesenswert?

Philipp Klaus K. schrieb:
> Tim  . schrieb:
>> - Ich weiss nicht, ob es ein Problem ist, oder nicht: Das "p"-register
>> nutzt die gleichen Speicherstellen ($00), wie die Programmvariablen.
>
> Das ist ein Problem. Anscheinend fehlt da noch etwas im Linker. Die
> Programmvariablen sollten eigentlich so liegen, wie im .map-File zu
> sehen (also insbesondere nicht an den Adressen 0 und 1).

Habe die 10926 getestet. Anscheinend gibt es jetzt wieder ein Problem 
mit den Adressen? Alle Sprungaddressen sind falsch.

von Tim  . (cpldcpu)


Lesenswert?

W.S. schrieb:
> Eben. Ich geb dir mal was zum Lesen, das ich vor etwa 2 Jahren dazu
> gemacht habe. Normalerweise fange ich ein Projekt immer zuerst mit einer
> Planung an, die ich dann per PDF festnagele, um beim anschließenden
> Codieren den Überblick zu behalten. Ist ja immer ein "pas de deux"
> zwischen Pascal/Delphi auf dem PC und C auf dem µC.

Vielen Dank für das Dokument! Die PICs scheinen genau so chaotisch die 
die Padauk-Devices zu sein, wenn es um Programmieralgorithmen geht.

Der einfachste Ansatz scheint mir tatsächlich über eine virtuelle 
Serielle schnittstelle zu sein. Ob die auf der MCU sitzt (STM32F07xx) 
oder über einen getrennten USB2serial chip umgesetzt wird, ist ja egal. 
Für die Hostsoftware erscheint mir im Moment Python am geeignetsten.

von H. (Gast)


Lesenswert?

Tim  . schrieb:
> Vielen Dank für den Hinweis auf TP866. Sieht generell recht
> interessant
> aus, vor allem als "Retro-Programmer".
>
> Rufus Τ. F. schrieb:
>> Was für ein CPLD? Im TL866 ist ein PIC18F87J50 verbaut, der Schaltplan
>> von dem Ding ist bekannt, und auch das Protokoll, das auf der
>> USB-Schnittstelle verwendet wird.

> Nach meinen Berechnungen scheint der Minimalwert für Vpp 9.6V zu sein.
> Das ist zumindest für den PFS154 zu viel. Ärgerlich. Die OTP devices
> könnte man allerdings damit programmieren, die benötigen VPP>10V.

Die Modifizierung der drei (vier) Widerstände bei einer ansonsten 
tauglichen Hardware erscheint keine unüberwindbare Hürde. Bei einem 
bekanntem USB-Protokoll ist das doch eine gute Grundlage. Evtl. kann man 
sogar einen weiteren Widerstand irgendwo einbauen, der eine Erkennung 
der Modifikation per Software auslesbar macht.

von Philipp Klaus K. (pkk)


Angehängte Dateien:

Lesenswert?

Hier ein paar von Hand gelötete Evaluation-Boards für Padauk-µC (für 
PFS154 und PFS173; für den noch nicht erschienenen PFS232 ist nur das 
unbestückte Board zu sehen). Schaltpläne und Layout auf 
https://github.com/free-pdk/f-eval-boards.

von Philipp Klaus K. (pkk)


Lesenswert?

Inzwischen hat das pdk14-Backend seinen Weg in SDCC trunk gefunden (also 
werden wohl ab Morgen auch die Snapshots 
(http://sdcc.sourceforge.net/snap.php) die Padauk-µC mit 14-Bit breitem 
Programmspeicher unterstützen).

Auch die Ergebnisse der Tests sehen schon ganz gut aus:

Summary for 'pdk14': 10 failures, 2997 tests, 2101 test cases, 1463033 
bytes, 17333727 ticks

Allerdings wurden viele Tests für pdk14 abgeschaltet, da sie nicht in 
den Speicher passen würden; man vergleiche z.B. mit stm8:

Summary for 'stm8': 0 failures, 9265 tests, 2123 test cases, 2179290 
bytes, 21641588 ticks

Philipp

P.S.: Es gibt inzwischen auch ein pdk15-Backend, das halbwegs 
funktionieren sollte.

von Max M. (maxmicr)


Lesenswert?

Auf deinem GitHub findet sich auch ein Projekt über ein Programmiergerät 
für die Padauk-uCs. Ich wusste gar nicht, dass das Programmierverfahren 
schon geknackt ist. Wo findet man darüber mehr Informationen?

von Philipp Klaus K. (pkk)


Lesenswert?

Max M. schrieb:
> Auf deinem GitHub findet sich auch ein Projekt über ein Programmiergerät
> für die Padauk-uCs. Ich wusste gar nicht, dass das Programmierverfahren
> schon geknackt ist. Wo findet man darüber mehr Informationen?

Das Programmiergerät easy-pdk-programmer ist die Arbeit von 
js_12345678_55AA, der im eevblog-Forum aktiv ist 
(http://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/); 
freepdk auf GitHub; er hat auch das free-pdk-Projekt auf GitHub 
angelegt.

von Philipp Klaus K. (pkk)


Lesenswert?

Wem die Padauk-µC bisher zu teuer / groß waren, findet nun mit dem neuen 
P15A ein etwas abgespecktes Exemplar (½ KW ROM, 64 B RAM).

Es handelt sich um einen µC mit 13 Bit breitem Programmspeicher; diese 
werden von SDCC, wie auch jene mit 16 Bit breitem Speicher, noch nicht 
unterstützt. Sowohl bei 13, als auch bei 16 Bit gibt es für SDCC noch 
größere Probleme zu überwinden. Das pdk14-Backend für µC mit 14 Bit 
breitem Speicher funktioniert dagegen bereits recht gut, und ich gehe 
davon aus, dass es irgendwann Ende April beim pdk15-Backend ähnlich gut 
aussehen wird.

von Tim  . (cpldcpu)


Lesenswert?

Ich habe mir alle sub $0.10 MCU auf LCSC angeschaut:

https://cpldcpu.wordpress.com/2019/08/12/the-terrible-3-cent-mcu/

Die von Padauk sind immer noch die interessantesten.

von Philipp Klaus K. (pkk)


Lesenswert?

Seit einiger Zeit ist das pdk15 backend stable wie auch pdk14.
Für pdk13 gibt es ein Backend, das aber noch experimentell ist.

Ich gehe davon aus, dass sich daran bis zum nächsten Release auch nichts 
mehr ändern wird.


Philipp

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

Ich habe jetzt auch endlich den free-pdk programmer von JS 
zusammengebaut. (Habe vorher meinen Arduino-basierten genutzt). 
Praktischerweise funktioniert alles auf Anhieb.

Da sich die Bauteile nur mit Mindestordergrößen von 5-100 bestellen 
lassen, habe ich noch mehrere Bauteilsätzung und Platinen übrig. Wenn 
jemand interesse hat, würde ich die übrigens Bauteile gegen 
Portoerstattung überlassen. Es sind noch Platinen und Bauteile für 3 
Programmer vorhanden. Ledliglich von der MCU ist nur noch eine da.

Achtung: Das ist kein Projekt für Lötanfänger. (LFQP 0.4mm, 0603 
Bauteile etc.)

von Gerd E. (robberknight)


Lesenswert?

Tim  . schrieb:
> Achtung: Das ist kein Projekt für Lötanfänger. (LFQP 0.4mm, 0603
> Bauteile etc.)

Der STM32F072 ist LQFP-48 mit 0.5mm Pitch, die restlichen Teile sind 
gröber. So fein ist das nicht.

von Tim  . (cpldcpu)


Lesenswert?

Gerd E. schrieb:
> So fein ist das nicht.

Anscheinend bist Du kein Lötanfänger :) Ich habe nach dem Zusammenbau 
zum ersten Mal ernsthaft erwogen, mir Lötpaste+Hotplate zuzulegen, da 
einige Teile schon arg fummelig waren. z.B. die Schottky-Dioden (0402?) 
und der USB-Anschluss.

von Gerd E. (robberknight)


Lesenswert?

Tim  . schrieb:
> Anscheinend bist Du kein Lötanfänger :) Ich habe nach dem Zusammenbau
> zum ersten Mal ernsthaft erwogen, mir Lötpaste+Hotplate zuzulegen, da
> einige Teile schon arg fummelig waren.

Hmm. Lotpaste hilft Dir nur, wenn Du auch eine Schablone (Stencil) vom 
Platinenfertiger machen lässt. Außerdem ist Lotpaste eine ziemliche 
Mimose (gekühlt aufbewahren, vor Nutzung aber warm werden lassen, nur ~6 
Monate haltbar). Bei BGA-Bauteilen geht es ohne Paste kaum, aber für 
sowas hier ist das nicht nötig.

Der Trick ist dagegen das Flussmittel. Das richtige und viel davon, 
richtig viel, desto mehr, desto besser.

Ich nehme Amtech NC-559. Achtung: nicht bei ebay/Ali/... kaufen, da 
gibts nur Fälschungen. Statt dessen hier: 
https://www.tme.eu/de/details/anc559tf/flussmittel/amtech/nc-559-as/
Du brauchst aber noch einen Dispenser und eine Luer-Lock-Spitze dafür.

Als billigere Alternative kommt das hier recht nah ran:
https://www.reichelt.de/flussmittelgel-flutschi-fl-22-no-clean-5-ml-edsyn-fl-22-p32673.html?&trstct=pol_5

So, aber jetzt möchte ich den Thread hier nicht länger mit Löttips 
spammen. Bei weiteren Fragen mach bitte einen neuen auf.

von Tim  . (cpldcpu)


Lesenswert?

Gerd E. schrieb:
> Ich nehme Amtech NC-559. Achtung: nicht bei ebay/Ali/... kaufen, da
> gibts nur Fälschungen. Statt dessen hier:

Das stimmt. Die Fälschungen haben mir immer die Lötkolbenspitze 
zersetzt. Ich habe oben den Stannol-Stift von Reichelt genutzt. Das 
klappt einigermassen. Das Amtech-Original habe ich noch nicht 
ausprobiert.

Allerdings hilft das alles nur bedingt bei der Ausrichtung der Bauteile. 
Da ist es schon besser, wenn sie im Ofen in Position "schwimmen".

von Peter (Gast)


Lesenswert?

Interessante Doku zum Thema hier:
Beitrag "Beschreibung der Padauk Mikrocontroller"

von Philipp Klaus K. (pkk)


Lesenswert?

Vom PMS15A bekommt man wohl 10 Stück pro Cent:

https://detail.1688.com/offer/591310744735.html

von Harald A. (embedded)


Lesenswert?

Philipp Klaus K. schrieb:
> Vom PMS15A bekommt man wohl 10 Stück pro Cent:
>
> https://detail.1688.com/offer/591310744735.html

Da kommt leider das Anmeldefenster von 1688.com. Kannst du mal eine 
Hardcopy einstellen, würde mich interessieren.

von Tim  . (cpldcpu)


Lesenswert?

Philipp Klaus K. schrieb:
> Vom PMS15A bekommt man wohl 10 Stück pro Cent:

Ich glaube 10 pc ist die Mindestorder, 0.12 RMB der Stückpreis. 
Allerdings sieht mir das eher nach einem Lockangebot aus. Der PMS150C 
ist auch für 0.14 RMB gelistet.

Ich habe bei LCSC angefragt, wann sie die neuen Typen liefern können 
(Vor allem die neuen MTP Varianten). Leider kam keine brauchbare Antwort 
zurück.

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


Lesenswert?

Gerd E. schrieb:
> Ich nehme Amtech NC-559. Achtung: nicht bei ebay/Ali/... kaufen, da
> gibts nur Fälschungen. Statt dessen hier:
> https://www.tme.eu/de/details/anc559tf/flussmittel/amtech/nc-559-as/
> Du brauchst aber noch einen Dispenser und eine Luer-Lock-Spitze dafür.

Hätteste noch einen Dispenser als Empfehlung?

von Dieter R. (drei)


Lesenswert?

Tim  . schrieb:
> Philipp Klaus K. schrieb:
>> Vom PMS15A bekommt man wohl 10 Stück pro Cent:
>
> Ich glaube 10 pc ist die Mindestorder, 0.12 RMB der Stückpreis.

Selbst ohne Chinesisch-Kenntnisse ist das eindeutig, das 
größer/gleich-Zeichen ist international:

¥ 0.12
≥10 PCS

trotzdem ziemlich günstig. Ich glaube aber nicht, dass ich auf der 
Klickibunti-Website, alles in chinesisch, erfolgreich einen 
Bestellvorgang durchführen könnte. Die wendet sich wohl nur an das 
heimische Publikum.

von Tim  . (cpldcpu)


Lesenswert?

Neben C und Assembler gibt es jetzt auch einen Brainfuck-Interpreter für 
die Padauk MCU. Darauf hat die Welt gewartet!

https://github.com/cpldcpu/SimPad/tree/master/Toolchain/examples/pfs1xx_brainfuck

von Gerd E. (robberknight)


Lesenswert?

Mw E. schrieb:
>> Du brauchst aber noch einen Dispenser und eine Luer-Lock-Spitze dafür.
>
> Hätteste noch einen Dispenser als Empfehlung?

Ich habe einen OK 910-MSG. Der kostet aber so 50 EUR rum. Wird nur 
eingekauft und für die gelabelt sein. Findest Du z.B. auch unter JD927.

Ich habe die Dinger aber auch schon deutlich billiger auf Ali gesehen. 
Musst Du mal suchen. "hand glue dispenser gun 10cc" oder so wären meine 
Suchbegriffe.

von Harald A. (embedded)


Lesenswert?

Dieter R. schrieb:
> Ich glaube aber nicht, dass ich auf der
> Klickibunti-Website, alles in chinesisch, erfolgreich einen
> Bestellvorgang durchführen könnte. Die wendet sich wohl nur an das
> heimische Publikum.

Wenn man auf diesen Plattformen von Europa aus bestellen möchte geht das 
nur mit einem Agenten, z.B. Yoybuy.com, die meisten Händler dort liefern 
nur lokal. Bei Yoybuy.com braucht man nur den Link reinkopieren und 
schon geht es los. Habe ich selbst schon gemacht, war absolut 
problemlos. Die Gebühren für die Plattform hielten sich im Rahmen.

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


Lesenswert?

@Gerd E.
Danke für die Pointer.

von Olaf B. (Firma: OBUP) (obrecht)


Lesenswert?

@Gerd E.:
  ebenfalls Danke f. Links / Suchbegriff

@Harald A.:
  Youbuy.com akzeptiert meine Registrierung nicht. Irgendwas funzt 
nicht.

Muß ich mir Padauk µC woanders organisieren. Mal sehen. Bloß keine OTP 
fürs erste. :-)
LCSC habe ich Account, Auswahl f. Padauk's momentan aber eher mau...

PIC Kenntnisse - ASM & C - momentan eingerostet, diese µC als 
Quasi-Derivat würden mich für kleenere Projekte aber reizen, bei denen 
meine ARMs vollkommen überdimensioniert sind. AVR komme ich zwar klar, 
gehören aber nicht zu meinen Lieblingen...

Werde Thread beobachten... :-)

von Tim  . (cpldcpu)


Lesenswert?

Olaf B. schrieb:
> LCSC habe ich Account, Auswahl f. Padauk's momentan aber eher mau...

Warum? Die haben alle relevanten Flash-Typen: PFS154, PFS173. Die 
anderen sind noch nicht erschienen.

von Olaf B. (Firma: OBUP) (obrecht)


Lesenswert?

Hast recht - Order raus :-)

von Philipp Klaus K. (pkk)


Lesenswert?

Olaf B. schrieb:

> PIC Kenntnisse - ASM & C - momentan eingerostet, diese µC als
> Quasi-Derivat würden mich für kleenere Projekte aber reizen, bei denen
> meine ARMs vollkommen überdimensioniert sind. AVR komme ich zwar klar,
> gehören aber nicht zu meinen Lieblingen...

Keine Sorge, die Padauk unterscheiden sich deutlich von den PIC, sind 
angenehmer zu programmieren. Auch die SDCC-Backends sind schon 
brauchbarer als die für PIC.
Insbesondere hat Padauk einen Softwarestack, im Gegensatz zu PIC kann 
man also Funktionsaufrufe verschachteln, bis der Speicher alle ist 
(während es zumindest bei den kleinen PIC einen sehr enge Grenzen 
setzenden Hardwarestack gab).
Die Padauk-Architektur erscheint mir vom Stil her eher kleineren MCS-51 
zu entsprechen als PIC (es gibt z.B. 3 getrennte Adressräume - RAM, ROM, 
I/O).

von Philipp Klaus K. (pkk)


Lesenswert?

Dieter R. schrieb:
> Tim  . schrieb:
>> Philipp Klaus K. schrieb:
>>> Vom PMS15A bekommt man wohl 10 Stück pro Cent:
>>
>> Ich glaube 10 pc ist die Mindestorder, 0.12 RMB der Stückpreis.
>
> Selbst ohne Chinesisch-Kenntnisse ist das eindeutig, das
> größer/gleich-Zeichen ist international:
>
> ¥ 0.12
> ≥10 PCS
>

Ja. Dazu passend auch:

https://youtu.be/5jw5D0F008c

(da hat sich jemand das Die eines PMS150C genauer angeschaut; die 
Herstellungskosten eines PM150C-Die werden dort auf etwa einen halben 
Cent geschätzt, der PMS15A wird wenn überhaupt auch nur wenig billiger 
sein).

von Tim  . (cpldcpu)


Lesenswert?

Einige Fortschritte beim Zusammenstellen einer Toolchain:

https://github.com/cpldcpu/SimPad/tree/master/Toolchain

Es gibt jetzt größenoptimierte Funktionen für das "printf-style" 
Debugging mit soft UART:

https://github.com/cpldcpu/SimPad/tree/master/Toolchain/examples/uartsend

Damit ist die Softwareentwicklung mit SDCC und Easypdkprog inzwischen 
einigermaßen flüssig möglich. Weitere Bugs sind mir bisher weder im 
SDCC, noch im Easypdkprog aufgefallen. Gratulation an Philip und 
Mitstreiter sowie JS für die gute Arbeit!

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

Kleinere Updates

Library zur Ansteuerung von WS2812 RGB-Leds:

https://github.com/cpldcpu/SimPad/tree/master/Toolchain/examples/WS2812_blinky

Elektronische Kerze:

https://github.com/cpldcpu/SimPad/tree/master/Toolchain/examples/candleflicker

Ein leider nicht zufriedenstellender Versuch, mit dem PFS154 eine LED 
als Lichtsensor zu verwenden (unten):

https://cpldcpu.wordpress.com/2019/09/28/a-led-candle-based-on-the-3-cent-mcu/

von Max M. (maxmicr)


Lesenswert?

Weitere Neuigkeiten inzwischen?
Es wird anscheinend weiterhin fleißig am Compiler entwickelt:

http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/ChangeLog

: Bearbeitet durch User
von Philipp Klaus K. (pkk)


Lesenswert?

Max M. schrieb:
> Weitere Neuigkeiten inzwischen?
> Es wird anscheinend weiterhin fleißig am Compiler entwickelt:
>
> http://svn.code.sf.net/p/sdcc/code/trunk/sdcc/ChangeLog

Keine großen Neuigkeiten seit Mitte August. Nur viele kleinere 
Verbesserungen und Bugfixes (letztere insbesondere auch bei reentranten 
Funktionen, die nun zwar korrekt, aber halt aufgrund der Architektur 
immer noch ineffizient sind).

von Tim  . (cpldcpu)


Lesenswert?

Interessanter Artikel über Padauk:

https://www.digitimes.com/news/a20200225PD209.html
1
Taiwan-based MCU maker Padauk Technology expects its shipments of MCU products to grow by over 20% on year to reach 1.3 billion units in 2020, according to company Tang Tsan-bih.
2
3
Despite growing concerns about the stability of related supply chain caused by the coronavirus outbreak, Tang said that he believes demand for MCUs will remain strong, particularly from sectors including 5G base stations, servers and other cooling fan systems.
4
5
Boasting a group of strong supply chain partners, including Magnachip Semiconductor and Powerchip Semiconductor Manufacturing (PSMC) for wafer foundry and Greatek Electronics for IC backend services as well as inventories of needed components for up to three months, Padauk is readied to support product roll-outs of its clients, Tang stated.
6
7
For individual product category, shipments of 8-bit MCUs for BLDC (brushless DC) motors will account for about 30% of its totals sales in 2020, up from 23% a year earlier, Tang revealed.
8
9
Meanwhile, the company is also expected to see its shipments of MCUs for TWS (true wireless stereo) devices expand significantly in 2020, having shipped about 20 million units to the sector in 2019, according to an estimate of industry sources.
10
11
The sources also estimated that Padauk will see its 2020 revenues grow over 10% from the NT$522 million (US$17.17 million) it recorded a year ago.
12
13
Shares of the MCU maker is scheduled to debut on Taiwan's OTC securities market in the second half of March.

Der durschnittliche Verkaufspreis der Padauk MCUs liegt demnach bei nur 
$0.013! (17.7 Mio. / 1.3 Mrd)

p.s.: Die Zitierfunktion ist aber etwas launisch...

: Bearbeitet durch User
von Sebastian (Gast)


Lesenswert?

Revenue ist Gewinn, nicht Umsatz

von Tim  . (cpldcpu)


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:

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)


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)


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)


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:

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)


Lesenswert?

@ Tim

Vielen Dank.

von Mehmet K. (mkmk)


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:

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)


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)


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. (pkk)


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)


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)


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:

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:

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:

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. (pkk)


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)


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)


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)


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)


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:

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)


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)


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)


Lesenswert?

Meine Güte gehst du mir auf den Geist.

von Tim  . (cpldcpu)


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)


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)


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)


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. (pkk)


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)


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)


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)


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)


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)


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. (pkk)


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)


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


Lesenswert?

Hallo :)
Ich dachte mir, dasa ich die Frage am besten hier mit rein stelle a 
statt einen neuen Thread aufzumachen.
Ich verwende jetzt schon ein Weilchen die Padauk uC und mich würde 
interessieren, wie ich erkenne wie viel Speicher also sowohl ROM als 
auch RAM von meinem Code belegt werden. Ich habe schon hin und wieder 
gelesen, dass man hierfür das .map File heranziehen kann. Dort habe ich 
auch eine Zeile mit Code gefunden. Entspricht die dort angegebene Größe 
1 zu dem belegten ROM im uC?

Schon mal vielen Dank für eure Antworten :)

Beitrag #6477629 wurde vom Autor gelöscht.
Beitrag #6477640 wurde vom Autor gelöscht.
von Ralph S. (jjflash)


Angehängte Dateien:

Lesenswert?

Wenn du unter Linux arbeitest und den SDCC verwendest: Ich habe für mich
ein kleines C-Programm geschrieben, dass die generierte IHX Datei
auswertet und somit den Speicherbedarf im Flash des Padauks bestimmt:

Syntax:

pfsreadhex device filename

Beispiel:

pfsreadhex pfs154 foo.ihx

Anmerkung der Name für das Device ist NICHT case sensitive (es wird
nicht zwischen Groß- und Kleinschreibung unterschieden. Der Dateiname
filename ist sehr wohl case sensitive (weil Linux eben case sensitive im
Umgang mit Dateinamen ist).

----------------------------------------

Der RAM Bedarf ist im Map-File abgelegt, hierbei ist jedoch
logischerweise nicht berücksichtigt, wieviele Bytes der Stack benötigt.
Es wird hier nur angezeigt, wieviel Speicherplatz die Variablen belegen.

Du findest im Map-File einen Abschnitt wie diesen hier (einen Dank hier
an Philipp Klaus K. , der mich aufgeklärt hat, dass die diesem Abschnitt
folgende Liste NICHT anzeigt, wieviel Ram-Platz eine einzelne Variable
belegt)
1
Area                                    Addr        Size        Decimal Bytes (Attributes)
2
--------------------------------        ----        ----        ------- ----- ------------
3
DATA                                00000002    00000061 =          97. bytes (REL,CON)

Eventuell schreibe ich noch einen Parser, der das Map-File nach dieser
Stelle durchsucht und dann werde ich diese in pfsreadhex evtl.
integegrieren.

Gruß,
Ralph

von Ralph S. (jjflash)


Angehängte Dateien:

Lesenswert?

Ich habe dem Progrämmchen die Auswertung des Map-Files mit hinzugefügt.

Die Syntax lautet jetzt:

pfsreadhex device projectname

Für projectname darf keinerlei Dateiextension mit angegeben werden, 
dieses fügt pfsreadhex automatisch hinzu.

Beispiel:

pfsreadhex pfs154 foo

analysiert foo.ihx und foo.map

Gruß,
Ralph

von Tobias (Gast)


Lesenswert?

Danke für die Antwort.
Linux habe ich leider nicht, aber ich werde die C Datein schon 
verstehen. Ich programmiere derzeit nämlich meine eigene GUI für den 
SDCC und die easypdkprogrammer.exe, damit das ganze benutzerfreundlicher 
ist. Da werde ich das dann mit einbauen

von Ralph S. (jjflash)


Lesenswert?

Tobias schrieb:
> Ich programmiere derzeit nämlich meine eigene GUI für den
> SDCC und die easypdkprogrammer.exe, damit das ganze benutzerfreundlicher
> ist.

Oha, da bin ich mal gespannt. Ich hoffe du stellst das ganze dann hier 
vor. Ich habe meine eigene IDE mittlerweile fertig, jedoch allerdings 
als TUI... (ich bin halt ein alter Mensch und immer noch ein Fan der 
uralten Borland Produkte)

von Tim  . (cpldcpu)


Lesenswert?

fyi, ich habe die aktuellen Designunterlagen zum lite-programmer hier 
abgelegt:

https://github.com/free-pdk/easy-pdk-programmer-lite-hardware

Leider ist im Moment der STM32F072 bei JLCPCB nicht lieferbar, so dass 
man ihn nicht automatisiert bestücken lassen kann.

von Tobias (Gast)


Lesenswert?

Ralph S. schrieb:
> Ich hoffe du stellst das ganze dann hier vor.

Kann ich gerne machen :)

Tim  . schrieb:
> Leider ist im Moment der STM32F072 bei JLCPCB nicht lieferbar

Weist du woran das liegt? Ich wollte nämlich noch ein paar normal 
Programmer aufbauen, jedoch bekommt man die fast niergends mehr. Und der 
Preis den LCSC angibt (obwohl er nicht auf Lager ist)  war das letzte 
mal bereits bei 14€.
Gibt es irgendwelche Alternativen? Ich kenne mich mit den STM32 nicht 
sonderlich aus, da 8bit für mich bisher vollkommen ausreichend waren.

von Tobias (Gast)


Lesenswert?

@Ralph S. könntest du mir kurz deinen Code erklären bzw. wie die Größe 
ermittelt wird.

von W.S. (Gast)


Lesenswert?

Tobias schrieb:
> Weist du woran das liegt? Ich wollte nämlich noch ein paar normal
> Programmer aufbauen, jedoch bekommt man die fast niergends mehr. Und der
> Preis den LCSC angibt (obwohl er nicht auf Lager ist)  war das letzte
> mal bereits bei 14€.
> Gibt es irgendwelche Alternativen?

Ja, ich weiß, woran das liegt.

Die Firmware ist eben nicht so strukturiert, daß man sie problemlos auf 
eine andere HW portieren kann. Hätte man sie so gemacht, daß man eine 
saubere Trennung zwischen Programmieralgorithmen, generellem 
Systemsetup, Kommunikationskanal und Lowleveltreibern durchgezogen 
hätte, dann wäre das Ausweichen auf irgendwelche andere Hardware 
überhaupt kein Problem gewesen. Aber so, wie sie ist, geht das eben 
nicht - zumal nicht einmal das Kommunikationsinterface PC<-->µC 
dokumentiert ist.

Die einzige Alternative wäre, die Firmware eben so umzuschreiben, daß 
man sie leicht portieren kann, z.B. auf einen LPC11Uxx oder NUC120 oder 
so etwas ähnliches.

Aus meiner Sicht wäre sogar ein tiefer greifendes Umstrukturieren 
sinnvoll: nämlich derart, daß die Algorithmen auf der PC-Seite 
verbleiben und der µC lediglich atomare Lowlevel-Operationen durchführt. 
Also Spannungen einstellen, Präambel applizieren, Programmierworte 
schreiben/lesen und dergleichen.

All so etwas steht oder fällt jedoch mit einer sauberen Definition des 
Protokolls zwischen PC und µC. Ich hatte das damals bei meinem 
PIC-Programmer so gemacht und es ist wirklich gut praktikabel. Für die 
Padauks würde ich sowas ja ebenfalls beisteuern, aber dafür braucht es 
eine ordentliche Dokumentation. Einfach nur zu sagen "lies dich durch 
den Wust an Forenseiten durch" ist daneben.

W.S.

von Tim  . (cpldcpu)


Lesenswert?

Tobias schrieb:
> Tim  . schrieb:
>> Leider ist im Moment der STM32F072 bei JLCPCB nicht lieferbar
>
> Weist du woran das liegt? Ich wollte nämlich noch ein paar normal
> Programmer aufbauen, jedoch bekommt man die fast niergends mehr. Und der

Keine Ahnung, man könnte beim Support anfragen. Die MCU war schon 
häufiger nicht lieferbar und ist nach einiger Zeit wieder verfügbar 
gewesen.

von Tobias K. (tobias-k)


Angehängte Dateien:

Lesenswert?

Hallo Ralph,
ich denke ich die ROM berechnung in deinem Programm jetzt mehr oder 
weniger verstanden. Bei dem Bsp müsste demnach der benötigte Speicher 
528 Byte betragen oder? Den ausführlichen Weg dorthin hab ich in dem 
Textfile.

:02002000253089
:10000000000001 13072F0428FE2C820173381230E0
:20002400022F800B1930002F80030012022F052800171530FF2F820BFF2F830BFF2F840 
B05
:0600440005130613113044
:06020A000913A0307A0088

Falls das vorgehen so stimmt würde ich gerne noch wissen, wieso du 
(0x400e <= fadress <= 0x4012 oder 0x10010 <= fadress <= 
0x10014)abprüfst.

: Bearbeitet durch User
von Gerd E. (robberknight)


Lesenswert?

Tobias schrieb:
>> Leider ist im Moment der STM32F072 bei JLCPCB nicht lieferbar
>
> Weist du woran das liegt? Ich wollte nämlich noch ein paar normal
> Programmer aufbauen, jedoch bekommt man die fast niergends mehr.

Die sind momentan auf Allokation, die dürften so gut wie überall 
ausverkauft sein.

Könnte mir gut vorstellen daß das Nachwehen vom Corona-Lockdown im 
Frühjahr sind.

von Philipp Klaus K. (pkk)


Lesenswert?

Ralph S. schrieb:
> Tobias schrieb:
>> Ich programmiere derzeit nämlich meine eigene GUI für den
>> SDCC und die easypdkprogrammer.exe, damit das ganze benutzerfreundlicher
>> ist.
>
> Oha, da bin ich mal gespannt. Ich hoffe du stellst das ganze dann hier
> vor. Ich habe meine eigene IDE mittlerweile fertig, jedoch allerdings
> als TUI... (ich bin halt ein alter Mensch und immer noch ein Fan der
> uralten Borland Produkte)

Eine naheliegende Möglichkeit könnte sein, eine Art 
easy-pdk-programmer-Plugin für eine IDE zu schreiben, die bereits SDCC 
unterstützt (z.B. Code::Blocks).

von Tim  . (cpldcpu)


Lesenswert?

Oder man konfiguriert sich einfach mit ein paar Zeilen einen 
VSCode-Workspace:
1
{
2
  "settings": {
3
    "C_Cpp.default.defines": [
4
      "PFS173"
5
    ],
6
    "C_Cpp.default.intelliSenseMode": "msvc-x64",
7
    "C_Cpp.default.systemIncludePath": [
8
      "${workspaceFolder}/include/",
9
      "${workspaceFolder}/include/pdk",
10
      "${workspaceFolder}/include/pdk/device",
11
      "C:/Program Files (x86)/SDCC/include/",
12
      "."
13
    ],
14
    "C_Cpp.default.cStandard": "c99",
15
    "cSpell.allowCompoundWords": true,
16
    "cSpell.diagnosticLevel": "Hint",
17
    "cSpell.enabled": false,
18
  }
19
}

Die Builds mache ich in der Konsole. Das ist Geschmackssache.

Ich vermute aber, hier es eher der Weg das Ziel :) Ich kann es 
nachvollziehen.

von Ralph S. (jjflash)


Angehängte Dateien:

Lesenswert?

Tobias K. schrieb:
> Falls das vorgehen so stimmt würde ich gerne noch wissen, wieso du
> (0x400e <= fadress <= 0x4012 oder 0x10010 <= fadress <=
> 0x10014)abprüfst.

Das ist, Asche über mein Haupt, ein Fehler von mir und ist ein 
Überbleibsel von einem Programm, das ich original für 
PIC-Mikrocontroller geschrieben hatte. Dort sind die Adressbereiche 
Konfigurationsworte und haben mit dem Flashspeicherbedarf nichts zu tun.

Im obigen Programm führt das zu keinem Fehlverhalten, da Byteadressen 
größer als 0x1800 bei einem Padauk Controller nicht auftreten können:

PFS154: 2k words, max. Wordadresse 0x07ff, max. Byteadresse 0x0fff
PFS173: 2k words, max. Wordadresse 0x0bff, max. Byteadresse 0x17ff

Die Zeilen
1
// die Configuration Words fuer hoechste Programmadresse ignorieren
2
  if (!( ((fadress >= 0x400e) && (fadress <= 0x4012))   ||
3
        ((fadress >= 0x10010) && (fadress <= 0x10014))    ))
können also gelöscht werden.

Grundsätzlich erfolgt nur eine Auswertung einer Intel-Hex-Datei, siehe 
auch:

https://de.wikipedia.org/wiki/Intel_HEX

Bei einer Zeichenposition wird von 0 an gezählt.

Zeichenpositon 0 muss in einer Datei immer ":" sein, sonst ist es keine 
Intel-Hex Datei.

Position 1.2 geben eine hexadezimale Zahl an, wieviele Datenbytes in 
einer Zeile vorhanden ist.

Position 3..6 geben in hexadezimaler Form eine 16-Bit Speicheradresse 
an, ab der später im Flash Datenbytes abgelegt werden, wenn die 
hexadezimale Zahl in Position 7..8 gleich 0x00 ist.

Position 9 und folgende sind die Datenbytes, die ins Flash geschrieben 
werden.

Was ich also mache ist, ausgehend davon, dass die kleinste 
Flashspeicheradresse 0 ist, die Datenbytes in einer Zeile zu zählen und 
diese der Adresse der Zeile hinzuzuaddieren.

Ist diese so ermittelte höchste Adresse einer Zeile größer als die 
bisher höchste festgestellte Adresse, wird diese der Variable mit der 
höchsten festgestellten Adresse zugeteilt.

Am Ende wird die ermittelte Anzahl der Bytes durch 2 geteilt, damit in 
der späteren Anzeige die Ausgabe als "Anzahl Words" ausgegeben werden 
kann.

---------------------------------------------------------

Deine Bytereihe
1
:020020 00 253089
2
:100000 00 00000113072F0428FE2C820173381230E0
3
:200024 00 022F800B1930002F80030012022F052800171530FF2F820BFF2F830BFF2F840B05
4
:060044 00 05130613113044
5
:06020A 00 0913A0307A0088

ergibt tatsächlich eine Anzahl von 528 Datenbytes = 264 Words, wobei 
hier anzumerken ist, dass das noch keine zulässige Intel-Hex Datei ist, 
weil ihr der "End of file" Record (Typ 01) fehlt. Dieser Record 
beinhaltet bei 8 Bit Daten auch die Startadresse, die bei Systemen, 
deren Flashspeicheradresse nicht bei 0x0000 beginnt, ausgewertet werden 
muß (höchste Adresse minus dem Wert der Startadresse ergibt den Flash 
Speicherbedarf)

-------------------------------------

Hm, das Erklären des Intel-Hex Formats gehört aber eigentlich nicht in 
diesen Thread, weil es hier ja um die Padauk Controller geht und eben 
nicht um das Intel-Hex Format welches vom SDCC als Ausgabeformat 
verwendet wird.

Gruß,
Ralph

von Ralph S. (jjflash)


Lesenswert?

Philipp Klaus K. schrieb:
> Eine naheliegende Möglichkeit könnte sein, eine Art
> easy-pdk-programmer-Plugin für eine IDE zu schreiben, die bereits SDCC
> unterstützt (z.B. Code::Blocks).

Das wäre zum einen eine Möglichkeit, oder man nimmt das ganze als ein 
"Makefile" Projekt, bindet die Hostsoftware zum Easy-PDK-Programmer in 
das Makefile mit ein und hat eine (sehr einfache) GUI mittels Geany 
(welches ein Makefile aufrufen kann)

von Ralph S. (jjflash)


Lesenswert?

Gerd E. schrieb:
> Die sind momentan auf Allokation, die dürften so gut wie überall
> ausverkauft sein.

stimmt... Reichelt hat scheinbar noch welche, hat aber seinen Preis im 
vl. zu von vor 2 Wochen nahezu verdoppelt auf jetzt 7,22 € für einen 
F072CBT6

Abartig

von Tobias K. (tobias-k)


Lesenswert?

Ralph S. schrieb:
> Tobias schrieb:
>> Ich programmiere derzeit nämlich meine eigene GUI für den
>> SDCC und die easypdkprogrammer.exe, damit das ganze benutzerfreundlicher
>> ist.
>
> Oha, da bin ich mal gespannt. Ich hoffe du stellst das ganze dann hier
> vor. Ich habe meine eigene IDE mittlerweile fertig, jedoch allerdings
> als TUI... (ich bin halt ein alter Mensch und immer noch ein Fan der
> uralten Borland Produkte)

Für die die es interessiert, habe ich meine kleine GUI in nem extra 
Thread kurz ein wenig vorgestellt.

Beitrag "Padauk Graphical User Interface"

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
Noch kein Account? Hier anmelden.