chaplin1999 / padauk-pfs154 Goto Github PK

Hier war urspruenglich geplant, Schaltplan, Layout und Software fuer einen Arduino UNO basierenden Programmer fuer den PFS154 Mikrocontroller von Padauk zu veroeffentlich. Daraus entwickelt hat sich bei den Fragen nach einer Toolchain und Beispielprogrammen eher ein komplettes Setup fuer den Chip. Grundsaetzlich:

• alle Beispiele sind Makefile-Projekte
  
• die Toolchain und alle hier enthaltenen Binaries sind defaultmaessig
  fuer ein 64-Bit Linuxsystem eingerichtet, alle Programme sind Kommando-
  zeilenprogramme.
  

Google-Ergebnisse geben da derzeit nur 2 Projekte aus, die nicht auf dem oben genannten Programmer basieren.

Beide habe ich ausprobiert (eines ist ein Projekt von socram8888 und eines vom mikrocontroller.net Mitglied CPLDCPU.. auch hier ein Dankeschoen). Beide dieser Projekte basieren auf einem ATMega / Arduino. Das Projekt von socram habe ich gar nicht an's Laufen gebracht, das von CPLDCPU / Tim nur mit sehr grossen Einschraenkungen, aber er hatte es in seiner Beschreibung ja auch schon gesagt gehabt: sein Projekt ist "hoch unfertig" und kann als Vorlage / Ideengeber dienen, einen eigenen Programmer zu entwickeln.

Grundsaetzlich hapert es bei beiden AVR basierenden Programmern daran, dass die Spannungen die zum Flashen benoetigt werden relativ kritisch in ihrer Konstanz und in ihrer Genauigkeit sind. Auch mein erster Ansatz, mittels eines PWM-Signals an einer geschalteten Spule die Programmierspannung zu erzeugen hatte nicht den gewuenschten Erfolg gebracht.

Der Ansatz des Easy-PDK-Programmers ist hier der bessere / richtige Weg: Eine konstante Spannung erzeugen, die ein paar Volt oberhalb der Spannung liegt, die beim Flashen benoetigt wird. Zu allem Unglueck (und da hapert es dann bei Tim's Entwurf) kann nach meinen Erkenntnissen - ein PFS-Controller nur korrekt geflasht werden, wenn 2 Spannungen variabel eingestellt werden koennen: Die Spannung an V_dd und die Programmierspannung V_pp an PA5.

Beim hier vorgestellten Programmer wird nun die Programmierspannung nicht mit einer PWM erzeugt, sondern mit dem ultra billigen (und sehr alten) Schaltregler MC34063. Wie beim "Easy-PDK-Programmer" auch werden 2 Operationsverstaerker in einem DIP-8 Gehaeuse (wieder ultra billig, wieder sehr alt: LM358) vom AVR an deren Eingaengen mit einer analogen Spannung gespeist, die durch PWM generiert und durch ein passives Tiefpass mit einer Grenzfrequenz von ca. 72 Hz in eine halbwegs ertraegliche Gleichspannung gefiltert wird. Der LM358 wird durch die Ausgangsspannung des Schaltreglers versorgt.

Meine eigene Zielvorgabe beim Entwurf des Programmers war, eine Schaltung zu erstellen, die von einem ambitionierten Elektroniker / Hobbybastler in wirklicher "do it yourself" Manier mit absolut gaengigen Standardbauteilen aufgebaut werden kann. LM358 und MC34063 sind aeuserst preiswert und hoch verfuegbar, ansonsten werden nur Widerstaende, Kondensatoren und eine Spule verwendet.

Aus diesem Grunde wurde auch ein Arduino UNO als Controller gewaehlt, weil dieser eine sehr grosse Verbreitung hat und wohl auch im Besitz solcher Elektroniker ist, die normalerweise die Nase bei dem Wort "Arduino" ruempfen (selbst mag ich die Hardwareteile, das Framework der Arduino-Sketche mag ich jedoch weniger: ich schreibe mir meine "Libraries" lieber selbst).

Die Firmware selbst ist daher auch nicht als Arduino-Sketch programmiert, sondern ist ein "normales" C-File, welches mit AVR-GCC kompiliert werden kann. Die Firmware wurde auch auf ATMega88 und Atmega168 getestet und funktioniert auf beiden Controllern.

Gerberfiles, Schaltplan und Bilder finden sich im Verzeichnis:

./gerber_files

Damit mit dem Arduino basierenden Programmer gearbeitet werden kann, habe ich in die Zip-Datei ein komplettes Setup gepackt, welches ein Programm fuer einen PFS154 erstellen und mit dem Programmer der Chip geflasht werden kann.

Vorraussetzung fuer dieses Setup ist:

• ein 64-Bit Linux System (bei Bedarf kann ich auch ein Setup fuer ein 32-Bit System erstellen, auf meinen Rechnern hier laeuft der Programmer auch darauf sehr gut)

• ein im System installierter SDCC ab der Version 4.0.3

• AVR-GCC zum Compilieren der Firmware des Programmers (wenn die Firmware des Programmers neu uebersetzt werden soll)

• AVRDUDE zum Flashen der Firmware

Das Hostprogramm ist in FreePascal geschrieben (einfach aus dem Grund, weil ich vor Ur-Zeiten in Pascal / Delphi Routinen zum Umgang mit Intel-Hex Files und deren Uebertragung geschrieben habe und ich diese eben weiterverwende). Sollte jemand am Hostprogramm Modifikationen vornehmen wollen, ist ein im System installierter FreePascal Compiler ab Version 2.6.4 notwendig.

Die Installation der im ZIP-File enthaltenen Programm ist einfach: Das Archiv in einen gewuenschten Ordner entpacken. Alle benoetigten Programme (inklusive eines uebersetzten Hostprogramms fuer den Easy-PDK-Programmer) haben relative Pfade.

Jedes Beispielprogramm liegt in einem Unterverzeichnis und jedes ist ein "Makefile-Projekt".

Ein Programm fuer den PFS154 wird uebersetzt durch einen Aufruf:

                           make

Der Chip wird mit

                           make flash

beschrieben.

Da Makefiles nicht jedermans Sache ist, habe ich die Handhabung der Makefiles deutlich vereinfacht. Es besteht aus einem Teil, in dem Angaben ueber den Controller, die Frequenz, zusaetzlich einzubindende Quelldateien etc. gemacht werden muessen:

Bei "PROJECT" wird die Datei angegeben, die die "main"-Funktion beinhaltet. Die Angabe ist OHNE eine Dateierweiterung anzugeben, im Beispiel benoetigt es also eine Datei "blink.c".

Zusaetzliche einzubindende "Softwaremodule" (.c / .h - Kombinationen) sind bei SRCS anzugeben, sie werden standardmaessig im Verzeichnis ../src abgelegt. Sollen mehrere Quelldateien uebersetzt und hinzugelinkt werden, muss jede weitere Angabe fuer die Makefile-Variable SRCS mit += erfolgen (die die Variable SRCS um genau diesen Eintrag dann erweitert).

Im obigen Fall bedarf es einer Datei namens "delay.c" die das Makefile in eine Objektdatei mit der Endung .rel (hier dann delay.rel) compilieren wird.

Eine besondere Beachtung verlang die Angabe unter "FACTORYCAL". Der "Easy-PDK-Programmer" ist in der Lage beim Flashen eine Kalibrierung des Systemtakts des Controllers vorzunehmen, das kann der Arduino basierende Programmer NICHT. Soll das Projekt mit dem "Easy-PDK-Programmer" geflasht werden, wird eine Zuweisung "FACTORYCAL = 0" beim Flashen eine Kalibrierung vornehmen. Bei "FACTORYCAL = 1" wird keine Kalibrierung vorgenommen und ist die Wahl fuer den Arduino basierenden Programmer.

Wird im Makefile Programmer 2 gewaehlt (Arduino basierend) ist zwingend eine Angabe erforderlich, unter welchem Port der Arduino angeschlossen ist. Arduino Clone mit einer CH340 USB2UART Bridge sind unter /dev/ttyUSBx ansprechbar, originale Arduino UNO's sind unter /dev/ttyACMx ansprechbar.

Im Umgang mit dem CH340 Chip hat sich bei genau einem meiner Rechner ein Problem gezeigt (ein AMD Ryzen5): Er kann den CH340-Chip nur genau ein einziges mal ansprechen, danach ist der virtuelle serielle Port blockiert (ich habe bis heute nicht herausgefunden warum). Um nicht jedesmal den USB-Stecker zu ziehen und wieder einzustecken habe ich ein kleines Tool geschrieben, das den CH340 zuruecksetzt.

Sollte dieses Phaenomen auftreten, kann im Makefile die Zuweisung

                        CH340RESET = 1

gemacht werden, der CH340 wird dann vor dem Zugriff geresetet und das Flashen sollte kein Problem sein.

Im Verzeichnis ./tools/pfsprog/firmware befindet sich die Betriebssoftware des Programmers. Soll eine Neuuebersetzung des Sourcecodes erfolgen, ist ein:

                                 make

aufzurufen. Dies ist jedoch fuer einen Arduino Uno NICHT notwendig, da in diesem Ordner auch ein bereits kompiliertes Hex-File enthalten ist.

Wenn es sich beim Arduino um einen Clone handelt (Schnittstelle /dev/ttyUSB0), ist nichts weiter zu tun als:

                                 make flash

aufzurufen, der Arduino wird geflasht. Bei einem originalen UNO muss mittels Texteditor in diesem Makefile der Port unter dem der Arduino angesprochen wird auf /dev/ttyACM0 geändert werden.

Um die Funktion des Shields zu ueberpruefen (kein muss, aber sehr empfohlen), kann nun das Shield auf den UNO ohne eingesteckten PFS154 Controller aufgesteckt und der Jumper JP1 gesteckt werden. Nach einem Reset arbeitet die Firmware nun nicht als Programmer sondern sie kann die Spannungen, die an den PFS-Controller waehrend des Flashens gefuehrt wird kalibrieren. Notwendig war das bisher in keinem Fall, aber es eignet sich wie gesagt sehr dazu, die Funktion der Spannungseinstellung zu ueberpruefen.

Arduino mit aufgestecktem Shield und gestecktem JP1 anschlissen und ein Terminalprogramm mit der Einstellung 8 Datenbits, keine Paritaet, 1 Stopbit und 115200 Baud starten. Anschliessend einen Reset am Arduino durchfuehren.

Der Nutzer wird nun aufgefordert, erst die Spannung an PA5 (V_pp) des PFS-Controllers zu messen und diese Spannung in Millivolt einzugeben. Ist die Eingabe getaetigt, sollte an diesem Pin sofort 8V anliegen. Das gleiche Vorgehen nun fuer den Pin fuer V_dd durchfuehren, hier sollte an diesem Pin sofort 6V anliegen.

Ist dieses der Fall, so ist der Programmer korrekt aufgebaut. Die Kalibrierwerte werden im internen EEPROM gespeichert.

Da der Arduino bei jedem Zugriff über die Schnittstelle einen Reset durchfuehrt, durchlaeuft der Arduino eben jedem Zugriff jedesmal seinen Bootloader, er verweilt darin ca. 2 Sekunden. Um dieses zu unterbinden kann der Jumper JP2 gesteckt werden, er blockiert hier einen Reset ueer die serielle Schnittstelle.

Hinweis: soll der Arduino neu geflasht werden muss dieser Jumper wieder entfernt werden, weil ansonsten ein Reset blockiert ist und der Bootloader nicht gestartet werden kann.

pfsprog action port filename [nowait]

action : wr = flasht einen PFS154 Controller mit der Intel-Hexdatei "filename" txwr = dasselbe wie "wr" mit dem Unterschied, dass beim Flashen ein Fortschrittsbalken (Progressbar) angezeigt wird run = startet das Programm im Controller stop = stopt ein gestartetes Programm

port : Anschluss, unter dem der Programmer angesprochen werden kann

filename : Intel-Hex Datei, die geflasht werden soll

nowait : Optionaler Parameter. Normalerweise verbindet sich pfsprog mit dem Programmer und wartet dann 2,2 Sekunden (das ist die Zeit, die der Bootloader fuer sich in Anspruch nimmt) und beginnt erst dann mit der Datenuebertragung. nowait ueberspringt die Wartezeit und beginnt sofort mit der Uebertragung. Diese Option kann gewaehlt werden, wenn ein AVR-Controller ohne Bootloader geflasht wurde oder der Reset (mittels JP2) blockiert ist

Beispiel : pfsprog txwr /dev/ttyUSB0 blink.ihx nowait

• er kann keinen anderen Controller als einen PFS154 flashen. Lt. EEVblog sollte bspw. Ein PFS173 dasselbe Flashprotokoll haben, mit dem Unterschied, dass die Datenbitbreite 15 statt 14 Bits betraegt und eine hoehere Programmierspannung von Noeten ist. Versuche hierzu waren bisher leider erfolglos. Die hoehere Programmierspannung konnte problemlos eingestellt werden. Vielleicht hat hierzu jemand einen Tip fuer mich welche Gegebenheiten bei einem PFS173 zu beachten sind

• Kalibrierung des Systemtakts kann nicht vorgenommen werden, so dass man bedenken muss, dass es beim Takt zu einer Abweichung lt. Datenblatt von +- 2% kommen kann.

Viel Spass mit dem Arduino basierenden PFS154 Flashershield

R. Seelig im Corona-Dezember 2020