Hi Alan, OK. I'll have to tackle this after I have regular data frames working on the Tiva. Thinking about it more, the "right" answer is probably to support both methods for dealing with RTR frames...
Matt On Tue, Dec 8, 2020 at 6:44 AM Alan Carvalho de Assis <acas...@gmail.com> wrote: > > 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, > > Alan > > On 12/7/20, Matthew Trescott <matthewtresc...@gmail.com> wrote: > > 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 > > with the CANIOC_RTR ioctl. Reading through can.c, everything looks > > good except that it's not clear to me what happens if a response is > > never received. It looks like the thread just waits for the semaphore > > indefinitely in can_rtrread. Is this the correct interpretation? > > > > Being new to NuttX, I'm not exactly sure what to do about this if my > > assumption is correct. Here's my general idea: > > > > - Add a "struct timespec timeout" field to struct canioc_rtr_s > > - Change the can_takesem() to nxsem_timedwait(), using clock_gettime > > and clock_timespec_add to get the absolute timeout > > - If the semaphore wait time expires with no response, then the > > lower-half driver would get a callback via can_ops_s with the index of > > the RTR message number to disable. For my driver, that callback would > > free the mailbox used for the RTR message in the TX FIFO. > > - If the semaphore posts before the wait expires, then it means the > > CAN hardware acknowledged the received message and freed the mailbox. > > > > The other possibility would be to just not implement this ioctl and > > let the application perform the exchange asynchronously with the new > > CONFIG_CAN_USE_RTR option. The latter definitely seems like the more > > flexible option, but is there a consensus on the "right" way to do > > this? Thanks! > > > > Matt > >
