Terminal Emulation for Console I/O

[rickman]

I was expecting that it would be a simple matter to send control
sequences to the console which would allow code to be written that can
control the console in a system independent way. But I don't seem to
be able to find any code for this. When an app needs to put
information on the screen in other than a scrolling display, isn't
there a simple, system independent way to do that?

I am looking to define fields on the screen with numbers and labels.
The user will be able to move the cursor using the arrow keys and
update some of the fields. Then pressing the Enter key the data will
be sent to the target. Results will be collected from the target and
displayed in the various fields. This will be a bit like a the
register and memory display of a software debugger.

The idea was to be that the app would be written in a system
independent way, but it is looking like this is not going to be
practical.

Rick

[Jonathan Bromley]

On Mon, 5 Jan 2009 21:38:41 -0800 (PST), rickman wrote:

>I was expecting that it would be a simple matter to send control
>sequences to the console which would allow code to be written that can
>control the console

Which console? A console box on a desktop PC, or do you
mean a VDU connected to your FPGA-embedded CPU via a serial
or other comms link?

> in a system independent way. But I don't seem to
>be able to find any code for this. When an app needs to put
>information on the screen in other than a scrolling display, isn't
>there a simple, system independent way to do that?

Hah! There is an "ANSI standard" for smart VDUs - it's what
the old DEC VT100 family used to do, and many console programs
on windowing operating systems implement it to some extent.
But it's always been a mess, since time immemorial.
Way back when dinosaurs roamed, there was a Unix tool
called "curses" that tried to automate some of this stuff
and provide a uniform API to a variety of different terminals.
I don't know whether it still exists.

>I am looking to define fields on the screen with numbers and labels.
>The user will be able to move the cursor using the arrow keys and
>update some of the fields. Then pressing the Enter key the data will
>be sent to the target. Results will be collected from the target and
>displayed in the various fields. This will be a bit like a the
>register and memory display of a software debugger.
>
>The idea was to be that the app would be written in a system
>independent way, but it is looking like this is not going to be
>practical.

If I were you I would write the user front-end using Tcl/Tk,
which is completely portable across various windowing OS,
and have that Tcl/Tk app communicate with your real system
over whatever comms scheme is convenient - sockets communication
if the two processes are both running on desktop machines,
UART-style serial line if the user front end is on your
desktop and the real app is in an embedded system. Getting
Tcl/Tk to do this takes a bit of getting used to, but is
really easy when you know how. And it means that your "real"
application doesn't need to know anything at all about the
user front end, but can communicate in terms of simple
machine-friendly commands to update and read values.
And of course you can still use that "real" interface
from a normal console for low-level debugging.

We've even played with this to put a GUI-style front end
on a VHDL simulation using Tcl's "command pipeline"
mechanism, although that takes some jumping through hoops.

If this idea is interesting, I can post some toy examples.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
[email protected]
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

[Marcus Harnisch]

Jonathan Bromley <[email protected]> writes:

> Way back when dinosaurs roamed, there was a Unix tool
> called "curses" that tried to automate some of this stuff
> and provide a uniform API to a variety of different terminals.
> I don't know whether it still exists.

http://www.gnu.org/software/ncurses/ncurses.html

Curses is still in use. Try this to get a taste:
http://freshmeat.net/browse/227/

Regards
Marcus

--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]

(seen on http://www.veripool.com/verilog-mode_news.html)

[rickman]

Opps, I shouldn't post in my sleep. I posted this to the wrong
group. Sorry...


On Jan 6, 12:38*am, rickman <[email protected]> wrote:
> I was expecting that it would be a simple matter to send control
> sequences to the console which would allow code to be written that can
> control the console in a system independent way. *But I don't seem to
> be able to find any code for this. *When an app needs to put
> information on the screen in other than a scrolling display, isn't
> there a simple, system independent way to do that?
>
> I am looking to define fields on the screen with numbers and labels.
> The user will be able to move the cursor using the arrow keys and
> update some of the fields. *Then pressing the Enter key the data will
> be sent to the target. *Results will be collected from the target and
> displayed in the various fields. *This will be a bit like a the
> register and memory display of a software debugger.
>
> The idea was to be that the app would be written in a system
> independent way, but it is looking like this is not going to be
> practical.
>
> Rick

[HT-Lab]

"Jonathan Bromley" <[email protected]> wrote in message
news:[email protected]...
> On Mon, 5 Jan 2009 21:38:41 -0800 (PST), rickman wrote:
>
...
> But it's always been a mess, since time immemorial.
> Way back when dinosaurs roamed, there was a Unix tool
> called "curses" that tried to automate some of this stuff

I think you are wrong, curses came after the dinosaurs, ASR33 terminal were
used during that time (if my memory serves me correctly)

...
> If I were you I would write the user front-end using Tcl/Tk,
> which is completely portable across various windowing OS,
> and have that Tcl/Tk app communicate with your real system
> over whatever comms scheme is convenient - sockets communication

I can't agree more, here is a simple example:

http://www.ht-lab.com/howto/remotemti/remote_modelsim.html

> Hah! There is an "ANSI standard" for smart VDUs - it's what
> the old DEC VT100 family used to do, and many console programs
> on windowing operating systems implement it to some extent.

I just had another look at the VT100 spec and it is actually quite powerful.
Apart from the graphics based characters (to create borders/boxes etc) it
also supports a "report cursor position" ESC sequence. I know the OP posted
this to the wrong newsgroup, but for anybody who want to add a portable text
based UI to their testbench/virtual prototype then check out the good old
VT100 standard.

> if the two processes are both running on desktop machines,
> UART-style serial line if the user front end is on your
> desktop and the real app is in an embedded system.
> Getting
> Tcl/Tk to do this takes a bit of getting used to, but is
> really easy when you know how. And it means that your "real"
> application doesn't need to know anything at all about the
> user front end, but can communicate in terms of simple
> machine-friendly commands to update and read values.
> And of course you can still use that "real" interface
> from a normal console for low-level debugging.
>
> We've even played with this to put a GUI-style front end
> on a VHDL simulation using Tcl's "command pipeline"
> mechanism, although that takes some jumping through hoops.
>
> If this idea is interesting, I can post some toy examples.

Please do. I am pretty sure that a lot of EDA users (incl myself) don't
fully appreciate the power of Tcl/TK. I spend considerable time create a
Modelsim Terminal interface using Modelsim's FLI. Using Tcl (or a thin
SystemC layer) is much much easier.

Hans
www.ht-lab.com


> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> [email protected]
> http://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.