Hi Nathan, On 8/10/23, Nathan Hartman <hartman.nat...@gmail.com> wrote: > On Thu, Aug 10, 2023 at 4:38 AM Tim Hardisty <t...@jti.uk.com.invalid> > 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 >> there's something that prevents a CAN message reaching an >> endpoint/destination, the CAN transmitter (of course, as I >> understand it) is continuously retrying the message send, meaning >> the test app hangs when you try and close the file once the test has >> been deemed to fail. That is "by design" in the higher (i.e. >> non-arch specific) can code as it waits for the TX FIFO/queue to empty >> until the close is allowed. >> >> What is the correct POSIX way to handle this error condition? >> >> > Sounds like in CAN we need the equivalent of tcflush() / tcdrain() as found > in termios. (Try looking up the man page for these functions on your system > or at online manpages.) In NuttX, at least for serial ports (i.e., UARTs), > these functions call IOCTLs which (if I remember correctly) are partly > implemented in the upper half driver (to clear the software buffer) and > partly passed to the lower half driver (to flush the hardware FIFO, if > applicable in the arch in question). > > I am not sure whether actual *termios* and its tc family of functions like > tcflush() / tcdrain() are a good fit for CAN. Maybe they are and you can > just adopt the same IOCTLs they use. But even if not, you can follow along > how these are implemented in NuttX and do something very similar. >
I think Can4Linux could be a good standard to follow, it was used on Linux before SocketCAN (and still an option there). https://en.wikipedia.org/wiki/Can4linux https://gitlab.com/hjoertel/can4linux BR, Alan
