uart write behavior

[mhanuel26]

Hi,

I want to know if it's possible to know when the uart has transmitted the data out of the interface.

My experience is that uart write method buffers the data, but I need to know the exact moment that there are no more bytes to send so I can toggle a GPIO. One way is to make write method blocking, which I understand is not possible.

I was trying to see if the native API offer additional control over this so I can write my low level app in C++ but it seems there is no additional uart core support different than AT API.

Will appreciate your comments,

[Fleker]

I don't believe there is any direct knowledge of the UART buffer, although as far as I know it's fairly expedient. What level of latency are you expecting?

[mhanuel26]

Hello @Fleker

Thanks for your response,

I am trying to work with RS-485 using two wires, I have to disable the driver as soon as the last bit is transferred, this was not working when I call UART.write followed by the GPIO toggle instruction.

Would you suggest me a workaround?

[Fleker]

Do you have to disable it at the exact time of the last bit? Can you get away with a 10ms timeout?

One workaround could be to add a UART line back to your device on the Rx pin so that you can see exactly when the data is sent out of the bus.

[mhanuel26]

Well, the closer the better,. The problem is that 10ms might be too much for high baud rate. Actually a normal baud rate of 19200 means several bits in a 10ms, so at the end it will depend on how fast the other peer can react and send data. If I do not disable the driver before the other peer start sending the response, the channel will get corrupted and data loss.

I think the workaround can be really messy, because I have to somehow code an "UART idle detector", it might involve timers, etc ...

[Fleker]

Can the receiving peripheral send an ACK byte back to your device when it receives the last part of the response?

[mhanuel26]

That would be part of the communication protocol.
The problem is rather at the physical layer, for RS-485 when having only two wires, the channel is half duplex, is suppose there is only one device transmitting at a given time, for the modbus case that device is called Master. It's the physical medium which impose the need to disable the driver since both driver and receiver are sharing the same two wires.
You simple cannot receive correctly if the driver is enable, which is really simple to do on an MCU or when you can control the transmitting timing, i.e. to know the exact time there are no more bytes to transmit.
I think the AT should be able to provide some way to allow this, as this is the way RS-485 works in two wires mode.

[mhanuel26]

Hi @Fleker ,

Would it be possible to have an upcoming release of AT that makes a UART.write blocking?
Or what I am trying to do might just be not possible with AT and ban be considered a dead road then.

Please let me know your thoughts,

[Fleker]

You can file a feature request for the framework using the issue tracker.

Is it possible to use four wire RS-485?

I'm going to ask some folks and get their insight.

[mhanuel26]

Four wires would be good since it's like full duplex, the problem is that most industrial RS-485, specially modbus devices are wired in the field using two wire scheme. Basically if you have a 4 wire device and you want to connect to a 2 wire network you just join A-Y and B-Z terminals.
By the way, here is the hardware I used for testing.