CAN bus API

The official pyboard running MicroPython.
This is the reference design and main target board for MicroPython.
You can buy one at the store.
Target audience: Users with a pyboard.
Post Reply
jgui
Posts: 4
Joined: Thu Nov 10, 2016 5:06 pm

CAN bus API

Post by jgui » Thu Jun 14, 2018 12:34 pm

Why id type (extended / standard) is not handled the same way as frame type (RTR / not RTR)?

Instead of:

CAN.init(mode, extframe=False, prescaler=100, *, sjw=1, bs1=6, bs2=8, auto_restart=False)
CAN.send(data, id, *, timeout=0, rtr=False)
(id, RTR, FMI, DATA) = CAN.recv(fifo, list=None, *, timeout=5000)

we could have:

CAN.init(mode, prescaler=100, *, sjw=1, bs1=6, bs2=8, auto_restart=False)
CAN.send(data, id, ext=False, *, timeout=0, rtr=False)
(id, EXT, RTR, FMI, DATA) = CAN.recv(fifo, list=None, *, timeout=5000)
with EXT: a boolean that indicates if id is extended or not.


I guess this choice is to simplify somehow the API, but as a consequence you need to use the 2 CAN channels and 2 transceivers to communicate with a product that is using both extended and standard id frames.

Do I miss something? Do you think it would be relevant to propose such an evolution?

jickster
Posts: 629
Joined: Thu Sep 07, 2017 8:57 pm

Re: CAN bus API

Post by jickster » Mon Jul 02, 2018 9:03 pm

jgui wrote:
Thu Jun 14, 2018 12:34 pm
Why id type (extended / standard) is not handled the same way as frame type (RTR / not RTR)?

Instead of:

CAN.init(mode, extframe=False, prescaler=100, *, sjw=1, bs1=6, bs2=8, auto_restart=False)
CAN.send(data, id, *, timeout=0, rtr=False)
(id, RTR, FMI, DATA) = CAN.recv(fifo, list=None, *, timeout=5000)

we could have:

CAN.init(mode, prescaler=100, *, sjw=1, bs1=6, bs2=8, auto_restart=False)
CAN.send(data, id, ext=False, *, timeout=0, rtr=False)
(id, EXT, RTR, FMI, DATA) = CAN.recv(fifo, list=None, *, timeout=5000)
with EXT: a boolean that indicates if id is extended or not.


I guess this choice is to simplify somehow the API, but as a consequence you need to use the 2 CAN channels and 2 transceivers to communicate with a product that is using both extended and standard id frames.

Do I miss something? Do you think it would be relevant to propose such an evolution?
I agree: if a controller supports standard AND extended messages, we should allow per-message setting of the ID type.

For completeness, there are controllers that cannot transmit extended but can receive extended

Section 5: http://home.isr.uc.pt/~rui/str/EXTENDED.pdf

but I don't think this is the case here. This is only true for super old controllers or POSSIBLY super-duper cheap controllers.

I created an issue for it

https://github.com/micropython/micropython/issues/3916

Post Reply