Terminal emulators

rickman 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.

Yes, there is a problem with compatibility to the different terminals, 
especially the ones which are trying to do the auto detect.

I use the primitive terminal I/O for debug and test purpose quite often, 
and I avoid using anything except the ASCII characters. "Press 1 to do 
this, press 2 to do that... etc. If the advanced user interface is 
required, then the best way is developing a binary protocol and the host 
GUI application of your own. If this GUI has to be platform independent, 
it can be done in Java.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

rickman <gnuarm@gmail.com> wrote:
> Cesar Rabak wrote:
>> Roger Ivie escreveu:
>> > On 2009-01-17, Cesar Rabak <csrabak@bol.com.br> wrote:
>> >> Using the serial port was OK some years ago, but presently you may get
>> >> your fingers burned as some newer machines do not come with this port
>> >> anymore.
>> >
>> > You can always buy a USB serial port.
>>
>> 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.
>
> Can I ask what you would suggest?  How would you interface to the test
> fixture?

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 - USB in
one side and at the simplest RxD and TxD out of the other at logic
levels and whatever speeds and start/stop bits etc you set on the host
end.  I've used it to replace the serial interface on a number of things
really it means you can get rid of the test fixture RS232 (or whatever)
transcivers and stick one of these things in its place.  It'll also
support the other RS232 lines like RTS/CTS/DTR etc if you need them.
It also has driver support for Windows and Linux.

Magic.

Of course, if the test fixture isn't under your control then ...

Nobby

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.
-- 
roger ivie
rivie@ridgenet.net

On Jan 18, 11:42=A0am, 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.

On Jan 18, 1:03=A0pm, 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.

On Jan 18, 1:03=A0pm, Roger Ivie <ri...@ridgenet.net> wrote:
> On 2009-01-18, Nobby Anderson <no...@invalid.invalid> wrote:
>
> > rickman <gnu...@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? =A0=
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.

The question was directed to you.  What is your solution?

Rick

On Jan 18, 1:23=A0pm, rickman <gnu...@gmail.com> wrote:
> On Jan 18, 1:03=A0pm, Roger Ivie <ri...@ridgenet.net> wrote:
>
>
>
> > On 2009-01-18, Nobby Anderson <no...@invalid.invalid> wrote:
>
> > > rickman <gnu...@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? =
=A0If
> > > 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.
>
> The question was directed to you. =A0What is your solution?

Sorry, I got you mixed up with Cesar.  I'm waiting to hear what he
suggests as a solution for a good interface.

Rick

larwe <zwsdotcom@gmail.com> writes:

> On Jan 18, 11:42&nbsp;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?

-- 

John Devereux

Cesar Rabak schrieb:

> Using the serial port was OK some years ago, but presently you may get
> your fingers burned as some newer machines do not come with this port
> anymore.

This may be true for IBM-compatibles (PCs) but many other devices with
some "intelligence" use UARTs. The reason is simple: It's cheap, easy to
use and everybody knows how it works.

Falk
P.S.: I was surprised, that a UMTS-Cardbus-Card contained a USB-Hub with
two serial converters. The internal modems answered "OK" to "AT" ;-)
-- 
http://cc.aljazeera.net/
http://ie.youtube.com/user/idfnadesk

On Jan 18, 1:53=A0pm, John Devereux <j...@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?

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