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 >
