Mi suposición sobre esto se basa en el documento que encontré en TI , que explica los bits utilizados en un mensaje CAN.
Allí puede ver que el identificador extendido de 18 bits está seguido por el bit RTR y dos bits llamados r1 y r0 (bits de reserva) que actualmente no tienen significado y probablemente podrían usarse en otra extensión del protocolo CAN.
Entonces, el periférico PIC tiene que generar esos bits en el marco de alguna manera. Supongo que si los configura en 1, el marco contendrá un bit de reserva de valor 1, actualmente no se utiliza y, dependiendo del otro lado, no tendrá ningún impacto.
Elegir no cablear estos bits a 0 es bastante inteligente, ya que el periférico admitirá una futura extensión del protocolo sin un cambio en el hardware.
La documentación de Microchip podría ser más clara en ese punto.
Otra razón común para los bits reservados son los modos de prueba internos para el periférico (para las pruebas a nivel de chip), pero por lo general estos están ocultos para los usuarios de alguna manera.
Como nota: no use estos bits para su propia extensión del protocolo CAN solo porque no se usan ahora y son útiles para su aplicación (todos podrían usar 2 bits más en un marco de datos, ¿no?), antes o más tarde se romperá algo, probablemente de la manera más horrible.
Una mejor fuente es la especificación real como esta documento de Bosch, donde dice:
CAMPO DE CONTROL
El CAMPO DE CONTROL consta de seis bits. Incluye el CÓDIGO DE LONGITUD DE DATOS y
Dos bits reservados para futuras expansiones. Los bits reservados deben ser enviados 'dominante'.
Los receptores aceptan bits "dominantes" y "recesivos" en todas las combinaciones.
El campo de control aparece justo después del bit RTR.