Hello Wolfgang this is the previous mail thread maintained with Jan and i
hope it answer your question
-- Forwarded message --
From: Jan Kiszka [EMAIL PROTECTED]
Date: Aug 13, 2007 1:13 AM
Subject: Re: i82527 CANbus RTDM driver
To: juanba romance [EMAIL PROTECTED]
juanba romance wrote:
On 8/12/07, Jan Kiszka [EMAIL PROTECTED] 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
