nRF5 action!

[NeverDie]

@rmtucker
How are you measuring how long it's sleeping?

[rmtucker]

@NeverDie said in nRF5 Bluetooth action!:

@rmtucker
How are you measuring how long it's sleeping?

Just using hwMillis() before and after sleep and subtracting one from the other.
It was just reading + 250ms until @d00616 commited some changes a few hours ago.

[rmtucker]

something wrong in here:-

// Calculate sleep time and prescaler
		if (ms<512000) {
			// prescaler 0, 30.517 μs resolution -> max 512 s sleep
			MY_HW_RTC->PRESCALER =  0;
			// Set compare register to 1/30.517 µs to garantee event triggering
			// A minimum of 2 ticks must be guaranteed
			// (1000/32768)<<12 == 125
			MY_HW_RTC->CC[0] = max((ms<<12 / 125), 2);
		} else {
			// 8 Hz -> max 582.542 hours sleep.
			MY_HW_RTC->PRESCALER = 4095;
			// Set compare register to 1/125ms
			// A minimum of 2 ticks must be guaranteed
			MY_HW_RTC->CC[0] = max((ms / 125), 2);
		}

[NeverDie]

@rmtucker said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

@rmtucker
How are you measuring how long it's sleeping?

Just using hwMillis() before and after sleep and subtracting one from the other.
It was just reading + 250ms until @d00616 commited some changes a few hours ago.

I thought so. The point being: doesn't millis stop when you're deep sleeping? Well, at least on an Arduino it does. Not sure what it does on the nRF5.

[rmtucker]

@NeverDie
No the nrf5 has a rtc.(Real time Counter)
It can even keep time while sleeping.(just found this out myself!).
That is a great leap forward on the arduino.

[rmtucker]

Try it just print the time out then put it to sleep for a minute then print the time out again.

[rmtucker]

The problem must be this line but i don't speak nrf5.:frowning:

			// (1000/32768)<<12 == 125
			MY_HW_RTC->CC[0] = max((ms<<12 / 125), 2);```

[rmtucker]

The only other thing it could be is the deletion of this line in the commit.

nrf5_rtc_event_triggered = false 

[rmtucker]

@d00616

MY_HW_RTC->CC[0] = max((ms<<12 / 125), 2);

Should be:-

MY_HW_RTC->CC[0] = max(((ms << 12) / 125), 2));

[rmtucker]

@d00616

Just checked and it now returns 10002 for a sleep(10000).
Much better after the above alteration.

[NeverDie]

Epilog: I made the changes so that just prior to taking a measurement the sense pin is hwPinMode'd to an input pin, and then immediately after the measurement I disconnect it. Seems to be working, and without the usurious power drain I was experiencing previously. :)

[rmtucker]

@NeverDie said in nRF5 Bluetooth action!:

Epilog: I made the changes so that just prior to taking a measurement the sense pin is hwPinMode'd to an input pin, and then immediately after the measurement I disconnect it. Seems to be working, and without the usurious power drain I was experiencing previously. :)

Good news
So what is the current usage now when sleeping?

[NeverDie]

@rmtucker said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

Epilog: I made the changes so that just prior to taking a measurement the sense pin is hwPinMode'd to an input pin, and then immediately after the measurement I disconnect it. Seems to be working, and without the usurious power drain I was experiencing previously. :)

Good news
So what is the current usage now when sleeping?

About 6ua on this particular Ebyte nRF52832. I'm pretty sure it would be higher on my other Ebyte nRF52832, though I haven't measured it again. Haven't tested any additional ones as of yet.

[mfalkvidd]

@rmtucker very nice work, thanks for locating the problem.

It occurs because 12/125 will be evaluated before the bit shift. http://en.cppreference.com/w/c/language/operator_precedence for details.

[d00616]

@rmtucker said in nRF5 Bluetooth action!:

MY_HW_RTC->CC[0] = max((ms<<12 / 125), 2);
Should be:-
MY_HW_RTC->CC[0] = max(((ms << 12) / 125), 2));

Thank you. This was the result of merging some commits. I haven't seen I reversed that change. I had tested the code before merging some commits into one.

Actually I check the result of sleep(511999) and sleep(512001). When it's finished I fix that in MySensors.

[d00616]

@scalz said in nRF5 Bluetooth action!:

@d00616 said in nRF5 Bluetooth action!:

Should I add a DISCONNECTED mode to hwPinMode()?

make sense to have it for input too.. i agree

What's the best name for this mode? DISCONNECTED or INPUT_DISCONNECTED. I prefer the first variant.

I have to play a little bit with the port modes. Maybe it saves some current when the serial port pins are put into the disconnected mode while sleeping.

[d00616]

@d00616 said in nRF5 Bluetooth action!:

Actually I check the result of sleep(511999) and sleep(512001). When it's finished I fix that in MySensors.

Is fixed in development branch.
https://github.com/mysensors/MySensors/pull/917

[scalz]

@d00616 said in nRF5 Bluetooth action!:

@scalz said in nRF5 Bluetooth action!:

@d00616 said in nRF5 Bluetooth action!:

Should I add a DISCONNECTED mode to hwPinMode()?

make sense to have it for input too.. i agree

What's the best name for this mode? DISCONNECTED or INPUT_DISCONNECTED. I prefer the first variant.

I have to play a little bit with the port modes. Maybe it saves some current when the serial port pins are put into the disconnected mode while sleeping.

agree too for the first one should be enough :simple_smile:
yes, for lower power consumption, better disconnect pins which are not needed.
it's the same for a simple 328p though (setting the right pin states).

[NeverDie]

As a follow-up to rmtucker's line of inquiry, what is currently the shortest deep sleep that's supported? Is it one millisecond, or something else?

[rmtucker]

@NeverDie
Theoretically it is 2 clock ticks at 32768khz so 0.000061035secs i think.
But how long it takes to go into sleep mode and come out of sleep mode i am not sure.
But of course the sleep function only allows millis.