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.)
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 (
formatting link
) - 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.
formatting link
Designed for microcontrollers. More than 107000 downloads in 2013.
formatting link
IoT, Trace, Certification, FAT FS, TCP/IP, Training, and more...
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'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!
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.
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.
I think a lot of posters are overcomplicating things. What about simple number-based menus:
Load
Save
Settings
Factory reset
Power off
Help
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.
On a workstation that has a COM port. It is used for testing the said embedded system.
The workstation has a keyboard.
No it is a standalone embedded that has no need for human interaction.
I'm looking for something simple and easy on the memory footprint of the embedded target.
I won't want to develop a full blown Windows GUI. Just a presentable serial console will do.
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.
However, there are quite easily usable tools to do the Windows GUI, compared to a small embedded system.
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.
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...
with similar format responses, perhaps:
resultcode value1,value2...
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.
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!!
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
formatting link
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.
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.
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.
In article , snipped-for-privacy@downunder.com says... ..
[off topic drift engaged]
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 | paul@pcserviceselectronics.co.uk
PC Services
Raspberry Pi Add-ons
Timing Diagram Font
For those web sites you hate
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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.