Searching \ for 'PC Hardware (again)' 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/index.htm?key=hardware+again
Search entire site for: 'PC Hardware (again)'.

Truncated match.
PICList Thread
'PC Hardware (again)'
1998\12\29@104154 by Andy Kunz

flavicon
face
How do I tell teh UART in a PC to speak even though the modem/handshake
lines tell it not to?

It looks like THAT is more of a problem than the IRQs were :-(

Andy

==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

1998\12\29@135726 by Gerhard Fiedler

picon face
At 10:37 12/29/98 -0500, Andy Kunz wrote:
>How do I tell teh UART in a PC to speak even though the modem/handshake
>lines tell it not to?

can you get more specific? AFAIK, all the handshake lines (RTS, CTS, DTR)
in normal UARTs are software controlled, but i've seen more advanced SCCs
which would allow to configure a hardware controlled handshake.

ge

1998\12\30@171850 by Tom Handley

picon face
  Andy, if you want to take over the PC's serial port in a
`non-multitasking-friendly' manner, here is a C `snippet' that I use:

>From the header file:
---------------------

/* Type Definitions */

typedef   unsigned char   UBYTE;  /* Old habbit...     */
...

/* Serial Port Definitions */

#define   COM1_BASE   0x3F8       /* COM1 Base Address */
#define   COM2_BASE   0x2F8       /* COM2 Base Address */
#define   COM3_BASE   0x3E8       /* COM3 Base Address */
#define   COM4_BASE   0x2E8       /* COM4 Base Address */
#define   COM_BASE    COM2_BASE   /* COM  Base Address */

/* Function Prototypes */

void  InitUSART(void);            /* Initialize USART  */
void  TxData(UBYTE);              /* Transmit Data     */
UBYTE RxData(void);               /* Receive  Data     */
...

>From the application file:
--------------------------
  Note, there are a lot of ways to do this. I use these routines as a
generic package and add sections relating to CTS/RTS and DTR/DSR as needed.
Also, they do not provide a time-out for a port that is not responding nor
do they use interrupts. I've used them up to 115.2K with handshaking
disabled. Works fine with a 20MHz PIC16C76/77 at 115.2K.
(BRGH = 1, SPBRG = 10). This is also the interface to my weather station and
my PIC-based logic analyzer which is in the prototype stage.

/*
  InitUSART() - Initialize USART to 115200, 8 Data Bits, No Parity, 1 Stop
Bit
*/
void InitUSART(void)
{
 outp(COM_BASE + 1, 0x00);   /* Turn off interrupts                    */
 outp(COM_BASE + 3, 0x83);   /* Access Divisor Latch                   */
 outp(COM_BASE + 0, 0x01);   /* Set 115200 (115200/1) Baud             */
 outp(COM_BASE + 1, 0x00);
 outp(COM_BASE + 3, 0x03);   /* Access DFM reg. Configure Data Format  */
 outp(COM_BASE + 4, 0x03);   /* Disable Loop, !OUTx. Enable !RTS, !DTR */
}

/*
  TxData() - Send Data to Serial Port
  Entry:
     data = Data to transmit
*/
void TxData(UBYTE data)
{
 UBYTE x;

 do                              /* Check for Tx Buffer Empty */
 {
   x = inp(COM_BASE + 5);
   x &= 0x20;
 } while(x == 0);

 outp(COM_BASE + 0, data);       /* Send Data                 */
}

/*
  RxData() - Receive Data from the Serial Port
  Exit:
     data = Rx Data
*/
UBYTE RxData(void)
{
 UBYTE x, data;

 while(TRUE)                     /* Check for Rx Data */
 {
   x = inp(COM_BASE + 5);
   x &= 0x01;
   if(x == 1)
   {
     data = inp(COM_BASE + 0);   /* Get Data          */
     break;
   }

   if(kbhit())                   /* Abort if Keypress */
   {
     getch();
     printf("\n");
     break;
   }
 }
 return(data);
}

  For Handshaking, I use the following:

 /* Wait for !CTS */
 do
 {
   x = inp(COM_BASE + 6);
   x &= 0x10;
 } while(x == 0);

 /* Wait for !DSR */
 do
 {
   x = inp(COM_BASE + 6);
   x &= 0x20;
 } while(x == 0);

 /* Wait for !RI  */
 do
 {
   x = inp(COM_BASE + 6);
   x &= 0x40;
 } while(x == 0);

 /* Wait for !DCD */
 do
 {
   x = inp(COM_BASE + 6);
   x &= 0x80;
 } while(x == 0);

 /* Disable !RTS  */
 x = inp(COM_BASE + 4);
 x &= 0xFD;
 outp(COM_BASE + 4, x);

 /* Enable !RTS  */
 x = inp(COM_BASE + 4);
 x |= 0x02;
 outp(COM_BASE + 4, x);

 /* Disable !DTR */
 x = inp(COM_BASE + 4);
 x &= 0xFE;
 outp(COM_BASE + 4, x);

 /* Enable !DTR  */
 x = inp(COM_BASE + 4);
 x |= 0x01;
 outp(COM_BASE + 4, x);


  - Tom

At 10:37 AM 12/29/98 -0500, Andy Kunz wrote:
{Quote hidden}

1998\12\30@220145 by chrispian khoo

picon face
>From spam_OUTowner-piclistTakeThisOuTspammitvma.mit.edu Tue Dec 29 15:27:17 1998
>Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by
walnut-backup.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id
<.....1.0001CB40KILLspamspam@spam@walnut-backup.ease.lsoft.com>; Tue, 29 Dec 1998 13:51:39
-0400
>Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV release 1.8c)
with
>          NJE id 0131 for PICLISTspamKILLspamMITVMA.MIT.EDU; Tue, 29 Dec 1998
13:57:26
>          -0500
>Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
>          V1.2b/1.8b) with BSMTP id 9777; Tue, 29 Dec 1998 13:57:08
-0500
>Received: from ha1.rdc1.sdca.home.com [24.0.3.66] by mitvma.mit.edu
(IBM VM
>          SMTP V2R4a) via TCP with SMTP ; Tue, 29 Dec 1998 13:57:07 EST
>X-Warning: mitvma.mit.edu: Host ha1.rdc1.sdca.home.com claimed to be
>           mail.rdc1.sdca.home.com
>Received: from cx48592-a ([24.4.88.50]) by mail.rdc1.sdca.home.com
(InterMail
>          v4.0 201-221-107) with SMTP id
>          <19981229185657.YKKM29537.mail.rdc1.sdca.home.com@cx48592-a>
for
>          <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU>; Tue, 29 Dec 1998 10:56:57 -0800
>X-Sender: lists@mail
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>Message-ID:  <4.1.19981229104948.0094e3b0@mail>
>Date:         Tue, 29 Dec 1998 10:56:33 -0800
>Reply-To:     pic microcontroller discussion list
<EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>
>Sender:       pic microcontroller discussion list
<PICLISTspamspam_OUTMITVMA.MIT.EDU>
>From:         Gerhard Fiedler <@spam@listsKILLspamspamHOME.COM>
>Subject:      Re: PC Hardware (again)
>To:           KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
>In-Reply-To:  <RemoveME3.0.1.32.19981229103720.00691ca8TakeThisOuTspampop.fast.net>
>
>At 10:37 12/29/98 -0500, Andy Kunz wrote:
>>How do I tell teh UART in a PC to speak even though the
modem/handshake
>>lines tell it not to?
>
>can you get more specific? AFAIK, all the handshake lines (RTS, CTS,
DTR)
>in normal UARTs are software controlled, but i've seen more advanced
SCCs
>which would allow to configure a hardware controlled handshake.
>
>ge
>

Hey guys

Talking about the handshake lines in (RTS CTS DTR, do u have to program
the pic (example: pic16c73 in this case) to configure these lines, even
when you're not going to use it? What I'm saying is that I'll fixing up
a null modem for the RS232 cable, using only TX, RX & gnd.

Take the example below quoted from a tutorial application from
microchip,

It says, "We will also use RC5 and RA5 as the terminal handshake lines
RTS and CTS, although these signals are not used in this application.
Following convention though we will set RTS as an input and CTS will be
driven low. "

the codes:" ;RTS must be = 00 cts MUST = 00
            BSF PORTC,5 ;RTS
            BSF PORTA,5 ;CTS

Dazed & confused?
Bye


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

1998\12\30@230157 by Gerhard Fiedler

picon face
At 19:01 12/30/98 -0800, chrispian khoo wrote:
>Talking about the handshake lines in (RTS CTS DTR, do u have to program
>the pic (example: pic16c73 in this case) to configure these lines, even
>when you're not going to use it? What I'm saying is that I'll fixing up
>a null modem for the RS232 cable, using only TX, RX & gnd.
>
>Take the example below quoted from a tutorial application from
>microchip,
>
>It says, "We will also use RC5 and RA5 as the terminal handshake lines
>RTS and CTS, although these signals are not used in this application.
>Following convention though we will set RTS as an input and CTS will be
>driven low. "


if you're not using these lines, you don't have to use them :-)

seriously, some comm apps expect something on the CTS input of the UART, so
it's usually a good thing to loop RTS (from PC UART) back to CTS (of PC
UART) if that might be the case. other than that you don't have to worry
about these handshake lines.

ge


'PC Hardware (again)'
1999\01\01@032221 by paulb
flavicon
face
Andy Kunz wrote:

> How do I tell the UART in a PC to speak even though the modem/
> handshake lines tell it not to?

 So in summary, on the 8250 series, it is the other way around, your
software has to implement any handshake dependencies/ flow control you
require.  It's all up to you!

 Some early programs *may* require preconditions, such as valid DCD, to
send data (I used to use the Motorola 6850 which had this restriction)
but except for a "tied" application, these are now *obsolete*.  (It was
in the event necessary to link out DCD in the 6850 - a totally useless
"feature".)

 They have been rendered obsolete by the virtually universal adoption
of the Hayes Modem standard, which requires that the modem be commanded
in order to connect.  When it is commanded it is of course, off line and
the DCD is necessarily "false".

 Hayes modems do make certain expectations of the handshake lines, so
you do in practice need to provide suitable control of these, but all of
these may *if required* be disabled in the modem.

 Basically, you provide the software support to suit the modem/
application, the UART places no restriction other than those sequence/
timing matters implicit in its buffering.
--
 Cheers,
       Paul B.

1999\01\04@023549 by Dr. Imre Bartfai

flavicon
face
Hi,
the UART in a PC WILL speak always if you want. The question is: how do
you tell it to it?

- if you write the data register (THRE/TSRE bits should be checked before
as they both must be 1), the data will be transmitted regardless of the
status of the handshake lines.

- if you use the BIOS services (INT 14h) use a loopback connector for
handshake lines (RTS-CTS, DSR-DTR-DCD)

- if you use something other, (some 3rd party routines) then RTFM.

All I wrote here is true using DOS.

I hope this helps.

Imre

On Tue, 29 Dec 1998, Andy Kunz wrote:

{Quote hidden}

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