Graphics based terminal emulator for windows development

There are many terminal emulators out there, most of which were designed to actually emulate a specific legacy terminal. There are emulators for the VT100, VT220, VT320, VT420, 3270, 5250, Tek 4010, and so on, and so on...

There are even terminal emulators that emulate X-terminal terminals on X-windows networks.

I have been working with the EZLCD-004 color LCD lately, which I communicate with over RS-232, and it occurred to me how nice this would be to have on a PC - for development.

http://store.earthlcd.com/ezLCD-004-ezLCD004?sc=7&
category=297

I currently use Hyperterminal for debugging on my PC, and I have actually written a library of ANSI control code functions to dress up the output, which include limited ASCII characters, colors, and position control.

But text based stuff is so boring, and if an API was written, along with a graphics terminal emulator, that could run on a PC, I could really dress up my debugging. In fact, I could do things like the temperature data-logger project, and plot a graph of temperature on the PC monitor...For that matter, I could just design embedded products that plug into the PC by either the RS-232 or a USB port, and all user I/O could come from the PC...

I have been searching the NET, trying to find something that would either let me send HTML scripts, or some primitive graphics commands from my embedded system over the RS-232 interface, and display them in a window on my PC, but haven't found anything yet.

If anyone out there knows of such a program, I'd like to know about it...

Otherwise, I think I'm going to start a project: Writing a program that will run on Windows that will not only support two-way communication between the PC and the COM port, but also support a limited set of graphics commands that will allow my embedded system to draw graphics on the PC window...

Thanks in advance,

-Dave

interesting never had that kind of idea in mind

do you have any small graphic example of what you want? I am not able to imagine what kind of gfx command you want on windows..

Well, for instance - there are many windows based applications that act as a "front end" for an embedded device that connects to the PC by the USB port. An example of this would be a PC based o-scope, or a PC based logic analyzer. These embedded devices are slaved devices. They get there commands from the host software running on the PC.

Well, while developing an embedded system, I use the PC for not only troubleshooting, like sending test strings over the COM port to Hyperterminal, but I'd also like to simulate system output, like maybe have the PC window look and feel like the color display on the actual target system.

Additionally, I often write code that can be used as a utility interface to the embedded system, that otherwise would never show up in the final released product, but provides a handy way of interfacing to the system over a remote interface like the COM port (I could see our field service guys carrying a laptop out in the field, plugging into the system, and running a diagnostic program from the PC to help them figure out what exactly was going on)...

Well, it seems like if the terminal emulator software they had could not only display simple ASCII characters, but also provide some limited graphics capabilities, the embedded system could not only dump raw data out to the PC, but it could also generate simple graphs - remember, a picture is worth a thousand words... :-)

I ran into this exact thing while building the SD memory card routines. I wanted to be able to look at the directory on the SD card, and provide functions like DIR, DEL, COPY, HELP, and so on, but I also wanted to be able to have a PLOT function (for plotting the raw temperature date I had gathered).

My screen could have looked like this if I had some graphics primitives to play with...

The idea here is to have a generic window on the PC that the embedded system can control - Now the embedded system is the master and the PC is the slave, just like it is within Hyperterminal.

I can currently change the colors within Hyperterminal, move the cursor around to any location on the screen, and draw simple block-graphics using the ASCII characters.

What if could also send simple commands like drawing a line, or drawing a box, and the PC screen would reflect these as well?

That's the idea...

Dave

My impression is that you want a way for the embedded device to draw
graphics on the PC.
Taking your example, the embedded device would send graph
drawing commands to the PC.

Surely it is more flexible to just transmit data, and let a custom program
on the PC create a graphical representation.

>My screen could have looked like this if I had some graphics primitives to play with

You could get the same or better, running a PC program written for the job.
Hyperterminal is just too limited for you.

You are correct about two things: I want a way for the embedded device to draw graphics on the PC, and Hyperterminal is just too limited for me...

The part to debate is whether or not flexibility is maintained by having the custom program on the PC create a graphical representation for me...

Having a PC program receive data means the PC program is responsible for where the data gets graphed. Having the embedded system draw the graphics means different applications can do different things.

Granted, there is more overhead in having the embedded system do the graphing, but the flexibility is greater (I think...).

Having a PC program that is generic, much like a graphics controller driving an LCD, means the PC window is an open palette, and I can do whatever I want there.

The processors now-a-days are faster, and have a lot more flash memory in them, not to mention the applications are larger, as banking memory has become quite popular.

Besides, this kind of utility program could be used by a variety of systems, where data might be different from system to system...

Any thoughts?

-Dave

wow, for a while i thought that image u posted is for real really nice i would be surprised if it was/is real

well we can develop a something similar terminal application that can do the same u want? I mean its like developing a canvas with some specif set of commands to draw write or do whatever on that canvas. hows that idea?

The part to debate is whether or not flexibility is maintained by having the custom program on the PC create a graphical representation for me...
Any thoughts?

DavesGarage

I flip flopped a bit on this, and came to think generating the display/interpreting the data
is best done by the PC.
I did think that the embedded device programmer know his program best so
is well placed to decide what is displayed and how.

But for me the key points are...
For fault finding etc the site engineer may want to display different info,
and what is wanted may change over time.

The kind if display would always be improved by the embedded device programmer.
His display of two years ago may look very different to the latest version.
Visiting engineers may be mislead (lost) if data that looks different
to what they are used to.

For fault finding etc the site engineer may want to display different info,
and what is wanted may change over time.

Even if the "site" engineer wanted to display something different, the embedded system would have to be modified to send the specific data the site engineer wanted, right? A change in specific data would require changing both the embedded software AND the PC application. Double duty...

Since the target embedded system is in a machine, and machines periodically get software upgrades, the embedded system would always be up to date with whatever data the visiting field service guy needs to evaluate the system. There wouldn't be any need to update the app program running on his laptop if it were a generic terminal...

His display of two years ago may look very different to the latest version.
Visiting engineers may be mislead (lost) if data that looks different
to what they are used to.

I'm not so sure I agree here...There are no random "visiting" engineers, just field service technicians, and they are sent, usually because it's time for the annual maintenance, or because the customer called and said something funny is happening. Each new software release comes with a service bulletin, which informs field service techs about new features, and what to expect from diagnostic routines...There should be no surprises...

Just thinking out loud...

-db

@Ajay,

Yeah - that's what I was thinking...

I could even make it's screen size scalable, like Hyperterminal is, but in pixel units, so it could be used to remotely emulate a color LCD, like the EZLCD I mentioned. I could write wrapper functions for the graphics commands the work with the EZLCD display, and send the same looking screens to a PC for desk development...

Even if the "site" engineer wanted to display something different, the embedded system would have to be modified to send the specific data the site engineer wanted, right? A change in specific data would require changing both the embedded software AND the PC application. Double duty...

DavesGarage

To some extent yes, but the embedded device can easily be instructed to
upload large chunks of data.. probably all its data.
A well thought out data retrieval program may last
many years without modification.

The PC program can then use whatever data it wants, and interpret it as required.
How the data is interpreted and displayed is decided by the engineer according to
his (or her) preferences.

There wouldn't be any need to update the app program running on his laptop if it were a generic terminal...

DavesGarage

True, but updating the PC program is easy, whether you think its easier
that updating embedded software probably depends on which you
are most comfortable with.

His display of two years ago may look very different to the latest version.
Visiting engineers may be mislead (lost) if data that looks different
to what they are used to.

I'm not so sure I agree here...There are no random "visiting" engineers, just field service technicians, and they are sent, usually because it's time for the annual maintenance, or because the customer called and said something funny is happening. Each new software release comes with a service bulletin, which informs field service techs about new features, and what to expect from diagnostic routines...There should be no surprises...

DavesGarage

"or because the customer called and said something funny is happening."
We used to call them faults
needing a visit at short notice possibly by a technician not familiar
with the particular equipment.

OK your technicians are true professionals, they read and digest
the service bulletins and there are no surprises, but life can
still be made easier for them