You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Regarding DS-015 we participated in the network topology discussion and stated if that if there's a well defined configuration of nodes and it's topology we could help analyzing the impact of different bitrates on such a topology.
The sample point is the location, typically given as a percent value, inside each bit period where the CAN controller looks at the state of the bus and determines if it is a logic zero (dominant) or logic one (recessive). All CAN controllers allow this point to be configured and it is always specified as a percentage from the start of the bit period.
The location of the sample point is a trade-off. An early sample point decreases the sensitivity to oscillator tolerances and allows lower-quality oscillators. A late sample point allows for a longer signal propagation time and therefore a longer bus. A later sample point is useful for non-ideal bus topologies.
The CAN-in-Automation user’s group makes recommendations of where the sample point should be for various bit rates, with 87.5% the most common.
"FAQ contribution from Embedded Systems Academy, experts in CAN bus. For more information visit www.esacademy.com"
Sample points recommendations
(87.5 % is the preferred value used by CANopen and DeviceNet, 75% is the default value for ARINC 825).
I do concur with @thirtytwobits about having a sample point option as well. Or at least thinking about minimal sample point or something like that. MCU's can indeed calculate timings (e.g. https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/s32k1xx/s32k1xx_flexcan.c#L393). However only having the timing from just the bitrate isn't enough you might end up with a low sample point e.g. 60% which is non-ideal.
Regarding DS-015 we participated in the network topology discussion and stated if that if there's a well defined configuration of nodes and it's topology we could help analyzing the impact of different bitrates on such a topology.
Originally posted by @PetervdPerk-NXP in #109 (comment)
I presume it should be named
uavcan.can.sample_point_pct
and typeduint8[2]
, for arbitration and data segments, respectively.The text was updated successfully, but these errors were encountered: