On Wed, Feb 10, 2010 at 08:00:11PM +0100, Wolfgang Grandegger wrote:
> 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:
[...]
> >>> 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. :)
Neither am I :-). I just try to avoid confusion.
>
> No problem, the data sheet just use a unusual terminology, especially
> for bus-on.
Definitely
[...]
>
>
> Wolfgang.
Kurt
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
