Multiple Zephyr Shell instances over UART

Background:

I seek to interact (human and/or additional MCU) with both UART peripherals (uart0 & uart1) in the easiest manner possible - issue commands, pass traffic, etc.

Options:

1 - Ideally, I would create 2 instances of the Zephyr shell - one instance for each UART.  Despite the shell being identified as being capable of having multiple instances, I've realized (in digging through code) that in the SDK v2.1.0, you can only have 1 instance of each shell type (serial, RTT, etc.).  Am I incorrect in this understanding?  Can you indeed have 2 shell instances - one for each UART on the nRF52840?

2 - If I can't have 2 shell instances (supposedly), 1 for each UART peripheral, I then tried to create 1 shell UART instance (for the 1st UART peripheral) and then enable the UART ASYNC API (for the 2nd UART peripheral).  However, it would appear to be that this is not possible either, per my research and subsequent post in this support thread (Async UART and shell module in Zephyr on nRF52480) just now.  I can leave the investigation and/or response to this scenario in the other support thread.  It doesn't look promising.

3 - Plan C is to use the shell for 1 UART and use the raw interrupt API for the other UART.  Painful, but do-able.

4 - Plan D is to ditch the shell altogether and use the UART ASYNC API for both UARTs.  This is perhaps slightly less painful than plan C, above, but the entire benefit of the shell is forfeit.

What am I missing?  What is the recommended way for a human and/or additional MCU to interact with the nRF52840 across both of its UART peripherals while still leveraging the best of Zephyr (Nordic SDK v2.1.0)?
- Can you have multiple UART shells?
- Can you have 1 shell and use the higher-level (DMA-enabled) UART ASYNC API?

Parents
  • Hi,

    I believe you are right there only being 1 UART shell, though you may also ask in the zephyr discord channel to see if any have an suggestion on the matter: https://discord.com/invite/Ck7jw53nU2 

    Though there are two other suggestions you may also consider:

    - How about letting only the third party MCU interface to the zephyr UART shell, but the third party MCU could also "relay" human to the zephyr UART shell through one of it's own UART ports. You could also potentially look at some external circuitry of the UART pins that ensured only either human or third party MCU physically interfaced the UART shell at any given time.

    - Another thought would be expanding to 2 UARTs by duplicating the shell_uart.c file in zephyr and changing some of the names, then adding a new devicetree entry for "zephyr_shell_uart2" and adding it to the dts. In theory should be doable.

    Best regards,
    Kenneth

Reply
  • Hi,

    I believe you are right there only being 1 UART shell, though you may also ask in the zephyr discord channel to see if any have an suggestion on the matter: https://discord.com/invite/Ck7jw53nU2 

    Though there are two other suggestions you may also consider:

    - How about letting only the third party MCU interface to the zephyr UART shell, but the third party MCU could also "relay" human to the zephyr UART shell through one of it's own UART ports. You could also potentially look at some external circuitry of the UART pins that ensured only either human or third party MCU physically interfaced the UART shell at any given time.

    - Another thought would be expanding to 2 UARTs by duplicating the shell_uart.c file in zephyr and changing some of the names, then adding a new devicetree entry for "zephyr_shell_uart2" and adding it to the dts. In theory should be doable.

    Best regards,
    Kenneth

Children
Related