Bypass serial port driver? (PB5.0)

[Michael Schwab]

I do serial communications in a polled fashion from a 2ms high priority
thread, and the serial port driver (being interrupt-driven) is just getting
in my way. I would like to be free to access the 16550 registers directly
myself. But I need to get the OS serial port driver "out-of-the-way".

Can I do this simply by removing the two blocks of registry entries for COM1
and COM2, and rebuilding the OS? Or will that crash the system on boot when
it tries to access COM1 for debug messages?

If I must leave COM1 registry entries in to avoid system crash, can I
re-direct it away from 03f8 to some other I/O address that is not used? (To
"fake out" the OS)

[Bruce Eitman [eMVP]]

Serial drivers are not used for debug output, the hardware is used but not
the driver.

Remove those entries and test it.

--
Bruce Eitman (eMVP)
Senior Engineer
beitman AT applieddata DOT net

Applied Data Systems
www.applieddata.net
An ISO 9001:2000 Registered Company
Microsoft WEP Gold-level Member

"Michael Schwab" <Michae...@discussions.microsoft.com> wrote in message
news:CB220590-E30D-46BE...@microsoft.com...

[Michael Schwab]

Ah, I wondered about that, since I still see the debug messages come out
after I open COM1 in my application. The debug messages are just
interspersed between messages I transmit. I still need to get rid of those
so they don't interfere with our use of the port. I found another thread
here about how to shut off the debug messages, so I'll try that.

So the debug messages are just blasted to 0x3f8 regardless of the registry
entries for COM1?

OK, thanks for the reply. I will indeed try removing the entries and see
what happens! :)

[Paul G. Tobey [eMVP]]

The HAL is responsible for where debug messages go, so there should be some
sort of a setting in your BSP to turn them off. Without knowing what BSP,
we can't say much more than that...

Paul T.

"Michael Schwab" <Michae...@discussions.microsoft.com> wrote in message

news:D7112D42-470C-4181...@microsoft.com...

[Remi de Gravelaine]

Hi,

If, as your hardware suggests, you are using an x86 machine and have some
control on the loader, you may consider setting ucComPort in the Bootargs
structure to something else that the default "1" value (1 stands for PC
COM1, @0x3F8.) Setting ucComPort to 2 will direct serial debug output to
0x2F8 and clearing it will disable it.
Keep in mind that the default CEPC eboot.bin uses 0x3F8 @ 38400 bauds,
regardless of ucComPort settting...

HTH
Remi

[Michael Schwab]

I have x86 (but I'm not sure how you guessed that! :) ) - Advantech SOM-4455
and Ampro ETX-610 cards (so far) with LX800 Geode. We are considering
Celeron 600 as well. But I don't know what "control on the loader" means.
Is this a setting in Platform Builder somewhere?

Advantech provides their own program (replaces io.sys) that only has this
BOOTCEPC.CNF file:
N:NK BIN
B:3
S:BOOTCEPCPCX
;L:640x480x16
L:800x600x16
;L:1024x768x16
;L:640x480x8
;L:800x600x8
;L:1024x768x8

The Ampro uses the DOS boot loader loadcepc.exe, and my Find shows that
ucComPort is somewhere in that file, buy my hex editor can't find it.

Where would I find this ucComPort to set it to zero?

It sounds like I need to ask the BSP vendors how to do this.

[Remi de Gravelaine]

>I have x86 (but I'm not sure how you guessed that! :) )

Well, AFAIK, machines that have a 16550-compatible UART at 0x3F8 are usually
PC's :^)

> But I don't know what "control on the loader" means.
> Is this a setting in Platform Builder somewhere?

No. Sorry for my english. The loader is something like loadcepc or
Advantech's code that replaces io.sys. It is the piece of code that is
responsible for setting the Bootargs up.

> The Ampro uses the DOS boot loader loadcepc.exe, and my Find shows that
> ucComPort is somewhere in that file, buy my hex editor can't find it.
>
> Where would I find this ucComPort to set it to zero?

I can't remember loadcepc's options right now but I think you should be able
to set the "debug COM port" value on the command line. Otherwise, you should
have the source code available with your Platform Builder
(Public\Common\Csp\X86\etc... AFAIR)

> It sounds like I need to ask the BSP vendors how to do this.

Right. It is probably the best thing to do.

Remi

[Michael Schwab]

Yes, indeed, I looked up command line options, and loadcepc /C:0 worked great
to turn off the debug messages on the Ampro. Advantech has not found an
answer for me as yet.

[Rob]

Why direct polling of the HW ?
It is not the most system-efficient or flexible way of doing things.
Blocking on a read (for a limited time) is a better option in most cases.
This gives a faster response on incoming data, and does not tie up the
processor.

But you might have some exotic commport issue that I donot know of....

Greetings,
Rob.