Announcement: there is an English version of this forum on 
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).
Angehängte Dateien:
-
pfs154_progshield_schematic.gif
13 KB -
pfs_progshield_bestueck_kl.jpg
270 KB -
pfs_progshield_loet_kl.jpg
310 KB -
pfs154_programmer_shield_3.gif
170 KB -
pfsprog_upload_screen.png
26 KB
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 ;-)
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
(ü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.)
Ich nehme gerne eine Platine, ich finde diese kleinen µCs sehr interessant. Ich melde mich bei Dir dann per Mail.
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 !
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.
Für alle, welche die Platine lieber selber ätzen wollen, gibt es hier jetzt ein PDF
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.
Habe das Layout nochmals gerinfügig verbesert
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.)
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
Angehängte Dateien:
-
pfsprog_layout_600dpi.jpg
410 KB
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.
Angehängte Dateien:
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
ich versuche mich mal das auf eagle umzusetzen (Merker)
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 !
kennst Du das hier Beitrag ""Universalprogrammer" für Linux" vielleicht könntet ihr euch zusammentun
Beitrag #6514399 wurde vom Autor gelöscht.
Angehängte Dateien:
-
pfsprog4.gif
64 KB
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.
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
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.
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"
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.
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 ...
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!
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.
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.
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.
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?
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. https://www.ebay.de/itm/20PCS-SOP16-SSOP16-TSSOP16-To-DIP16-0-65-1-27mm-IC-Adapter-PCB-Board/173990566789?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649 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: https://www.ebay.de/itm/SOP20-to-DIP20-20-PIN-Programmer-Adapter-Socket-Converter-Board-1-27-mm-Pi-LTkj/373373709254?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649 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 ?!?
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
Angehängte Dateien:
-
ir-remote-code.png
3,8 KB
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
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.
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
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.
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
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 ?
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?
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.
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
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.
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).
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).
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.
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
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
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
ööööö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
Angehängte Dateien:
-
pfs173.PNG
170 KB
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.
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 !
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
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).
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.
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.
Angehängte Dateien:
-
pfs154_fotoansicht.jpg
180 KB -
PFS154_programmer_shield_pcb.jpg
190 KB
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).
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"
Eine Platine hätte ich noch zu vergeben. Für 6 € inklusive Porto kannst du sie haben .
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 | ________|___________________|____________________________ |
>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.
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
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
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/
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
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.
Für die nächsten Tage: Ciao Irgendwann mach ich vllt. mal mit dem Programmer weiter.
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!
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 ?
Ralph S. schrieb: > ;-) hast du den Programmer mal zusammengebaut ? Nein, bin noch nicht dazu gekommen. Kommt aber :)
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
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?
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 ?
>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...
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.
Seid Ihr mit dem PFS173 weitergekommen ? Ich träume ja immer noch von einem 128s Balancer, das wäre zumindest endlich mal eine sinnvolle Anwenung für eine 5 cent mcu. Der PFS154 hat ja kein ADC sondern nur einen analogen comperator, was immer das ist. Kann man damit auch schrittweise 8 bit messen ? Neben den 100 Euro für den offiziellen Programmer schreckt mich vor allem die Einarbeitung in eine neue toolchain ab. Und linux hab ich nur auf meinen vservern. Da hab ich aber für meinen hoverboard online compiler inzwischen eine hübsche IDE entwickelt: www.pionierland.de/hoverhack Also wenn Ihr mir ein Makefile geben könnt und ich die toolchain dort installiere, dann könnte ich flux eine online ide für die Padauk chips machen. Dann bräuchte ich nur noch ein Windows tool um über den Nano zu flashen ? Toll finde ich, dass Euer programmer mit 1-2 Stunden auf lochrasterplatine selbst herzustellen ist. Brauche ich wirklich den MC34063 Bereich? Oder kann man nicht einfach einen billige dcdc step up booser auf 14V einstellen ? das Roland und Dankeschön.
Das R. schrieb: > Brauche ich wirklich den MC34063 Bereich? Oder kann man nicht einfach > einen billige dcdc step up booser auf 14V einstellen ? ... sollte auch gehen ! Das R. schrieb: > Seid Ihr mit dem PFS173 weitergekommen ? nein, ich habe da schlicht aufgegeben ! Das R. schrieb: > Neben den 100 Euro für den offiziellen Programmer schreckt mich vor > allem die Einarbeitung in eine neue toolchain ab. Du kannst ja denn EASY-PDK-PROGRAMMER von hier aufbauen: https://github.com/free-pdk/easy-pdk-programmer-hardware Der kann auch den PFS173. Allerdings ist der dort verwendete STM32F072 in Pandemiezeiten ziemlich rar geworden, leider ! Alternativ kannst du einen Programmer mit STM32F072 auch nach: Beitrag "Re: Zeigt her eure Kunstwerke (2020)" aufbauen. Hier hast du dann nicht all zu kleine Teile.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.