• State Not Answered
  • Replies 14 replies
  • Subscribers 69 subscribers
  • Views 530 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 329572
Options

SDConnect on nRF5340 : using UARTE with unknown rx length

BrianW

I am struggling with the same requirement as this ticket :  RE: NRFX UART RX CONTINUOUS RECEIVE where RX LEN is unknown 

ie receive from a UARTE without knowing in advance how many rx bytes to expect. This is typical for exchanging AT type commands on a UART with another system...the receiver doesn't know how long the command being sent is going to be. In my previous nRF51/nRF52 projects, I just use UART ISR to get each byte, add to my fifo buffer, and detect LF/CR to know when I got a complete line...but this was before SDKConnect and not using UARTE.

Some questions:

 - Using an nRF5340, its seems my only option is to use SDKConnect with Zephyr, yes? No more SoftDevice builds?

- do I understand correctly that the nrf5340 does NOT support basic UART, only UARTE? Only EasyDMA operation is possible (in the same way it doesn't seem to support TWI, only TWIM)

- I have multiple UARTs to service - but if as per the final reply in the ticket above I have to use 2 timers per channel (one to count bytes received, one to do the 'idle line' timeout) it seems I won't have enough timers?

what is the correct way to handle a UART on the nrf5340 for this use case?

Thanks

Brian

btw, I did look at the tutorials, but they are very basic (and use the zephyr driver which uses the same timer mechanism) so weren't much help... But if there is a good sample that is useable for a real application Id be very happy...

Parents Reply
  • 0 in reply to Vidar Berg

    Thanks for the info.

    Looking then at the Zephyr system uart driver implementation  (as per the link):

    - can I use it in  'interrupt driven API' mode on an nRF5340?

    - is there a code example/sample of an application that uses this mode?

    - in this mode, how many UART devices can I open like this simultaneously? (ie does each instance use a resource like a TIMER/PPI to do its byte counting?)

    - how (non)efficient is this mode compared to 'asynchronous API' mode? (in terms of CPU overhead at a specific baud rate when the data is arriving at that rate (ie no idle periods)

    thanks

    Brian

Children
  • 0 in reply to BrianW

    Hi Brian,

    Yes, you can use the interrupt-driven API on the nRF53. Usage of this API is demonstrated by the UART echo sample (zephyr/samples/drivers/uart/echo_bot/). You can enable all UART instances with this driver as long as you make sure to not enable other peripherals which share ID with your UARTE instances (Peripherals with shared ID).

    Peripherals sharing ID with UARTE2

    https://docs.nordicsemi.com/bundle/ps_nrf5340/page/chapters/memory/appmem.html#ariaid-title3

    BrianW said:
    how (non)efficient is this mode compared to 'asynchronous API' mode? (in terms of CPU overhead at a specific baud rate when the data is arriving at that rate (ie no idle periods)

    There is some more overhead since it uses smaller DMA buffers, but it's usually not notiecable as long as you use hardware flow control. Without hardware flow control, you will may need to use the async API to acheive reliable reception.

    Best regards,

    Vidar

  • 0 in reply to Vidar Berg

    I was not planning to use hardward flow control : do you have an idea at what baud rate it would be neccessary (using the interrupt-driven api)?

    On the 'peripheral shared id' question :

    - the QSPI peripheral for the flash is independant of SPIs 0-4, yes?

    - when using the wifi nRF7002 chip, does this use the SPI peripheral on the NET processor? (and hence does not use up one of the peripherals on the APP processor...)

    thanks

  • 0 in reply to BrianW

    The QSPI is completely indepentent and does not share peripheral ID with any of the other peripherals

    BrianW said:

    I was not planning to use hardward flow control : do you have an idea at what baud rate it would be neccessary (using the interrupt-driven api)?

    Unfortunately, I don't think you will be able to achieve reliable reception with 3 UART instances running concurrently when you don't have HWFC. The async API mitigates this problem as it can work with larger DMA buffers and double-buffering. 

  • 0 in reply to Vidar Berg

    The QSPI is completely indepentent and does not share peripheral ID with any of the other peripherals

    Ok, thanks. 

    Vidar Berg said:
    Unfortunately, I don't think you will be able to achieve reliable reception with 3 UART instances running concurrently when you don't have HWFC. The async API mitigates this problem as it can work with larger DMA buffers and double-buffering. 

    Ok... 

    Is there an api call (zephyr or nrfx-uarte) that allows the application to make the easydma switch to the 2nd buffer without aborting it? This would at least let me check for received data before the buffer is full, without potentially stopping the uarte in the middle of a character....

    BrianW said:
    - when using the wifi nRF7002 chip, does this use the SPI peripheral on the NET processor? (and hence does not use up one of the peripherals on the APP processor...)

    Any guidance on this one? I haven't started on the wifi operation yet (we are just at PCB schema and component selection...)

  • 0 in reply to BrianW

    I don't see the benefit of using the interrupt-driven API over the async API. A third option is to use the nRFX UARTE driver directly if the zephyr drivers don't meet your requirements.

    BrianW said:
    Any guidance on this one? I haven't started on the wifi operation yet (we are just at PCB schema and component selection...)

    The Wifi stack runs on the application core, and there are specific pins which are dedicated to the QSPI, see https://docs.nordicsemi.com/bundle/ps_nrf5340/page/qspi.html#ariaid-title2 

Related