app_uart_get() and app_uart_put()

[Jimmyh]

Hi,

I want to use the functions app_uart_get() and app_uart_put() to communicate between the computer and NRF52840.

But when I type a string on the computer, the app_uart_get() function doesn't seem to receive it.

I'm using Segger Embedded Studio, the function app_uart_PUT()  is the same. What should I do?

[Karl Ylvisaker]

Hello again, Jimmy

Thank you for your patience with this. The summer holiday season has begun here in Norway, and so the DevZone forum is operating at reduced capacity for the next couple of weeks.

Jimmyh said:

Finally, I found that communication became normal when I commented out the function NRF_LOG_DEFAULT_BACKENDS_INIT().

I don't know why. But when I comment it out, I won't be able to use printf () anymore.

Do you know why these two pieces of code conflict? And is it possible to use printf as well?

Well done on the debugging of this!
I took another look in your sdk_config.h file, and it seems that you have enabled both NRF_LOG_BACKEND_UART_ENABLED and NRF_LOG_BACKEND_RTT_ENABLED, which is likely causing troubles, since you are attempting to use the UART for both logging and app_uart.
My recommendation here would be to set NRF_LOG_BACKEND_UART_ENABLED 0, and leave NRF_LOG_BACKEND_RTT_ENABLED 1, so that you can see your NRF_LOG_* and prinft() statements in your RTT terminal(either the standalone Segger RTT Viewer desktop application or the SES Debug terminal).

Jimmyh said:

There are a lot of Settings in this project that I can't understand. But that's okay.

Jimmyh said:

that's what the tutorial video is all about. I didn't quite understand some of it,

Please do not hesitate to ask if there is anything unclear or that you do not understand - either here, or you could open another ticket if the issue diverges from your original issue - we're happy to help!

Best regards,
Karl

[Jimmyh]

Hi Karl,

There is another problem that bothers me about serial communication.

In the example, app_uart_get () and app_uart_put () both transfer data as a single byte. Every time a byte such as an "s" is received by NRF52840, an interrupt is generated.

But sometimes the DATA the PC sends is not just a byte, maybe a string of characters like "start".

I have an if statement in my code to determine if the received string is needed. So my problem is how to combine the bytes received by app_uart_get () into a character array.

I tried putting each byte received into a predefined character array in the interrupt of the app_uart_put () function. One problem with this is that I don't know if the data for the RX pin has been transferred, i.e. there is no flag to indicate when there is no data transfer for the RX pin. I don't know when to stop assigning to that predefined character array. Because if I don't stop, every time I receive the data, it's going to be in the same array. But I want to separate them one at a time.

If the description of my problem is not clear enough, please do not hesitate to point out my shortcomings.Thanks.

Jimmy

[Karl Ylvisaker]

Hello again, Jimmy

Jimmyh said:

There is another problem that bothers me about serial communication.

Does this mean that you previous issue has been resolved, and that you are now able to communicate through UART-BLE->BLE-UART back and forth between your devices as expected?

Jimmyh said:

But sometimes the DATA the PC sends is not just a byte, maybe a string of characters like "start".

There are certain byte values of the ASCII table that do not correspond to alphabetical characters directly, but instead corresponds to control characters / commands - please see the lower byte values.
You Serial Terminal on your PC might be sending these control characters 'behind the scenes', or for example at the end of a string to denote the end of the sending.

Jimmyh said:

I don't know when to stop assigning to that predefined character array. Because if I don't stop, every time I receive the data, it's going to be in the same array. But I want to separate them one at a time.

You could use a special character to terminate your string - i.e to indicate the end of the string, so that your device will shift to another buffer. C strings are terminated by the null character.
You can see that the unmodified application already does a similar thing by checking for the control characters "\n" or "\r" to see if the whole sending is received over UART before it starts sending it over BLE.

Best regards,
Karl