Ira W. Snyder wrote: > 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. :)
No problem, the data sheet just use a unusual terminology, especially for bus-on. When the CAN controller is stopped, or in reset or init mode, it is bus-off. When it goes to normal mode, it enters the CAN error state "error active". That is what your data sheet calls bus-on. When you stop the controller it goes bus-off again. The controller can also go bus-off by itself if it has detected too much errors. Hope it's clearer now. The following link might be useful as well: http://www.softing.com/home/en/industrial-automation/products/can-bus/more-can-bus/error-handling/error-states.php?navanchor=3010510 Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
