Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #456 > unrolled thread

Which newsgroup to discuss details of serial-port programming?

Back to article view | Back to comp.os.msdos.programmer

Contents

  Which newsgroup to discuss details of serial-port programming? DOS Guy <DOS@Guy.com> - 2012-02-07 19:41 -0500
    Re: Which newsgroup to discuss details of serial-port programming? pete@nospam.demon.co.uk - 2012-02-08 07:13 +0000
    Re: Which newsgroup to discuss details of serial-port programming? "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-08 03:12 -0500
    Re: Which newsgroup to discuss details of serial-port programming? DOS Guy <DOS@Guy.com> - 2012-02-08 08:37 -0500
      Re: Which newsgroup to discuss details of serial-port programming? DOS Guy <DOS@Guy.com> - 2012-02-08 09:29 -0500
        Re: Which newsgroup to discuss details of serial-port programming? Jim Leonard <mobygamer@gmail.com> - 2012-02-08 07:20 -0800
          Re: Which newsgroup to discuss details of serial-port programming? DOS Guy <DOS@Guy.com> - 2012-02-08 21:38 -0500
            Re: Which newsgroup to discuss details of serial-port programming? "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-09 02:16 -0500
      Re: Which newsgroup to discuss details of serial-port programming? pete@nospam.demon.co.uk - 2012-02-08 18:55 +0000
        Re: Which newsgroup to discuss details of serial-port programming? DOS Guy <DOS@Guy.com> - 2012-02-08 22:12 -0500
          Re: Which newsgroup to discuss details of serial-port programming? Jim Leonard <mobygamer@gmail.com> - 2012-02-09 07:23 -0800
            Re: Which newsgroup to discuss details of serial-port programming? DOS Guy <DOS@Guy.com> - 2012-02-09 19:57 -0500
              Re: Which newsgroup to discuss details of serial-port programming? Jim Leonard <mobygamer@gmail.com> - 2012-02-10 07:13 -0800
        Re: Which newsgroup to discuss details of serial-port programming? Jim Higgins <invalid@invalid.invalid> - 2012-02-09 23:39 +0000
          Re: Which newsgroup to discuss details of serial-port programming? Sjouke Burry <s@b> - 2012-02-10 00:34 +0000
            Re: Which newsgroup to discuss details of serial-port programming? Jim Higgins <invalid@invalid.invalid> - 2012-02-15 17:40 +0000
          Re: Which newsgroup to discuss details of serial-port programming? pete@nospam.demon.co.uk - 2012-02-11 20:50 +0000
            Re: Which newsgroup to discuss details of serial-port programming? Jim Higgins <invalid@invalid.invalid> - 2012-02-15 17:46 +0000
              Re: Which newsgroup to discuss details of serial-port programming? pete@nospam.demon.co.uk - 2012-02-15 18:26 +0000

#456 — Which newsgroup to discuss details of serial-port programming?

What usenet newsgroup(s) are there for discussion of the finer points of
writing software for reading / writing to the uarts found in a typical
PC?

(the issue I'm dealing with has nothing to do with the OS or even the
programming language being used - it's all about the registers and the
FIFO's).

[toc] | [next] | [standalone]

#457

In article <4F31C4B5.E3E5B364@Guy.com> DOS@Guy.com "DOS Guy" writes:

> What usenet newsgroup(s) are there for discussion of the finer points of
> writing software for reading / writing to the uarts found in a typical
> PC?
> 
> (the issue I'm dealing with has nothing to do with the OS or even the
> programming language being used - it's all about the registers and the
> FIFO's).

I'd say here (comp.os.msdos.programmer) is as good as any, though I 
noticed the article was cross-posted to other equally relevant groups.  
There might be a more focused hardware group (alt.comp.hardware? 
comp.sys.ibm.pc.hardware.misc? ) but I guess most of the regulars here 
will have experience of programming the serial ports at low level.  I 
suppose it depends where most traffic is...

Pete 
-- 
Believe those who are seeking the truth.
Doubt those who find it.  -  André Gide

[toc] | [prev] | [next] | [standalone]

#458

"DOS Guy" <DOS@Guy.com> wrote in message news:4F31C4B5.E3E5B364@Guy.com...
> What usenet newsgroup(s) are there for discussion of the finer points of
> writing software for reading / writing to the uarts found in a typical
> PC?
>
> (the issue I'm dealing with has nothing to do with the OS or even the
> programming language being used - it's all about the registers and the
> FIFO's).

It's probably not an issue of a group, but an issue of locating someone with
actual experience.  They're likely to be "around" on some similar group
that's relevant to their current interests.  That may require posting to a
variety of groups, and maybe moving the conversation to where it's on-topic.
There might be someone still around here (comp.os.msdos.programmer).  I'd
also try alt.os.development to find someone.  There are a few guys still
programming x86 hardware there.  You might also try x86 assembly groups such
as alt.lang.asm and comp.lang.asm.x86.  c.l.a.x. is moderated and posts
should be x86 assembly related, but it's another place where you could
locate someone with the necessary experience.  You could also try others
like comp.arch, comp.arch.embedded, or comp.sys.ibm.pc etc.  There are a few
sub-groups in comp.sys.ibm.pc hierarchy.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#459

I know that there have been many varients of the 8250 uart over the
years, and making this even more fuzzy is knowing the exact performance
specs when the uart is incorporated into a motherboard chipset or
multifunction asic, but...

The issue I'm dealing with is writing a set of data (16 bytes) to a uart
using I/O commands (I'm reading and writing directly to the ports, not
using any bios routines, not using any interupts, etc).

If the more modern versions of these uarts have 16-byte read/write
buffers, then I should be able to fire off a set of data (16 bytes)
without having to monitor the fifo and tx buffer status bits (bits 5 and
6 of uart register 5).  But when I try that, the computer on the
receiving end doesn't like what it's getting (the receiving program
hangs or crashes).

But when I monitor the status of those bits as I'm writing the data, and
only write new data when one (or the other) of those bits are not low,
then the data exchange works fine.

It's almost like the uart is acting like it has only a 1-byte write fifo
- but I am enabling the fifo's by writing the appropriate data to other
registers.

I'm using 2-port PCI card for this work, with the uart integrated into a
single ASIC that is also handling the PCI bus interface.  This work is
being done in a pure DOS environment (not running under linux or NT) so
there is no OS interference or virtualization happening here.

Ideas?

Comments?

[toc] | [prev] | [next] | [standalone]

#460

Basically, on the assumption that I'm working with uarts that have
16-byte fifo's, and that I'm enabling them correctly:

Given an empty fifo as a starting point, I can't seem to write data to
the fifo any faster than they're leaving the uart through the transmit
register.  I should at least be able to fill up the tx fifo really
quickly - even before the first byte has been fully transmitted out of
the uart.

[toc] | [prev] | [next] | [standalone]

#461

On Feb 8, 8:29 am, DOS Guy <D...@Guy.com> wrote:
> Basically, on the assumption that I'm working with uarts that have
> 16-byte fifo's, and that I'm enabling them correctly:
>
> Given an empty fifo as a starting point, I can't seem to write data to
> the fifo any faster than they're leaving the uart through the transmit
> register.  I should at least be able to fill up the tx fifo really
> quickly - even before the first byte has been fully transmitted out of
> the uart.

Is the information in http://courses.engr.illinois.edu/ece390/resources/serial.html
any help?  Specifically the section starting with "Why and how to use
the FIFOs"?

[toc] | [prev] | [next] | [standalone]

#463

Jim Leonard wrote:

> Is the information in 
> http://courses.engr.illinois.edu/ece390/resources/serial.html
> any help?  Specifically the section starting with "Why and how to use
> the FIFOs"?

I had a look at that document, and to be honest - no.

There is a lot of talk in these various guides and documents about the
history and development of these uarts, the bugs and how they were
corrected, etc. 

But none of that is of any use when the hardware you're working with
doesn't actually contain discrete uart chips so you don't know if you're
working with a 16550 or 16650.

Beyond that, I haven't come across any document that mentions the timing
contraints when you're sending data to a uart to fill the TX fifo.

One would think that if you're starting with an empty fifo, that you can
blast 16 bytes to the uart without needing to monitor anything.

[toc] | [prev] | [next] | [standalone]

#465

"DOS Guy" <DOS@Guy.com> wrote in message news:4F3331BA.DB28243F@Guy.com...
...

> But none of that is of any use when the hardware you're working with
> doesn't actually contain discrete uart chips so you don't know if you're
> working with a 16550 or 16650.
>

Not sure if this helps ...

16C550 (16 byte FIFO)
16C650 (32 byte FIFO)
16C750 (64 byte FIFO)
16C850 (128 byte FIFO)
16C950 (128 byte FIFO)

> Beyond that, I haven't come across any document that mentions the timing
> contraints when you're sending data to a uart to fill the TX fifo.

The first link is an application note and has coding flow charts and x86
code examples.  That might be what you need.  The others are datasheets for
various 16-series UARTs from various manufacturers.

"The NS16550A: UART Design and Application Considerations"
National Semiconductor Application Note 491
http://ftp.utcluj.ro/pub/users/nedevschi/PMP/WLab/serial/uart/AN-491.pdf

"PC16550D Universal Asynchronous Reciver/Transmitter with FIFOs"
http://www.ti.com/lit/ds/symlink/pc16550d.pdf

"OX16C950 rev B High Performance UART with 128 byte FIFOs"
http://www.semiconductorstore.com/pdf/newsite/oxford/ox16c950b.pdf

"CAST Altera H16750S UART with FIFOs, IrDA, and Synchronous CPU Interface
Megafunction"
http://www.cast-inc.com/ip-cores/uarts/h16750s/cast_h16750s-a.pdf

"IMP16C550 Universal Asynchronous Receiver/Transmitter (UART) with 16-BYTE
FIFO's"
http://www.ds-imp.com.cn/pdf/IMP16C550.pdf

"XILINX XPS 16550 UART"
http://www.xilinx.com/support/documentation/ip_documentation/xps_uart16550.pdf

HTH,


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#462

In article <4F327A82.EE0D3C75@Guy.com> DOS@Guy.com "DOS Guy" writes:

> I know that there have been many varients of the 8250 uart over the
> years, and making this even more fuzzy is knowing the exact performance
> specs when the uart is incorporated into a motherboard chipset or
> multifunction asic, but...
> 
> The issue I'm dealing with is writing a set of data (16 bytes) to a uart
> using I/O commands (I'm reading and writing directly to the ports, not
> using any bios routines, not using any interupts, etc).

It's a lot easier enabling and using interrupts....

> If the more modern versions of these uarts have 16-byte read/write
> buffers, then I should be able to fire off a set of data (16 bytes)
> without having to monitor the fifo and tx buffer status bits (bits 5 and
> 6 of uart register 5).  But when I try that, the computer on the
> receiving end doesn't like what it's getting (the receiving program
> hangs or crashes).
> 
> But when I monitor the status of those bits as I'm writing the data, and
> only write new data when one (or the other) of those bits are not low,
> then the data exchange works fine.
> 
> It's almost like the uart is acting like it has only a 1-byte write fifo
> - but I am enabling the fifo's by writing the appropriate data to other
> registers.

The 8250 has a 1-byte write buffer, so it looks like that is the chip 
your PCI card is using/emulating.  Only the later 16550 chip has a 
FIFO buffer, and by all accounts the FIFO implementation in early 
versions was broken; you can can only rely on a 16550AF or later for a 
working FIFO (or so I believe).

For seriously large data transfers, I'd strongly recommend the 
interrupt driven approach -- it's a bit of extra setup work but well 
worth the effort IMHO.  However, if you are only sending 16 bytes then 
I'd suggest ignoring any FIFO and just polling the TBE bit(5) of the 
line status register (base + 5) to determine when it's safe to 
serialise the next byte.  If you can lay your hands on a copy of the 
book "C Programmers Guide to Serial Communications" by Joe Campbell 
(SAMS, ISBN 0-672-22584-0) all is explained there.  Alternatively I do 
have some old 8086 asm code lying around here for a buffered comms TSR 
(using interrupts) I'll happily email it to you.

Pete
-- 
Believe those who are seeking the truth.
Doubt those who find it.  -  André Gide

[toc] | [prev] | [next] | [standalone]

#464

pete@nospam.demon.co.uk wrote:
 
> The 8250 has a 1-byte write buffer, so it looks like that is the
> chip your PCI card is using/emulating.

I can't believe that an off-the-shelf dual-port PCI serial card is going
to be emulating the ancient 8250 and not the 16550.

> Only the later 16550 chip has a FIFO buffer, and by all accounts
> the FIFO implementation in early versions was broken;

I've read that a lot, but I haven't been able to find a description of
exactly how the fifo was broken in that particular version.

> For seriously large data transfers, I'd strongly recommend the
> interrupt driven approach --

What I've got works well without the hassles of setting up interrupts.

This is the setup:

Two computers, one running XP, the other running DOS.

The XP computer has a socket-478 P4 cpu (2.8 ghz - just so you know the
horsepower this machine has).  It has a proprietary ISA data acquisition
board.  It's running a compiled PowerBasic (v 3.5) program that performs
direct I/O access to the card (no dma or interrupts on the card - the
card has 128 kb of data buffering capacity).  The program can perform
direct I/O access because it's "wrapped" in a port-talker program stub
that has poked some holes in the NT port permission map.

The PB program performs real-time data acquisition, saving, and plotting
of up to 32 data traces on screen (in VGA mode) at acquisition rates
from 200 to 400 hz per channel.  There are a total of 148 data streams
or channels being acquired by the card, each data element being 16 bits
and all streams being acquired at 200 to 400 hz.  So we have 148 x 2
(bytes per sample) = 296 bytes x 200 (hz) = 59,200 bytes per second.

This was all originally designed back when this card and sofware would
have been running on a i486-based motherboard running at maybe 133 mhz,
streaming data to a 200 mb hard drive, circa 1994.

So the task for the serial port is to convey 16 channels of data to a
secondary computer for real-time trace display on a larger monitor.

This was first attempted using PowerBasic's native com functions, but
this proved too troublesome when unknown com port errors happened after
highly erratic periods of operation (ie - streaming would work for xx
minutes and then the program running on one or the other computer would
kack).  The serial port was set up for 115.2 kbaud operation.
At that point, the native com functions were abandoned and direct port
access was done using PowerBasic's native inp and out functions.  This
proved to be much more robust, and data transfer reached very close the
the theoretical maximum for the 115.2 kbuad operation.

Next, it was proposed to use 2 com ports to double the data transfer
rate.  This is where I discovered this issue with writing to the TX
output buffers of the uarts.

My original code was to have 2 sequential loops - each loop being a
16-byte write operation, first to com1, then 16 bytes to com2.  With
that implimented, I found that I wasn't attaining the expected doubling
of the effective overall buad rate to 230 kbuad, but instead just
maintaining the existing 115.2 kbaud - as if the uarts don't have any
fifo buffering.

So what I did next was to alternate or interleve the writes between the
two ports.

This DID have the desired effect - of doubling the throughput.

So at this point my problem is solved.  The extra code running on the
sending computer to send this data to the receiving computer is having
no noticable effect on that computer's performance when it comes to
displaying and saving the acquired data, so I really don't have to
explore this apparent lack of efficiency at not being able to utilize
the TX fifo buffers - but I'd still like to know why they appear to not
work in an effective manner.

[toc] | [prev] | [next] | [standalone]

#466

On Feb 8, 9:12 pm, DOS Guy <D...@Guy.com> wrote:
> So the task for the serial port is to convey 16 channels of data to a
> secondary computer for real-time trace display on a larger monitor.

Curious; was there a reason you couldn't use a local LAN with packet
drivers instead?

[toc] | [prev] | [next] | [standalone]

#469

Jim Leonard wrote:
 
> > So the task for the serial port is to convey 16 channels of data
> > to a secondary computer for real-time trace display on a larger
> > monitor.
> 
> Curious; was there a reason you couldn't use a local LAN with
> packet drivers instead?

What powerbasic commands are there to open and send data through an
ethernet port?

[toc] | [prev] | [next] | [standalone]

#470

On Feb 9, 6:57 pm, DOS Guy <D...@Guy.com> wrote:
> > Curious; was there a reason you couldn't use a local LAN with
> > packet drivers instead?
>
> What powerbasic commands are there to open and send data through an
> ethernet port?

Interrupts, for talking with the packet driver (very low level) or
winsock (provides a TCP and UDP stack).

[toc] | [prev] | [next] | [standalone]

#467

On Wed, 08 Feb 2012 18:55:43 +0000 (UTC), pete@nospam.demon.co.uk
wrote:

>Alternatively I do have some old 8086 asm code lying around here
>for a buffered comms TSR (using interrupts) I'll happily email it to you.

Any chance you could post it somewhere for download?  Please?

[toc] | [prev] | [next] | [standalone]

#468

Jim Higgins <invalid@invalid.invalid> wrote in 
news:28m8j71ohsjru7a5tebe0kj1piv4ei4d3s@4ax.com:

> On Wed, 08 Feb 2012 18:55:43 +0000 (UTC), pete@nospam.demon.co.uk
> wrote:
> 
>>Alternatively I do have some old 8086 asm code lying around here
>>for a buffered comms TSR (using interrupts) I'll happily email it to 
you.
> 
> Any chance you could post it somewhere for download?  Please?
> 

Check out this comport pack, buffered witout interrupts.
put the program on two pc's wit a null modem cable,
and start typing on both sides.
http://home.planet.nl/~burry004/comport.zip
source code and executable testprogram.

[toc] | [prev] | [next] | [standalone]

#484

On 10 Feb 2012 00:34:42 GMT, Sjouke Burry <s@b> wrote:

>Jim Higgins <invalid@invalid.invalid> wrote in 
>news:28m8j71ohsjru7a5tebe0kj1piv4ei4d3s@4ax.com:
>
>> On Wed, 08 Feb 2012 18:55:43 +0000 (UTC), pete@nospam.demon.co.uk
>> wrote:
>> 
>>>Alternatively I do have some old 8086 asm code lying around here
>>>for a buffered comms TSR (using interrupts) I'll happily email it to 
>you.
>> 
>> Any chance you could post it somewhere for download?  Please?
>> 
>
>Check out this comport pack, buffered witout interrupts.
>put the program on two pc's wit a null modem cable,
>and start typing on both sides.
>http://home.planet.nl/~burry004/comport.zip
>source code and executable testprogram.

Thank you!

[toc] | [prev] | [next] | [standalone]

#475

In article <28m8j71ohsjru7a5tebe0kj1piv4ei4d3s@4ax.com>
           invalid@invalid.invalid "Jim Higgins" writes:

> On Wed, 08 Feb 2012 18:55:43 +0000 (UTC), pete@nospam.demon.co.uk
> wrote:
> 
> >Alternatively I do have some old 8086 asm code lying around here
> >for a buffered comms TSR (using interrupts) I'll happily email it to you.
> 
> Any chance you could post it somewhere for download?  Please?

Done.  It should now be available at 

        www pdlhost demon co uk / utils / buffcomm.zip

Pete
-- 
Believe those who are seeking the truth.
Doubt those who find it.  -  André Gide

[toc] | [prev] | [next] | [standalone]

#485

On Sat, 11 Feb 2012 20:50:47 +0000 (UTC), pete@nospam.demon.co.uk
wrote:

>In article <28m8j71ohsjru7a5tebe0kj1piv4ei4d3s@4ax.com>
>           invalid@invalid.invalid "Jim Higgins" writes:
>
>> On Wed, 08 Feb 2012 18:55:43 +0000 (UTC), pete@nospam.demon.co.uk
>> wrote:
>> 
>> >Alternatively I do have some old 8086 asm code lying around here
>> >for a buffered comms TSR (using interrupts) I'll happily email it to you.
>> 
>> Any chance you could post it somewhere for download?  Please?
>
>Done.  It should now be available at 
>
>        www pdlhost demon co uk / utils / buffcomm.zip
>
>Pete


Thank you.  Looking at this it came back to me...  it's what we used
to call a FOSSIL driver.  Good stuff.  Thanks again.

[toc] | [prev] | [next] | [standalone]

#486

In article <pnrnj791psqjmj304p71tgk4jolnr75rsa@4ax.com>
           invalid@invalid.invalid "Jim Higgins" writes:

> On Sat, 11 Feb 2012 20:50:47 +0000 (UTC), pete@nospam.demon.co.uk
> wrote:
[snip]

> Thank you.  Looking at this it came back to me...  it's what we used
> to call a FOSSIL driver.  Good stuff.  Thanks again.

I was probably a FOSSIL when I wrote it -- certainly am now ;-)

Pete
-- 
Believe those who are seeking the truth.
Doubt those who find it.  -  André Gide

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.msdos.programmer

csiph-web