Software UART for WindowsXP

Now why on earth would you want to do *that*? If you have a UART, why not use it?

It's almost certainly not going to work, anyway. A software-only UART can be a viable thing to implement on an embedded, narrow-purpose system where you have complete control over everything the CPU does.

But on a PC running a strictly user-oriented, GUI multitasking system like XP, there's essentially no way you'll manage to keep sufficiently precise timing for a software UART to work reliably enough to meaningfully test some hardware with it.

And that's before you start worrying how, if you don't have a RS232 port, you would ever get the output of that software UART delivered to the real world. If you don't have RS232, odds are high you won't have any freely programmable I/O pins (a.k.a.: a printer port) either.

Hyperterminal?

Are you just trying to capture the output? If so, I suggest hooking up to another computers RS232 port and using something like Hyper Terminal to log transmissions.

Hope that helps,

Hans,

I too thought about the timing constraints with a PC. But I was wondering how HyperTerminal can send the data and that too at rates higher than 38.4 kBaud. Is this communication reliable in terms of the accuracy of timing?

Other than that, I have some issues about using HyperTerminal (as some folks have suggested). I have to transmit 8 bit Hex data. And my understanding is that HyperTerminal can send only ASCII values. So I was wondering if there is any way to pack this Hex data into 8 bits and send it through in an 8N1 format over the RS232.

Any leads, anyone?

T.

Hans-Bernhard Broeker wrote:

already.]

baud

why

UART

sufficiently

to

have

The bit-level timing is performed by the serial port hardware, based on a clock derived from a crystal osciallator.

Depending on the nature of the software that is running, it may or may not be able to process every receive byte in a timely enough fashion to avoid recieve overruns. This is why 16550-style serial ports have a receive FIFO.

Similarly, if the software is really busy it might not be able to send bytes at the maximum possible rate.

check out the "ComTestSerial" utility at

free download allows you to send and receive binary, ASCII etc up to

Bob

Why, by using a hardware UART, of course! And one with an internal FIFO, at that, because at higher baud rates, Windows' interrupt latency wouldn't even be low enough to deliver one byte at a time before the next one arrives.

Yes.

You're confusing the meanings of words. There's no such thing as "Hex data" opposed to ASCII values. There's raw binary data, which may or not also happen to consist of only ASCII values.

If you want automated high-rate tests, use a programming language to talk to the serial port. Pretty much any language should do.

ww.fifo.se AJ

"Fao, Sean" skrev i meddelandet news:hDB0e.14$ snipped-for-privacy@news.abs.net...