Coverage decreased (-0.0%) to 93.14% when pulling dc9a9ad on PappaPeppar:newrtr into c1a77a0 on micropython:master.

I also thought about making normal send take an rtr parameter... but in that case the data argument is unused and so perhaps a little contrived. @PappaPeppar you have experience using this CAN class I assume, so you're in the best position to decide if it should be 1 send method for both normal and rtr, of if they should be separate methods as you originally had.

I have changed my mind about this several times for the same reason. But I think this way is reasonable, it saves some flash and the maintenance might be a bit easier since the code in both functions are very similar.

Merged in e3cd154.

A think making send handle RTR frames is the right thing to do. An RTR frame is exactly the same as a normal data frame, except for the single RTR bit, so it should use the same method. In fact, the standard allows you to put a non-zero value in the DLC entry of an RTR frame (even though the data payload does not exist) so that makes the data parameter relevant.