💬 MySensors NRF5 Platform
-
I've created a BME280 node along the lines of the NRF5 beginners guide I posted.
But something odd is happening. The node works great for about 8 hours.. and then it stops working.
I already changed the power supply, but the same thing happens.
Could it be a memory leak?
-
@nca78 I downloaded the latest update to VisualMicro last night and had mixed success. I can now pick the MyboardNRF5 boards, but run into a compile error where it cannot find the build directory. Have you tried it yet?
-
@neverdie said in 💬 MySensors NRF5 Platform:
@d00616 Will everything work the same on the nRF52840?
Has anyone tried it?Yes. At the moment, I have no time to finish my work on supporting the nrf52840. In my Repository https://github.com/d00616/ArduinoHwNRF5 you can find my last state. All 840 ports P0 (0-31) and P1 (62-64) should be usable as GPIO but there is no support using the P1 ports with any pin mapping component like UART, I2C....
The second change in my last commit is mcuboot. A bootloader compiled with Zephyr. Firmware can be upgraded OTA using MYSController with some enhancements (ask @tekka about the correct version). Firmware transmision works well but, at the moment my mcuboot port don't work. The memory layout between zephyr and arduino is different. The application cashes after start. I think it's a problem with different memory layout between Arduino and Zephyr.
For NRF52 MCUs the memory problem can be solved by moving the interrupt vector register to the IV location in the image and setting the SP register to the correct value. Maybe the starting code of ArduinoHwNRF5 is the correct position, so this mcuboot version can be used for Arduino and Zephyr Software.
If moving the SP to the correct position doesn't help, for NRF51 the Arduino linker scripts must be changed. I think there is only a small change required, but I have no idea about how to do this.
It's welcome if someone can finish this work.
-
@neverdie said in 💬 MySensors NRF5 Platform:
@d00616 Will everything work the same on the nRF52840?
Has anyone tried it?Yes. At the moment, I have no time to finish my work on supporting the nrf52840. In my Repository https://github.com/d00616/ArduinoHwNRF5 you can find my last state. All 840 ports P0 (0-31) and P1 (62-64) should be usable as GPIO but there is no support using the P1 ports with any pin mapping component like UART, I2C....
The second change in my last commit is mcuboot. A bootloader compiled with Zephyr. Firmware can be upgraded OTA using MYSController with some enhancements (ask @tekka about the correct version). Firmware transmision works well but, at the moment my mcuboot port don't work. The memory layout between zephyr and arduino is different. The application cashes after start. I think it's a problem with different memory layout between Arduino and Zephyr.
For NRF52 MCUs the memory problem can be solved by moving the interrupt vector register to the IV location in the image and setting the SP register to the correct value. Maybe the starting code of ArduinoHwNRF5 is the correct position, so this mcuboot version can be used for Arduino and Zephyr Software.
If moving the SP to the correct position doesn't help, for NRF51 the Arduino linker scripts must be changed. I think there is only a small change required, but I have no idea about how to do this.
It's welcome if someone can finish this work.
@d00616 Argh, that's a pity if the pin mapping doesn't yet work, because it means I won't be able to do the drop-in upgrades from the Fanstel nRF52832 to the Fanstel nRF52840 as I had hoped to do. It means I would have to re-do all the PCB's if I want to upgrade to nRF52840. :( I guess I would have to figure out some other way to remap the pins.
-
I have a couple of BT840s on order, also hoping for the easy upgrade. It looks like the pins have the same functionality as the BT832 except for pins 11, 12, and 13 (and 14 if you weren't using it for reset). I wonder why they did not just keep them all the same.
-
Sorry wrong wording. All P0 ports can be mapped. But to map P1 ports there is additional code required which does'n exists in the Arduino port.
-
If someone try to work on mcuboot compatibility. Maybe only the IV is the problem. For NRF52 the IV can be moved to the beginning of the image, but the nRF51 IV is in the mcuboot rage.
-
I have a couple of BT840s on order, also hoping for the easy upgrade. It looks like the pins have the same functionality as the BT832 except for pins 11, 12, and 13 (and 14 if you weren't using it for reset). I wonder why they did not just keep them all the same.
@nagelc According to the Fanstel documentation, "Except the 19 pins in solid black dots, BT840F and BT832F is hardware pin to pin compatible. " So, if I'm understanding correctly, it appears that the the castellated pins should be exactly the same, and those are the only ones I'm able to solder anyway.
This is quoting from their v1.1 datasheet, which is dated August, 2018: https://static1.squarespace.com/static/561459a2e4b0b39f5cefa12e/t/5b75e95daa4a99c02bbce364/1534454116506/BlueNor_BT840F_datasheets.pdf
-
@nagelc According to the Fanstel documentation, "Except the 19 pins in solid black dots, BT840F and BT832F is hardware pin to pin compatible. " So, if I'm understanding correctly, it appears that the the castellated pins should be exactly the same, and those are the only ones I'm able to solder anyway.
This is quoting from their v1.1 datasheet, which is dated August, 2018: https://static1.squarespace.com/static/561459a2e4b0b39f5cefa12e/t/5b75e95daa4a99c02bbce364/1534454116506/BlueNor_BT840F_datasheets.pdf
Oh, I see now. p18 is the reset pin on the nRF52840 now, not p21 as on the nRF52832. However, both share the same physical location on the Fanstel modules. OK, so in that case, I guess it only matters if you want to use the reset pin as an gpio pin instead. Likewise, the LED has the same physical pin location on the module, but it's pin 020 on the nRF52832 and pin p13 on the nRF52840.
Well, if we can just somehow manage to upload a simple blink sketch to the nRF52840 from the Arduino IDE, then I suppose I can live with wherever else is different. It's getting some kind of "hello world" compiled, uploaded, and running that's always the hardest part with these things. Once that's in place, one can chip away at the rest of it. i.e. it looks like I can re-use my same PCB's with the nRF52840 and just make some software changes to make it work. I'd still count that as good news. :)
-
@neverdie said in 💬 MySensors NRF5 Platform:
@d00616 Will everything work the same on the nRF52840?
Has anyone tried it?Yes. At the moment, I have no time to finish my work on supporting the nrf52840. In my Repository https://github.com/d00616/ArduinoHwNRF5 you can find my last state. All 840 ports P0 (0-31) and P1 (62-64) should be usable as GPIO but there is no support using the P1 ports with any pin mapping component like UART, I2C....
The second change in my last commit is mcuboot. A bootloader compiled with Zephyr. Firmware can be upgraded OTA using MYSController with some enhancements (ask @tekka about the correct version). Firmware transmision works well but, at the moment my mcuboot port don't work. The memory layout between zephyr and arduino is different. The application cashes after start. I think it's a problem with different memory layout between Arduino and Zephyr.
For NRF52 MCUs the memory problem can be solved by moving the interrupt vector register to the IV location in the image and setting the SP register to the correct value. Maybe the starting code of ArduinoHwNRF5 is the correct position, so this mcuboot version can be used for Arduino and Zephyr Software.
If moving the SP to the correct position doesn't help, for NRF51 the Arduino linker scripts must be changed. I think there is only a small change required, but I have no idea about how to do this.
It's welcome if someone can finish this work.
@d00616 I guess this is what you mean by Zephyr? http://docs.zephyrproject.org/boards/arm/nrf52840_pca10059/doc/nrf52840_pca10059.html?highlight=nrf52840
-
@d00616 I guess this is what you mean by Zephyr? http://docs.zephyrproject.org/boards/arm/nrf52840_pca10059/doc/nrf52840_pca10059.html?highlight=nrf52840
@neverdie said in 💬 MySensors NRF5 Platform:
@d00616 I guess this is what you mean by Zephyr? http://docs.zephyrproject.org/boards/arm/nrf52840_pca10059/doc/nrf52840_pca10059.html?highlight=nrf52840
With Zephyr, I mean the Zephyr OS. This board definition is part of a newer Zephyr Version, I had used to compile mcuboot. This was ~7 Month ago.
-
@NeverDie I think you might have no problem at getting blink working. On this pic, the nrf52840dk was running mysensors https://forum.mysensors.org/post/79460 (it was a simple counter test).
But sure nrf52840 is "new", and each new mcu always needs time to get all features working..+the maintenance..the more the merrier, not sure :smile: -
@NeverDie I think you might have no problem at getting blink working. On this pic, the nrf52840dk was running mysensors https://forum.mysensors.org/post/79460 (it was a simple counter test).
But sure nrf52840 is "new", and each new mcu always needs time to get all features working..+the maintenance..the more the merrier, not sure :smile:@scalz said in 💬 MySensors NRF5 Platform:
nrf52840dk
You're sure it was the nrf52840dk? I didn't think it had been released until fairly recently, whereas your post was 10 months ago. Maybe it was the pre-dk? I guess either way it would support your point. I just want to be sure you didn't mean the nrf52832dk?
I guess since the MCU seems to be the same (?), there's a good chance it may work.
-
@NeverDie yes. on the pic, pca10056 (so it's nrf52840), that's the only dk I have (nice dev board). it was using d00616 mysensors driver.
@scalz said in 💬 MySensors NRF5 Platform:
@NeverDie yes. on the pic, pca10056 (so it's nrf52840), that's the only dk I have (nice dev board). it was using d00616 mysensors driver.
That's great! Were you able to have it send/receive to/from nRF52832's as well?
-
@NeverDie on the pic there was multiple nrf52832 nodes, only the dk was 840, the gw had nrf24.
Atm, the nrf52840 arduino core is not finished, so the additional features 840 can provide (security, zigbee etc), won't be available soon for arduino+mysensors. And there is still work to do for getting all 832 features. I think for the moment 840 is maybe interesting for the additional range only, or if you don't have enough memory with a 832..
Sometimes I'm wondering what's the best?? focusing and getting a solid core/framework for a very few mcu, or handling lot of mcus :muscle: with unfinished cores (+lot of maintenance)?
But I agree with you, tech stuff is sexy (I'm not the last at testing lot of mcus though) ;) -
@NeverDie on the pic there was multiple nrf52832 nodes, only the dk was 840, the gw had nrf24.
Atm, the nrf52840 arduino core is not finished, so the additional features 840 can provide (security, zigbee etc), won't be available soon for arduino+mysensors. And there is still work to do for getting all 832 features. I think for the moment 840 is maybe interesting for the additional range only, or if you don't have enough memory with a 832..
Sometimes I'm wondering what's the best?? focusing and getting a solid core/framework for a very few mcu, or handling lot of mcus :muscle: with unfinished cores (+lot of maintenance)?
But I agree with you, tech stuff is sexy (I'm not the last at testing lot of mcus though) ;)@scalz I'm still wondering: was your 840 able to send and receive with the 832's?
In the near-term I'd settle for the additional range that the 840 has to offer. IIRC, it has a 4db higher Tx and a 4db better Rx than the 832. So, 840 to 840 should have an 8db better link budget, which is significant.
-
@NeverDie I think I tried once, but I'm not sure; so take it as 'nope' :) But all nrf were compatible as they were talking to gw..
I agree 840 should have more range. but that's just datasheet numbers, in 2.4ghz band, and still not 20dB. for a direct replacement, you win range sure. but good 832 design choices can work as good as bad 840 design choices.
I have a different strategy. and I already got 832s ic for 2€. Because bt840f has not really a nice price imho. for what ?? a mcu few passives, pcb antenna, and just a few IOs exposed to castellated pins (I have no time to debug when there is a bad solder point on bottom pads..).
bt840 is more affordable but you loose all the range.
Then, you can find module from chinese brands. price is ok too. but the same lower range. On my side I would prefer spend money on good sensors.
