elimination of intercharacter gap in RS232 stream?

"Grant Edwards" <grante@visi.com> wrote in message 
news:13hsesd1pj0dnc6@corp.supernews.com...
> On 2007-10-23, Bo <bo@cephus.com> wrote:
>
>> IRQ was disabled in the BIOS. After setting an interrupt for
>> com3/com4 the problem was fixed.
>
> Yup.
>
>> This leads me to the question: what/how/where is the
>> connection from BIOS to OS to drivers, made? Any links?
>
> I'm not sure what you're asking.  The BIOS enables/disabled
> various chipset modules.  The drivers just try to use those
> modules and don't generally know how/if they can be enabled or
> disabled.

What is the mechanism by which the kernel, or a driver, knows what the BIOS 
settings are?
>
>> I was assuming that the driver, when loaded, knew he needed to
>> be IRQ driven from the OS. Apparently this is not the case...
>
> The driver knows that it needs to be IRQ drivin.  It just
> doesn't know whether the IRQ is actally connected as expected.

So if it is expecting to be IRQ driven and the BIOS hasn't assigned an IRQ, 
how did it know this and I assume, revert to a polling mode? I'm surprised 
it worked at all. Seems that the OS or driver at load should have generated 
a warning/error during boot to let user know an expected resource was not 
there? And if the driver has a polling mode, why that polling mode gave junk 
data in the middle of a buffer and missed a couple or so bytes at the end of 
the buffer that _were_ in the serial data (seen on the scope)? Does the BIOS 
create a resource table somewhere in fixed location memory that the OS then 
use to have visibility into the system hardware? Or does the OS perform a 
PnP type query and not care what the BIOS setting is (this seems improbable 
to me)?


> [Well, actually the setserial program can try to discover what
> IRQ is connected to a given UART.  I never had a lot of luck
> with it.]

An application?

Thanks,

Bo 

On 2007-10-25, Bo <bo@cephus.com> wrote:

>>> This leads me to the question: what/how/where is the
>>> connection from BIOS to OS to drivers, made? Any links?
>>
>> I'm not sure what you're asking.  The BIOS enables/disabled
>> various chipset modules.  The drivers just try to use those
>> modules and don't generally know how/if they can be enabled or
>> disabled.
>
> What is the mechanism by which the kernel, or a driver, knows
> what the BIOS settings are?

It doesn't know (in general).

>>> I was assuming that the driver, when loaded, knew he needed to
>>> be IRQ driven from the OS. Apparently this is not the case...
>>
>> The driver knows that it needs to be IRQ drivin.  It just
>> doesn't know whether the IRQ is actally connected as expected.
>
> So if it is expecting to be IRQ driven and the BIOS hasn't
> assigned an IRQ, how did it know this

It didn't.  It was trying to use the default IRQ.

> and I assume, revert to a polling mode?

It didn't.

> I'm surprised it worked at all.

If the IRQ that the driver is waiting for is being generated by
a different bit of hardware (say a mouse), then sometimes that
happens often enough to make things limp along.  Or, if you
call read()/write() often enough, that will service the FIFOs
and make things sort of work part of the time.

> Seems that the OS or driver at load should have generated a
> warning/error during boot to let user know an expected
> resource was not there?

It doesn't have any way to know the resource isn't there
without doing some possibly distruptive hardware probing.  

The serial ports are ISA bus devices.  They're not
plug-and-play. There's no safe, reliable way for the driver to
find out what hardware is there and and how the IRQs are
configured.  It can try, but there's the possibility that doing
so will lock up some unknown hardware or generate external
signals that aren't good.

> And if the driver has a polling mode,

It doesn't.

> why that polling mode gave junk data in the middle of a buffer
> and missed a couple or so bytes at the end of the buffer that
> _were_ in the serial data (seen on the scope)? Does the BIOS
> create a resource table somewhere in fixed location memory

No.

> that the OS then use to have visibility into the system
> hardware?

No.

> Or does the OS perform a PnP type query

No -- not for serial ports anyway.  Drivers for some other ISA
board types (e.g. ISA network cards) try to probe to see if the
card is there and discover it's configuration.  But, the UARTs
don't know what IRQ (if any) they're hooked to.

> and not care what the BIOS setting is (this seems improbable
> to me)?

The user (you) is expected to configure the serial port HW and
driver parameters so that they match.  That's the way the ISA
bus works -- or doesn't work, in many cases. ;)

>> [Well, actually the setserial program can try to discover what
>> IRQ is connected to a given UART.  I never had a lot of luck
>> with it.]
>
> An application?

Yes.  If you tell it to, it will try to auto-probe in order to
figure out what UART type is installed and what IRQ it's hooked
to (and optionally configure the device driver to match).  

The driver doesn't do that itself because auto-probing can lock
up a machine if some other bit of hardware is there instead of
the expected UART, or if the IRQ goes somewhere unexpected.

The ISA bus sucked the day it was born, and it still sucks.

If you get a PCI serial card, none of these problems happen.
PCI serial cards "just work".

-- 
Grant Edwards                   grante             Yow! I know th'MAMBO!!
                                  at               I have a TWO-TONE CHEMISTRY
                               visi.com            SET!!