PicoMon für CH32V003 oder STM32F0xx

[Ralph S. (jjflash)]

PicoMon ist ein (sehr) kleiner Terminalmonitor, für 2 unterschiedliche 
Mikrocontroller realisiert.

Die "Challenge" für das Programm könnte man auch benennen nach: Von 
STM32 nach CH32, zurück und dann gemeinsam, weil:

der erste Programmentwurf erfolgte für einen STM32-Controller. Dann habe 
ich das "Projekt" zur Seite gelegt um den CH32 zu evaluieren. Also 
beschlossen, den kleinen Monitor mit CH32 weiter zu führen. Allerdings 
gibt es einen großen Vorteil bei STM32: er hat mehr RAM.

Wie dem auch sei. "Angestachelt" von einem Nachbarthread von mir, bei 
dem Laberkopp meinte, den Textdisplayadapter seriell mittels UART 
anzusteuern, wollte ich das für ein farbiges Display machen.

Wollte ich schon immer haben, weil ich zum einen eine einfache 
Möglichkeit haben will, Ausgaben anstelle zum PC zu schicken auf dem 
Steckbrett anzeigen zu lassen. Zum Anderen möchte ich schon lange eine 
Möglichkeit haben, ein Display an einen PC anzustöpsel und dieses ohne 
großen Aufwand zu betreiben. Speziell hier möchte ich eine 
Ausgabemöglichkeit auf ein Display haben, die von sehr kleinen 
ThinClients, die nur noch als Internetradio dienen, kommen.

Jetzt habe ich das endlich mal gemacht.

Also, was kann mein PicoMon?

PicoMon empfängt auf der RxD-Leitung des USART Zeichen mit 4800 Bd im 
Protokoll 8N1. Eingehende Steuerzeichen werden interpretiert für
- Linefeed
- Carriage return
- Tabulator
- Backspace
und vor allen Dingen ESC-Sequenzen
- und einem zusätzlichen Gadget, welches einen "mißbrauchten" Steuercode 
16 (0x10h) mißbraucht, um einen String, der eine Turtlegrafik beinhaltet 
darstellen zu könne.

Die ESC-Sequenzen werden hinsichtlich der Farben so interpretiert, wie 
sie ein Linux-Terminal auch interpretieren würden. Ebson so wird die 
Cursorsteuerung interpretiert, so dass die Kontrolle wo und in welcher 
Farbe ein Text erscheinen soll gegeben ist.

PicoMon unterstützt die Grafikcontroller ILI 9162, ili9163, ili9340, 
st7735 / st7735r, st7789, st9225 und s6d02a1 mit Pixelauflösung von 
128x128, 160x80, 160x128 und 320x24 mit Schriftstilen in 4 
unterschiedlichen Größen: 5x7, 8x8, 10x16 und 12x16 Pixeln.

Aus der Kombination von unterschiedlichen Displayauflösungen und 
Schriftgrößen ergeben sich viele Kombination hinsichtlich der 
dargestellten Zeichen auf dem Display. Die Ausgabe der Zeichen kann 
waage- oder senkrecht erfolgen.

Wird in der untersten Zeile ein Linefeed erzeugt, scrollt der Textinhalt 
nach oben und die unterste Zeile wird beschrieben.

Hierfür ist ein Framebuffer notwendig, der alle eingehenden Zeichen 
zwischenspeichert (mit samt den Farbattributen) um diese bei Bedarf nach 
oben scrollen zu können.

Hieraus ergibt sich die "Problematik", dass in Verbindung mit einem 
Display mit "vielen Pixeln" (für mich hat ein 320x240 Display viele 
Pixel) und einem sehr kleinen Schriftstil der RAM eines CH32V003 nicht 
ausreicht (das war dann der Grund, warum es das ganze jetzt für 2 
Controller gibt: ein STM32F042 und STM32F070F6 haben grundsätzlich 6 
kByte RAM und der ist immer ausreichend bei diesem Projekt).

Die Funktionsweise ist wie so oft simpel, aber manches artet dann sogar 
in Arbeit aus:

Der USART ist als Interrupt realisiert, der alle eingehenden Zeichen in 
einem Ringbuffer speichert (damit bei einem eventuellen zeitraubenden 
Scrollen kein Zeichen verloren geht). Diese Zeichen werden zuerst 
geparst und dann zum einem im Framebuffer und auf dem Display abgelegt.

Das wars dann eigentlich auch schon. Wer so etwas brauchen kann, möge 
sich bedienen. Ich für mich werde wohl PCB's erstellen für 160x80, 
160x128 und 320x240 Displays

PicoMon kann von jedem Controller aus angesteuert werden, der einen Text 
mit einer Baudrate von 4800 Bd verschicken kann (also von allen, 
getestet habe ich das mit MCS-51, AVR, Padauk PFS154, STM8, STM32 und 
CH32V003).

Zur Demonstration habe ich dem Archiv ein Demoprogramm für AVR ATmega 
mit eingepackt (bei mir ist das ein abgespeckter Arduino-Nano, dem die 
Chinesen damals den Mega328p entfernt und dafür einen Mega168 eingesetzt 
hatten... als das ganze noch inkl. Porto für 1,50€ zu haben war)

[Oliver R. (orb)]

Ralph S. schrieb:
> PicoMon kann von jedem Controller aus angesteuert werden, der einen Text
> mit einer Baudrate von 4800 Bd verschicken kann

Warum so ein ungebräuchlicher Wert? Nostalgie?

[Yalu X. (yalu) (Moderator)]

Ralph S. schrieb:
> Wird in der untersten Zeile ein Linefeed erzeugt, scrollt der Textinhalt
> nach oben und die unterste Zeile wird beschrieben.
>
> Hierfür ist ein Framebuffer notwendig, der alle eingehenden Zeichen
> zwischenspeichert (mit samt den Farbattributen) um diese bei Bedarf nach
> oben scrollen zu können.

Geht das nicht einfacher, sehr viel schneller und ohne Framebuffer mit
der integrierten Scrollfunktion, über die die meisten (oder sogar alle?)
der von dir genannten TFT-Controller verfügen?

[Ralph S. (jjflash)]

Yalu X. schrieb:
> Geht das nicht einfacher, sehr viel schneller und ohne Framebuffer mit
> der integrierten Scrollfunktion, über die die meisten (oder sogar alle?)
> der von dir genannten TFT-Controller verfügen?

Ich denke die haben alle eine Scrollfunktion !

Ich hatte mit den Scrollfunktionen von ein paar Displays experimentiert 
gehabt. Grundsätzlich hatte das auch funktioniert. Dann schließe ich ein 
augenscheinlich gleiches Display (mit gleichem Controller) an und es 
verschiebt mir aufgrund unterschiedlicher interner Adressbelegungen die 
Anzeige "unschön".

Natürlich hast du recht, dass das dann viel schneller geht und 
grundsätzlich sollte ich mir Gedanken darüber machen, ob es so sinnvoll 
ist, eine .h / .c Kombination für viele Displays in einem verwalten zu 
wollen als für jedes Display eine eigene!

Alleine die ST7735 Derivate bringen mich in ihrer Vielfalt manchmal zum 
"Verzweifeln". Es müßte (ich gebe zu es wäre besser) auch für jede 
Auflösung ein eigenständige Software gemacht werden (by the way: bis 
jetzt hat mir noch niemand sagen können, wie man eine .h / .c korrekt 
benennt. Entgegen der Aussage eines Herren hier, der mir beibringen 
wollte, was eine Library ist und diese eine .a Datei ist, die mittels 
-lfoo hinzugelingt wird und ich das doch nicht Library nennen soll, was 
ich auch nicht getan habe. Also, wenn hier jemand mitliest und die 
korrekte Bezeichnung weiß, bin ich gerne lernfähig und übernehme diese 
Bezeichnung). ST7735 Controller bedienen meines Wissens nach Auflösungen 
von 160x80 bis 320x240.

Diesen "Wust" der Unterschiedlichkeit auseinander zu "klabustern" war / 
ist mir etwas zu aufwändig und deshalb habe ich keine interne 
Scrollfunktion genutzt.

Hier fängt dann ein weiteres Problem mit meinem PicoMon an: Um nicht für 
jeden Displaycontroller den Ram-Bereich zu definieren in dem Zeichen 
ausgegeben wird (und der dann nur in seinem Bereich einmal adressiert 
werden muß), adressiere ich jeden einzelnen Pixel. Das alleine macht die 
Sache schon 3 mal langsamer als es sein könnte. Allerdings brauche ich 
für eine korrekte Darstellung dann aber nur Offsetadressen anzugeben um 
Unterschiedlichkeiten auszugleichen. Hinzu kommt, dass ich die 
Ausrichtung des Displays (horizontal, vertikal) in Software mache (ich 
weiß, auch hier gibt es interne Funktionen des Controllers). Würde ich 
die Ausrichtung dem Display überlassen, müßte ich zusätzlich auch die 
Init-Sequenz entsprechend für jede Ausrichtung anpassen.

Und weil ich noch dazu kein DMA verwende, ist das Setzen eines Zeichens 
relativ langsam. Für eine Textausgabe jedoch schnell genug (sieht man 
vom Scrolling einmal ab).

Der Framebuffer erschien mir die "einfachere" Lösung (wenn auch 
langsamer und schlechter im Sinne von schlechter).

Oliver R. schrieb:
>> PicoMon kann von jedem Controller aus angesteuert werden, der einen Text
>> mit einer Baudrate von 4800 Bd verschicken kann
>
> Warum so ein ungebräuchlicher Wert? Nostalgie?

Weil das ganze jetzt relativ langsam ist und der Eingangsbuffer des 
UARTS nicht überlaufen soll (er ist 256 Byte groß), dürfen die Zeichen 
nicht zu schnell eintreffen und von daher habe ich den Wert 4800 Baud 
gewählt.

Yalu hat aber Recht mit seiner Aussage. Vielleicht sollte ich mich 
daransetzen und die ganze Steuerung des Displays komplett neu schreiben 
(in der Hoffnung das gut handhabbar gestalten zu können). Und vielleicht 
sollte ich mich nicht immer verzetteln und an einer "Geschichte" dran 
bleiben anstelle immer neue Baustellen aufzumachen.

Bisher habe ich zu beschreibende Adressbereiche und Scrollarea immer nur 
für einen expliziten Anwendungsfall gemacht. Universell ist mir das 
bisher nicht geglückt!

PicoMon ist für meine Zwecke ausreichend schnell und vor allen Dingen - 
aus meiner Sicht der Dinge - leicht und schnell anpassbar, aber wenn 
sich jemand die Muse macht und das besser gestaltet übernehme ich solche 
Dinge dann schon gerne.

[Apollo M. (Firma: @home) (majortom)]

Ralph S. schrieb:
> Also beschlossen, den kleinen Monitor mit CH32 weiter zu führen. Allerdings gibt 
es einen großen Vorteil bei STM32: er hat mehr RAM.

Mit dem ch32x033, 62k/20k flash/ram, 5V tolerant, tssop20, ... für 0.30€ 
hast du keine Sorgen mehr und lernst nebenbei den kleinen Bruder 
ch32v003, der für mich nur in sop8 Sinn macht, besser kennen.
Autobaud Erkennung wäre auch wünschenswert ...

[Christoph M. (mchris)]

>Autobaud Erkennung wäre auch wünschenswert ...
und eine Oszilloskop-Funktion ..