* Error Active
@ 2014-04-14 8:03 Steffen Rose
2014-04-14 8:50 ` Wolfgang Grandegger
0 siblings, 1 reply; 6+ messages in thread
From: Steffen Rose @ 2014-04-14 8:03 UTC (permalink / raw)
To: linux-can@vger.kernel.org
Hello,
I write a generic application, that should work with different socketcan driver implementations.
I know, there are different possibilities to get the CAN controller state. And I see, that different
implementation do not implement all of them.
What is the standard way to get the state change from Error Passive to Error Active?
My current way (in short incomplete form):
can_err_mask_t err_mask = CAN_ERR_FLAG | CAN_ERR_CRTL | CAN_ERR_PROT | CAN_ERR_BUSOFF;
setsockopt(mBSDSocket, SOL_CAN_RAW, CAN_RAW_ERR_FILTER, &err_mask, sizeof(err_mask));
got = read(mBSDSocket, &frame, sizeof(struct can_frame));
if (frame.can_id & CAN_ERR_FLAG) {
if (frame.can_id & CAN_ERR_PROT) {
if (frame.data[2] & CAN_ERR_PROT_ACTIVE) {
=> change to Error active
}
}
}
This will work with the Systec USB interface, but do not work with Peak, Beagle bone, EMS CPC.
I have seen the implementation in the can utils.
I know, the libsocketcan implements a different way. But I cannot extract the relevant parts.
And I think a have to poll the current state with it and I search an event based mechanism.
--
Mit freundlichen Grüßen / Regards
Steffen Rose
www.emtas.de
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Error Active
2014-04-14 8:03 Error Active Steffen Rose
@ 2014-04-14 8:50 ` Wolfgang Grandegger
2014-04-14 9:56 ` Steffen Rose
0 siblings, 1 reply; 6+ messages in thread
From: Wolfgang Grandegger @ 2014-04-14 8:50 UTC (permalink / raw)
To: Steffen Rose; +Cc: linux-can
Hi Stefan,
On Mon, 14 Apr 2014 10:03:51 +0200, Steffen Rose <ro@emtas.de> wrote:
> Hello,
>
> I write a generic application, that should work with different socketcan
> driver implementations.
> I know, there are different possibilities to get the CAN controller
state.
> And I see, that different
> implementation do not implement all of them.
>
> What is the standard way to get the state change from Error Passive to
> Error Active?
Historically we only supported "increasing" state changes
"active->warning->passive->bus-off". A few recent drivers do
also support "passive->warning->active" but most don't (yet).
> My current way (in short incomplete form):
>
> can_err_mask_t err_mask = CAN_ERR_FLAG | CAN_ERR_CRTL | CAN_ERR_PROT |
> CAN_ERR_BUSOFF;
> setsockopt(mBSDSocket, SOL_CAN_RAW, CAN_RAW_ERR_FILTER, &err_mask,
> sizeof(err_mask));
>
> got = read(mBSDSocket, &frame, sizeof(struct can_frame));
> if (frame.can_id & CAN_ERR_FLAG) {
> if (frame.can_id & CAN_ERR_PROT) {
> if (frame.data[2] & CAN_ERR_PROT_ACTIVE) {
>
> => change to Error active
Yes, that would be the correct way but as I said above, only a few drivers
use CAN_ERR_PROT_ACTIVE (do a "grep -r CAN_ERR_PROT_ACTIVE
drivers/net/can").
...
> This will work with the Systec USB interface, but do not work with Peak,
> Beagle bone, EMS CPC.
Some time ago I have posted an RFC for providing "decreasing" state
changes
as well including proper bus-off recovery for the SJA1000. If would dig it
out in case you are interested.
> I have seen the implementation in the can utils.
>
> I know, the libsocketcan implements a different way. But I cannot
extract
> the relevant parts.
> And I think a have to poll the current state with it and I search an
event
> based mechanism.
It's not a matter of libsocketcan or ip/iproute2.
Wolfgang.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Error Active
2014-04-14 8:50 ` Wolfgang Grandegger
@ 2014-04-14 9:56 ` Steffen Rose
2014-04-14 11:05 ` Wolfgang Grandegger
0 siblings, 1 reply; 6+ messages in thread
From: Steffen Rose @ 2014-04-14 9:56 UTC (permalink / raw)
To: linux-can; +Cc: Wolfgang Grandegger
Hello Wolfgang,
> > What is the standard way to get the state change from Error Passive to
> > Error Active?
>
> Historically we only supported "increasing" state changes
> "active->warning->passive->bus-off". A few recent drivers do
> also support "passive->warning->active" but most don't (yet).
Historically:
What was the correct error handling in state error passive? Did you ignore it
in the application? My concrete question is, how did you "define" an error free
system after this state change in earlier time?
> > This will work with the Systec USB interface, but do not work with Peak,
> > Beagle bone, EMS CPC.
>
> Some time ago I have posted an RFC for providing "decreasing" state
> changes
> as well including proper bus-off recovery for the SJA1000. If would dig it
> out in case you are interested.
I'm afraid, I do not write / change my supported socketcan drivers. But I'm
interested to read the RFC.
> > I have seen the implementation in the can utils.
> > I know, the libsocketcan implements a different way. But I cannot
> > extract
> > the relevant parts.
> > And I think a have to poll the current state with it and I search an
> > event
> > based mechanism.
>
> It's not a matter of libsocketcan or ip/iproute2.
I have seen a difference of the can state between
candump -e can0,0~0,#FFFFFFFF
(increase errors - last was error passive)
and
ip -det -stat link show can0
(show error warning state)
This difference was during transmission on an open can bus with Ack error and
state error passive.
ip got the correct state error passive after receiving a message later, as I
did check the error active state change.
Do socketcan have different ways to get the current state? Is it a low level
driver part to read and hold the current state?
(I'm sorry. I'm unsure about the driver I tested in this situation. I think,
it was the EMS CPC driver and kernel 3.2.0-60-generic. )
--
Mit freundlichen Grüßen / Regards
Steffen Rose
www.emtas.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Error Active
2014-04-14 9:56 ` Steffen Rose
@ 2014-04-14 11:05 ` Wolfgang Grandegger
2014-04-14 12:13 ` Steffen Rose
0 siblings, 1 reply; 6+ messages in thread
From: Wolfgang Grandegger @ 2014-04-14 11:05 UTC (permalink / raw)
To: Steffen Rose; +Cc: linux-can
Hi Stefan,
On Mon, 14 Apr 2014 11:56:54 +0200, Steffen Rose <ro@emtas.de> wrote:
> Hello Wolfgang,
>
>> > What is the standard way to get the state change from Error Passive
to
>> > Error Active?
>>
>> Historically we only supported "increasing" state changes
>> "active->warning->passive->bus-off". A few recent drivers do
>> also support "passive->warning->active" but most don't (yet).
>
> Historically:
> What was the correct error handling in state error passive? Did you
ignore
> it
> in the application? My concrete question is, how did you "define" an
error
> free
> system after this state change in earlier time?
Well, as I said. The state was never decreased from error passive, which
is wrong, I agree. So far nobody cared.
>> > This will work with the Systec USB interface, but do not work with
>> > Peak,
>> > Beagle bone, EMS CPC.
>>
>> Some time ago I have posted an RFC for providing "decreasing" state
>> changes
>> as well including proper bus-off recovery for the SJA1000. If would dig
>> it
>> out in case you are interested.
>
> I'm afraid, I do not write / change my supported socketcan drivers. But
> I'm
> interested to read the RFC.
Check
https://gitorious.org/linux-can/wg-linux-can-next/commits/eec921ac28fde243456078a557768808d93d94a3
Especially the commits for "can: sja1000: consolidate error state
handling" and
"can: sja1000: consolidate bus-off handling", which can be regarded as the
reference. The commit messages also shows traces. That's how they should
look
like.
>> > I have seen the implementation in the can utils.
>> > I know, the libsocketcan implements a different way. But I cannot
>> > extract
>> > the relevant parts.
libsocketcan, like ip uses a netlink socket to get the configuration and
statistics of the CAN device. This includes the "state" property.
>> > And I think a have to poll the current state with it and I search an
>> > event
>> > based mechanism.
That's a bad idea. Looking to the state changes via error messages is far
more elegant.
>> It's not a matter of libsocketcan or ip/iproute2.
>
> I have seen a difference of the can state between
> candump -e can0,0~0,#FFFFFFFF
> (increase errors - last was error passive)
>
> and
> ip -det -stat link show can0
> (show error warning state)
>
> This difference was during transmission on an open can bus with Ack
error
> and
> state error passive.
> ip got the correct state error passive after receiving a message later,
as
> I
> did check the error active state change.
>
> Do socketcan have different ways to get the current state? Is it a low
> level
> driver part to read and hold the current state?
No. Both get the infos via netlink socket from the kernel.
> (I'm sorry. I'm unsure about the driver I tested in this situation. I
> think,
> it was the EMS CPC driver and kernel 3.2.0-60-generic. )
This device uses a SJA1000.
Wolfgang.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Error Active
2014-04-14 11:05 ` Wolfgang Grandegger
@ 2014-04-14 12:13 ` Steffen Rose
2014-04-14 14:38 ` Wolfgang Grandegger
0 siblings, 1 reply; 6+ messages in thread
From: Steffen Rose @ 2014-04-14 12:13 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linux-can
Hello Wolfgang,
thank you very much for your answers.
> libsocketcan, like ip uses a netlink socket to get the configuration and
> statistics of the CAN device. This includes the "state" property.
Do all implementation support the netlink socket, especially the CAN state?
I think, state is UNKNOWN and don't mean the Can state, is it?
$ ip -det -stat link show can0
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast *state* UNKNOWN qlen
10000
link/can
*can state* ERROR-ACTIVE restart-ms 0
bitrate 250000 sample-point 0.875
tq 250 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
ems_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
> > Do socketcan have different ways to get the current state? Is it a low
> > level
> > driver part to read and hold the current state?
>
> No. Both get the infos via netlink socket from the kernel.
I'm not so familiar with the parts of the system and the correct naming of it.
I understand, that socketcan has a common part for all (many) driver
adaptations (can_bcm, can_raw) and a CAN controller specific part (can).
As I understand, for the last point exists many different implementations with
different feature implementation.
> > (I'm sorry. I'm unsure about the driver I tested in this situation. I
> > think,
> > it was the EMS CPC driver and kernel 3.2.0-60-generic. )
>
> This device uses a SJA1000.
>
My mistake
USB interface from EMS
vcan 12686 0
can_bcm 22077 0
can_raw 17120 0
can 36556 2 can_bcm,can_raw
ems_usb 17510 0
can_dev 15321 1 ems_usb
--
Mit freundlichen Grüßen
Steffen Rose
-------------------------------------------------------------------------
emtas - your embedded solution partner
Nächste CANopen Schulung am 06. Mai in Merseburg
Nächste EnergyBus Schulung am 07. Mai in Merseburg
-------------------------------------------------------------------------
emtas GmbH
Fritz-Haber-Straße 9
06217 Merseburg
Tel.: +49(0)3461-79416-0
Fax.: +49(0)3461-79416-10
www.emtas.de - service@emtas.de
Geschäftsführer: Andreas Boebel, Torsten Gedenk, Steffen Rose
Registergericht: Amtsgericht Stendal
Registernummer: HRB 17616
-------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Error Active
2014-04-14 12:13 ` Steffen Rose
@ 2014-04-14 14:38 ` Wolfgang Grandegger
0 siblings, 0 replies; 6+ messages in thread
From: Wolfgang Grandegger @ 2014-04-14 14:38 UTC (permalink / raw)
To: Steffen Rose; +Cc: linux-can
On Mon, 14 Apr 2014 14:13:33 +0200, Steffen Rose <ro@emtas.de> wrote:
> Hello Wolfgang,
>
> thank you very much for your answers.
>
>> libsocketcan, like ip uses a netlink socket to get the configuration
and
>> statistics of the CAN device. This includes the "state" property.
>
> Do all implementation support the netlink socket, especially the CAN
state?
Yes.
> I think, state is UNKNOWN and don't mean the Can state, is it?
> $ ip -det -stat link show can0
> 3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast *state*
UNKNOWN
> qlen
This "state" is network related.
> 10000
It follows the CAN related settings and statistics.
> link/can
> *can state* ERROR-ACTIVE restart-ms 0
> bitrate 250000 sample-point 0.875
> tq 250 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
> ems_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
> clock 8000000
> re-started bus-errors arbit-lost error-warn error-pass bus-off
> 0 0 0 0 0 0
> RX: bytes packets errors dropped overrun mcast
> 0 0 0 0 0 0
> TX: bytes packets errors dropped carrier collsns
> 0 0 0 0 0 0
>
>
>> > Do socketcan have different ways to get the current state? Is it a
low
>> > level
>> > driver part to read and hold the current state?
>>
>> No. Both get the infos via netlink socket from the kernel.
This answer is wrong. It has nothing to do with the netlink socket.
Sorry for confusion. Yes, the low-level driver does handle the state
changes
reported by the CAN hardware.
> I'm not so familiar with the parts of the system and the correct naming
of
> it.
>
> I understand, that socketcan has a common part for all (many) driver
> adaptations (can_bcm, can_raw) and a CAN controller specific part
(can).
There is CAN protocol, common CAN devices interface and specific device
drivers.
> As I understand, for the last point exists many different
implementations
> with
> different feature implementation.
Ideally they do implement the same features but it depends on the hardware
to some extend, of course. The big goal is to provide a *common* interface
for CAN error state and error message handling.
>> > (I'm sorry. I'm unsure about the driver I tested in this situation. I
>> > think,
>> > it was the EMS CPC driver and kernel 3.2.0-60-generic. )
>>
>> This device uses a SJA1000.
>>
>
> My mistake
> USB interface from EMS
>
> vcan 12686 0
> can_bcm 22077 0
> can_raw 17120 0
> can 36556 2 can_bcm,can_raw
> ems_usb 17510 0
> can_dev 15321 1 ems_usb
OK.
Wolfgang.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-04-14 14:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-04-14 8:03 Error Active Steffen Rose
2014-04-14 8:50 ` Wolfgang Grandegger
2014-04-14 9:56 ` Steffen Rose
2014-04-14 11:05 ` Wolfgang Grandegger
2014-04-14 12:13 ` Steffen Rose
2014-04-14 14:38 ` Wolfgang Grandegger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.