Assistance with nRF52840 (Particle Boron) Support

[Sandman2001]

Current Situation

Currently in preliminary research to add support for Nordic Semiconductor's nRF52 Family. #140 references some hardware requirements (such as the esp32's dual LX6 cores). For reference, here is the MC that I am hoping to integrate Nordic's Product specification. My two goals with this request is to verify feasibility of this application on the nRF52 family & port application to particle's SDK. The boron does not have a radio chip installed on the board, will create a breakout board to connect module, which chip (sx12xx, cc1101, etc.) is arbitrary for this application.

Proposed Change

Why particle & this specific board?

• Boron's cellular support
• support for over the air flashing of devices. boards are miles apart, would spend 1/2 day re-flashing devices individually
• Particle's device health manager sends realtime updates for deployed devices
• the Boron is the established hardware for other projects, would like to integrate this application into others
• minimize addition of new hardware as change will have to be made for multiple systems
• Have all code run on one SoC instead of multiple communicating with each other (cost & complexity reduction)

Additional Context

Currently a junior developer looking to get my hands dirty in some projects involving new hardware integration. Any assistance will be a push in the right direction for this project.

[NorthernMan54]

For the rtl_433 portion of the code base, it should be straight forward, as it will run on almost any processor ( with enough ram to support it ). But the other half of the code base is was written to be run on top of the Arduino / ESP32 framework. So you should be able to replace the Arduino / ESP32 framework pieces with what ever framework the nRF52 ships with.

But that board doesn't appear to support wifi, so what would you do with the data ?

[NorthernMan54]

Also that board is pretty light on RAM, 1 MB flash and 256 kB RAM

I don't think it has enough guts to run this.

[Sandman2001]

"But that board doesn't appear to support wifi, so what would you do with the data ?"

• The board contains a cellular chip, current projects send data through a webhook using the "Particle.publish()" function, looking to move to tcp/ip or MQTT operations in future

"Also that board is pretty light on RAM, 1 MB flash and 256 kB RAM"

• if need be, much of the devices, some demodulation modes, etc. can be removed to optimize memory usage.
• if the ram is being consumed by signal processing, will run some testing to determining minimum sampling rate to obtain data from sensors

These are my initial thoughts. I would prefer to have this architecture due to implementation reasons. However, if you are confident that it will not work, it would be better to fail fast and move to a different approach rather than waste time trying to get this to implement.

[NorthernMan54]

Ram and flash are a concern, on the esp32 it was tight with 320k of ram, and the final builds in OMG were over 1mb of flash.

So it may work or may not…..no guaranteed due to resource constraints