Help with old com port code

[Criss French Member Find all posts View Profile Close Criss French]

trying to figure what this old QB3.5 code snippet was up to. Specifically the OUT p%, 11, which is obviously doing something to the chosen serial port. What is at that address and what does stuffing 11 there do. Also a good link for this kind of old hardware info free online would be greatly appreciated. Thanks and cheers.

INPUT "Port number ( 1 or 2 ) "; Port$
IF VAL(Port$) = 2 THEN p% = &H2FB ELSE p% = &H3FB

OPEN "Com" + Port$ + ":9600,N,8,1,CS0,DS0" FOR RANDOM AS #9
OUT p%, 11
t! = TIMER: WHILE TIMER - t! < .2: WEND       '  delay for .2 second
PRINT #9, "";                                 '  Send set-up characters
PRINT #9, "tw";

[Paul Dixon Member Find all posts View Profile Close Paul Dixon]

Criss,
check out the data sheet for the serial chip (the 16550 UART) you can get one here: http://www-s.ti.com/sc/ds/tl16c550a.pdf

See page 20 of that data sheet for a full explanation, but the line of code appears to be turning on the FIFO built into modern UARTs which defaults to being disabled for compatibility with older UARTs.

Paul.


------------------

[Criss French Member Find all posts View Profile Close Criss French]

Thanks Paul, should have thought to search for the 16550 UART since that's the hardware I'm dealing with. Duh. Was stuck thinking that 'serial port settings' or somesuch would be impossibly overbroad, but you nailed it.

How did you figure it was the fifo register. I remember the base address as &HxF8, so &HxFB is 4'th register, i.e. reg #3. Where's my confusion?

------------------
What can go wrong will go wrong.
Anything can go wrong.
What hasn't?!?!

[This message has been edited by Criss French (edited December 03, 2002).]

[Paul Dixon Member Find all posts View Profile Close Paul Dixon]

Criss,
<<Where's my confusion?>>

The confusion may not be yours!
I was in a hurry when I replied and miscounted the registers (reg 2 appears twice in the list, once as read only once as a write only FIFO control register).

So, 02FB refers to register 3 (they're numbered from 0, not 1) which is the line control register.
The line of code is setting parity and number of bits to 8 data bits, 1 stop bit, ODD parity enabled.

Retrieve and read the 16550 data sheet to check that though!

Paul.



------------------

[Criss French Member Find all posts View Profile Close Criss French]

So, 02FB refers to register 3 (they're numbered from 0, not 1) which is the line control register.
The line of code is setting parity and number of bits to 8 data bits, 1 stop bit, ODD parity enabled.

Retrieve and read the 16550 data sheet to check that though!

Thanks again Paul, I grabbed the data sheet right away when you posted your first reply, found the register table, and carefully counted out the registers to make shure I wasn't wrong. I concluded that it must be the parity, stopbits, etc. Don't know why the guy used "9600,N,8,1,CS0,DS0" if he wanted something else. Go figure. Between his strange approach and your initial slipup I was really left wondering which wrong was right. Now I will go and clean up that old code.

Another interesting possibility was that using OUT to clear the FIFO's could be a way to clear up some of the mystery problems that folks have had when trying to open comm ports connected to things like GPS that send a steady data stream (or in this case a graphics tablet). I have had that problem too before, using several different QB3.5 compiled programs. But with the same device (a sounder), on all the same machines, PB3.5 compiled code ran perfectly. I used to have to unplug the sounder every time I launched a comm program, until I recompiled with PB, or else face a solid lock up. I have heard of others in this forum with that trouble under PB, so I suspect that both hardware quirkiness and compiler differences can be factors. With experimentation one might be able to use the right OUT's to pre-condition the comm ports just before the OPEN, avoiding that trouble. I for one am finally free of the problem though (free of QB3.5), and won't be looking back unless I am forced to

------------------
What can go wrong will go wrong.
Anything can go wrong.
What hasn't?!?!

[This message has been edited by Criss French (edited December 04, 2002).]

[Tom Hanlin Member Find all posts View Profile Close Tom Hanlin]

The QB comm handler had a rigid design incorporating hardcoded
limitations based on early comm hardware. The OUTs may be to allow
bps rates and other settings that could not be implemented directly
through QB.

There was a bug in several versions of QB where it was necessary to
employ a specific INP or OUT command after a particular kind of comm
error. In all versions of QB, it was necessary to have error trapping
turned on, so you could catch (and ignore) certain kinds of transient
comm errors.

So, there's probably a fair bit of odd-looking overhead in that old
program that you can cheerfully dispense with in your PB programs.

------------------
Tom Hanlin
PowerBASIC Staff

[Criss French Member Find all posts View Profile Close Criss French]

Works Great! Thanks for the help guys. It's a program to digitize paper rolls from a chart recording survey depth sounder. I had to completely rebuild the thing to make it work right. I actually think the last guy was just on glue, that out statement did nothing but set odd parity. He wrote horrible chicken scratch that leaves me quite puzzled here and there. After much 'refactoring' of the code the thing makes sense, and works nicely. And bravo to PB for excellent comm support. And tight fast code. And working exactly like it's supposed to every time. And and and... OK, I'll shut up now. Almost. I've rebuilt about 6 different important programs now from QB3.5 to PB3.5, and I'm not regreting one second of it. It works better, and I like the programs better (love USING$()).