Hi Nathan,
On 8/10/23, Nathan Hartman wrote:
> On Thu, Aug 10, 2023 at 4:38 AM Tim Hardisty
> wrote:
>
>> I like your idea of IOCTLs - I will be revisiting this issue in the next
>> few weeks and will look to see what's involved in implementing this as it
>> "feels" right.
>>
>
> snip
>
> In
On Thu, Aug 10, 2023 at 4:38 AM Tim Hardisty
wrote:
> I like your idea of IOCTLs - I will be revisiting this issue in the next
> few weeks and will look to see what's involved in implementing this as it
> "feels" right.
>
snip
In trying to cover potential board faults, I have found that if
>
feels" right.
On 10/08/2023 09:04, David Sidrane wrote:
Tim,
Seehttps://github.com/apache/nuttx/issues/3927
David
-Original Message-
From: Alan C. Assis
Sent: Wednesday, August 9, 2023 3:47 PM
To:dev@nuttx.apache.org
Cc: Pavel Pisa
Subject: Re: CAN TX fail handling
Hi T
Tim,
See https://github.com/apache/nuttx/issues/3927
David
-Original Message-
From: Alan C. Assis
Sent: Wednesday, August 9, 2023 3:47 PM
To: dev@nuttx.apache.org
Cc: Pavel Pisa
Subject: Re: CAN TX fail handling
Hi Tim,
Agree! This behavior could be implemented in the driver
Hi Tim,
Agree! This behavior could be implemented in the driver, for example
using some elapsed time. But again, it needs to be analyzed careful to
avoid introduce sometime too specific for a user needs.
Currently the can_close() try to wait for the TX complete that could
never happen because
Thanks Alan,
I can see that a timeout/retry in detail would be hardware dependent.
But in the absence of "something," code can send a message, but have no
idea that it hasn't actually been sent, then try and close the "file"
and the thread will hang indefinitely. I think we need something
Hi Tim,
I think that the default behavior of CAN Controller is trying to send
indefinitely a message, some HW can define some retry limit.
Please take a look:
https://forum.pjrc.com/threads/67435-FlexCAN-Infinite-Endless-TX-Retries
So, I'm not sure if it will make sense to implement a CAN TX
I am now cracking on with the app for my custom board, and in parallel
writing a production board-test app.
In trying to cover potential board faults, I have found that if there's
something that prevents a CAN message reaching an endpoint/destination,
the CAN transmitter (of course, as I
