On Wed, Feb 10, 2010 at 07:19:26PM +0100, Kurt Van Dijck wrote: > On Wed, Feb 10, 2010 at 08:47:27AM -0800, Ira W. Snyder wrote: > > On Wed, Feb 10, 2010 at 10:09:34AM +0100, Kurt Van Dijck wrote: > > > On Tue, Feb 09, 2010 at 04:05:00PM -0800, Ira W. Snyder wrote: > > > > Hello all, > > > > > > > > I posted last week asking about a driver for boards running on a PLX > > > > chip. It turns out that these are passive boards. I have been looking > > > > for a driver for the Janz CMOD-IO board CAN interfaces. > > > > > > > > I finally found the datasheets and took the time to write a driver. This > > > > board is an intelligent CAN interface: it has onboard microprocessors to > > > > help process CAN traffic. > > > > > > > > This is a very rough first try at a CAN driver. I'm sure it still has > > > > problems, and I would appreciate if you can take a look and help me add > > > > what is needed. I'm am not extremely knowledgeable about the CAN bus. > > > > > > > > The things that are known to be wrong: > > > > > > > > - bus-on / bus-off handling > > > > > > > > I did this straight in the network device open()/stop() methods. I don't > > > > handle the condition where we get too many bus errors and the bus goes > > > > into bus-off state. What should I be doing here? > > > What you call 'bus-off' is indeed the stop() method. the CAN busoff > > > (which is something different) > > > comes via interrupt (bus-state-change), indicating the > > > can-chip cut itself from the bus. In such case, a special 'struct > > > can_frame' must be emitted to userspace. > > > > Ok. The way I read this: the netdevice open()/stop() methods should put > > the device into "CAN buson" and "CAN busoff" state. In addition, when > > the device has an error, it will go into "CAN busoff" state eventually. > > In this case, I should generate a special CAN frame and send it to > > userspace. Is that right? > Well, the net_device goes up/down (like any other net_device). There is > no such thing as 'CAN buson'. And you can't put the chip in busoff > either. the CAN bus state (error-active, error-passive, bus-off) is a > parameter you can't control (from software, you can shortcircuit the bus > physically to force a bus-off during trasnmissions).
Ok. > I think it's important to distantiate between these. I must be confused by my datasheet. That is how I have been learning the CAN terminology. It has two commands for "Set CAN bus state", CONreq and COFFreq (on and off). It says: <begin quote from datasheet, page 3-32> The CAN controller is involved in bus activities only if its bust state is bus-on. For setting parameters to the controller it is necessary for the bus state to be bus-off (reset). The user requests the bus state to be set bus-on and bus-off, respectively, with messages supecified as CONreq and COFFreq, respectively. After reset and provider initialization the CAN controller is in the bus-off state. This is to allow the user to set the CAN controller parameters, e.g. the baud rate, to values different from their defaults before ICAN becomes an active station on the bus. Note that according to the CAN protocol the controller may be forced into the bus-off state when too many transmission errors occur. </end quote> > You would of course in the end find out you cannot put the chip in > bus-off :-). It seems to me, that is not what the datasheet says. But they probably use a different terminology than you are using. We're probably talking about different things. This card does not transmit packets until you set it into "bus-on" state, using the CONreq message. I found that if I do not set the card's state to "bus-on", then it sends me an error message. I think I should generate an error frame from the error message. Please note, I'm not trying to argue or be unfriendly, I'm just trying to get the terminology straight. Like I said, I'm not a CAN expert. I'm learning what I can as I write the driver. :) Thanks, Ira _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
