Higher priority interrupts and nimble stack

[will sanfilippo <wi...@runtime.io>]

Jiacheng asked about disabling interrupts for a long time (600-700usecs) and whether it was OK; also that there was a high priority interrupt that can take 600-700 usecs. I (possibly) mistakenly answered; I was only thinking about disabling interrupts at task level and not considering a high priority interrupt that could interrupt the nimble stack during either a radio or timer isr.

I would have to take a closer look at the current code to see if the stack could handle a higher priority interrupt that interrupts either the cputime isr or the radio isr. I believe it can but it was not considered when the code was written so there may be catastrophic failures. Just wanted to make folks aware of this.

I also presume that folks thinks that the controller should be written in such a way that developers can have higher priority interrupts enabled than the radio/timer isrs? Of course, this could always interfere with radio timing and BLE events; the idea being that nothing catastrophic happens. This would not add a lot of code and should not add much time to existing interrupts.



 

Re: Higher priority interrupts and nimble stack

[WangJiacheng <ji...@icloud.com>]

Thanks Will,

My high interrupt is event driving and the time can not be predicted, it must be served because it is related to power supply. 

I’m trying to make the Nimble connections are not dropped when the high interrupt event is served. If I’m lucky there will be no Nimble and Mynewt events when my interrupt event is served, however, there always has a collision after several hours running based on  my initial test, since I observed Nimble connection drop.

The Nimble connection dropping returns error message like (I’m using bletiny to test)
------------------------------------------------------------------------------------------
2779222:connection updated; status=520 handle=1 our_ota_addr_type=0 our_ota_addr=01:02:03:04:05:06 our_id_addr_type=0 our_id_addr=01:02:03:04:05:06 peer_ota_addr_type=1 peer_ota_addr=50:f8:fb:78:ec:d9 peer_id_addr_type=1 peer_id_addr=50:f8:fb:78:ec:d9 conn_itvl=24 conn_latency=0 supervision_timeout=72 encrypted=1 authenticated=0 bonded=1
2779231:subscribe event; conn_handle=1 attr_handle=27 reason=2 prevn=0 curn=0 previ=1 curi=0
2779233:disconnect; reason=520 handle=1 our_ota_addr_type=0 our_ota_addr=01:02:03:04:05:06 our_id_addr_type=0 our_id_addr=01:02:03:04:05:06 peer_ota_addr_type=1 peer_ota_addr=50:f8:fb:78:ec:d9 peer_id_addr_type=1 peer_id_addr=50:f8:fb:78:ec:d9 conn_itvl=24 conn_latency=0 supervision_timeout=72 encrypted=1 authenticated=0 bonded=1
------------------------------------------------------------------------------------------

I’m think if it is possible that inside Nimble events queue, the cpu_time ISR and radio ISR have aware that there have some other ISRs so the resource is not always available, if this happen, return a message like “the resource is busying, please try again later.”. If this is possible, the existing Nimble connections will not be dropped. Or there is quick connections parameters update such that it is possible to skip several connection events, thus keep the connections still continue to keep in connection  during the high ISRs are served.

Any comments and suggestions are welcome.

Thanks,

Jiacheng




> 在 2017年1月27日，03:55，will sanfilippo <wi...@runtime.io> 写道：
> 
> Jiacheng asked about disabling interrupts for a long time (600-700usecs) and whether it was OK; also that there was a high priority interrupt that can take 600-700 usecs. I (possibly) mistakenly answered; I was only thinking about disabling interrupts at task level and not considering a high priority interrupt that could interrupt the nimble stack during either a radio or timer isr.
> 
> I would have to take a closer look at the current code to see if the stack could handle a higher priority interrupt that interrupts either the cputime isr or the radio isr. I believe it can but it was not considered when the code was written so there may be catastrophic failures. Just wanted to make folks aware of this.
> 
> I also presume that folks thinks that the controller should be written in such a way that developers can have higher priority interrupts enabled than the radio/timer isrs? Of course, this could always interfere with radio timing and BLE events; the idea being that nothing catastrophic happens. This would not add a lot of code and should not add much time to existing interrupts.
> 
> 
>