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.
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.
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.
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?)
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.
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
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
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.
... 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.
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
Es gibt von Padauk zwei Patentapplikationen zu einem multi-threaded
Microcontroller.
https://patents.google.com/patent/US20070067605https://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.
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
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=78http://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?
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.
>> 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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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".
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.
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...
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. :-)
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...
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
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.
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.
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.
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.
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
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.
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
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.
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?
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.
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.
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
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.
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
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.
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?
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.
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.
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.
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.
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
Habe mal einige der Befehlskodierungen rekonstruiert.
Die Befehle sind als 14bit-Wort kodiert, ähnlich PIC16. Das Encoding ist
allerdings nicht binärkompatibel.
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.
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
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.
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
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.
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
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.
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
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
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:
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.
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 ?
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
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
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.
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?
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
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.
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.
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
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.
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.
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
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
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.
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?
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!
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?
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
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.
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.
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.
Philipp Klaus K. schrieb:> Dennoch verbleiben deutliche Einschränkungen:> * Variablen liegen immer im RAM, nicht im ROM.> ...
Wo sollten Variablen denn sonst liegen?
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. ;-)
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... ;)
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
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
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.
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".
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.
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).
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.
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
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.
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
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.
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
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.
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):
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?
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
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.
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
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.
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.
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.
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
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
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:
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.
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.
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
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.
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.
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.
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.
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
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.pdfhttp://static.minipro.txt.si/mirror/docs/TL866_schematic.pdf
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.
@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.
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.
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.
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
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:
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
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?
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.
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
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
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.
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.
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.
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.
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.
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?
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.
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.
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
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.)
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.
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.
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.
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".
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.
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.
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.
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.
@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... :-)
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.
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).
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).
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!
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).
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...
Thread beobachten
Seitenaufteilung abschalten
