hardbyte / hardbyte/python-can

Unify bit timing parameters

未關閉
#614 7 則留言 2 個 reaction 已指派 1 人 已被 @christiansandberg 認領 在 GitHub 檢視
api enhancement
主要語言
Python
星號
1.6k
分支
697
PR 合併指標
30 天內沒有已合併 PR

描述

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.

For CAN-FD you must specify different settings for arbitration phase and data phase.

Interfaces supporting BTR register:
* canalyst (named Timing0 and Timing1)
* slcan (named btr as hexadecimal string)
* pcan (possible, see #538)
* ixxat (possible)
* systec (possible)
* ...?

Interfaces supporting SJW, TSEG1, TSEG2, SAM:
* kvaser (named sjw, tseg1, tseg2, no_samp)
* vector

Interfaces supporting CAN-FD:
* kvaser (uses same sjw, tseg1, tseg2 for both arbitration and data)
* vector (sjwAbr, tseg1Abr, tseg2Abr and sjwDbr, tseg1Dbr, tseg2Dbr)
* pcan (f_clock, nom_brp, nom_tseg1, nom_tseg2, nom_sjw and data_brp, data_tseg1, data_tseg2, data_sjw)

As 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.

貢獻指南

開啟貢獻指南

評估

這個 Issue 還沒有評估資料。

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。