"Intelligenter" Textdisplayadapter mit Padauk PFS154

[Ralph S. (jjflash)]

Aus 2 Anlässen heraus entstand ein "intelligenter" Adapter für HD44780 
kompatible Textdisplay (wobei sich über "intelligent" trefflich streiten 
läßt).

1. Ein einfaches Displaymodul für das Steckbrett zu haben, das sich nur 
mit einer einzelnen Leitung steuern läßt (um den Kabelverhau deutlich zu 
verringern).
Natürlich kann man hier auch I2C-Displays verwenden, aber hier bedarf es 
dann wieder mehr oder weniger aufwändige Software im steuernden 
Controller

und

2. etwas mit dem Ultra-Low-Cost Controller PFS154 zu realisieren. Preis 
bei lcsc.com, Stand 23.10.2024 für PFS154-8 bei Abnahme von 50 Stück 
5,76 Cent, für den PFS154-16 bei Abnahme von 50 Stück 7,99 Cent

Der Displayadapter hat nur eine Eingangsdatenleitung auf der die 
Information über ein proprietäres 12-Bit PWM Protokoll übertragen wird. 
Der steuernde Microcontroller benötigt also nur - wie bereits erwähnt - 
eine einzelne Steuerleitung zum Ansprechen des Adapters.

Die "Intelligenz" bezieht sich darauf, dass dem Adapter keine 
Initialisierung und kein Beschreiben der Displayregister vorgegeben 
wird, dieses wird vom Adapter selbst erledigt.

Dem Adapter muß nur mitgeteilt werden, welches Zeichen ausgeben werden 
soll oder wohin die nächste Ausgabestelle positioniert wird.

Demoprogramme zur Verwendung des Adapters sind für STM8, AVR (ATmega, 
ATtiny) und PFS154 im Archiv enthalten.

Sämtliche Software ist unter Linux mit den Compilern AVR-GCC und SDCC, 
die Programme können mit einem einfachen Aufruf von < make > compiliert 
werden.

Und nein: Ich habe kein Demoprogramm für einen Arduino gemacht, aber 
vielleicht mache ich das noch (vielleicht).

Eine PCB die das ganze auf einem Steckbrett nutzbar macht ist bei JLCPCB 
schon in Auftrag.

Ein (unspektakuläres) Video mit einem Arduino-Nano kann man hier sehen:

https://www.youtube.com/watch?v=0BEhvig6jcs

Vom Zeitaufwand her war - wie fast immer - die Erstellung der 
Dokumentation länger als das eigentliche Schreiben der Software.

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

So, an die "Nörgler": gerne könnt ihr Eure Kommentare abgeben wie 
überflüssig das ist, was daran alles falsch ist etc. Auch negative 
Bewertungen freuen mich.

Für die Konstruktiven: Kritik nehm ich gerne an.

Und last but not least (ich hoffe ich setze mich da nicht in die 
Nesseln): Für denjenigen, der glaubhaft damit etwas anfangen will und 
einen Adapter aufbauen will, aber keinen PFS-Programmer hat, keinen 
aufbauen will (mit einem Arduino wäre das sehr einfach), dem schicke ich 
dann gerne in einem Briefchen einen programmierten PFS154 Controller.

Viel Spaß,

JJ

[Harald K. (kirnbichler)]

Ralph S. schrieb:
> Der Displayadapter hat nur eine Eingangsdatenleitung auf der die
> Information über ein proprietäres 12-Bit PWM Protokoll übertragen wird.

Warum nicht eine normale UART-Übertragung verwenden? Das ist auf der 
Seite derer, die so ein Display ansteuern wollen, um Größenordnungen 
einfacher zu handhaben als dieses Protokoll hier, und auch das braucht 
nur eine Leitung zwischen µC und Deinem Displaycontroller.

Sonst ist die Idee schick, keine Frage.

[Ralph S. (jjflash)]

Harald K. schrieb:
> Warum nicht eine normale UART-Übertragung verwenden?

Sehr gute Frage, denn in der Tat wollte ich zuerst UART verwenden. Da 
ich aber mindestens 12 Bits zur Steuerung benötige wären über UART 2 
Übertragungen notwendig gewesen. Das führt beim PFS154 bisweilen zu 
Problemen, da der PFS154 kein Hardware-UART besitzt. Eine Software-UART 
konnte ich nur bis zu einer max. Baudrate von 19200 bei 8 MHz Coretakt 
realisieren (was natürlich für den Displayadapter ausgereicht hätte).

Nun hätte man die 2-Byte Aufteilung natürlich so realisieren können, 
dass das erste Byte das Kommando und das zweite Byte der Value ist. Wenn 
er davon aber eines "verschluckt" kommt der Adapter durcheinander (wobei 
mir gerade die Idee kommt, das höchstwertigste Bit als 
Unterscheidungsbit zwischen Value und Kommando zu nehmen und das Value 
auf einen Zahlenwert bis max. 127 zu begrenzen, was ausreichend wäre, 
weil die Textdisplay zumindest für europäische Zeichen nur die unteren 7 
Bits nutzen)).

Zudem (ich gebe es zu) hatte ich es mir dann leicht gemacht und aus 
einem bestehenden Projekt welches 32-Bit übertragen mußte, das Protokoll 
einfach auf 12 abgeändert.

Harald K. schrieb:
> Das ist auf der
> Seite derer, die so ein Display ansteuern wollen, um Größenordnungen
> einfacher zu handhaben als dieses Protokoll hier

Aus diesem Grund habe ich für STM8, AVR, und PFS "Libraries" (stxlcd.c / 
stxlcd.h) geschrieben, um mit dem Protokoll gar nicht erst in Kontakt 
treten zu müssen.

Aaaaaaaber: ich versuche mich noch einmal an einer UART-Übertragung, 
denn du hast in einem Punkt (den ich mal unterstelle) Recht: Bei einem 
UART-Protokoll könnte man dann auf stxlcd verzichten.

[Frank M. (ukw) (Moderator)]

Ralph S. schrieb:
> Da ich aber mindestens 12 Bits zur Steuerung benötige wären über UART 2
> Übertragungen notwendig gewesen.

Das kann man optimieren. Wenn Du sowieso das oberste Bit als 
Unterscheidung zwischen Kommando und auszugebendem Zeichen verwendest, 
könnte man auch mehrere Zeichen hintereinander senden ohne jedesmal das 
Kommando zu senden. Du musst nur nach jeder Ausgabe eines Zeichens den 
"virtuellen Cursor", also die Spalte um 1 inkrementieren. Dann weisst 
Du, dass das nächste Zeichen dahinter kommt.

[Ralph S. (jjflash)]

Frank M. schrieb:
> Das kann man optimieren. Wenn Du sowieso das oberste Bit als
> Unterscheidung zwischen Kommando und auszugebendem Zeichen verwendest,
> könnte man auch mehrere Zeichen hintereinander senden ohne jedesmal das
> Kommando zu senden. Du musst nur nach jeder Ausgabe eines Zeichens den
> "virtuellen Cursor", also die Spalte um 1 inkrementieren. Dann weisst
> Du, dass das nächste Zeichen dahinter kommt.

Bin ich gerade dabei, auch die Baudrate am PFS154 konnte ich steigern, 
aber ich denke bei 57600 Bd (soll es zuverlässig sein), ist Schluss.

:-)  was für eine Fummelei

[Ralph S. (jjflash)]

... allerdings stellt sich mir gerade die Frage:

Wenn ich einen Controller habe, der bereits über den UART kommuniziert 
oder über einen seriellen Bootloader mit Firmware gefüttert wird und nur 
einen Hardware-Uart hat, dann muß ich auch wieder einen Software-Uart 
für diesen Controller einbinden und dann ist es egal, ob man das mit 
meinem proprietären oder einem UART-Protokoll realisiert.

:-) aber jetzt habe ich angefangen mit UART und jetzt schau ich mal wie 
lange das dauert.

Auf das in Arbeit befindliche PCB hat das jedenfalls keinen Einfluß, 
weil der Eingangspin am PFS frei wählbar ist und der an interner 
Peripherie sowieso fast nichts hat (eigentlich eine komische 
Wortschöpfung: Peripherie = außen ?).

[Michael B. (laberkopp)]

Ralph S. schrieb:
> Sämtliche Software ist unter Linux

Was ist denn deine aktuelle Programmierumgebung für den PFS, auch unter 
Linux ?

Das war zu seinem Erscheinen ja nicht verfügbar.

Sieht nach C aus, aber

Ralph S. schrieb:
> konnte ich nur bis zu einer max. Baudrate von 19200 bei 8 MHz Coretakt

ging noch in C oder brauchte Assembler ? Irgendwie sind zig Dateien in 
deinem ZIP.


Harald K. schrieb:
> Warum nicht eine normale UART-Übertragung verwenden

Eindeutig, und sogar ein normales Protokoll, mit Steuerzeichen (CR: x 
pos 0, LF: y pos +1, FF: y pos 0, HT x pos +2, BS: x pos-1, SO cursor 
blinken, SI cursor aus). Dann könnte das als Terminal für fast jeden 
dienen.

[Stephan S. (uxdx)]

mit einem UART wäre so ein Display mit 2 oder 4 Zeilen ideal als Anzeige 
für einen "Headless"-Server: Raspi, NAS & Co. Ich habe dafür bisher ein 
ESP32-C3 mit Micropython und lcd_i2c genutzt 
https://github.com/brainelectronics/micropython-i2c-lcd

[Harald A. (embedded)]

PIC16F15213 für 35ct oder LPC824 für 80ct hätten UART, wobei die sogar 
aufgrund ihres internen kalibrierten Oszillators ohne Quarz auskommen. 
Oder noch billiger PY32F002 für 15ct, braucht aber AFAIK einen Quarz 
(bei UART Betrieb). Der letztgenannte kann vermutlich nebenbei noch 
Bitcoin-Mining betreiben (fast). Der Puya ist übrigens auch 5V-tauglich.
Das Kontrast-Poti kann man noch mit einem Portpin ersetzen, der zwischen 
Hi-Z und Low wechselt.

[J. S. (jojos)]

Wäre wäre Fahrradkette...
Ich würde auch einen anderen Controller nehmen wenn es mir auf das 
Gerätchen ankommt, aber es geht doch genau darum sich mit dem Padauk zu 
beschäftigen und damit auch eine halbwegs praktische Anwendung und ein 
paar Code Snippets für die Sammlung zu bekommen.
Wenn man so ein minimal Terminal braucht ist sicherlich auch ein 
überdimensionierter ESP oder RP2040 kein Ding für das man erst das 
Weihnachtsgeld abwarten muss.
Also einfach ein brauchbares Miniprojekt mit Lehrwert würde ich sagen.

[Ralph S. (jjflash)]

Michael B. schrieb:
> Was ist denn deine aktuelle Programmierumgebung für den PFS, auch unter
> Linux ?

Hallo Michael, meine Umgebung ist ein Slackware-Linux, als Toolchain für 
den PFS154 verwende ich SDCC 4.1 (auch wenn es mittlerweile eine höhere 
Version gibt, die sollten aber wohl weiterhin den PFS154 können).

Michael B. schrieb:
> Sieht nach C aus, aber
>
> Ralph S. schrieb:
>> konnte ich nur bis zu einer max. Baudrate von 19200 bei 8 MHz Coretakt
>
> ging noch in C oder brauchte Assembler ? Irgendwie sind zig Dateien in
> deinem ZIP.

Das ist reines C.

Momentan funktioniert die Baudrate auch noch mit 57600 Bd (unter C). :-) 
mit Eiswürfel und mit Fön bearbeitet funktioniert die Übertragung noch 
zuverlässig und stabil.

Stimmt, in meinem ZIP sind viele Dateien enthalten, eben die 
verschiedenen Projektordner für STM8 und AVR als Sender sovie PFS154 als 
Sender und Empfänger. Eine IDE verwende ich nicht, das ist alles ein 
reines "Makefile-Projekt", die Dateien nur mit Texteditor erstellt 
(sogar in der Konsole). In den jeweiligen Unterverzeichnissen sind alle 
Dateien enthalten, damit ein einfaches Make zum Builden genügt. Siehe 
auch das PDF-File.

Einen Fehler habe ich auch schon gefunden, der beim setzen von 
benutzerdefinierten Zeichen auftritt und werde das natürlich 
korrigieren.

Michael B. schrieb:
> Eindeutig, und sogar ein normales Protokoll, mit Steuerzeichen (CR: x
> pos 0, LF: y pos +1, FF: y pos 0, HT x pos +2, BS: x pos-1, SO cursor
> blinken, SI cursor aus). Dann könnte das als Terminal für fast jeden
> dienen.

Das wäre natürlich möglich, das Cursorblinken habe ich abgestellt, ist 
aber nicht das Problem, das ein- ausschaltbar zu machen.

Harald A. schrieb:
> PIC16F15213 für 35ct oder LPC824 für 80ct hätten UART, wobei die sogar
> aufgrund ihres internen kalibrierten Oszillators ohne Quarz auskommen.

:-) mir ging es ja darum, das mit dem billigstmöglichen zu machen. 
Außerdem (sorry), ich mag die PIC's einfach nicht und ich habe keinen 
neueren Programmer hierfür, ich bin bei PicKit 2 stehen geblieben.

Harald A. schrieb:
> Oder noch billiger PY32F002 für 15ct,

den habe ich mir zumindest von den (spärlichen) Dokumentationen schon 
angesehen, aber ich habe mich damit noch nicht intensiver beschäftigt. 
Hier weiß ich z.Bsp. nicht, ob der mit meinen Tools zu flashen ist. Zur 
Verfügung habe ich ein Seeger JTAG/ST-Link, einen originalen ST-Link und 
China-Clone ST-Link. Weißt du da genaueres wie der zu flashen ist und 
vor allem weißt du hier etwas über einen eventuellen Abstraction-Layer 
für arm-none-eabi-gcc ?

Harald A. schrieb:
> Das Kontrast-Poti kann man noch mit einem Portpin ersetzen, der zwischen
> Hi-Z und Low wechselt.

Das habe ich mir überlegt und werde ich vllt. auch noch machen. 
Ursprünglich dachte ich, dass mir ein Timerinterrupt beim PFS mein 
Timing zerstört aber dann hab ich mich daran erinnert, dass der Timer 
doch tatsächlich PWM kann (also hat der PFS dann doch noch ein bisschen 
Peripherie an Bord). Hi-Z kann der aber beim PWM nicht.

[Harald A. (embedded)]

Ralph S. schrieb:
> > :-) mir ging es ja darum, das mit dem billigstmöglichen zu machen.
> Außerdem (sorry), ich mag die PIC's einfach nicht und ich habe keinen
> neueren Programmer hierfür, ich bin bei PicKit 2 stehen geblieben.

Ja, alles gut, mein Beitrag nur als ganz allgemeine Anregung. Ich hatte 
mir den Padauk auch mehrfach angesehen und wollte damit mal loslegen, 
wusste aber nicht so recht was ich damit tun könnte.

> Harald A. schrieb:
>> Oder noch billiger PY32F002 für 15ct,
>
> den habe ich mir zumindest von den (spärlichen) Dokumentationen schon
> angesehen, aber ich habe mich damit noch nicht intensiver beschäftigt.
> Hier weiß ich z.Bsp. nicht, ob der mit meinen Tools zu flashen ist.

Englische Doku (sieht sehr komplett aus) auf py32.org
Hier hat man sich intensiv damit beschäftigt, sogar Patches für die 
STM32 IDE
https://www.eevblog.com/forum/microcontrollers/$0-11-py32f002a-m0-24mhz-320kb-actually-324kb-more-peripherals/

> Hi-Z kann der aber beim PWM nicht.
Das ist leider eine sehr seltene Spezies. Vlt. kann man einfach mit 
einem 1ms oder 100us Timer selber anlegen, der Filter kann es ja 
glätten.

[Ralph S. (jjflash)]

Harald A. schrieb:
> Ich hatte
> mir den Padauk auch mehrfach angesehen und wollte damit mal loslegen,
> wusste aber nicht so recht was ich damit tun könnte.

Vieles was man mit einem 8-Bit Controller halt machen kann:

- Resetcontroller für STM32F Series
- Thermometer mit NTC, Genauigkeit +- 0,7°C
- LED VU-Meter
- Treiber für 4 Digit 7-Segmentanzeige Auch wenn ich hier dafür verissen 
wurde weil ich die LED's direkt an den PFS gehängt habe und es den 
Leuten hier zu dunkel war. Ich habe hier allerdings niemanden gesehen 
der auf die Anzeige geschaut hat. Ich habs dann doch mit 
Treibertransistoren abgeändert
- LED Spielzeuge in sehr klein
- UKW-Radio mit RDA5807 und Tasten, Sendersuchlauf und charliegeplexten 
Leuchtdioden als Anzeige
- Melodyplayer (allerdings natürlich Töne nur aus Rechtecksignalen und 
monophon)

Allerdings gebe ich dir recht, die Möglichkeiten sind begrenzt und 
insbesondere verhält sich der Chip ziemlich zickig. In der Schaltung den 
Chip zu flashen gestaltet sich auch als schwierig (und ich warte auf 
eine PCB von JLCPCB der den EasyPdkProgrammer als Basis hat und von dem 
ich mir erhoffe dass sich die Handhabung erleichtert - momentan hantiere 
ich mit meinem selbstgestrickten Programmer auf Arduino-Uno 
Hardwarebasis)

Harald A. schrieb:
> Englische Doku (sieht sehr komplett aus) auf py32.org
> Hier hat man sich intensiv damit beschäftigt, sogar Patches für die
> STM32 IDE

Hast du dich selbst mit dem schon beschäftigt? Ich mag auch an sich die 
aufgeblähten IDE's nicht, ich bin halt alt und mag das sehr klassisch 
mit Texteditor und Makefile

Ansonsten:

@laberkopp und uxdx

ich hab das jetzt tatsächlich auf UART auch noch gestrickt, allerdings 
mit einigen Fallstricken:

- ich benötige zwischen gesendeten Bytes Wartezeiten. Das ist einmal der 
Soft-UART geschuldet, zum anderen den Zeiten die das Display (bspw. bei 
der Initialisierung) braucht.

- erst dachte ich, dass alles funktioniert. Sendender Controller war ein 
STM8 geflasht mit ST-Link Adapter. Benutzt wurde hier der Hardware-UART. 
Dann so dachte ich, das ganze schnell auf AVR portiert (Arduino-Nano) 
und hier dann Software-UART benutzen, weil Hardware-UART durch 
Bootloader belegt... und natürlich gehts nicht! Also den Nano über ISP 
flashen und Hardware-UART benutzen. Funktioniert! Also schön lange am 
Software-UART fummeln (den ich lange nicht benutzt habe und der auch zu 
großen Teilen nicht von mir ist).

Summasummarum: Bis zu einer Baudrate von 9600 Bd funktioniert das auch 
mit Software-UART gut (und natürlich wieder den Eiswürfel- und Föntest 
gemacht).

@laberkopp : Die Idee die Steuercodes eines Terminals mit einzupflegen 
habe ich aufgenommen und implementiert (wobei ich eine Stunde wegen 
eines doofen Fehlers beim Cursor an- und ausschalten verplempert habe). 
Aber funktioniert.

Wenn ich den Code etwas aufgeräumt habe, werde ich die UART-Version auch 
einstellen,
oder

@Moderatoren: hierfür dann einen neuen Thread ?

und zu guter letzt brauchts noch etwas für die Nörgler: Ja, ich habe das 
auf dem Steckbrett aufgebaut (siehe Bild).

[Harald A. (embedded)]

Ralph S. schrieb:
> Vieles was man mit einem 8-Bit Controller halt machen kann:
Schöne Projekte, Respekt. Ich meinte, was ICH damit in meinem Kontext 
tun kann. Für meine Sachen hatte der dann doch hier und da zu wenig 
Peripherie. Ich mag z.B. keine in SW nachgebildeten UARTs, habe ich 
schon gemacht, will ich aber in diesen Tagen nicht mehr. So um 2000 rum 
sah das anders aus.
>
> Hast du dich selbst mit dem schon beschäftigt? Ich mag auch an sich die
> aufgeblähten IDE's nicht, ich bin halt alt und mag das sehr klassisch
> mit Texteditor und Makefile

Bisher nur theoretisch, werde mir aber demnächst mal ein Evalboard 
bestellen oder eines machen. Mit der STM32 IDE bin ich hochzufrieden, 
Makefiles mochte ich noch nie. Ja, muss man sich nur mal reinfuchsen, 
früher schon zwangsweise gemacht. Kann man machen, will ich aber nicht 
mehr (s.o.) Die IDE macht das übrigens sehr gut und ist auch ausreichend 
performant. Ja, belegt hunderte MBs auf der Platte, mir egal. Gleiches 
gilt für die NXP IDE. Geht ebenfalls sehr gut. Eclipse bietet echt feine 
Features, suchen und ersetzen, Fehlersuche, integrierter Debugger, 
Livewatch Variablen etc. pp

[Crazy Harry (crazy_h)]

Sehr schönes Projekt. I2C wäre aber auch eine Option. Ja ein Pin mehr, 
aber bei frei wählbarer Adresse endlich mal mehrere Displays an einem 
Master 🙂. Das Displayinit macht dein Adapter natürlich selber, der 
Master muß sich darum nicht kümmern. Evtl. via I2C einstellbaren 
Kontrast und Hintergrundbeleuchtung.

[Ralph S. (jjflash)]

so, Wochenende ist vorrüber (leider) und natürlich haben mir die 
Vorschläge keine Ruhe gelassen und habe das ganze überarbeitet. 
Irgendwie muß ich Brötchen verdienen und kann mich dieser Geschichte 
hier nicht weiter so widmen wie ich das gerne machen möchte

Jetzt gibt es 2 Versionen des Textdisplaysadapters, einmal mit der 
PWM-Übertragung und einmal mit UART.

Bei der Implementierung (wie von laberkopp vorgeschlagen) gabs dann ein 
paar "böse" Überraschungen für mich und so ganz als Terminal ist das mit 
ein paar Einschränkungen nutzbar. Hier hat mir das Steuerzeichen für 
einen Linefeed \n etwas Kopfzerbrechen bereitet, weil ich im 
Hardwarelayout keine Leitung für das Auslesen des Displays vorgesehen 
hatte (schöner Fehler zum Nachbauen) und ich soetwas wie einen 
Framebuffer für eine Zeile einrichten mußte. Hier ging mir dann das RAM 
des PFS154 aus.

Außerdem benötigt es eine gewisse Zeit bis das abgearbeitet ist und von 
daher muß nach dem Senden eines Zeichens 3 Gedenkmillisekunden eingelegt 
werden.

Damit man mit dem ganzen einfach hantieren kann habe ich mein 
abgespecktes Printf für diesen Adapter überarbeitet und ihm ein paar 
neue Steuerzeichen hinzugefügt, so dass prinzipiell eine Steuerung des 
Adapters einzig mit diesem speziellen Printf machbar ist (auch wenn der 
String innerhalb des Printf dann bisweilen etwas kryptisch anmuten 
kann).

Schade dass ich jetzt keine Zeit mehr habe um das ganze zu 
dokumentieren, was aber die Tage geschehen wird und dann werde ich die 
ganze Soße hier einstellen.

Habt eine schöne Woche,

JJ

PS: jetzt hat es ja doch endlich einige Negativbewertungen gegeben, 
nicht nur bei mir! :-) ich freu mich !

[Ralph S. (jjflash)]

Crazy Harry schrieb:
> I2C wäre aber auch eine Option. Ja ein Pin mehr,
> aber bei frei wählbarer Adresse endlich mal mehrere Displays an einem
> Master 🙂. Das Displayinit macht dein Adapter natürlich selber, der
> Master muß sich darum nicht kümmern.

Na ja, das ganze gibt es ja schon fix und fertig mit PCF8574 (der 
allerdings nur die Steuerbefehle des Masters umsetzt).

Crazy Harry schrieb:
> Evtl. via I2C einstellbaren
> Kontrast und Hintergrundbeleuchtung.

werde ich versuchen wie und ob das funktionieren kann. Den Hardware PWM 
des PFS154 habe ich ja noch frei !

[Ralph S. (jjflash)]

so, ich habe (vorerst) fertig und die Anmerkungen hier aufgenommen. 
Wirklich richtig zufrieden bin ich noch nicht aber ich bin (wirklich 
ohne Eigenlob) fasziniert davon, was mit dem kleinen PFS154 realisierbar 
ist.

Vorerst funktioniert der Textdisplayadapter mit 8x2 und 16x2 Zeichen 
Displays. Irgendwann (aber nicht so schnell) werde ich versuchen, das 
auch auf ein 4-zeiliges Display zu erweitern, momentan jedoch ist die 
Software für 2 zeilige Displays ausgelegt.

Harald K. schrieb:
> Warum nicht eine normale UART-Übertragung verwenden? Das ist auf der
> Seite derer, die so ein Display ansteuern wollen, um Größenordnungen
> einfacher zu handhaben als dieses Protokoll hier, und auch das braucht
> nur eine Leitung zwischen µC und Deinem Displaycontroller.

Den Adapter gibt es jetzt in 2 Versionen, eine mittels der bereits 
vorgestellten Impulsmethode (PWM) und eben eine mit UART-Übertragung.

:-) allerdings: mit der im Archiv vorhandenen *.c / *.h Software zum 
Ansprechen des Adapters besteht an sich kein Unterschied in der 
Handhabung.

Frank M. schrieb:
> Du musst nur nach jeder Ausgabe eines Zeichens den
> "virtuellen Cursor", also die Spalte um 1 inkrementieren.

:-) das war gar nicht notwendig, weil das das Display von ganz alleine 
macht.

Michael B. schrieb:
> Harald K. schrieb:
>> Warum nicht eine normale UART-Übertragung verwenden
>
> Eindeutig, und sogar ein normales Protokoll, mit Steuerzeichen (CR: x
> pos 0, LF: y pos +1, FF: y pos 0, HT x pos +2, BS: x pos-1, SO cursor
> blinken, SI cursor aus). Dann könnte das als Terminal für fast jeden
> dienen.

Habe ich jetzt implementiert. Grundsätzlich funktioniert das alles. Um 
noch gut damit "arbeiten" zu können, habe ich die 
Übertragungsgeschwindigkeit auf 9600 Bd festgelegt.

Allerdings habe ich Änderungen an deinen Empfehlungen vorgenommen:

Für einen Tabulatorstop genügt es nicht, einfach die X-Position um 2 zu 
erhöhen, von daher habe ich einen Tabulatorstop so implementiert, dass 
er auf jedes 4 Zeichen des Displays setzt (die x markieren den 
Tabulatorstop):

....x...x...x...

Den LineFeed habe ich implementiert, jedoch macht er die ganze Sache 
etwas langsam. Befindet sich der aktuelle Cursor bereits in der zweiten 
Zeile, wird die zweite Zeile in die erste kopiert bei Beibehalten der 
x-Position. Da dieser Vorgang dauert, darf nach einem LF erst nach 12 
Millisekunden wieder ein Zeichen gesendet werden (ansonsten nach 2 
Millisekunden).

Dieses muß die Software die den Adapter steuert berücksichtigen (und 
nach dem Senden eines Zeichens eine entsprechende Pause einlegen). 
Schließe ich den Adapter über einen USB2UART Bridge an, funktioniert das 
Ganze natürlich.

Es sind also alle von dir vorgeschlagenen Steuerzeichen \n \r \t \b 
eingefügt. Mit dem Senden von SO (Code 0x0e) und SI (Code 0x0f) wird der 
Cursor an/ausgeschaltet.

Stephan S. schrieb:
> mit einem UART wäre so ein Display mit 2 oder 4 Zeilen ideal als Anzeige
> für einen "Headless"-Server: Raspi, NAS & Co.

Wenn du beim Senden der Zeichen die oben erwähnten Pausen einlegst, 
sollte das kein Problem sein.

Um mit dem Adapter "arbeiten" zu können habe ich *.h / *.c Quelldateien 
geschrieben, die den Adapter ansteuern. Unterstützt werden die 
Quelldateien für PFS154, AVR, STM8 und STM32F0xx (dieser in Verbindung 
mit libopencm3).

Eine der wichtigsten Funktionen zum Ansteuern des Adapters habe ich

stxt_printf

genannt.

Diese ist zum einen eine abgespeckte Version eines printf, vor allem 
durch das Weglassen einer float-Ausgabe, die durch eine Ausgabe einer 
"Pseudofestkommazahl" ersetzt wurde.

  void stxt_printf(const uint8_t *s,...);
      Platzhalterfunktionen:

          %s     : Ausgabe Textstring
          %d     : dezimale Ausgabe
          %x     : hexadezimale Ausgabe
                   ist Wert > 0xff erfolgt 4-stellige Ausgabe
                   is Wert <= 0xff erfolgt 2-stellige Ausgabe
          %k     : Integerausgabe als Pseudokommazahl 12345 wird als 123.45
                   ausgegeben (globale Variable printfkomma bestimmt die 
                   Position des Kommas, hier = 2)
          %c     : Ausgabe als Asciizeichen
          %p     : setze X-Position
          %P     : setze Y-Position
          %l     : loesche aktuelle Zeile und gehe zu x-Position 1

Beispiel:

stxt_printf("%P%l",2);    // gehe zu Zeile 2 und lösche diese
stxt_printf("%P%l",1);    // gehe zu Zeile 1 und lösche diese, Ausgabeposition
        // ist jetzt 1,1 (links oben)
stx_printf("Hallo\n\rWelt");  // in der ersten Zeile erscheint "Hallo", dann
                                // erfolgt ein linefeed \n gefolgt von einem  
                                // carriage return und in der zweiten Zeile
                                // erscheint "Welt"

Mann kann das natürlich auch in einer Zeile schreiben, was das ganze jedoch etwas "kryptisch" macht:

stxt_printf("%P%l%P%lHallo\n\r\Welt",2,1);

printfkomma= 3;
stxt_printf(Wert=%k",-3141);

wird als 3.141 ausgegeben.

Harald A. schrieb:
> Das Kontrast-Poti kann man noch mit einem Portpin ersetzen, der zwischen
> Hi-Z und Low wechselt.

Hab ich gemacht, es wird aber noch ein passiver Tiefpassfilter 
notwendig, 1K-Ohm zu 4.7µF lassen das Display ruhig aussehen.

Michael B. schrieb:
> Irgendwie sind zig Dateien in
> deinem ZIP.

Es sind jetzt eher noch mehr geworden, weil in jedem Ordner auch das 
Setup für die unterschiedlichen Familien enthalten sind, damit ein 
einfacher Makeaufruf reicht. Im Anhang des PDF-Files habe ich die 
Verzeichnisstruktur und die Dateien die darin enthalten sind 
aufgedröselt.

[Harald A. (embedded)]

Ist der interne Takt des Padauks denn so gut dass es für UART reicht?

[Ralph S. (jjflash)]

Harald A. schrieb:
> Ist der interne Takt des Padauks denn so gut dass es für UART
> reicht?

Versuche ausserhalb des Textadapters hier haben noch funktionierende
Verbindungen bis 57600 Bd zustande gebracht. In Verbindung mit dem
Textadapter hier gab es andere "Schwierigkeiten", weshalb ich auf 9600
Bd nach unten gegangen bin (was angesichts der wenigen Daten die
versendet werden zu verschmerzen ist).

:-) und jetzt kommt mein "Basteltrieb" zum Vorschein: Mit Eiswürfel im
Plastikbeutel habe ich den Chip "gekühlt" und mit Fön erwärmt.
Funktionierte noch.

"Friere" ich den PFS mittels Kältespray ein, bleibt er stehen (ich weiß
nicht wie kalt genau das da geworden ist. Müßte ich Temp.-Sensor
anbringen).

Das Soft-Uart für den PFS154 habe ich schon (ich gebs zu) relativ
"Stümperhaft" realisiert, weil mir der Speicherplatz für
Timerinterruptgesteuerte UART nicht reicht (zudem "spinnt" der
Pin-Change in Verbindung mit Timerinterrupt, hier muß ich noch genauer
lesen wo ich meinen Fehler begehe).

Das Problem hier ist, dass der PFS154 nur einen einzigen Interruptvektor
hat, über den gepollt werden muß, wer den Interrupt ausgelöst hat. Da
hakt es noch etwas.
Am liebsten hätte ich eine Softuart die eben über den Timer- und
Pinchange-Interrupt in einen Puffer einliest. Dann könnten die
Wartezeiten zwischen den einzelnen Zeichen verschwinden. Ob der mickrige
RAM von 128 Byte dafür reicht, weiß ich nicht.

Für den Adapter hat der Codeschnipsel im Anhang gereicht, allerdings bin
ich nicht so wirklich stolz darauf, weil ich weiß, dass man das besser
machen kann, aber wie gesagt: Für den Adapter hats gereicht, außerdem
ist das in den Quelldateien im Archiv so auch ersichtlich.

Ich hatte auch mit dem - inoffiziellen - 16 MHz Modus Vesuche
angestellt, aber damit läuft der Chip relativ schnell instabil, wenn die
Versorgungsspannung nicht wirklich super ist ==> deshalb nur 8 MHz
Coretakt (nicht nur bei Verwendung mit UART).

Und zum Ansehen (leider habe ich das jetzt im Querformat auf die
Schnelle mit dem Handy gemacht) ein Youtube-Video mit PFS154 (und
Softuart 9600 Bd) und STM8S103

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

[Harald A. (embedded)]

Die Höhe der Baudrate ist ja letztendlich egal, da die prozentuale 
Abweichung der Taktfrequenzen ja immer eingeht. Könnte man nicht jedes 
Kommando z.B. mit einem 0x00 losgehen lassen, welches man dann per Timer 
vermisst? Weiß nicht, ob der Platz dafür noch da wäre. Zur 
Synchronisation könnte man eine Mindestpause zwischen den Befehlen 
definieren, damit man eindeutig die Sync-Marke am Anfang rausfinden 
kann. Oder alle paar Sekunden ein einzelnes 0x00 senden, dann weiß der 
Controller, das diese Marke zur Vermessung der Baudrate dient.

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

Während der Padauk ein Controller der jüngeren Technikgeschichte ist, 
gibt es für  Alphanumerische Display a la HD44780 auch Projekte älteren 
Datums.

So hat der Forums-Admin himself, Andreas, vor 20 Jahren eine Ansteuerung 
für den PC-Parallelport veröffentlicht (ja, bei neuen PC's 
ausgestorben).

https://www.mikrocontroller.net/articles/LCD_an_Parallelport

Als "tricky" gilt lediglich da timing der Init-Phase des displays, die 
Darstellung der Zeichen kann anhand des Datenblattes nach ASCII-Code 
simple runtergeschrieben werden.

Da noch ältere threads zu Detailfragen:
* Beitrag "LCD (HD44780) Cursor Position wechseln"
* https://www.mikrocontroller.net/attachment/210879/lcd_doku.pdf

[Ralph S. (jjflash)]

Bradward B. schrieb:
> So hat der Forums-Admin himself, Andreas, vor 20 Jahren eine Ansteuerung
> für den PC-Parallelport veröffentlicht (ja, bei neuen PC's
> ausgestorben).
>
> https://www.mikrocontroller.net/articles/LCD_an_Parallelport

Wie Andreas habe ich das vor 30 Jahren auch gemacht, zuerst am 
Parallelport und dann über Schieberegister HEF4094 und den 
Steuersignalen eines COM-Ports den es ja nicht mehr gibt.

Mit dem COM-Port hatte es dann auch noch mit Windows 2000 geklappt 
(Windows mache ich schon lange nicht mehr).

Lustig ist, dass die Displays ja immer noch verwendet werden und hier 
ging es ja darum, das Display für Versuche und/oder zum Anschluß an 
einen anderen Mikrocontroller zu verwenden.

[Crazy Harry (crazy_h)]

Früher gab es zig Programme für die verschiedensten Displays (auch 
grafische mit T6963 320x240 Pixel) für eine Parallelportansteuerung. 
Darauf konnte man dann z.B. Festplattenbelegung, CPU-Last, Up-/Download 
Speed und Menge und noch vieles mehr anzeigen.

[Ralph S. (jjflash)]

:-) kenn ich selbst alles noch von "viiiiiel früher". Aber allen ist 
gemein (zumindest auf deinen Fotos, dass diese mit einem HD44780 
kompatiblen Controller bedient wurden.

[Crazy Harry (crazy_h)]

Richtig, ein Foto von meinem T6963 hatte nicht greifbar, bis jetzt 🙂

[Ralph S. (jjflash)]

lachen muß (sorry): damals war Case-Modding derart in, dass es (für 
mich) schon zu arg war.

Heute ... muß es ein Notebook sein, so klein, so schlank, so 
leistungsstark und ausdauernd ohne Steckdose.

ähem... :-) was hat das mit dem Displayadapter und so zu tun ?

(aber danke für die Bilder, ich sehe so etwas immer wieder gerne. Vllt. 
solltest du, wenn du mehr davon hast, so etwas bei den Kunstwerken 
einstellen ?!?)

[Crazy Harry (crazy_h)]

Ok gewonnen 🙂 aber ich wollte widerlegen, daß es nur mit HD44780 geht.

Das was du da gemacht hast, habe ich mal für grafische Displays über I²C 
gemacht.

[Ralph S. (jjflash)]

:-) ich wußte nicht, dass es ums gewinnen geht!

Super schöne Arbeit. Für mich bin ich am Überlegen, auf einem farbigen 
128x128 ebenfalls einen graphischen Displayadapter zu machen. 
Grundsätzlich stellt sich mir das "Problem", welche Funktionen (außer 
Text) dieses Display haben soll.

Eine Bitmapübertragung hattest du nicht realisiert, oder ? Bin ich am 
Grübeln, ob einfache Funktionen für putpixel, line, circle und rectangle 
reichen.

Und richtig schön: das ganze in Pascal. Welchen Controller hast du 
verwendet (ich liebäugel hier mit einem STM32F030) und absolutes 
Interesse (weil eigentlich ein Pascal/Delphi Fan): Welches Pascal hast 
du hier verwendet (Freepascal an Controller angepasst ?)

[Crazy Harry (crazy_h)]

Ralph S. schrieb:
> :-) ich wußte nicht, dass es ums gewinnen geht!

Ich meinte das im Sinne von "ja hat nichts mit deinem Adapter zu tun".

Ich habe einen Mega32 @ 8MHz verwendet. Die Bitmaps sind alle schon dort 
vorhanden und können ja, je nach Verwendungszweck, angepaßt werden. 
Gemacht wurde das, um ein grafisches Display mit einem kleinen 
Controller ansteuern zu können. Programmiert in AVRCo-Pascal.
Inzwischen hab ich auch noch ein 320x240 mit einem XMega256A3U @ 64MHz 
so am laufen. Dieses mal jedoch um den Hauptcontroller zu entlasten. Das 
ganze ist eine Art Monitoring von Netzwerkkomponenten. uC1 pingt 
Switche, Router und Steuerungen an und sendet das Ergebnis an uC2. Der 
bereitet das grafisch auf und steuert das Display an. Leider wurde die 
Schaltung nie praktisch eingesetzt und so baute ich später eine 
Schaltung draus, die die Abgastemperatur meiner Heizung mitloggt.

[Frank M. (ukw) (Moderator)]

@Crazy Harry: Wenn Du Dein(e) Projekte vorstellen möchtest, mache das 
bitte in einem gesonderten Thread.

Hier ist das Thema "Textdisplayadapter mit Padauk PFS154". Da passen 
Deine Beiträge und Deine Bilder nicht rein, da sie nicht zum Thema 
passen. Sie stören auch den Lesefluss, wenn man sich über den 
Textdisplayadapter informieren möchte.

[Crazy Harry (crazy_h)]

Ich stelle nichts vor, ich unterhalte mich mit Ralph über das was man 
machen kann. Du kannst meine Posts gerne löschen. Dann aber bitte ALLE 
2765.

[Frank M. (ukw) (Moderator)]

Crazy Harry schrieb:
> ich unterhalte mich mit Ralph über das was man machen kann

Auch dafür könnte man durchaus einen gesonderten Thread aufmachen. Hier 
im Subforum "Projekte und Code" sollte man schon näher beim Thema 
bleiben, da hier zuallererst Projekte vorgestellt werden. Wenn man 
später nach Textdisplay-Projekten recherchiert und dann nur 
Graphikdisplays findet, ist das einfach nur ärgerlich.

Ich wüsste nicht, wie man mit einem schwachbrünstigen PFS154 ein 
Graphikdisplay ansteuern könnte. Von daher halte ich Deine Begründung 
"ich unterhalte mich mit Ralph über das was man machen kann", für 
ziemlich weit hergeholt. Mit einem PFS154 kann man da jedenfalls 
nichts in der Richtung machen. Von daher ist das hier offtopic.

> Du kannst meine Posts gerne löschen. Dann aber bitte ALLE 2765.

Das ist kindisch.

[Ralph S. (jjflash)]

Nachdem ich auch endlich wieder Zugriff auf mein Github habe, habe ich 
das gesamte Projekt dort auch eingestellt.

https://github.com/jjflash65/pfs154_textdisplay_adapter

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

> Nachdem ich auch endlich wieder Zugriff auf mein Github habe, habe ich
> das gesamte Projekt dort auch eingestellt.
>
> https://github.com/jjflash65/pfs154_textdisplay_adapter

Da passt was nicht, die PDF-reader können das PDF nicht lesen.

[Ralph S. (jjflash)]

Bradward B. schrieb:
> Da passt was nicht, die PDF-reader können das PDF nicht lesen.

Oh, bedauerlich. Das PDF ist ein Export aus LibreOffice Writer. Habe ich 
mir jetzt angesehen mit Firefox, Chrome und Opera und sieht aus wie im 
Screenshot des Anhangs.

Das PDF ist dasselbe wie dieses, das hie eingstellt ist.

Welchen Browser verwendest du und vielen Dank für die Info.

PS: in der letzten Zeit habe ich auch Probleme mit einigen GitHub 
Repositories die PDF-Dateien anzuzeigen.

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

> Oh, bedauerlich. Das PDF ist ein Export aus LibreOffice Writer. Habe ich
> mir jetzt angesehen mit Firefox, Chrome und Opera und sieht aus wie im
> Screenshot des Anhangs.
>
> Das PDF ist dasselbe wie dieses, das hie eingstellt ist.

Das ( 
https://www.mikrocontroller.net/attachment/649567/textdisplayadapter.pdf 
) ich ohne Probleme aus dem Browser heraus öffnen.
>
> Welchen Browser verwendest du und vielen Dank für die Info.

Browser ist firefox 115.17.0esr (64 bit), lt. Info ... die aktuelle 
Version.

Runtergeladen als  .zip oder raw wird es ohne Meckern angezeigt.

> PS: in der letzten Zeit habe ich auch Probleme mit einigen GitHub
> Repositories die PDF-Dateien anzuzeigen.

Beim eigenen PDF-Export aus LibreOffice writer hatte ich mal Probleme, 
das PDF mit nicht standard Einstellung nicht angezeigt wurden. Scheint 
hier aber nicht das Problem zu sein,
ist wohl eher Git Hub ( 
https://github.com/jjflash65/pfs154_textdisplay_adapter/blob/main/textdisplayadapter_2.pdf 
)

[Mi N. (msx)]

Dein eingangs gewähltes 12 Bit Format finde ich besser als ein serielles 
8N1 Format, da das Timing viel einfacher zu erfüllen ist. Selbst wenn 
bei Deinem jetzigen Einzelstück die Temperaturschwankungen noch 
toleriert werden, wäre es blöd, wenn es irgendwann aus der Reihe tanzt.

Dein Programm habe ich mir nicht weiter angesehen und weiß daher nicht, 
inwieweit es noch Erweiterungen zuläßt. Elegant wäre aus meiner Sicht, 
den Kontrast und die Hintergrundbeleuchtung meinetwegen in ein paar 
festen Abstufungen einstellbar zu machen. Für die Beleuchtung wäre 
Ein-Aus schon mal zum Stromsparen geeigent. Die Kontrastspannung könnte 
auf 0,3 - 1 V begrenzt werden. Außerhalb dieses Bereiches zeigen die 
allermeisten Displays garnichts Lesbares an.

Auf Grund Deiner Anregungen habe ich mir den Controller etwas näher 
angesehen, werde aber wohl 'die Finger' davon lassen. Der günstige Preis 
lohnt erst bei richtigen Stückzahlen, beispielsweise, wenn jede Nadel 
vom Tannenbaum ganz individuell blinken soll ;-)
Aber Deine 'Spielerei' ist voll in Ordnung!

[Ralph S. (jjflash)]

Mi N. schrieb:
> Elegant wäre aus meiner Sicht,
> den Kontrast und die Hintergrundbeleuchtung meinetwegen in ein paar
> festen Abstufungen einstellbar zu machen.

Wäre an sich kein Problem, einzig: mit welchem Defaulwert würde 
gestartet werden? Ich habe hier unterschiedliche Displays ausprobiert 
und alle brauchen eine etwas andere Kontrastspannung.

Mi N. schrieb:
> Die Kontrastspannung könnte
> auf 0,3 - 1 V begrenzt werden. Außerhalb dieses Bereiches zeigen die
> allermeisten Displays garnichts Lesbares an.

Das könnte ich so integrieren, dass  0..255 einer Spannung von 0..1 Volt 
entspricht. Ich habe hier auch alte Polin-Displays 0802), die möchten 
bisweilen weniger als 0,3V. Mehr als 1 V will keines.

Mi N. schrieb:
> und die Hintergrundbeleuchtung meinetwegen in ein paar
> festen Abstufungen einstellbar zu machen.

Ist absolut machbar, der zweite PWM des PFS154 ist noch frei und kann 
dafür verwendet werden.

Mi N. schrieb:
> Auf Grund Deiner Anregungen habe ich mir den Controller etwas näher
> angesehen, werde aber wohl 'die Finger' davon lassen.

:-) wirklich "lohnen" tut sich der Aufwand nicht, den ich betrieben habe 
bis ich mit dem PFS154 umgehen konnte. Bisweilen stellt der sich 
ziemlich zickig an und dann hast du noch das Problem mit dem Programmer 
(egal ob das mein Eigenbauprogrammer als Arduino-Shield oder der 
EasyPdkProgrammer - eindeutig besser war).

Dadurch dass der Chip nur sehr schlecht in der Schaltung programmierbar 
ist, man manche Krücken mit Kabeln aus dem Programmer macht und den dann 
auf ein Steckbrett setzt => man hat da an mehreren Fronten gekämpft und 
es war eine Challenge bis da alles so klappt wie man sich das vorstellt.

Seit heute - endlich - habe ich einen Eigenbauprogrammer, der auf der 
des EasyPdkProgrammer basiert und der mir beim "Spielen" mit dem Chip 
fast meinen gewohnten Komfort gibt, den ich bei anderen Chips auch habe. 
Der Programmer selbst war eine Challenge (anderer Thread hier), weil das 
USB des Programmers einfach nicht gewollt hat. :-) jetzt aber doch.

Vielleicht stelle ich das Projekt mit dem Programmer hier ein 
(funktioniert jetzt wirklich tadellos).

Meine Toolchain und viele Beispiele zum PFS154 findest du auf meinem 
GitHub (allerdings nur für Linux).

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

Wenn du das komplette Verzeichnis auspackst hast du in dieser 
Verzeichnisstruktur dann auch schon den Compiler mit kopiert (nirgendwo 
verankert) um die Demoprogramme mittels "make" zu übersetzen. Dort 
findest du dann Sourcen für Verwendung der Timer, des Komparators, 
Softwareuart -i2c -spi. Demo für Text-LCD (wie das jetzige Projekt), 
7-Segmentanzeige und Bitbanging im allgemeinen

:-) vllt. kann ich dir den PFS154 doch noch schmackhaft machen ?!? Aus 
welchen Gründen auch immer habe ich mit dem irgendwie "mehr Spaß" als 
mit meiner neuen STM32F4 Platine mit Grafik-LCD.

Bradward B. schrieb:
> Beim eigenen PDF-Export aus LibreOffice writer hatte ich mal Probleme,
> das PDF mit nicht standard Einstellung nicht angezeigt wurden. Scheint
> hier aber nicht das Problem zu sein,
> ist wohl eher Git Hub (

Ich glaube auch, dass das an GitHub liegt.

[Ralph S. (jjflash)]

Weil mich jemand privat mit meiner regulären Mailadresse angeschrieben 
hat (und für den auch schon ein programmierter Controller in der Post 
ist) habe ich jetzt noch ein Arduino-Sketch auf die Schnelle gemacht 
(nein, nicht über Klassen und Arduino-Bibliotheken, sondern gerade das 
C-Programm kurz modifiziert, damit es Arduino "frisst").

Im Anhang auf dem Foto sieht man das Display schon auf einem PCB-Adapter 
stecken, aber noch mit einem Trimmer für die Kontrastspannung (weil die 
PCB's bei JLCPCB schon in Arbeit waren).

By the way, weil es schon ab und an vorgekommen ist dass ich "privat" 
angeschrieben wurde: hey Leute so arg kann ich Euren Ruf gar nicht 
versauen.