On 09/21/2010 06:49 PM, [email protected] wrote: > Hello Oliver, > Hello Wolfgang, > > >>> If the self reception message is looped back to Rx queue in Tx >>> interrupt (3) end becomes time stamp exactly at this moment - when we > >>> are getting the correct starting point for our timeout countdown. And > >>> important issue - if we are using active CAN interface (the one with >>> own microcontroller), the timestamp shall be generated by >>> microcontroller and passed to SocketCAN driver. >> >> The timestamp is set in netif_rx(). In the case above it's done at tx >> completion interrupt, which looks like the behaviour you prefer to > have. >> >> Especially i would take a look into the per-socket filters, that would > allow >> you to filter for exact CAN-Identifiers, which prevents your socket > rx-queue >> to contain other stuff, that's sorted out in userspace. The used > rx-queue >> could be really short then. >> >> E.g. you could use different sockets for different CAN-ID filters (and > the >> select()-syscall) to handle all of them in your userspace app. > > I was checking the sja100_start_xmit from sja1000.c and was captured by > the > line: > > . > can_put_echo_skb(skb, dev, 0); > . > > I thought this is the moment, when the tx message is looped back. But > obviously > this is happening in sja1000_interrupt on Tx interrupt event by the mean > of: > > . > can_get_echo_skb(dev, 0); > netif_wake_queue(dev); > . > > If this is like that, than I am surely OK with it.
The code is your friend: http://lxr.linux.no/#linux+v2.6.35.5/drivers/net/can/dev.c#L311 should convinse you. > I like the idea for using several opened socket on one interface for > it's > elegance, but afraid this is not applicable due to very critical > requirement: > the order of messages for both Tx and Rx messages shall be kept. > > Example from CANopen for reception: > Imagine two CAN messages on the bus coming very close. > The first is PDO with data and the second is NMT command "switch to > preop". > Received by the CANopen application in that order, this sequence will > cause > data update (PDO) and NMT state transition in state "preop" (we assume > state > "operational" before). In the "preop" state PDO processing is disabled. > So if > due to reception of PDO and NMT over different sockets the order of > message > processing will be changed (NMT before PDO), the application will switch > to > "preop" before processing the PDO and the data from that PDO will be > lost. Well, I do actually not understand why it's elagant to use more than one socket/thread for a serialized task. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
