René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Unify bit timing parameters","articleBody":"I've had a quick look at the various interfaces and how you can specify custom bit timing parameters. They vary in abstraction. Some supports setting BTR registers directly, usually using some external tool for help. Some lets you specify SJW, TSEG1, TSEG2, SAM and then BRP is calculated from desired bitrate.\r\n\r\nFor CAN-FD you must specify different settings for arbitration phase and data phase.\r\n\r\nInterfaces supporting BTR register:\r\n* canalyst (named Timing0 and Timing1)\r\n* slcan (named btr as hexadecimal string)\r\n* pcan (possible, see #538)\r\n* ixxat (possible)\r\n* systec (possible)\r\n* ...?\r\n\r\nInterfaces supporting SJW, TSEG1, TSEG2, SAM:\r\n* kvaser (named sjw, tseg1, tseg2, no_samp)\r\n* vector\r\n\r\nInterfaces supporting CAN-FD:\r\n* kvaser (uses same sjw, tseg1, tseg2 for both arbitration and data)\r\n* vector (sjwAbr, tseg1Abr, tseg2Abr and sjwDbr, tseg1Dbr, tseg2Dbr)\r\n* pcan (f_clock, nom_brp, nom_tseg1, nom_tseg2, nom_sjw and data_brp, data_tseg1, data_tseg2, data_sjw)\r\n\r\nAs suggested by @bmeisels I propose to create a bit timing class which can bridge the different APIs and reduce clutter in the argument list. See #615 for implementation.","author":{"url":"https://github.com/christiansandberg","@type":"Person","name":"christiansandberg"},"datePublished":"2019-06-04T11:32:37.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":7},"url":"https://github.com/614/python-can/issues/614"}