Low memory footprint UART-based text user interface

I am looking for a textual user interface library on the Nios II 
microcontroller running on an FPGA. The Nios controller talks to a host 
computer via serial port. The code running on the Nios II should be 
memory efficient, i.e. ~ 4 KB, and should provide basic user interfaces 
like menus navigable using arrow keys (or is it possible using mouse 
clicks on the serial console?) and dialog boxes. Any suggestions?

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

On 28/07/2014 05:46, Ang Zhi Ping wrote:
> I am looking for a textual user interface library on the Nios II
> microcontroller running on an FPGA. The Nios controller talks to a host
> computer via serial port. The code running on the Nios II should be
> memory efficient, i.e. ~ 4 KB, and should provide basic user interfaces
> like menus navigable using arrow keys (or is it possible using mouse
> clicks on the serial console?) and dialog boxes. Any suggestions?
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
If this is for debug or diagnostics I suggest you write it yourself and 
go for a much simpler interface.
Pretty much everything I make has a serial port debug interface and they 
will accept commands like:

PEEK 500	(which means read out contents of memory location 500)

or annother one:

EWQ 500 0x12345678 (which means write 32 bit word to eeprom)

(note the cunning acceptance of decimal or hex input !)

This is really easy to do, and a very low overhead on the processor. 
Once you start with dialogue boxes and menus it's like Windows over 
serial port and horrible.

(The nearest I get to a menu is if my son does the code and he will 
usualy put in something like 'HELP' which wikll list all the commands - 
  I put my faith is seperate printable documentation.)

Michael Kellett

On 28/07/2014 05:46, Ang Zhi Ping wrote:
> I am looking for a textual user interface library on the Nios II
> microcontroller running on an FPGA. The Nios controller talks to a host
> computer via serial port. The code running on the Nios II should be
> memory efficient, i.e. ~ 4 KB, and should provide basic user interfaces
> like menus navigable using arrow keys (or is it possible using mouse
> clicks on the serial console?) and dialog boxes. Any suggestions?

Your post is confusing - first you request a text base user interface, 
then you talk about navigation menus, which would imply graphics? 
Unless you mean pure command line driven menus where the selection (via 
text input) reveals another list of options which are dependent on the 
command just entered (a bit like the reaaallllyyy old text based 
adventure games you could run on the very first 8-bit home computers).

In any case, I think unless you stick to pure text entry, you would 
struggle to fit in your 4K limit - assuming that 4K is for both code and 
data.

A text base command interpreter would straight forward to implement and 
not take up much code or data space at all.  You may even be able to use 
FreeRTOS+CLI without FreeRTOS ( http://www.FreeRTOS.org/cli ) - I don't 
think there are any dependencies on FreeRTOS in that code.  That 
minimises RAM usage by allowing a single line of output to be returned 
at a time, so you only need a buffer larger enough for one line at a 
time.  You simply keep calling the command interpreter with the current 
command until it returns that there is no more output to be generated 
(you don't have to do one line at a time, if you had enough RAM you 
could just supply a buffer big enough to allow all the output to be 
generated at once).  The code size if very small, and there is only one 
file to compile.

Mouse mouse drivers I have seen are for USB, but I don't see any reason 
why you could not re-target to get input from the serial port, if it is 
still possible to buy serial mice.  The code for that would not leave 
you much for your user interface though.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 107000 downloads in 2013.

+ http://www.FreeRTOS.org/plus
IoT, Trace, Certification, FAT FS, TCP/IP, Training, and more...

On 28/7/2014 4:09 PM, FreeRTOS info wrote:
> Your post is confusing - first you request a text base user interface, 
> then you talk about navigation menus, which would imply graphics? 
> Unless you mean pure command line driven menus where the selection (via 
> text input) reveals another list of options which are dependent on the 
> command just entered (a bit like the reaaallllyyy old text based 
> adventure games you could run on the very first 8-bit home computers).

There are serial console characters which simulates the look and feel of
dialog boxes and navigation menus, i.e. box edges, shadows. No actual
pixel graphics are involved.

On 7/27/2014 9:46 PM, Ang Zhi Ping wrote:
> I am looking for a textual user interface library on the Nios II
> microcontroller running on an FPGA. The Nios controller talks to a host
> computer via serial port. The code running on the Nios II should be
> memory efficient, i.e. ~ 4 KB, and should provide basic user interfaces
> like menus navigable using arrow keys (or is it possible using mouse
> clicks on the serial console?) and dialog boxes. Any suggestions?

I've designed character based layered menu systems in the past
intended to talk to a "glass TTY" over a serial port.  In my case,
I built a slimmed down curses(3c) implementation (simplified
optimizations) then layered the menu/UI system on top of this.

In my case, the serial link was slow and curses(3c) gave me an
obvious performance enhancement without having to hand-optimize
each potential series of menu invocations -- let curses(3c) sort
out the most efficient way to update the physical screen from the
virtual image!

But, I'd have to look to see how big it was.  Keep in mind you will
need at least 4KB of DATA to represent the virtual screen (80x25x2)
plus any "pads" into that!  (you didn't state if your 4KB target
was for TEXT only or TEXT+DATA)

The big advantage this had (for me -- beyond the performance enhancement
over the slow serial channel) was that I could then support different
*real* TTY's (with a termino entry).  But, that was back when we *had*
real TTYs!  You could probably hard code ANSI 3.64 and be done with it!

On Mon, 28 Jul 2014 08:44:45 +0100, MK <mk@nospam.co.uk> wrote:

>On 28/07/2014 05:46, Ang Zhi Ping wrote:
>> I am looking for a textual user interface library on the Nios II
>> microcontroller running on an FPGA. The Nios controller talks to a host
>> computer via serial port. The code running on the Nios II should be
>> memory efficient, i.e. ~ 4 KB, and should provide basic user interfaces
>> like menus navigable using arrow keys (or is it possible using mouse
>> clicks on the serial console?) and dialog boxes. Any suggestions?

Were are you going to display those menus, an a miniature display on
the device itself or some external display ?

Where are the arrow keys, on the front panel of the device or
somewhere else ?

Does your device have a built i mouse or track ball or light pen or
this external to your days.

Your approach would have made sense in the 1970-90's when dumb
terminals, like VT100/VT220 were used. These had an addressable
cursor, some line drawing characters and some controllable attributes,
such as inverse video, blinking, underlining etc. In this case, you
had to code your user interface into your product to allow real
physical dumb terminals and later on terminal emulators, understanding
the VT100 functionality.


>If this is for debug or diagnostics I suggest you write it yourself and 
>go for a much simpler interface.
>Pretty much everything I make has a serial port debug interface and they 
>will accept commands like:
>
>PEEK 500	(which means read out contents of memory location 500)
>
>or annother one:
>
>EWQ 500 0x12345678 (which means write 32 bit word to eeprom)
>
>(note the cunning acceptance of decimal or hex input !)
>
>This is really easy to do, and a very low overhead on the processor. 
>Once you start with dialogue boxes and menus it's like Windows over 
>serial port and horrible.
>
>(The nearest I get to a menu is if my son does the code and he will 
>usualy put in something like 'HELP' which wikll list all the commands - 
>  I put my faith is seperate printable documentation.)
>
>Michael Kellett

Once you have a very primitive command line processing on the embedded
device, move the user interface to a more user friendly platform, such
as any Windows machine and these days, even to some smart phones,
which these days start to be more popular than tabletops or laptobs. 

The problem is just how to perform the actual interface.
Unfortunately, serial communication is rapidly becoming obsolete,
perhaps a USB device with serial interface on your embedded system or
perhaps Bluetooth might be an option.

Ang Zhi Ping <azhiping@dso.org.sg> wrote:
> On 28/7/2014 4:09 PM, FreeRTOS info wrote:
> > Your post is confusing - first you request a text base user interface, 
> > then you talk about navigation menus, which would imply graphics? 
> > Unless you mean pure command line driven menus where the selection (via 
> > text input) reveals another list of options which are dependent on the 
> > command just entered (a bit like the reaaallllyyy old text based 
> > adventure games you could run on the very first 8-bit home computers).
> 
> There are serial console characters which simulates the look and feel of
> dialog boxes and navigation menus, i.e. box edges, shadows. No actual
> pixel graphics are involved.

I think a lot of posters are overcomplicating things.  What about simple
number-based menus:

1. Load
2. Save
3. Settings
4. Factory reset
5. Power off
9. Help
0. Main menu
#. Speak to an operator
(ok, maybe don't include #)

then typing a number gets other submenus like this.

The advantage is this is easy to automate: type 0351 at any point and you
know you'll always end up at the same place (main menu->settings->...->...).
Parsing numbers is easy, and less pain than commands.

The code to implement this shouldn't be complicated, just make a data
structure with (function) pointers to handle each item or submenu.  The text
is probably the biggest memory footprint, after the code to implement
each function.

You can also drive this with cursors and a highlight bar, but I'd suggest
it's more hassle than the potential reward.  That's only useful if your
gadget has a display.

Theo

On 28/7/2014 6:19 PM, upsidedown@downunder.com wrote:
> Were are you going to display those menus, an a miniature display on
> the device itself or some external display ?

On a workstation that has a COM port. It is used for testing the said
embedded system.

> Where are the arrow keys, on the front panel of the device or
> somewhere else ?

The workstation has a keyboard.

> Does your device have a built i mouse or track ball or light pen or
> this external to your days.

No it is a standalone embedded that has no need for human interaction.

> Your approach would have made sense in the 1970-90's when dumb
> terminals, like VT100/VT220 were used. These had an addressable
> cursor, some line drawing characters and some controllable attributes,
> such as inverse video, blinking, underlining etc. In this case, you
> had to code your user interface into your product to allow real
> physical dumb terminals and later on terminal emulators, understanding
> the VT100 functionality.

I'm looking for something simple and easy on the memory footprint of the
embedded target.

> Once you have a very primitive command line processing on the embedded
> device, move the user interface to a more user friendly platform, such
> as any Windows machine and these days, even to some smart phones,
> which these days start to be more popular than tabletops or laptobs. 

I won't want to develop a full blown Windows GUI. Just a presentable
serial console will do.

> The problem is just how to perform the actual interface.
> Unfortunately, serial communication is rapidly becoming obsolete,
> perhaps a USB device with serial interface on your embedded system or
> perhaps Bluetooth might be an option.

That is a sad fact. But I am still optimistic that future workstations
will be equipped with at least 1 serial port. My new Dell Precision
T3610 workstation, which arrived earlier this year, even has a parallel
port. Otherwise, there will always be those USB-UART adaptors available.

Serial port will still enjoy popularity in embedded targets as it is
cheaper to implement compared to USB.

On Mon, 28 Jul 2014 20:08:59 +0800, Ang Zhi Ping <azhiping@dso.org.sg>
wrote:

>On 28/7/2014 6:19 PM, upsidedown@downunder.com wrote:


>> Once you have a very primitive command line processing on the embedded
>> device, move the user interface to a more user friendly platform, such
>> as any Windows machine and these days, even to some smart phones,
>> which these days start to be more popular than tabletops or laptobs. 
>
>I won't want to develop a full blown Windows GUI. Just a presentable
>serial console will do.

However, there are quite easily usable tools to do the Windows GUI,
compared to a small embedded system.

>> The problem is just how to perform the actual interface.
>> Unfortunately, serial communication is rapidly becoming obsolete,
>> perhaps a USB device with serial interface on your embedded system or
>> perhaps Bluetooth might be an option.
>
>That is a sad fact. But I am still optimistic that future workstations
>will be equipped with at least 1 serial port. My new Dell Precision
>T3610 workstation, which arrived earlier this year, even has a parallel
>port. Otherwise, there will always be those USB-UART adaptors available.
>
>Serial port will still enjoy popularity in embedded targets as it is
>cheaper to implement compared to USB.

These days, you have to carefully look, is it cheaper to add a
USB/serial converter, producing 5 V serial level signals, instead of
real MC1488/89 (+/-12 V) RS232 buffers.

On Mon, 28 Jul 2014 20:08:59 +0800, Ang Zhi Ping <azhiping@dso.org.sg>
wrote:

>On 28/7/2014 6:19 PM, upsidedown@downunder.com wrote:
>> Were are you going to display those menus, an a miniature display on
>> the device itself or some external display ?
>
>On a workstation that has a COM port. It is used for testing the said
>embedded system.
>
>> Where are the arrow keys, on the front panel of the device or
>> somewhere else ?
>
>The workstation has a keyboard.
>
>> Does your device have a built i mouse or track ball or light pen or
>> this external to your days.
>
>No it is a standalone embedded that has no need for human interaction.
>
>> Your approach would have made sense in the 1970-90's when dumb
>> terminals, like VT100/VT220 were used. These had an addressable
>> cursor, some line drawing characters and some controllable attributes,
>> such as inverse video, blinking, underlining etc. In this case, you
>> had to code your user interface into your product to allow real
>> physical dumb terminals and later on terminal emulators, understanding
>> the VT100 functionality.
>
>I'm looking for something simple and easy on the memory footprint of the
>embedded target.
>
>> Once you have a very primitive command line processing on the embedded
>> device, move the user interface to a more user friendly platform, such
>> as any Windows machine and these days, even to some smart phones,
>> which these days start to be more popular than tabletops or laptobs. 
>
>I won't want to develop a full blown Windows GUI. Just a presentable
>serial console will do.


The point is that doing a Windows GUI (or a Linux one), is going to be
less work in most cases that trying to do it on the device.  The tools
on those platforms are pretty good.  And then you can make the
interface to the device very small and quick, and if you want it
semi-human usable with just a TTY, just make it simple text commands
in a format like:

 command parm1,parm2...<cr>

with similar format responses, perhaps:

 resultcode value1,value2...<cr>

That would certainly result in the smallest code footprint on your
device.

You might add an (optional, if you wanted to allow the human usable
form) wrapper around those so that you could add a checksum, which
would only be used by the GUI application, which would improve the
reliability of the communications.

It's much more likely that you'd fit something like that into 4KB,
than a TUI like you described.

An additional advantage is that the command line/response approach
lends itself to scripting, and that may be useful in manufacturing and
test/diagnostics of the device.