GUI Terminal Client
Peter Jakacki
Posts: 10,193
Note: This post is not strictly about Propeller chips but more about what Propeller chips and others communicate to on the PC. It may be sandboxed but I like to kick it off here.
There are many times where I will specify a serial terminal on a PC as the only PC side interface to an embedded device. Typically many of my products have a USB serial port that is used for development and also by the end-user or installer to setup and configure the equipment via Hyperterminal and TeraTerm style serial terminals. But the user interface is limited to fixed sized text and simple line graphics and 8 colors in the case of these ANSI capable terminals listed. So the whole menu and interaction is dictated by the embedded device through the serial link and the terminal emulator is a dumb client. Certainly not a friendly modern interface, more like what we had back in the 70's and early 80's.
These ANSI terminals are decades old and so the emulators just do pretty dumb text and that's it but what is stopping us from transforming the humble terminal emulator into a GUI client/terminal. This client could be controlled via the serial port or any other connection or even internally from other applications using nothing more than a two-way communications pipe. By sending a certain command sequence from the server which in this case would be the embedded device over the serial port we can rather than display plain text instead call up forms and dialog boxes that can be navigated using the keyboard, mouse, or any other input device of the PC. The result is the client application looks like any other windows application with title bar and menus etc but totally dictated from the embedded device or server.
Take a simple PC calculator application for instance, although this may be of no practical use we can visualize this easily and to assist I have attached a screenshot of one. This could be created from the embedded device using no other PC software but the GUI terminal. The embedded application (server) would send command sequences to open a new window, set the title, specify the menus, buttons and labels, and a display window. When the user clicks the "9" button or uses the keyboard then that would send back the character 9 or sequence preset for that action. The server would then send back the display update as 9 and then imagine we now press "+","3","=" and so the display updates accordingly but all controlled from the server, not the PC. This client software can even be cross-platform to run on Windows, Linux, and OSX for instance much like Brad's BST.
I spoke to Brad about this as well and I am not aware of any software currently available that does this. There must be a big demand for this type of thing and I can see that special PC applications can be created simply using this standard software plus custom software on the embedded device. In the case of the Propeller chip I would store a lot of the server side software and tables either in the EEPROM, or DataFlash, or SD memory card.
My PC skills are ok but I'm no guru. I would like to see this project being an open-source project that can be developed, expanded, and maintained by many contributors. As open-source anybody can download it and use it just as they use terminal emulators now. The advantages are that the user gets a modern easy to use GUI on their PC and platform while the embedded application doesn't have to worry about the PC platform itself but talks to it just like it was talking to a terminal emulator. Also many USB serial ports are capable of running at mega-baud speeds when there is a direct connection from the embedded processor to it's USB chip and so this also permits very fast GUI updates.
Thoughts anyone?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
There are many times where I will specify a serial terminal on a PC as the only PC side interface to an embedded device. Typically many of my products have a USB serial port that is used for development and also by the end-user or installer to setup and configure the equipment via Hyperterminal and TeraTerm style serial terminals. But the user interface is limited to fixed sized text and simple line graphics and 8 colors in the case of these ANSI capable terminals listed. So the whole menu and interaction is dictated by the embedded device through the serial link and the terminal emulator is a dumb client. Certainly not a friendly modern interface, more like what we had back in the 70's and early 80's.
These ANSI terminals are decades old and so the emulators just do pretty dumb text and that's it but what is stopping us from transforming the humble terminal emulator into a GUI client/terminal. This client could be controlled via the serial port or any other connection or even internally from other applications using nothing more than a two-way communications pipe. By sending a certain command sequence from the server which in this case would be the embedded device over the serial port we can rather than display plain text instead call up forms and dialog boxes that can be navigated using the keyboard, mouse, or any other input device of the PC. The result is the client application looks like any other windows application with title bar and menus etc but totally dictated from the embedded device or server.
Take a simple PC calculator application for instance, although this may be of no practical use we can visualize this easily and to assist I have attached a screenshot of one. This could be created from the embedded device using no other PC software but the GUI terminal. The embedded application (server) would send command sequences to open a new window, set the title, specify the menus, buttons and labels, and a display window. When the user clicks the "9" button or uses the keyboard then that would send back the character 9 or sequence preset for that action. The server would then send back the display update as 9 and then imagine we now press "+","3","=" and so the display updates accordingly but all controlled from the server, not the PC. This client software can even be cross-platform to run on Windows, Linux, and OSX for instance much like Brad's BST.
I spoke to Brad about this as well and I am not aware of any software currently available that does this. There must be a big demand for this type of thing and I can see that special PC applications can be created simply using this standard software plus custom software on the embedded device. In the case of the Propeller chip I would store a lot of the server side software and tables either in the EEPROM, or DataFlash, or SD memory card.
My PC skills are ok but I'm no guru. I would like to see this project being an open-source project that can be developed, expanded, and maintained by many contributors. As open-source anybody can download it and use it just as they use terminal emulators now. The advantages are that the user gets a modern easy to use GUI on their PC and platform while the embedded application doesn't have to worry about the PC platform itself but talks to it just like it was talking to a terminal emulator. Also many USB serial ports are capable of running at mega-baud speeds when there is a direct connection from the embedded processor to it's USB chip and so this also permits very fast GUI updates.
Thoughts anyone?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
308 x 398 - 23K
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
T o n y
Except it's neither open source, nor cross platform..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I found something similar to what I am asking, it's a plea for Unix GUI reform: the Graphics Terminal.
www.xs4all.nl/~evbergen/groklaw-gui-terminal.html
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
I too am frustrated by the current GUI software on the PC. Most users are now unaware of the response times we used to get from minis and mainframes with the old text terminals. The terminals (pcs) are now so much faster yet, for instance, but data entry is so much slower.
I have refused to move on to VB.NET because it just seems to be a more complex way of doing things, not easier. I have stuck with VB6 for that side of things, but the GUI is certainly not easy. And, it is not easy to port to other OSes such as *nix & mac.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
What you want to do is already possible by having the GUI in the Web Browser Client (Cluso99 mentions using a Web Browser) and running a Web Server on the Propeller. It comes down to writing JavaScript/HTML, etc... and storing it on the Propeller. A few years ago I did this and it worked very well for one Web Browser Client connection. It is though as you say complicated today, but a PC program can solve that.
In short, it would be workable for a PC program to act as a "proxy" with the Propeller serial interface. The PC program would translate Web Browser requests and forward them to the Propeller and take responses from Propeller and stuff it into TCP/IP packets for the Web Browser. Using such a program removes the requirement to have Propeller running TCP/IP via a network interface.
Added:
On the other hand, keeping the complexity with Propeller (TCP/IP and maybe replace Ethernet with a SLIP serial port) provides a cross-platform solution with a Web Browser now without any PC or other platform programming.
In any case using a Web Browser would require knowing HTML for page display and JavaScript or other for handling button events. It is not that hard and might actually enhance your skill set if that's what you want.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers? Not available at this time since I think you deserve more information than you requested.
Post Edited (jazzed) : 3/18/2010 7:37:07 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away
[url=http:///www.freebasic.net/forum/viewtopic.php?t=14366&start=30]http:///www.freebasic.net/forum/viewtopic.php?t=14366&start=30[/url]
Search for Tek 4xxx series escape codes, and the command line option for "xterm".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Just stop thinking "terminal" although I am describing it as such because it replaces and supersedes a text (and graphics) terminal. It's a GUI which means a user interface based on graphics, not just graphics. When we write a simple VB application for instance we have a form designer and we can define the menus, the buttons, the dialog boxes etc. So imagine if we write an application that is able to display these buttons and menus etc at run-time under serial/stream control.
I may have to sit down and cobble something together to get it started, I know what I want, what is needed, and that it would be a universal app just as the old terminal and terminal emulators were universal. With the GUI Term or whatever you could still do your default text stuff which I would always want too but like the Transformers it can transform into a calculator (interface) if told too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers?
Not available since you deserve more information than you requested.
May the road rise to meet you; may the sun shine on your back.
May you create something useful, instead of just another hack.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
I think I understand what you're wanting, and agree there's a definite need. PhiPi has created neat "tuning" apps for the TSL1401 and bell modem, but the ability to generate these "on the fly" from the prop end would be very useful
I'm imaging something like a VB form with a whole variety of components loaded but disabled and hidden. You then have access to all the normal object settings such as form.visible=true, size and positioning etc, using say serial escape strings. That much should be relatively straightforward, but doing the event handling for the returned information is where it gets interesting. I guess it would be possible to have the usual VB events (loss of focus, data change, mouseover etc) return an escape string back to you, with programmable content set by the prop side (and default to null strings initially)
I think the advantage of a VB approach and language syntax is that we have some chance of being familiar with the commands. Not sure about cross platform though.
There are several other approaches of course, but they tend towards a net/browser connection (eg SVG) instead of serial
cheers
tubular
Stream encoding can be implemented as 7-bit data + 1-bit control with all data and characters sent as multiples of 7-bits with the 8-bit bit set to zero. This makes it compatible with standard ASCII and by setting the 8th bit we are indicating a command or control to be interpreted far beyond the simple CR, LF sequences etc. Although escape sequences can be sent I always cringe at the thought of stream corruption and loss of synchronization that would result in a total misinterpretation of the message plus the incompatibility with binary data. I have used the 7+1 method for variable length fields and records packed in RAM and it is a very reliable method of marking what is and what isn't data, where a field begins. In fact many records would not even have certain fields at all while other records could have special fields added. To send binary data it would be sent as multiples of 7-bits so that 32-bits of information would perhaps have a marker or command code and 5 lots of data characters resulting in 35 bits of data over 6 characters, totally transparent.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
I suppose browsers can disappear and over time the transport/markup language definition can become obsolete.
If your customer will use your product for more than 20 years, it would make sense to have that product.
Being able to build the same product in 20 years for maintenance and/or enhancements is however dubious.
Meanwhile, what you seek *is* available to anyone now in one form until you have the new system ready to go.
Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers?
Not available since you deserve more information than you requested.
May the road rise to meet you; may the sun shine on your back.
May you create something useful, instead of just another hack.
I've got VT100 already working in vb.net. So, how hard would it be to add some more commands? I don't think it would be hard at all. Consider a form in vb.net and you put some rich text boxes on the form and some buttons and a few other things, and then you make most of them hidden. Then you write some 'new' VT100 escape sequences. But these all borrow syntax from html instead. So you could now send an escape sequence to change the size of the form. Another escape sequence to show a button, with its location. Another to change the text on the button. vb.net could handle doing each of those with a couple of lines of code. And from the propeller end, if the code looked like html then it would be familiar and easy to edit. Indeed, it could even be pure html and you could run it through a simple spin routine that adds ESC[noparse][[/noparse]html to the beginning of each line before sending it out the serial port.
Just a thought...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I also don't have a Prop so I cannot directly test it, but I did write another program that sends the data over the serial connection and it worked fine. So we will have to probably make some adjustments to make this work with the Prop.
Example:
If you send it the following data: 1,20,100,200,300 the Terminal will display a Button with the height = 20, width = 100, LocationX = 200, LocationY = 300.
If you send it the following data: 2,20,100,200,300 the terminal will display a Text box with the height = 20, width = 100, LocationX = 200, LocationY = 300.
If you send it the following data: 0 the terminal will be cleared of all controls.
My sending program sends the data as the following in C#:
serialPort1.Open();
byte[noparse]/noparse data = { 1, 100,20,200,300 };
serialPort1.Write(Encoding.ASCII.GetString(data));
I have started to write the part that will handle the Events that are sent back to the Prop, it is not finished yet.
Also we can switch languages if you prefer, I am well versed in VB, VB.NET, C++, C#, and Java
In design mode the user would have a toolbox of controls and access to each controls property sheet for sizing color and location etc.·The toolbox would allow·future revisions·to include existing or new user controls such as LED arrays or dials/gauges .
Some kind of naming convention would need to be formulated so that the user could quickly identify and communicate with a controls events , maybe parsing the name of the control to a letter and number.
The less the Prop has to think about design and the easier it is to access the applications functions the better.
It would be nice to be able to save a set of personal applications to configuration files for future use.
Jeff T.
·
I think what you are suggesting is to basically create a custom app every time that you want to do something, or have the app pre-stored. Either way I think that is getting away from what he wants.
The way I see it (and I could be wrong) is the Prop is running and it needs some information from the user, in this case it needs you to select something from a drop down box. So the prop clears the control surface and displays a drop down box and an accept button. After the user has selected the item and pressed the accept button the Prop reads the event and goes onto the next step which might be display a textbox to get some text from the user. This way the prop has complete control of the control surface.
Jesse
Jeff T.
I like Peter's use of the 8th bit, although that may cause language problems for other than english. I always hated the esc sequences that became long and complicated. For the ICL mini I worked on, to position text on the screen, we sent control characters... home,down,down....,right,right,.... Not quite as fast as direct cursor control but it avoided esc sequences. We used a macro to do this which also did left and up to get to the position in the quickest way. i.e column 41 did left x39 instead of right x41.
So we could describe a widget like button as a group of control characters describing it's position, size, color, contents.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Somewhere you will have to define what the terminal will be, if we do not use a computer than we will have to create another device that will receive these commands from the Prop. So if you really wanted to get this to work we would need to create a list of generic commands that we could send serially that would describe the different procedures that the terminal must receive/send. After we created our list we could than began to build the terminals (either pc or a 'black box' or both) as long as the terminals know how to interpret those commands it does not matter what the prop is connected to.
Jesse
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cmapspublic3.ihmc.us:80/servlet/SBReadResourceServlet?rid=1181572927203_421963583_5511&partName=htmltext
Hello Rest Of The World
Hello Debris
Install a propeller and blow them away
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers?
Not available since you deserve more information than you requested.
May the road rise to meet you; may the sun shine on your back.
May you create something useful, instead of just another hack.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
The main issue if you use a serial line is speed.
Therefore I use a "data stream" concept for data transmission.
This means that all characters coming from a propeller will go directly to a "window object". To switch between the window objects, there is an escape character defined ( I chose 0xFE ). If this escape character is detected, the terminal knows that a command will follow. This command can be used to switch between the window objects.
Here is my example
Post Edited (Chris Micro) : 3/20/2010 10:25:40 AM GMT