MCURSES - Mini Curses Bibliothek für Mikrocontroller

[Frank M. (ukw) (Moderator)]

mcurses ist eine Mini-Curses-Programmbibliothek, die weniger auf 
Effizienz sondern eher auf möglichst wenig Speicherplatz-Verbrauch 
getrimmt ist. So ist diese Bibliothek durchaus auf Mikrocontrollern wie 
z.B. ATmegas lauffähig.

Die mcurses-Funktionen lehnen sich so nah wie möglich an das Original 
CURSES bzw. NCURSES an, trotzdem müssen jedoch teilweise Abstriche 
gemacht werden. Als Terminal wird lediglich VT200 unterstützt. Ein 
optimal passendes Terminal-Emulationsprogramm ist PuTTY.

Dokumentation und Download im Wiki-Artikel:

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

Im Download-Archiv ist ein Demoprogramm enthalten, welches ein paar 
Test-Ausgaben macht. Anschließend wird noch die Tastatur getestet - 
inkl. Funktionstasten, Cursor-Tasten etc.

Viel Spaß,

Frank

(Edit: Link auf Artikel repariert)

[stru_aus (Gast)]

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

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

das programm liegt auf einem atmega mit ftdi,
minicom ruf ich auf mit
minicom -b 9600 -D /dev/ttyUSB0

ich seh das demo, aber nachdem "Press a key (2x ESC to quit):" erscheint 
tut sich halt nichts mehr..

[Frank M. (ukw) (Moderator)]

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

[Uwe S. (de0508)]

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.

[stru_aus (Gast)]

achja.. hab den code natürlich auf 9600 baud angepasst.
mit minicom geht kein einziger empfang, auch nicht normale zeichen.

hatte mir dann den usart code angeschaut, aber keinen fehler gefunden.
wenn ich bei minicom local echo an mache sehe ich die zeichen, aber der 
code rührt sich nicht.

dann: test an nem windows rechner mit putty. da geht es prima, alles.

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

[Frank M. (ukw) (Moderator)]

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

[Uwe S. (de0508)]

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

[Frank M. (ukw) (Moderator)]

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?

[Frank M. (ukw) (Moderator)]

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

[Frank M. (ukw) (Moderator)]

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

[Nils S. (kruemeltee)]

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...

[Frank M. (ukw) (Moderator)]

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

[Nils S. (kruemeltee)]

>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 :)

[Frank M. (ukw) (Moderator)]

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 :-)

[stru_aus (Gast)]

das minicom-problem hab ich gelöst.
standardmässig ist bei minicom die hardware-flow-control eingeschaltet.
per commandozeilenaufruf geht das nicht zum abschalten, man muss sich 
durch das menü angeln, evtl geht es mit ner eigenen configurationsdatei.

also: es klappt nun auch mit linux, leider nicht out of the box.

nochmal für linuxer:
aufruf mit
minicom -s -b 9600 -D /dev/ttyUSB0
bzw statt ttyUSB0 das jeweilige device, das muss dem user auch erlaubt 
sein.
dann im menu zu "Serial port setup" gehen, dort mit "F" die hardware 
flow control ausschalten, enter klicken, escape klicken und es läuft.

mit dem schalter "-c on" könnte man auch noch farben anschalten, wurde 
im ersten demo nicht verwendet, hab ich auch noch nicht getestet.

[Uwe B. (boerge)]

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.

#if USE_AVR
  #define PRINTF(...)      usart_write(__VA_ARGS__)
  #define GETLINE(buf, len)  usart_read_line(buf, len)
#else
  #define PRINTF(...)      printf(__VA_ARGS__);fflush(stdout);
  #define GETLINE(buf, len)  fgets(buf, len, stdin)
#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

[Frank M. (ukw) (Moderator)]

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

[Uwe B. (boerge)]

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

[Frank M. (ukw) (Moderator)]

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

[ein Tscheche (Gast)]

es gibt auch eine linux-version von Putty...

[stru_aus (Gast)]

oh.. putty für linux.. danke XD

[Frank M. (ukw) (Moderator)]

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)

[Uwe B. (boerge)]

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...

[Frank M. (ukw) (Moderator)]

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

[Uwe B. (boerge)]

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

[Frank M. (ukw) (Moderator)]

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:

  case '\n':  // Newline (Unix/Linux)
  case '\r':  // Carriage Return (raw terminal input)
      ...

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

#define KEY_CR '\r'
#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.

[Uwe B. (boerge)]

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. (ukw) (Moderator)]

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:

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

In Zeile 126 steht:

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

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

In Zeile 131 dasselbe:

        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 :-)

[Uwe B. (boerge)]

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

[Frank M. (ukw) (Moderator)]

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

[Frank M. (ukw) (Moderator)]

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:

Alt:
                        case 0x87: // NextPage
Neu:
                        case KEY_NPAGE: // NextPage

Alt:
                        case 0x89: // PrevPage
Neu:
                        case KEY_PPAGE: // PrevPage

Alt:
                        case 0x0A: // RETURN
Neu:
                        case KEY_CR: // RETURN

Alt:
                        case 0x09: // TAB
Neu:
                        case KEY_TAB: // TAB

Alt:
                        case 0x88: // DEL
Neu:
                        case KEY_DC: // DEL

Alt:
                        case 0x7F: // BACKSPACE
Neu:
                        case KEY_BACKSPACE: // BACKSPACE

Alt:
                        case 0x84: // INSERT
Neu:
                        case KEY_IC: // INSERT

Damit sollten wir nun ein einheitliches Tastaturmapping gefunden haben.

Viel Spaß :-)

[Uwe B. (boerge)]

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 (Gast)]

>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.

Hättest Du den Editor eventuell auch in Deinem "BASIC" schreiben können?

[Uwe B. (boerge)]

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

[Uwe B. (boerge)]

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

[Frank M. (ukw) (Moderator)]

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

[Frank M. (ukw) (Moderator)]

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. (Gast)]

Hallo,

auch ich habe jetzt bei meinem Z80 bastel Computer mcurses in Betrieb, 
zusammen mit picocom oder minicom. Endlich redet er mit mir über ein 
Terminal. Es lief mit dem sdcc Compiler ohne eine einzige Änderung am 
Code direkt los, da ich putchar und getchar überschrieben hatte und er 
die auch nutzt.

Sehr gut, klasse gemacht!

Jetzt würde ich noch gern einen Basic Interpreter einbauen aber da 
müsste ich mich noch einarbeiten, wie das gemacht wird. Ich habe kein 
Speichermedium. Erinnere mich nur schwach an den C64 damals, glaube ein 
echter Editor war das nicht, man musste jede Zeile bearbeiten in dem man 
sie mit Zeilennummer neu schrieb glaube ich.  Eher wie "edlin".

Christian

[Frank M. (ukw) (Moderator)]

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

[Joe G. (feinmechaniker)]

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

[Frank M. (ukw) (Moderator)]

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.

[Uwe B. (boerge)]

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.

[Ernst O. (ernstj)]

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

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

[greg (Gast)]

Die Library sieht interessant aus, etwas störend sind IMHO die fest im 
Code hängenden AVR-Eigenheiten 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.

[Uwe B. (boerge)]

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

[Frank M. (ukw) (Moderator)]

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" ;-)

[Uwe B. (boerge)]

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

[Frank M. (ukw) (Moderator)]

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?

[Frank M. (ukw) (Moderator)]

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 (Gast)]

Hallo Frank,

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

Beispiel:  Programm test

./test

Programm läuft im Vordergrund (Textkonsole + Ausgaben verfügbar)

./test &

Programm läuft im Hintergrund (Textkonsole + Ausgaben nicht verfügbar)

fg %1

Programm läuft wieder im Vordergrund (Textkonsole + Ausgaben verfügbar)

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

zum Thema GPL:

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

Daraus ergibt sich das die  GNU Lesser General Public License bessere
Einsatzmöglichkeiten für den Anwender ermöglicht.

[Frank M. (ukw) (Moderator)]

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 (Gast)]

Hier

https://github.com/nsf/termbox/tree/master/src

kannst du abgucken :)

[Frank M. (ukw) (Moderator)]

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.

[MCURSES-Tester (Gast)]

"Wenn mcurses auch den Bildschirm-Inhalt im Speicher hält"

termbox arbeitet komplett mit double buffering.

[Terminal Tor (Gast)]

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?

[Frank M. (ukw) (Moderator)]

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 (Gast)]

Danke für die schnelle Antwort!

Werde mir mal den Code ansehen.

[Frank M. (ukw) (Moderator)]

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.

[Terminal Tor (Gast)]

Ich verwende den STM32F107 (bzw. STM32F407). Der Controller steckt auf 
meinem Roboter (spezielle HW) welcher über UART bzw. nRF24L01-Funkmodul 
über MCurses Kommandos und Daten im Lesemode (Terminal) senden soll.

[Uwe B. (boerge)]

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

[Frank M. (ukw) (Moderator)]

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

[Uwe B. (boerge)]

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

[Frank M. (ukw) (Moderator)]

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

[Uwe B. (boerge)]

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

[Leo C. (rapid)]

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.

[Einer K. (Gast)]

@Frank M.

Wenn ich es besser könnte, würde ich dich loben, aber so bewundere ich 
dich, für deine Arbeit.



Kurzer Bericht:
Aus rein egoistischem Interesse war ich auf der Suche nach ncurses für 
Arduino.
Erfolglos.

Dann Deins gefunden.

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

Die dazu nötige Arbeit:
mcurses.c nach mcurses.cpp umbenennen
demo.c nach demo.ino umbenennen

Ordner demo anlegen
mcurses.h mcurses.cpp demo.ino und mcurses-config.h in den Ordner 
werfen.
Fertig. Tuts. Das reicht für die Grundfunktion.

Ein Warning wirft es:

E:\Daten\Arduino\mcurses\examples\demo\demo.ino: In function 'void screen_demo()':

E:\Daten\Arduino\mcurses\examples\demo\demo.ino:346:66: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]

         shift_left_str (10, 20, "MCURSES LIB DEMO IN SLOW MOTION");

                                                                  ^

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

Danke

[Frank M. (ukw) (Moderator)]

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

const char *

 statt

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?

[Einer K. (Gast)]

Frank M. schrieb:
> Was ist damit gemeint?
Der UART Flansch passt halt so noch nicht in die Arduino Welt.


Nunja, in diesem Zustand steht der Timer0 und auch alle anderes UARTs 
(und noch viel mehr) nicht für die Arduino Umgebung zur Verfügung. Damit 
ist ein Großteil des Arduino Gedöns/Libs aus dem Rennen. Eine missliche 
Situation.

Mein Plan sieht in Etwa so aus:
Erst die serielle Anbindung auf Arduino Serial umbauen.
Damit sollte das Arduino Universum wieder voll zur Verfügung stehen.
Dann das ganze Gedöns in eine Arduino Lib Struktur verpacken.

Das Ergebnis lasse ich dir gerne hier zukommen.
Vielleicht gefällt dir das dann ja sogar .... ;-)

[ChrisMicro (Gast)]

>Dann Deins gefunden.

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

Hier habe ich den Code von Frank etwas modifiziert und den Code in eine 
Arduino-Libray verwandelt.

https://github.com/ChrisMicro/mcurses

Damit geht's mit dem in Betrieb nehmen noch schneller.

- runterladen
- in den Arduino Library Ordner kopieren
- Beispiele flashen.

> Was ist damit gemeint?
> Der UART Flansch passt halt so noch nicht in die Arduino Welt.

Der Arduino Flansh passte jetzt und wird mit Hilfe eines Call-Back 
"angeflanscht":

void Arduino_putchar(uint8_t c)
{
  Serial.write(c);
}

void setup()
{
  Serial.begin(115200);

  setFunction_putchar(Arduino_putchar); // tell the library which output channel shall be used

  initscr();                  // initialize mcurses

}

[Einer K. (Gast)]

Schau an, dann muss ich mich ja gar nicht mehr bewegen!

Danke.

[ChrisMicro (Gast)]

>Schau an, dann muss ich mich ja gar nicht mehr bewegen!
>Danke.

Äh .. ja. Seit zwei Tagen gibt es hier eine parallel-Diskussion:

Beitrag "Arduino: VT100 graphics"

Was natürlich schön wäre, wenn man mehr "Examples" hätte. Ich finde den 
Code der Beispiele auch etwas überfrachtet, weil man in den Beispielen 
ja versuchen sollte, das Wesentliche möglichst kurz auf den Punkt zu 
bringen.
Vielleicht hast Du ja noch eine schöne Idee.

[Einer K. (Gast)]

Ja, den Thread habe ich dann doch noch gefunden.
;-)
Mit Verspätung.

ChrisMicro schrieb:
> Vielleicht hast Du ja noch eine schöne Idee.
Bei mir dreht es sich hauptsächlich um Eingabemasken.

Mal schauen, wie weit sich das entwickelt...

[ChrisMicro (Gast)]

Jetzt habe ich mal den Hex-Editor von der Main separiert.
Damit kann man den Editor überall einbinden. Man muss nur vorher die 
Call-Backs für "putch" und "getch" setzen.

Vielleicht wäre es gut, wenn man die PEEK und POKE Funktionen auch als 
Call-Back Schnittstelle aufführen würde. Dann könnte man von außen 
zwischen RAM und FLASH hin und her schalten oder sogar den Editor nur 
für ein Byte Array ( Memory Protection ) zugänglich machen.

[Manuel S. (thymythos)]

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

[50s (Gast)]

Manuel S. schrieb:
> Das Projekt selbst ist allerdings nicht OpenSource.

...wie wäre es mit Quellcode-Lesen:

/*---------------------------------------------------------------------- 
------------------------------------------------------------------------ 
-----
 * mcurses.c - mcurses lib
 *
 * Copyright (c) 2011-2015 Frank Meyer - frank(at)fli4l.de
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *----------------------------------------------------------------------- 
------------------------------------------------------------------------ 
----
 */

[Christian J. (Gast)]

Sag mal Frank,

hast Du inzwischen die einzeilige Eingabezeile impelmentiert, die ich 
damals 2015 anfragte? Ich habe das ja bei meinem Z80 Bau prima verwenden 
können. Nur die Eingabezeile, die mit CR übernommen wird war noch nicht 
fertig.


> Viel Spaß,
>
> Frank

[Frank M. (ukw) (Moderator)]

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

[Frank M. (ukw) (Moderator)]

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).

[Heiler.De (Gast)]

Ich weiss, dass das schon ein paar Tage her ist, aber ich finde, das 
sollte nicht ohne Reaktion stehen bleiben (für alle künftigen Leser, 
denen das so nicht bewusst ist):

ChrisMicro schrieb:
> Was natürlich schön wäre, wenn man mehr "Examples" hätte. Ich finde den
> Code der Beispiele auch etwas überfrachtet, weil man in den Beispielen
> ja versuchen sollte, das Wesentliche möglichst kurz auf den Punkt zu
> bringen.

Sieh dir mal die ncurses-Manpages oder z.B. 
"NCURSES-Programming-HOWTO.pdf" (<= meine Empfehlung!!!) an.
*curses ist derart umfangreich und nicht gerade das, was ich als sauber 
und gegliedert bezeichnen würde, dass die Beispiele, die du möchtest 
kaum möglich sind.
Wenn man für jede Funktion ein kleines Beispiel schreiben würde (je 1 
kleine C-Datei z.B.), dann wäre das so umfangreich dass man im 
Beispiel-Wald die Bäume nicht mehr sieht.
Somit wäre der Haufen Beispiele wieder "nur" eine Nachschlage-Referenz, 
die man zu Rate zieht, wenn man was bestimmtes sucht.

Ich beschäftige mich nach Jahren gerade endlich mit mcurses und bin echt 
erstaunt über das, was ich aus meinen Basteleien mit einem guten 
User-Interface rausholen kann.
Bin auch sehr erfreut darüber meinen schlechten Bastel-Code mit Escape 
Sequenzen, den ich bisher verwendet habe, ersetzen zu können.
Will damit sagen, ich kann die Tage ein paar meiner ersten Gehversuche 
mit mcurses als Beispiele posten.

Ausserdem habe ich festgestellt (wovon ich aber auch schon ausging), 
dass das Beispiel mit dem Makefile.unix problemlos unter Windows/cygwin 
compiliert und läuft.
Ein "Port" mit dem Watcom-Compiler auf DOS ging auch problemlos.
Mit Borland-C++ 3.1 hatte ich ein paar Probleme bei der definition der 
Benutzten Datentypen, aber da habe ich dann nicht weiter nach gesehen - 
eigentlich auch uninteressant, war nur ein Versuch....


Vielen Dank an Frank für deine unermüdliche Arbeit, die über Jahre 
hinweg immer wieder der Community Gutes zuträgt (nicht nur mcurses!) und 
an alle anderen, die sich da mit eingeklinkt haben.

[ChrisMicro (Gast)]

Hier hat ein chinesischer Programmierer mcurses an ein Real-Time-System 
angepasst:

https://github.com/wuhanstudio/mcurses

Ich weiß aber nicht, welches das ist.

[Frank M. (ukw) (Moderator)]

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.

[Christian J. (Gast)]

Und? Ist das was Neues? Klappte ja schon 2015 alles prima...

[ChrisMicro (Gast)]

Frank M. (ukw) (Moderator)
>Nett. Ich sehe da aber nur ein paar minimale Anpassungen an Arduino. Die
>stammen ja von Dir.

Ich meinte die Änderungen hier:

https://github.com/wuhanstudio/mcurses/commit/5c6f177ce45dd073296a816fc04edf87d341a825

void rtt_putchar(uint_fast8_t c)
{
  rt_kprintf("%c", c);
}

rtt_putchar klingt so ein wenig nach "Real-Time"

Er hat auch einige Datentypen auf "uint_fast8_t" umgestellt. Diese Art 
der Optimierung ist mir noch recht fremd.

Der Typ von Wuhanstudio scheint ziemlich professionel zu sein. Er mach 
viel mit FPGAs:
https://github.com/wuhanstudio

[ChrisMicro (Gast)]

Jetzt habe ich noch mal genauer nachgesehen. Er scheint dieses Realtime 
OS zu verwenden:

https://github.com/RT-Thread/rt-thread

Leider bindet er im Header von "mcurses.h"

#include <rtthread.h>

ein, das dürfte die Kompatibilität als Arduino-Lib beenden.

Da müsste man noch ein

#ifdef "Arduino.h"

hinbasteln.