I am trying to communicate with a black box reciever with its onchip uar tuned to 115200 bps, 8 data bits, and 1 stop bit. I am sending a text fil of size 105KB to the reciever from my PC through the Hyperterminal but wit a character delay of 1 ms. If i dont keep that character delay, i dont ge the required acks back from the reciever. And sending with a 1ms dela takes about 28 minutes to get into the reciever and give me vali acknowledgement.
Please help me configure out a way for this problem and also why at 11520 bps, this much time should be taken...
This is a problem crying out for an oscilloscope. You need to take a look at the time delay between the transmission of your character and the receipt of the ACK character. If that time is less than about
1 millisecond, and the time between transmitted character the problem is with Windows and Hyperterm.
Windows is notoriously bad with programmmed delays---they often end up being some multiple of the old DOS time tick---which is about 55 milliseconds, IIRC. It may be that Hyperterm is really extending your desired 1Msec delay to 18msec.
You could also figure that out by examining the output from Hyperterm with an oscilloscope. Since you may not have one handy, I did this test for you---and voila! The time between characters with a specified
1mSec character delay is somewhere between 10 and 20 milliseconds--- and varies greatly. This seems to support the hypothesis that Hyperterm is using a delay routine with a clock that ticks at somewhere between 50 and 60Hz.
I think you need to figure out how to do this transfer without the character delays. If you really need an ack for each character, your transmission time should depend on the speed with which the receiver can fetch the input character and send the ACK.
Maybe your device uses hardware handshaking signals to indicate to the host (e.g. hyperterm) that it is ready to receive data. Check if your box' manual says anything about the type of handshaking and cable that should be used.
After dealing with Hyperterminal for many years, I find that a good working hypothesis is:
"It's Hyperterminal's fault."
Start by getting a decent terminal emulator. Teraterm is free and way, way better than HT. There are other free terminal emulators as well. All are vastly better than Hyperterminal.
HT is a waste of bits.
--
Grant Edwards grante Yow! I'm thinking about
at DIGITAL READ-OUT systems
visi.com and computer-generated
IMAGE FORMATIONS...
That could be -- I didn't think to ask about that.
Unfortunately paying more doesn't always mean it's going to work better. Some of the cheap ones work fine, some of the expensive ones don't.
They all seem to work better under Linux than Windows (at least for me).
Even with the ones that work fine, trying to do anything with them that requires precise timing is futile. With a USB adapter, you can't expect to something like a 1ms delay between characters.
Even with an directly connected UART getting reliable 1ms delays between bytes just isn't going to happen unless you're using an RTOS.
--
Grant Edwards grante Yow! Yes, but will I
at see the EASTER BUNNY in
visi.com skintight leather at an
IRON MAIDEN concert?
On single processor NT/2000 systems the Sleep(1) nominally 1 ms delay would be about 0-10 ms, on multiprocessor systems 0-16 ms. However, if the multimedia timers are enabled, Sleep(1) would at least try to sleep for about 1 ms, of course there can be large variations depending of load, even when the program executes in the realtime priority class.
I have a usb-serial adapter that I was suprised to find that total transfer time was halved compared to a conventional serial port in one particular application (both under Linux). The application sends out a character and then waits for it to be echoed back before sending the next character. I have used the adapter on several different flavours of Linux and it behaved the same. Suprised.
You probably could have sped up the conventional serial port drastically by setting the low latency flag and setting the RX FIFO size to 1 on the device using the setserial program. By default, the Linux serial drivers are set up to be optimal for things like PPP that transfer largish blocks of data (more than
10ms worth).
The default configuration is it's pretty sub-optimal for things like sending a single byte and waiting for a single byte to come back.
--
Grant Edwards grante Yow! .. does your DRESSING
at ROOM have enough ASPARAGUS?
visi.com
Setting aside that pretty much anything that can drive a serial port on Windows works a whole lot better than Hypoterminal, that statement doesn't make any sense at all. You just stated an analogon of: "I use a cheap car and it works a whole lot better than a pair of trousers".
Sorry Guys for the delay. Ws out of college on a vactiona ndnow i m back. Well, after reading all the posts to this query the following points ar cleared further.:
No i dont use a usb-serial adapter.
I use only the RS232 Cable to connect to my receever and my PC>
I have tried this thing out with TeraTerm also and i find that i nee to have that 1ms delay there too to get the valid ack messages.
the reciver is not mine. I dont hve the source code for the reciever else there wouldnt hve been any problem at all in debugin the transfer.
As far as i recall enabling/disabling the FIFO does not have any efec on slwoing the transfer bcoz everything is controlled by the LSR only i this case of No flow control applications.
Lacking any quotations, your reply is totally meaningless. Every article should stand by itself. Previous traffic may, in fact probably, is not available to your readers.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
Sorry Guys for the delay. Ws out of college on a vactiona ndnow i m back. Well, after reading all the posts to this query the following points are cleared further.:
No i dont use a usb-serial adapter.
I use only the RS232 Cable to connect to my receever and my PC>
I have tried this thing out with TeraTerm also and i find that i need to have that 1ms delay there too to get the valid ack messages.
the reciver is not mine. I dont hve the source code for the reciever, else there wouldnt hve been any problem at all in debugin the transfer.
As far as i recall enabling/disabling the FIFO does not have any efect on slwoing the transfer bcoz everything is controlled by the LSR only in this case of No flow control applications.
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.