I am trying to test a modem by pinging it with some data at 38400 baud using an 8N1 format over a serial RS232 link. I was wondering if someone had code (for WinXp) for a software UART which will do the same.
Any suggestions/ideas/comments on the same will be most welcome.
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.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
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.
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.
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.
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.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.