Everything nRF52840

[NeverDie]

@uhrheber said in Everything nRF52840:

One interesting thing I stumbled upon:

https://github.com/insane-adding-machines/unicore-mx

UniCore-MX | Universal Core for ARM Cortex-M0/0+/3/4/7/X

Supports nRF51/52

I looked at the link, but I can't figure out what problem it's solving. What's the headline on that?

[heinzv]

@redferne I was trying to get your platform and board extention as wellas the BLE library added to platformio, but got stuck afetr many many hours and many attempts (too much to add all the problems in one post). I'm using platformio with Windows 10 (I guess you use it with Linux/Ubuntu and also with a couple of command line tools)

I was trying to install this two:
https://github.com/Redferne/arduino-nRF5
Redferne/arduino-BLEPeripheral

I was trying to build a couple of simple examples and also the

C:\users\internet.platformio\lib\BLEPeripheral\src\BLEBondStore.cpp:11:12: fatal error: nrf_soc.h: No such file or directory

and
C:\users\internet.platformio\lib\BLEPeripheral\src/BLEPeripheral.h:136:5: error: 'nRF52840' does not name a type; did you mean 'NRF52840'?

and all other following errors are probably the result of the above ones.

Any hints?

Another question: How to define/declare the usage of the S140 softdevice in the project?
Using the PlatformIO IDE, not the command line.

[NeverDie]

As pointed out by @reinhold, here's a handy tool for programming your nRF52840 dongle, and possibly other nRF52 projects too:

https://www.tindie.com/products/ElectronutLabs/pogoprog-model-c-pogo-pin-programmer-swd-2-pack/

I think I'd like it better if it could somehow latch itself to the board, though, so that I could also get debugging information hands free without having to continually press the tool up against the board.

[Redferne]

@heinzv I'm sorry if I was unclear. I have only updated and tested one example which is the PCA10059 It should build without errors, but you might need to specify build type as "ble" or "dongle" as per the readme.

To enable the NRF52840 support use these flags:

-DNRF52 -DNRF52840 -DNRF52840_XXAA

and if building with the BLE Peripheral library and Softdevice S140 add:

-DNRF52 -DNRF52840 -DNRF52840_XXAA -DNRF52_S140

[NeverDie]

I have basic radio code now working in micropython: https://github.com/rabbithat/micropython_nRF52840/blob/master/README.md

So, I'm inching closer toward being able to do OTA code updates. :smiley:

[alowhum]

@neverdie Does this also mean we're slightly closer to a MySensors implementation in MicroPython?

[NeverDie]

@alowhum said in Everything nRF52840:

@neverdie Does this also mean we're slightly closer to a MySensors implementation in MicroPython?

Theoretically. ;)

[NeverDie]

By the way, I have it now to where you can send long strings (up to 255 characters if so desired) in a single packet from one node to another using micropython: https://github.com/rabbithat/Micropython_nRF52840_send

So, it's starting to get useful. I expect OTA code updates should be within range fairly soon. Since it's all written in micropython, I'll be able OTA update even the radio code as well, which is slick. :sunglasses:

[alowhum]

Very cool!

[NeverDie]

I have my first pass on nRF52840 OTA updates working with micropython. So, proof of concept works. :smile: I feel I should improve the code a bit before posting it though. I should probably add a hash function like MD5 or SHA256 to make sure the transmitted update is valid before making it go live.

[monte]

@neverdie YAY for transport-agnostic mysensors-python-edition!

[Omemanti]

@neverdie would this also be usable for the nrf52832? (Not asking for an ETA here :))

[Wormhole]

Hi,

I've recently purchased a couple of the nrf52840 dongles and was searching web for ways to flash them and came across this post. I am a complete NOOB with this stuff, so I've found the information here really useful, so thanks to all who have contributed.

During my searches, I can across this; HOME SMART MESH (https://www.homesmartmesh.com/). It seems very similar to what MySensors is doing, but geared towards nrf5 hardware. Was wondering if you had seem this before, or had any thoughts on the project re: pros and cons?

[heinzv]

@wormhole I took a quick look at this HomeSmartMesh project and it's certainly interesting.
However, the MySensors project is more mature, has a large community, supports more MCU's and sensors and many HW projects are using/supporting it. It also supports nRF51 and nRF52 MCU's already to a certain extent (I guess using the internal nRF24 radio protocol and external RF chips like RFM69/95).
Beside that, it supports also a couple of home automations suite like FEHM, OpenHAB etc.
I'm currently on OpenHAB 2.3 using the MySensors Gateway for OpenHAB.
I think it would be rather a good idea, that we get the new nRF52840 features and RF protocols supported by MySensors (such as the BLE 5.0 with the long range feature).
We had already the discussions on IEEE 802.15.4 / Thread / Zigbee which are also great for home automation. The question was also, if we can/should include it in MySensors or are these competing technology stacks to MySensors.
I personally like the MySensors project, because it project a good development infrastructure with a lot of supported/preconfigures sensors which makes it quite easy to creates sensor nodes..
Now we are exploring how to best integrate and use the nRF52840 boards. NeverDie seem to be quite ahead of us and exploring also micropython option (not sure how far that fits into the MySensors concept :-)

[NeverDie]

I now have working OTA update code for micropython programs on the nRF52840. I posted it on github: https://github.com/rabbithat/NRF52840_MicroPython_OTA_Updates

:sunglasses:

[heinzv]

@neverdie You are a hero :-) Now the question is of course what comes next? Do you see any chance to get some of the findings implemented into the MySensors project? or will it be a completly new nRF52840 thread/story? Like using ZigBee or BLE 5.0 long range (remember the discussion we had with @scalz if it makes sense to use MySensors aor use a full standard stack like ZigBee or BLE 5.0).
What are your thoughts and plans? Best option to build sensor nodes/actors with nRF52840?

[NeverDie]

@heinzv said in Everything nRF52840:

@neverdie You are a hero :-) Now the question is of course what comes next? Do you see any chance to get some of the findings implemented into the MySensors project? or will it be a completly new nRF52840 thread/story? Like using ZigBee or BLE 5.0 long range (remember the discussion we had with @scalz if it makes sense to use MySensors aor use a full standard stack like ZigBee or BLE 5.0).
What are your thoughts and plans? Best option to build sensor nodes/actors with nRF52840?

Well, as the saying goes, Rome wasn't built in day. I think there's no doubt that MySensors could be built using MicroPython, but right now there is no Rome and there's barely even a camp site. It's all just green fields and a few scattered tents. Also, I am just one person, and this is still early days. My near-term plan is to improve the OTA code to make it faster and more efficient. Right now, perhaps ironically, maybe the only reason to prefer Micropython over C is the existence of this OTA code. If someone writes an OTA bootloader for the nRF52840 in C, maybe that reason goes away. I might have done that instead, but this seemed a shorter path to getting an OTA.

In the end, programming the nRF52840 is, at this stage, almost like writing micro code. In other words, it almost doesn't matter which language you pick (provided it has an OTA updater), because the focus ends up being the same: fiddling with the registers and programming the PPI in order to get the highest efficiency.

[heinzv]

@neverdie sure, I did not epect Rome to be built in one day by one person :-) I was just curiuos in which direction you're heading.
If the OTA feature is one of the key features, I was thinking of using a couple of information provided by Nordic such as as details on the OTA/flashing process of the nRF52 as well as the OTA DFU bootloader example provided as part of the 15.2 SDK.

OTA/Flash process
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk52.v0.9.0%2Fbledfu_architecture.html
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.tools%2Fdita%2Ftools%2FnRF_Connect%2FnRF_Connect_DFU.html

OTA/Flash sources in C/C++
Just a few thoughts (I have to investiage) if we could use the sequence from the bootloader examples and they used libs for receiving data/code and initialized the flash process using the provided libraries
nRF5_SDK_15.2.0\components\libraries\bootloader
here I see in the dfu sub-dir the required function to observer, receiver and flash code

There a multiple examples how the code is transfered: via USB/serial, BLE/Zigbee, ANT ... and I guess we could use also the nRF24 protocol. Also encryption functions are available in the samples (secure dfu bootloader).

We need to derive, what nee to be done on the sender side to start to set the target to dfu mode and initiate the code transfer. Maybe that is also a tricky task.

Do you see that this approach can work and could be added to own C/C++ sketches and thus also added the MySensors project (of coure we need to include and use the required nRF52 libs for dfu)?

[NeverDie]

I don't doubt that it can be done. The amount of effort? It could be a little or a lot. I just don't know.

[NeverDie]

By the way, I now have the micropython code in a state where it is more easily demoed: https://github.com/rabbithat/NRF52840_MicroPython_OTA_Updates

Rather than continuing to post here about it, I'll just make future updates there. So, if anyone here is interested in it, you may want to check the github repository from time to time. :spock-hand: