how to understand end of transmition in serial port

Projects Programming
1

hi

i have a esp8266 12e and rs485 driver ic for comminucation to a modbus rtu device

when i use Serial.write(my_data_buffer , number_of_data_in_buffer)

this function send my_buffer to serial buffer and immediately go to next line of program

simultaneous hardware serial sending data and execute next lines of my program

i need to understand end of transmission buffer for switch rs485 to receive response of rtu device

please help me to how detect end of transmit serial port of my_buffer immediately

2

The best way to detect that a full message has been received is to have an end of message character either one that you have explicitly appended to the message or a Carriage Return character added by the transmitting system

Read Serial input basics - updated for ideas and examples

3

thanks UKHeliBob
but i need to understand end of transmit no receive
of course DI and RE pin in driver ic connected to one pin of esp8266
therefor i don't receive in transmit time

4

Sorry but I find it difficult to understand what you want to do in either your original post or the latest one.

If the problem is that Serial.write() with a length parameter moves quickly to the next program statement then you could iterate through the my_data_buffer array and send one byte at a time. That way you will know exactly what has been sent and that you have completed the transmission.

If the problem is that data is being added to the output buffer whilst data is being sent from it then consider using a second buffer to hold incoming data during serial transmission

If neither of these is the problem, then please give more details and maybe an example of the problem.

5

Serial.flush() should help.

6

Can the 'end-of-transmission' be known by polling the TXC0-bit (USART Transmit Complete) of UCSR0A Register?

while(bitRead(UCSR0A, 6) != HIGH)
{
    ;
}
7

Alternative to Serial.flush() is to check with Serial.availableForWrite(); this can allow (maybe within limits) for non-blocking code. When transmission is done, it should return 64.

GolamMostafa:
Can the 'end-of-transmission' be known by polling the TXC0-bit (USART Transmit Complete) of UCSR0A Register?

while(bitRead(UCSR0A, 6) != HIGH)

{
    ;
}

I think that that only works per byte, not per sequence of bytes.

8

sterretje:
I think that that only works per byte, not per sequence of bytes.

How does the following command work in the Arduino Platform? (My thought is still linked with Assembly Platform.)

Serial.write(myArray, sizeof(myArray));

1. I think that the above instruction writes one byte at a time on the UART Port/Transmit Register.

Or

2. The instruction queues the bytes onto FIFO buffer from which they are asserted on the Transmit Register one byte at a time by 'interrupt process'?

9

Number 2. Till such time that FIFO buffer is full.

10

sterretje:
Number 2. Till such time that FIFO buffer is full.

Till such time that FIFO buffer is (full.) empty?

11

Serial.print/write start blocking once the FIFO is full.

Sorry for the confusion that this caused.

12

sterretje:
Serial.print/write start blocking once the FIFO is full.

Sorry for the confusion that this caused.

Happy day! (K+)

13

check with Serial.availableForWrite() ... When transmission is done, it should return 64.

At which point, there will still be a byte in the TX Shift register, and another one in the buffer register.
And it assumes that the buffer was 64 to start with... On an AVR.

On AVR, I believe that Serial.flush() has gone to some trouble to ensure that those last bytes are sent before it returns. But the OP is using an ESP8266, which has a signficantly different UART (128byte hardware FIFOs, according to the TRM!), so who knows? Actually looking at the code, I see:

void HardwareSerial::flush(){
      :
    uart_wait_tx_empty(_uart);
    //Workaround for a bug in serial not actually being finished yet
    //Wait for 8 data bits, 1 parity and 2 stop bits, just in case
    delayMicroseconds(11000000 / uart_get_baudrate(_uart) + 1);

So it does seem to be "trying."

this can allow (maybe within limits) for non-blocking code.

Good point...

14

thanks for all
Serial.flush is best way
it's OK
best regard