Hallo everyone, I have problem with communication over serial port.
This is what I am having problem with:
I need to make communication with device which has usb on rs232 convertor and fifo memory.
I sent data to fifo memory in same time device read data from fifo memory.
When micro (in device) sees that memory is full, it change state of CTS signal. CTS signal stays in that state until memory is half full.
I have problem to write code in C that sends data to device but considering CTS.
I send data as char byte array, memory is 4K , speed is 38400
Does anyone have a clue how I can solve this mistery
Milan
But you didn't bother to update the old thread to say where this new one is, did you?
The old thread was about an ARM (lpc2148); now you've chosen C51 - so what chip, exactly, are you actually using?
"I have problem to write code in C that sends data to device but considering CTS"
What problem, exactly, do you have?
Isn't it obvious:
IF cts is clear THEN you can send data ELSE you must wait & try again
"Does anyone have a clue how I can solve this mistery"
There is no mystery - it's just a perfectly normal case of thinking about your control logic!
Hardware Flow Control is, of course, very common indeed - have you actually tried googling, or any other research...?
What is the mistery [sic!]?
Why don't you just read the CTS state before you insert characters into the FIFO? That is quite the same as for a "normal" UART where you have a "not full" bit somewhere in a status register that tells if you can fill up the UART FIFO (or maybe just the transmit holding register) or if you need to wait until one or more characters have been sent.
Baudrate, FIFO size, send buffer size etc is really irrelevant to the problem. It's just a question of "fits at least one more character" or "does not fit more characters".
"It's just a question of 'fits at least one more character' or 'does not fit more characters'"
Except that the question is now, "transmission is allowed" or "transmission is not allowed" (according to the state of CTS).
Apart from that, as you say, the principle is identical - there is no mystery!
interesting problem. A way I would achieve data transfer is have a microcontroller acting as a "buffer" to RX the data at 9600bps, then have it relay it (without all of the unnecessary stuff like protocol sticks in the data transfer) at a very low speed, say 300bps, with a little bit of error correction/checksumming. The other end has a RX that feeds data into a buffer on the microcontroller, then it's turned into stuff it can understand (a really inefficient 50-bytes per packet format that has a lot of wastage in terms of time management). I've tried getting it to talk to a box, but as the data protocol is very confusing I have not achieved this as of yet (I designed a "token-based" chat/webpage system which sends matrices with the data in them, as these can be sent without exiting a program.) Over radio links, lower speed is better to combat cruddy receivers and potential interference.
This post will be edited later with more information.
but the OP's problem is that (s)he can't even do that!
"RX the data at 9600bps"
You have to receive the data at whatever speed the source sends it - the OP specifically stated 38400.!
"This post will be edited later with more information."
I don't really see that your post has anything to do with this thread?