If that third CanBus is FD capable, why not keep just that one and drop the others if needed, so that other more popular features like PWM or analog input would not have to be sacrificed.
Oh, if only it were that easy. If we axe CAN1 or CAN2 signals, we also lose other really important must-have features.
For CAN1, we get it in 2 places - one shares with SPI & 2 PWM - the other shares with 2 of the analog pins and 2 PWM, and also MCLK for the main I2S. We can't sacrifice the main SPI port, nor MCLK for the main I2S.
For CAN2, the pins share with Serial1, 2 PWM, and 2 XBAR access pins. This could be abandoned, but then we'd have only 7 serial ports instead of 8. Maybe that's not so bad? But people do use serial ports. Getting all 8 ports (5 on the breadboard pins, 3 on the bottom) seems pretty attractive.
Unfortunately, the pins where the CANFD signals can be accessed don't have much else going for them. They come to 3 locations. The first shares only with CAN2 (why NXP would choose that, I have no idea) and the other shares with part of the 3rd I2S and a couple pins from a GPT timer and a couple XBAR inputs. The XBAR signals are probably the only interesting thing someone not using CAN3 might do with those pins. The 3rd location can't be used since they're JTAG pins needed by the bootloader.
FWIW, on the chip's timers, my general plan is to make the 16 FlexPWM and 16 Quadtimers available for general signal usage (at least the subset routing to pins - though others can route though the XBAR to pins). I'm planning to use all 3 channels from both GPT timers to augment the PIT timers, so Teensy 4.0 will be able to support 10 IntervalTimer instances. Only the PIT & GPT have the option to clock directly from the 24 MHz crystal, and I'm going to make that the default, so all IntervalTimer will remain on the same time base when you dynamically change the F_CPU speed.
