* [Xenomai-core] Fwd: i82527 CANbus RTDM driver
[not found] ` <46BF9427.2040809@domain.hid>
@ 2007-08-13 8:34 ` juanba romance
2007-08-13 8:54 ` Wolfgang Grandegger
0 siblings, 1 reply; 3+ messages in thread
From: juanba romance @ 2007-08-13 8:34 UTC (permalink / raw)
To: lwg; +Cc: xenomai
[-- Attachment #1.1: Type: text/plain, Size: 6170 bytes --]
Hello Wolfgang this is the previous mail thread maintained with Jan and i
hope it answer your question
---------- Forwarded message ----------
From: Jan Kiszka <jan.kiszka@domain.hid>
Date: Aug 13, 2007 1:13 AM
Subject: Re: i82527 CANbus RTDM driver
To: juanba romance <juanba.romance@domain.hid>
juanba romance wrote:
> On 8/12/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Hi Juanba,
>>
>> I won't go much into technical and design details in this reply, because
>> I'm hoping we can continue this discussion on some public list.
>> Xenomai-core e.g.?
>
> I think that right now the sources are not too useful in a first "public"
> post, may be better to announce in the list that i am developing the stuff
and
> wait if somebody else shows any interest would be better
>
> Would you like to re-post? With or without code
> (there is likely some size limit, so pushing code to a webserver is
better)?
> Of course, yes..
>
> Some questions I'm going to ask then:
>> - Is your API compatible to any pre-existing one?
> I don't think so, the stuff use specific objects/interfaces of the
Xenomai-framework
> to exchange the control and data flow between the user and kernel address
> spaces.
I was referring to the API the user of the CAN driver sees, not its
internal design. On first sight, I don't see Xenomai specifics in the
interface.
> In fact the objects/system calls were selected having in mind the driver
> capabilities which also income from our previous designs/products around
the 82527
> chipset
>
> > Did you consider the *official* RTDM CAN profile?
> Yes. I study your framework, but to be sincere i think that the
> capabilities/specifications are too far between. In particular all the
stuff
> related with the remote frame data exchange. The expected latencies and
the
> porting to other frameworks/platforms are also important to the
> re-usage-design. I have reviewed the official one as a reference to
> programming with the new symbols set and to check different approaches to
> solve our stuff.
Don't fully get your requirements yet - food for discussion on the
public list I guess.
>
>> If yes and something was missing/insufficient in that profile:
>> Why was it impossible to extend it (so that at least basic CAN
>> operations remain portable, tools can be reused)?
>
> I think that two matters were around my mind, time and optimal design.
> You must consider also the opposite situation. we already have a design
> implemented with the necessary tools to check/verify/validate; the point
is
> that we like/need to add it real time capabilities. This
> implementation/ideas ha/s/ve been ported from things like uclinux-mcf5282,
> linux-i386 including also MC51 micro controllers.
See, Socket-CAN is close to mainline Linux, and RT-Socket-CAN (ie.
RTDM's CAN profile) is compatible with it, just making it deterministic
under the hood. Older CAN frameworks for Linux, including commercial
ones, will more and more become obsolete.
If there are technical deficits, specifically compared to pre-existing
approaches, _that_ would be very interesting to discuss with the aim to
improve the design wherever feasible. Maybe it turns out that certain
scenarios simply require different approaches. But as long as deficits
aren't really discussed and, at best, quantified, we make no progress.
> Other important issue is my time and the required one to write the sources
> following the profile specification, which must be also fully understood.
> i.e. the sources don't consider at any stage the 11 and 29 bits stuff, our
> application is 29 bits focused on, so the stuff is removed
> I mean, we need to have the driver ready to the application purposes ASAP
> and this could be contradictory also with other generalist issues. Of
> course, I assume that i.e. that fix will be easy but i like to clarify
that
> this kind of things are minors from our point of view. The documentation
> that i need to build any case, will present these design issues in terms
of
> functional operation and provided tools.
Looking forward.
>
>> What are your plans with the driver? How/where are you planning to
>> maintain it?
>
> Right now i am worry about it's reliability on stress. This is one of the
> things that we have checked once and again at our company, a design is
> proposed, implemented, verified and validated but not under the worst case
> when all the software is fully weird, then the people cry.
>
> To be honest i haven't thought about the external issues in terms of
> maintenance, this is new for me. If the Xenomai crew like the stuff of
> course your control version repositories would be the best place. At our
For Xenomai integration, we either need a patch against the existing
stack, enhancing it in favour of creating a second one. Or we need
evidence that only a different approach is adequate for certain CAN
controllers and/or CAN applications.
> company we hold the driver stuff as much as possible, all the changes are
> biased to the application level, we don't add too much functionalities in
> the kernel space from the validation stage.
> I think you should guide me about the possibilities..
Or course, you can always stick with "grow your own". That's often
cheaper to start with, but wastes resources on the long term - as you
loose community participation, including a far broader testing, review,
and enhancement you generally can organise on your own.
>
>> So, my question will surely be critical :),
> Of curse not, it's only a matter to share/clarify points o view.. your
> comments are welcome..
>
>> but that shall not mean I don't appreciate your work! It's yet another
>> nice driver that may help people to build solutions. Well, and maybe we
can
>> still find common ground.
>
> That's it. I hope to have enough time to manage the stuff. To be
confidence
> i think that the stuff give a different point of view so could useful to
> somebody..
>
>> Thanks!
>> Jan
>
> I am grateful to ear your comments/opinions,
> Cheers
>
> So, I will post something related on in the xenomai-core list.. OK?
Yep.
>
> PS: Your archive name should end like ...tar.bz2.
>
> Guau.. uups sorry...
>
Jan
[-- Attachment #1.2: Type: text/html, Size: 7401 bytes --]
[-- Attachment #2: signature.asc --]
[-- Type: text/plain, Size: 250 bytes --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD4DBQFGv5QpniDOoMHTA+kRAkGAAJjd24o9F1+UrovxQHFbeZ1zJJzCAJ0XcC/0
QuJIv5SkmaadqJz/4ww6Jw==
=sugd
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 3+ messages in thread