Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.msdos.misc > #352
| From | DOS Guy <DOS@Guy.com> |
|---|---|
| Newsgroups | comp.os.msdos.misc, alt.msdos.programmer, comp.os.msdos.programmer |
| Subject | Re: Which newsgroup to discuss details of serial-port programming? |
| Date | 2012-02-08 22:12 -0500 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <4F33399B.80C7B393@Guy.com> (permalink) |
| References | <4F31C4B5.E3E5B364@Guy.com> <4F327A82.EE0D3C75@Guy.com> <1328727343snz@nospam.demon.co.uk> |
Cross-posted to 3 groups.
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.
Back to comp.os.msdos.misc | Previous | Next — Previous in thread | Next in thread | Find similar
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
csiph-web