- Set enablePin high
- Send some characters
- Wait for empty transmit buffer
- Wait for the transmission to complete
- Set enablePin low
If you leave out the wait steps, the code "turns off" the RS485 chip too quickly, because the last byte is still being sent from the serial hardware port.
Ive been trying to see if there is something similar I need to do on the ESP8266.
I found this code - https://github.com/plieningerweb/esp8266-software-uart
In that code, just before setting the enablePin to low, we wait for an amount of time
os_delay_us(s->bit_time*6);
Waiting this long might work 95% of the time – or perhaps all the time – either way it doesn’t seem to be quite the right thing to do. Is it in fact possible for the chip to be doing some work with wifi during this delay(with a possible consequent timing problem)? Then I read Kolbans excellent book http://neilkolban.com/tech/esp8266 - in the section “Working with Serial”
To find out how many bytes are on the various queues, we have to go pretty low level. For example, the number of bytes on the TX queue is given by:
(READ_PERI_REG(UART_STATUS(uart_no))>>UART_TXFIFO_CNT_S) & UART_TXFIFO_CNT;
So my question is – rather than waiting a “fixed” amount of time, would it be better to have a while loop to wait until the TX queue is empty? If so does that limit us to the hardware UART and in any case I don’t understand the difference between the hardware UART and “software serial”
Obviously I could try it – but again, something that mostly works is not as good as something that implements the “correct” way to do things.
Any thoughts?