elimination of intercharacter gap in RS232 stream?

Quick follow-up-- was not the video card... still stymied.

Bo

Yes. You really have to be careful with absolutes in a forum this large :)

Robert

I just did an ASCII one recently (in Rapid yet) to control an AC drive.

Robert

How old was the drive? I implemented Modbus for a few different products back in the early 90's, and I supported both ASCII and RTU. But I never ran into any installations that used ASCII.

Follow-up to group--- we found/fixed the problem:

IRQ was disabled in the BIOS. After setting an interrupt for com3/com4 the problem was fixed.

This leads me to the question: what/how/where is the connection from BIOS to OS to drivers, made? Any links?

I was assuming that the driver, when loaded, knew he needed to be IRQ driven from the OS. Apparently this is not the case...

Thanks to all for the suggestions/thoughts....

Bo

Yup.

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.

The driver knows that it needs to be IRQ drivin. It just doesn't know whether the IRQ is actally connected as expected. [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.]

It was a new drive (completely new installation), I don't know how old the drive design was.

ASCII made a lot of sense for the implementation, if only because it is easy to debug with a simple monitor.

Robert

ASCII is tons easier to debug and far more foolproof. IMO, ASCII should be the default for any application that isn't bandwidth limited.

Which certainly wasn't an issue in this case. It takes the motor on the order of seconds to ramp to speed.

I'm not sure it would even be possible to achieve RTU timings in Rapid. I wasn't tempted to try.

Robert

What is the mechanism by which the kernel, or a driver, knows what the BIOS settings are?

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)?

An application?

Thanks,

Bo

It doesn't know (in general).

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

It didn't.

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.

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.

It doesn't.

No.

No.

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.

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. ;)

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".