In all my embedded DSP based products I use an RS232 port (driven with printf) as a means of seeing whats going on inside a CPU or DSP. I am looking for a way to increase the flexability of the displayed data since there is often data from differnt processes all competing for my attention before it scrolls off the screen. I was considering using an X Windows terminal emulator program (which I know very little about at this point) as a means for interacting with my embedded projects. It would be great if I could fire up an Xwindows terminal emulator program on my Windows PC, choose COM2, 19200 8N1 and BAM! display graphical data from a small embedded device. Since the available memory left over for debug-related code tends to be on the order of a few kbytes, the embedded device would only be sending printfs containing the most basic of Xwindows commands. Has anyone done something similar to this? Is there a better way to get a tiny embedded device to control a standardized graphical debug interface? Thanks, -howy
Using an X Windows Terminal as an RS232 debug interface
Started by ●August 20, 2007
Reply by ●August 20, 20072007-08-20
On 2007-08-20, howy <howyhowy@gmail.com> wrote:> I was considering using an X Windows terminal emulator program (which > I know very little about at this point) as a means for interacting > with my embedded projects. It would be great if I could fire up an > Xwindows terminal emulator program on my Windows PC,What? It isn't at all clear what you mean by "fire up an X Windows terminal emulator program on my Widnows PC". You want to run an Xterm and have it run and display on your windows machine or run on your Windows machine and display elsewhere?> choose COM2, 19200 8N1 and BAM! display graphical data from a > small embedded device.Huh? X Windows terminal emulators don't typically do graphics (unless you count xterm's Tektronix 4xxx emulation). They're just text terminals.> Since the available memory left over for debug-related code > tends to be on the order of a few kbytes, the embedded device > would only be sending printfs containing the most basic of > Xwindows commands.You seem to be laboring under a fundamental misunderstanding of what a X Windows terminal emulator does. It's typically just a ANSI terminal emulator that runs under X Windows. It doesn't do graphical X protocol stuff via the serial port.> Has anyone done something similar to this? Is there a better > way to get a tiny embedded device to control a standardized > graphical debug interface?X Windows terminal emulators aren't graphical (except for xterm's emulation of an old Tektronix storage-tube terminal). -- Grant Edwards grante Yow! My pants just went to at high school in the Carlsbad visi.com Caverns!!!
Reply by ●August 20, 20072007-08-20
> Huh? X Windows terminal emulators don't typically do graphicsThat may explain my confusion when trying to Google for info on this concept. Back in the late 1980's to early 1990's when Unix work stations transitionsed from text-based to graphical interfaces (at least thats when I saw it happening in college), I was under the impression that the graphical user interface was based on a stream of ASCII commands similar to PostScript. Maybie it WAS postscript... But at any rate these graphical dumb terminals were communicating over a network using a human-readable ASCII protocol (similar to the concept of HTML but much more user readable). Was I on drugs or was there some GUI interface that used an ASCII serial stream at its lowest level (not HTML but similar in concept)? -howy
Reply by ●August 20, 20072007-08-20
howy <howyhowy@gmail.com> writes:> I was under the impression that the graphical user interface was > based on a stream of ASCII commands similar to PostScript. Maybie it > WAS postscript...You're probably thinking of Display Postscript, not X. Still, it sounds like you need something more like syslog than X or DP. All that means is that each printf() gets an extra parameter or two that says where the message is coming from, and it's "level" (verbosity, severity, whatever). You store all the messages on the development machine, and you can filter them later. You'd need to design a simple encapsulation protocol, but that shouldn't be hard. A few bytes for a header with type/size, then many bytes for the message.
Reply by ●August 20, 20072007-08-20
On 2007-08-20, howy <howyhowy@gmail.com> wrote:>> Huh? X Windows terminal emulators don't typically do graphics > > That may explain my confusion when trying to Google for info > on this concept. > > Back in the late 1980's to early 1990's when Unix work > stations transitionsed from text-based to graphical interfaces > (at least thats when I saw it happening in college), I was > under the impression that the graphical user interface was > based on a stream of ASCII commands similar to PostScript. > Maybie it WAS postscript...You may be thinking of "display postscript", a scheme unrelated to X Windows that Sun used in it's first foray into GUIs. http://en.wikipedia.org/wiki/Display_PostScript http://partners.adobe.com/public/developer/ps/sdk/index_archive.html#dps Or you might be thinking of AT&T's MGR windowing system: it was based on in-band escape sequences. http://www.hack.org/mc/mgr/ http://en.wikipedia.org/wiki/ManaGeR http://tldp.org/HOWTO/archived/MGR-HOWTO/ MGR was a cute little system. I had it running under a Unix v7 clone on an 80286 for a while. It didn't require any networking facilities at all -- everything was done in-band via ptys. The X protocol is binary and runs over either TCP or Unix domain sockets. You could establish a PPP connection and then send X protocol commands from the embedded system to an X server running on the host (under Windows or Unix).> But at any rate these graphical dumb terminals were > communicating over a network using a human-readable ASCII > protocol (similar to the concept of HTML but much more user > readable). > > Was I on drugs or was there some GUI interface that used an > ASCII serial stream at its lowest level (not HTML but similar > in concept)?That sounds like either MGR or Display Postscript to me (though I know little about the latter). The X protocol is a pretty complex binary protocol that runs over network connections. -- Grant Edwards grante Yow! I want to so HAPPY, at the VEINS in my neck STAND visi.com OUT!!
Reply by ●August 20, 20072007-08-20
On 2007-08-20, DJ Delorie <dj@delorie.com> wrote:> > howy <howyhowy@gmail.com> writes: >> I was under the impression that the graphical user interface was >> based on a stream of ASCII commands similar to PostScript. Maybie it >> WAS postscript... > > You're probably thinking of Display Postscript, not X. > > Still, it sounds like you need something more like syslog than X or > DP.Except I think he wants to do graphical stuff... -- Grant Edwards grante Yow! I just bought at FLATBUSH from MICKEY visi.com MANTLE!
Reply by ●August 20, 20072007-08-20
> You're probably thinking of Display Postscript, not X. > Still, it sounds like you need something more like syslog than X or..OK, thanks I will look into that. I was hoping there was a standard terminal emulator protocol (like a graphical version of a VT100 terminal) that would allow me to place a few buttons, graphs, and text windows on the PC's screen and maybe even accept user input commands like button press events and keyboard input - over a low bitrate serial stream. -howy
Reply by ●August 20, 20072007-08-20
howy <howyhowy@gmail.com> writes:> I was hoping there was a standard terminal emulator protocol (like a > graphical version of a VT100 terminal) that would allow me to place > a few buttons, graphs, and text windows on the PC's screen and maybe > even accept user input commands like button press events and > keyboard input - over a low bitrate serial stream.Ok, not syslog then. That's for debug messages and the like. Sounds more like Display Postscript, unless you want to do X over PPP, but that's pretty heavy-weight.
Reply by ●August 21, 20072007-08-21
Il 21/08/2007 0.48, howy ha scritto:> I was hoping there was a standard terminal emulator protocol (like a > graphical version of a VT100 terminal) that would allow me to place a > few buttons, graphs, and text windows on the PC's screen and maybe > even accept user input commands like button press events and keyboard > input - over a low bitrate serial stream. >Check EmWare's EMIT. If you have little space left on your micro, could be an easy way to add a graphical interface. Basically, your micro sends events and receives commands with a proprietary protocol. On the PC, a gateway renders this in a dynamic web page, that could be delivered also on the net, or locally. The www.emware.com site doesn't point to the company anymore... Anyone knows if it's still in businness ?
Reply by ●August 21, 20072007-08-21
howy <howyhowy@gmail.com> writes:> In all my embedded DSP based products I use an RS232 port (driven with > printf) as a means of seeing whats going on inside a CPU or DSP. > > I am looking for a way to increase the flexability of the displayed > data since there is often data from differnt processes all competing > for my attention before it scrolls off the screen. > > I was considering using an X Windows terminal emulator program (which > I know very little about at this point) as a means for interacting > with my embedded projects. It would be great if I could fire up an > Xwindows terminal emulator program on my Windows PC, choose COM2, > 19200 8N1 and BAM! display graphical data from a small embedded > device. Since the available memory left over for debug-related code > tends to be on the order of a few kbytes, the embedded device would > only be sending printfs containing the most basic of Xwindows > commands. > > Has anyone done something similar to this? Is there a better way to > get a tiny embedded device to control a standardized graphical debug > interface?Web server? Not done it myself, but there are several projects implementing cut-down "tiny" web servers on small micros (even PICs). In your case you could use SLIP over RS232. -- John Devereux