Hi there,
I'm using a PCA10040 board, and the app that I am working on was originally built in SDK 11.0. I'm trying to send a stream of arbitrary bytes over USB using the UART. It's real-time data, but the throughput is only 1,200 bytes / second, which a 115,200 baud UART can handle easily.
I wrote a small loop which uses app_uart_put() to transmit the contents of a 20-byte buffer, one byte at a time. Most of the time, I receive 20 bytes on my desktop PC. But when my byte stream includes 0x0A (which could be interpreted as an ASCII LF, even though that is not how I'm using it), I get 21 bytes, and the 0x0A has been changed to 0x0D, 0x0A (CR, then LF).
I'm observing the data in hexadecimal mode on a Linux desktop computer using GTKTerm. GTKTerm has an "automatic CR LF" option, but I have turned it off. Unless there's a bug in GTKTerm, the CR is being added by the nRF52. I understand that adding a CR might be useful behavior for sending text to a Windows device, but I want my byte stream unchanged.
I will write a serial port program of my own to test whether GTKTerm is the problem, even though I doubt it. In the mean time, I'm looking through the Nordic app_uart_c source code to see whether I can find something that would intercept and change 0x0A, and/or flags that I might set to prevent such a change. I would appreciate any information you might have to help.
I actually wanted to use the C standard library function, fwrite(), and direct the bytes to stdout. I can get some data from the nRF52 using fwrite(), but eventually it stops transmitting! I'm not sure why. My code includes setbuf(stdout, NULL) after the UART initializes, so I think that I should not have to print an LF to flush the buffer.
Thanks for your input!
