Bibliothek für VT100-Terminals

Kai L. schrieb:
> ich habe mir eine keine Bibliothek zusammen geschustert, mit der ich
> VT100-Terminals ansteuern kann.

Schau Dir mal MCURSES an. Das ist eine abgespeckte Version der 
(n)curses-Bibliothek, welche speziell für die Benutzung auf 
Mikrocontrollern angepasst wurde. Sie "versteckt" nicht nur alle 
Escape-Sequenzen vor dem Programmierer, sondern liefert auch sämtliche 
Funktionalitäten mit, um ein VT100 (VT200/VT320/VT400) nicht nur 
anzusteuern, sondern versteht auch alle gängigen Funktions-/Cursor- und 
Navigationstasten. Diese werden direkt in numerische Tasten-Codes 
umgesetzt.

MCURSES kann Attribute (Farbe, etc) setzen, Scrolling-Regions 
verwenden, Einzelzeichen- und String-Ausgabe und noch einiges mehr.

Ein kleines Tetris-Spiel (Menüführungen etc.) lässt sich damit in 
Nullkommanix programmieren.

Damit ist Deine "Bibliothek" mit gerade 3 simplen Funktionen, (welche 
auch noch das speicherhungrige sprintf() verwendet) komplett hinfällig.

MCURSES läuft auf Unix, Linux, AVRs (ATmega, ATTiny) und anderen µCs 
wie STM32. Selbst auf Z80 (SDCC) ist die Bibliothek portiert. Die 
Portierung auf andere Prozessoren beschränkt sich im wesentlichen auf 
eine Implementierung von putchar() und getchar(). Der Rest ist portabler 
Code.

Sorry,

Frank

Anbei ist eine neue Version, die sprintf durch utoa und ein paar weitere 
Zeilen zur Formatierung ersetzt. Ohne sprintf sinkt der 
Speicherverbrauch in meinem kleinen Testprogramm um satte 1130 Byte. Die 
Geschwindigkeit sollte entsprechend auch gestiegen sein.
Auch war vorher fälschlicherweise die stdlib.h statt der stdio.h 
eingebunden, was jetzt jedoch genau passend ist.
Viel Spaß! :)

Hallo Frank,

vielen Dank für den Tipp :) Bis jetzt war ich nur auf ncourses gestoßen, 
die abgespeckte Version davon kannte ich noch nicht.
Meine Mini-Bibliothek kann da von der Funktionsvielfalt natürlich nicht 
mithalten, wobei sie geschätzt gerade einmal 400 Bytes groß ist (das 
ganze Programm samt Schleifen, etc. umfasst 558 Bytes) und zumindest für 
mich alle benötigten rudimentären Funktionen bereitstellt.

Einen Nachteil der mcourses Bibliothekt sehe ich jedoch darin, dass sie 
um alle Funktionen zu realisieren auch die Hardwareseitig den UART 
kontrolliert, was ich nicht möchte. In einem Fall benutze ich nämlich 
meine kleine Bibliothek um auf dem ATmega2560 Daten raus zu liefern über 
den UART2. Die oben beschriebene Bibliothek kann aber maximal 2 UARTs 
verwalten. Daher müsste ich sie, wenn ich sie verwenden sollte 
umschreiben.
Mir war es wichtig eine strikte Trennung zwischen den Befehlen und der 
Hardware-Ausgabe bereit zu stellen. Das physikalische Layer, auf dem die 
Daten übertragen werden wird dadurch irrelevant und ich kann ohne großen 
Aufwand einfach die Funktionen einer UART-Bibliothek verwenden um die 
Befehle an den PC zu senden. An der Bibliothek ändern muss ich dabei 
nichts.
Ich hoffe ich habe irgendwie verständlich gemacht was mein Hintergedanke 
hierbei war ;) Die mcourses Bibliothek ist ganz klar von der 
Funktionalität her größer und besser, allerdings verfolge ich mit meiner 
Mini-Bibliothek einen anderen Ansatz.

Gruß

Kai

Kai L. schrieb:
> Einen Nachteil der mcourses Bibliothekt sehe ich jedoch darin, dass sie
> um alle Funktionen zu realisieren auch die Hardwareseitig den UART
> kontrolliert, was ich nicht möchte.

Das stimmt so nicht. Durch Anpassung von nur 2 Funktionen

   void mcurses_phyio_putc (uint8_t ch)
und
   uint8_t mcurses_phyio_getc (void)

auf das gewünschte Ausgabe-Device, kannst Du kommunizieren, worüber Du 
willst. Das kann UART1, UART3, UARTX, SPI, I2C, ETHERNET oder sonstwas 
sein.

> In einem Fall benutze ich nämlich
> meine kleine Bibliothek um auf dem ATmega2560 Daten raus zu liefern über
> den UART2. Die oben beschriebene Bibliothek kann aber maximal 2 UARTs
> verwalten. Daher müsste ich sie, wenn ich sie verwenden sollte
> umschreiben.

Das meinst Du nur auf den ersten Blick. MCURSES hat strikt die 
logischen und die physikalischen Funktionen getrennt.

> Ich hoffe ich habe irgendwie verständlich gemacht was mein Hintergedanke
> hierbei war ;) Die mcourses Bibliothek ist ganz klar von der
> Funktionalität her größer und besser, allerdings verfolge ich mit meiner
> Mini-Bibliothek einen anderen Ansatz.

Sie ist auf einem AVR gerade mal 1,9 KB groß - bei vielfachem 
Funktionsumfang. Deine 3 Funktionen verschlingen schon 500 Byte.

Allein die Fallunterscheidung, ob x bzw. y eine 1-, 2- oder 3-stellige 
Zahl ist, ist viel zu kompliziert.

statt 9 mal:

      buffer[5] = 'H';
      ...
      buffer[6] = 'H';
      ...
      buffer[7] = 'H';

zu schreiben, macht man das mit einer einzigen Zuweisung am Schluss der 
Funktion:

      buffer[pos] = 'H';

Du machst für so etwas einfaches eine Fallunterscheidung von 3x3 = 9 
Fällen und brauchst alleine, um den Cursor zu setzen, 68 Zeilen Code.

Hier die äquivalente Funktion in MCURSES:

static void
mymove (uint8_t y, uint8_t x)
{
    mcurses_puts_P (SEQ_CSI);
    mcurses_puti (y + 1);
    mcurses_putc (';');
    mcurses_puti (x + 1);
    mcurses_putc ('H');
}

Die mcurses_puts/puti/putc-Funktionen sind alle vom Ausgabedevice 
komplett unabhängig.


Sag mal: Wie lange programmierst Du schon?

Hier Deine 3 Funktionen in einer anderen Form, die nur 80 Bytes statt 
322 auf einem ATmega88 an Code verbraten - bei gleicher Funktionalität:

1

static uint8_t

2

myutoa10 (uint8_t i, char * buffer)

3

{

4

    uint8_t len;

5

6

    if (i >= 100)

7

    {

8

        uint8_t ii = i / 100;

9

        *buffer++ = ii + '0';

10

        i -= 100 * ii;

11

        ii = i / 10;

12

        *buffer++ = ii + '0';

13

        i -= 10 * ii;

14

        len = 3;

15

    }

16

    else if (i >= 10)

17

    {

18

        uint8_t ii = i / 10;

19

        *buffer++ = ii + '0';

20

        i -= 10 * ii;

21

        len = 2;

22

    }

23

    else

24

    {

25

        len = 1;

26

    }

27

28

    *buffer++ = i + '0';

29

    return rtc;

30

}

31

32

void VT_CURSOR_UP_N(char* buffer, uint8_t n)

33

{

34

    uint8_t pos;

35

36

    //buffer benoetigt eine Mindestlaenge von 7 Zeichen

37

    buffer[0] = '\e';

38

    buffer[1] = '[';

39

    pos = 2;

40

    pos += myutoa10(n, &buffer[pos]);

41

    buffer[pos++] = 'A';

42

    buffer[pos] = 0;

43

}

44

45

46

void VT_CURSOR_DOWN_N(char* buffer, uint8_t n)

47

{

48

    uint8_t pos;

49

50

    //buffer benoetigt eine Mindestlaenge von 7 Zeichen

51

    buffer[0] = '\e';

52

    buffer[1] = '[';

53

    pos = 2;

54

    pos += myutoa10(n, &buffer[pos]);

55

    buffer[pos++] = 'A';

56

    buffer[pos] = 0;

57

}

58

59

void VT_CURSOR_SET(char* buffer, uint8_t x, uint8_t y)

60

{

61

    uint8_t pos;

62

63

    //buffer benoetigt eine Mindestlaenge von 11 Zeichen

64

    buffer[0] = '\e';

65

    buffer[1] = '[';

66

    pos = 2;

67

    pos += myutoa10(x, &buffer[pos]);

68

    buffer[pos++] = ';';

69

    pos += myutoa10(y, &buffer[pos]);

70

    buffer[pos++] = 'H';

71

    buffer[pos] = 0;

72

}

Damit sinkt der erzeugte Code auf unter ein Viertel. Aber nicht nur 
dieser ist um ein Vielfaches kürzer, sondern auch der C-Quelltext - und 
dabei immer noch gut lesbar. Die Funktion utoa() wurde dabei durch 
myutoa10() ersetzt. Diese ist nicht nur kürzer, sondern liefert auch 
direkt die Länge zurück.

Code ungetestet, sehe aber auf Anhieb keinen Fehler.

Übersetzt wurde beide Versionen mit

1

int main ()

2

{

3

    char buffer[12];

4

5

    VT_CURSOR_SET(buffer, 10, 10);

6

    VT_CURSOR_UP_N(buffer, 1);

7

    VT_CURSOR_UP_N(buffer, 1);

8

}

Alt:

   Program:     322 bytes (3.9% Full)

Neu:

   Program:      80 bytes (1.0% Full)

Das Konzept, erst einen Buffer zu füllen, um ihn dann in einer Schleife 
auszugeben, halte ich für doppelt gemoppelt. Warum erst den Buffer 
füllen? Direkt raus auf das Device! Dann braucht man auch keine 
String-Längen zu berechnen, nur um zu verhindern, dass man sich den 
Buffer kaputtschießt.

Frank M. schrieb:
> Hier Deine 3 Funktionen in einer anderen Form, die nur 80 Bytes statt
> 322 auf einem ATmega88 an Code verbraten - bei gleicher Funktionalität:

Vielen Dank. So etwas verstehe ich schon eher unter konstruktiver 
Kritik. :)

Bei deiner myutoa-Funktion verwendest du Divison um die einzelnen 
Stellen umzuwandeln. Gibt es eventuell Möglichkeiten (gerne auch zu 
Lasten der Lesbarkeit) um die Funktion ohne Division zu realisieren? 
Soweit ich weiß mögen AVRs ja keine Divison (sehr viel langsamer im 
Vergleich zu +, -, *).

Da myutoa auch im Gegensatz zu utoa die Anzahl der Stellen der 
Dezimalzahl zurück gibt, brauche ich nicht durch if-Abfragen die Länge 
die Positionen der restlichen Zeichen im Array festlegen.

Re: Bibliothek für VT100-Terminals schrieb:
> Statt auf konstruktive Kritik treffe ich aber auf einen alten
> Platzhirsch, der seine eigene Bibliothek als Maß der Dinge ansieht und
> keine neuen Ideen und Ansätze zulässt.

Tut mir leid, dass Du das so siehst. Aber einen Source mit drei 
Mini-Funktionen, welche ursprünglich einfach nur sprintf() aufriefen, 
eine "Bibliothek" zu nennen, erschien mir doch ein wenig ... merkwürdig 
- zumal die Header-Datei komplett weggelassen werden kann. Die drei 
Funktionen lassen sich nämlich komplett ohne zu übersetzen. Kein 
ernsthafter µC-Programmier verwendet für diesen schlichten Fall das 
Monstrum sprintf() - schon gar nicht für die einfache Ausgabe einer 
maximal dreistelligen Dezimalzahl.

Deine Version mit utoa() war zwar schon etwas sportlicher, allerdings 
sieht Code, der 9-mal hingeschrieben wird - nur mit abweichenden 
Konstanten - nicht gerade wie ein Programm aus. Jede Programmiersprache 
kennt Variablen. Die sollte man auch nutzen ;-)

>  Ich habe mit meiner Arbeit keinen
> Anspruch darauf auch nur ansatzweise so gut wie etablierte Lösungen zu
> sein, die schon seit Jahren gepflegt werden. Sie ist aus einer
> Notwendigkeit heraus und dem Antrieb etwas über die Steuerung von
> Terminals zu lernen entstanden.

Als ich den Source das erste Mal sah, fragte ich mich nach dem Nutzen: 
"Was will ich mit einer 'Bibliothek', die gerade mal den Cursor 
positionieren kann?"

Tut mir leid, ich kann mir da nur schwerlich eine ernsthafte Anwendung 
vostellen. Es kann ja sein, dass ein schlichtes Positionieren in Deinem 
konkreten Fall ja genügen mag. Aber normalerweise erhebt eine 
Bibliothek den Anspruch einer gewissen allgemeineren Lösung, aus der 
man schöpfen kann. Dafür klingt für mich Deine Bezeichnung "Bibliothek" 
ziemlich hochgestochen.

> Wenn ich aber hier keine konstruktive Kritik bekomme um meinen eigenen
> Code zu verbessern und etwas dabei zu lernen werde ich meine Ideen in
> Zukunft in einer anderen Bibliothek zur Verfügung stellen.

Du musst lernen, mit Kritik umzugehen. Auch nicht-konstruktive Kritik 
kann durchaus ein Ansporn sein, es besser zu machen. In diesem konkreten 
Fall hielt ich es für den besseren Weg.

Kai L. schrieb:

> Bei deiner myutoa-Funktion verwendest du Divison um die einzelnen
> Stellen umzuwandeln. Gibt es eventuell Möglichkeiten (gerne auch zu
> Lasten der Lesbarkeit) um die Funktion ohne Division zu realisieren?

Nicht, dass ich wüsste. Um die einzelnen Stellen einer Dezimalzahl zu 
isolieren, musst Du teilen. utoa() arbeitet da nicht anders, teilt aber 
abweichend dazu durch die angegebene Basis. Leider ist für einen µC das 
Teilen durch 10 nicht so einfach wie das Teilen durch eine Zweierpotenz.

> Da myutoa auch im Gegensatz zu utoa die Anzahl der Stellen der
> Dezimalzahl zurück gibt, brauche ich nicht durch if-Abfragen die Länge
> die Positionen der restlichen Zeichen im Array festlegen.

Eben. Das war der Sinn der Sache. Ausserdem ist das "Ausrechnen" von 
maximal 3 Stellen in einer speziellen Version tatsächlich kürzer als die 
der allgemeinen Funktion utoa().