>>> 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!!
Reply by Bo●October 25, 20072007-10-25
"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
Reply by Robert Adsett●October 24, 20072007-10-24
In article <13hte24o7ib311d@corp.supernews.com>, Grant Edwards says...
> On 2007-10-24, Robert Adsett <sub2@aeolusdevelopment.com> wrote:
>
> > ASCII made a lot of sense for the implementation, if only
> > because it is easy to debug with a simple monitor.
>
> 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
--
Posted via a free Usenet account from http://www.teranews.com
Reply by Grant Edwards●October 24, 20072007-10-24
On 2007-10-24, Robert Adsett <sub2@aeolusdevelopment.com> wrote:
> ASCII made a lot of sense for the implementation, if only
> because it is easy to debug with a simple monitor.
ASCII is tons easier to debug and far more foolproof. IMO,
ASCII should be the default for any application that isn't
bandwidth limited.
--
Grant Edwards grante Yow! I invented skydiving
at in 1989!
visi.com
Reply by Robert Adsett●October 23, 20072007-10-23
In article <13hqvpnr29p7j3f@corp.supernews.com>, Grant Edwards says...
> On 2007-10-23, Robert Adsett <sub2@aeolusdevelopment.com> wrote:
> > In article <13gtanpb99n382@corp.supernews.com>, Grant Edwards says...
> >> On 2007-10-11, cbarn24050@aol.com <cbarn24050@aol.com> wrote:
> >> > On Oct 11, 6:45?am, Paul Keinanen <keina...@sci.fi> wrote:
> >> >
> >> >> Modbus is a quite common industrial protocol that requires that the
> >> >> space between characters within the message is less than 1.5 character
> >> >> times.
> >> >
> >> > Thats not right accoring to my sources. There are two modbus
> >> > protocalls ASCII and binary.
> >>
> >> In my experience, only the latter has been used for the past 15
> >> years or so.
> >
> > I just did an ASCII one recently (in Rapid yet) to control an AC drive.
>
> 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.
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
--
Posted via a free Usenet account from http://www.teranews.com
Reply by Grant Edwards●October 23, 20072007-10-23
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.
> 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.
[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.]
--
Grant Edwards grante Yow! Vote for ME -- I'm
at well-tapered, half-cocked,
visi.com ill-conceived and
TAX-DEFERRED!
Reply by Bo●October 23, 20072007-10-23
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
"Bo" <bo@cephus.com> wrote in message
news:50921$470d02cb$41a26d4d$30902@API-DIGITAL.COM...
> Writing an Embbeded Linux app for a PC104/Versalogic board. Linux
> 2.6.14.17.
>
> Using write() to transmit data packets to another PC104 board. If I
> write()
> 30 bytes, sometimes there is a 2-5mS gap in the middle of the
> transmission, usually at about byte 15-20, but sometimes at byte 29--as
> seen on a scope. Tried using low latency setting when
> opening the port--but this made no difference. This is causing
> difficulties for the receiving end-- and we have yet to add two more
> serial ports to the application.
>
> Any ideas on how to force continous transmission of the data?
>
>
> Thanks,
>
> Bo
>
Reply by Grant Edwards●October 23, 20072007-10-23
On 2007-10-23, Robert Adsett <sub2@aeolusdevelopment.com> wrote:
> In article <13gtanpb99n382@corp.supernews.com>, Grant Edwards says...
>> On 2007-10-11, cbarn24050@aol.com <cbarn24050@aol.com> wrote:
>> > On Oct 11, 6:45?am, Paul Keinanen <keina...@sci.fi> wrote:
>> >
>> >> Modbus is a quite common industrial protocol that requires that the
>> >> space between characters within the message is less than 1.5 character
>> >> times.
>> >
>> > Thats not right accoring to my sources. There are two modbus
>> > protocalls ASCII and binary.
>>
>> In my experience, only the latter has been used for the past 15
>> years or so.
>
> I just did an ASCII one recently (in Rapid yet) to control an AC drive.
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.
--
Grant Edwards grante Yow! Jesus is my
at POSTMASTER GENERAL...
visi.com
Reply by Robert Adsett●October 23, 20072007-10-23
In article <13gtanpb99n382@corp.supernews.com>, Grant Edwards says...
> On 2007-10-11, cbarn24050@aol.com <cbarn24050@aol.com> wrote:
> > On Oct 11, 6:45?am, Paul Keinanen <keina...@sci.fi> wrote:
> >
> >> Modbus is a quite common industrial protocol that requires that the
> >> space between characters within the message is less than 1.5 character
> >> times.
> >
> > Thats not right accoring to my sources. There are two modbus
> > protocalls ASCII and binary.
>
> In my experience, only the latter has been used for the past 15
> years or so.
I just did an ASCII one recently (in Rapid yet) to control an AC drive.
Robert
--
Posted via a free Usenet account from http://www.teranews.com
Reply by Robert Adsett●October 23, 20072007-10-23
In article <vratg3th99pospet0ns86vro4n39l6ebv0@4ax.com>, Paul Keinanen
says...
> On Thu, 11 Oct 2007 15:26:12 -0700, cbarn24050@aol.com wrote:
>
> >On Oct 11, 6:45?am, Paul Keinanen <keina...@sci.fi> wrote:
> >
> >> Modbus is a quite common industrial protocol that requires that the
> >> space between characters within the message is less than 1.5 character
> >> times.
> >
> >Thats not right accoring to my sources. There are two modbus
> >protocalls ASCII and binary. Only the binary version frames the
> >message blocks with gaps (because it cannot send control characters).
> >The ASCII version can have gaps as long as 1 second between characters.
>
> Have you actually seen anybody using Modbus ASCII in contrast to
> Modbus RTU or Modbus/TCP ?
Yes. You really have to be careful with absolutes in a forum this large
:)
Robert
--
Posted via a free Usenet account from http://www.teranews.com