Dear NuttX developers,
I'm working on wiring up the CAN module for the Tiva/Stellaris chips
for NuttX (using the character device model for now since the
SocketCAN model still appears to be work-in-progress). I am looking at
implementing support for sending remote frames and receiving responses
wi
Hi Matt,
>
> I think the solution using timeout should be more appropriated.
>
> I don't remember using RTR and the test application doesn't use it.
> probably it was never exercised.
>
> Please submit a PR with your suggested modification.
>
> BR,
>
&
Hi Frank-Christian,
I don't know whether it's on anyone's to-do list, (I just joined this
mailing list a few weeks ago myself), but I "CAN" say that if you are
interested in writing your own driver it shouldn't be terribly
difficult (I'm working on a driver for the TI Tiva chips currently).
As you
Hi Peter,
I haven't worked with NuttX's SocketCAN implementation or STM32, but I
did write a "classic" char-device CAN driver for the Tiva MCUs. The
reason I wrote a char-device driver is because the char-device CAN
subsystem has ioctls for things like hardware message filtering and
the interface
On Fri, Jan 28, 2022 at 7:43 PM Michael Jung wrote:
> specific ioctl command implementation
Creating a kernel thread in an ioctl "lower-half" would probably cause
the file descriptors from the calling task to get copied. Might this
be another case of
https://github.com/apache/incubator-nuttx/iss
Hi everyone,
I was thinking about how to implement the software for my project
(control module for a Formula SAE car) and realized that the basic ADC
driver model is a bit inconvenient and creates a lot of extra overhead
in userspace threads when implementing advanced features. Some
features I thi
On Thu, Mar 17, 2022 at 2:41 AM Xiang Xiao wrote:
>
> We are working on this to provide multiple read/poll support. The basic
> idea is that:
>
>1. Upper half driver hold FIFO shared by all client
>2. Each client hold the offset into the share FIFO
>
> The benefit is that we don't need to
