MCURSES - Mini Curses Bibliothek für Mikrocontroller

stru_aus schrieb:
> hab den mal probiert - find ich prächtig :D

Freut mich :-)

> als linux user hab ich minicom verwendet statt putty, vermutlich liegt
> es an mir, aber ich brachte keinen empfang von zeichen pc->avr zustande

Hm, verstehe ich nicht. Müsste gehen, mit PuTTY läufts. Funktioniert 
auch die Eingabe von ganz normalen Buchstaben nicht?

> minicom ruf ich auf mit
> minicom -b 9600 -D /dev/ttyUSB0

Hast Du mcurses-config.h diesbzgl. angepasst? mcurses läuft 
standardmäßig mit 19200 Bd und nicht 9600 Bd.

Gruß,

Frank

Hallo Frank,

ich finde die Lib auch klasse, aber ich würde noch diese Funktionen von 
PeDa einbauen.

Beitrag "AVR-GCC: UART mit FIFO"

oder

UART library - Peter Fleury
http://homepage.hispeed.ch/peterfleury/avr-software.html#libs

Da ich Scanner und Parser immer selber schreibe, finde ich einen FiFo 
für die Serielle Ein- und Ausgabe sehr gut.

Uwe S. schrieb:
> ich finde die Lib auch klasse, aber ich würde noch diese Funktionen von
> PeDa einbauen.
>
> Beitrag "AVR-GCC: UART mit FIFO"
>
> oder
>
> UART library - Peter Fleury
> http://homepage.hispeed.ch/peterfleury/avr-software.html#libs

Ich habe da lediglich rudimentäre UART-Funktionen eingebaut, da ich 
diese eigentlich weniger als Bestandteil der mcurses-LIB sehe. 
Eigentlich sollte das UART-Interface gar nicht zu mcurses gehören. Aber 
man will ja was sehen :-)

Ich schaue mit die UART-Libs an. Sicher kann man da was besser machen.

Gruß,

Frank

Hallo Frank,

danke, es soll auch nur als eine Anregung verstanden werden.

hier noch ein update der letzten lib: 
http://beaststwo.org/avr-uart/index.shtml

stru_aus schrieb:
> liegt wohl doch an minicom, dem brachte ich nicht vt200 bei,
> standardmässig steht da vt102. kenn mich mit termcap etc nicht aus :(

VT102 sollte eigentlich ausreichen. Zumindest sollte er die 
alphanumerischen Zeichen, wie z.B. Buchstaben (A-Z) zeigen, wenn Du 
irgendeine Buchstaben-Taste drückst. Auch die Cursor-Tasten sollten bei 
VT102 funktionieren.

Bist Du sicher, dass RX korrekt am ATmega angeschlossen ist?
Um welchen ATmega handelt es sich?

Neue Version 1.0.2 verfügbar:

 - Demo-Programm ausgebaut (schöner, netter, Hingucker ;-) )
 - addstr_P() und mvaddstr_P() zur Dokumentation hinzugefügt

Gruß,

Frank

Neue Version 1.0.4 verfügbar:

Änderungen:

  - mcurses-Library + Demo-Programm nun auch unter Linux lauffähig

Man kann mcurses nun auch unter Unix bzw. Linux nutzen, also ohne 
Mikrocontroller. Dies kann ganz hilfreich bei der Entwicklung sein, da 
dies auf einem "richtigen" Rechner doch einfacher und schneller geht als 
mit einem µC.

Das mcurses-Demo-Programm kann man mit dem Aufruf

   make -f Makefile.unix

erzeugen. Dieses kann man dann mit dem Kommando

   ./demo

ausführen.

Gruß,

Frank

Hast du vielleicht mal einen Screenshot vom Demo-Programm? Müsste 
erstmal was mit Max232 aufbauen ums mir auf einem Controller ansehen zu 
können...

Nils S. schrieb:
> Hast du vielleicht mal einen Screenshot vom Demo-Programm?

Da es eher eine Animation ist, ist ein Screenshot wenig aussagekräftig.

> Müsste erstmal was mit Max232 aufbauen ums mir auf einem
> Controller ansehen zu können...

Ich benutze dieses Teil:

  http://shop.myavr.de/Bauelemente%20und%20Controller/myUSBtoUART.htm?sp=article.sp.php&artID=200024

Vorteil: Kein Max232 notwendig, weil das Ding TTL-Pegel hat.
Nachtei: Du kannst die Strippe nicht 15m lang machen ;-)

Mit 7,95 EUR finde ich den Preis ganz in Ordnung.

Gruß,

Frank

>Ich benutze dieses Teil:
Hehe, ja praktisch.. Hier liegen schon seit Monaten mehrere FTDIs, aber 
bisher zu faul gewesen Platinen zu machen...

Aber ich glaub, da werd ich mich demnächst mal reinarbeiten.

Kennst du den Demos Commander? Das wär ja geil mit ner SD-Karte :)

Nils S. schrieb:
> Kennst du den Demos Commander? Das wär ja geil mit ner SD-Karte :)

Nein. Aber ich habe gerade mal mit CamStudio das Demo-Programm gefilmt 
und die AVI-Datei hochgeladen. Findest Du im Artikel:

     http://www.mikrocontroller.net/articles/MCURSES

Ich weiß, ist jetzt nicht der Super-Duper-Werbefilm. Aber mir ging es 
lediglich um die Vorstellung der Möglichkeiten mit einer Bibliothek, die 
gerade mal 1,5 KB groß ist. Da könnte man noch ganz andere Sachen mit 
machen, z.B. Spiele wie Snake oder Tetris über mcurses laufen lassen...

Viel Spaß beim Zuschauen :-)

Hallo Frank,

super! Habe es zwar noch nicht ausgetestet, Quelltext und Demo-Filmcjen 
sieht nach dem aus, was ich benötige...

Vielleicht eine kleine Anmerkung/Anregung zur physischen Ausgabe: in 
meinem AVR BASIC gibt es auch Ein-/Ausgabe-Funktionen und habe dabei 
auch auf plattformunabhängigkeit geachtet. Ein AVR benutzt die serielle 
Schnittstelle, unter Linux sieht es wieder anders aus. Ich habe das über 
Defines in der Konfigurationsdatei gelöst, die dann an den 
entsprechenden Programmstellen eingebaut sind.

1

#if USE_AVR

2

  #define PRINTF(...)      usart_write(__VA_ARGS__)

3

  #define GETLINE(buf, len)  usart_read_line(buf, len)

4

#else

5

  #define PRINTF(...)      printf(__VA_ARGS__);fflush(stdout);

6

  #define GETLINE(buf, len)  fgets(buf, len, stdin)

7

#endif

Bzw. so wäre es auch einfacher deine Lib in eigene Projekte einzubinden, 
die ganz andere Ein-/Ausgabe-Routinen für die serielle Schnittstelle 
verwenden, man braucht nur die Defines in der Konfig ändern...

Das die entsprechenden Header-Dateien eingezogen werden muss der 
Anwender dann natürlich selbst gewährleisten...

Grüße Uwe

Hallo Uwe,

Uwe Berger schrieb:
> super! Habe es zwar noch nicht ausgetestet, Quelltext und Demo-Filmcjen
> sieht nach dem aus, was ich benötige...

Prima :-)

> Vielleicht eine kleine Anmerkung/Anregung zur physischen Ausgabe: in
> meinem AVR BASIC gibt es auch Ein-/Ausgabe-Funktionen und habe dabei
> auch auf plattformunabhängigkeit geachtet.

Ja, ich sehe: Du machst das prinzipiell etwas anders als ich, aber 
ähnlich - wenn man genauer hinschaut.

mcurses braucht lediglich 3 physische I/O-Funktionen:

  xxx_init ()
  xxx_putc ()
  xxx_getc ()

Diese habe ich mit den Namen...

  mcurses_uart_init ()
  mcurses_uart_putc ()
  mcurses_uart_getc ()

definiert. Tatsächlich machen sie unter Unix bzw. Linux aber was ganz 
anderes und scheren sich nicht um irgendwelche UARTS o.ä., sondern 
benutzen stdio in Verbindung mit termio.

Vielleicht hätte ich sie anders nennen sollen, nämlich besser:

  mcurses_phyio_init ()
  mcurses_phyio_putc ()
  mcurses_phyio_getc ()

Ich bin auch gar nicht glücklich damit, dass der physische I/O-Anteil 
mit in der mcurses-LIB ist. Eigentlich hat er nichts darin zu suchen, 
soll sich doch jeder sein eigenes Lieblings-I/O-Modul anflanschen...

Aber nackt ohne I/O wäre mcurses auch wieder uninteressant... Vielleicht 
sollte ich das in eine mcurses-io.c auslagern, wo dann jeder seine 
eigene Lieblings-I/O-Lib (mit FIFO oder was weiß ich) ankoppeln kann.

Ich schlage vor, Du baust den physischen I/O-Teil auf Deine Belange um 
und wir beide beraten nochmal, wie wir das allgemein lösen... so dass 
wir beide zufrieden sind. Einverstanden?

Also: First make it work, then make it fine :-)

Gruß,

Frank

Frank M. schrieb:
> Ich schlage vor, Du baust den physischen I/O-Teil auf Deine Belange um
> und wir beide beraten nochmal, wie wir das allgemein lösen... so dass
> wir beide zufrieden sind. Einverstanden?
>
ok, ich melde mich dann wieder!

Grüße Uwe

Uwe Berger schrieb:
> ok, ich melde mich dann wieder!

Ich habe gerade gesehen, dass ich da noch ein Stück Linux-Code 
ausserhalb der 3 Funktionen

  mcurses_uart_init ()
  mcurses_uart_putc ()
  mcurses_uart_getc ()

(nämlich in initscr) hatte. Den habe ich nun noch nach 
mcurses_uart_init() verschoben. Bei der Gelegenheit habe ich die 3 
Funktionen in

  mcurses_phyio_init ()
  mcurses_phyio_putc ()
  mcurses_phyio_getc ()

umbenannt.

Das ganze habe ich als Version 1.0.6 hochgeladen.

vielleicht ist es besser, wenn Du auf dieser Version aufsetzt. Hier ist 
der Linux- und der AVR-Code besser isoliert. Ich verspreche, dass ich 
jetzt auch erstmal (außer Bugfixes) nichts mehr am Source ändern werde 
;-)

Gruß,

Frank

Neue Version 1.1.0 verfügbar:

Änderungen:

05.08.2011: Version 1.1.0

    * Unterstützung von Farben
    * Unterstützung von Graphikzeichen (Zeichnen von Rechtecken etc)
    * Neue Funktionen/Makros: nodelay(), refresh() und getyx()
    * Ringbuffer für effizientere Ein- und Ausgabe (UART)
    * AVR- und Linux-spezifische I/O-Funktionen besser modularisiert
    * Dokumentation ausgebaut
    * Demoprogramm ausgebaut (Farbe, Türme von Hanoi etc)

MoinMoin,

im Anhang mal ein weiteres "Demo-Programm" zu Franks mcurses-Lib. Es 
handelt sich um einen sehr simplen Text-Editor, der für mich allerdings 
eine Vorarbeit für einen Editor auf einer MCU ist, um z.B. direkt dort 
auch BASIC-Programme (AVR BASIC) editieren zu können.

Der eigentliche Editor, ich habe ihn einfach smed (small editor) 
getauft, verbirgt sich in der Prozedur smed(). Das derzeitige 
Rahmenprogramm ist für eine Linux-Plattform (bzw. mehr gcc und dessen 
Filesystem-Zugriffsroutinen aus der stdio.h) geschrieben. Ich habe 
versucht, die plattformspezifischen Dinge in entsprechenden Funktionen 
zu "kapseln". Folgende Funktionen/Prozeduren wären dies (natürlich mit 
den entsprechenden Abhängigkeiten und globalen Variablen; siehe 
Quelltext...):

get_edit_data()
set_edit_data()
insert_edit_data()
delete_edit_data()
load_edit_data()
save_edit_data()

Mein Plan ist es jetzt, diesen Editor (also mehr obige angesprochene 
Funktionen) für eins der Speichermedien meines 
AVR BASIC-Interpreters auf einem AVR anzupassen. Wahrscheinlich 
werde ich da mein letztens angesprochenes Etherrape mit externem 
DataFlash verwenden 
(Beitrag "Re: Basic-Interpreter auf einem AVR"), da dort 
ausreichend SRAM zur Verfügung stehen sollte.

Vielleicht kann ja jemand diesen Editor noch für etwas anderes 
gebrauchen...

Grüße Uwe

PS.: @Frank --> schaue dir bitte nochmal deine KEY_...-Definitionen in 
mcurses.h an, da gibt es ein paar Unstimmigkeiten (z.B. KEY_PPAGE ist 
nicht 0x88) bzw. es fehlen ein paar Entscheidende (z.B. Backspace, ...). 
Ich habe mir erst mal mit dem eigentlichen Tastencodes beholfen, weil 
ich deine Lib nicht ändern wollte...

PPS.: der Editor kann zwar überlange Zeilen nicht vollständig anzeigen 
bzw. verändern, sollte diese aber auch nicht abschneiden. Wenn ich mal 
viel Lust habe, behebe ich dieses kleine Manko noch...

Uwe Berger schrieb:

> im Anhang mal ein weiteres "Demo-Programm" zu Franks mcurses-Lib.

Super, werde ich ausprobieren :-)

> PS.: @Frank --> schaue dir bitte nochmal deine KEY_...-Definitionen in
> mcurses.h an, da gibt es ein paar Unstimmigkeiten (z.B. KEY_PPAGE ist
> nicht 0x88) bzw. es fehlen ein paar Entscheidende (z.B. Backspace, ...).

Benutzt Du PuTTY? Vergleiche bitte die Einstellungen unter KEYBOARD mit 
den meinigen Einstellungen, siehe Anhang.

Ich vermute mal, dass Du CTRL-H als Backspace-Key eingetragen hast, ich 
habe (Linux-Console-konform) CTRL-? eingestellt, was dem 
DELETE-Character (0x7F) entspricht. Ebenso habe ich VT400 als Tastatur 
gewählt und nicht ESC[n~, um so möglichst nahe am Standard eines 
VT200/VT400-Terminals zu sein.

Oder hast Du es mit der Linux-Console getestet? Vielleicht sollten wir 
da einen gemeinsamen "Standard" wählen, damit es da keine Irritationen 
gibt.

Gruß,

Frank

MoinMoin,

nun hast du mich auf der falschen Seite erwischt, weil um so etwas habe 
ich mich eigentlich noch nie so richtig gekümmert...:-)

Frank M. schrieb:
> Benutzt Du PuTTY? Vergleiche bitte die Einstellungen unter KEYBOARD mit
> den meinigen Einstellungen, siehe Anhang.
>
nein, ich habe mit xterm und GNOME-Terminal getestet. Bei Letzterem, 
wenn ich jetzt mal in den Einstellungen nachsehe, ist für Backspace 
"ACSII DEL" und für Delete "Escape-Sequenz" konfiguriert. (was auch 
immer das heißen mag...).

Ich merke schon, ich muss mal VTxxx-Manuals lesen...


> Ich vermute mal, dass Du CTRL-H als Backspace-Key eingetragen hast, ich
> habe (Linux-Console-konform) CTRL-? eingestellt, was dem
> DELETE-Character (0x7F) entspricht.
>
0x7F für Delete oder Backspace? --> durch Probieren (der Code-Fetzen 
steht noch einkommentiert an der entsprechenden Stelle), habe ich 
folgende Codes herausgefunden:

0x7F -> Backspace (fehlt bei dir)
0x88 -> Delete (bei dir KEY_PPAGE)
0x87 -> NextPage (hast du auch entsprechend)
0x89 -> PrevPage (bei dir KEY_END)
0x84 -> Insert (bei dir KEY_HOME)

Grüße Uwe

Uwe Berger schrieb:
> 0x7F für Delete oder Backspace? --> durch Probieren (der Code-Fetzen
> steht noch einkommentiert an der entsprechenden Stelle), habe ich
> folgende Codes herausgefunden:
>
> 0x7F -> Backspace (fehlt bei dir)
> 0x88 -> Delete (bei dir KEY_PPAGE)
> 0x87 -> NextPage (hast du auch entsprechend)
> 0x89 -> PrevPage (bei dir KEY_END)
> 0x84 -> Insert (bei dir KEY_HOME)

Ich glaube schon, ich weiß, was da los ist. Ein VTxxx-Terminal hat zwar 
auch die 6 Tasten oberhalb der 4 Cursor-Tasten, jedoch sind diese 6 
Tasten auf einem VT200 komplett anders angeordnet als auf einer 
AT-Tastatur. PuTTY trägt wohl bei der VT400-Einstellung dieser Anordnung 
Rechnung und gibt daher wohl die ESCAPE-Sequenzen für die 
VTxxx-Terminal-Tasten aus - unabhängig von der tatsächlichen 
Beschriftung.

Okay, Ich werde BACKSPACE auf 0x7F ändern und die 6 Edit-Tasten oberhalb 
des Cursor-Blocks an eine AT-Tastatur angleichen. Dies dürfte dann 
denselben ESCAPE-Sequenzen entsprechen wie auf der Linux-Console und 
auch für xterm gelten. Vielleicht habe ich da zu starrsinnig auf 
VT200/VT400-Kompatibilität geachtet - schließlich sind die originalen 
VT-Terminals mittlerweile so gut wie ausgestorben ;-)

Ich passe das also an und dokumentiere dann die notwendigen 
PuTTY-Einstellungen, damit die Tasten auch überall gleich funktionieren.

Ich habe eben mal in smed.c reingeschaut. Eine Anregung hätte ich:

  case '\n':

ist verständlicher als

  case 0x0A:

Ebenso

  case '\t':

statt

  case 0x09:

Das 0x0A gilt auch nur für Unix-TTYs, da wird das empfangene CR ('\r' = 
0x0D) mittels stty-Einstellung nach NL ('\n' = 0x0A) gemapped ("icrnl"). 
Bei Raw-Input (z.B. auf einem µC) wirst Du '\r' (0x0D) beim Drücken der 
CR-Taste bekommen und nicht 0x0A.

Daher wäre in smed.c evtl. ein doppelter case-switch sinnvoll:

1

  case '\n':  // Newline (Unix/Linux)

2

  case '\r':  // Carriage Return (raw terminal input)

3

      ...

um da beiden Plattformen zu genügen.

Ich werde wohl in der nächsten Version dieses Unix-typische Mapping per 
termio abschalten, so dass auch unter Linux das CR als 0x0D (= '\r') 
ankommt.

Ausserdem füge ich dann noch ein

1

#define KEY_CR '\r'

2

#define KEY_TAB '\t'

in mcurses.h hinzu, um das Ganze abzurunden.

Gruß,

Frank

EDIT:

Wie ich gerade sehe, machst Du keinen Gebrauch von den 
Scrolling-Regions. Dies hätte den Vorteil, dass Du nicht einen Großteil 
des Bildschirms neu "zeichnen" musst. Stattdessen kann man den Text 
innerhalb der Scrolling-Region je nach Taste (KEY_UP oder KEY_DOWN) 
einfach nach unten bzw. nach oben "schieben". Dann muss nur eine 
einzelne Zeile beim Scrollen aktualisiert werden, was das Ganze gerade 
bei serieller Übertragung wesentlich flüssiger macht.

Wenn Du möchtest, kann ich Dir die notwendigen Änderungen irgendwann in 
den nächsten Tagen zukommen lassen. Wenn Du es selber machen möchtest, 
schaue Dir das Demo-Programm an, da findest Du eine Anwendung vom Rollen 
(runter bzw. rauf). Dann macht das Terminal das selbst und es geht 
wesentlich flotter.

Hallo Frank,

Frank M. schrieb:
> Daher wäre in smed.c evtl. ein doppelter case-switch sinnvoll:
>   case '\n':  // Newline (Unix/Linux)
>   case '\r':  // Carriage Return (raw terminal input)
>       ...
>
das ist gar nicht so dumm, denn an einer anderen Stelle im Programm gibt 
es auch eine Stelle, an der Zeilenende erkannt werden soll... So etwas 
ähnliches sollte dann auch für Non-UNIX-Textdateien funktionieren.


> Wie ich gerade sehe, machst Du keinen Gebrauch von den
> Scrolling-Regions. Dies hätte den Vorteil, dass Du nicht einen Großteil
> des Bildschirms neu "zeichnen" musst. ...
>
stimmt, das hattest du weiter oben schon angedeutet. Ich hatte es wohl 
vor lauter Kursor-Berechnung/-Plazierung aus dem Sinn verloren. Ich baue 
es ein, denn das Programm selbst sollte damit auch schneller werden...

Grüße & Danke Uwe

Frank M. schrieb:
>> im Anhang mal ein weiteres "Demo-Programm" zu Franks mcurses-Lib.
>
> Super, werde ich ausprobieren :-)

Ich habe mal etwas rumgespielt.

1. Compilieren:

1

smed.c:126: warning: comparison is always false due to limited range of data type

2

smed.c:131: warning: comparison is always false due to limited range of data type

In Zeile 126 steht:

1

        if ((sign = n) < 0) n = -n;

Da "sign" als uint8_t definiert ist, kann der Ausdruck niemals negativ 
sein.

In Zeile 131 dasselbe:

1

        if (sign < 0) s[i++] = '-';

Dann habe ich smed aufgerufen mit:

       ./smed

ohne Eingabe eines Dateinamens. Es erscheint:

       Usage: ./smed [filename]

Die eckigen Klammern bedeuten bei einer Usage-Meldung, dass das Argument 
optional ist. Ist es aber nicht, daher wäre folgende Meldung besser:

       Usage: ./smed filename

um anzudeuten, dass das Argument zwingend notwendig ist. Ausserdem 
sollten die Usage und andere Fehlermeldungen auf stderr statt stdout per

       fprintf (stderr, ...);

ausgegeben werden.

Okay, ich habe dann mal eine Datei x.txt angelegt:

       >x.txt

und anschließend smed aufgerufen. Wenn ich nun "12345" eingebe, 
erscheint stattdessen auf dem Bildschirm "23451", d.h. das erste 
eingegebene Zeichen wird immer weiter nach rechts geschoben, weil der 
Cursor nach dem ersten Zeichen nicht eine Stelle nach rechts gestellt 
wird.

Die Ursache dafür liegt wohl an der (noch) leeren Datei x.txt. Ist die 
Datei tatsächlich auch gefüllt, gibt es diesen Effekt nicht.

Sonst gefällt mir smed schon ganz gut, Kompliment :-)

Hallo Frank,

Frank M. schrieb:
> Ich habe mal etwas rumgespielt.
>
> 1. Compilieren:
>
> smed.c:126: warning: comparison is always false due to limited range of data 
type
>
> smed.c:131: warning: comparison is always false due to limited range of data 
type
>
ich habe diesen Code-Schnipsel irgendwoher copiert und mir keine 
weiteren Gedanken dazu gemacht, werde ich abändern...

> Dann habe ich smed aufgerufen mit:
>
>        ./smed
>
> ohne Eingabe eines Dateinamens. Es erscheint:
>
>        Usage: ./smed [filename]
>...
>
ok, dass ist das sehr, sehr einfach gehaltene Rahmenprogramm, was für 
mich nicht so die Bedeutung hat, weil ich mehr an smed() selbst 
interessiert bin. Es ist eigentlich nur dafür da, um nicht gleich auf 
einer MCU testen zu müssen. Natürlich könnte man da auch auf nicht 
vorhandene Dateien, korrekte Ausgabekanäle usw. besser reagieren. Werde 
ich, um das Demo "abzurunden", auch machen, hast recht...

> Okay, ich habe dann mal eine Datei x.txt angelegt:
>
>        >x.txt
>...
>
upps, den Fall (leere Datei) hatte ich nicht ausprobiert, muss natürlich 
funktionieren und werde ich korrigieren. Ein ähnliches Problemchen hatte 
ich beim Einfügen am Dateiende, was ich aber lösen konnte...

> Sonst gefällt mir smed schon ganz gut, Kompliment :-)
>
Danke! Wie gesagt, das obige Programm ist eigentlich nur eine 
Arbeitsversion, um daraus im nächsten Schritt einen Editor für 
ressourcenarme Systeme zu bauen --> "small editor for small systems" 
oder so ähnlich ;-)...

Ich stelle die korrigierte Version dann wieder hier ein.

Grüße & Danke Uwe

Uwe Berger schrieb:
> Danke! Wie gesagt, das obige Programm ist eigentlich nur eine
> Arbeitsversion, um daraus im nächsten Schritt einen Editor für
> ressourcenarme Systeme zu bauen --> "small editor for small systems"
> oder so ähnlich ;-)...

Ja, ich weiß, was Deine Intention ist. Editoren für Linux gibt es ja 
schon zuhauf :-) Ich dachte nur, dass einige Kleinigkeiten (leere Datei 
etc.) Dich schon interessieren würden.

> Ich stelle die korrigierte Version dann wieder hier ein.

Machs nicht so schnell und warte bitte ein wenig. Ich habe gerade das 
Key-Mapping in mcurses angepasst, damit es dann auch mit smed rund 
läuft. Ich lade das gleich hoch und beschreibe dann gleich die nötigen 
Anpassungen an smed.

Gruß,

Frank

Die MCURSES-Version 1.2.0 ist nun verfügbar unter

    http://www.mikrocontroller.net/articles/MCURSES

Änderungen:

    - Key-Mapping an Linux/Console angepasst, insb. die sog. "Edit keys"
    - KEY_BACKSPACE als Backspace-Taste definiert
    - KEY_CR als RETURN-Taste definiert
    - KEY_TAB als Tabulator-Taste definiert

@Uwe:

Mit der neuen Version sind folgende Änderungen an smed notwendig:

1

Alt:

2

                        case 0x87: // NextPage

3

Neu:

4

                        case KEY_NPAGE: // NextPage

5

6

Alt:

7

                        case 0x89: // PrevPage

8

Neu:

9

                        case KEY_PPAGE: // PrevPage

10

11

Alt:

12

                        case 0x0A: // RETURN

13

Neu:

14

                        case KEY_CR: // RETURN

15

16

Alt:

17

                        case 0x09: // TAB

18

Neu:

19

                        case KEY_TAB: // TAB

20

21

Alt:

22

                        case 0x88: // DEL

23

Neu:

24

                        case KEY_DC: // DEL

25

26

Alt:

27

                        case 0x7F: // BACKSPACE

28

Neu:

29

                        case KEY_BACKSPACE: // BACKSPACE

30

31

Alt:

32

                        case 0x84: // INSERT

33

Neu:

34

                        case KEY_IC: // INSERT

Damit sollten wir nun ein einheitliches Tastaturmapping gefunden haben.

Viel Spaß :-)

MoinMoin,

anbei die überarbeitete Version des Editor-Demos. Hauptsächlich wurden:

* Fehlerkorrekturen vorgenommen
* Franks aktualisierte Key-Mappings übernommen
* da wo es sinnvoll ist, Bildschirmaufbau via Scrolling-Regions

Vielleicht kommt die Tage noch eine Version mit ein paar weiteren 
Funktionen, die für einen Editor ganz sinnvoll erscheinen und ohne 
größeren Aufwand realisierbar sein sollten.

Grüße Uwe

chris schrieb:
> Hättest Du den Editor eventuell auch in Deinem "BASIC" schreiben können?
>
theoretisch ja, wenn man die ganzen mcurses-Funktionen z.B. als 
call-Aufrufe (siehe Doku) einbinden würde. Die Frage ist aber, ob man 
sich ein solchen Editor als BASIC-Programm wirklich antun möchte.

Wenn deine Frage darauf hinzielt, ob man "mcurses-Aus-/Eingaben" 
innerhalb eines BASIC-Programms machen könnte, dann ein volles ja (wenn 
man genannte Voraussetzung schafft).

Grüße Uwe

MoinMoin,

habe gerade smed (siehe weiter oben...) in mein AVR-BASIC-Projekt 
integriert und die neue Version des BASIC-Interpreters ins hiesige SVN 
geladen.

Damit ist es möglich BASIC-Programme direkt "auf" der MCU zu editieren, 
ein Speichermedium für die Dateien natürlich vorausgesetzt.

Im Anhang mal ein Bildschirmfoto des Editors in Aktion auf einem 
Etherrape-Board, welches mit einem ATmega644 und einem externen 
Dataflash bestückt.

Einen Dank an Frank für die mcurses-Bibliothek und die konstruktiven 
Hinweise zu smed!

Grüße Uwe

Hallo Uwe,

Uwe Berger schrieb:
> habe gerade smed (siehe weiter oben...) in mein AVR-BASIC-Projekt
> integriert und die neue Version des BASIC-Interpreters ins hiesige SVN
> geladen.

Sehr schön! Ich glaube, ich muss mir Dein Basic auch mal anschauen :-)

> Einen Dank an Frank für die mcurses-Bibliothek und die konstruktiven
> Hinweise zu smed!

Nichts zu danken, hat viel Spaß gemacht. Wenn Du Vorschläge/Bugs/Tipps 
oder sonstiges zu melden hast, immer her damit!

Gruß,

Frank

Anlässlich einer neuen Version hole ich den Thread mal wieder nach oben.

Version 1.3.0 ist online (siehe MCURSES) mit folgenden Änderungen:

    - Neue Funktion getnstr()
    - Neues Makro mvgetnstr()
    - Kleinere Korrekturen in endwin()

Mit der neuen getnstr() Funktion kann man eine komplette Eingabezeile 
als String einlesen. getnstr() beinhaltet einen Mini-Editor, der mit den 
gängigen Tasten Pos1, Ende, Entf, Backspace und den Cursor-Tasten 
bedienbar ist.

Viel Spaß,

Frank

Christian J. schrieb:

> Jetzt würde ich noch gern einen Basic Interpreter einbauen aber da
> müsste ich mich noch einarbeiten, wie das gemacht wird.

Schau mal nach Uwe Bergers Basic Interpreter, den er bereits auf AVR, 
XMC2GO und STM32F4xxx portiert hat:

  Beitrag "Basic-Interpreter auf einem AVR"
  Beitrag "uPlay Basic Interpreter per XMC2Go"
  Beitrag "Basic Editor und Interpreter auf dem STM32F429-Disco"

Achtung bei älteren Links in obigen Threads: irgendwann ist Uwe von 
bralug.de nach bplaced.net umgezogen.

Im AVR-Basic-Interpreter benutzt Uwe auch die mcurses-Lib:

  Beitrag "Re: Basic-Interpreter auf einem AVR"

Damit hat er sich einen Full-Screen-Editor gestrickt. Das würde schon 
mal gut zu Deiner mcurses-Anwendung passen.

Du findest Uwes AVR-Basic-Interpreter auch im SVN:

  http://www.mikrocontroller.net/svn/list

Es lohnt auf jeden Fall auch einen Blick auf Uwes Seite:

  http://mikrocontroller.bplaced.net/wordpress/

Gruß,

Frank

Christian J. schrieb:
> Jetzt würde ich noch gern einen Basic Interpreter einbauen aber da
> müsste ich mich noch einarbeiten

Einen Basicinterpreter für Z80 findest du hier, ist nicht mal CP/M 
notwendig :-)
http://searle.hostei.com/grant/#MyZ80

Neue MCURSES-Version 2.1.0 ist verfügbar.

Grund ist ein Bugfix in der mcurses-internen Funktion mcurses_puti(), 
welches für Werte 100 bis 109 falsch arbeitete.

MoinMoin,

Frank M. schrieb:
> Schau mal nach Uwe Bergers Basic Interpreter, den er bereits auf AVR,
> XMC2GO und STM32F4xxx portiert hat:
>
>   Beitrag "Basic-Interpreter auf einem AVR"
>   Beitrag "uPlay Basic Interpreter per XMC2Go"
>   Beitrag "Basic Editor und Interpreter auf dem STM32F429-Disco"
>
> Achtung bei älteren Links in obigen Threads: irgendwann ist Uwe von
> bralug.de nach bplaced.net umgezogen.

kleine Richtigstellung zu Franks herausgesuchten Beiträgen/Links zum 
Thema Basic-Interpreter, da ich mich nicht gern mit fremden Lorbeeren 
schmücken möchte:

Erster erwähnter Beitrag ist tatsächliche mein Basic-Interpreter. Den 
aktuellen Stand findet man im hiesigen SVN.

Der zweite und dritte erwähnte Beitrag ist nicht von mir!

Die XMC2Go-Implementierung ist von einem gewissen Uwe B., der nichts mit 
mir zu tun hat. Der Quelltext dieses Interpreters sieht ähnlich meinem 
aus, da wir beide den gleichen Ursprung verwendet haben (uBasic von Adam 
Dunkel). Aber letztendlich sind wir wohl unterschiedliche Wege gegangen.

Die STM32F429-Implementierung stammt von einem Uwe Becker, den ich 
ebenfalls nicht kenne (aber den Ort, in dem er wohnt...;-)...). Über 
seine Implementierung kann ich nichts sagen (würde mich aber 
interessieren), da er bisher keine Quellen veröffenlicht hat (...oder 
habe ich etwas übersehen?).

Grüße Uwe

Nachtrag: gerade gesehen, Uwe B. und Uwe Becker scheint ein und die 
selbe Person zu sein... Damit gehe ich mal davon aus, dass seine beiden 
Impementierungen ähnlich aussehen werden.

Ich denke man sollte den Namen ändern, wenn das noch zu machen ist:

"Curses" heisst "Flüche"
"Courses" heisst "Kurse"

MoinMoin,

ernst oellers schrieb:
> "Curses" heisst "Flüche"

"Curses" ist der richtige Begriff und KANN nicht geändert werden, da es 
sich hieran anlehnt:
http://de.wikipedia.org/wiki/Curses
http://de.wikipedia.org/wiki/Ncurses

Grüße Uwe

ernst oellers schrieb:
> Ich denke man sollte den Namen ändern, wenn das noch zu machen ist:
>
> "Curses" heisst "Flüche"
> "Courses" heisst "Kurse"

Nix zu machen :-)

mcurses ist angelehnt an die Curses-Bibliothek für Unix aus den 80ern:

  http://www.lehman.cuny.edu/cgi-bin/man-cgi?curses+3

Ein Ableger war dann ncurses (zunächst nur für Linux):

   http://linux.die.net/man/3/ncurses

Courses passt da gar nicht. Wir lassen es schön bei mcurses, also den 
"Mini-Flüchen" ;-)

MoinMoin,

greg schrieb:
> Die GPL ist denkbar
> schlecht geeignet im Bereich der eingebetteten Systeme.

Frank wird sich schon etwas dabei gedacht haben!

Warum sollte GPL für eingebettete Systeme ungeeignet sein?

Grüße Uwe

greg schrieb:
> Die Library sieht interessant aus, etwas störend sind IMHO die fest im
> Code hängenden AVR-Eigenheiten [...]

Wieso stören sie Dich?

Unter Linux oder SDCC für Z80 (oder demnächst für STM32F4) werden die 
AVR-Spezifika doch komplett weggeblendet.

> und die Lizenz. Die GPL ist denkbar
> schlecht geeignet im Bereich der eingebetteten Systeme. Es wäre toll,
> wenn der Code alternativ permissive lizensiert wäre.

Grund?

Hallo Uwe,

Uwe Berger schrieb:
> Erster erwähnter Beitrag ist tatsächliche mein Basic-Interpreter. Den
> aktuellen Stand findet man im hiesigen SVN.
>
> Der zweite und dritte erwähnte Beitrag ist nicht von mir!

Sorry. Ich dachte, solche Namensähnlichkeiten gäbe es eher bei den 
berühmten Namen, die mit "M" beginnen ;-)

Danke für die Richtigstellung.

MCURSES-Tester schrieb:

> ist die MCURSES-lib auch für Linuxprozesse geeignet,
> die wahlweise im Hintergrund und Vordergrund (dann mit
> user-input) laufen ?

> fg %1
>
> Programm läuft wieder im Vordergrund (Textkonsole + Ausgaben verfügbar)

Prinzipiell geht das schon, allerdings wird dann der Bildschirminhalt 
nicht wieder rekonstruiert. Das liegt daran, dass die auf µC 
zugeschnitte mcurses-Lib kein Abbild des Bildschirms speichert. In 
diesem Fall müsste die Anwendung den Bildschirminhalt wieder herstellen. 
Ich habe bisher nicht gewusst, dass mcurses auch für Linux-Anwender 
vielleicht für Interesse sein könnte. Dafür gibt es ja das wesentlich 
leistungsfähigere ncurses. Sollte es aber dennoch der Fall sein, könnte 
ich durchaus in die UNIX-/Linux-Variante so etwas einbauen.

Wenn mcurses auch den Bildschirm-Inhalt im Speicher hält, können sogar 
bestimmte Operationen schneller bzw. optimiert ablaufen. Wenn mcurses 
jetzt den Cursor um eins nach rechts schieben will, muss es eine 
Escape-Sequenz bestehend aus drei Zeichen senden. Eine "intelligentere" 
Variante braucht einfach nur das Zeichen zu senden, was rechts vom 
Cursor steht. Das ist ja gespeichert und daher bekannt. Das ist nur ein 
Beispiel. Es gibt noch viele andere, wo ein "Bildschirmspeicher" von 
Vorteil sein könnte. Für µCs ist dies jedoch wenig sinnvoll, da 
naturgemäß das RAM ein knappes Gut ist. Aber nicht soooo schlimm, da 
gibt es ja auch kein Job-Control ;-)

Okay, warum die mcurses-Variante für Linux nicht ein wenig aufbohren....

> zum Thema GPL:
>
> bitte das Thema http://de.wikipedia.org/wiki/GPL_linking_exception
> mal durchlesen.

Danke, schaue ich mir an.

MCURSES-Tester schrieb:
> Hier
> https://github.com/nsf/termbox/tree/master/src
> kannst du abgucken :)

Was soll ich da abgucken? Ich programmiere schon seit 1985 für unixoide 
Systeme. Job-Control-Handling ist easy.

Terminal Tor schrieb:
> Frank M. gefällt mir sehr gut - Danke!!!
>
>> Unter Linux oder SDCC für Z80 (oder demnächst für STM32F4)...
>
> Gibt es eigentlich den Source schon für STM32?

Im Moment nur hier in diesem Projekt:

  http://www.mikrocontroller.net/articles/WordClock24h#Download

Relevant sind aus wclock24.zip die 3 Dateien:

  - mcurses.c
  - mcurses.h
  - mcurses-config.h

Ich bin noch nicht dazu gekommen, diesen Stand in den 
MCURSES-Artikel einzupflegen, weil dazu ein paar Kommentare bzgl. 
STM32 notwendig wären.

Kurze Erläuterung, was hier STM32-spezifisch ist:

mcurses-config.h:

  - Stellt man MCURSES_UART_NUMBER auf 0, wird der USB-Port des
    STM32F4-Discovery als Virtual COM Port (VCP) verwendet. Das
    heisst, man benötigt noch die USB-Lib, weil kein UART des
    STM32, sondern STM32-USB am Micro-USB-Port verwendet wird. Die
    Einstellung von MCURSES_BAUD wird hier auch komplett ignoriert.

    Ausserdem ist in diesem Fall zu beachten, was hier unter "Start"

       http://www.mikrocontroller.net/articles/WordClock24h#Start

    bzgl. PuTTY erläutert wird, nämlich dass der COM-Port erst nach
    Aufruf von initscr() zur Verfügung steht und man erst dann eine
    COM-Port Verbindung (z.B. mit PuTTY) aufnehmen kann. Aus diesem
    Grund wartet initscr() auch 10 Sekunden, bevor es durchstartet.

Aber okay, das ist ein spezieller Fall beim Disco-Board. Verwendet man 
einen normalen UART am STM32, dann ist

    MCURSES_UART_NUMBER

auf Werte zwischen 1 - 6 zu setzen. Da ein STM32 auch immer alternative 
Pins zur Verfügung stellt, sollte man im Source prüfen, ob ich für die 
jeweilige UART-Nummer auch die Pins ausgesucht habe, die gewünscht sind.

Desweiteren muss MCURSES_BAUD eingestellt werden. Ich habe mit 115200Bd 
überhaupt keine Probleme gehabt.

Noch ein Wort zu den Nucleo-Boards:

Ist man stolzer Benutzer eines Nucleo Boards (z.B. 401er oder 411er) und 
wählt man UART2, kann man auch den USB-Anschluss des Nucleo-Boards 
nutzen. Hier macht aber nicht der STM32 die USB-Umsetzung, sondern die 
Elektronik auf der ST-Link-Hälfte des Boards. Hier ist der Anschluss von 
PuTTY unproblematischer. Ein Reset des STM32 schadet der COM-Verbindung 
nicht. Beim Disco-Board geht die Verbindung kaputt und PuTTY muss dann 
neu gestartet werden. Das ist echt blöd und deswegen überlege ich auch, 
die USB-Unterstützung (speziell für das Disco-Board) auch wieder 
rauszunehmen.

Aber es gibt natürlich auch den Weg, ausschließlich einen UART zu 
verwenden und auf der PC-Seite einen eigenen USB-UART-Wandler zu 
verwenden. Dann gibt's auch keine Probleme.

Ich hoffe, damit wird es etwas klarer.

Wenn Du noch Fragen hast, melde Dich.

P.S.
Die in mcurses-config.h vorhandenen #ifdefs sind projektspezifisch. Die 
solltest Du rauslöschen und die Preprocessor-Konstanten 
MCURSES_UART_NUMBER und MCURSES_BAUD ohne Wenn und Aber (d.h. ohne 
#ifdef) setzen.

Terminal Tor schrieb:
> Werde mir mal den Code ansehen.

Gut. Freue mich auf Feedback. Benutzt Du eines der oben erwähnten Boards 
oder hast Du eine eigene Schaltung? Welchen STM32F4 verwendest Du dafür?

Sorry, wenn ich nachfrage. Bin auch erst seit kurzem in der STM32-Welt 
unterwegs und sammle noch Erfahrungen.

Hallo Frank,

ich verwende mcurses mal wieder für eine kleine (plattformunabhängige) 
Spielerei...

Dabei vermisse ich curs_set() --> also Ein-/Ausschalten des Cursors. 
Hast du nicht Lust diese Funktion zu implementieren?

Grüße & Danke Uwe

Hallo Uwe,

Uwe Berger schrieb:

> ich verwende mcurses mal wieder für eine kleine (plattformunabhängige)
> Spielerei...

Welche? Bin neugierig :-)

> Dabei vermisse ich curs_set() --> also Ein-/Ausschalten des Cursors.
> Hast du nicht Lust diese Funktion zu implementieren?

Ja, ist sinnvoll, baue ich bis spätestens Ende der Woche ein. Ich wollte 
sowieso mal den STM32-Port veröffentlichen.

EDIT:

Ich habe mir gerade nochmal den Source, der zum Download bereitsteht, 
angeschaut und bemerkt, dass curs_set() bereits drin ist :-)

Ich habs wohl im Artikel vergessen zu erwähnen - gerade nachgeholt.

Aufruf:

   curs_set (0);       // Cursor unsichtbar
   curs_set (1);       // Cursor sichtbar

Viel Spaß!

Frank

MoinMoin,

Frank M. schrieb:
>> ich verwende mcurses mal wieder für eine kleine (plattformunabhängige)
>> Spielerei...
>
> Welche? Bin neugierig :-)

ein Tetris-Clone, den ich später auch auf einem MC (mit einem "Display", 
was noch nicht 100% feststeht; nur möglichst groß muss es sein :-)) 
laufen lassen möchte. Derzeit ist die Tetris-Engine fertig. Mal sehen, 
vielleicht stelle ich den Quelltext auf mc.net zur Verfügung.

Die Quelltextstruktur ist so gestaltet, dass die Ein-/Ausgabe- und 
Timer-Routinen entsprechend der Plattform austauschbar sind. Zum Test 
läuft das Ding moentan mit deinen mcurses-Routinen für die Ein-/Ausgabe. 
(Bin gerade am überlegen, ob ich noch etwas für X implementiere...).

Frank M. schrieb:
> Ich habe mir gerade nochmal den Source, der zum Download bereitsteht,
> angeschaut und bemerkt, dass curs_set() bereits drin ist :-)
>
...ok, ich hatte zwar gestern Abend in deinen Quelltext kurz 
reingeschaut, muss es dann aber wohl überlesen haben.

Grüße & Danke Uwe

Uwe Berger schrieb:
> ein Tetris-Clone, den ich später auch auf einem MC (mit einem "Display",
> was noch nicht 100% feststeht; nur möglichst groß muss es sein :-))

Klingt spannend :-)

Ich habe gerade die Version 2.2.0 hochgeladen mit den folgenden 
Änderungen:

   - Portierung auf STM32F10x und STM32F4xx
   - Auswahl der UART-Schnittstelle (nur STM32)
   - Neue Funktionen: printw() und vprintw() (nur STM32)
   - Neue Makros: mvprintw() und mvvprintw() (nur STM32)
   - Variablen-Typen uint8_t auf uint_fast8_t umgestellt
   - Funktionsbeschreibung von curs_set() nachgeholt

Viel Spaß,

Frank

Frank M. schrieb:
>> ein Tetris-Clone, den ich später auch auf einem MC (mit einem "Display",
>> was noch nicht 100% feststeht; nur möglichst groß muss es sein :-))
>
> Klingt spannend :-)

siehe Beitrag "ein plattformunabhängiger Tetris-Clone"

Es wird dabei testweise/beispielhaft dein MCURSES verwendet...

Grüße Uwe

Frank M. schrieb:
> Ja, das ist ein Nachteil, den ich aber nicht sooo gravierend finde. Eine
> feste Maximal-Zahl von Zeilen/Spalten (z.B. 35/135) reicht Dir nicht?

Ich möchte die Größe des Fensters zur Laufzeit ändern können. Ich hatte 
das mal testweise eingebaut, und fand es nicht sonderlich schwierig.
Dein demo.c lief damit eigentlich schon ganz gut.

>> Mein Versuch, MCURSES dafür zu erweitern, ist vor einer Weile kläglich
>> gescheitert. (Ich schicke "ESC [ 6 n" (Cursor position report) ans
>> Terminal und versuche die Antwort aus dem Input-Stream herauszufischen.)

Das Problem war die Erkennung, wie groß das Fenster denn momentan sein 
sollte (wenn das Ausgabefenster ein Xterm ist, dessen Größe mit der Maus 
geändert wird). Ich hatte versucht das komplett in MCURSES abzuwickeln 
und von dort an "geeigneter Stelle" die Escape-Sequenz geschickt. Es 
kann dann aber passieren, daß die Antwort vom Terminal gerade dann 
kommt, wenn der Anwender gerade die ESC-Taste gedrückt hat.

> Schaue ich mir mal an.

Ich kann meine Sourcen raussuchen und Dir zukommen lassen.

Arduino F. schrieb:

> Es hat keine 10 Minuten gedauert, dann lief das Demo auf meinem UNO.
> Kompiliert und hochgeladen mit der Arduino IDE.

Freut mich.

> Ein Warning wirft es:E:\Daten\Arduino\mcurses\examples\demo\demo.ino: In
> function 'void screen_demo()':

Die Lösung ist einfach:

Einfach ein

1

const char *

 statt

1

char *

 in die Funktionsdefinition von shift_left_str() schreiben. Das könnte 
man auch noch bei den meisten anderen Funktionen, die ein char * als 
Parameter benötigen, nachziehen.

> Todo:
> Anpassen, so dass die Arduino Komfort Funktionen genutzt werden können.

Was ist damit gemeint?

Hallo Frank,

ich würde mcurses gerne in einem FreeRTOS-Projekt einsetzen und dafür 
anpassen. Das Projekt selbst ist allerdings nicht OpenSource.
Würde es dir etwas ausmachen, mcurses unter der MIT-Lizenz freizugeben, 
so wie auch ncurses?

Gruß,
Manuel

Christian J. schrieb:
> hast Du inzwischen die einzeilige Eingabezeile impelmentiert, die ich
> damals 2015 anfragte?

Ja, die ist bereits seit Ende 2014 drin:

Beitrag "Re: MCURSES - Mini Curses Bibliothek für Mikrocontroller"

Dokumentation im Artikel: MCURSES: getnstr

50s schrieb:
> Manuel S. schrieb:
>> Das Projekt selbst ist allerdings nicht OpenSource.
>
> ...wie wäre es mit Quellcode-Lesen:

Manuel meinte sein Projekt, nicht mcurses.

@Manuel: Melde Dich einfach mal per Mail (PN).

ChrisMicro schrieb:
> Hier hat ein chinesischer Programmierer mcurses an ein
> Real-Time-System angepasst:
> https://github.com/wuhanstudio/mcurses

Nett. Ich sehe da aber nur ein paar minimale Anpassungen an Arduino. Die 
stammen ja von Dir.