her Collins wrote:
>
> I do think that approach makes more sense than implementing retries in
> the HAL. By the way, I did submit a PR for performing I2C retries in
> the HAL:
> https://github.com/apache/mynewt-core/pull/1373#issue-212250961
>
> I am happy to redo this a
On Thu, Aug 30, 2018 at 11:35:44AM -0700, Vipul Rahane wrote:
> Hey,
>
> I think that’s a really great idea. One thing I would add is that we
> definitely should honor timeouts in any of the retries. Also, a way to
> disable the retries should be a good idea. Probably making it a syscfg
> which
Sorry, just read Will’s comment.
Did not want to repeat it.
- Vipul
> On Aug 30, 2018, at 11:35 AM, Vipul Rahane wrote:
>
> Hey,
>
> I think that’s a really great idea. One thing I would add is that we
> definitely should honor timeouts in any of the retries. Also, a way to
> disable the
Hey,
I think that’s a really great idea. One thing I would add is that we definitely
should honor timeouts in any of the retries. Also, a way to disable the retries
should be a good idea. Probably making it a syscfg which when set to 0 does not
do any retries.
I am assuming the errors codes
On Thu, Aug 30, 2018 at 09:48:32AM -0700, will sanfilippo wrote:
> I think my only comment is tries vs retries. You always want to make
> at least one try so you would have to set that to 1 every time right?
> I like retries personally but that is just me. Mainly because you
> would never allow
On Thu, Aug 30, 2018 at 07:47:34PM +0300, marko kiiskila wrote:
> > On Aug 30, 2018, at 7:21 PM, Christopher Collins wrote:
> > [1] We should do the same for the other HAL APIs (i.e., non-I2C), but
> > that can come later.
>
> Not sure this makes sense for other ones, as i2c is the only one with
> On Aug 30, 2018, at 7:21 PM, Christopher Collins wrote:
>
> On Wed, Aug 29, 2018 at 10:06:37PM -0500, Greg Stein wrote:
>> On Wed, Aug 29, 2018 at 8:59 PM Christopher Collins
>> wrote:
>>
>>> Hello all,
>>>
>>> I noticed the HAL master I2C API does not include any retry logic. As
>>>
>
Retry is also good if a bus conflict is detected (on a multi-master bus).
> I can think of two ways to add I2C retries. Each of them requires
> changes:
>
> (1) Delegate the retry logic to the code calling into the HAL (e.g.,
> drivers).
> (2) Implement retry
e is simply not ready to receive data, then
> retrying seems like the appropriate solution.
>
> I can think of two ways to add I2C retries. Each of them requires
> changes:
>
> (1) Delegate the retry logic to the code calling into the HAL (e.g.,
> drivers).
>
are
being NACKed because the slave is simply not ready to receive data, then
retrying seems like the appropriate solution.
I can think of two ways to add I2C retries. Each of them requires
changes:
(1) Delegate the retry logic to the code calling into the HAL (e.g.,
drivers).
(2
10 matches
Mail list logo
