Terminal emulators

On 2009-01-18, larwe <zwsdotcom@gmail.com> wrote:
> On Jan 18, 1:03&#4294967295;pm, Roger Ivie <ri...@ridgenet.net> wrote:
>
>> So, your answer is to build the USB serial port into the target
>> hardware? I loled.
>
> It's a frequently-used approach.

But if you're uneasy enough with the future availability of USB serial ports 
to hassle me about saying "you can always buy one", how is building one of
them into the device a solution?
-- 
roger ivie
rivie@ridgenet.net

larwe wrote:

> Well, yes - kinda. HID, modem and mass-storage are fairly unambiguous.
> Not every application fits into the mold of a supported class though.

For a HID device you can transfer anything you want, see e.g. this article:

http://www.edn.com/article/CA243218.html

In short: You can transfer 64 bytes each millisecond, for which you can
define your own format.

If you are going to build your own mouse or special input device, of course
you can create your own HID descriptors. The HID specification shows the
details:

http://www.usb.org/developers/devclass_docs/HID1_11.pdf

They defined a very complicated, universal concept how to encode many
physical properties, and how they are connected to the human body, in a
generic way, but you don't need it, if your application knows your device.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On Jan 18, 1:53 pm, John Devereux <j...@devereux.me.uk> wrote:
> larwe <zwsdot...@gmail.com> writes:
> > On Jan 18, 11:42 am, Cesar Rabak <csra...@bol.com.br> wrote:
>
> >> Always is a strong word. I agree buying a USB serial port could be
> >> atractive to keep legacy apps/boards/devices available, but IMHO not a
> >> great idea for new developments.
>
> > There is still nothing as simple as an asynchronous serial port, and
> > this is likely to be the case for a long long time. In one form or
> > another, we'll have emulated serial ports for a very long time to
> > come.
>
> > Moving away from simple serial interfaces takes you down one of two
> > unfortunate paths:
>
> > - Interfaces like Ethernet can be nice and generic, but they're
> > implementationally complex and costly on the device end.
>
> > - Interfaces like USB can be implementationally "simple" on the device
> > end  (in the sense that you might just have to switch to a USB micro,
> > and add the connector) but now you have the burden of developing and
> > supporting proprietary device drivers, which OS vendors are constantly
> > working to break.
>
> Are there any "driverless" USB solutions feasible? For example I
> gather that a "mass storage" model requires no proprietary
> drivers. Are there any other (perhaps simpler) ones?

I believe the HID (human interface device) does not require special
drivers.  But this is setup for low speed comms only (keyboard, mouse,
etc).  It may be possible for the target to configure as both a mass
storage device and an HID.  Low speed comms for control and mass
storage for bulk transfers.  Still, this is way more complex than
needed for what this is doing in my app.

To answer a question about the target hardware, I have control over
the test fixture, but the hardware has been built and I gave it an
RS-232 interface chip connected to an FPGA.  I also gave it an SD card
socket, so if the testing process gets highly routine, it may be
possible to let the test fixture load the test and programming file
from an SD card and do everything without operator interaction and
without delays on the serial port (if that is an issue).

I'm actually looking into buying pre-programmed Flash FGPAs, so that
would reduce the test time without any fancy development work.  Then
it is all about the actual tests required.

To give a higher level perspective to this, I am trying to reduce the
delivery time.  If I reduce the test time and complexity I can turn
testing over to the assembly house.  The only fly in the ointment is
the burn-in required.  I am currently taking all the boards to my
customer's facility where I can burn in 56 boards a day.  I would like
to build burn in fixtures, but unless I can come up with something on
the cheap it will just be too expensive.  The ideal solution would be
a single board that can used for both functions, test and burn-in.
But for now I am just trying to get the testing formalized and semi-
automated.

Rick

Frank Buss <fb@frank-buss.de> writes:

> larwe wrote:
>
>> Well, yes - kinda. HID, modem and mass-storage are fairly unambiguous.
>> Not every application fits into the mold of a supported class though.
>
> For a HID device you can transfer anything you want, see e.g. this article:
>
> http://www.edn.com/article/CA243218.html
>
> In short: You can transfer 64 bytes each millisecond, for which you can
> define your own format.
>
> If you are going to build your own mouse or special input device, of course
> you can create your own HID descriptors. The HID specification shows the
> details:
>
> http://www.usb.org/developers/devclass_docs/HID1_11.pdf
>
> They defined a very complicated, universal concept how to encode many
> physical properties, and how they are connected to the human body, in a
> generic way, but you don't need it, if your application knows your device.

That's interesting, thanks. Saved for later study.

64 bytes per millisecond is pretty fast actually, compared to
traditional RS232 say. If the latency on the link is 1 millisecond,
that is also much better than you get with a typical USB-RS232
converter.

Is it actually possible for ones program to access such a device
without installing any drivers? The ideal would be a single win32
executable that could run on any (USB capable) windows system without
modification.

-- 

John Devereux

John Devereux wrote:

> Is it actually possible for ones program to access such a device
> without installing any drivers? The ideal would be a single win32
> executable that could run on any (USB capable) windows system without
> modification.

Yes, this is possible. I've written such a program for a commercial project
some time ago, which works without problems from Windows 98 SE to Vista
(unlike some serial port programs with virtual COM port drivers) and will
publish a modified and more general version on my web page, when I have
some time. Should be no problem with Linux and MacOS, too.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

John Devereux wrote:

> That's interesting, thanks. Saved for later study.

I've downloaded the sample program from the EDN article and looks like a
good starting point. They've used multithreading and overlapped IO, which
is important, if you don't want to hang your program, if the user removes
the USB device while you are waiting in a ReadFile. This is the way I've
used for my commercial project, too.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Roger Ivie <rivie@ridgenet.net> wrote:
> On 2009-01-18, Nobby Anderson <nobby@invalid.invalid> wrote:
>> rickman <gnuarm@gmail.com> wrote:
>>> Cesar Rabak wrote:
>>>> Roger Ivie escreveu:
>>>> >
>>>> > You can always buy a USB serial port.
>>>>
>>>> Always is a strong word.
>>>
>>> Can I ask what you would suggest?
>>
>> Is this a test fixture you have under your control or are building?  If
>> so, you can use something like a CP2102 USB to UART covnerter 
>
> So, your answer is to build the USB serial port into the target
> hardware? I loled.

Whatever.  Imagine my dismay.

On Sun, 18 Jan 2009 18:53:57 +0000, John Devereux
<john@devereux.me.uk> wrote:

>Are there any "driverless" USB solutions feasible? For example I
>gather that a "mass storage" model requires no proprietary
>drivers. Are there any other (perhaps simpler) ones?

You can write USB serial device software (we've done it) which
requires no drivers for Mac, Linux and Windows (except the INF
file). The CDC/ACM model is what we used. However, it was a real
pain. Windows requires a .INF file whose rules are obscure,
especially for Vista. If you make a composite device, e.g.
serial and mass storage, Macs don't understand the IAD descriptor
and you need a kluge which both Windows and Linux accept.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

On Fri, 16 Jan 2009 23:22:13 -0800 (PST)
rickman <gnuarm@gmail.com> wrote:

> I have been working on a program which will use a terminal emulator as
> the user interface.  One thing I am finding is that there seem to be
> different command formats in the different emulators.  I tried using
> the telnet program that came with Windows.  Then I tried Putty.  The
> characters sent from keypresses seem to be different for the various
> function keys.  For example, under telnet, the DEL key is the single
> code 127 while the Putty program sends a sequence of ESC [ 3 ~   The
> function keys F1 to F4 are sent as similar sequences in Putty when in
> "ESC[n~" mode and sends VT52 sequences (e.g. ESC O P) in VT100 mode.
> The telnet program only seems to send the VT52 sequences.  Neither
> program sends the VT100/52 sequence for the cursor control keys
> (arrows).
> 
> I can't find documentation on the ESC[n~ sequences anywhere.  It seems
> that there is overlap in that a command can be ESC[n~ or ESC[nm~.  So
> the ~ serves as a command terminator which makes the command a bit
> harder to parse.
> 
> I can make the program work with any of these formats, but I would
> like to understand where they come from and to make sure that I am
> using them correctly by finding the appropriate documentation.  Are
> the "ANSI" keyboard sequences documented anywhere?  I can find docs on
> the commands *sent* to ANSI terminals, but I only find info on VT52,
> VT100 etc keyboards.  Even if I try to use the VT100 formats, they are
> not uniformly supported.
> 
> Rick

Escape sequences are notoriously wild, wacky, and variable.  You may
save yourself a lot of grief by reducing the scope of characters you
care about to letters, numbers, and punctuation.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

larwe escreveu:
> On Jan 18, 11:42 am, Cesar Rabak <csra...@bol.com.br> wrote:
> 
>> Always is a strong word. I agree buying a USB serial port could be
>> atractive to keep legacy apps/boards/devices available, but IMHO not a
>> great idea for new developments.
> 
> There is still nothing as simple as an asynchronous serial port, and
> this is likely to be the case for a long long time. In one form or
> another, we'll have emulated serial ports for a very long time to
> come.
> 

If you and your organization share this belief and this solution is good 
enough gor for it!

> Moving away from simple serial interfaces takes you down one of two
> unfortunate paths:
> 
> - Interfaces like Ethernet can be nice and generic, but they're
> implementationally complex and costly on the device end.
> 
> - Interfaces like USB can be implementationally "simple" on the device
> end  (in the sense that you might just have to switch to a USB micro,
> and add the connector) but now you have the burden of developing and
> supporting proprietary device drivers, which OS vendors are constantly
> working to break.
> 
You're right about the paths but I don't agree totally on your 
'unfortunate' judgment.


-- 
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/