Everything nRF52840

[nagelc]

@heinzv Yes. I'm using with Arduino IDE, but I connect a terminal program (TerraTerm) to the UART com port. You need to do more setup to get the serial out from NRF52832. The easiest way is to use the MyBoardNRF5 board type to select a pin to be TX. But that is a bit much for a blink sketch.
There is yet another usb driver for the Trace and Firmware Update ports. I forget how that is loaded (zadig I think), but you can safely ignore it.
Seems like your setup should just work uploading the sketch on your COM58.

For the GDB connection. There is a syntax difference for ports higher than 9. Try this. I had it in my notes, but haven't tried it since my ports are less than 9.

"target extended-remote \.\com58"

[heinzv]

@nagelc So everything works now with the BMP using the MyBoardNRF5. At least it supports the nRF52832 (if I'm lucky also the nRF52840) but I started with my barebone 832 modules.
So it upload the sketch and it does also reset and start.
I could also do the connection to the second serial port now with Terra Term and get the Serial.println. Cool.
The secret was, that I created another BMP for my blackpills (I did a couple of tweaks) and connect now the HW serial of the nRF52 to the BMP serial (UART2) and it forwards it via the USB of the BMP to the COM port.

The output looks now like yours when I do an upload:
WARNING: Spurious .ci folder in 'MySensors' library
WARNING: Spurious .mystools folder in 'MySensors' library
Build options changed, rebuilding all
Sketch uses 3720 bytes (0%) of program storage space. Maximum is 524288 bytes.
Remote debugging using \.\COM58
Target voltage: unknown
Available Targets:
No. Att Driver
1 Nordic nRF52
2 Nordic nRF52 Access Port
Attaching to Remote target
0x00000ae0 in ?? ()
Reading symbols from nRF52832_Blink.ino.elf...done.
Loading section .text, size 0xe88 lma 0x0
Loading section .ARM.exidx, size 0x8 lma 0xe88
Loading section .data, size 0x74 lma 0xe90
Start address 0x5f8, load size 3844
Transfer rate: 27 KB/sec, 640 bytes/write.
Temporary breakpoint 1 at 0xbc4: file D:\mcdev\arduino\portable\packages\sandeepmistry\hardware\nRF5\0.6.0\cores\nRF5\main.cpp, line 28.
Starting program: C:\Users\internet\AppData\Local\Temp\arduino_build_913185\nRF52832_Blink.ino.elf
Note: automatically using hardware breakpoints for read-only addresses.

Temporary breakpoint 1, main ()
at D:\mcdev\arduino\portable\packages\sandeepmistry\hardware\nRF5\0.6.0\cores\nRF5\main.cpp:28
28 {

Program complete!

Here is the picture of my BMP and the nRF module:

[heinzv]

My nRF52832 moduls with MySensors in nRF24 mode seem to work, I have to start another node acting als Gateway and see if they communicate and what distance can be reached in the nRF24 mode.

---

| / |_ / | ___ _ __ ___ ___ _ __ ___
| |/| | | | _ \ / _ \ _ \/ __|/ _ \| _/ __|
| | | | || || | / | | _ \ _ | | _
|| ||_, |/ ___|| ||/_/|| |/
|__/ 2.3.1-beta

24 MCO:BGN:INIT NODE,CP=RNNNN---,VER=2.3.1-beta
28 TSM:INIT
30 TSF:WUR:MS=0
31 TSM:INIT:TSP OK
33 TSM:FPAR
40 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2048 !TSM:FPAR:NO REPLY
2050 TSM:FPAR
2057 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
4064 !TSM:FPAR:NO REPLY
4066 TSM:FPAR
4073 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6081 !TSM:FPAR:NO REPLY
6083 TSM:FPAR
6090 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
8098 !TSM:FPAR:FAIL
8099 TSM:FAIL:CNT=1
8101 TSM:FAIL:DIS
8103 TSF:TDI:TPD
18105 TSM:FAIL:RE-INIT
18107 TSM:INIT
18108 TSM:INIT:TSP OK
18110 TSM:FPAR
18117 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
20125 !TSM:FPAR:NO REPLY
20127 TSM:FPAR
20134 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
22142 !TSM:FPAR:NO REPLY
22144 TSM:FPAR
22151 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
24159 !TSM:FPAR:NO REPLY
24161 TSM:FPAR
24168 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
26176 !TSM:FPAR:FAIL
26177 TSM:FAIL:CNT=2
26179 TSM:FAIL:DIS
26181 TSF:TDI:TPD

[NeverDie]

I built the micropython firmware for running on the nRF52840:

Here's the proof:

MicroPython v1.9.4-623-g34af10d2e on 2018-10-05; PCA10056 with NRF52840
Type "help()" for more information.
>>> 1+1
2
>>>

You can download it from here: https://forum.micropython.org/viewtopic.php?f=2&t=5348

[NeverDie]

So, the idea for doing OTA code updates is simple enough: you transmit each line of code and the target assembles it into a string. Then the target executes the string, which updates the code on the target. QED

Here's a notional example of what I mean:

>>> simpleCode="def j(x): return x**2"
>>> simpleCode
'def j(x): return x**2'
>>> exec(simpleCode)
>>> j(5)
25
>>>

You can use whatever radio transport you want, including Nordic's "proprietary radio" that we are all familiar with. There's no reliance on bluetooth or Nordic's DFU.

[heinzv]

@NeverDie great job! I'll definity try it on my holyiot bare modules, but I'm still fighting with the flashing via either the Nordic DK and/or ST-Link v2SO far I was not successfull (I only got it to run with Arduino IDE and BMP, but that is not usable in that case). DK seem not recognize my external nRF52840 and the ST-Link wants some address ranges so I'm trying to get it run with openocd, but that also returns errors. So I'm stuck and wasting many evenings/nights (with Google).

[NeverDie]

@heinzv Using the DK should be easy. If you want to post how you're wiring your connections to the target, maybe I could help you identify what mistake you are making. Or, if you prefer, you could post to the Nordic support forum, as they would be obligated to help since it's a Nordic product. Or, better yet, do both, because then you'll at least get the ball rolling with Nordic in case you have a defective DK (unlikely, but who knows).

[heinzv]

@NeverDie thanks for the hints/offer:
I have connected to the nRF52840 DK via the P20 connector
Here is the wiring setup

VDD---> VTG of P20 in DK board
SWDIO--> SWDIO of external board
SWDCLK-->SWDCLK of external Baord
GND DETECT--> GND of external Board
GND--> GND of external baord.

[NeverDie]

@heinzv How is it that you are powering the target?

[heinzv]

@neverdie I admit that I also powered the module via the DK because it takes less than 20mA. I used this connection description:
But I'll try to use a complete an external PS next time and see if it makes a difference.

[NeverDie]

@heinzv Nice picture. Hmmmm..... Seems like your wiring should work. Maybe try VDDnRF instead of VDD? I'm not sure what the difference is, but I think that may have been what I used most recently.

Are you dragging the hex file to the virtual drive on the PC to upload it to the target? If so, what exactly happens when you do? It should be as simple as that.

I'm using Windows 10. What about you? Not sure if the version of Windows has anything to do with it.

It appears that you are using the nRF52832 DK. Correct? What exactly is the target that you are trying to upload to?

One way or another we'll get this thing solved for you.

[heinzv]

@NeverDie thanks, appreciate your help as you are far ahead.
Here is my update: I have build 4 nRF52832 boards with the E73 EBYTE modules and two nRF52840 board with the tiny holyiot modules (see picts below).
It seems that by using the wiring shown in my last post, I can flash the 840 boards. I'll also try again one of the working 832 boards later (I'm in business trip the next few days).
But I have a couple of questions to you:
1.) I don't know how to identify which MCU will be flashed. I only see the J-Link adapter in Segger or the board with the Segger Serial in nRFgo Studio. How can I know, that I'm not flashing the DK onboard MCU? Where is this shown, indicated where the flashing will go? That is strange to me. Another example is my sel build Black Magic Probe: It shows which devices are connected to it and you can select one (if multiple are shown in a select - select target 1,2 ...)
2.) How can I make use of any bootloader (DFU, Serial, USB, OTA, ANT etc.) so that flashing with the DK is not always required? I have not found a good way so far to flash any useful bootloader (I have tried some of the examples). The onyl one which creates a serial devices is the example for the PCA100059 (the USB dongle) which shows a serial device: nRF52 SDFU USB (COM75). HOw to make use of that (I have tried all of the offered programmer als oin Arduino IDE but could not upload/flash my blink sketch)
3.) How to you flash the USB dongle beside using the nRFconnect which requires the compiled image?
Are you also soldering the SWD pins and use them with the Segger and the DK?
4.) When I flashed your micropython (or circuitpython?) for the 840 (my board). How to I connect and use it? My 840 boards have it's own USB port (see topic 2, which shows the nRF52 SDFU port when I flash the one bootloader). When I flash the MP, the ports are gone (how to connect via USB, Serial, Terminal etc.)?

I've also tried a couple of other things like a DFU bootloader with a S140 softdevice (as it was recommended by Nordic) but was not sucessful to combine them (the S140 was flashed, but then?)

I have many more questions but I hope we can sort out some of the 1-4. I hope I have described them so that you can follow my thoughts and questions

nrf52840 on DK

nRF52832 on BMP

[NeverDie]

@heinzv said in Everything nRF52840:

@NeverDie thanks, appreciate your help as you are far ahead.
Here is my update: I have build 4 nRF52832 boards with the E73 EBYTE modules and two nRF52840 board with the tiny holyiot modules (see picts below).
It seems that by using the wiring shown in my last post, I can flash the 840 boards. I'll also try again one of the working 832 boards later (I'm in business trip the next few days).
But I have a couple of questions to you:
1.) I don't know how to identify which MCU will be flashed. I only see the J-Link adapter in Segger or the board with the Segger Serial in nRFgo Studio. How can I know, that I'm not flashing the DK onboard MCU? Where is this shown, indicated where the flashing will go? That is strange to me. Another example is my sel build Black Magic Probe: It shows which devices are connected to it and you can select one (if multiple are shown in a select - select target 1,2 ...)

If it's wired corectly, then only the external board gets flashed.

2.) How can I make use of any bootloader (DFU, Serial, USB, OTA, ANT etc.) so that flashing with the DK is not always required? I have not found a good way so far to flash any useful bootloader (I have tried some of the examples). The onyl one which creates a serial devices is the example for the PCA100059 (the USB dongle) which shows a serial device: nRF52 SDFU USB (COM75). HOw to make use of that (I have tried all of the offered programmer als oin Arduino IDE but could not upload/flash my blink sketch)

I don't know.

3.) How to you flash the USB dongle beside using the nRFconnect which requires the compiled image?
Are you also soldering the SWD pins and use them with the Segger and the DK?

Yes.

4.) When I flashed your micropython (or circuitpython?) for the 840 (my board). How to I connect and use it? My 840 boards have it's own USB port (see topic 2, which shows the nRF52 SDFU port when I flash the one bootloader). When I flash the MP, the ports are gone (how to connect via USB, Serial, Terminal etc.)?

So far I've only flashed MP to the 832 and 840 DK's. In those instances, you can do serial IO over the USB connection using putty or similar terminal.

I've also tried a couple of other things like a DFU bootloader with a S140 softdevice (as it was recommended by Nordic) but was not sucessful to combine them (the S140 was flashed, but then?)

I have many more questions but I hope we can sort out some of the 1-4. I hope I have described them so that you can follow my thoughts and questions

[cascade]

Howdy y'all first off thanks @NeverDie for this thread, I spent a good time lurking at these NRF52 posts and learned and re-learned a few things here and there.

I've built an E73 NRF52832 PCB and successfully did a blink using Espruino and Adafruit's Bluefruit FW for Arduino and just noticed the $10 CAD E73-2G4M08S1C (NRF52840) back in-stock (as of October 8). I am in the process of designing a pcb board layout for it but in the meantime thought that the community might find the following useful if you plan on designing/using these modules:

1. E73-2G4M08S1C and other footprints in the same 'family' are readily available in Altium Designer format here: http://www.cdebyte.com/en/data-download.aspx?id=356&pid=202

2. Library.io allows you to convert '.pcblib' / altium files to an Eagle Library format, you just need to specify the Symbol and Package, from here you can convert to KiCad or similar I'd reckon but have not used KiCad enough to verify this. This saved me a lot of time.

In case someone was wondering: I've had no issues using the J-Link Edu Mini with the NRF52832, will update here when I get to the NRF52840.

Just starting my own NRF journey and thought to add this here in case someone is looking for E73 module specifics WRT NRF52832/NRF52840 .

[Redferne]

Big thanks to @sandeepmistry, @lpercifield, @jeremypoulter and all others contributing to the NRF Arduino development effort. I have borrowed a lot and forked off another project for adding support for the NRF52840 dongle (PCA10059). If you are using PlatformIO and have access to a NRF52840 you can take it for a spin here PCA10059. I have tested UART, TWIM, SPIM and the BLE Led toggle example works.

[NeverDie]

@redferne Thanks for your post. How are you liking PlatformIO? Does PlatformIO have full support, with all the extra pin names etc., for the nRF52840?

[Redferne]

@NeverDie I never liked the Arduino IDE, so I think PlatformIO is next logical step, it is very easy to get going and it opens up for advanced usage. Your own choice of editor, has great debugging capabilities with VSCode integration.

If you build the PCA10059 example I linked you should have GPIO (digital) access to all 47 pins. I've made it simple in the pca10059 variant so that D0 (0) is p0.00 -> D47 (47) is p1.15.

Some external pins on the dongle which I have tested:
Serial pins RX->P1.10, TX->P1.13
I2C, TWIM, Wire on pins CLK->P0.29, SDA->P0.31
SPI here MISO->P0.13, MOSI->P0.15, CLK->P0.17, CS->P0.22

[heinzv]

@redferne thanks for your effort spent to support nRF52840 for VS Code/Platform.io. I'll certaily give it a try. The good thing with platform.io is that it's easier to use/import existing arduino (ino) projects than in e.g. Segger Studio which only supports licensed J-Link flash/debug adapters.

Two questions:
1.) Does your "port" support also the 15.2 SDK features of the 840 (Softdevice S140, BLE 5.0 long range, ZigBee, Thread ...)
2.) What flash method is supprted/used or you're using? Just plug the USB dongle in and it can be uploaded?

Oh, a third question: If I use bare nrf840 Modules, what flash adapter/mode would you recommend or have you tested (I have the 840 DK board, a ST-Link v2 and a Balc Magic Probe adapter)?

[NeverDie]

@nc78 Earlier you had asked about vendors for the dongle. I found an alternative dongle that ships from China:
https://www.tindie.com/products/Zelin/nrf52840-micro-dev-kit-usb-dongle/
Price is very similar. I like it better than the Nordic dongle, because it exposes pins P0.06 and P0.08, which are used by the DK for UART communications.

[Redferne]

@heinzv

1. It does use the S140 v6.1.0 Softdevice, however I have only "ported"/test the most basic SDK 15.2 BLE feature of @sandeepmistry BLEPheriphal BLEPeripheral. The example shows as BLEService and Read/Writeable BLECharCharacteristic used to toggling the onboard LED. I was hoping we could get more developers involved and "port" the missing pieces, if there's interrest. My main focus was just to get something Arduino-like running using PlatformIO build system on the cheap (~$10) NRF52840 dongle.

2. I have tested Black Magic Probe (Bluepill) and JLink Mini on the PCA10059 with great success. It also possible to use the nrfutil to create a dfu.zip. The Nordic Open DFU Bootloader (which is pre-flashed on PCA10059) allows easy programming without soldering, just plug-in USB.

First get and install the nrfutil from here

1. Linux environment example, first build the PCA10059 example project:

pio run -e ble

1. Generate a dfu.zip including the softdevice:

nrfutil pkg generate --hw-version 52 --debug-mode --sd-req 0x00 --sd-id 0xAE --application .pioenvs/ble/userfirmware.hex --softdevice ~/.platformio/packages/framework-arduinonordicnrf5/cores/nRF5/SDK/components/softdevice/s140/hex/s140_nrf52_6.1.0_softdevice.hex dfu.zip

1. Plugin the PCA10059 dongle in a USB port. Make sure that the Bootloader is executing by checking the RED led, should be "breathing". Else press the reset button. Now flash the new firmware, here the dongle was enumerated as ACM3.

nrfutil dfu usb-serial --package dfu.zip --port /dev/ttyACM3

... and Bob's your uncle

[Nca78]

@neverdie said in Everything nRF52840:

@nc78 Earlier you had asked about vendors for the dongle. I found an alternative dongle that ships from China:
https://www.tindie.com/products/Zelin/nrf52840-micro-dev-kit-usb-dongle/
Price is very similar. I like it better than the Nordic dongle, because it exposes pins P0.06 and P0.08, which are used by the DK for UART communications.

Thank you for the link, it looks like an interesting dongle. But after asking for a quote at Arrows and giving up (looked like a big mess to get items shipped here as it cannot be included in another order and they would only deliver in US), I realized that they now have them in stock.
So I bought 2 at 9.5$ each + 12% discount on the website, so less than 8.5$ each and as I bought other items (including BT840 modules) I have free express shipping too. Cheapest price + free express shipping, I think it's called "having it both ways" So I'll be able to join the little nrf52840 club next week.

[heinzv]

@redferne wow and thanks again for your fast and complte/detailed answer.
I like especially

• that you already started to use/support softdevices S140 and thus BLE 5.0, thread and Zigbee is "potentially" available
• that you also succesfully use Black Magic Probe, as I also wante to use it because it works in Arduino IDE and Platform.io and it supports also an UART Port to communicate (I also use Blue/Blackpill BMP's)

It would be great if it would be posssible (if not already) to use BLE 5.0 with the long range feature (that is not supported by the older S132 or nRF52832). Zigbee would be also great. But not sure what of the features (for a reliable longer indoor range) would be usable from within the MySensors project (beside using the nRF52 as/with the nRF24 proticol).

[Uhrheber]

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

[mtiutiu]

This post is deleted!

[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.

[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.

[alowhum]

Very cool!

[NeverDie]

I have my first pass on nRF52840 OTA updates working with micropython. So, proof of concept works. 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

[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.

[alowhum]

You can now buy the USB-stick version for $22 on Aliexpress without shipping.

http://www.aliexpress.com/item/NRF52840-Dongle/32946349826.html

For $15 there is an expansion-less USB-stick:
http://www.aliexpress.com/item/Nordic-nRF52840-BLE-dongle-bluetooth-4-0-bluetooth-5-0-for-computer/32951812498.html

Little dev boards for $30:
http://www.aliexpress.com/item/NRF52840-Development-board-Bluetooth-5-Bluetooth-low-power-consumption/32935228197.html

And this interesting dev board for $33:
http://www.aliexpress.com/item/Nrf52840-development-board/32921005555.html

And a larger one with integrated ESP32 for $42:
http://www.aliexpress.com/item/Nrf52840-development-board-ESP32-development-board-Mini/32921001572.html

[Sergio Rius]

@NeverDie Thanks for your time and good work!
I was thinking on start fiddling with the nrf52, but after the reading I don't know if I would handle it.

[NeverDie]

I tried platformio and indeed it seems very nice. It supports the nRF52840.

[Sergio Rius]

Do you think this board could be used for a wifi gateway?
https://es.aliexpress.com/store/product/Nrf52840-development-board-ESP32-development-board-Mini/2956052_32921001572.html

[NeverDie]

@sergio-rius Assuming they're connected, I'd like to say yes, but I don't know how they're wired, so if that's all there is to go on... it's a cat in a bag.

[NeverDie]

For those who haven't yet tried it, platformio has an "arduino" mode where it can program an nRF52840 very much along the lines that you would an arduino. Since it supports the nRF52840, I'd say it's a natural upgrade from the Sandeep Mistry library, which you don't really need to use anymore if you don't want to (though maybe it's still relevant for mySensor's compatability). At least to me, platformio seems much easier to use and much less of a learning curve than Segger Embedded Systems, Eclipse, or MBed. For anyone used to Arduino, it will seem very familiar.

[NeverDie]

Has anyone been able to send a packet with a payload of greater than 85 bytes using an nRF52832/nRF52840? According to the datasheet, a 255 byte payload should be possible. Yet, even if I set MAXLEN to 255, the payload seems to be truncated at 85 bytes. So, I'm curious as to why I'm not able to get a larger payload transmitted, and thus I'm wondering whether anyone else here has succeeded at it.

Anyone?

[hugob]

Sorry for cross-posting.

I started with nRF52 a few days ago. I have the Nordic nRF52 SDK board (PCA10056) with a nRF52840 operational as a MySensors serial gateway together with Home Assistant on a RaspberryPI (with Hass.io). I am using the Arduino nRF5 and the sandeepmistry nRF5 board libraries.

Some issues:
- It looks like it only works in debug mode. But in debug mode, both debug messages and gateway messages appear on the usb port. Homes Assistant is not confused by the debug messages.
- Leds are not working.
- The programmer on the Arduino IDE is not working for me ("No J-Link" error, while there is a J-Link interface available), so I export a HEX fle form Arduino IDE and program the board with the nRFConnect tool from Nordic.

In order to solve the issues above, I installed the Segger environment. With the board you get a free license from Nordic and you can do some fancy debugging. I also looked at Keil but that is a no-go for me. With Segger, I can upload a simple Blink example from Nordic to the board an debug it. I am now struggling with importing the MySensors library sources in Segger. If someone did this before, please let me know (!). Once this is done, I can debug the code on the hardware. May be I could fix the issues, like non blinking leds, by inspecting the code and watch for configuration issues of the ports (the addressing of the ports seems to be OK). But being able to debug would be a big plus in future development.

Off course, once the gateway is working with blinking leds, I want to replace the development board with something cheaper from E-Bay et al. I want to give this one a try:
https://www.aliexpress.com/item/Nordic-nRF52840-module-Bluetooth-low-energy-long-range-500-meters-bluetooth-5-0-PCB-IPX-Antenna/32953759053.html
The plus of this board is that you can use an external 2.4 Ghz antenna. And it has the newest 52840. If you are creating a gateway, I suppose your budget will not depend on $3 price difference.

Once all that is done, I want to turn my Nordic Thingy (https://www.nordicsemi.com/eng/Products/Nordic-Thingy-52) into a MySensors device. Seems like doable. But someone has to do it.

[wassfila]

@neverdie Bluetooth and zigbee have different scopes and different business models. Zigbee is targeting automation networks such as devices that are permanently available and collecting in a server, while Bluetooth is only user centric in its pairing mechanism (it's funning those bluetooth devices that collect a certain amount of data locally for download with the user's phone, they are not scalable for big systems). Zigbee is evolving towards more structured networks capabilities and I predict that the Thread is sooner or later going to replace Zigbee without users loosing functional products as the alliance is already preparing a common zigbee and Thread top layer (dot dot) that would provide a smooth transition. Thread will provide a standardised routing between the sensors local network and the internet, and that is very competitive compared to any Bluetooth or zigbee solution where every one has to reinvent the wheel for a different way of mapping the local network to global, vendor specific or custom gateways would finally tend to disappear. Even if you do not want your sensor to be shared with the world, the smooth transition from low power wireless network to ethernet (and the raspr) is something I would apreciate. Now add to that the MQTT-SN that is designed for low power wireless networks, and you get an out of the box MQTT layer for your low power wireless sensor. I do not know, but if I would bet, I'd bet on that to gain interest in the future.
And by the way, I do not think that these fancy standards compete with MySesnors, because the SW that is simple and you know is 100 times more practicle to work with, port and adapt to corner cases than a huge stack such as BT or zigbee.

[NeverDie]

@wassfila Who knows?The nRF52 chips are multi-protocol, which I suppose is one way to hedge your bets. Thread is one of them.

[NeverDie]

As of today, uLisp now works on the nRF52840. I posted a repository and build instructions on github: https://github.com/rabbithat/uLisp_nRF52840 I have moved from uPython to uLisp to facilitate over-the-air code upates.

[NeverDie]

An interesting benchmark I just did on the nRF52840: I'm able to transmit (and receive) the entire Declaration of Indepdence (roughly 8KB of text) in under 35 milliseconds. So, with that as a reference, I expect OTA code updates can be fairly low power.

[Sergio Rius]

@neverdie On platformio, what do you use for programming? A black magic probe?

And about the 255 payload, have you looked for a wrong sized variable or type? If you want me to give it a go on visual studio+resharper just send me a sample. I still don't have a programmer and still haven't received my nrfs so I would only look for programming errors.

[NeverDie]

@sergio-rius

I use the nrf52840-DK as the programmer.

Regarding the 255 payload, I'm able to get it if I send static length payloads, so that's what I'm doing now. However, variable length acts very strangely in that the maximum length before truncation seems to vary depending upon what the actual payload content is. It's 100% repeatable for the same payload content, but changing the content generally leads to a different maximum length. So, I'm not sure what's up with that. It definitely shouldn't be that way.

[Sergio Rius]

@neverdie Does it have compression or checksum of the payload? I'm not used to that library, but it seems some processing is done. First try with plain repeating characters or numbers to discard encoding issues.

[alowhum]

@neverdie #240 Time to Say Goodbye to Arduino and Go On to Micropython/ Adafruit Circuitpython? – 15:27
— Andreas Spiess

[NeverDie]

@alowhum Thanks. Not sure if you saw this: https://forum.mysensors.org/topic/9889/anyone-here-tried-mercrisp-forth-for-programming-arm-cortex-m-i-e-blue-pill-nrf5-stm32-etc

Looks as though there will be a mecrisp-stellaris FORTH release for the nRF52840 within about a week, or maybe sooner. Because of its built-in optimizing compiler to native machine code, I'll probably settle on mecrisp-stellaris.

[alowhum]

Yes I saw it. Very hardcore.

[NeverDie]

You can now run mecrisp-stellaris FORTH on the nRF52840-DK: https://github.com/rabbithat/FORTH_NRF52840-DK

[rozpruwacz]

@NeverDie did You compared somehow the range of the nrf52840 dongle with other nrf52840/nrf52832/nrf51822 modules ? I'm asking because after first test it appears that the nrf52840 dongle has worse range than core51822 module using the same radio settings.

[NeverDie]

@rozpruwacz No, I hadn't noticed that. Do note though that you can increase the tx power on the nRF52840 dongle to 8db, whereas 4db is the max for the nRF51822.

[rozpruwacz]

@neverdie said in Everything nRF52840:

@rozpruwacz No, I hadn't noticed that. Do note though that you can increase the tx power on the nRF52840 dongle to 8db, whereas 4db is the max for the nRF51822.

Yes, but with the same settings I would expect at least the same range. I will keep testing.

[NeverDie]

@rozpruwacz The nRF52840 chip itself should be better because of its greater receive sensitivity.You didn't say exactly what you're comparing it against (aside from it being an nRF51822), but the dongle has a smallish antenna and a small ground plane. Usually those don't have as good a range. It's one of the trade-offs that comes with smaller size. It may also be more directional that what you're expecting, so try rotating it and see if that makes a difference.

[rozpruwacz]

@neverdie i'm comparing it with core51822 module which also has pcb antenna

[NeverDie]

I just now posted a much easier mecrisp-starellis FORTH for the nRF52840-DK: https://github.com/rabbithat/nRF52840-DK_easy/blob/master/README.md

On this one, all you need do is upload the hex file located in that repository and you're done.

[heinzv]

@neverdie interesting research and ideas. Have you tried to get BLE 5.0 running (the S140 SD) or using the nrf52840 radio features (best with long range) so that we can consider a sensor node/actor and does the sleep properly work? There are some basic features which have to work before switching the development/runtime env.

[NeverDie]

@heinzv

I haven't been working on that per se, but I do have a REPL over radio working: https://github.com/rabbithat/nRF52_wireless_Forth_REPL
which can also be used for doing OTA code updates.

[heinzv]

@NeverDie You doing a great research! I have quickly checked your REPL code and the radio lib.
So you have implemented a OSI Layer 3+4 (Transport Layer with IP/TCP Stack).
I'm wondering if/how this can be used to complay to BLE 5.0 (long range), ZigBee and Threads which the new Nordic SDK (Zigbee and Threads 2.0) offers? Are they also using the Softdevice S140 (6.1) libs or ...?
There is a ZigBee OTA update example provided by Nordic (but I have not yet enogh time to test it).
Currently, I'm still using MySensors and the NRF5_ESP (Nordic private) protocol which works. IT would be also interesting to use a more industry standard protocol like ZigBee or THREADS which seem to be also supported by OpenHAB.
I'll certainly do further investigations in this direction. I have tried to test it with Segger Embedded studio and also with IAR Studio for ARM (the second requires some newer 32Bit version libs from Nordic and an internat request for that was raised already). Segger works fine with the J-Link adapters.

[NeverDie]

@heinzv said in Everything nRF52840:

I'm wondering if/how this can be used to complay to BLE 5.0 (long range), ZigBee and Threads which the new Nordic SDK (Zigbee and Threads 2.0) offers? Are they also using the Softdevice S140 (6.1) libs or ...?

If you specifically want those protocols, then at present the Nordic SDK is the only existing library I know of that will get you them.

[NeverDie]

It appears that Fanstel is now selling the amplified nRF52840 modules:
https://www.fanstel.com/bt840f-nrf52840-ble-5-module-secure-iot-802154-thread-zigbee-1

[alowhum]

Wait, what? The nRF52840 can now act as a Zigbee device too??

So I could make Arduino projects that talk Zigbee?

[NeverDie]

@alowhum Well, 802.15.4 for sure. I already did it, as I reported earlier. Beyond that, there's no native on-chip support for Zigbee per se. Maybe they confused it with zigbee? https://www.electronicdesign.com/what-s-difference-between/what-s-difference-between-ieee-802154-and-zigbee-wireless

That said, someone could certainly write a zigbee on top of it. It's meant for stuff like that. I imagine Thread is already written on top of it.

Anyway, I suspect that the amplified nRF52840 modules will be as good as it gets for quite some time and will remain relevant for years to come. The long wait is finally over!

[NeverDie]

By the way, I now have the wireless FORTH REPL working on the same nRF52840-dongle as in the OP of this thread: https://github.com/rabbithat/nRF52840-Dongle_hex/blob/master/README.md

I can plug the dongle into any USB port to power it, and with the wireless REPL the experience is exactly the same as if I had a wired serial connection to the dongle. I can interact with the REPL, start programs, load code or updates, and/or debug--all wirelessly. If you want to try it, I have getting started instructions in the github repository.

[blademckain]

Someone know if exist a usb nRF52840-dongle (with external antenna ) to plug into a raspberry to scan nearby tag?

[alowhum]

@blademckain The Micro:bit comes close.

[nagelc]

The new Arduino Nano 33 BLE is going to use the nrf52840. It will be interesting to see how support for the nrf52840 evolves in the Arduino environment.

https://hackaday.com/2019/05/19/new-arduino-nano-line-rolls-out-in-four-flavors-at-maker-faire-bay-area/

[monte]

This post is deleted!

[alowhum]

@nagelc that's great news!!

[nagelc]

Arduino Nano 33 BLE code is coming out. It's going to be based on MBED. Here's a discussion on the Arcuino Blog:
https://blog.arduino.cc/2019/07/31/why-we-chose-to-build-the-arduino-nano-33-ble-core-on-mbed-os/

I think it is interesting that no one has updated Sandeep Mistry's code for the NRF52840. Since it has been so long, I'm guessing this is not an easy task.

[NeverDie]

@nagelc thanks for the update. Mbed has a lot of overhead to it, but anything is better than moving mountains alone.

[simbo]

Someone may get some reuse out of this. I've made a 3d printed prototyping rig for the NRF52840 DK board as part of my MySensors adventures....

https://www.thingiverse.com/thing:3836487

[monte]

@nagelc I think Sandeep Mistry is working on new arduino core, based on mbed. As you can see he is titled as "Senior Software Engineer at Arduino" here. So I guess Mysensors community would need to move to new core eventually, or to fork Sandeep's core and develop it alone. I would prefer the first choice.

[scalz]

@monte
I remember in first place they mentioned apache mynewt a while ago, but finally they are moving to mbed.. still nice to hear. I think this new arduino/mbed core has not everything yet for running MySensors, that needs some work on proprietary rf.., whereas there are other working cores. At least for short-mid term. There are so much nice things to improve or add on todolist.
Team knows about new mcus, new cores etc what's missing is time, resources vs real life and projects!

[monte]

@scalz With official support from arduino and massive amount of chinese clone boards and much more powerful hardware I think in a year new nano board can become a new standard. Not to mention that single board which already has everything to work with mysensors is something many people where looking for for years.
I understand the time constrains, and am always thankful for a dev's work for community's good

[scalz]

@monte sure would be nice, no need to argue on this, about a standard. (still not sure imho if 2.4g would be best choice). I'm wondering if adafruit will give up on all the work they made on their custom core too (I imagine they have no hurry, and wait to see if that'll be promising).
let's see what will happen. and perhaps next year there will be new better mcus again, almost sure

[Amine Alami]

@heinzv Sorry to cut-in with an unrelated comment, but can you tell me how or from where you got this nice schematic diagram? I am looking for one that has other cards such as Raspberry Pi and TI cards for an architectural diagram

Cheers

[heinzv]

@amine-alami what nice schematic diagram are you refering to? I'm looking at this thread very sporadically.

[NeverDie]

After waiting almost a year for the dust to clear, it seems that there are now roughly two leading platforms at the moment that either have or may get good software support:

1. The Adafruit nRF52840 feather: https://www.adafruit.com/product/4062
   which Adafruit either has or is making Arduino compatible.
2. Possibly the Arduino Nano 33 BLE: https://store.arduino.cc/usa/nano-33-ble
   and/or https://store.arduino.cc/usa/nano-33-ble-sense
   for which, ironically, Arduino has chosen to adopt using mbed as the core software techology.

In other words, it appears that Adafruit has become more Arduino than Arduino!

There are also some "particle" boards that are hybrids:
https://www.cnx-software.com/2018/02/14/particle-unveils-three-nrf52840-bluetooth-5-boards-argon-wifi-boron-lte-and-xenon-particle-mesh-technology/
I had thought these would necessarily be more expensive, but right now the Xenon board is selling at $15, which is almost half the price of either the Adafruit or the Arduino boards:
https://www.amazon.com/s?k=particle+xenon&i=electronics&ref=nb_sb_noss_1
Are the particles easy to program and perform OTA updates? I have no experience with them. They're pushing a subscription service if you have more than ten or so of them, so I suppose the true cost could be higher if you go "all in" on them. On the other hand, if you happen to want/need whatever their cloud service is, at least you'd be getting some kind of value for your subscription money. I suspect that, at the moment, it may be the easier to do OTA updates with particle than the first two, if only because it needs to be good if they are to justify their service fee. Their Photon board (which is a wi-fi only device) has gotten mostly favorable reviews on Amazon. On Photon the subscription fee doesn't kick in until you have more than 100 photons, which sounds a lot less confining the the 10+ units of Argon or Xenon. Unfortunately, it sounds as though it's not low power enough for battery powered nodes: https://www.youtube.com/watch?v=68N67ZVxTZ0 A 7.5ma deep sleep sounds stupidly high to me. What were they thinking?

In summary, the Adafruit nodes sound best to me at this point in time. The Arduino nodes might catch up with the adafruit if enough people buy/develop for them. Time will tell. Sadly, Particle may be DOA unless they have a trick up their sleeve that I don't know about.

[scalz]

I think adafruit core is nice, and they added freertos which is a nice touch too. So, in case, I can easily reuse some modules I wrote for esp32 projects (which is freertos based too, out of he box)

Good to know, it's not perfect, both cores, nrf5 adafruit or arduino-mbed, unfortunately miss some sdk files..

I like Adafruit core so far, but Segger IDE with full sdk support is very convenient, because spending time in arduino cores linking missing libs etc is such waste of time, vs coding fun features..

[NeverDie]

@scalz Yes, you raise a good point about Segger.

I'll try both the Adafruit and the Arduino versions and report back my impressions afterward.

[NeverDie]

I gave the Arduino Nano 33 BLE Sense a try just now. I'd say it's beginner friendly in the sense that you can simply plug it into USB and program it that way through the Arduino IDE: no getting confused or stuck burning the flash using an st-link or similar.

Blink compiles into a roughly 80KByte binary, and I presume most of that is overhead of the included mbed platform. This isn't really a problem though, because the nRF52840 has an abundance of flash--probably more than you'll ever need, even with mbed consuming part of it.

As for the sensors that are built onto the 33 BLE Sense, you need to load libraries for each one that you want to make use of, but it appears that those libraries are available.

I get the impression that Arduino has typecast the nRF52840 as primarily a bluetooth device. I see no mention of the radio's proprietary mode. That is perhaps unfortunate, because Bluetooth per se isn't easy, and proprietary mode is actually much easier.

On the other hand, maybe easier-to-use Bluetooth libraries will eventually arise. I guess time will tell.

[alowhum]

@NeverDie This is a bit of a side-question but to what degree could Arduino's Bluetooth support fulfill the role MySensors plays?

In theory it seems Bluetooth could be a useful smart home communications platform:

• Just like MySensors, Zigbee, Z-wave, it avoids using the IP stack, and generates a separate network for smart devices. This lowers risk to user's home network.
• Lower energy than WiFi. Lower energy than NRF24 too?
• The killer app: it's built into smartphones, tablets and Raspberry Pi's already. No need for an extra dongle.

What I don't know is

• To what extent Bluetooth has useful smart home profiles
• To what extent Arduino devices could present themselves as smart home devices using those profiles.
• To what extent older Bluetooth chips can work with newer device profiles (it would seem a software upgrade should be enough?)

Maybe this should be a separate post

[mfalkvidd]

@alowhum interesting idea. Maybe add low-power features to the list. Bt-le has some very nice low-power features, but will it be possible to use them in custom sketches?

[Nca78]

@alowhum hard to say if the best would be to get rid of the gateway and program adapter for bluetooth devices, or to make a bluetooth gateway between bluetooth network and mysensors serial protocol.
In both cases we could have some custom profiles for the types of sensors used by MySensors.

[NeverDie]

@alowhum Good questions. From a distance, Bluetooth seems near ubiquitous. Closer up, the capabilities seem governed by the available "profiles" baked into a particular implementation, and that's where the apparent ubiquity seems to fall apart. There are long range modes that 5.2 Bluetooth BLE can support, but which of the profiles implement them? Those would be the set of profiles worth considering. Of those profiles, which one would be the best fit? Maybe knowing that would be a step toward answering your questions.

https://www.bluetooth.com/blog/5-videos-that-prove-thelong-range-capabilitiesof-bluetooth/

[alowhum]

Here is the datasheet of the actual Bluetooth module on the Arduino 33 BLE (PDF):
https://www.u-blox.com/sites/default/files/NINA-B3_DataSheet_(UBX-17052099).pdf

Here is a list of Bluetooth profiles:
https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles

Mesh networking profile details (PDF):
https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=429634

I'm trying to figure out:

• Can these Arduino's even present themselves as a specific Bluetooth profile? E.g. as a bicycle cadence sensor, or a smart lamp, etc.
• Can these Arduino's be programmed via Bluetooth?

the Mesh profile would be interesting:

Mesh Profile Specification[10] allows for many-to-many communication over Bluetooth radio. It supports data encryption, message authentication and is meant for building efficient smart lighting systems and IoT networks.

Application layer for Bluetooth Mesh has been defined in a separate Mesh Model Specification.[11] As of release 1.0 lighting, sensors, time, scenes and generic devices has been defined. 

The Bluetooth module documentation says it has hardware support for mesh networking. Nothing else though.

The Bluetooth mesh networking spec only seems to support very basic things like lamps though. No advanced things like thermostats.

Other interesting things:

According to this blogpost, Arduino exposes the full MBED options.

Apparently you double-tap the reset button to be able to access the bootloader. Nothing about wireless upload of sketches via bluetooth though.

Here are some examples from Arduino on what you can make:
https://github.com/arduino-libraries/ArduinoBLE/tree/master/examples/Peripheral