Serial 1 half duplex filling RX buffer when using Serial1.write()?

Firmware
1

I am getting some behavior I didn’t expect, and that I don’t understand, when using half duplex mode on Serial 1. I am trying to implement a 1-wire UART to communicate to a PGA308 (programmable gain amplifier). I believe I have the communications working… mostly. At least, the data that I get back from the chip looks all correct, it’s just the way I have to get the data that seems odd.

The issue I am having is that after sending data to the chip to program registers and then sending the commands to read back a register value, when I do a Serial1.read() all the commands I sent out are stored in the RX buffer. Is that the expected behavior? That would imply that if I sent too much data before I wanted to read anything in from the chip that I could overflow my RX buffer?

Do I really need to read back in all the commands I just sent before I can get to the useful information? That seems like a waste of processing time.

2

I think you are experiencing this

You are reading back your TX data in the RX buffer

If you are using a fairly low baudrate (less than 38400), you could try out my ParticleSoftSerial library which should work better - I’m also open for any error reports :wink:

1 Like
3

Thanks @ScruffR. Yep, that seems like the same issue. Had you ever heard from anyone on whether or not that was the intended behavior of halfduplex? If it will be fixed one day I may just work around it for now and then remove the extra steps needed to deal with it after a fix.

I’ll definitely take a peek at your library. I’m trying to write an auto-calibration routine to zero out a strain gage, more or less while it’s actually being used, so I think I need the baud near the max chip rate of 114k, if I can get it. I guess the question is, would it be faster to flush() then read() to empty the buffers of the sent data or to use a software library at a slower rate that didn’t need to dump the TX data. In my use case, I am not reading any data except at the start and end of the routine but I will easily be sending more than the 64 byte RX buffer can store. I wonder what happens with TX when the RX buffer is full.

I had bit banged a 1-wire serial that worked at 114k but I was assuming a hardware UART would be better and/or more stable (and I didn’t notice the half duplex section of the firmware reference until I was done :blush:) My code didn’t use interrupts so it was only stable and tested on a scope at a single speed. In fact, it had to turn off interrupts for brief periods so the delays wouldn’t get messed up. I also liked that the hardware serial write() appears to be non-blocking as long as the buffer isn’t full; my hacked together routines blocked, although if I have to flush() after a write(), it’s basically being turned into a blocking call. An RX buffer is also nice, usually. :slight_smile: