Schubert, Thorsten wrote: > On Tue, Mar 09, 2010 at 01:39:53PM +0100, Wolfgang Grandegger wrote: > >> No, ".brp_inc = 2" would mean that the brp register does not support > odd >> values. > > Of course it is true that the six BRP bits can be set to any > combination.
On the SJA1000 that's the case, but it might not for other CAN controllers. > I think the essential property one wants to specify is that the SJA1000 > will never generate TQs with an odd number of clock cycles. can_calc_bittiming() will take care. >> Hope it's clean now. > > Not quite. What is the meaning of the brp field in struct can_bittiming? Bit rate prescaler. > I assumed the idea of struct can_bittiming was to have device > independent > timing information. I am just wondering why there is a brp field at all. The brp is required on most CAN controllers to setup the proper bit-timing. The user does still specifiy the bit-timing in an hardware independent way. See: http://lxr.linux.no/#linux+v2.6.33/Documentation/networking/can.txt#L730 > Isn't this the driver's business to determine the brp value given the TQ > and the clock frequency? No, it would result in a lot of duplicated code. So far, can_calc_bittiming() does a good job. > However, if one defines struct can_clock to be the reciprocal of the > minimum time quanta (instead of a system clock), things are consistent. The user can specify the time quanta period if he likes. Still, it must be translated into values the hardware can use. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
