Suggestion: Nordic MCU without the radio

This is not a support request, but merely a suggestion to the company. I need a host MCU for my project which will use an nRF52-based pre-approved module. I would like to use a second nRF52 as host MCU with the radio disabled for the following reasons:

  • Can use same VS Code toolchain for both the module and host MCU
  • Familiarity with nRF52 product family can be applied to both module and host MCU development
  • Can re-use the same code for serial communications between module and host MCU

I was considering the nRF52832 for my host MCU, but it is severely lacking in UART peripherals: it only has one!

A Cortex-M4F MCU from a competitor that costs about the same has way more peripherals available for the same pin count. This is not surprising, as this competing product does not include a radio taking up silicon real estate.

So I'm thinking: wouldn't it be nice if Nordic had a Cortex-based MCU without the radio?

Parents Reply Children
  • UART is not a good choice for the MCU-to-MCU communication since its slow and you cannot really shut down the HF clock unless you use more pins.

    MCU-to-MCU speed is not a problem for my application, but being able to shut down the HF clock is not something I had considered. Thanks for the suggestion.

    I still need a UART to communicate with an external device, plus I would like to have a spare dedicated UART for debugging purposes.

    There are NRF52x and NRF53X chips with >1 UART(E) available.

    I'm now looking at the nRF52833 as a possibility, but the easier-to-solder QFN40 variant doesn't have enough spare GPIOs. The QFN48 variant of the nRF52840 doesn't have the USB device peripheral that I also need. I'm considering the use of I2C I/O expanders, which may help in PCB routing.

    Note that its usually cheaper to use a bigger MCU like NRF53x instead of 2 smaller ones.

    If it were purely just BOM costs, then yes I would agree with you. But I need to use a pre-approved RF module to reduce certification risk/cost, and such a module won't provide me with enough I/O to implement my application.

    I'm not stuck; I can go with a competitor's MCU for the host MCU. It's just it would have been nice to the use same toolchains for both MCUs.

  • One advantage of using UART for the MCU-to-MCU communication is that it's easier to test the slave MCU using a PC. In my case, I don't need high throughput. My application is a kind of "smart" remote control.

Related