nRF5 action!

[NeverDie]

@rmtucker said in nRF5 Bluetooth action!:

if you wanted it adding to the code?

Definitely!

[scalz]

for unused pins, it should be floating, not pullup. set the pin register you need to 0x02.
Something like that
NRF_GPIO->PIN_CNF[ulPin] = 0x02;
that will put pin in same state like it's on reset. Everything disabled/default, floating, with disconnect bit set.
(see datasheet gpio).

@d00616 said in nRF5 Bluetooth action!:

Should I add a DISCONNECTED mode to hwPinMode()?

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

[NeverDie]

Maybe add:
OUTPUT_D0D1 -> Disconnected 0, Disconnected 1
or similar to your list as another easy way to effectuate the disconnect?

[NeverDie]

It finally makes sense now as to why there were all those "disconnected" choices among the various OUTPUT options. In my case, for controlling whether the solar panel is connected or disconnected, choosing OUTPUT_S0D1 works perfectly. :)

So, I suppose another way to disconnect an input pin would be to redefine it as an OUTPUT pin with a disconnect state, and then immediately put it into the disconnected state.

[rmtucker]

@d00616 said in nRF5 Bluetooth action!:

@rmtucker said in nRF5 Bluetooth action!:

Yes being able to change the prescaler dynamically would help a great deal as 125ms / 582.542 hours is not really useful for most applications with a 250ms overrun.

The sleep() function is now more precise for sleeping <512s:

https://github.com/mysensors/MySensors/pull/909

The PR is waiting for merge.

Hmm just tried the latest commit and it is giving me 306ms for sleep(10000).
Something not quite right.

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