Low memory footprint UART-based text user interface

[Ang Zhi Ping]

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

[MK]

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

[FreeRTOS info]

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

[Ang Zhi Ping]

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.

[Don Y]

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!

[upsid...@downunder.com]

On Mon, 28 Jul 2014 08:44:45 +0100, MK <m...@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.

[Theo Markettos]

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

[Ang Zhi Ping]

On 28/7/2014 6:19 PM, upsid...@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.

[upsid...@downunder.com]

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

>On 28/7/2014 6:19 PM, upsid...@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.

[Robert Wessel]

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

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.

[Grant Edwards]

On 2014-07-28, Ang Zhi Ping <azhi...@dso.org.sg> 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?

It sounds to me like you're talking about something like a curses/menu
type system. I really doubt you can do that in 4KB of memory. Maybe
20KB, but 4KB is going to be really, really tough.

If 4KB is all you've got, you probably need to implement some simple
command protocol and then write a UI to run on the host computer (I'd
use Python for that part of it, but that's me.)

--
Grant Edwards grant.b.edwards Yow! I'm having a
at tax-deductible experience!
gmail.com I need an energy crunch!!

[Sp...@controlq.com]

On Mon, 28 Jul 2014, Grant Edwards wrote:
>
> It sounds to me like you're talking about something like a curses/menu
> type system. I really doubt you can do that in 4KB of memory. Maybe
> 20KB, but 4KB is going to be really, really tough.
>
> If 4KB is all you've got, you probably need to implement some simple
> command protocol and then write a UI to run on the host computer (I'd
> use Python for that part of it, but that's me.)

BINGO!

implement a small CLI with a command protocol, and write a host side app
in curses, tk, Kivvy, javascript, or whatever!!! Your CLI will
work/suffice for an expert with a terminal emulator, and for the great
unwashed, you provide a user interface which they can understand. Voila!

Cheers,
Rob.

[Theo Markettos]

Sp...@controlq.com wrote:
> BINGO!
>
> implement a small CLI with a command protocol, and write a host side app
> in curses, tk, Kivvy, javascript, or whatever!!! Your CLI will
> work/suffice for an expert with a terminal emulator, and for the great
> unwashed, you provide a user interface which they can understand. Voila!

It really depends on what the target environment is.

If it's something where there's always a specific computer about, then fine.
Like a lathe that has a PC next door for driving jobs. Install app on PC
once, forget about it. It's still there 10 years later, no problem.

If it's software that's easy to make ubiquitous, then fine. eg javascript
app that can talk to the local serial port, just point go to www.example.com
and run the app. But I suspect making enough holes in the Javascript
security model for this to work is going to be awkward. An alternative
would be a single .exe that you can just download and run (though again
security could be an issue)

The middle ground is where installing the app becomes a pain. For example,
we had an instrument on test last week (whose big-name manufacturer will
remain nameless). There was a little screen and 4 buttons by the side of
the screen as the UI. This got very tedious very quickly. But there was a
Windows app.

However, it's only a Windows app. Not a Mac app or a Linux app, which is
what I would want to use. OK, it's only on test, dump it in a Windows VM.
It runs, talks to the instrument, and... segfaults. Repeatedly.

Some googling later I discover that the 32 bit Windows app doesn't work on
64 bit Windows. But there's a 64 bit Windows app (hidden away). That
doesn't segfault. However it randomly goes into hissy fits and refuses to
acknowledge the existence of the instrument, despite that I can telnet into
the instrument from inside the Windows VM so it's definitely alive.

The app itself (a .NET thing) is OK, has a nice GUI but is a bit thin in
that it's just an interface to some GPIB commands: it doesn't do much
clever that I couldn't do by reading the GPIB manual. It basically
duplicates the on-instrument GUI without having to go via those little 4
buttons. I'm sure there are cleverer things that could be done given
there's a PC at its disposal.

And usually what happens is that the app will refuse to work on Windows 9
when that is released and no fixes appear because the manufacturer can't be
bothered any more.



The bottom line is, with a USB serial port you can be sure you're talking to
the thing. It works on any machine that can use a USB serial port. It
doesn't need software beyond the USB CDC driver. It'll work on any machine,
any OS, with no setting up whatsoever. If a menu system, it needs no
manual, it is self-documenting. It is easy to discover the functionality
available. And, most importantly, it's very difficult to mess up the client
side.

Theo

[Ang Zhi Ping]

On 28/7/2014 11:14 PM, Grant Edwards wrote:
> It sounds to me like you're talking about something like a curses/menu
> type system. I really doubt you can do that in 4KB of memory. Maybe
> 20KB, but 4KB is going to be really, really tough.

Yes a curses library for embedded targets, preferably one that does not
require an OS to run on.

> If 4KB is all you've got, you probably need to implement some simple
> command protocol and then write a UI to run on the host computer (I'd
> use Python for that part of it, but that's me.)

That is what I'm trying to avoid by looking around for some ready made
libraries.

[Ang Zhi Ping]

On 28/7/2014 7:45 PM, Theo Markettos wrote:
> 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.

Sounds like a good idea. Maybe dialogs can be dispensed all together...

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

If only navigating an automated call machine can be as simple as what
you have mentioned *hehe*

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

The terminal output is intended for debugging/troubleshooting purposes.

[Ang Zhi Ping]

On 28/7/2014 8:40 PM, upsid...@downunder.com wrote:
> On Mon, 28 Jul 2014 20:08:59 +0800, Ang Zhi Ping <azhi...@dso.org.sg>
> wrote:
>
>> On 28/7/2014 6:19 PM, upsid...@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 debugging may be performed by any sort of machine (beyond my
control), thus it is preferable not to rely on a Windows GUI because an
executable has to be distributed. Hosting a TUI on the device itself is
the most portable way of ensuring any computer equipped with a COM port
is able to view the debug messages.

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

That is true.

[Ang Zhi Ping]

Sounds like GDB remote serial protocol. Which leads me to wonder why
Altera do not support RSP via serial.

Ah maybe I should start another thread about RSP as this is pretty
interesting!

[Rob Gaddi]

On Tue, 29 Jul 2014 20:14:53 +0800

Ang Zhi Ping <azhi...@dso.org.sg> wrote:

> On 28/7/2014 7:45 PM, Theo Markettos wrote:
> > 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.
>
> Sounds like a good idea. Maybe dialogs can be dispensed all together...
>

Agreed, that's the way to go. Among other major advantages, it saves
you having to worry about what terminal the PC side is emulating.
ANSI? VT100? They all use different control codes, and you'd have to
interrogate their terminal (also only support sometimes) then pick the
right control code set.

This way, everything you ever write out is a readable character for the
user, and one where you don't really care desperately about what
position it winds up at. Any terminal, no matter how stupid, will just
work.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

[Paul]

In article <7q7ct91s0hnhvokl7...@4ax.com>,
upsid...@downunder.com says...
..

[off topic drift engaged]

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

Even then a lot had programmable character sets, colour, even graphics
remember VT30-S, VT35 (had prototype as console on my bench PDP-11/10),
VT103.....

Yes often the colour was only 8 colours but that was more about limits
of cheap DACs and memory chip sizing in those days.

--
Paul Carpenter | pa...@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/pi/> Raspberry Pi Add-ons
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.badweb.org.uk/> For those web sites you hate

[Nils M Holm]

upsid...@downunder.com wrote:
> Your approach would have made sense in the 1970-90's when dumb
> terminals, like VT100/VT220 were used.

I have always thought that the VT100 was an "intelligent" terminal,
because it could move the cursor, clear the screen, change display
attributes, etc. The ASR 33 was a dumb terminal.

--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org

[Robert Wessel]

On 1 Aug 2014 17:51:33 GMT, Nils M Holm <news...@t3x.org> wrote:

>upsid...@downunder.com wrote:
>> Your approach would have made sense in the 1970-90's when dumb
>> terminals, like VT100/VT220 were used.
>
>I have always thought that the VT100 was an "intelligent" terminal,
>because it could move the cursor, clear the screen, change display
>attributes, etc. The ASR 33 was a dumb terminal.

It was. Modern usage often considers anything with no local
processing to be a dumb terminal. Ultimately the distinctions are not
that meaningful. Or precise.