Re: Resources for Linux SocketCAN
Heinz-Jürgen Oertel <[email protected]>
| Newsgroups | gmane.comp.hardware.bus.can |
|---|---|
| Message-ID | <5407564.MjuYGfYG5p@uschi> |
Am Mittwoch, 6. Februar 2013, 13:00:01 schrieb Dinesh Guleria: > Thanks for replying Heinz. Dinesh, It was not me who requested buildroot. It was Bram Kerkhof regards > > >> ideally it should be a neat and tidy > > > > buildroot package for my target platform (iMX25@400Mhz), and play nice > > with Crosstool-NG. > > Are you telling about, following buildroot ? > http://buildroot.uclibc.org/ > > Actually i have worked with crosstool-NG made made my cross toolchain. > And used raspbian rootfile system for the development along with > Scrathbox2 & QEmu. > > What exactly Buildroot is capable to do ? Means it requires > rootfile-system from the vendor or it is capable to create Kernel & > rootfile system for us. Haven't worked with it ? > > Regards, > > Dinesh > > On 2/6/13, Heinz-Jürgen Oertel <[email protected]> wrote: > > Hello Dinesh, > > > > Am Freitag 01 Februar 2013, 12:12:07 schrieben Sie: > >> 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. > > > > can4linux has only one TX Fifo (yet). > > There was no need to having priority based queues. > > It should not be to difficult to add such a feature. > > A bit more difficult would be to stop transmission of a low priority > > frame and schedule a higher prior one for transmission. > > > > I can not speak for SocketCAN, but think they have plans for it. > > > >> >> 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. > > > > This is correct. We prefer this static assign of resources. > > > >> [skip more ...] > > > > Regards > > > > Heinz > > > > -- -- Archives and useful links: http://groups.yahoo.com/group/CANbus Subscribe and unsubscribe at www.vector.com/canlist/ Report any problems to <[email protected]>