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. Hope this helps, Nathan
