On Mon, May 10, 2010 at 12:27:13PM +0530, Subhasish Ghosh wrote:
>
> Hi!,
>
> I have one more concern regarding not using any hw ID filter for individual
> mailboxes.
>
> If I understand correctly, when a CAN receiver receives data, it sends an ACK
> to the transmitter.
> Now, if hw filtering is not supported, when a transmitter sends something and
> many receivers read the data, then all of them would send an ACK.
>
> How will the transmitter ever know if the intended receiver actually received
> the data.
never.
Even when it would do hardware filtering, and no filter matched, the chip would
send
an ACK.
And indeed, if 3 chips are on the bus, A B & C, and A sends, and receives an
ACK,
you could (in theory) not say who generated an ack.
But in such cases, you're on a bad bad bus.
The ack is not to indicate the messages got through some filter, but to
indicate the
bus is ok.
If you need application level ack's, you need to design it in your
communication,
like you would do on UDP (when comparing to TCP).
Kurt
>
> Best Regards,
> Subhasish Ghosh
>
>
>
>
> ________________________________
> From: Kurt Van Dijck <kurt.van.di...@eia.be>
> To: Wolfgang Grandegger <w...@grandegger.com>
> Cc: Oliver Hartkopp <socket...@hartkopp.net>; Subhasish Ghosh
> <subhasis...@yahoo.com>; socketcan-users@lists.berlios.de
> Sent: Tue, 27 April, 2010 2:50:59 PM
> Subject: Re: [Socketcan-users] Socket can h/w filter
>
> On Tue, Apr 27, 2010 at 09:48:23AM +0200, Wolfgang Grandegger wrote:
> > Oliver Hartkopp wrote:
> > > Subhasish Ghosh wrote:
> > >
> > >> The CAN controller that I am using allows configuring per-mailbox IDs.
> > >> CAN being a broadcast network, this feature reduces the interrupts to
> > >> the processor.
> > >>
> > >> From Documentation/can.txt, what I understand is that the socketcan
> > >> interface does not provide any mechanism to configure the h/w for this
> > >> purpose (chapter 6.3).
> > >>
> > >> Instead, the h/w is configured to receive all identifiers and the
> > >> filtering is done on the stack (like ti_hecc.c) and to avoid hogging the
> > >> processor some interrupt mitigation techniques like NAPI is implemented.
> > >>
> > >> Isn't this a work around?
> I think the mailbox infrastructure is a workaround to sell CAN chips
> without the requirement for a decent software infrastructure :-)
>
> Can your CAN chip receive RTR frames and put them to software without the
> hardware transmitting something?
> > >
> > >
> > > No it's not.
> > >
> > > Remember that you're working in a multi-user system now, and therefore
> > > it's
> > > not defined what all of your user-apps need from the specific CAN bus.
> > >
> > > For that reason the implementation of efficient filters is done in the
> > > soft-IRQ that's called right after the (hard-) interrupt routine of the
> > > CAN
> > > driver.
> > >
> > > Having a generic CAN driver interface is one of the major motivations for
> > > SocketCAN. You really don't want to have hardware-specific ("N mailboxes")
> > > configuration interfaces which leads into a maintenance hell.
> >
> > Yes, I also do not see a generic way yet to support per mailbox (or
> > message object) filtering.
> Ack.
>
> I've had some experience with the CAN chip within the c167 infineon cpu,
> which I
> believe is similar to the bosch cc770 can chip.
> Such setup with different 'mailboxes' only worked when there is a system-wide
> policy defined which CAN id go via which mailbox.
>
> a small piece of history:
> Before I found that such policy is _really_ required (although I found this
> nowhere
> in the datasheets), I ran into a race condition of the hardware (!).
> If you put (in that specific CAN chip) 2 different CANids in TX mailboxes,
> but whose
> CANids do match within the global receive mask, and the lowest CAN id is put
> in a
> mailbox after the higher(=lower priority on CAN) CANid, then the CAN chip
> would send
> the higher priority CAN id first (=good), but fails to find the correct TX
> mailbox
> in the CAN chip. Instead, it marks the first matched mailbox(= higher CAN id,
> which
> was not sent!) as transmitted. Subsequently, it finds the second mailbox
> (with the
> CANid that was just sent) as wanting transmission ......
>
> I'm not sure on the precise relationship between CAN id's, or how to configure
> the mailboxes (its about 8years ago).
> Anyway, I ended up in a CAN frame sent back to back because I used >1 TX
> mailbox.
>
> => rule 1: only use 1 tx mailbox.
>
> As oliver mentioned, different applications may need different filters on the
> mailbox.
> If 2 applications use different filters, you cannot tell if a frame that
> matched the
> first filter would not match the second. So, software filtering is still
> required.
>
> The existing software filters are, IMO, way more powerfull that what I have
> seen from
> hardware filters.
>
> => rule 2: use software filtering.
> >
> > >> My question is, did I miss something, is there any way to configure the
> > >> h/w for this purpose. Is it a good idea if I cook up a sysfs interface
> > >> for my driver for this.
> > >
> > >
> > > The problem is, that a filtering on driver level affects *every* user in
> > > the
> > > system.
> >
> > Yes, messages rejected by hardware filters are lost.
> >
> > > So far no one discovered a problem with the irq-load of CAN drivers in his
> > > system. We've been running a 133MHz PowerPC with four SJA1000 controllers
> > > for
> > > years ...
> >
> > Interrupt load might be an issue, especially on load end systems.
> >
> > > If you really(!) get into problems, we should discuss a netlink
> > > configuration
> > > option for driver-level CAN-ID filtering (also abstracted from
> > > "mailboxes").
> >
> > Yes.
> >
> > > But please check if it's really needed and if you probably have a
> > > different
> > > view on the general approach of SocketCAN now.
> >
> > Some kind of generic hardware filter support might be useful for some
> > corner cases, I think. Does anyone else find it useful?
> I have long stopped using hardware filters.
> Please note this is only my experience.
> If a decent netlink based mechanism would emerge, not affecting
> the software filters, and not trying to be intelligent, but just relaying
> a system wide policy into a CAN chip, then it would not hurt?
> And chips implementing it, could then at least measure their performance gain
> (and
> see if it was worth the effort). (This last issue could be measured with some
> quick sysfs properties too)
> >
> > Wolfgang.
> Kurt
> > _______________________________________________
> > Socketcan-users mailing list
> > Socketcan-users@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/socketcan-users
>
>
_______________________________________________
Socketcan-users mailing list
Socketcan-users@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/socketcan-users
