Oliver, On Sat, Oct 03, 2009 at 02:33:27PM +0200, Oliver Hartkopp wrote: > Kurt Van Dijck wrote: [...] > > i assumed the CAN physical layer would come back into the discussion one day. > So thanks for picking it up. > > > Currently, my tests have been limited to activation/deactivation, since > > only these operations are affected. > > The majority of CAN users and CAN hardware developers only know CAN > transceivers like the 'dumb' 82C251 (www.nxp.com/pip/PCA82C251_3.html) > HighSpeed CAN transceiver, which allows 1MBit/s Bitrate. > > But when we look at the TJA1054 (www.nxp.com/pip/TJA1054_3.html) or TJA1041 > (www.nxp.com/pip/TJA1041_6.html) CAN transceivers, we get in contact with > > - fault tolerance, e.g. when one CAN line is shortened to GND > - transceiver sleep modes (*) > - start up the systems power supply due to CAN traffic > - transceiver error notifications > - reduced possible bitrates, e.g. the TJA1054 allows only 125 kBit/s > - etc waauw. I go ask my colleagues about these. > > * = especially to access the transceiver mode bits STB, /EN, /WAKE on a > TJA1054 or to read the /ERR pin of the TJA1054 need some real gpio pins. And > theses gpio pins are heavily hardware deopended! Since gpiolib (2.6.2x, drivers/gpio/...), gpio usage for this kind of application gets normalized too. > > So it's not only 'enabling' and 'disabling' the transceiver, there is need to > control and read the transceiver states and get some properties like > max_phy_bitrate or something like this. > > Does you approach allow these more complex dependencies also? My approach does absolutely _not_ address these dependencies. > Or is probably the PHY abstraction layer > > linux/Documentation/networking/phy.txt > > something, we should take a look at? Yes, we should not ignore such resource. I just looked into it. It seems like MDIO is a kind of serial bus (like I2C) that can have more PHY's on 1 bus, and every PHY have more registers. This is way more complex than what I know from CAN.
The CAN chips itself imply a series of link monitoring (busoff etc) inside the CAN chip. only a few options live outside (shortcircuit detection etc). I think this eliminitas the bigger interaction models as seen between PHY & ethernet devices. An interface would be limited to exposing some properties (max baudrate) at open_candev(), an 'enable()/disable()' hook. If I imagine a complex CAN transceiver, I'd implement another platform_device, using some GPIO's, .... The hard thing is finding the right transceiver for the right CAN chip, but I see no elegant solution for that in the PHY infrastructure. Nevertheless, I feel I'm not the only one having a GPIO for enabling the dumb 82C251 (my hardware colleague was proud telling it saves XX mA when off), so a more centralised approach could be interesting. I'll need to give this some time :-) > > As i'm not a 'platform' specialist maybe someone (like you) could give some > feedback to these requirements. > > Regards, > Oliver Kurt > _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
