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). 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. Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
