NRF52 Interfacing sensor with serial through UART

[xhr0428]

I have a sensor with serial protocol of 7 bits data, even parity, 2 stop bits. I wanted to use uart library to interface with this sensor. But I couldn't find the settings to change data bits, even/odd parity or number of stop bits. Is it possible to do so with uart library? Or I have to write functions by myself to read bit by bit? Thanks

[RK]

No. If you check the UART specs you'll see it only supports 8 bit with one parity bit (or none). I believe that's even parity but I can't see where it says so. The old nRF51 series let you supply your own parity bit, which might have helped you on writes, but the nRF52 doesn't and it wouldn't help you on reads anyway.

So you'll have to do it another way.

[xhr0428]

Thanks. I wrote my own read functions with nrf_delay_us for timing. Is there a better way for that?

[RK]

doubt that's going to work very well, at least not when you have the softdevice running as it will be interrupted constantly and your timings will drift. Interrupts won't help you much in that case either as they too can get delayed. Unless you are using a slow baud rate and using one of the timers to make sure, even if you process one bit late (due to something interrupting you) you stay basically synchronized, bitbanging the uart isn't going to work too well.

If you're not using the softdevice, you'll probably get away with it.

[xhr0428]

Hi RK, I'm using softdevice and baud rate is 4800. I believe I begin to see the issue you mentioned. The sensor itself can output data every 60ms. I set up a timer with 200ms interval. It worked fine. But when I decreased the interval to 100ms, it stopped working randomly after some time. There was a very high chance when I connected/disconnected the device to my phone. I guess because of activities of softdevice, it lost a few bits and got stuck in some loop. Is there a better way to implement the whole thing?

[RK]

well it depends how you are doing your delays. If you're using nrf_delay then, no, you are just going to drift constantly. If you use a timer instead you can correct the interval you 'wait' for each bit. If you look at the softdevice spec you'll see what the max time it could interrupt for you might be, I think you'll find even 4800 baud won't bitbang reliably. I'd try interrupt driven at the highest priority available and see how you do.