Searching \ for 'Serial Comms' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/io/serials.htm?key=serial
Search entire site for: 'Serial Comms'.

Truncated match.
PICList Thread
'serial comms'
1997\01\17@012040 by TONY NIXON 54964

flavicon
picon face
I was wondering if anyone knows of a simple program around that would
allow basic 'talking' on the PC serial port using DOS.

I'm using Windows Terminal program, but am having intermittant
trouble talking to it using a PIC74.

Any help appreciated

Tony


Just when I thought I knew it all,
I learned that I didn't.

1997\01\17@134357 by James and Iliana Holbrook

flavicon
face
At 05:13 PM 1/17/97 GMT+1100, you wrote:
>I was wondering if anyone knows of a simple program around that would
>allow basic 'talking' on the PC serial port using DOS.
>
>I'm using Windows Terminal program, but am having intermittant
>trouble talking to it using a PIC74.
>
>Any help appreciated
>
>Tony
>
>
>Just when I thought I knew it all,
>I learned that I didn't

Tony,
       I use a program called Maxterm.. it's a dos comm program that was
designed for talking to microcontrollers. It has several nice features that
come in handy. I would be glad to email it to you.
                                       James

1997\01\17@162435 by Michael S. Hagberg

flavicon
face
At 05:13 PM 1/17/97 GMT+1100, you wrote:
>I was wondering if anyone knows of a simple program around that would
>allow basic 'talking' on the PC serial port using DOS.
>

i alway liked procomm, there is a shareware version that i often
use on customers systems to check modems or link to other
serial devices.

michael

1997\01\17@180144 by Eduardo J. Martinez Velez

flavicon
face
part 0 594 bytes

       I use a program called Maxterm.. it's a dos comm program that was
designed for talking to microcontrollers. It has several nice features that
come in handy. I would be glad to email it to you.
                                       James


----------------------------
Thanks for all - Mil gracias
----------------------------
Eduardo Jorge Mart’nez VŽlez
a   Asesoria
&   &
 s   Sistematizacion
INET: spam_OUTejmvTakeThisOuTspamsatlink.com
 .....73070.3653KILLspamspam@spam@compuserve.com
CServe: 73070,3653
2000-Rosario-SF-Argentina
TelFax: (54)(41)254561
Tel: (54)(41)8804
----------------------------

1997\01\17@215133 by John Payson

picon face
> At 05:13 PM 1/17/97 GMT+1100, you wrote:
> >I was wondering if anyone knows of a simple program around that would
> >allow basic 'talking' on the PC serial port using DOS.
>
> i alway liked procomm, there is a shareware version that i often
> use on customers systems to check modems or link to other
> serial devices.

I used to use ProComm, but I nowadays prefer to use COMMO.  I find that
COMMO--despite being much smaller than the others (less than 64K for all
needed file, not counting help or docs) includes a full scripting language,
some internal upload/download protocols (Xmodem and Ymodem variants) as
well as the ability to auto-launch a Zmodem receive upon seeing the H:\pic\efo~3.txt
indicator.  In addition, it includes a built-in text editor and scrollback
buffer (64K limit on each); the scrollback buffer logs what scrolls off
the screen (so it often yields decent results even in cases where other
programs do not; if a program displays "MORE" and then upon receiving a
keystroke overwrites that with the continued display, the "MORE" will not
appear in the scrollback) and the program can log to a file either [1]
Everything that comes in the port, or [2] Everything that scrolls off
the screen.

Really great program.

1997\01\18@153945 by Dorin Dogaroiu

flavicon
face
>At 05:13 PM 1/17/97 GMT+1100, you wrote:
>I was wondering if anyone knows of a simple program around that would
>allow basic 'talking' on the PC serial port using DOS.
>
>I'm using Windows Terminal program, but am having intermittant
>trouble talking to it using a PIC74.
>
>Any help appreciated
>
>Tony
>

- Try using procomm for DOS. It is very good.

- check the software which is delivered with new modems cards (
Commit, Bitcom ...) because they have also dirrect connection option.

- devellop your own. There is a Turbo Pascal shareware library for
communication functions ( by Marshall Software) which has also
examples of terminal programs, so you can configure the software on
your own whishes. If you are interested on this library, I can mail
it to you.

                                       Dorin

------------------------------------
Dorin Dogaroiu
Research Institute for Computers
Bucarest, Romania
E-mail  :  dogaroiudspamKILLspampcnet.pcnet.ro
          .....ddorinKILLspamspam.....kappa.ro
------------------------------------

1997\01\18@234826 by myke predko

flavicon
face
James,

What are the features in Maxterm that makes it well suited for talking to
microcontrollers?

myke
{Quote hidden}

A New Era in Computing:

HAL 9000

Born January 12, 1997 - Urbana Illinois

1997\01\19@114640 by James and Iliana Holbrook

flavicon
face
At 11:45 PM 1/18/97 EST, you wrote:
>James,
>
>What are the features in Maxterm that makes it well suited for talking to
>microcontrollers?
>
Myke,
       The features that I like are control of the DTR & RTS lines,
download pacing with the pace character settable from the interface, scroll
back buffer, intergrated editor ( you can make quick changes to code and
download it without changing programs ), the baud rate is settable from the
interface, there is also a character redefinition mode that gives you a hex
display and an ascii display of your information at the same time ( very
handy for memory dumps ), it's small, quick, easy to use and runs great in a
DOS window in Win 3.11 or Win95.
       And maybe the nicest feature is that it's free.

       I hope that answered all your questions.
                                               James

1997\01\19@233012 by tjaart

flavicon
face
James and Iliana Holbrook wrote:
>
> Tony,
>         I use a program called Maxterm.. it's a dos comm program that was
> designed for talking to microcontrollers. It has several nice features that
> come in handy. I would be glad to email it to you.
>                                         James

Can it monitor COM1 & COM2 simultaneously? Geez, I'd give my eye teeth
for a nice terminal prog that displays in two columns, and where you can
define 'return carriage' characters. Something like this :
------------------------------------------------------------
baudrate = XXXX 8N1           | baudrate = YYYY 8N1
return = ASCII 13             | return = ASCII 26
------------------------------------------------------------
This text comes from the PIC  |
                             |This text comes from the 'oth
                             |er' side of the comms
blah blah blah                |
                             |blah blah blah
blah blah blah                |
                             |blah blah blah

et cetera....


--
Friendly Regards

Tjaart van der Walt
______________________________________________________________
|  Another sun-deprived R&D Engineer slaving away in a dungeon |
|WASP International GSM vehicle tracking and datacomm solutions|
|+27-(0)11-622-8686 |  http://wasp.co.za   | @spam@tjaartKILLspamspamwasp.co.za |
|______________________________________________________________|

1997\01\20@035138 by Chaipi Wijnbergen

flavicon
picon face
On Mon, 20 Jan 1997, Tjaart van der Walt wrote:

> Can it monitor COM1 & COM2 simultaneously? Geez, I'd give my eye teeth
> for a nice terminal prog that displays in two columns, and where you can
> define 'return carriage' characters. Something like this :
> ------------------------------------------------------------
> baudrate = XXXX 8N1           | baudrate = YYYY 8N1
> return = ASCII 13             | return = ASCII 26
> ------------------------------------------------------------

You need the DSCOPE.EXE program from http://www.ednmag.com, I got it from that
web site. I looked again and was unable to find it any more, It was
shareware, I think that I can send it to does individuals that will email
directly yo me.

Chaipi

1997\01\20@122539 by nuje

flavicon
picon face
In message  <KILLspam199701180240.UAA18325KILLspamspamMars.mcs.net> RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU writes:
> I used to use ProComm, but I nowadays prefer to use COMMO.  I find that
> COMMO--despite being much smaller than the others (less than 64K for all
> needed file, not counting help or docs) includes a full scripting language,
> some internal upload/download protocols (Xmodem and Ymodem variants) as
> well as the ability to auto-launch a Zmodem receive upon seeing the H:\pic\efo~3.txt
> indicator.  In addition, it includes a built-in text editor and scrollback
> buffer (64K limit on each); the scrollback buffer logs what scrolls off
> the screen (so it often yields decent results even in cases where other
> programs do not; if a program displays "MORE" and then upon receiving a
> keystroke overwrites that with the continued display, the "MORE" will not
> appear in the scrollback) and the program can log to a file either [1]
> Everything that comes in the port, or [2] Everything that scrolls off
> the screen.
>
> Really great program.
>

Can you tell us where we can get Commo, please.


Regards,


Mike Watson

1997\01\20@151957 by Luis Fernandez

flavicon
face
Hi,

>I was wondering if anyone knows of a simple program around that would
>allow basic 'talking' on the PC serial port using DOS.

I'm using START. Is a SIMPLE and "naked" terminal. You just invoque it as:

       START <COM PORT NUMBER> <BAUD RATE>
       Ej: START 2 9600

I use it for simple communications using the serial port. Has no other
feature except echo-on/off :-)

The good thing is that this just sizes 14.370 bytes. Works in any old PC.

Anyone interested just send me a message directly.




Luis Fernandez Cormenzana
RadioBit Sistemas, S.L.
       Vehicle fleet control systems
       Patrol presence controllers

Fax/Tel:+34-6-585 64 57
e-mail: spamBeGoneradiobitspamBeGonespamdragonet.es
http://www.dragonet.es/users/radiobit

1997\01\20@170831 by William Chops Westfield

face picon face
   >I was wondering if anyone knows of a simple program around that would
   >allow basic 'talking' on the PC serial port using DOS.

If you (still) have basica (or GWBASIC), it has quite good support for the
com ports (1 and 2, anyway.)  Very early in the PC's life, I wrote a
termnial emulator/file transfer program in a combination of assembler and
basica (the assembler does the terminal emulation, basica does user
interface, configuration, and file transfers (xmodem.)  If the assembler
part is missing, the basica will do "dumb terminal" as well, but not all
that well...

I'd be willing to post or make this FTPable if anyone is interested.

The "commercial" version of this program, which might have been a worthy
competitor of Crosstalk I, crashed and burned for business reasons :-(

BillW

1997\01\26@115050 by Mike Fahrion

flavicon
face
Check out SimpTerm on our website at http://www.bb-elec.com
It is a shareware terminal program which supports up to 4 ports at
any address/irq and also allows inline monitoring of communications
between two ports.  Great com tool IMHO.

-mike
TakeThisOuTmfahrionEraseMEspamspam_OUTbb-elec.com


{Quote hidden}

1997\01\26@121103 by Mike Fahrion

flavicon
face
Hate to drag out this non-pic topic, but there's been a lot of
misconceptions mixed in with good information on this subject.

PC's themselves can handle any number of com ports (I've run 12-16
"non-intelligent" boards on one machine.  Windows 3.x standard com
driver will not allow IRQ sharing or higher numbers of ports.  Many
aftermarket drivers overcome this.  Win95 and NT handle all the ports
you could need.

IRQ Sharing.  Win 95 and NT allow IRQ sharing (meaning two ports IN
USE at the same time on the same IRQ).  HOWEVER - your port MUST have
special hardware to support shared IRQ's.  Most off the shelf modems
& ports don't.  Many boards headed for industrial applications do.
IRQ sharing works well and I generally recommend it.

Win 95 and NT have pretty much solved most of the dos/win3.x com
problems of the past.  With the correct hardware and an understanding
of how things work there shouldn't be any problems.  Granted this all
comes with a bit of overhead (to say the least) but Pentium machines
are cheap.  If you are running multiple ports with little buffering
an no handshaking, just buy a fast machine.

Bottom line isn't too bad.  Good hardware supports shared IRQ's,
'95 and NT support it also - just be sure when you buy that your com
boards support and address and any IRQ, and hopefully shared IRQ's.
(Note that most industrial board suppliers support this stuff,
ourselves included at (shameless plug) http://www.bb-elec.com

Also - the aim of USB (universal serial bus) is to clear this stuff
all up for the user, and from what I've seen so far, it looks pretty
good, although more complex for peripheral mfgs.  I just returned
from the USB Implementers Forum and there is a lot of effort going on
to make sure that it is done right this time.  Looks good so far,
we'll see in the next few months.

-mike
mfahrionEraseMEspam.....bb-elec.com
At home

1997\01\26@152446 by John Dammeyer

flavicon
face
At 08:27 PM 14/01/1997 +0000, you wrote:
>Hate to drag out this non-pic topic, but there's been a lot of
>misconceptions mixed in with good information on this subject.
>
>PC's themselves can handle any number of com ports (I've run 12-16
>"non-intelligent" boards on one machine.  Windows 3.x standard com
>driver will not allow IRQ sharing or higher numbers of ports.  Many
>aftermarket drivers overcome this.  Win95 and NT handle all the ports
>you could need.

Not completely true.  The physical PC architure does not allow interrupt
sharing from separate boards on the ISA bus unless the boards share a common
device driver. Your comment gives the opposite impression. What happens on
one board is design dependent, done with with special circuitry or an on
board processor that can produce one edge from multiple devices.
>
>IRQ Sharing.  Win 95 and NT allow IRQ sharing (meaning two ports IN
>USE at the same time on the same IRQ).  HOWEVER - your port MUST have
>special hardware to support shared IRQ's.  Most off the shelf modems
>& ports don't.  Many boards headed for industrial applications do.
>IRQ sharing works well and I generally recommend it.

As I stated above.  An individual board may have 16 serial ports but it
still produces only one _edge_ triggered interrupt which cannot be shared
with another, different type of ISA card.
>
>Win 95 and NT have pretty much solved most of the dos/win3.x com
>problems of the past.  With the correct hardware and an understanding
>of how things work there shouldn't be any problems.  Granted this all
>comes with a bit of overhead (to say the least) but Pentium machines
>are cheap.  If you are running multiple ports with little buffering
>an no handshaking, just buy a fast machine.

Even NT doesn't address the problem for ISA bus machines.  For non-ISA it
does because they run level triggered.  For example:

Imagine Serial port 1 producing an interrupt.  The service routine begins
and before the service routine ends Serial port 2 on a different ISA card
produces an interrupt on the same IRQ.  This edge from the interrupt is
invisable since the IRQ line is still active.  The device driver for Serial
Port 1 finishes off and tells the OS that it successfully completed the
interrupt.

Several options now.

The OS then writes the EOI to the Programmable Interrupt Controller (PIC)
and continues on;  but the IRQ line is still held asserted by Serial Port 2
so additional characters on any other serial ports can never produce an edge
and therefore never interrupt the processor.

Or...
The OS, noting that the device did indeed complete the interrupt,  calls all
the other drivers attached to that interrupt anyway, just to make sure that
they also didn't cause it.  Trouble is, when do you stop looking?

The OS could go down the list and look at Serial 2... which also caused an
interrupt and while there, doing that,  Serial 1 could come calling again.

The OS could keep calling the drivers until all drivers said that they did
not cause an interrupt at which point the OS can send the EOI to the PIC and
give control back to the application.  But, an interrupt can still sneak in
during that one instruction before the EOI that is sent out to the PIC and
the PIC will miss it.

>
>Bottom line isn't too bad.  Good hardware supports shared IRQ's,
>'95 and NT support it also - just be sure when you buy that your com
>boards support and address and any IRQ, and hopefully shared IRQ's.
>(Note that most industrial board suppliers support this stuff,
>ourselves included at (shameless plug) http://www.bb-elec.com

Nice WEB site!

Bottom line is that if you want multiple serial ports than purchase an ISA
card that has a large number of ports with an onboard processor on one IRQ.
If you want more ports than purchase more cards but put them on separate
IRQs.  there are also systems out there that use the SCSI port to impliment
huge numbers of Serial ports.

As this is the PIC list most subscribers will have, or soon will have, an
intimate knowledge of interrupts and physical hardware.  It would benefit
the list if you gave gory details as to how you handled multiple IRQs rather
than anecdotal comments.  ie: What constitues 'Good Hardware'?  What do
drivers do to share IRQs?  How does your software handle the edge verse
level problem.  Otherwise your email reads more like.  "Buy from us.  We
know what we're doing! You don't need to know the details!  Just trust us!"

Regards,

John.

[snip]

>-mike
>EraseMEmfahrionspambb-elec.com
>At home
>
>
Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc.      Ph. 1-250-544-4950
PO Box 20002                  Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9

1997\01\26@152446 by John Dammeyer

flavicon
face
At 08:27 PM 14/01/1997 +0000, you wrote:
>Hate to drag out this non-pic topic, but there's been a lot of
>misconceptions mixed in with good information on this subject.
>
>PC's themselves can handle any number of com ports (I've run 12-16
>"non-intelligent" boards on one machine.  Windows 3.x standard com
>driver will not allow IRQ sharing or higher numbers of ports.  Many
>aftermarket drivers overcome this.  Win95 and NT handle all the ports
>you could need.

Not completely true.  The physical PC architure does not allow interrupt
sharing from separate boards on the ISA bus unless the boards share a common
device driver. Your comment gives the opposite impression. What happens on
one board is design dependent, done with with special circuitry or an on
board processor that can produce one edge from multiple devices.
>
>IRQ Sharing.  Win 95 and NT allow IRQ sharing (meaning two ports IN
>USE at the same time on the same IRQ).  HOWEVER - your port MUST have
>special hardware to support shared IRQ's.  Most off the shelf modems
>& ports don't.  Many boards headed for industrial applications do.
>IRQ sharing works well and I generally recommend it.

As I stated above.  An individual board may have 16 serial ports but it
still produces only one _edge_ triggered interrupt which cannot be shared
with another, different type of ISA card.
>
>Win 95 and NT have pretty much solved most of the dos/win3.x com
>problems of the past.  With the correct hardware and an understanding
>of how things work there shouldn't be any problems.  Granted this all
>comes with a bit of overhead (to say the least) but Pentium machines
>are cheap.  If you are running multiple ports with little buffering
>an no handshaking, just buy a fast machine.

Even NT doesn't address the problem for ISA bus machines.  For non-ISA it
does because they run level triggered.  For example:

Imagine Serial port 1 producing an interrupt.  The service routine begins
and before the service routine ends Serial port 2 on a different ISA card
produces an interrupt on the same IRQ.  This edge from the interrupt is
invisable since the IRQ line is still active.  The device driver for Serial
Port 1 finishes off and tells the OS that it successfully completed the
interrupt.

Several options now.

The OS then writes the EOI to the Programmable Interrupt Controller (PIC)
and continues on;  but the IRQ line is still held asserted by Serial Port 2
so additional characters on any other serial ports can never produce an edge
and therefore never interrupt the processor.

Or...
The OS, noting that the device did indeed complete the interrupt,  calls all
the other drivers attached to that interrupt anyway, just to make sure that
they also didn't cause it.  Trouble is, when do you stop looking?

The OS could go down the list and look at Serial 2... which also caused an
interrupt and while there, doing that,  Serial 1 could come calling again.

The OS could keep calling the drivers until all drivers said that they did
not cause an interrupt at which point the OS can send the EOI to the PIC and
give control back to the application.  But, an interrupt can still sneak in
during that one instruction before the EOI that is sent out to the PIC and
the PIC will miss it.

>
>Bottom line isn't too bad.  Good hardware supports shared IRQ's,
>'95 and NT support it also - just be sure when you buy that your com
>boards support and address and any IRQ, and hopefully shared IRQ's.
>(Note that most industrial board suppliers support this stuff,
>ourselves included at (shameless plug) http://www.bb-elec.com

Nice WEB site!

Bottom line is that if you want multiple serial ports than purchase an ISA
card that has a large number of ports with an onboard processor on one IRQ.
If you want more ports than purchase more cards but put them on separate
IRQs.  there are also systems out there that use the SCSI port to impliment
huge numbers of Serial ports.

As this is the PIC list most subscribers will have, or soon will have, an
intimate knowledge of interrupts and physical hardware.  It would benefit
the list if you gave gory details as to how you handled multiple IRQs rather
than anecdotal comments.  ie: What constitues 'Good Hardware'?  What do
drivers do to share IRQs?  How does your software handle the edge verse
level problem.  Otherwise your email reads more like.  "Buy from us.  We
know what we're doing! You don't need to know the details!  Just trust us!"

Regards,

John.

[snip]

>-mike
>RemoveMEmfahrionEraseMEspamEraseMEbb-elec.com
>At home
>
>
Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc.      Ph. 1-250-544-4950
PO Box 20002                  Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9


'Serial comms'
1997\02\10@102820 by Ed Todd
picon face
A couple of points:

If you are not using hardware flow control, you have to continuously poll
the RX line for a start bit.  If you have other processing to do, poll it
at least once every 0.25 bit widths.

If you are using hardware flow control, some OS's and packages tend to
leave RTS high, even when the queue is empty.  Raise CTS and poll for a
start bit for a while: try about 1 msec.  If nothing comes in, drop CTS.

When you see a start bit, wait till you are between 0.25 and 0.5 of a bit
width in the start bit before starting whatever you are using for a timer.
If you follow the 'rules', you can handle PC data quite easily, since they
send nice, even data.  Media that can give irregular timing (radio, IR) has
its own challenges.
 <RemoveMEedtoddspam_OUTspamKILLspamsni.net>    Ed Todd

1997\02\12@042516 by lmclaren

flavicon
face
Ed Todd wrote:
>
> A couple of points:
>
> If you are not using hardware flow control, you have to continuously poll
> the RX line for a start bit.  If you have other processing to do, poll it
> at least once every 0.25 bit widths.
>
> If you are using hardware flow control, some OS's and packages tend to
> leave RTS high, even when the queue is empty.  Raise CTS and poll for a
> start bit for a while: try about 1 msec.  If nothing comes in, drop CTS.
>
> When you see a start bit, wait till you are between 0.25 and 0.5 of a bit
> width in the start bit before starting whatever you are using for a timer.
> If you follow the 'rules', you can handle PC data quite easily, since they
> send nice, even data.  Media that can give irregular timing (radio, IR) has
> its own challenges.
>   <RemoveMEedtoddTakeThisOuTspamspamsni.net>    Ed Todd

I have been working on a project that needs to listen and do other
things at the same time.
Using a 16c84 at 4MHz and a rtos I am able to listen, send, feed the
send routines, etc just by polling.
The application note on microchips web site is very usefull.


--
Lee McLaren                          EraseMElmclarenspamspamspamBeGonetrumpet.com.au
Comstra pty. ltd.                    RemoveMElmclarenKILLspamspamcomstra.com.au
2 Kirksway place                     phone       03 62244488
Hobart Tasmania                      fax         03 62244601
Australia 7000                       mobil       018 138682

'It was five hours of Boggs's "channelling". After three hours
I asked him to summon up the soul of Jimi Hendrix and requested
All Along the Watchtower. You know, the guy's been dead
twenty years but he still hasn't lost his edge'
Mulder

1997\02\26@200041 by TONY NIXON 54964

flavicon
picon face
I'm using a PIC project for data aquisition and when complete will
down load it's data to a PC for analysis.

I know this next bit is not PIC related, but I am planning on using
Delphi to create a Windows interface for the project to give it an
easy user interface when it is complete. Has anyone addressed a
problem like this before, and if so could you provide some help as
serial comms on a PC seems to be a complex issue.

Tony


Just when I thought I knew it all,
I learned that I didn't.

1997\02\26@220031 by ags

flavicon
face
> I know this next bit is not PIC related, but I am planning on using
> Delphi to create a Windows interface for the project to give it an
> easy user interface when it is complete. Has anyone addressed a
> problem like this before, and if so could you provide some help as
> serial comms on a PC seems to be a complex issue.
When you use Delphi, splurge and pay the $15 (or so) for a shareware
component that will take all of the nastiness out of talking on the com
port.
Look at http://www.delphi32.com (or one of the many other sites with
Delphi components on it) for one that you could use.

Hope this helps,

Alan G. Smith
+---------------------------------------------------------
| Alan G. Smith
| agsSTOPspamspamspam_OUTpoboxes.com
| http://www.innovatus.com/ags

1997\02\27@094726 by Ed Todd

picon face
If you are thinking of writing a windows app yourself, serial comms isn't
too difficult.

OpenComm
       Open COMM port, define buffer sizes
BuildCommDCB, SetCommState
       Configure COMM port (speed, flow control, etc)
ReadComm, WriteComm
       Read/write data
CloseComm
       Close port
See the compiler help files on these and related topics.
 <spamBeGoneedtoddSTOPspamspamEraseMEsni.net>    Ed Todd

1997\02\27@100611 by Alan G. Smith

flavicon
face
Actually this is NOT CORRECT for Win32 (Windows 95, Windows NT).  These
functions have been replaced with the normal
 OpenFile
   ReadFile
   WriteFile
 CloseHandle

Look in MSDN for more details.

Hope this helps!

+---------------
| Alan G. Smith
| KILLspamagsspamBeGonespampoboxes.com
| http://www.innovatus.com/ags

On Thu, 27 Feb 1997, Ed Todd wrote:

{Quote hidden}

1997\02\27@102132 by Robert Zeff

flavicon
face
part 0 1514 bytes

-----Original Message-----
From:   Ed Todd [SMTP:@spam@edtodd@spam@spamspam_OUTSNI.NET]
Sent:   Thursday, February 27, 1997 6:43 AM
To:     spamBeGonePICLISTspamKILLspamMITVMA.MIT.EDU
Subject:        Re: Serial Comms

If you are thinking of writing a windows app yourself, serial comms isn't
too difficult.

OpenComm
       Open COMM port, define buffer sizes
BuildCommDCB, SetCommState
       Configure COMM port (speed, flow control, etc)
ReadComm, WriteComm
       Read/write data
CloseComm
       Close port
See the compiler help files on these and related topics.
 <.....edtoddspam_OUTspamsni.net>    Ed Todd

It is easy if you're doing polled reads.  Usually in a Windows app one would do
overlapped IO with multiple threads for read and write.  There is an ActiveX
(OLE) comm control
that comes with Visual C++ that makes the task easier.

Regards,




                     \\\|///
                   \\  ~ ~  //
                    (  @ @  )
    --------------oOOo-(_)-oOOo---------------
    |                                         |
    |               Robert Zeff               |
    |            Nikola Engineering           |
    |            209-577-4268  x101           |
    |            TakeThisOuTrzeff.....spamTakeThisOuTnikola.com             |
    |   Free Spice for Windows NT / Win95:    |
    |        WWW:  http://Nikola.com          |
    |                                         |
    ----------------------Oooo.---------------
                .oooO     (   )
                (   )      ) /
                 \ (      (_/
                  \_)

1997\02\27@151721 by )

flavicon
face
Tony,

I'm not sure of your budget for your project, if any. However I'd like
to recommend my favorite async library - Async Professional from Turbo
Power Software. I'll qualify this recommendation in that I've only used
the Pascal version of their products, which I have found to be
excellent. The packages sell for under $200. I'm more familiar with the
DOS library. What I liked about it was the first time I used it, it only
took about five minutes for me to learn to use their routines enough
that I could finish the program I was working on.

Their web address is:

http://www.tpower.com


Frank Richterkessing
Experimental Methods Engineer
GE Appliances

TakeThisOuTFRANK.RICHTERKESSINGKILLspamspamspamAPPL.GE.COM


{Quote hidden}

1997\02\27@154404 by Philippe TECHER

flavicon
face
I wrote a little object which drive the serial port thrue Windows function.
This object is in charge to send/receive data and wait until finishing
transmission/reception.
The object is wrote in C++, Borland C++4.5 exactly but I thing it can be
easily translate ine Microsoft C++ or other C++.

If you are interresting, tell me directly.

Regards,
       Philippe (spamBeGoneP.TECHER@spam@spamspam_OUTinsat.com).

1997\02\28@005332 by jattievdl

flavicon
face
I've got a very nice windows interface package with source code from
National instruments Labwindows CVI. You can set the start bits stop
bits, send strings or bits and read the input and output buffer lengths
of the data received and send. The sourcecode is C based with a nice
windows graphic user interface. I'm willing to send it via E-mail if
you're interested.

Best regards

Jattie

1997\02\28@103130 by jattievdl

flavicon
face
It seems thart there's quite some interest in the software I've
mentioned regarding the serial comms. Unfortunately the software is
dedicated to the National Instrument compiler and runtime and the
sourcecode won't run or compile under Visual C++ etc.

I've got a Dosbased discrete sourcecode example of serial comms to a
Dallas touch memory implementing baudrate etc without making use of the
serial drivers. I'm willing to make this available too.

Has anyone got an FTP site that's willing to make this sourcecode and
applications  available.

Best regards

Jattie

1997\02\28@155022 by Jon Bertrand

flavicon
face
    "Alan G. Smith" wrote:

    >Actually this is NOT CORRECT for Win32
    >(Windows 95, Windows NT).  These

    >functions have been replaced with the normal
    >  OpenFile
    >  ReadFile
    >  WriteFile
    >  CloseHandle
    >Look in MSDN for more details.
    >Hope this helps!

    Sorry to be so off topic here:

    There are several bugs in the COMM.DRV in 16 bit windows and I've seen
    evidance that you should ReadFile can destroy data in NT and Win95.

    I snipped this text from TurboPower's Async Pro software for Delphi
    2.0 (a good product).  I'll post it here.  Sorry for the size!

    4. Problems with COMM.DRV and 16-bit applications
    =====================================================================
    COMM.DRV, the Windows 3.1 communications driver, has two major roles:
    1) to program the serial port hardware (the UART) and service all UART
    interrupts; and 2) to provide an API that USER.EXE and application
    programs use to control the serial port and receive and transmit data.

    COMM.DRV has many documented bugs and behavioral quirks. The list
    below
    describes these problems, from most-severe to least-severe. Each item
    indicates whether Async Professional for Delphi works around the issue
    or describes a workaround for application programs.

     1. The posting of communication notification messages may stop
        unexpectedly. Async Professional for Delphi avoids this problem by
        using a timer in conjunction with notification messages.

     2. Random reboots occur when using communication notification events.
        The exact cause of this problem isn't clear and seems to affect
    only
        a small percentage of Windows users. Microsoft's suggested
        workaround is to turn off communication notification events if you
        are affected by the problem. In Async Professional for Delphi,
    this
        is accomplished by setting the TApdComPort.DispatchMode property
    to
        dTimer (the default).

     3. Machines with a PCI bus and a 16550 UART may hang or stop
    processing
        communications events under Windows for Workgroups 3.11. The
        solution is to replace the SERIAL.386 driver that came with
    Windows
        for Workgroups. The complete problem description and the
    replacement
        driver are available in the Microsoft Knowledge Base under entry
        WG1001.

     4. Random hangs or reboots occur when a program uses COM1 with an IRQ
        shared with another open port. Microsoft's suggested solution is
    not
        to share an IRQ with COM1.

     5. Programs appear to hang when closing a communications port. This
        occurs because COMM.DRV attempts to send all data in the output
        buffer before closing a port, which results in an apparent hang if
        output is blocked by flow control. Async Professional for Delphi
        avoids this problem by flushing the output buffer before closing a
        port.

     6. Random program behavior and random crashes occur when input/output
        buffers sizes greater than 32K are used. Async Professional for
        Delphi avoids this problem by limiting buffer sizes to 32K.

     7. The CBR_14400 baud rate constant isn't treated correctly,
    resulting
        in an actual baud rate other than 14400. Async Professional for
        Delphi avoids this problem by passing the baud directly instead of
        using CBR_14400.

     8. The Windows function UngetCommChar may cause data loss or a
    general
        protection fault. Async Professional for Delphi never calls this
        function.

     9. The Windows API does not provide information about the absolute
        value of modem status lines. Microsoft's suggested workaround is
    to
        peek at a location within COMM.DRV to obtain these signal values.
        Async Professional for Delphi implements this workaround by
    default
        but it can be turned off for COMM.DRV replacements that don't
        support the workaround. See the TApdComPort property UseMSRShadow
        for more information.

     10. The Windows documented method of detecting changes in the data
         carrier detect (DCD) signal do not work. The solution is the same
         as in item 9.

     11. SetCommState, when used to set or reset the DTR/RTS signals,
    leaves
         interrupts off too long and may cause data loss. Async
    Professional
         for Delphi avoids this problem by using EscapeCommFunction to
         control the DTR/RTS signals.

     12. Under Windows for Workgroups 3.11 a random byte may be
         transmitted as a port is closed. This is a bug in the SERIAL.386
         driver and can be fixed by downloading WG1001 from the Microsoft
         Knowledge Base, which contains a fixed version of SERIAL.386.


    5. Problems with VCOMM/SERIAL.VXD and 32-bit applications
    =====================================================================
    SERIAL.VXD, the Windows 95 and Windows NT serial port driver has two
    major roles: 1) to program the serial port hardware (the UART) and
    service all UART interrupts; and 2) to work with VCOMM, the general
    purpose serial communications controller, and application programs to
    provide serial port control and input/output functions.

    VCOMM and SERIAL.VXD have one known bug:

     1. At least some releases of Windows NT 3.51 workstation do not
    provide
        access to the RI (ring indicator) modem signal. The Microsoft
        support forum recommends looking for incoming 'RING' strings from
        the modem when waiting for incoming calls instead of using the RI
        signal.


    6. Communications driver replacement sources
    =====================================================================
    Although it is possible for Async Professional for Delphi or an
    application program to work around all known communications
    driver problems, replacement drivers are available which also work
    around these problems. Some replacements also offer higher performance
    or additional features.

    Below is a list of replacement communications drivers that we have
    tested with Async Professional for Delphi. All of these drivers are
    for
    16-bit Windows only; we don't know of any replacement drivers for
    32-bit Windows.

    CYBERCOM.DRV from CyberSoft Corporation Pty Ltd., also available as
    CYBERCOM.LZH on the TurboPower BBS. It's also in several forums on
    CompuServe; one is CYBERC.ZIP in IBMCOM/Comm Utilities.

    TURBOCOM.DRV from Pacific Comware, voice: 503-482-2744, fax:
    503-482-2627, BBS: 503-482-2633.

    For highest performance and reliability, intelligent communications
    boards with replacement drivers are the best solution. Intelligent
    communications boards use a dedicated processor to handle the physical
    serial I/O. This relieves the main CPU of that burden and assures that
    received data is retrieved in a timely fashion. The intelligent board
    then holds the received data until the Windows application asks for
    it.

    Below is a list of intelligent communications boards that we have
    tested
    with Async Professional for Delphi. DigiBoard offers drivers for all
    16-bit and 32-bit Windows environments.

    T/PORT board from Telcor Systems Corporation, voice: 508-653-3995,
    fax:
    508-651-0065.

    DigiBoard family of boards, DigiBoard Incorporated, voice:
    612-912-3444 (800-344-4273), BBS: 612-912-4800, fax: 612-912-4952,
    email: TakeThisOuTsalesspamspamdgii.com


'Serial comms'
1997\03\09@002510 by Ed Todd
picon face
How to do it in code:

If using hardware flow control, check RTS, if raised, raise CTS and start a
timer for 1-3 msecs.

Look for start bit edge.
- if using flow control, check continuously until timer expires
- otherwise, check once every 1/4 bit width, a 'reasonable' sample rate

If edge found:
- if polling continuously in previous step, wait 1/2 bit width
- otherwise wait 1/4 bit width

You are now 1/2 way through start bit (1/4 to 1/2 if sampling rather than
continuous test).  This is a good sample point.

Wait for 9 bit periods to go by, sampling at end of bit period and rolling
inverted line state (0 on line = 1 bit) right through an 8 bit register.

Wait for 1 bit period to go by.  Reject the byte if line high, invalid stop
bit.

When all bytes received, drop CTS if using h/w flow control.

Beware of buffer overrun.  Just because you drop CTS does not mean COMs
stop.  Some cached UARTs empty their buffer before stopping even if flow
control used.

1997\03\09@181543 by Jim Main

flavicon
picon face
In article <199703090524.WAA11341EraseMEspammailrelay.csn.net>, Ed Todd
<RemoveMEedtoddEraseMEspamspam_OUTSNI.NET> writes
>How to do it in code:
>
>If using hardware flow control, check RTS, if raised, raise CTS and start a
>timer for 1-3 msecs.

aren't RTS & CTS the wrong way round above?

Jim

--
Jim Main

1997\03\09@234018 by Lee Jones

flavicon
face
>> How to do it in code:
>>
>> If using hardware flow control, check RTS, if raised, raise CTS
>> and start a timer for 1-3 msecs.

> aren't RTS & CTS the wrong way round above?

Which way 'round depends.  RS-232 is not symmetrical.  Is the
PIC implementing RS-232 DTE (data terminal equipment, e.g. a
PC) or DCE (data circuit-terminating equipment, e.g. modem)?

In a DTE device, RTS (request to send) is an output which is
asserted when the device wants to transmit.  CTS (clear to send)
is an input which is asserted by the other end (communications
equipment) when it's OK to begin transmitting.

In a DCE device, RTS is an input and CTS is an output.

When dealing with RS-232 devices, you always have to keep the
DTE/DCE distinction in mind.

RTS & CTS go back to half-duplex communication systems.  The
modem actually needed the RTS signal to known when to disable
it's demodulator and enable it's modulator.  The modem would
raise CTS when it was ready to begin transmitting data.  This
took 50-100 milliseconds.  Then "fast turn-around" modems were
developed that only took 8 milliseconds.

Once high speed full-duplex models became economically feasible,
the whole point became moot.  And RTS/CTS started being used as
a hardware flow control technique for locally connected devices.

                                               Lee Jones

P.S. Another common hardware flow control is based on DTR (data
  terminal ready, DTE output) & DSR (data set ready, DTE input).

-------------------------------------------------------------------
Jones Computer Communications             @spam@leeRemoveMEspamEraseMEfrumble.claremont.edu
509 Black Hills Dr, Claremont, CA 91711         voice: 909-621-9008
-------------------------------------------------------------------


'Serial comms'
1997\04\20@070731 by Leon Heller
flavicon
picon face
Hello all,

I had a poke around on the Microchip site a few weeks ago and found some
useful source code, I think it was something to do with a training
course. The file is ADVDEMO2.ZIP; I can't remember where it was though.

I've just been playing with the ADVUART.ASM program which is included.
With a couple of minor changes it worked fine with a 4 MHz 16C84 at 9600
baud, interfaced to the PC via a MAX232. It's a lot simpler and easier
to understand than the code in AN555. If anyone has a problem locating
it, I can email a copy.

Leon
--
Leon Heller
Amateur radio callsign: G1HSM
Email: EraseMEleonspam@spam@lfheller.demon.co.uk http://www.lfheller.demon.co.uk
Tel: +44 (0) 118 947 1424 (home) +44 (0) 1344 385556 (work)


'serial comms'
1997\11\17@083016 by Jurgen Fechner
picon face
serial comms on a pc does seem to be a complex issue in windows, but it
is quite easy from dos using C++...

look up bioscom, inportb, outportb

bioscom is basically the C++ version of  int 14h

can you point me towards somewhere where I can find info on the same
subject but for Delphi

Thanks
Jurgen

1997\11\17@104237 by Martin McCormick

flavicon
face
       I wish it was as simple as Interrupt 14H.  The bitter truth is
that what should be the simple act of receiving serial data on a P.C.,
is a nightmare.  Interrupt 14H which is what the bioscom function is based
on will only work as expected on P.C.'s with an IBM-compatible BIOS.

       On other systems, it just doesn't work.  One is almost forced to write
an assembler routine that talks directly with the port.  The Int 14H and
the bioscom function don't even set up interrupt vectors so one is forced
to use lower speeds to keep from missing data.

Martin McCormick WB5AGZ  Stillwater, OK 36.7N97.4W
OSU Center for Computing and Information Services Data Communications Group

1997\11\17@134957 by William Chops Westfield

face picon face
   I wish it was as simple as Interrupt 14H.  The bitter truth is that
   what should be the simple act of receiving serial data on a P.C., is a
   nightmare.  Interrupt 14H which is what the bioscom function is based
   on will only work as expected on P.C.'s with an IBM-compatible BIOS.

   On other systems, it just doesn't work.  One is almost forced to write
   an assembler routine that talks directly with the port.  The Int 14H
   and the bioscom function don't even set up interrupt vectors so one is
   forced to use lower speeds to keep from missing data.

There are assorted TSR programs for DOS that turn Int14h into a reasonably
working, interrupt driven serial port, instead of the cripled crock it
starts as in a standard PC bios.  Check simtel20 mirrors.  I think I wrote
the first of these in 1982 or there abouts, but that one is probably
written in the MIT 8086 cross assembler (not much use anymore?) and better
things have been written since...

(There followed a bunch of comm programs like kermit with very nice serial
drivers of their own, ignoring the existance of int14h.  Then along came
networks and such, and network OS's started putting their remote serial
port APIs on int14.  A program you write using int14 should be able to
communicate using serial, tcp, netbios, IPX, and others, depending on
which TSR is running.)

BillW

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