Re: Setting connection parameters

[Christopher Collins]

Hi Tim,

Thanks for the report.  I am curious why ble_gap_update_params() did not
work with the Xperia.  One thing I should mention is that the central is
not obligated to update the connection when the peripheral asks it to.
It should have responded to the request, though.

On Tue, Aug 30, 2016 at 04:10:58PM +0100, Tim Hutt wrote:
[...]
> 3. Using a 5 second timeout, then ble_gap_update_params it works as
> expected! I couldn't find in the spec where it mentions the 5 seconds, but
> I guess it is needed in some way.

The five second recommendation is in Vol. 3, Part C, Appendix A, Table
A.1:

Timer name
TGAP(conn_pause_peripheral)

Value
5s

Description
Minimum time upon connection establishment before the peripheral
starts a connection update procedure

Requirement or Recommendation
Recommended value

Thanks,
Chris

Re: hal watchdog

[Mathew Calmer]

On August 30, 2016 at 12:28:50 PM, will sanfilippo 
(wi...@runtime.io) wrote:
Sounds reasonable. As I am sure you know, doing it through the sanity task 
sometimes is an issue getting the time right as you would then need to know the 
worst-case timing of all the tasks that could be running… but any way you cut 
it, you have to put some time limit on that… in past lives I have seen some 
pretty complicated ways to deal with this but this seems reasonable and if 
developers need something different they can implement it with this hal.



I would consider making the return value of init() be the time or some 
reference to the time that was actually set.  So, for example, if the user asks 
for 1 ticks, and the system can only support 2000, it could return 2000 
from init, after trying it’s best to support the request.

It could be done in powers of two or some other mechanism, but conceptually 
using that return value to explain what was actually set would be a nice 
interface.   If watchdog was not implemented on given hardware, default return 
could be negative (error) or 0, implying watchdog was not set (although 0 also 
implies success… so…).

Re: hal watchdog

[Sterling Hughes]

Hi,

2) When developers create the system and want a HW watchdog, what in 
the OS tickles the watchdog? Is that done by the sanity task or is it 
done by the OS in some other manner (os time tick, for example)? Or 
does the creator of the application need to provide for the tickle?


This would be done by sanity task. For folks who do not want to use 
sanity task would have to come up with

another mechanism.


Thanks

PS I am not sure if memory serves (and it rarely does!) but I think I 
have worked on older MCU’s whose maximum internal watchdog timeout 
was < 1 second. I dont know if current day MCU’s have this kind of 
limitation, but if they did, how would that be addressed? Or is it 
not a concern…


Argh, I had not considered such hardware. I think I would make the 
tickling happen then on 2 layers;
sub second stuff being internal to driver through a timer interrupt, 
and the slower tickling happening

through the watchdog API.



I was assuming that the internal watchdog would not be a sanity level 
watchdog, but rather be tickled within the OS context switch, and that 
if people wanted to tickle a watchdog through sanity, they could 
register a sanity function and do it in that context.


I assume we’ll want an OS level configuration/define that specifies 
how often to tickle the watchdog, and that define should be a power of 
2.


Sterling

Re: hal watchdog

[will sanfilippo]

Sounds reasonable. As I am sure you know, doing it through the sanity task 
sometimes is an issue getting the time right as you would then need to know the 
worst-case timing of all the tasks that could be running… but any way you cut 
it, you have to put some time limit on that… in past lives I have seen some 
pretty complicated ways to deal with this but this seems reasonable and if 
developers need something different they can implement it with this hal.

> On Aug 30, 2016, at 10:39 AM, marko kiiskila  wrote:
> 
> Hi Will,
> 
>> On Aug 29, 2016, at 4:53 PM, will sanfilippo  wrote:
>> 
>> I have some questions: 
>> 
>> 1) What happens if the internal watchdog does not allow for a long timeout?
> 
> I was thinking of just returning an error from init in that case, but maybe we
> need a routine that returns the max supported timeout. And make at least
> the watchdogs for the current MCUs support at least 30 seconds?
> 
>> 2) When developers create the system and want a HW watchdog, what in the OS 
>> tickles the watchdog? Is that done by the sanity task or is it done by the 
>> OS in some other manner (os time tick, for example)? Or does the creator of 
>> the application need to provide for the tickle?
> 
> This would be done by sanity task. For folks who do not want to use sanity 
> task would have to come up with
> another mechanism.
> 
>> Thanks
>> 
>> PS I am not sure if memory serves (and it rarely does!) but I think I have 
>> worked on older MCU’s whose maximum internal watchdog timeout was < 1 
>> second. I dont know if current day MCU’s have this kind of limitation, but 
>> if they did, how would that be addressed? Or is it not a concern…
> 
> Argh, I had not considered such hardware. I think I would make the tickling 
> happen then on 2 layers;
> sub second stuff being internal to driver through a timer interrupt, and the 
> slower tickling happening
> through the watchdog API.
> 
>>> On Aug 29, 2016, at 4:40 PM, marko kiiskila  wrote:
>>> 
>>> Hi,
>>> 
>>> I was going to add support for hardware watchdog(s).
>>> The API I was thinking would be pretty simple.
>>> 
>>> The first user for this would be the sanity task.
>>> 
>>> —8<---
>>> /*
>>> * Set the watchdog time to fire no sooner than 'expire_secs' seconds from 
>>> now.
>>> */
>>> int hal_watchdog_init(int expire_secs);
>>> 
>>> /*
>>> * Tickles the watchdog. Needs to be done before 'expire_secs' fires.
>>> */
>>> int hal_watchdog_tickle(void);
>>> 
>>> /*
>>> * Stops the watchdog.
>>> */
>>> int hal_watchdog_stop(void);
>>> 
>>> —8<———
>>> 
>>> Let me know if this doesn’t seem right.
>> 
>