UART for GPS\GSM

[g.cutri]

Hello,

I'm writing a firmware for the nrf52840 with a GPS\GSM module connected via UART.

I would like to ask what would be the best library\approach to interact with this module considering that:

1) I need to continuously read from the UART (with as low CPU resources as possible) and receive a callback when the <CR> character is detected.

2) I need to send commands while reading is in progress

I have seen that there are many different libraries (UART\UARTE drivers, UART\UARTE nrfx drivers, Serial Port library, libUARTE, etc.) and I have read a lot of discussions, but all seems very confusing.

[Edvin]

Hello,

2)

So you need an event handler to take care of the incoming data, because you need to be able to send while you are reading.

1) 

I see.

Is the amount of incoming data always the same length, does it vary?

The reason I ask is because the libuarte library is one option. However, it introduces some delay unless you know the length of the incoming data. This is because it doesn't check the content of the incoming data, but it checks whether the buffer is full (which is why you would  need to know the length) or if a certain amount of time has passed since the last byte received, which would cause a timeout interrupt, assuming that the transmitter is done sending data.

You say that you need it to be very CPU resource effective. How often and how much data does the FPS module send? I suspect that it isn't really that fast, but that you just need to be able to do other things while reading the uart at the same time, is that correct?

Either way, I think that the UART that is used in the ble_app_uart example is suitable for your use case. It checks the incoming byte for <CR>, and triggers a BLE transfer only if the last character is "\r", "\n", or the buffer is full. Check out the uart_event_handle() in main.c and how it calls ble_nus_data_send() after checking for '\r' or '\n'.

Best regards,

Edvin

[g.cutri]

Hi Edvin and thank you for your reply.

To answer your question: the amount of coming data is not known a priori. The module may respond to one command or it may send an URC (Unsolicited Result Code) at any time. All I know is that every string ends with <CR>.

Your assumption is correct. I'm using FreeRTOS and the reading task shall not wait for incoming data.

The example you suggest is interesting but it seems that it doesn't use the DMA, at least for sending. Also, it uses the old app_uart module. Isn't the Serial Port Library a replacement for this module (as written in https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.0.0%2Flib_serial.html)?

I'm wondering if this is the best option for what I'm trying to do.

BR

[Edvin]

g.cutri said:

The example you suggest is interesting but it seems that it doesn't use the DMA

 That depends on the settings. It is the definition NRF_DRV_UART_USE_UARTE that decides whether DMA is used or not.

I usually use the app_uart library, because it is already set up in a widely used example.

 

g.cutri said:

Isn't the Serial Port Library a replacement for this module

 It appears to be (I have not seen the statement that you linked to before now). It has fallen out of the latest SDKs, but if you check in SDK16.0.0, there is an example in SDK\examples\peripheral\serial that uses the serial library. However, by default it is set up using a blocking read function (not an event handler), but it is possible to set up. However, I am not sure about the differences between this library and the app_uart library. Again, what I would do in your situation is to test the app_uart library (or the nrf_serial if you prefer), and check if you experience any issues. The libuarte doesn't seem to fit your requirements completely, since it would introduce a known delay if you don't know the size of the UART string a priori.

Best regards,

Edvin