Thanks Halysson for the link:
https://www.iotforall.com/top-iot-boards-for-development-prototyping-you-need-to-know-in-2023
The irony: the board they used in the image is the Meadow F7 powered
by NuttX :-D
Case some one know this gentleman, please ping him.
BR,
Alan
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 under
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 tim
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 that
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 thi
On Wed, 9 Aug 2023 at 10:43, Brennan Ashton
wrote:
> On Tue, Aug 8, 2023, 5:22 PM Andrew Dennison >
> wrote:
>
> > Hi Nuttx Dev,
> >
> > We are negotiating with the authors of the linux device driver for the
> CTU
> > CAN FD IP core to it re-licenced from GPL to so the driver can then be
> > por
