On Tue, Feb 02, 2010 at 08:57:58PM +0100, Oliver Hartkopp wrote: > Ira W. Snyder wrote: > > Hello all, > > Hello Ira, > > i'll try to answer some general points ... > > > > > I have a few cPCI CAN cards from Janz. They consist of a non-intelligent > > cPCI MODULbus card into which plugs up to 4 MODULbus modules. Our boards > > have two intelligent CAN modules and a TTL module. Each CAN module has > > a MC68332 CPU and RAM onboard, along with an SJA1000 chip. The TTL > > module is basically used for GPIO. > > > > Currently, I use a character device driver provided by Janz, but I'd > > like to use the new in-kernel CAN interface layer instead. Mostly to > > make transitioning to newer kernels more painless, as well as to use the > > improved sockets-based API. > > :-) > > > > > I've written a few kernel drivers before, but I'm not very familiar with > > CAN at all. Can someone explain why I would want to use the intelligence > > on the CAN modules? To reduce interrupt load on the host system? > > The so called "active" or as you say "intelligent" CAN hardware gets its > justification from several points: > > 1. It reduces the interrupt latency requirements of the host system > 2. It can perform (complex) filtering inside the embedded hardware > 3. It can perform (time critical) CAN specific communication protocols (e.g. > ISO 16765-2) inside the embedded hardware > > These topics are mainly relevant for Windoze boxes ;-) > > With SocketCAN e.g. the integration of ISO 15765-2 inside the networklayer > easily allows to meet the timing requirements also with "passive" CAN > hardware. The integration of CAN communication protocols & filtering inside > the Linux networklayer therefore aims to make specialized "active" CAN > hardware unnecessary. > > The CAN netdevice driver model reduces the CAN interface to a common (simple) > driver interface as you know it from ethernet drivers. Their major > functionality is to simply send & receive ethernet frames ... > > "Active" CAN hardware is usually connected to the host system via dual-ported > RAM to allow the host CPU to retrieve the CAN frames or CAN protocol PDUs > en-bloc (see point 1. above). >
Thanks for this information. Now that I know what to look for, I've found the programming manual for the firmware running on the microcontroller. It is available here, if you're interested: http://www.janz.de/as/en/download-document/12-ican-software-reference-manual.html It'll take me a few days or more to get through it. > There are currently two active drivers both with dual-ported RAM access in the > SocketCAN SVN: > > - ESD PCI 331 > - Softing (PCMCIA) > > As Wolfgang already suggested the ESD PCI 331 driver seems to be a good > starting point for your development. > Now that I have a manual, these will be good examples. I've just finished an initial look through the ESD PCI 331 driver. I can already see similarities to the Janz board. I'm sure I'll be back with questions soon. :) Thanks for the help, Ira _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
