Forum: Projekte & Code Padauk PFS154 Programmer mit Arduino Uno / ATmega88 - 328


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Ralph S. (jjflash)



Lesenswert?

Da die Beschreibung des Projekts sehr (sehr) lange geraten ist und ich 
nicht jedem zumuten will alles zu lesen hier nur kurz um was es sich 
handelt:

- absolutes DIY Projekt eines Arduino-Shields, das einen PFS154 
Programmer realisiert
- das ganze auf einem Lochraster - r3 Prototypen PCB mit ausschließlich 
bedrahteten Standardbauteilen
- für Linux 64-Bit Systeme

Für diejenigen die das interessiert habe ich das readme.txt File 
angehängt. Das gezeigt Layout funktioniert nur auf Prototypenplatinen, 
die zwischen den beiden Reihen 16 Pads zur Verfügung haben.

Von dem Entwurf habe Gerberfiles erstellt und ich werde 5 Platinen 
erhalten (hoffentlich), das ganze auch deshalb, weil ich noch nie etwas 
bei JLCPCB bestellt habe: Ich bin gespannt (auch wenn es eigentlich eine 
Verschwendung ist, eine solche Platine fertigen zu lassen, hier hätte 
man dann noch einiges realisieren können, hätte man es in SMD gemacht).

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ralph S. schrieb:
> Von dem Entwurf habe Gerberfiles erstellt und ich werde 5 Platinen
> erhalten (hoffentlich),

Brauchst Du alle 5 Platinen? ;-)

Tolles Projekt! Auch Deine anderen Padauk-Projekte. Zusammen mit diesem 
Programmer macht es dann auch für Außenstehende Sinn, sich mal die 
PFS-Mikrocontroller näher anzuschauen.

Ich tippe mal darauf, dass noch mehr Leute so eine Platine möchten ;-)

von Ralph S. (jjflash)


Angehängte Dateien:

Lesenswert?

Vielen Dank fürs Lob, aber dieser gebührt in erster Linie denen, die den 
Chip "reversed engeneert" haben und extrem Hirnschmalz investiert haben. 
Hier dann Philipp Klaus Krause, CPLDCPU - Tim und noch heftiger die 
Leute vom EEVblog (und hier dann im speziellen js_12345678_55AA der wohl 
heftig Zeit und Hirnschmalz in das Programming Protokoll gesteckt hat). 
Beim EEVblog bin ich nicht involviert (ich habe nur mitgelesen) und auch 
hier war ich nicht so wirklich involviert. Insofern bin ich nur ein 
Nutzer dessen, was die erarbeitet haben.

Ich "verwende" nur deren Erkenntnisse / Arbeit um dann mit dem PFS in 
einer mir gewohnten Art und Weise umgehen zu können.

Derzeit werkel ich an meinem eigenen Setup mit einer eigenen TUI-IDE 
speziell für den PFS154 und einem integrierten Makefile-Generator und 
schreibe dazu immer wieder mal "kurzen" Code für den PFS (in aller Regel 
portiere ich hier Funktionen die ich an sich für andere Controller 
geschrieben habe und schaue, ob die unter dem PFS lauffähig sind). Heute 
morgen bswp. habe ich auf die Schnelle (eines Nachbarthreads) die 
Software für Standardtextdisplays nach PFS portiert.

In wie weit das Sinn macht möchte ich nicht überdenken, ich denke dass 
der PFS für Kleinstanwendung und "Sklavenarbeit" hergenommen werden kann 
(wie bpsw. Tim's kaskatierbare 7-Segmentanzeige).

Einige (viele) Dinge habe ich schon gemacht und ich sollte mich mal mehr 
um das "Paket schnüren" kümmern, damit ich ein "Gesamtpaket" vorstellen 
kann.

Der Programmer war hierzu zwingend notwendig, damit ein Bastler das 
einfach auf die Schnelle aufbauen kann... und wenn es auf einem 
Steckbrett mit einem Arduino-Nano ist (der wird wohl, auch wenn viele 
die Nase rümpfen doch wohl bei fast allen irgendwo rumliegen). Der Rest 
ist absolutes Standard-Bastelmaterial.

Im Moment versuch ich dahinter zu kommen, wie das Protokoll für den 
PFS173 funktioniert, lt. EEVblog sollte das so sein wie beim 154 nur mit 
15 statt 14-Bitbreite und erhöhter Programmierspannung ==> leider ist 
dem nicht so.

Gruß,

Ralph

PS: ich habe gesehen, dass die readme.txt irgendwie mit einem falschen 
Zeichensatz gespeichert wurde... ich habe sie jetzt wieder in den von 
mir präferierten Weise mit 7-Bit Ascii korrigiert und hier noch einmal 
mit angefügt

von Ralph S. (jjflash)


Lesenswert?

(über mich selbst lachen muß, weil zu viel gelabert und geschrieben): 
Ich wollte ja eigentlich nur hierauf eingehen:

Frank M. schrieb:
> Brauchst Du alle 5 Platinen? ;-)

Ich brauche genaue eine (bzw. will genau eine) da ich ja bereits einen 
Easy-PDK und eben den auf Lochraster-Karte aufgebauten habe.

Sollte da jemand eine Platine haben wollen (wenn sie da sind), kann ich 
mir schon vorstellen 4 Stck. davon für 3 oder 4 Euro pro Stück inkl. 
Porto in einem Briefkuvert zu verschicken !

;-)

Lachen muß: wenn man mir wirklich wirklich glaubhaft erklärt, dass man 
am Hungertuch nagt und einen dann 3 oder 4 Euro ruinieren, verschenk ich 
sie vllt. auch (aber eben nur vllt.)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ich nehme gerne eine Platine, ich finde diese kleinen µCs sehr 
interessant. Ich melde mich bei Dir dann per Mail.

von Ralph S. (jjflash)


Lesenswert?

Ich schick dir gerne eine... wenn sie da sind ! Das wird allerdings 
höchstwahrscheinlich dieses Jahr nichts mehr, denn ich habe sie erst 
gestern geordert und ab nächster Woche bin ich in Urlaub (und die 
Lieferadresse ist meine Firmenadresse).

;-) bis dahin geht ja auch vllt. das Versenden an eine GMX-Mail wieder !

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ralph S. schrieb:
> Ich schick dir gerne eine... wenn sie da sind !

Kein Problem, ich hab Zeit :-)

von bingo (Gast)


Lesenswert?

Ralph S. schrieb:
> Von dem Entwurf habe Gerberfiles erstellt

Wäre schön, wenn Du die hier einstellen könntest.

Tolles Projekt, ich wollte mich schon immer mal mit den Padauks 
beschäftigen,
meine sowieso schon vorhandene Neugier wurde jetzt noch gesteigert.

von bingo (Gast)


Angehängte Dateien:

Lesenswert?

Für alle, welche die Platine lieber selber ätzen wollen, gibt es hier 
jetzt ein PDF

von Ralph S. (jjflash)


Lesenswert?

bingo schrieb:
> Wäre schön, wenn Du die hier einstellen könntest.

Schmunzeln muß, eigentlich war das ja ein "Lochrasterprojekt" für eben 
einfachstes DIY.

bingo schrieb:
> Für alle, welche die Platine lieber selber ätzen wollen, gibt es hier
> jetzt ein PDF

Dienstlich arbeite ich mit einem anderen Routingprogramm als für private 
Spielereien, hier reicht mir das Sprint-Layout.

Ich werde morgen mal die Gerber-Files hier einstellen und ich schau mal, 
wie gut die Export-Funktion zu einem Bitmap oder JPG wird (zwecks 
Skalierung). Ich stell es dann rein.

von bingo (Gast)


Angehängte Dateien:

Lesenswert?

Habe das Layout nochmals gerinfügig verbesert

von bingo (Gast)


Lesenswert?

Ralph S. schrieb:
> Schmunzeln muß, eigentlich war das ja ein "Lochrasterprojekt" für eben
> einfachstes DIY.

Manche Leute machen gerne Lochraster, manche nicht (ich z.B.)

von Tim  . (cpldcpu)


Lesenswert?

Super projekt!

Man könnte das ja eigentlich auch prima für einen Arduino Nano 
schrumpfen, oder?

Zur Schaltung: Ich würde noch pull-down Widerstände an den PWM-Ausgängen 
hinzufügen, um zu verhindern dass Spikes and VDD und VPP entstehen 
können, wenn man den Arduino resettet.

Ob man mit dem Arduino auch eine UART-Verbindung zum Debuggen herstellen 
könnte? Ist natürlich Blöd, dass der ATMEGA328 nur einen UART hat. Man 
könnte eine Richtung als Soft-UART auslegen.

Ich finde die Beschränkung auf die Flash-Varianten vernünftig. Die 
OTP-Devices bieten außer dem Preis wenig Vorteile. Warum der PFS173 
nicht funktioniert, kann ich auch nicht sagen. Allerdings ist er sehr 
empfindliche gegenüber den eingestellten Spannungen. Kannst Du denn 
wenigstens die ID auslesen? Evtl. ist das Timing auch ein Problem, da 
der Tiefpass am Eingang der Opamps die Spannungsrampen deutliche 
langsamer macht, als es beim EasyPDKProg der Fall ist.

: Bearbeitet durch User
von Ralph S. (jjflash)


Angehängte Dateien:

Lesenswert?

wie gestern angekündigt: die Gerberfiles im Anhang und ein 
hochauflösendes (600 dpi) Bild des Layouts ( ;-) für die, die das selbst 
ätzen möchten).

bingo schrieb:
> Manche Leute machen gerne Lochraster, manche nicht (ich z.B.)

sehr grinsen muß: ich mag auch keine Lochrasterkarten mehr, aber 
manchmal ist das schneller als ....  Leider ist meine Ätzkuvette den Weg 
allen irdischen gegangen ! (was nicht sooooo dramatisch ist, weil ich 
sowieso nur noch höchst selten selbst geätzt habe, ich glaube das letzte 
mal vor 2 Jahren).

Tim  . schrieb:
>
> Man könnte das ja eigentlich auch prima für einen Arduino Nano
> schrumpfen, oder?

Hmmm, könnte vllt. funktionieren, wenn man dann SMD-Bauteile verwendet. 
Das war so nicht mein Anliegen.

Tim  . schrieb:
> Zur Schaltung: Ich würde noch pull-down Widerstände an den PWM-Ausgängen
> hinzufügen, um zu verhindern dass Spikes and VDD und VPP entstehen
> können, wenn man den Arduino resettet.

Das hatte ich ursprünglich gemacht gehabt, aaaaber dann war die erzeugte 
Ausgangsspannung nicht mehr stabil genug. Das passive Tiefpassfilter 
verhindert relativ gut Spikes und nach dem Reset wurde eine delay 
eingefügt. Die vorhandenen Spikes (die nicht mehr so richtig groß sind) 
hat ein PFS154 500 Flashvorgänge überlebt.

Tim  . schrieb:
> Ob man mit dem Arduino auch eine UART-Verbindung zum Debuggen herstellen
> könnte? Ist natürlich Blöd, dass der ATMEGA328 nur einen UART hat. Man
> könnte eine Richtung als Soft-UART auslegen.

;-) das Hostprogramm mag ich dann aber nicht schreiben !!!!

Tim  . schrieb:
> Allerdings ist er sehr
> empfindlichen gegenüber den eingestellten Spannungen. Kannst Du denn
> wenigstens die ID auslesen?

Die ID kann ich leider nicht auslesen, ich glaube wenn das ID - lesen 
klappt wird auch der Rest klappen.

Tim  . schrieb:
> Evtl. ist das Timing auch ein Problem, da
> der Tiefpass am Eingang der Opamps die Spannungsrampen deutliche
> langsamer macht, als es beim EasyPDKProg der Fall ist.

An das hatte ich auch schon gedacht gehabt, ABER: ich bin hergegangen 
und habe 2 stabile Festspannungen aufgebaut (gespeist von einem 
Labornetzteil) und deren Ausgangsspannungen an V_dd und V_pp geschaltet 
so dass die beiden Spannungen sehr schnell anliegen. Vorerst war das 
nicht das Problem.

von Ralph S. (jjflash)


Angehängte Dateien:

Lesenswert?

peinlich, peinlich: Im Schaltplan des Eröffnungsthreads hat sich ein 
Fehler eingeschlichen  (im Schaltplan, nicht im Layout):

Ich habe schlicht den Pegel-Spannungsteiler vom Arduino zum Padauk 
Controller unterschlagen (Spannungsteiler 220 : 330 Ohm).

Sorry

von Joachim B. (jar)


Lesenswert?

ich versuche mich mal das auf eagle umzusetzen (Merker)

von Ralph S. (jjflash)


Lesenswert?

Joachim B. schrieb:
> ich versuche mich mal das auf eagle umzusetzen (Merker)

Das sollte ja an sich kein Problem sein, die Schaltung hat ja wenige 
Bauteile und ist auch nicht sonderlich verzwickt. ;-) meine eigene 
Challenge war, das eben Lochrasterkompatibel zu sein.

Die oben angefügten Gerberfiles kannst du ja im Eagle importieren und 
dann nach gutdünken schalten und walten.

Im Moment habe ich drei Dinge:

1.:) Um CPLDCPU absichtlich falsch zu verstehen, habe ich das ganze 
jetzt für einen Arduino NANO geroutet, aber sicherlich nicht so wie er 
denkt.

Tim  . schrieb:
> Man könnte das ja eigentlich auch prima für einen Arduino Nano
> schrumpfen, oder?

Schrumpfen könnte man schon, aber ich bin noch "verrückter" geworden und 
mache das für Lochstreifenplatine auf die ein Nano gesteckt werden kann 
( ;-) und somit wird es dann eher größer, aber ich muß auf der Lötseite 
keine Silberdrähte verlöten). Leider kam mir erst später die Idee wie 
ich das mit einem Routingprogramm einfacher hätte machen können, und so 
habe ich das wie gaaaaaaanz früher erst auf Papier gemacht und dann für 
eine Bildschirmdarstellung aufgehübscht.

2.:) Da ich ja schon seit Jahren an einem Setup bastle, um damit die 
gängigsten Controller bearbeiten zu können (und dabei immer schön billig 
bleiben) hab ich hier auch mal ein "Flashershield"  veröffentlicht 
gehabt

Beitrag "Arduino - UNO Flashershield (Linux)"

welches 3 verschiedene Derivate von MCS-51 programmieren kann, natürlich 
die AVR Serie mit ISP und ein paar wenige (alte) PIC16F Controller.

Wenn man sich anschaut, was zum Programmieren eines PIC Controlle 
benötigt wird, ist es genau dasselbe was zum Flashen eines PFS154 
gebraucht wird: 2 unterschiedliche Spannungen und 2 Datenleitungen. Also 
werde ich versuchen, mir ein neues Flashershield zu generieren, das 
zusätzlich eben noch den PFS154 auf einem Shield kann.

3.:) Ich "hirne" immer wieder mal, warum meine Schaltung partout keinen 
PFS173 erkennen, geschweige denn programmieren kann. Aber immer wenn ich 
eine Idee habe wird das ausprobiert.

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

So, jetzt mache ich mein Lochstreifenlayout fertig !

von bingo (Gast)


Lesenswert?

kennst Du das hier Beitrag ""Universalprogrammer" für Linux" 
vielleicht könntet ihr euch zusammentun

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


Angehängte Dateien:

Lesenswert?

bingo schrieb:
> kennst Du das hier Beitrag ""Universalprogrammer" für Linux"
> vielleicht könntet ihr euch zusammentun

Den Universalprogrammer von Jörg kenne ich sehr wohl und den Aufwand den
er dort getrieben hat ist immens. Ich wollte seinen Code schon einmal
auf SMT32 portieren (damals hatte er auch die Erlaubnis dazu gegeben)um
damit STM8 flashen zu können, aber das stellte sich als zu viel Aufwand
heraus, da Jörg große Teile in Assembler programmiert hat (ich denke
ohne Assembler hätte er das Timing für manche Bausteine nicht einhalten
können).

Von daher habe ich das gelassen, weil ich für alle von mir genutzten
Chips Programmer habe und sowieso sehr gerne mit Bootloadern arbeite die
dann einen Programmer nicht zwingend erfordern. So hatte ich damals
einen Bootloader für STM8S103 geschrieben und somit hatte es sich für
mich erledigt gehabt.

Mein Flashershield und der PFS154 Programmer hier soll einfach nur ein
sehr einfacher Zusatz für diejenigen sein, die einen Arduino herumliegen
haben und mittels diesem eben sehr einfach einige Chips flashen können.
Es sollte auch sehr einfach aufzubauen sein, OHNE dass es zwingend eine
gedruckte Platine benötigt.

Ich hätte absolut kein Problem damit, würde Jörg den PFS-Programmer in
seinen integrieren wollen, aber ich denke sehr, dass das auf seiner
Universalprogrammer-Hardware nicht funktionieren wird:

Er erzeugt die Programmierspannung mittels PWM die einen FET-Transistor
schaltet und an einer Spule dadurch einen Step-Up Wandler realisiert.
Dieses war auch mein erster Ansatz, aber es hatte sich gezeigt, dass die
so generierte Spannung zu Empfindlich für das Flashen eines PFS ist.
Hier müßte so viel Aufwand zur Säuberung betrieben werden, dass es
einfacher ist, einfach einen Schaltregler zu verwenden. Außerdem kann
Jörgs Programmer nur eine Programmierspannung stellen, der
PFS-Programmer braucht aber deren 2 einstellbare Spannungen um stabil zu
laufen.

;-) und um meiner eigenen Zielvorgabe einer einfach aufzubauenden
Schaltung etwas hinzuzufügen habe ich jetzt ein Layout (mit viel
Hirnschmalz) gemacht, das aus einem Arduino-Nano und einer
Lochstreifenplatine (ja, richtig gelesen: Lochstreifenplatine) den
Programmer realisiert.

Ich habe das jetzt zig mal überprüft und das Layout sogar in mein
Layoutprogramm eingegeben um zumindest die richtige Verdrahtung
überprüfen zu können. Eine "normale" Platine zu routen ist deutlich
einfacher.

Nach dem ich mir jetzt zu 99% sicher bin, dass ich keinen
Verdrahtungsfehler mehr habe, werde ich das auch aufbauen, ;-) einfach
weil ich denke dass das keiner für mich macht.

Ein Grund warum das evtl. nicht funktioniert (ich hoffe aber sehr, DASS
es funktioniert) ist, dass die Art der Verdrahtung (eben
Lochstreifenplatine) doch etwas suboptimal ist: Masseführung ist alles
andere als ideal und manche Leitungen haben doch eine relativ große
Länge.

Ich werde sehen, ob das klappt. Das Layout habe ich angehängt.
Wer das aufbauen mag: Die roten Kreuze sind die
Leiterbahnunterbrechungen auf der Lötseite. Grundsätzlich sollte man vor
dem Bestücken die Unterbrechungen vornehmen. Ich verwende hierfür einen
4,5mm HSS Bohrer (ohne Bohrmaschine natürlich) und drehe diesen im
Lötauge mit LEICHTEM Druck um so die Kuperschicht zu trennen.

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

ich habe für den nano mal ein eagle erstellt mit 1,6mm Bohrungen, dort 
können Präzisionsfassungen (EinzelPins ausgelöst) versenkt werden für 
den Nano

gebaut habe ich damit schon mal meine Wordclock12h

: Bearbeitet durch User
von chris_ (Gast)


Lesenswert?

Das Projekt finde ich extrem interessant.

Könnt ihr vielleicht noch ein paar weitere Informationen liefern?

1. Wo bekommt man die Padauk MCUs am besten?
2. Wo findet sich die Entwicklungssoftware?
3. Kann man sie auf Linux installieren?
4. Eine Sammlung einfacher Programmierbeispiele wäre nicht schlecht.

von Tim  . (cpldcpu)


Lesenswert?

chris_ schrieb:
> Das Projekt finde ich extrem interessant.
>
> Könnt ihr vielleicht noch ein paar weitere Informationen liefern?
>
> 1. Wo bekommt man die Padauk MCUs am besten?
> 2. Wo findet sich die Entwicklungssoftware?
> 3. Kann man sie auf Linux installieren?
> 4. Eine Sammlung einfacher Programmierbeispiele wäre nicht schlecht.

Hier wäre ein guter Startpunkt für die Open Source Toolchain:
https://free-pdk.github.io/

Hier kann man die controller kaufen:
https://lcsc.com/products/PADAUK_11011.html

Im interessantesten sind die Flash-Varianten PFS154 und PFS173

Hier gibt es auch noch einen längeren thread:
Beitrag "Padauk MCU für 0.038 USD aus Taiwan"

von Tim  . (cpldcpu)


Lesenswert?

Ralph S. schrieb:
> 1.:) Um CPLDCPU absichtlich falsch zu verstehen, habe ich das ganze
> jetzt für einen Arduino NANO geroutet, aber sicherlich nicht so wie er
> denkt.

Ne, die Variante hatte ich durchaus auch im Kopf :) Allerdings mit SMD 
Bauteilen. Vielleicht werde ich einfach mal den lite-programmer umbauen.

von Ralph S. (jjflash)


Lesenswert?

Tim  . schrieb:
> Ne, die Variante hatte ich durchaus auch im Kopf :) Allerdings mit SMD
> Bauteilen. Vielleicht werde ich einfach mal den lite-programmer umbauen.

sollte ich es hinbekommen, irgendwann den 173er bedienen zu können, dann 
wäre das für micht ein wirklicher Ersatz für den lite-programmer, denn 
dann könnte ich dafür wirklich eine Mega88 verwenden und das ganze dann 
ohne Arduino Fertigteil routen. Hätte den Vorteil, dass man das wieder 
klein bekommt. Meinen eigenen Lite-Programmer habe ich auch geroutet, 
so, dass der noch handbestückbar ist und, irgendwie witzig: Beim 
originalen ist mir (wie beim originalen Arduino) der USB-B Anschluß zu 
klobig, bei deinem ist mir USB-micro zu klein (ich hab hier schon einige 
Gerätedefekte mit Micro an der Buchse gehabt, inklusive meines letzten 
Handys). Die Gerätschaften die ich hier habe sind absichtlich auf 
USB-mini ausgewählt und so hat mein Lite-Programmer einen Mini-Anschluß.

Heute werde ich mich ein bischen "frusten" und an 2 Dingen spielen:

1:) - 173 Programmieralgorithmus

2:) - Evaluierung von CH552 / CH554. Die haben 2 PWM-Kanäle (allerdings 
beide nur 8-Bit) und USB on Board. Ich werde mich da also beschäftigen, 
ob 8-Bit PWM für V_pp ausreichend ist und ich werde schauen, ob ich das 
USB davon in den Griff bekomme. Wenn dem so wäre, könnte man den 
Padauk-Programmer mit diesem Chip flashen (der dann auf LCSC für ca. 30 
Cent erhältlich ist). ;-) damit wäre dann auch der Programmer passend 
zum Mikrocontroller selbst "ultra low cost").

chris_ schrieb:
> 1. Wo bekommt man die Padauk MCUs am besten?
> 2. Wo findet sich die Entwicklungssoftware?
> 3. Kann man sie auf Linux installieren?
> 4. Eine Sammlung einfacher Programmierbeispiele wäre nicht schlecht.

Tim hatte ja schon geantwortet gehabt. Beispiele findest du auch im 
Zip-Archiv des Anhangs im Eingangsthread.

Außerdem bin ich ja immer auch noch am werkeln an einem Framework für 
den Padauk, hier habe ich (auf meinem Rechner) ein Setup, dass (wie bei 
vielen anderen auch) den SDCC Compiler verwendet. Hier habe ich den SDCC 
aller seiner Möglichkeiten beraubt, andere Controller als den PFS zu 
bedienen (damit unnötige Files nicht mit herumgeschleppt werden müssen) 
und habe sämtliche an der Toolchain beteiligten Programm relativ zu 
meinem "Framework" gehalten. Das hat den Vorteil, dass man einfach den 
kompletten Ordner irgendwohin kopieren kann und das funktioniert dann 
gleich.

Wenn du magst, kann ich das mal auf meinen Server stellen und du kannst 
zumindest die Toolchain ausprobierern ... und wenn sie dir nicht gefällt 
kannst du es einfach wieder löschen.

Das Framework arbeitet mit Makefiles !

Vielleicht wäre es auch einmal an der Zeit für mich, über Github 
nachzudenken ...

von bingo (Gast)


Lesenswert?

Ralph S. schrieb:
> Dieses war auch mein erster Ansatz, aber es hatte sich gezeigt, dass die
> so generierte Spannung zu Empfindlich für das Flashen eines PFS ist.

Ich findie die Idee mit den OPAmps zur Spannungserzeugung genial!

von Ralph S. (jjflash)


Lesenswert?

bingo schrieb:
> Ich findie die Idee mit den OPAmps zur Spannungserzeugung genial!

... die wird eigentlich sehr häufig angewendet. Schon zu meiner Lehrzeit 
wurden OP's  als Spannungsregler eingesetzt. In aller Regel gabs eine 
Referenzdiode, im Rückkopplungszweig umschaltbare Trimmer für 
umschaltbare Ausgangsspannung.

D.h. die geniale Idee ist nicht von mir, der Entwickler vom 
Easy-PDK-Programmer hat das auch so gemacht und ohne ihn wäre ich nicht 
auf die Idee gekommen, das mit einem derart alten und billigen OP zu 
machen. Ich hätte einen TL082 genommen und hätte diesem eine negative 
Hilfsspannung erzeugen müssen. Der LM358 (wie er auch gerne in IHK 
Abschlußprüfungen Teil 1 verwendet wird) hat den Vorteil, dass er 
Eingangsspannungen ab 30 mV bei unipolarer Versorgung korrekt arbeitet. 
Er hat den Nachteil, dass er am Ausgang viel Spannung "schluckt": bei 5V 
Versorgung bspw. kann er am Ausgang nicht mehr als 3,5 V stellen.

von W.S. (Gast)


Lesenswert?

Ralph S. schrieb:
> Vielleicht wäre es auch einmal an der Zeit für mich, über Github
> nachzudenken ...

Lieber nicht. Schreibe lieber eine gute Dokumentation über deine 
Entwicklungen, da haben andere Leute viel mehr davon als von einem 
Haufen Zeugs auf Github.

Noch etwas: Warum soll es denn bei dem Brenner immerzu nur so 
minimalistisch zugehen, daß du dir Gedanken machst, ob du mit 8 Bit PWM 
auskommst oder nicht? Ist das ein Sport? Ich hatte vor Jahren mir meinen 
eigenen PIC-Programmer gemacht und dafür einen 'allgegenwärtigen' 
STM32F103C8T6 benutzt sowie Schaltregler und Schalter für VCC und VPP 
separat davon. Das hat den Vorteil, daß man die Spannungen in aller Ruhe 
einstellen kann und für PWM dabei auch besser tiefpaßfiltern kann. Im 
Grunde kostet das nur wenige Bauteile, entspannt jedoch die Abläufe 
für's Programmieren spürbar. Ich bin auch sehr dafür, eben nicht einen 
OpV-Ausgang für die Spannungsausgabe an den µC zu verwenden, denn diese 
sollte weingstens ein wenig per Kondensator gepuffert werden. Grund: man 
muß damit rechnen, daß durch die chipinternen Programmierabläufe 
Stromspitzen auftreten, die weggefiltert werden müssen, um die jeweilige 
Spannung konstant zu halten. Ein OpV kann so etwas nur sehr bedingt, 
weil er zumeist viel langsamer ist als die wechselnde Last an seinem 
Ausgang. Sowas kann eventuell das ganze Programmieren durcheinander 
bringen.

W.S.

von Ralph S. (jjflash)


Lesenswert?

chris_ schrieb:
> 2. Wo findet sich die Entwicklungssoftware?
> 3. Kann man sie auf Linux installieren?
> 4. Eine Sammlung einfacher Programmierbeispiele wäre nicht schlecht.

so, ich habe jetzt mal einen Teil doch auf ein github gestellt:

https://github.com/jjflash65/pfs154

Du kannst dir das Repository in ein Verzeichnis deiner Wahl clonen (ist 
aber ausschließlich für ein 64-Bit Linux).

Das System ist komplett mit relativen Pfaden eingerichtet, auch der 
SDCC. An diesem habe ich alles entfernt was nicht zum Programmieren von 
Padauk benötigt wird. Philipp wird mich hoffentlich aufklären, ob so 
etwas zulässig ist oder nicht und ob das Gesamtpaket immer in Gänze 
vorhanden sein muß. Die Lizenzbestimmungen sind natürlich enthalten.

Wechselst du in eines der Beispielverzeichnisse, sollte ein Aufruf von 
"make" schon das Programm übersetzen.

Ein "make flash" führt einen Upload zum Controller durch (so du einen 
Programmer angeschlossen hast).

An einer (TUI)-IDE bin ich noch am werkeln, für ein eigenes Projekt 
einfach ein neues Verzeichnis anlegen und sich am besten ein Makefile 
aus einem der anderen Verzeichnisse kopieren und anpassen.

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

W.S. schrieb:
> Ralph S. schrieb:
>> Vielleicht wäre es auch einmal an der Zeit für mich, über Github
>> nachzudenken ...
>
> Lieber nicht.

ich habe es soeben doch getan !

W.S. schrieb:
> Ist das ein Sport?

Für mich ist das tatsächlich ein Sport, mit so wenig wie möglich 
auszukommen.

W.S. schrieb:
> Warum soll es denn bei dem Brenner immerzu nur so
> minimalistisch zugehen

Weil einige nicht viel Geld ausgeben wollen für etwas, von dem sie nicht 
wissen ob dieses etwas für sie taugt. Bei so kleinstem Geldeinsatz 
probiert man das eben eher mal etwas aus.

Auch wenn dir der Satz nicht gefällt: keep it easy, keep it cheap!

W.S. schrieb:
> Ich bin auch sehr dafür, eben nicht einen
> OpV-Ausgang für die Spannungsausgabe an den µC zu verwenden

Ich bin an sich auch nicht soooooo dafür (aus einigen Gründen, ein paar 
hast du genannt), aber:

Um zu sehen wie "standfest" das Teil ist hab ich insgesamt 1000 
Flashvorgänge (mit 92% "Füllung" des Flashspeichers) durchgeführt um zum 
einen zu sehen, wie oft ein Fehler auftaucht und zum anderen, ob der 
Controller das mitmacht.

Gestartet hatte ich das gestern abend und zu meinem erstaunen heute 
morgen gab es keinen einzigen Fehler und der Controller ist immer noch 
programmierbar.

Von daher:

W.S. schrieb:
> Sowas kann eventuell das ganze Programmieren durcheinander
> bringen.

Haben sich deine Befürchtungen nicht bestätigt.

von chris_ (Gast)


Lesenswert?

Ralph S. (jjflash)
>chris_ schrieb:
>> 2. Wo findet sich die Entwicklungssoftware?
>> 3. Kann man sie auf Linux installieren?
>> 4. Eine Sammlung einfacher Programmierbeispiele wäre nicht schlecht.

>so, ich habe jetzt mal einen Teil doch auf ein github gestellt:

>https://github.com/jjflash65/pfs154

Dankeschön.
Würde der
PADAUK Tech PFS154-S16
damit gehen?

Was mir bei der Programmierplatine auffallt: Gibt es irgendwo einen 
passenden SOP16-Programmieradapter?

von Ralph S. (jjflash)


Lesenswert?

chris_ schrieb:
> Würde der
> PADAUK Tech PFS154-S16
> damit gehen?

... das ist genau der, für den mein Programmer gemacht ist (der 
Easy-Programmer kann noch mehr).

Ich habe das ausprobiert mit 8,14 und den 16 pol. Varianten, gehen alle.

Ich gehe mal davon aus, dass du keine Controller zu Hause hast (und wie 
andere und ich auch, das erst einmal mittels langer Wartezeit von 
LCSC.COM bestellst): wenn du magst, kann ich dir 3 Stück in ein Kuvert 
stecken und dir das schicken. Allerdings habe ich eine GMX-Mailadresse 
und ich weiß nicht, ob eine PN dann bei mir ankommt ?!?

Ich habe die zum Experimentieren bisher auf Adapter gelötet (das ist 
dann auch das Rastermaß des Programmers, "Mini-Lite-Programmer und mein 
Programmer) und ist dann auch steckbrettkonform.

Ebay-Artikel Nr. 173990566789

Ansonsten (bisher einmal gemacht für eine Spielerei mit dem PFS) habe 
den Chip mit einem solchigen Adapter geflasht, da sind dann halt während 
des Flashvorgangs 4 Pins außerhalb des Programmersockets:

Ebay-Artikel Nr. 373373709254

Hast du das Setup von meinem Githup-Repository tatsächlich ausprobiert? 
Es würde mich (brennend) interessieren, ob du damit fehlerfrei 
compilieren konntest.

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

Ergebnis für heute:

Ich konnte doch tatsächlich die ID des PFS173 lesen. Ich hatte einen 
Fehler gesucht, wo keiner ist: Meine Versuche ergaben eine ID von 0x0EA2 
und in irgendeinem Post auf EEVblog hatte ich gelesen, dass da AA2 
kommen soll. Nach einem Vergleich mit dem "Easy-PDK-Programmer" hab ich 
dann festgestellt, dass dort ebenfalls die ID 0x0EA2 ankommt.

Vllt. bekomme ich es ja doch noch hin, auch einen 173 er zu flashen ?!?

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

Habe es nur einmal grob hingeschoben. Mit SMD Bauteilen würde man auf 
den Footprint des lite-programmers kommen.

Edit: Korrektes PCB angehängt. Bitte das erste Bild ignorieren.

Edit2: Die BOM liegt bei $0.47 pro PCB mit MOQ von 10. Bis auf die Spule 
und die mechanischen Teile könnte man alles bei JLCPCB bestücken lassen.

: Bearbeitet durch User
von Ralph S. (jjflash)


Angehängte Dateien:

Lesenswert?

Zum Eingang erstmal (weil die Menschen Augentiere sind) ein Video vom 
"Ergebnis der Nacht":

https://www.youtube.com/watch?v=gGn-rjJ5ndA

Tim  . schrieb:
> Habe es nur einmal grob hingeschoben. Mit SMD Bauteilen würde man auf
> den Footprint des lite-programmers kommen.

Freu ich mich dass du das gemacht hast, aber prinzipiell frage ich mich 
weshalb (vllt. aus dem gleichen Grund wie bei mir: weil man's kann und 
weil es Spaß macht?). Du hast doch schon den Mini-Lite-Programmer, der 
deutlich besser ist als der Arduino basierende hier. Der Mini-Lite kann 
mehr Bausteine und er kann die Taktfrequenz kalibrieren.

Wie auch immer, freut mich.

Anmerkungen habe ich aber auch:

Du hast die Schaltung geändert, vor allem in Bezug auf den Schaltregler 
(der dann deutlich besser ist als mein oller MC34063 ).

Hier könnte ich von jemanden noch eine Unterstützung gebrauchen, weil 
ich denke dass die Anpassung bei mir Spule zur Frequenz noch Potential 
nach oben hat. Meine Spule ist aus dem Grund 330µH, weil ich nur 1 mH, 
680µH und 470µH hier habe, aber eben rechnerisch in etwa 330µH benötigt 
werden (das ist auch der Grund, warum bei mir 2 Spulen eingesetzt sind: 
sie sind parallel geschaltet).

Du hast Kondensatoren zum Säubern der Spannung von Vdd und Vpp eingefügt 
und ich hoffe du konntest das Testen. Bei mir hat der Programmer 
"gesponnen" als ich dort 220nF hatte. Bei 100nF nicht, aber es hatte 
auch keinen Effekt.

Hm, du hast die Jumper weggelassen (den fürs Kalibrieren kann man 
wirklich entfernen, weil man über die Software noch ein zusätzliches 
Kommando einführen kann, dass eine evtl. Kalibrierung ermöglicht). Den 
zweiten Jumper halte ich aber doch für wichtig (der, der den Reset bei 
Verbindungsaufbau zum Arduino durchführt), weil sonst bei jedem 
Flashvorgang knapp 2 Sekunden gewartet werden muß, bis der Vorgang 
startet (und somit die Option "nowait" beim Programm nicht verfügbar 
ist). Außerdem funktioniert die Option "run" dann auch nicht.

Ich sehe keinen größeren Kondensator über der Betriebsspannung (den, den 
ich am MC34063 angebracht hatte) und weiß nicht, wie gut die Spannung 
ohne diesen dann für den Operationsverstärker wird. Allerdings weißt du 
von deinem Mini-Lite-Programmer (der ja denselben OP bedient) ob das 
funktioniert oder nicht.

Aber ich freu mich, die Platine ist witzig und:

Tim  . schrieb:
> Die BOM liegt bei $0.47 pro PCB mit MOQ von 10.

Die 47 Cent sind ja der Knaller, man darf gar nicht drüber nachdenken, 
wie das hergestellt wird zu dem Preis.

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

In der letzten Zeit habe ich mich NICHT um die Firmware des Programmers 
gekümmert (sollte ich aber tun), weil es sehr schleppend vorangeht und 
ich Erfolgserlebnisse irgendwie haben wollte. Softwareseitig kann ich 
jetzt die ID eines PFS173 lesen und den Chip auch löschen. Schreiben 
kann ich leider noch nicht.

Aber dafür habe ich mich ums Repository gekümmert und einige Sourcen für 
den PFS154 hinzugefügt, gestern Nacht kamen hinzu:

- IR-Empfänger mit HX1838

Dort habe ich dann die (widerspenstigen) Timer2 und Timer3 kennen 
gelernt und so gaaaaaaanz richtig weiß ich nicht, was da 
Boundary-Register dort macht, wenn es doch eigentlich nur für eine PWM 
relevant ist. Vllt. kann mich da jemand aufklären. Dabei habe ich noch 
gelernt, dass externe Interrupts 0 und 1 von der Logik her 
Pinchange-Interrupts für PA0 und PB0 sind.

- 7-Segmentanzeige mit TM1637

Weil man ja was zum Anzeigen der Codes braucht und das auf einem Video 
besser lesbar ist

- Portexpander mit Schieberegister 74HC595 / HEF4094

;-) irgendwas muß man ja mit der Fernbedienung steuern.

Einige Änderungen wurden am Repository vorgenommen und ein (wirklich 
sehr böser Fehler) in "pfs1xx_gpio.h" vorgenommen: Ich hatte nicht 
bemerkt gehabt, dass die Initialisierung für Pins auf PB als Eingang 
nicht funktioniert (und hatte mir einen Wolf in meinem Code gesucht 
warum das nicht funktioniert hat).

Github-Repository ist:

https://github.com/jjflash65/pfs154

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

Für mich aus Interesse (ich bin nicht der Spezialist was IR-Codes von 
Fernbedienungen angeht), vllt. kann mir jemand sagen, wie dieses 
Protokoll im Anhang oben heißt. Es stammt von einer ultra-low-cost 
chinesischen Fernbedienung (wie man sie für 1,50€ inkl. IR-Empfänger und 
Porto kaufen kann).

Inaktiv liefert der IR-Receiver Hi-Pegel. Beim übermitteln eines Datums 
erfolgt 9 ms ein Lo-Pegel, danach für 5 ms ein Hi-Pegel (welches ich für 
mich als Startbit bezeichne), danach kommen 32 Bits die folgenderweise 
codiert sind:

- Pausedauer ist immer 0,6ms
- Pulsdauer für logische 0 ebenfalls 0,6ms
- Pulsdauer für logische 1 sind 1,7ms

Vllt. weiß das ja Frank M. (ukw) aus dem Handgelenk heraus ?

Gruß zum WE,

JJ

von W.S. (Gast)


Angehängte Dateien:

Lesenswert?

Ralph S. schrieb:
> W.S. schrieb:
>> Warum soll es denn bei dem Brenner immerzu nur so
>> minimalistisch zugehen
>
> Weil einige nicht viel Geld ausgeben wollen für etwas, von dem sie nicht
> wissen ob dieses etwas für sie taugt. Bei so kleinstem Geldeinsatz
> probiert man das eben eher mal etwas aus.
>
> Auch wenn dir der Satz nicht gefällt: keep it easy, keep it cheap!

Nö, deinen Denkansatz vermag ich nicht nachzuvollziehen, ich sehe das 
ganz anders: Wer kein Geld ausgeben will für einen Padauk-Programmer, 
der hat mit hoher Sicherheit irgend ein µC-Eval-Board irgend eines 
Herstellers oder ein passendes Arduino-Zeugs herumlungern. So etwas 
zusammen mit etwas Analogschaltung (ggf. auf Lochraster) wäre die 
allerbilligste und auch schnellste Lösung.

Aber das hat einen Haken: All das, was in den jeweiligen µC als Firmware 
hineinkommen soll, MUSS portabel sein - und zwar leicht portabel.

Bei all dem, was ich bislang gesehen habe, ist das nicht der Fall. Das 
hat alles danach ausgesehen, daß man Programmer in Serie produzieren und 
verkaufen will und deshalb den HW-Aufwand niedrig und die Dokumentation 
gering halten will.

Für das Nachvollziehen bei anderen Bastlern braucht es aber 
Dokumentation. Sonst passiert es Anderen ähnlich wie dir mit der 
falschen ID für den Chip.

Als Minimum sollte wenigstens eine Art Diskussionsgrundlage vorhanden 
sein. Ich kenne sowas von den DIN-Normungsgremien: Dort wird ein 
Basisdokument aufgesetzt, dann an alle Teilnehmer verteilt und diese 
tragen dann ihre Bedenken, Änderungen etc. dort ein, was dann diskutiert 
wird, dann ein neues Dokument mit den bis dato akzeptierten Änderungen 
verteilt und so weiter, bis die Sache fertig und beschlußfähig ist.

Auch dann, wenn man sein Projekt nicht so hoch hängen will, ist es immer 
gut, Eckdaten wie z.B. die Algorithmen und die Protokolle für sich 
selber festzuschreiben, man will sich ja auch in 3 Jahren noch dran 
erinnern können. Das ist allemal besser, als drauflos zu programmieren.

Wie so etwas aussehen kann, wenn man es eigentlich nur für sich selbst 
mal niederschreibt, kannst du in dem angehängten PDF nachlesen. Als 
Beispiel. Das ist NICHT für die Padauk, sondern eigentlich nur für die 
kleinen PIC16, die ich noch immer für einige kleinere Projekte einsetze. 
Allerdings habe ich bei dem Brenner eine Arbeitsteilung vorgesehen: Die 
Algorithmen macht der PC, die niederen Verrichtungen macht der µC. Diese 
sind leicht in fast jedem µC implementierbar und für Änderungen und 
Erweiterungen der Algorithmen bedarf es eben keiner Änderung an der 
Firmware des µC. Ich sehe so eine Aufteilung als Optimum an - wenn man 
nicht Kommerzielles im Sinn hat.

W.S.

von Tim  . (cpldcpu)


Lesenswert?

Ralph S. schrieb:
> Freu ich mich dass du das gemacht hast, aber prinzipiell frage ich mich
> weshalb (vllt. aus dem gleichen Grund wie bei mir: weil man's kann und
> weil es Spaß macht?). Du hast doch schon den Mini-Lite-Programmer, der
> deutlich besser ist als der Arduino basierende hier. Der Mini-Lite kann
> mehr Bausteine und er kann die Taktfrequenz kalibrieren.

Aktuell ist der STM32F072 bei LCSC nicht zu bekommen., so dass niemand 
den EasyPDKProg nachbauen kann. Die Idee mit der Arduino-Variante fand 
ich schon immer gut, weil man dann mit Bauteilen auskommt, die bei 
JLCPCB im Basic-sortiment zu bekommen sind. (https://jlcpcb.com/parts). 
Ich wollte mich aber nie an die Software setzen, da es ja schon einen 
guten Programmer gibt. Jetzt hast Du es halt gemacht :)

In dem PCB oben stecken ca. 15 Minuten arbeit. Ich habe nämlich einfach 
beim lite-programmer die Teile weggelassen, die der Arduino-Programmer 
nicht braucht. Daher auch der andere Boost-Converter. Das PCB ist noch 
nicht geroutet.

Der MT3608 funktioniert gut und hat vor allem auch eine 
Frequenzregelung, die die switcher-Frequenz bei Laständerungen nicht zu 
stark abfallen lässt. Dadurch gibt es keine "singenden" Induktivitäten, 
wie bei einigen anderen Boostern. Der MC34063 ist natürlich schon etwas 
älter und arbeitet bei deutlichen niedrigen Frequenzen, daher sind auch 
die große Induktivität und die großen Kondensatoren notwendig.

> Du hast Kondensatoren zum Säubern der Spannung von Vdd und Vpp eingefügt
> und ich hoffe du konntest das Testen. Bei mir hat der Programmer
> "gesponnen" als ich dort 220nF hatte. Bei 100nF nicht, aber es hatte
> auch keinen Effekt.

Das ist die Beschaltung aus dem EasyPDKprog.

> Hm, du hast die Jumper weggelassen (den fürs Kalibrieren kann man

Was macht denn der Jumper? :) Ich habe ihn nicht weggelassen, sondern 
bisher nicht hinzugefügt.

> Ich sehe keinen größeren Kondensator über der Betriebsspannung (den, den
> ich am MC34063 angebracht hatte) und weiß nicht, wie gut die Spannung
> ohne diesen dann für den Operationsverstärker wird. Allerdings weißt du
> von deinem Mini-Lite-Programmer (der ja denselben OP bedient) ob das
> funktioniert oder nicht.

Der OPamp hat bei den switcher-Frequenzen ja auch noch einiges an Gain- 
Reserve und hilft die Versorungsspannung zu glätten. Ein Problem wird 
eher sein, dass der PWM-Ripple von der MCU auch sehr gut verstärkt wird.

Im Design-Log vom lite-programmer sind einige Messungen zur Stabilität 
des Supplies:
https://github.com/free-pdk/easy-pdk-programmer-lite-hardware/blob/master/Design_log.pdf

>Die 47 Cent sind ja der Knaller, man darf gar nicht drüber nachdenken,
>wie das hergestellt wird zu dem Preis.

Das PCB ist noch nicht dabei. Die Bauteilpreise bei LCSC sind halt die, 
die man bekommt wenn der Disti nicht 400% Marge draufrechnet. Bin 
gespannt, ob die das lange durchalten. Irgendwann müssen die auch mal 
Lagerbestände abschreiben...

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ralph S. schrieb:
> Inaktiv liefert der IR-Receiver Hi-Pegel. Beim übermitteln eines Datums
> erfolgt 9 ms ein Lo-Pegel, danach für 5 ms ein Hi-Pegel (welches ich für
> mich als Startbit bezeichne), danach kommen 32 Bits die folgenderweise
> codiert sind:
>
> - Pausedauer ist immer 0,6ms
> - Pulsdauer für logische 0 ebenfalls 0,6ms
> - Pulsdauer für logische 1 sind 1,7ms
>
> Vllt. weiß das ja Frank M. (ukw) aus dem Handgelenk heraus ?

Das ist NEC IRMP: NEC.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ralph S. schrieb:
> Inaktiv liefert der IR-Receiver Hi-Pegel. Beim übermitteln eines Datums
> erfolgt 9 ms ein Lo-Pegel, danach für 5 ms ein Hi-Pegel (welches ich für
> mich als Startbit bezeichne), danach kommen 32 Bits die folgenderweise
> codiert sind:
>
> - Pausedauer ist immer 0,6ms
> - Pulsdauer für logische 0 ebenfalls 0,6ms
> - Pulsdauer für logische 1 sind 1,7ms
>
> Vllt. weiß das ja Frank M. (ukw) aus dem Handgelenk heraus ?

Das ist NEC: 
https://www.mikrocontroller.net/articles/IRMP#NEC_.2B_extended_NEC

von Ralph S. (jjflash)


Lesenswert?

Tim  . schrieb:
> Was macht denn der Jumper? :) Ich habe ihn nicht weggelassen, sondern
> bisher nicht hinzugefügt.

Der verbindet (oder auch nicht) den Reset des ATmegas über einen Elko 
mit Vcc. Das hat zur Folge, dass der kurze Reset-Impuls der auf der DTR 
Leitung der seriellen Schnittstelle gesendet wird, wenn die 
Schnittstelle geöffnet wird, den ATmega (so er einen Bootloader hat) 
NICHT genügend lange auf GND schalten kann und der ATmega NICHT resetet 
(und von daher auch NICHT in seinen Bootloader springt... bei jedem 
Flashvorgang).

Frank M. schrieb:
> Das ist NEC:
> https://www.mikrocontroller.net/articles/IRMP#NEC_.2B_extended_NEC

Daaaaanke, dann weiß ich das jetzt auch endlich einmal. Das Protokoll 
ist schon ziemlich alt, oder ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ralph S. schrieb:
> Daaaaanke, dann weiß ich das jetzt auch endlich einmal. Das Protokoll
> ist schon ziemlich alt, oder ?

Nicht so alt wie RC5, aber mittlerweile hat NEC einen geschätzten 
Marktanteil von 95%. Du findest NEC eigentlich überall. Auf diesen 
chinesischen Flachfernbedienungen wie in Deinem Youtube-Video sowieso.

Aber ich habe noch eine Frage zu dem Video:

NEC besteht aus
1
  8 Bit Adresse + 8 Bit neg. Adresse + 8 Bit Kommando + negiertes 8 Bit Kommando

Extended NEC besteht aus
1
  16 Bit Adresse + 8 Bit Kommando + 8 Bit negiertes Kommando

Bei NEC ist der Informationsgehalt des 32-Bit-Frames also 8 + 8 = 16 
Bit, bei Extended NEC 16 + 8 = 24 Bit.

Ich vermute, dass Du die redundanten Informationen erst gar nicht 
rausnimmst, sondern sogar alle 32 Bits auswertest. Wie kannst Du diese 
Information überhaupt auf einer 4-stelligen HEX-Anzeige (max. 16 Bit) 
darstellen?

von Ralph S. (jjflash)


Lesenswert?

Frank M. schrieb:
> Wie kannst Du diese
> Information überhaupt auf einer 4-stelligen HEX-Anzeige (max. 16 Bit)
> darstellen?

Oh jeh, "erwischt": Das allererste mal als ich eine Fernbedienung 
auswerten wollte (mußte) hatte ich dort festgestellt, dass die oberen 
16-Bit identisch mit den unteren 16 Bit waren (das war damals auf einem 
MCS-51 System). Dort hatte ich dann einfach die oberen 16-Bit 
weggeworfen, weil es sowieso "nur" Redundanz war. Als die Controller 
größer wurden habe ich dann wirklich alle 32-Bit belassen und in einem 
späteren Programm einfach nur die Codes auf Gleichheit geprüft, mich 
hatte es nicht interessiert was die Codes bedeuten, mir ging es nur um 
eine eindeutige Zuordnung.

Bei dem jetzigen Code mache ich das genauso:
1
    // die ersten 16 Bit des Pakets einlesen ohne diese
2
    // auszuwerten
3
    for (cx= 0; cx < 16; cx++)
4
    {
5
      b= ir_getbit(48);
6
      if (b == 2) goto timeout_err;
7
      if ( waittil_hi(48) ) goto timeout_err;          // auf naechstes Datenbit warten
8
    }
9
10
    // erste 8 Bit seriell lesen
11
    hw= 0;
12
    for (cx= 0; cx < 8; cx++)
13
    {
14
      b= ir_getbit(48);
15
      if (b == 2) goto timeout_err;
16
      hw |= (b << cx);
17
      if ( waittil_hi(48) ) goto timeout_err;          // auf naechstes Datenbit warten
18
    }
19
    result= (uint16_t) hw << 8;
20
21
    // zweite 8 Bit seriell lesen
22
    hw= 0;
23
    for (cx= 0; cx < 8; cx++)
24
    {
25
      b= ir_getbit(48);
26
      if (b == 2) goto timeout_err;
27
      hw |= (b << cx);
28
      if ( waittil_hi(48) ) goto timeout_err;          // auf naechstes Datenbit warten
29
    }
30
    result |= hw;

Die ersten 16-Bit (eigentlich nur 8 Bit plus deren negierte Pendants) 
werden schlichtweg nicht ausgewertet. Aber: prinzipiell bringst du mich 
jetzt auf die (richtige) Idee, die ersten 8-Bit zu lesen, mit den 
zweiten zu vergleichen (als Fehlerüberprüfung) und mit den 3. und 4. 
8-Bit genauso zu verfahren. Wie gesagt: mir kam es nur darauf an, 
unterscheidbare Codes zu bekommen die in Eigenentwicklungen verwendet 
wurden. Gängig hatte ich hier häufig dann ein Setup-Programm, bei dem 
ich die Elektronik anlernen konnte und die Werte im EEProm gespeichert 
hatte. Wie gesagt: du bist der Experte für IR ... ich war da eher nur 
pragmatisch. Das hat dann bspw. bei meinem Demoprogramm hier den 
Vorteil, dass das Demoprogramm mit dem Schalten der 8-Kanäle, der 
Software für den IR, den 7-Segment Controller und das Schieberegister 
nur 940 Words von 2048 lang ist.

Im übrigen (weil ich weiß dass wieder jemand meckern wird): Das hier ist 
einer der extrem wenigen Fälle, in denen ich ein "goto" verwende um 
einer ewig langen Schachtelung zu entkommen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ralph S. schrieb:
> Die ersten 16-Bit (eigentlich nur 8 Bit plus deren negierte Pendants)
> werden schlichtweg nicht ausgewertet.

Alles klar, du ignorierst also die Adressbits. Damit kannst Du dann 
evtl. nicht mehr unterscheiden, ob das gerade die FB für den TV oder den 
Mediaplayer oder CD-Laufwerk ist. Wenn Du damit zufrieden bist, reicht 
das aus.

Da das 4. Byte lediglich der negierte Wert des 3. Bytes ist, müsste 
aktuell auf Deinem Display jeweils ein Kommando-Byte plus das negierte 
Kommando-Byte ausgegeben werden. Ich könnte jetzt nochmal das Video 
schauen, und die ausgegebenen Hex-Werte dahingehend überprüfen, aber ich 
nehme es an, dass es genau so ist.

Ralph S. schrieb:
> Aber: prinzipiell bringst du mich jetzt auf die (richtige) Idee, die
> ersten 8-Bit zu lesen, mit den zweiten zu vergleichen (als
> Fehlerüberprüfung) und mit den 3. und 4. 8-Bit genauso zu verfahren.

Ja, könntest Du machen. Genau dafür sind die Negierungen da drin. Wenn 
es aber Extended NEC ist, dann ist das 2. Byte nicht das negierte 1. 
Byte. In diesem Fall hättest Du dann 16 + 8 = 24 Bit. Passt leider auch 
nicht aufs Display. Ob Deine China-FB NEC oder Ext. NEC sendet, kannst 
Du leicht überprüfen, indem Du das erste mit dem zweiten negierten Byte 
vergleichst.

: Bearbeitet durch Moderator
von Ralph S. (jjflash)


Lesenswert?

Frank M. schrieb:
> Da das 4. Byte lediglich der negierte Wert des 3. Bytes ist, müsste
> aktuell auf Deinem Display jeweils ein Kommando-Byte plus das negierte
> Kommando-Byte ausgegeben werden. Ich könnte jetzt nochmal das Video
> schauen, und die ausgegebenen Hex-Werte dahingehend überprüfen, aber ich
> nehme es an, dass es genau so ist.

genau so ist es und die Addition zusammen ergibt immer 0xFF !

Frank M. schrieb:
> Alles klar, du ignorierst also die Adressbits. Damit kannst Du dann
> evtl. nicht mehr unterscheiden, ob das gerade die FB für den TV oder den
> Mediaplayer oder CD-Laufwerk ist. Wenn Du damit zufrieden bist, reicht
> das aus.

Beim aller aller ersten mal ging es darum, 4 Pumpen hinter einer 
Glasscheibe ein- und ausschalten zu können.

Ich war immer von deiner IRMP fasziniert und hatte die ein einziges mal 
auf einem STM32F103 laufen. Hier war aber dann IRSND viel interessanter 
und ich hab vor ein paar Jahren damit einen festinstallierten Beamer 
(der noch keine Rechnersteuerung hatte) über den Rechner dennoch 
ferngesteuert gehabt. Die originale Fernbedienung ausgelesen gehabt und 
dann den eben so gesteuert gehabt.

Wenn es größeres sein soll, reicht das hier natürlich nicht ! ;-) um 
einfach nur Kanäle ein- und auszuschalten dann schon.

von Ralph S. (jjflash)


Lesenswert?

Das Github - Repository ist umgezogen nach:

https://github.com/jjflash65/Padauk-pfs154

von Ralph S. (jjflash)


Lesenswert?

Nach einigen Untersuchungen komme ich einfach nicht zum Ziel, einen 
PFS173 auf meiner Hardware zu beschreiben.

Immerhin kann ich jetzt doch tatsächliche alle 15 Bits aus ihm korrekt 
lesen (bisher waren immer nur 14 Bit korrekt). Nie hätte ich geglaubt, 
dass der PFS154 die Logiglevel schneller als der 173er anlegt, ist aber 
so.

Momentan kann ich also ID lesen, den Chip loeschen, den Flash-Speicher 
lesen.

Wenn irgendjemand irgendwo eine Doku zum Timing und Spannungshöhen 
darüber seht, würde mich der Link dazu brennend interessieren ( :-) am 
gestrigen Sonntag hab ich 5 Stück PFS173 gehimmelt: mit zu hohen 
Spannungen, verpolt, Programmfehler etc.)

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

Dafür hab ich jetzt mal wirklich alle Controller der ATmegaxx8 
ausprobiert und schön schön, das Programm läuft von ATmega88 bis 
ATmega328.

Einen kleinen Schrecken hatte ich, wie ich das ganze auf einem 
originalen Arduino-Uno ausprobiere und prompt geht es nicht !

Mein Trick mit dem Kondensator am Reset gegen +Ub geschaltet 
funktioniert an einm originalen Arduino nicht. Ein originaler Arduino 
ist also nur ohne die Option "nowait" betreibbar (und somit ist hier 
dann auch kein Test eines Blinkprogramms im Sockel möglich), aber 
geflasht wird korrekt.

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

Pause machen, dann hierein schauen und dann werde ich mal schauen, ob 
ich den originalen Code von dem Easy-PDK-Programmer zerlegt bekomme. Der 
ist schon irgendwie sehr stark "zerklüftet" (leider).

von Ralph S. (jjflash)


Lesenswert?

Frank M. schrieb:
> Ja, könntest Du machen. Genau dafür sind die Negierungen da drin. Wenn
> es aber Extended NEC ist, dann ist das 2. Byte nicht das negierte 1.
> Byte. In diesem Fall hättest Du dann 16 + 8 = 24 Bit. Passt leider auch
> nicht aufs Display. Ob Deine China-FB NEC oder Ext. NEC sendet, kannst
> Du leicht überprüfen, indem Du das erste mit dem zweiten negierten Byte
> vergleichst.

;.) als für NEC-"Normal" hab ich das jetzt wie Frank's Angaben gemacht 
(und ist jetzt auch im Repository so vorhanden).. irgendwie sehen die 
Codes jetzt auch aufgeräumter  aus (richtig halt). Mal gucken, wo ich 
eine "NEC - extended" Fernbedienung her bekomme, das Protokoll ist ja 
auch relativ einfach, dann kann ich das ja auch noch machen. ;-) oder 
Frank macht eine "abgespeckte" Version von IRMP für den Padauk (wenn 
dann mal die Platinen da sind).

von W.S. (Gast)


Lesenswert?

Ralph S. schrieb:
> ob
> ich den originalen Code von dem Easy-PDK-Programmer zerlegt bekomme. Der
> ist schon irgendwie sehr stark "zerklüftet" (leider).

Tja, jetzt bist du auch an dieser Stelle angekommen.
Willkommen im Club.

W.S.

von Ralph S. (jjflash)


Lesenswert?

W.S. schrieb:
> Tja, jetzt bist du auch an dieser Stelle angekommen.
> Willkommen im Club.
>
> W.S.

... da gibt es einen Unterschied zwischen dir und mir: Ich bin sehr froh 
dass es die Software gibt, denn sie funktioniert absolut Spitze und für 
diejenigen die einen Programmer benötigen ist die "Optik" der Firmware 
Wurst.

Jeder hat seinen eigenen Stil und derjenige der den 
"Easy-PDK-Programmer" gemacht hat, muß Ewigkeiten geforscht, 
experimentiert, Unmengen an
Chips verheizt und sein Hirn verrenkt haben damit das funktioniert.

Dafür zolle ich dem Hochachtung, auch wenn ich seinen Programmaufbau 
nicht einfach (sondern nur schwierig) nachvollziehen kann. ER ... hat es 
hinbekommmen... und zwar als einziger, es gibt noch keinen anderen 
Programmer der funktionabel ist als dieser. Sogar funktionabler als der 
originale von Padauk, weil der Originale nur den eigenen Code und keine 
Intel-Hex-Dateien versteht.
---------------------------------
Ich hätte gewettet, dass du hier wieder aufschlagen wirst ob des 
"zerklüfteten" Quellcodes und hatte mir schon in den Hintern gebissen 
gehabt wie ich auf "veröffentlichen" geklickt habe.

Von daher tut es mir leid, dass ich den obigen Beitrag geschrieben 
habe..

JJ

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

Ich habe noch einmal den Padauk-Writer herausgekramt und einen 
Programmiervorgang auf einem PFS173 mitegeschnitten.

Das Ergebnis ist anbei als .csv und Rigol MSO5000 .bin file. Leider 
hängt sich Pulseview beim öffnen der .csv Datei auf und die .bin Datei 
konnte ich bisher nicht fehlerfrei lesen. Daher bin ich auch nicht ganz 
sicher, ob die Auflösung der abgespeicherten Daten ok ist.

Evtl. hat jemand eine besseere Idee?

: Bearbeitet durch User
von K. S. (the_yrr)


Angehängte Dateien:

Lesenswert?

CSV funktioniert schon ewig nicht bei Pulseview. Leider funktioniert bei 
VCD Dateien auch der analoge Teil nicht, in GTKWave allerdings 
problemlos. Wenn jemand weiß wie man in Pulseview auch analoge Kanäle 
als VCD importieren kann, könnte ich die konvertierte Datei hochladen.

EDIT:
probiert es mal hiermit, import als "raw analog data", format FLOAT_LE, 
4 Kanäle.

das sieht zumindest auf den ersten Blick so aus wie die VCD in GTKWave, 
sollte also stimmen.

: Bearbeitet durch User
von Ralph S. (jjflash)


Lesenswert?

öööööha: Pulseview schmiert bei mir auch ab ... und wahrscheinlich:

K. S. schrieb:
> CSV funktioniert schon ewig nicht bei Pulseview. Leider funktioniert bei
> VCD Dateien auch der analoge Teil nicht, in GTKWave allerdings
> problemlos.

bei anderen auch nicht. GTKwave (Asche über mein Haupt) kenne ich nicht, 
aber ich versuche mich gerade mit LibreOffice-Calc (ist bei 1.000.000 
Meßreihen bei 4 Meßstellen nicht so ganz easy), aber ich hab für mich 
das ganze jetzt mal extrahiert und "programmiere" mir so meine eigenen 
Filter um zu sehen was da los war.

Außerdem werde ich mal (ich habe leider kein 4-Kanal 
Speicheroszilloskop) mir die Spannungsverläufe ohne die Logik und danach 
auf dem Logikanalyzer die Logik ansehen.

In den Daten von Tim sieht es bis jetzt so aus, als ob die V_pp beim 
Schreiben 8.2V beträgt. Was mich stutzig macht (und das werde ich dann 
ausprobieren) ist, dass (so beim Überfliegen der Meßreihen ohne Grafik) 
beim anliegen von 8.2V die V_dd scheinbar 1.8V hat. Da wäre ich bisher 
viel zu hoch gewesen....

Ich schau mal

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

K. S. schrieb:
> EDIT:
> probiert es mal hiermit, import als "raw analog data", format FLOAT_LE,
> 4 Kanäle.
>
> das sieht zumindest auf den ersten Blick so aus wie die VCD in GTKWave,
> sollte also stimmen.

Super, scheint zu funktionieren! Hast Du das über GTKwave exportiert?

Leider ist die Qualität der Daten nicht ganz so gut wie erhofft. Die 
Auflösung reicht nicht immer für die clock aus. Vermutlich hat mein 
Scope nicht alle Daten exportiert. Es gab auch noch ein ground-loop 
problem, da der programmer den GND-Pin nicht immer auf ground legt.

Das müsste ich noch einmal wiederholen - wird leider erst nach 
Weihnachten etwas. Um die grobe Sequenz und das VPP/VDD cycling zu 
verstehen, könnte es aber ausreichen.

von Ralph S. (jjflash)


Lesenswert?

Tim  . schrieb:
> Das müsste ich noch einmal wiederholen - wird leider erst nach
> Weihnachten etwas. Um die grobe Sequenz und das VPP/VDD cycling zu
> verstehen, könnte es aber ausreichen.

Sehr super. Leider sehe ich noch nicht wirklich alles das, was ich sehen 
mag. Vllt. könntet ihr mir die csv-Datei nach vcd konvertieren (weil aus 
irgendeinem Grunde mag das Python-Script nicht so, wie ich das will). 
GTKwave habe ich mir installiert nd läuft.

Hey... ;-) vllt. wird das ja doch noch was für den PFS173 (eigentlich 
habe ich schon aufgegeben gehabt). Zu der Vpp/Vdd cyling: so in etwa 
habe ich das bisher versucht. Die nicht aufgelöste Signalfolge von 
clk/dat wäre jetzt interessant. Allerdings "verwirrt" mich noch etwas, 
dass deren Pegel in Abhängigkeit des Pegels von Vpp mit nach oben/unten 
wandern.

Ich bin mal gespannt !

von Tim  . (cpldcpu)


Lesenswert?

Ralph S. schrieb:
> Allerdings "verwirrt" mich noch etwas,
> dass deren Pegel in Abhängigkeit des Pegels von Vpp mit nach oben/unten
> wandern.

Das ist das GND-Problem. Der ground pins floatet teileweise. Ich muss 
wahrscheinlich gegen das Gehäuse erden.

Korrektur: Die Digitalpegel skalieren mit VDD. Das wird durch 
programmer/DUT verursacht weil die Logikpegel mitskalieren.

: Bearbeitet durch User
von Ralph S. (jjflash)


Lesenswert?

Tim  . schrieb:
> Ralph S. schrieb:
>> Allerdings "verwirrt" mich noch etwas,
>> dass deren Pegel in Abhängigkeit des Pegels von Vpp mit nach oben/unten
>> wandern.
>
> Das ist das GND-Problem. Der ground pins floatet teileweise. Ich muss
> wahrscheinlich gegen das Gehäuse erden.
>
> Korrektur: Die Digitalpegel skalieren mit VDD. Das wird durch
> programmer/DUT verursacht weil die Logikpegel mitskalieren.

;-) ich wollte dir eigentlich keine Mühe machen ... aber danke dafür, 
dass dir die Mühe machst !

Ich habe im Kopf erst einmal ein bisschen Ruhe vor dem 173er, weil ich 
mich im Kreis drehe, und werde das nach einer (kürzeren) Zeit wieder 
auspacken mit hoffentlich ein paar neuen Ideen dazu.

;-) ;-) ;-) dafür habe ich "oldschool man" mein Ultra-Retro IDE 
öffentlich gemacht (und kein Scheiß, ca. 70% vom Sourcecode schreibe ich 
damit, u.a. auch, weil mir darin das "suchen-ersetzen" besser gefällt 
als sonst wo).

von K. S. (the_yrr)


Angehängte Dateien:

Lesenswert?

Tim  . schrieb:
> Super, scheint zu funktionieren! Hast Du das über GTKwave exportiert?

freut mich. Nein, das habe ich über ein kurzes Python Script erstellt, 
zusammengeklaut und sehr hässlich. War aber schneller fertig als es 
gedauert hat herauszufinden, dass Pulseview in VCD die analogen Kanälen 
ignoriert.

Anbei das Script, obwohl ich mich für die Qualität schon etwas schäme, 
sowie das VCD. Ich würde allerdings das RAW von oben mit Pulseview 
benutzen, funktioniert super.

von W.S. (Gast)


Lesenswert?

Ralph S. schrieb:
> Ich hätte gewettet, dass du hier wieder aufschlagen wirst ob des
> "zerklüfteten" Quellcodes und hatte mir schon in den Hintern gebissen..

Na lieber nicht, sonst mußt du im Stehen programmieren. Aber vielleicht 
merkst du inzwischen, wie ungemein wichtig das Dokumentieren all dessen 
ist, was da bislang herausgefunden wurde.

Und zum Quellcode des Easy-PDK-Brenners: der ist nicht zerklüftet, 
sondern auf seine Art völlig professionell geschrieben. Das merkt man an 
allen Stellen.

Aber er ist NICHT dafür gemacht, daß du oder ich oder irgend jemand 
anderes dort ohne längere Beschäftigung durchsehen kann.

Er ist zwar veröffentlicht, aber nicht, um dir den eigenen Nachbau zu 
erleichtern. Bedenke mal, daß von diesen Brennern vor geraumer Zeit wohl 
schon die zweite Serie aufgelegt worden ist.

So viele Brenner braucht ein einzelner Bastler nicht, das ist zum 
Verkauf gedacht. Und das ist auch der Punkt, an dem ich mich störe.

Du magst das meinetwegen völlig anders sehen, aber das ändert nichts 
daran, daß hier jetzt die Signale nochmal per Speicheroszi aufgenommen 
werden und man sie auswerten will.

OK, man könnte auch den Thread im eevblog nochmal komplett durchkauen 
und all die dortigen Anhänge durchsehen, das Ganze ist ja bereits schon 
mal getan worden - aber eben nicht für dich und nicht für mich. 
Vielleicht verstehst du mich jetzt etwas besser.

W.S.

von Ralph S. (jjflash)



Lesenswert?

So, mein "Testballon" mit JLCPCB ist heute angekommen (Platinen) und ich 
habe gleich eine bestückt und bin erstaunt, weil die Platine so ohne 
weiteres sofort funktioniert hat.

Für diejenigen, die sich eine solchige Platine machen lassen wollen sind 
die Gerber-Files im Anhang (allerdings: die Platine ist nicht wirklich 
"schön", sieht ob der ausschließlich bedrahteten Bauteil schon "retro" 
aus. Allerdings war/ist das ja "nur" ein Lochrasterprojekt gewesen und 
von daher.

Aber sie funktioniert (sehr gut).

von bingo (Gast)


Lesenswert?

Ralph S. schrieb:
> Für diejenigen, die sich eine solchige Platine machen lassen wollen sind
> die Gerber-Files im Anhang

DANKE! Bin selbst noch nicht dazu gekommen, mein eigenes PDF zu ätzen
Beitrag "Re: Padauk PFS154 Programmer mit Arduino Uno / ATmega88 - 328"

von Ralph S. (jjflash)


Lesenswert?

Eine Platine hätte ich noch zu vergeben. Für 6 € inklusive Porto kannst 
du sie haben .

von Ralph S. (jjflash)


Lesenswert?

1
 _______________________________________________________
2
3
                Stueckliste / BOM
4
 _______________________________________________________
5
6
  Anzahl |   Wert            |    Bemerkung
7
 ________|___________________|__________________________
8
9
            Kondensatoren
10
 _______________________________________________________
11
         |                   |
12
    1    |    1.8 nF         |
13
    2    |    220 nF         |
14
    3    |     10 uF / 16V   |
15
    1    |     47 uF / 25V   |  16V reichen nicht
16
    1    |    220 uF / 10V   |  kann auch groesser sein
17
 ________|___________________|___________________________
18
19
                Spule
20
 ________________________________________________________
21
         |                   |
22
    1    |  330 uH / 100 mA  |  koennen auch 2 parallel
23
         |                   |  geschaltete 680 uF sein
24
 ________|___________________|___________________________
25
26
               Dioden
27
 ________________________________________________________
28
         |                   |
29
    1    |      BAT48        |  oder beliebige Shottky-
30
         |                   |  Diode
31
    1    |       LED         |  Farbe nach Wunsch
32
 ________|___________________|___________________________
33
34
             Widerstaende
35
 ________________________________________________________
36
         |                   |
37
    1    |        18         |
38
    1    |       180         |
39
    2    |       220         |
40
    2    |       330         |
41
    1    |       470         |  Vorwiderstand LED, je
42
         |                   |  nach Strombedarf der LED
43
    3    |        1k         |
44
    3    |      4.7k         |
45
    3    |       10k         |
46
 ________|___________________|___________________________
47
48
                 IC's
49
 ________________________________________________________
50
         |                   |
51
    1    |       LM358       |  KEIN TL072 / TL084 !!
52
    1    |     MC34063       |
53
 ________|___________________|____________________________
54
55
              Sonstiges
56
 ________________________________________________________
57
         |                   |
58
    2    |  2-pol. Stift     | Jumper JP1 / JP2
59
    1    | 10-pol. Stift     | Arduino Steckverbinder
60
    2    |  8-pol. Stift     | Arduino Steckverbinder
61
    1    |  6-pol. Stift     | Arduino Steckverbinder
62
    2    |  8-pol. Buchse    | Sockel PFS154
63
 ________|___________________|____________________________

von chris_ (Gast)


Lesenswert?

>So, mein "Testballon" mit JLCPCB ist heute angekommen (Platinen) und ich
>habe gleich eine bestückt und bin erstaunt, weil die Platine so ohne
>weiteres sofort funktioniert hat.

Die Platine gefällt mir richtig gut. Leider habe ich kaum Zeit, mich mit 
dem Thema zu beschäftigen. Am besten wäre es, wenn es irgendwo einen 
Bausatz mit allen Teilen und ein paar Sample-Prozessoren gibt.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ralph S. schrieb:
> Stueckliste / BOM

Super, vielen Dank!

von Ralph S. (jjflash)


Lesenswert?

chris_ schrieb:
> Am besten wäre es, wenn es irgendwo einen
> Bausatz mit allen Teilen und ein paar Sample-Prozessoren gibt.

Bausatz kann es nicht geben, da es die Platine erst seit gestern gibt. 
Jetzt wäre es ein leichtes, sich anhand der Stückliste die Teile 
irgendwo zu bestellen, wenn es auch noch Sample-Prozessoren benötigt 
wäre da die Quelle der Wahl: www.lcsc.com

Wenn du aber kaum Zeit hast, solltest du dich vllt. mit neuen (auch wenn 
sie relativ einfach sind) Microcontrollern nicht beschäftigen

von Jürgen Z. (jk_z) Benutzerseite


Lesenswert?

Hallo und gutes neues Jahr,

erstmal danke für die Top-Entwicklung. Ich hatte Anfang des Jahres auch 
mit ähnlichen Ideen angefangen, aber mein Padauk-Projekt (und vieles 
anderes) ist dann wegen Corona-bedingter Mehrarbeit einfach 
liegengeblieben. Mein erster Ansatz war einen alten 
Vellman-Pic-Programmer "umzurüsten", bevor ich eine neue Hardware mache 
... Ich hatte mich da auch an dem EASY-PDK-Programmer orientiert.

> Eine Platine hätte ich noch zu vergeben. Für 6 € inklusive Porto kannst
> du sie haben .

Ich hätte an der Platine Interesse, falls sie nicht bereits jemandem 
versprochen oder schon verkauft ist. Meine ersten Anwendungen der PFS, 
die ich jetzt in Angriff nehmen wollte, gehen in Richtung Amateurfunk 
und digitale Modelleisenbahndecoder ...
Notfalls müsste bei mir eben eine Arduino-Prototypplatine "dran glauben" 
:-) ...

Grüße,
Jürgen

von Testi (Gast)


Lesenswert?

Du könntest dein Programmer auf kitspace.org stellen:
Dort können
- Gerber files
- BOM

direkt hinterlegt werden, so dass per Mausklick die Komponenten (z.B. 
von Mouser, LCSC, Digikey, ...) und das PCB (z.B. von PCBWay, Aisler, 
OSHPark, JLCPCB, ...) bestellt werden können.

Beispiel:
https://kitspace.org/boards/github.com/kitspace-forks/arduino-uno/

von Ralph S. (jjflash)


Lesenswert?

Jürgen Z. schrieb:
> Mein erster Ansatz war einen alten
> Vellman-Pic-Programmer "umzurüsten", bevor ich eine neue Hardware mache

Daran dürften wohl einige gedacht haben (und ich auch) und ich hatte 
versucht gehabt, einen einfachen Programmer von mir (der nur wenige 
PIC16F flashen konnte) umzuprogrammieren für den PFS, aber das 
scheiterte an 3 Dingen:

1.) mein PIC - Programmer hat nur einen rudimentären PWM Step-Up Wandler 
ohne Regelung (d.h. keine Kontroller der erzeugten Ausgangsspannung, die 
Ausgangsspannung wird in ihrer Höhe durch eine Zenerdiode begrenzt)

2.) meine erzeugten 12V sind nicht stabil genug für einen PFS-Flasher 
und die Responszeit bis eine Spannung eingestellt ist dauert zu lange

3.) ... der absolut hinderlichste Grund: Um den Flashvorgang stabil zu 
bekommen benötigt es beim Flashen des PFS derer 2 einstellbarer 
Spannungsleitungen. Die Vdd muß beim Flashen auf 3 V gehalten werden 
(genauer gesagt der Spannung entsprechen, die die Logikpegel der 
seriellen Programmierung haben). Auf Vdd muß also einstellbar sein: 0V, 
3V, 5V. Auf Vpp muß einstellbar sein: 0V, 6V, 8V.

Meinem PIC-Programmer fehlte da schlicht eine zweite analoge Zuführung 
an den Target-Controller

von Ralph S. (jjflash)


Lesenswert?

Testi schrieb:
> direkt hinterlegt werden, so dass per Mausklick die Komponenten (z.B.
> von Mouser, LCSC, Digikey, ...) und das PCB (z.B. von PCBWay, Aisler,
> OSHPark, JLCPCB, ...) bestellt werden können.

na ja, die Gerberfiles hier (und auf dem GitHub Repository) können so 
wie sie sind an jlcpcb geschickt werden. Benötigtes Material sollte bei 
jedem halbwegs gut sortierten Elektronikbastler vorrätig sein.

von Ralph S. (jjflash)


Lesenswert?

Für die nächsten Tage: Ciao

Irgendwann mach ich vllt. mal mit dem Programmer weiter.

von Ralph S. (jjflash)


Lesenswert?

Unglaublich: jetzt habe ich so viele PFS154 für Experimentierzwecke 
verschenkt, dass ich mir jetzt welche auf lcsc.com nachbestellen wollte 
und zu meinem Erschrecken mußte ich feststellen, dass die 16 pol. 
Variante "out of stock'" ist.

Gibts noch andere gut Bezugsquellen hierfür?

Verrückt dass man sogar als Bastler die Chipknappheit (ob nun künstlich 
oder durch Corona) zu spüren bekommt.

Dringlich sind die Chipfs für mich noch nicht, ich habe noch 6 Stück, 
aber erstaunt, dass die nicht lieferbar sind war ich doch!

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Ralph,

ich habe diese gefunden:

https://de.aliexpress.com/item/1005002002245739.html

von Ralph S. (jjflash)


Lesenswert?

Oki, werde ich "zur Not" dort bestellen, wenn ich sie dringend brauche 
(die sind dort ja nur noch halb so preiswert wie auf lcsc.com .... oder 
auch doppelt so teuer).

;-) hast du den Programmer mal zusammengebaut ?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ralph S. schrieb:
> ;-) hast du den Programmer mal zusammengebaut ?

Nein, bin noch nicht dazu gekommen. Kommt aber :)

von Tiramisu (Gast)


Lesenswert?

Arduino UNO Programmer fuer den PFS154 aus dem github bei
AISLER fertigen lassen und zusammengebaut, funktioniert! MERCI!

Ich habe uebrigens mit meinen HP Elitebook auch das Problem,
dass ich nur ein paar Mal den Programmer aufrufen kann, dann
kommt irgendwann ein "Communication Error". Da nuetzt dann ein
Abstecken des Arduino nichts, ich muss den Rechner rebooten,
obwohl das ein /dev/ttyACM0 Device ist (vgl. README).

Blink aus dem github laeuft!

Das "ewige Licht" im Thread 'Ultra Low Power LED Flasher mit Padauk 
PFS154', Beitrag "Ultra Low Power LED Flasher mit Padauk PFS154",
wurde mit sdcc4.1.0 uebersetzt und wird ohne Fehlermeldung programmiert:

-x-x-x-x-

$ ./pfsprog txwr /dev/ttyACM0 /tmp/main.ihx

 waiting for programmer...

 ID: 0x0aa1 found, PFS154 present...

 Words to flash: 2048

 Writing|################################################### 100% 2.21s

 All is done...

-x-x-x-

allerdings gibt es kein Blinken(an zwei unbeschriebenen PFS154 
ausprobiert).
Ich habe den 16-poligen PFS154 genommen
und ich habe mich nicht getraut die LED ohne 220Ohm Widerstand an dem
Pin zu betreiben (Labornetzteil 3,3V).

Waere es moeglich, das Intel Hex File zu bekommen, das definitiv laeuft?
Nach meinem Wissensstand sieht das Compilat (dispdk 2AA1 /tmp/main.ihx)
(s.u.) gut aus und es ist IMHO erstaunlich kurz fuer einen Controller, 
der nur
ein einziges Register ("A") hat:


0x0000:   0x0000    NOP

0x0001:   0x1301    CLEAR [0x01]

0x0002:   0x2f02    MOV A, 0x02

0x0003:   0x2801    ADD A, 0x01

0x0004:   0x2cfe    AND A, 0xFE

0x0005:   0x0182    MOV IO(0x02), A  ;SP

0x0006:   0x381d    CALL 0x01D

0x0007:   0x3012    GOTO 0x012

0x0008:   0xffff    ?????

0x0009:   0xffff    ?????

0x000a:   0xffff    ?????

0x000b:   0xffff    ?????

0x000c:   0xffff    ?????

0x000d:   0xffff    ?????

0x000e:   0xffff    ?????

0x000f:   0xffff    ?????

0x0010:   0x007b    RETI

0x0011:   0x3022    GOTO 0x022

0x0012:   0x2f02    MOV A, 0x02

0x0013:   0x0b80    MOV [0x00], A

0x0014:   0x3019    GOTO 0x019

0x0015:   0x2f00    MOV A, 0x00

0x0016:   0x0380    IDXM 0x00, A

0x0017:   0x1200    INCM [0x00]

0x0018:   0x2f02    MOV A, 0x02

0x0019:   0x2800    ADD A, 0x00

0x001a:   0x1700    CEQSN A, [0x00]

0x001b:   0x3015    GOTO 0x015

0x001c:   0x3011    GOTO 0x011

0x001d:   0x2ff4    MOV A, 0xF4

0x001e:   0x0183    MOV IO(0x03), A  ;CLKMD

0x001f:   0x2fe4    MOV A, 0xE4

0x0020:   0x0183    MOV IO(0x03), A  ;CLKMD

0x0021:   0x0200    RET 0x00

0x0022:   0x2f00    MOV A, 0x00

0x0023:   0x018d    MOV IO(0x0D), A  ;PADIER

0x0024:   0x2f00    MOV A, 0x00

0x0025:   0x018e    MOV IO(0x0E), A  ;PBDIER

0x0026:   0x2f00    MOV A, 0x00

0x0027:   0x0184    MOV IO(0x04), A  ;INTEN

0x0028:   0x2f00    MOV A, 0x00

0x0029:   0x0185    MOV IO(0x05), A  ;INTRQ

0x002a:   0x2f20    MOV A, 0x20

0x002b:   0x0188    MOV IO(0x08), A  ;MISC

0x002c:   0x2f42    MOV A, 0x42

0x002d:   0x019c    MOV IO(0x1C), A  ;TM2C

0x002e:   0x2f00    MOV A, 0x00

0x002f:   0x019d    MOV IO(0x1D), A  ;TM2CT

0x0030:   0x2f47    MOV A, 0x47

0x0031:   0x0197    MOV IO(0x17), A  ;TM2S

0x0032:   0x2f01    MOV A, 0x01

0x0033:   0x0189    MOV IO(0x09), A  ;TM2B

0x0034:   0x2f10    MOV A, 0x10

0x0035:   0x0190    MOV IO(0x10), A  ;PA

0x0036:   0x2f00    MOV A, 0x00

0x0037:   0x0192    MOV IO(0x12), A  ;PAPH

0x0038:   0x2f00    MOV A, 0x00

0x0039:   0x0191    MOV IO(0x11), A  ;PAC

0x003a:   0x1f11    SET1 IO(0x11).4  ;PAC.4

0x003b:   0x0000    NOP

0x003c:   0x0000    NOP

0x003d:   0x0000    NOP

0x003e:   0x1d11    SET0 IO(0x11).4  ;PAC.4

0x003f:   0x0077    STOPEXE

0x0040:   0x0000    NOP

0x0041:   0x303a    GOTO 0x03A

0x0042:   0x007a    RET

von Tiramisu (Gast)


Lesenswert?

Bin etwas weitergekommen:

Andere Programme wie "oled1306_i2c" des Padauk-pfs154 githubs
laufen tadellos und auf Anhieb, nochmals DANKESEHR!

Wenn ich das github blink/blink.c abaendere und auf den ILRC Takt
umschalte mit:

#define speed1         10

void main(void)

{

  CLKMD =  CLKMD_ILRC | CLKMD_ENABLE_ILRC | CLKMD_ENABLE_IHRC;

  CLKMD =  CLKMD_ILRC | CLKMD_ENABLE_ILRC ;

  ...

blinkt es fein und mit dem niedrigen Takt ILRC.

Wenn ich noch vor den CLKMD settings noch

PDK_SET_FUSE(FUSE_IO_DRV_LOW);  // Set output driving strength to low

hinzufuege, also:

void main(void)

{

  PDK_SET_FUSE(FUSE_IO_DRV_LOW);  // Set output driving strength to low

  CLKMD =  CLKMD_ILRC | CLKMD_ENABLE_ILRC | CLKMD_ENABLE_IHRC;

  CLKMD =  CLKMD_ILRC | CLKMD_ENABLE_ILRC ;

ist weder an der LED noch an meinem Voltmeter eine Aenderung
(der etwa 0,1V) des Ports zu sehen.

Der sdcc generiert in das Assemblerfile:

                                    232         .area   FUSE (ABS)

      000FFE                        233         .org    (0x07ff*2)

      000FFE FC 30                  234         .word   (0x30FC|0x0000)

                                    235         .area   CODE

Im Intel Hex sind die Fuses an 0x07ff m.E. korrekt gesetzt.

$ dispdk 2aa1 l.ihx

...

0x07fd:   0xffff    ?????

0x07fe:   0xffff    ?????

0x07ff:   0x30fc    GOTO 0x0FC


Sollte es funktionieren, dass man mit dem PFS154 Arduino Uno Programmer
und dem pfsprog die Controller-Fuses setzen kann --- ich frage nur,
weil ja Fuses-immer-Aerger-machen(TM) und das halt eine Erklaerung 
waere?

von Ralph S. (jjflash)


Lesenswert?

Schau dir mal:

https://github.com/jjflash65/Padauk-pfs154/blob/master/include/auto_sysclock.h

an!

Da wirst du feststellen, dass du an Fuses nicht wirklich hantieren 
musst. Solltest du die in dem Github verwendeten Demos ausprobieren (und 
das Setup unangetastet lassen), mußt du in dem entsprechenden Makefile 
einzig die Angabe für F_CPU machen!

Ansonsten freue ich mich dass der Programmer funktioniert.

Tiramisu schrieb:
> Ich habe uebrigens mit meinen HP Elitebook auch das Problem,
> dass ich nur ein paar Mal den Programmer aufrufen kann, dann
> kommt irgendwann ein "Communication Error". Da nuetzt dann ein
> Abstecken des Arduino nichts, ich muss den Rechner rebooten,
> obwohl das ein /dev/ttyACM0 Device ist (vgl. README).

Ich habe leider kein HP Elitebook, sonst hätte ich mir das angesehen. 
Verwunderlich ist, dass dann sogar ein Abstecken nichts mehr nutzt. 
Andererseits (habe ich schon erlebt) kann es sein, dass der Devicename 
"ttyACM0" nicht mehr vergeben wird und ein neuanstecken sich als 
"ttyACM1" anmeldet. Sollte dieses der Fall sein, hilft in aller Regel 
dann:

ln /dev/ttyACM1 /dev/ttyACM0

Hiermit wird bis zum nächsten Booten das Device auf den angegebenen Port 
gelinkt!

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

By the way: darf ich mal fragen, was du bei Aisler bezahlt hast ?

von Tiramisu (Gast)


Lesenswert?

>By the way: darf ich mal fragen, was du bei Aisler bezahlt hast ?
Fuer drei Platinen incl. P&P: 23,31E

Ich hab gestern den zweiten Programmer angefangen aufzubauen(die 
16p-TEXTOOL
Sockel sind angekommen :-) ), den nehme ich heute in Betrieb, ich mache
dann mal ein paar Bilder. Auf aliexpress gibt es ein paar coole
SOP16->DIP Konverter, dann brauchen die PFS154 nicht mehr diese
Fummelbehandlung...

Bei aliexpress sind die PFS154 als auch die PFS173 (noch) verfuegbar...

von Ralph S. (jjflash)


Lesenswert?

Ich bin dabei, die Schaltung um einen Analogschalter zu erweitern (mit 
Relais funktioniert es natürlich schon) um die Anschlußpins des PFS154 
über ein Flachbandkabel mit DIP16 Verbinder nach außen zu führen, um 
nicht jedesmal den Chip in die Fassung zu stecken und auf einem 
Steckbrett experimentieren zu können,

Und wenn ich da schon dabei bin, wird die Platine einen eigenen ATmega 
(88, 168 oder 328) beherbergen, so dass ein Arduino-Uno nicht mehr 
benötigt wird.

Sozusagen ein "In-Circuit-Emulator" für Arme.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.