Searching \ for '[TECH] Virtual serial port used as a software API' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=serial
Search entire site for: 'Virtual serial port used as a software API'.

Exact match. Not showing close matches.
PICList Thread
'[TECH] Virtual serial port used as a software API'
2010\07\18@160830 by YES NOPE9

flavicon
face
I really like using serial ports to send ASCII commands to hardware  
modules and retrieve status in ASCII as well.

It occurred to me that an API ( Application Programming Interface )  
could be constructed to look like a virtual serial asynch port.
Then one could communicate with the software module using ASCII  
commands and getting back ASCII responses.
Many programming languages support access to asynch serial ports and  
this might be an easy way to make the API available.

#1  Is this a viable idea or have I missed some pitfalls ?
#2  Has this already been done ?  ( and worked ? )  ( has been a  
disaster ? )

Best

Gus

2010\07\18@162738 by Michael Watterson

face picon face
 On 18/07/2010 21:08, YES NOPE9 wrote:
> I really like using serial ports to send ASCII commands to hardware
> modules and retrieve status in ASCII as well.
>
> It occurred to me that an API ( Application Programming Interface )
> could be constructed to look like a virtual serial asynch port.
> Then one could communicate with the software module using ASCII
> commands and getting back ASCII responses.
> Many programming languages support access to asynch serial ports and
> this might be an easy way to make the API available.
>
> #1  Is this a viable idea or have I missed some pitfalls ?
yes it works
> #2  Has this already been done ?  ( and worked ? )
yes it works
>   ( has been a
> disaster ? )
>
> Best
>
> Gus
I have two kinds on PC.
1) Come in pairs. All serial programs to communicate on SAME PC, with no
real ports used at all.
2) Remote/local virtual Serial  via TCP/IP. Client or Server. The
"remote" server or local client can be a program, Serial over USB,
Serial over Bluetooth or really serial. The "driver" looks like a serial
port but internally has TCP/IP settings and ports. Or an application can
use the remote port directly via TCP/IP (or UDP) + Port.

There are also "virtual dialup modems" that have AT commands and special
phone numbers. USB modems for TCP/IP over GSM, GPRS, EDGE, 3G and
HSDPA/iHSPA work like this in reality.

VPN looks like a dialup modem on some OS, the IP address of the server
you want is put in to the "phone number" box.

2010\07\18@183105 by Olin Lathrop

face picon face
YES NOPE9 wrote:
> I really like using serial ports to send ASCII commands to hardware
> modules and retrieve status in ASCII as well.

Yucc.  Text commands and response are usually inconvenient for a small
embedded system.  I usually use a binary protocol.  If I want a command line
interface to this protocol, I write a program on the PC that presents the
command line to the user but communicates in binary to the embedded system.

There will have to be a parser somewhere between your text input and what
the embedded system ultimately does.  It makes a lot more sense to put this
parser on the PC where resources for it are essentially free.  For the
reverse direction (remote system to PC), it's even easier since the small
system never has to create a cumbersome text command, and it therefore never
needs to be parsed.  You get the integer opcode directly on the host.

> It occurred to me that an API ( Application Programming Interface )
> could be constructed to look like a virtual serial asynch port.

Windows has already done this, and even provided a standard place to put
your code to implement the serial port routines.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2010\07\18@222618 by Matthew Schinkel

picon face


Yes, this has been done. I think this is the website but i'm not sure. The description on the webpage sounds exactly the same as your description.


http://com0com.sourceforge.net/



Matt.

{Quote hidden}

> --

2010\07\18@225321 by Vitaliy

face
flavicon
face
Matthew Schinkel wrote:
> http://com0com.sourceforge.net/

We used this successfully. It's not end user-level friendly, but is perfect
for development purposes.

Vitaliy

2010\07\21@231935 by Vitaliy

face
flavicon
face
Olin Lathrop wrote:
>> I really like using serial ports to send ASCII commands to hardware
>> modules and retrieve status in ASCII as well.
>
> Yucc.  Text commands and response are usually inconvenient for a small
> embedded system.  I usually use a binary protocol.  If I want a command
> line
> interface to this protocol, I write a program on the PC that presents the
> command line to the user but communicates in binary to the embedded
> system.
>
> There will have to be a parser somewhere between your text input and what
> the embedded system ultimately does.  It makes a lot more sense to put
> this
> parser on the PC where resources for it are essentially free.  For the
> reverse direction (remote system to PC), it's even easier since the small
> system never has to create a cumbersome text command, and it therefore
> never
> needs to be parsed.  You get the integer opcode directly on the host.

We consider this almost every time we design a new device. While what you
say has merit, ASCII has the benefit of serving as a rudimentary user
interface on any system where a suitable terminal emulator is available.

Vitaliy

2010\07\24@053431 by William \Chops\ Westfield

face picon face

On Jul 18, 2010, at 1:08 PM, YES NOPE9 wrote:

> It occurred to me that an API ( Application Programming Interface )
> could be constructed to look like a virtual serial asynch port.
> Then one could communicate with the software module using ASCII
> commands and getting back ASCII responses.
> Many programming languages support access to asynch serial ports and
> this might be an easy way to make the API available.

> #1  Is this a viable idea or have I missed some pitfalls ?
> #2  Has this already been done ?  ( and worked ? )  ( has been a
> disaster ? )

Yes, this has been done.  It's quite common in the internet protocols,  for example.  The "command channel" is vaguely "virtual terminal  like", and the commands sent and responses received are all mostly  human-readable:
       mail from:<billwspamKILLspamcsco.com>
        250 OK
       rcpt to:<.....olinKILLspamspam.....piclist.com>
       500 No such recipient
       rcpt to:<EraseMEolin1spam_OUTspamTakeThisOuTpiclist.com>
       400 mailbox full of flames
       rcpt to:<olin3spamspam_OUTpiclist.com>
       250 OK
       rcpt to:<@spam@newtonKILLspamspampiclist.com>
       250 OK
       data
       354 enter mail, end with "."
is email, for example.  FTP and HTTP work similarly.

Also used by the Egg Bot Board  http://www.schmalzhaus.com/EBB/, which  in turn is based on the USB Bit Whacker http://www.schmalzhaus.com/ UBW/ ; these instantiate a USB virtual comm port that accepts text  commands for setting bits, etc on output pins.  Or to control stepper  motors and servos.  No actual serial port ever exists (unlike, say,  Arduino, which actually implements a usb/serial converter and sends  bits serially over a wire, though this is somewhat hidden from the  user.)
Apparently a fair number of "USB peripherals" go the arduino route;  they contain a USB/Serial converter and a micro that doesn't  understand USB at all (GPS peripherals a particular example.)

BillW

More... (looser matching)
- Last day of these posts
- In 2010 , 2011 only
- Today
- New search...