ListenMode ISR hook

[karrots]

It would be nice to attach a function to the ListenMode ISR from user space. As it stands right now the userland code has no way of knowing if a WDT ISR or ListenMode ISR triggered the wake up.

[LowPowerLab]

Any suggestion how you'd like this implemented?

[karrots]

I guess there are two ways to go about this.

1. Introduce a function one can call to check if ListenMode initiated the wake-up.
2. Introduce a function to register a callback so the user can do what they will.

[rrobinet]

Was this issue not already solved by the kiwi version?
https://lowpowerlab.com/forum/index.php?topic=838.0
Robert

On 07 Jun 2016, at 04:01, Jonathan Karras <[email protected]mailto:[email protected]> wrote:

I guess there are two ways to go about this.

1. Introduce a function one can call to check if ListenMode initiated the wake-up.
2. Introduce a function to register a callback so the user can do what they will.

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/43#issuecomment-224142767, or mute the threadhttps://github.com/notifications/unsubscribe/ABL9zfi9NC2p318HKByuqD6qKG98ycKgks5qJND1gaJpZM4ImISx.

[LowPowerLab]

@rrobinet I can't find anything from kiwi.
@karrots I guess I would prefer a callback, something like this. Although if someone hooks a large function that is not appropriate to call from an ISR, any thoughts about that?

Where would you put the hook to be place in the listenModeInterruptHandler?

I think it would make sense to put this at the end of it. It should then be a minimal function that just sets a flag in user land so they know it woke from ListenMode. Does that sound reasonable?

[karrots]

Like @rrobinet said either need a way when the uC wakes to check if the radio did the waking. Or a call back like you referenced so the user can set their own variable or some such.

My personal need wouldn't need the call back to be called inside the ISR but it may need to be to keep from getting interrupted and losing state. Like you mention this can get dangerous for those not familiar with doing a minimal amount of items inside the ISR.

If you go the callback route it should be the very last thing called inside your handler it would seem.

[rrobinet]

I am not sure we are talking about the same problem, but I refer to a SPI interrupt issue while using an ethernet shield together with rfm69 transceiver

I am using a 'old' rfm library version (not the ATC one) patched with the solution proposed by kiwi which solves this interrupt conflict.

Robert

On 09 Jun 2016, at 01:07, Jonathan Karras <[email protected]mailto:[email protected]> wrote:

Like @rrobinethttps://github.com/rrobinet said either need a way when the uC wakes to check if the radio did the waking. Or a call back like you referenced so the user can set their own variable or some such.

My personal need wouldn't need the call back to be called inside the ISR but it may need to be to keep from getting interrupted and losing state. Like you mention this can get dangerous for those not familiar with doing a minimal amount of items inside the ISR.

If you go the callback route it should be the very last thing called inside your handler it would seem.

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/43#issuecomment-224757930, or mute the threadhttps://github.com/notifications/unsubscribe/ABL9zexgPi2Ciykol4Gvgg-MM_5VfVzzks5qJ0shgaJpZM4ImISx.

[karrots]

@rrobinet No conflicts here. Just no way to tell if ListenMode woke from sleep or some other signal on one of the two interrupt pins that can wake the uC from sleep. The RFM69 library already hooks the needed ISR for its own purposes.