On 1 Aug 2014 17:51:33 GMT, Nils M Holm <news2009@t3x.org> wrote:
>upsidedown@downunder.com wrote:
>> Your approach would have made sense in the 1970-90's when dumb
>> terminals, like VT100/VT220 were used.
>
>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.
It was. Modern usage often considers anything with no local
processing to be a dumb terminal. Ultimately the distinctions are not
that meaningful. Or precise.
Reply by Nils M Holm●August 1, 20142014-08-01
upsidedown@downunder.com wrote:
> Your approach would have made sense in the 1970-90's when dumb
> terminals, like VT100/VT220 were used.
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
Reply by Paul●August 1, 20142014-08-01
In article <7q7ct91s0hnhvokl7kfce3gs6ievudj0c5@4ax.com>,
upsidedown@downunder.com says...
..
[off topic drift engaged]
> 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.
On Tue, 29 Jul 2014 20:14:53 +0800
Ang Zhi Ping <azhiping@dso.org.sg> wrote:
> On 28/7/2014 7:45 PM, Theo Markettos wrote:
> > I think a lot of posters are overcomplicating things. What about simple
> > number-based menus:
> >
> > 1. Load
> > 2. Save
> > 3. Settings
> > 4. Factory reset
> > 5. Power off
> > 9. Help
> > 0. Main menu
> > #. Speak to an operator
> > (ok, maybe don't include #)
> >
> > then typing a number gets other submenus like this.
>
> Sounds like a good idea. Maybe dialogs can be dispensed all together...
>
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.
Reply by Ang Zhi Ping●July 29, 20142014-07-29
On 28/7/2014 9:37 PM, Robert Wessel wrote:
> On Mon, 28 Jul 2014 20:08:59 +0800, Ang Zhi Ping <azhiping@dso.org.sg>
> wrote:
>
>> On 28/7/2014 6:19 PM, upsidedown@downunder.com wrote:
>>> Were are you going to display those menus, an a miniature display on
>>> the device itself or some external display ?
>>
>> On a workstation that has a COM port. It is used for testing the said
>> embedded system.
>>
>>> Where are the arrow keys, on the front panel of the device or
>>> somewhere else ?
>>
>> The workstation has a keyboard.
>>
>>> Does your device have a built i mouse or track ball or light pen or
>>> this external to your days.
>>
>> No it is a standalone embedded that has no need for human interaction.
>>
>>> 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.
>>
>> I'm looking for something simple and easy on the memory footprint of the
>> embedded target.
>>
>>> 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.
>>
>> I won't want to develop a full blown Windows GUI. Just a presentable
>> serial console will do.
>
>
> 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...<cr>
>
> with similar format responses, perhaps:
>
> resultcode value1,value2...<cr>
>
> 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.
Sounds like GDB remote serial protocol. Which leads me to wonder why
Altera do not support RSP via serial.
Ah maybe I should start another thread about RSP as this is pretty
interesting!
Reply by Ang Zhi Ping●July 29, 20142014-07-29
On 28/7/2014 8:40 PM, upsidedown@downunder.com wrote:
> On Mon, 28 Jul 2014 20:08:59 +0800, Ang Zhi Ping <azhiping@dso.org.sg>
> wrote:
>
>> On 28/7/2014 6:19 PM, upsidedown@downunder.com wrote:
>
>
>>> 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.
>>
>> I won't want to develop a full blown Windows GUI. Just a presentable
>> serial console will do.
>
> However, there are quite easily usable tools to do the Windows GUI,
> compared to a small embedded system.
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.
>>> 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.
>>
>> 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.
>
> 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.
That is true.
Reply by Ang Zhi Ping●July 29, 20142014-07-29
On 28/7/2014 7:45 PM, Theo Markettos wrote:
> I think a lot of posters are overcomplicating things. What about simple
> number-based menus:
>
> 1. Load
> 2. Save
> 3. Settings
> 4. Factory reset
> 5. Power off
> 9. Help
> 0. Main menu
> #. Speak to an operator
> (ok, maybe don't include #)
>
> then typing a number gets other submenus like this.
Sounds like a good idea. Maybe dialogs can be dispensed all together...
> 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.
If only navigating an automated call machine can be as simple as what
you have mentioned *hehe*
> 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.
The terminal output is intended for debugging/troubleshooting purposes.
Reply by Ang Zhi Ping●July 29, 20142014-07-29
On 28/7/2014 11:14 PM, Grant Edwards wrote:
> 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.
Yes a curses library for embedded targets, preferably one that does not
require an OS to run on.
> 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.)
That is what I'm trying to avoid by looking around for some ready made
libraries.
Reply by Theo Markettos●July 28, 20142014-07-28
Spam@controlq.com wrote:
> BINGO!
>
> 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 www.example.com
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.
Theo
Reply by ●July 28, 20142014-07-28
On Mon, 28 Jul 2014, Grant Edwards wrote:
>
> 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.)
BINGO!
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!
Cheers,
Rob.