nRF5 action!

[NeverDie]

@Toyman said in nRF5 Bluetooth action!:

Is it confirmed that the range and power consumption are on par with 328+24L01 combo?

Yes, it's better in both dimensions.

[d00616]

@Jokgi said in nRF5 Bluetooth action!:

@NeverDie Check out the new nRF52810. It is a stripped down version of the nRF52840.. Not as much memory and the peripherals are lower in count. But it has a Cortex M4 (Not F) and some of the targets are sensors, wearable, beacons, etc. On air compatible with nRF24L series and nRF52 series. Some limitations on BT 5.0 however.

Where are the long range BLE modes? I think long range BLE modes are one of the best features of the 840 series.

[Toyman]

@d00616 not supported by 52810

[NeverDie]

@Nca78
I just now posted a small breakout board for it: https://www.openhardware.io/view/483

[Toyman]

What's the proper way to deal with interrupts on nrf?
Many white areas:

• shall I use "smartsleep()" instead of usual arduino way of attaching interrupts? is it enough?
• what pins have hardware interrupts? any?
• what about the macro mentioned in d00016 readme?
• how to overcome nrf51 bug of 1ma power consumption (code-wise)? Otherwise I see no reason buying nrf51 modules if they consume 1ma while sleeping

I thoroughly read al the docs before asking!

[NeverDie]

@Toyman said in nRF5 Bluetooth action!:

What's the proper way to deal with interrupts on nrf?

Welcome to the bleeding edge. I'm only aware of the one way, which is how @d00616 does it in his example code above. It seems like this part of the code is still (?) under development. For instance, the HW supports multiple interrupts being active at the same time, whereas the current code seems to support at most one interrupt.

[Toyman]

@NeverDie wait, d00616 code is basically an extension of Sandeep's. The Sandeep's code (should) supports 8 interupts for nrf52 and 4 - for nrf51.
At least, that's what I conclude from here
Assuming it works, the next question is: can I put just ANY pin into attachinterrupt() function or not?

[NeverDie]

I made this adapter to aid with collecting serial debug output from the last two nRF5 breakout boards:
https://www.openhardware.io/view/484/IDC-10-pin-ARM-debug-adapter

[d00616]

@Toyman said in nRF5 Bluetooth action!:

What's the proper way to deal with interrupts on nrf?
Many white areas:

what pins have hardware interrupts? any?

There is an limit in the number of monitored pins but not which pins are monitored.

what about the macro mentioned in d00016 readme?

This macro is required on NRF52 to read back event registers in interrupts. This clears the cache.

how to overcome nrf51 bug of 1ma power consumption (code-wise)?
Otherwise I see no reason buying nrf51 modules if they consume 1ma while sleeping

This depends on the nRF51 chip release. The first available chip release has this type of bug. I prefer nRF52 because the chip is much more flexible with better radio characteristics.

The flexibility of nRF5 MCUs starts with the interrupt vector in RAM. This allows to add bootloaders without adding latency or you can replace interrupts which are predefined in the arduino-nrf5 software.

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

The first available chip release has this type of bug.

So, it's a hardware bug then? i.e. nothing can really be done about it for that chip release?

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

@d00616 said in nRF5 Bluetooth action!:

The first available chip release has this type of bug.

So, it's a hardware bug then? i.e. nothing can really be done about it for that chip release?

There is a second method via GPIO -> pin sense for interrupt detection. This method requires less power, but you have to detect which pin is changed in software. Simulating a pin change interrupt is more complicated as detecting high or low level. I have started to do some researches and tests, but in my opinion it's to much work to support these outdated chip variants.

[NeverDie]

Motivated by the above, I just now did some current tests on the nRF52832 and found that:

1. Going directly to an RTC sleep after powerup consumes 2.2ua.
2. Enabling DCDC doesn't increase that.
3. Nor does blinking an LED and then putting that pin into a disconnected state (D0) before sleep.

HOWEVER,
4. Activating Serial using Serial.begin(..) before sleep causes the current drain during sleep to rise to around 10.8ua. That was surprising to me, because this code in hwSleep(..) seems geared toward turning OFF serial prior to sleep:

  // Idle serial device
  NRF_UART0->TASKS_STOPRX = 1;
  NRF_UART0->TASKS_STOPTX = 1;
  NRF_UART0->TASKS_SUSPEND = 1;

So, I guess more is needed there?

[Toyman]

@d00616 thx. How do I use the macro? Just put in ISR?
Regarding the bug: if read the docs correctly, all nrf51 have the bug :-(

[Toyman]

@NeverDie do you use hwSleep() instead of sleep()?

[NeverDie]

@Toyman said in nRF5 Bluetooth action!:

@NeverDie do you use hwSleep() instead of sleep()?

Yes.

[NeverDie]

OK, I found that adding:

  NRF_UART0->ENABLE=0;  //disable UART0

brings the current consumption back down to 2.2ua during sleep. :)

[Toyman]

@NeverDie should it be placed just before hwSleep()?

[NeverDie]

@Toyman said in nRF5 Bluetooth action!:

@NeverDie should it be placed just before hwSleep()?

It's just a possible preliminary piece of the solution, because you'll need to renable UART0 after waking up from sleep. I haven't tested to see whether Serial.print(..) still works after re-enabling, or whether it needs to be re-initialized. Those are details yet to be sorted.

Or, maybe there's some other way of doing it. At this point, I'm just reporting my finding and tossing it out there as a tantalizing possibility.

[d00616]

@Toyman said in nRF5 Bluetooth action!:

@d00616 thx. How do I use the macro? Just put in ISR?

Yes. Give the event register as parameter.

Regarding the bug: if read the docs correctly, all nrf51 have the bug

This bug is listed as PAN#39 and fixed at the end of 2014.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

OK, I found that adding:
NRF_UART0->ENABLE=0; //disable UART0

brings the current consumption back down to 2.2ua during sleep.

Great work. Are you able to build an Pull Request fixing this? This Pull request should also be tested in the condition with a disabled serial port.

If you need help, please ask. I do the reviews.