Christian Sandberg

Can’t we calculate the register values ourselves? It doesn’t seem to be that complicated after all. Maybe we should also take the opportunity for the next major release to unify...

My idea was to take BRP (or a calculate this as well), number of samples, tseg1, tseg2 and SJW to calculate the register values. Some interfaces use this abstraction level...

Interfaces like kvaser and vector seem to calculate the BRP based on bitrate. PCAN (CAN FD) forces you to provide BRP yourself. Other just use BTR directly. Maybe it is...

I've created a new issue #614 for unifying the various interfaces.

@bmeisels, could you have a look at this and tell me what you think?

> See my note about unifying arbitration and data timings. I must have missed that note, where is it? > As a general note I think my parameter list parsing...

Have you submitted the review?

I would prefer to get some more input on how we want to have it first. Basically if we should use class instances to divide between normal and data phase...

Maybe it is overkill exposing a class for this in the API. How about using dictionaries to group the timing parameters but having possibility to pass `f_clock` separately since it...

I'd like to add a third option, which is for the user to pass all bit timing settings as individual keyword arguments just like they do today, but with standardized...