Re: Resources for Linux SocketCAN

Hi,

Suppose there is 20 different messages in the common tx queues for a device
from suppose 4 processes.
My question is does SocketCAN & CAN4Linux supports message priority based
transmission, or it is just FIFO.

>> Each receiving process needs its on receive queue for example and memory
for it. To mange this, at compile time yo define
-DCAN_MAX_OPEN=4 in the Makefile to allow, in this example, four processes
to open one physical device at the same time.
Queue size too is a compile time constant.


Yes that what i was thinking if can4linux support same device to be opened
by different process then there will be common TX queue for device
& individual receive queue(for every process).

>> I prefer UIO based drivers ... they running in user space and need only
very small kernel modules which are more or less independent from the
kernel version.
An user space driver can be written in plain POSIX code, avoids a lot of
context switches, and can be used for LINUX and PREEMPT_RT Linux.

Yes mmap() the /dev/mem for CAN driver Registers, is always a best option,
with one thread receiving packets & other thread transmitting. I do not see
any problem with transmission of packets. But main problem comes at the the
time of asynchronous receiving when  bus load is high say 1-Mbps this may
led to the packet loss if MOB registers are already preoccupied.

Also when you are using external SPI based devices like MCP-2515 then in
that case you need a driver to communicate with SPI protocol driver. Then
user space application have to context switch at least for writing to
device. Though asynchronous receive can be implemented using Proc or
Debugfs interfaces.

Regards,

Dinesh


On Fri, Feb 1, 2013 at 5:39 AM, Bram Kerkhof <[email protected]> wrote:

> The can4linux API seems to be a way better match for my needs than the
> convoluted SocketCAN stuff, but I have the impression that the build
> process
> needs a fair bit of hand waving and polishing... If I want even a shadow of
> hope that the kernel guys include this in their precious build environment,
> some major trimming needs to be done; ideally it should be a neat and tidy
> buildroot package for my target platform (iMX25@400Mhz), and play nice
> with
> Crosstool-NG.
>
> You don't happen to have experience with buildroot? ;-)
>
> Cheers,
> Bram
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Heinz-Jürgen Oertel
> Sent: donderdag 31 januari 2013 23:57
> To: [email protected]
> Subject: Re: [CANLIST] Resources for Linux SocketCAN
>
> Am Donnerstag 31 Januar 2013, 23:14:27 schrieb [email protected]:
> > Hello,
> >
> > the  problems to watch in selected socketCAN implementation could be
> > - message priorizing (the one we tweaked didnt have a proper one, or
> > at
> > all?)
> > - message buffering i.e does every incoming message create an
> > interrupt and force the CPU to fetch it? This could create a MAJOR
> > load in higher traffic
> > - is it possible to do also all necessary configurations and
> > diagnostics via SC? Once again the one we had in hand did not handle
> this.
> >
> > We have later tested the one for iMX53 from Freescale and that with
> > their flexcan works pretty well.
> > Although we are still missing some functionality and speed and will
> > build a cutomized driver.
> >
> > isto
> >
>
> can4linux is available for FlexCAN  and some iMX devices.
> Give it a try and improve it with what you call "missing functionality" -
> whatever this is.
>
> Regards
>  Heinz
>
>
> >
> >
> > "Bram Kerkhof"
> >
> >
> >
> >
> > From:   "Bram Kerkhof" <[email protected]>
> > To:     <[email protected]>
> > Date:   28.01.2013 14:09
> > Subject:        [CANLIST] Resources for Linux SocketCAN
> > Sent by:        [email protected]
> >
> >
> >
> >
> > Hi all,
> >
> > In my current project we have to use the Linux SocketCAN layer to get on
> > the bus, so I?m investigating existing resources and documentation for
> the
>
> > API.
> >
> > As can be expected, google turns up a number of links, which may or may
> > not be up-to-date, and of which most links are limited to describing the
> > part of the API that scratches the author?s itch.
> > So have any of you worked already with SocketCAN; what are your
> > experiences and can you recommend any useful links or information?
> >
> > Cheers,
> > Bram
> >
> >
> >
> >
> > This e-mail is confidential and it is intended only for the addressees.
> Any review, dissemination, distribution, or copying of this message by
> persons or entities other than the intended recipient is prohibited. If you
> have received this e-mail in error, kindly notify us immediately by
> telephone or e-mail and delete the message from your system. The sender
> does
> not accept liability for any errors or omissions in the contents of this
> message which may arise as a result of the e-mail transmission.
> >
> --
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector.com/canlist/
> Report any problems to <[email protected]>
>
>
> --
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector.com/canlist/
> Report any problems to <[email protected]>
>