nRF5 action!

[Toyman]

Guys, remind me pls: is CR2450 enough for the nrf52 Ebyte module acting as a Mysensors node?
Is it capable to handle tx current spikes?
Energizer datasheet states 9ma as max curent pulse. Is it sufficient?

[Toyman]

@neverdie I've setup the bootloader for my BT project and I confirm its much easier than it looks.
Can it be used for MySensors? For BT, I create a hex file in Keil and then upload it via nrftoolbox app.
Can the same procedure be used with MySensors? OTA needs Softdevice and Softdevice is not compatible with MySensors

[scalz]

@toyman said in nRF5 action!:

Guys, remind me pls: is CR2450 enough for the nrf52 Ebyte module acting as a Mysensors node?
Is it capable to handle tx current spikes?
Energizer datasheet states 9ma as max curent pulse. Is it sufficient?

yes but you need some power buffer for the spikes. So put 100uF low leakage ceramic capa close to batt holder, and you could also add one more close to your nrf5 module.

Can the same procedure be used with MySensors? OTA needs Softdevice and Softdevice is not compatible with MySensors

You already have your answer I think ;)

[NeverDie]

@toyman said in nRF5 action!:

Can the same procedure be used with MySensors? OTA needs Softdevice and Softdevice is not compatible with MySensors

Ouch. :astonished: That does seem like a gotcha. :confounded: Thanks for pointing that out!

Let's enumerate the possible remedies: :thinking_face:

1. I guess theoretically the bootloader could use softdevice to handle uploads and then revert to MySensors afterward. After all, with these devices there's so much flash and memory that there's nothing which says the bootloader needs to be tiny. In that case your code would need to force a reboot, and the bootloader would need to wait a period of time to see if an OTA upload is being requested before continuing. But this is all theoretical, and I don't know enough to know whether that would be easy or difficult to make work. Far from elegant to be sure. Maybe there's a better solution than that? Admittedly, this looks like a rabbit hole I'd rather not go down.

2. Maybe (?) micropython is the the easier path out of this train wreck, assuming (?) it can assemble a string that it reads from OTA and then execute it (EVAL it) the way that. say, LISP, can. Then you could bypass softdevice entirely and use whatever radio communications you want. The relative ease of that might make it worth the added baggage of running an interpreter. Well, that might work for me, but for mysensors it would mean a major port to micropython, which, AFAIK, no one has yet done.

3. That leaves writing your own wireless bootloader, like I guess others here have done for mysensors and the atmega328p, but that doesn't sound trivial either.

4. Any other ideas?

I'm just thinking out loud here and above, but I'm admittedly now both stymied and flummoxed. Being wireless without the ability to do wireless updates is not good.

@scalz Does the TI platform have the same sort of issue, or does it handle OTA updates differently?

[NeverDie]

For instance, this buttonless approach stays in DFU mode for 30 seconds after a reset: https://thingtype.com/blog/dfu-ota-updating-an-nrf52-application-over-the-air/

I guess maybe that's the shortest path out of this dilemma.

[monte]

@neverdie but all those bootloaders rely on bluetooth (thus softdevice) for DFU, that means we need to write our custom bootloader which uses different transport.

[NeverDie]

@monte said in nRF5 action!:

@neverdie but all those bootloaders rely on bluetooth (thus softdevice) for DFU, that means we need to write our custom bootloader which uses different transport.

In a perfect world, yes. However, since that doesn't yet exist, the question is: what else, if anything, can be done today?

[Nca78]

@neverdie said in nRF5 action!:

In a perfect world, yes. However, since that doesn't yet exist, the question is: what else, if anything, can be done today?

Today is either use bluetooth/ant/thread (all need softdevice) or write your own OTA bootloader for legacy radio without softdevice.

[NeverDie]

Looks as though micropython does support the bluetooth stack for both nRF52832 and nRF52840: https://github.com/micropython/micropython/tree/master/ports/nrf

Micropython also runs on the nRF51, but apparently (judging from the BBC micro:bit), there's not also enough extra space to also support the bluetooth at the same time on the nr51.

[Uhrheber]

@neverdie Speaking of micropython: Adafruits fork of micropython (called circuitpython) now also supports the nRF52840. The also added the nRF52840 dongle as make target (pca10059). After compiling, you can use nRF Connect to flash the hex file to the dongle, via the stock USB DFU bootloader, so you don't need an extra programmer.

I like that dongle, it's cheap yet powerful, and it may be the smallest micropython-capable board with native USB. Native USB is nice, because in this case it has not only a serial REPL, but also a virtual drive with the code files, like the original pyboard.

[NeverDie]

After running through a gauntlet, I managed to get micropython running on the nRF52832-DK! I posted the firmware here: https://forum.micropython.org/viewtopic.php?f=2&t=5343&p=30756#p30756 to spare anyone else from running the same gauntlet. Just copy the firmware.hex file directly to the nRF52832-DK drive on your PC, and it will upload automatically to the DK and start running micropython. )

[Toyman]

@neverdie what are potential advantages of micropython?

[NeverDie]

@toyman OTA updates.

[Toyman]

@neverdie I am afraid it still relies on Softdevice

[monte]

@toyman no, if your code is in python. So the deal is "just" to port mysensors to python.

[NeverDie]

@toyman Micropython on the BBC micro:bit (which uses the nRF51822) has a Radio library that uses Nordic's proprietary radio modes and doesn't involve Bluetooth. I suppose the question is: what would be involved in getting it to run on the nRF52832 or the nRF52840. Seems like it would be substantially the same.

Faiing that, if I can directly manipulate the radio registers from miropython as I can from C, then it shouldn't be too hard to get at least minimal radio capability up and running from within micropython.

If I can get rudimentary radio communications working in micropython, then from there it should be easy to do OTA updates via REPL. I did some proof of concept to that effect on the micro:bit, but quickly ran out of memory--the micro:bit has only a total of 16K of RAM, so there's very little headroom to begin with. On the nRF52840, lack of RAM shouldn't be an issue.

[NeverDie]

@scalz hinted at it previously, but it looks like MyNewt OS might offer yet another way to do OTA updates. According to their posted information, it offers:

A open-source Bluetooth 5.0 stack (both Host & Controller), NimBLE, that completely replaces the proprietary SoftDevice on Nordic chipsets. (https://github.com/apache/mynewt-core/blob/master/README.md)

Apparentlly it runs on both the nRF52832 and the nRF52840.

[speechsupply]

@neverdie
1737 posts and counting
Spend hours reading this. Amazing journey so far.

[Uhrheber]

@neverdie There are three ways to manipulate registers directly from Micropython:

1. Use machine.mem16

2. Use the decorator @micropython_viper
   The Viper code emitter implements integer types and pointers, allowing to access memory and registers directly.

3. Use the decorator @micropython.asm_thumb
   Write your code in ARM assembler.

Problem: I don't know whether any of this is already implemented and works reliably in Micropython for nRF.

[Toyman]

@speechsupply this thread is golden. I was so empowered that was able to easily switch to nRF SDK and to start producing (semi) commercial BLE-ANT device