Re: [Fwd: Re: [Xenomai-help] hello xenomai world?]

Re: [Fwd: Re: [Xenomai-help] hello xenomai world?]

[Roland Tollenaar]

Hi,
>> Invoke make like this: make /path to xeno-config/. Which is why I was
>> going on about the config variables. I wil now try and find
>> xeno-config if it exists and see how that works. On the other hand I
>> don;t doubt that the application will compile. I need to find out what
>> libraries to include for this particular one for the next steps. See
>> later.
> 
> Ack, my bad. The example makefiles do not assume /usr/xenomai (or,
> alternatively, /usr/xenomai/bin/xeno-config) as default for XENO. Will fix.
> 
> Meanwhile try "make XENO=/usr/xenomai".
Ok this does compile. however when running the resulting sigxcpu there 
is an error while loading the shared libraries. cannot find 
libnative.so.0. This may be a result of the library installation. From 
long ago I remember that to install a library ldsomethingorother must be 
run to amend a certain library file. Due to the live nature of my 
installation this file whatever it is called might get overwritten.
What is strange is that the other applications don't seem to have this 
problem. Latency testsuitapp runs for example.


> Your feedback is appreciated and helps improving things. Just a certain
> part of your verbosity might have been avoidable by digging a bit deeper
> and checking twice, no? :)
:)
Perhaps. We are all in a big hurry and there are lots of bits and pieces 
with lots of documentation. Most of it not so bad actually but not 
really unified. If I from my point of view were to comment, then I would 
say that a single unified manual would have really made life a lot 
easier. Then again I have a handicap with my distribution so it may have 
been a lot simpler had I been working on a fixed installation instead of 
a windows laptop which turns into linux when it has a usb stick in it. 
On yet a third hand, I do think that a lot of people will only start 
recompiling kernels when they enter this real-time story. A combined 
really slow step-by-step instruction set of how to compile the kernel 
with xenomai would make it a lot more accessible.

On even yet another hand (I'm counting with my feet by now) I don;t 
really know what the objective of xenomai is. So far it appears to be an 
impressively engineered product for which I don't doubt there should be 
decent interest. Industry however is rather demanding when it comes to 
development time (which is where my hurry comes from) and would 
generally not go through the motions I am trying to rush through here. 
We typically want a platform on which one can start developing for the 
application ASAP. Now even though what I am doing is relatively speaking 
the easy bit (compared to developing the rt-patches and drivers), there 
are still too many man hours involved in just getting to the final platform.

Apparently -from how I understand the documentation- the objective, or 
one of the objectives of xenomai, is to make porting to it from other RT 
operating systems as easy as possible. Having to struggle ones bottom 
off to get xenomai installed and understanding how it works, would rub a 
lot of the shine off this (I speak based only on the twinkels I have 
seen so far :)) otherwise hyper-promising bit of software engineering.

Anyhow, must catch some quick sleep. Sorry again for all the questions. 
Especially the stupid ones :)

Thanks for tolerating and responding to them.

Ah, one last thing, if you want to remind me about our contribution to 
the documentation that would be good.

Regards,

Roland.





> 
> Jan
> 
> 

Re: [Fwd: Re: [Xenomai-help] hello xenomai world?]

[Wolfgang Grandegger]

Roland Tollenaar wrote:
> Hi,
>>> Invoke make like this: make /path to xeno-config/. Which is why I was
>>> going on about the config variables. I wil now try and find
>>> xeno-config if it exists and see how that works. On the other hand I
>>> don;t doubt that the application will compile. I need to find out what
>>> libraries to include for this particular one for the next steps. See
>>> later.
>>
>> Ack, my bad. The example makefiles do not assume /usr/xenomai (or,
>> alternatively, /usr/xenomai/bin/xeno-config) as default for XENO. Will 
>> fix.
>>
>> Meanwhile try "make XENO=/usr/xenomai".
> Ok this does compile. however when running the resulting sigxcpu there 
> is an error while loading the shared libraries. cannot find 
> libnative.so.0. This may be a result of the library installation. From 
> long ago I remember that to install a library ldsomethingorother must be 
> run to amend a certain library file. Due to the live nature of my 
> installation this file whatever it is called might get overwritten.
> What is strange is that the other applications don't seem to have this 
> problem. Latency testsuitapp runs for example.
> 
> 
>> Your feedback is appreciated and helps improving things. Just a certain
>> part of your verbosity might have been avoidable by digging a bit deeper
>> and checking twice, no? :)
> :)
> Perhaps. We are all in a big hurry and there are lots of bits and pieces 
> with lots of documentation. Most of it not so bad actually but not 
> really unified. If I from my point of view were to comment, then I would 
> say that a single unified manual would have really made life a lot 
> easier. Then again I have a handicap with my distribution so it may have 
> been a lot simpler had I been working on a fixed installation instead of 
> a windows laptop which turns into linux when it has a usb stick in it. 
> On yet a third hand, I do think that a lot of people will only start 
> recompiling kernels when they enter this real-time story. A combined 
> really slow step-by-step instruction set of how to compile the kernel 
> with xenomai would make it a lot more accessible.
> 
> On even yet another hand (I'm counting with my feet by now) I don;t 
> really know what the objective of xenomai is. So far it appears to be an 
> impressively engineered product for which I don't doubt there should be 
> decent interest. Industry however is rather demanding when it comes to 
> development time (which is where my hurry comes from) and would 
> generally not go through the motions I am trying to rush through here. 
> We typically want a platform on which one can start developing for the 
> application ASAP. Now even though what I am doing is relatively speaking 
> the easy bit (compared to developing the rt-patches and drivers), there 
> are still too many man hours involved in just getting to the final 
> platform.
> 
> Apparently -from how I understand the documentation- the objective, or 
> one of the objectives of xenomai, is to make porting to it from other RT 
> operating systems as easy as possible. Having to struggle ones bottom 
> off to get xenomai installed and understanding how it works, would rub a 
> lot of the shine off this (I speak based only on the twinkels I have 
> seen so far :)) otherwise hyper-promising bit of software engineering.
> 
> Anyhow, must catch some quick sleep. Sorry again for all the questions. 
> Especially the stupid ones :)
> 
> Thanks for tolerating and responding to them.
> 
> Ah, one last thing, if you want to remind me about our contribution to 
> the documentation that would be good.

To speed up your development you could:

- take training courses on Embedded Linux and Xenomai.
- hire an expert.

Xenomai is free software and any active participation or even sponsoring 
is welcome to improve the software and documentation.

Wolfgang.

Re: [Fwd: Re: [Xenomai-help] hello xenomai world?]

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

Roland Tollenaar wrote:
> Hi,
>>> Invoke make like this: make /path to xeno-config/. Which is why I was
>>> going on about the config variables. I wil now try and find
>>> xeno-config if it exists and see how that works. On the other hand I
>>> don;t doubt that the application will compile. I need to find out what
>>> libraries to include for this particular one for the next steps. See
>>> later.
>>
>> Ack, my bad. The example makefiles do not assume /usr/xenomai (or,
>> alternatively, /usr/xenomai/bin/xeno-config) as default for XENO. Will
>> fix.
>>
>> Meanwhile try "make XENO=/usr/xenomai".
> Ok this does compile. however when running the resulting sigxcpu there
> is an error while loading the shared libraries. cannot find
> libnative.so.0. This may be a result of the library installation. From
> long ago I remember that to install a library ldsomethingorother must be
> run to amend a certain library file. Due to the live nature of my
> installation this file whatever it is called might get overwritten.
> What is strange is that the other applications don't seem to have this
> problem. Latency testsuitapp runs for example.
> 

Yeah, yet another beginners trap. The testsuite apps are built by
autotools stuff that automatically adds the lib folder as search path to
generated binaries. That currently doesn't happen to the examples,
although Xenomai libs are installed to a non-standard folder by default.
OK, I'll commit an enhanced version to SVN. Thanks for pointing out.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

The "product" Xenomai (was: [Xenomai-help] hello xenomai world?)

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4051 bytes --]

Roland Tollenaar wrote:
>> Your feedback is appreciated and helps improving things. Just a certain
>> part of your verbosity might have been avoidable by digging a bit deeper
>> and checking twice, no? :)
> :)
> Perhaps. We are all in a big hurry and there are lots of bits and pieces
> with lots of documentation. Most of it not so bad actually but not
> really unified. If I from my point of view were to comment, then I would
> say that a single unified manual would have really made life a lot
> easier. Then again I have a handicap with my distribution so it may have
> been a lot simpler had I been working on a fixed installation instead of
> a windows laptop which turns into linux when it has a usb stick in it.
> On yet a third hand, I do think that a lot of people will only start
> recompiling kernels when they enter this real-time story. A combined
> really slow step-by-step instruction set of how to compile the kernel
> with xenomai would make it a lot more accessible.

Well, compiling your own kernel is often one central key to the system
development. But you are right, it's an entry barrier to getting started
with real-time _application_ development. That's why I hope we will
manage to create and maintain some pre-compiled binary packages one day,
both for kernel and user space part, with standard PC as target. Yet
another item on the to-do list...

> 
> On even yet another hand (I'm counting with my feet by now) I don;t
> really know what the objective of xenomai is. So far it appears to be an
> impressively engineered product for which I don't doubt there should be

Xenomai is not a "product". It's an open source project, a developer and
user community.

> decent interest. Industry however is rather demanding when it comes to
> development time (which is where my hurry comes from) and would
> generally not go through the motions I am trying to rush through here.
> We typically want a platform on which one can start developing for the
> application ASAP. Now even though what I am doing is relatively speaking
> the easy bit (compared to developing the rt-patches and drivers), there
> are still too many man hours involved in just getting to the final
> platform.

Keep in mind: You haven't bought a box with some CD and a manual, nor
have you signed a support contract by downloading Xenomai. Anything you
can get from Xenomai must be contributed by someone else first,
including some quick-start-in-five-minutes package or support around it.
Should really become general knowledge about open source.

There are also commercial support solutions available, but that's not
what happens *here*, in this particular forum.

> 
> Apparently -from how I understand the documentation- the objective, or
> one of the objectives of xenomai, is to make porting to it from other RT
> operating systems as easy as possible. Having to struggle ones bottom
> off to get xenomai installed and understanding how it works, would rub a
> lot of the shine off this (I speak based only on the twinkels I have
> seen so far :)) otherwise hyper-promising bit of software engineering.

You can be sure that we know there are always things to improve to lower
the entrance barrier. But there are also more than enough other things
to do, and no one here has been hired to address this specific issue. So
we have to look how things get improved incrementally whenever time permits.

We are aware that helping beginners to get familiar with Xenomai is an
"investment" in potential future contributors (though the return rate is
yet improvable as well). That's also one reason why we are hanging
around here - even for free. :)

> 
> Anyhow, must catch some quick sleep. Sorry again for all the questions.
> Especially the stupid ones :)
> 
> Thanks for tolerating and responding to them.
> 
> Ah, one last thing, if you want to remind me about our contribution to
> the documentation that would be good.

Be careful, I typically actually do so! ;)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]