at91_enthus wrote:
> On Mon, Jan 24, 2011 at 10:54 PM, Gilles Chanteperdrix <
> [email protected]> wrote:
>
>> at91_enthus wrote:
>>> On Mon, Jan 24, 2011 at 10:28 PM, Gilles Chanteperdrix <
>>> [email protected]> wrote:
>>>
>>>> at91_enthus wrote:
>>>>> On Mon, Jan 24, 2011 at 10:16 PM, Gilles Chanteperdrix <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> at91_enthus wrote:
>>>>>>> On Mon, Jan 24, 2011 at 9:25 PM, Gilles Chanteperdrix <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> at91_enthus wrote:
>>>>>>>>> On Mon, Jan 24, 2011 at 8:41 PM, Gilles Chanteperdrix <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> at91_enthus wrote:
>>>>>>>>>>> Hi.
>>>>>>>>>>>
>>>>>>>>>>> I was testing Xenomai on my AT91SAM9G20-based board and tried to
>>>>>> adapt
>>>>>>>>>> the
>>>>>>>>>>> code found here:
>>>>>>>>>>>
>> http://www.armadeus.com/wiki/index.php?title=Xenomai:Blinking_LEDs.
>>>>>>>>>> By the way, this code is ridiculous. It creates a real-time task
>> to
>>>>>>>>>> write to some non real-time device, which makes the real-time task
>>>>>>>> useless.
>>>>>>>>> I know.
>>>>>>>> Yes, but this example is bad in many ways:
>>>>>>>> - first it uses xenomai api to create a real-time task, and uses
>> write
>>>>>>>> which causes the real-time task to switch to secondary domain;
>>>>>>>> - the Makefile does not use xeno-config, which have been the
>>>> recommended
>>>>>>>> way of getting the compiler flags since day 1;
>>>>>>>> - it nullifies SIGTERM and SIGINT, which is a dubious decision, and
>>>>>>>> could lead people to believe that they should do the same when using
>>>>>>>> Xenomai, whereas there is no such requirement.
>>>>>>>> - the pointers point to outdated version of the documentation.
>>>>>>>> - it uses runinfo/xeno-load, which are kind of outdated too, make
>>>> things
>>>>>>>> uselessly complicated, and in any case, tell you to type Ctrl-C to
>>>>>>>> interrupt the program, which is bound to fail if anything goes
>> wrong,
>>>>>>>> since SIGINT is neutralized in the program.
>>>>>>>>
>>>>>>>>> That's why I went to mmap().
>>>>>>>> That is not really the right solution either. I admit that for
>> driving
>>>>>>>> leds, it may be a bit overkill, but anyway, what you should do is
>>>> write
>>>>>>>> an RTDM driver for driving the leds. Keeping the driver separated
>> from
>>>>>>>> the application will allow the same program to run on other
>> platforms
>>>>>>>> where driving the LEDS is done differently without changing much of
>>>> the
>>>>>>>> application code. In other word, the application/driver separation
>> is
>>>> a
>>>>>>>> sane one.
>>>>>>>>
>>>>>>>> Anyway, mmap should work.
>>>>>>>>
>>>>>>>> (I chose that sample code because, for
>>>>>>>>> now, I am only learning to use basic functions)
>>>>>>>>>> Wrong test here. Should be "if (aic_base == MAP_FAILED)"
>>>>>>>>> Indeed, my program fails miserably when I check the mapping of AIC,
>>>> not
>>>>>>>>> PIOB's. And yet, I just can't figure why in the non-Xenomai code,
>> AIC
>>>>>>>>> mmap-ing works fine.
>>>>>>>> Well errno might give you a clue. Do you have FCSE enabled?
>>>>>>>>
>>>>>>>> Regards.
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>> Gilles.
>>>>>>> FCSE is enabled. errno returns 22 (invalid argument).
>>>>>> best effort or guaranteed?
>>>>> Best effort
>>>>>
>>>>>
>>>>>> Please activate FCSE messages.
>>>>> ... compiling new kernel
>>>>>
>>>>>
>>>>>> How big is
>>>>>> MAP_SIZE?
>>>>>>
>>>>>>
>>>>> 4096
>>>> Ok. Could you post your full kernel configuration, as well as the full
>>>> program?
>>>>
>>> I put the .config and the code in the attachments.
>>
>
>> If you remove all the native skin stuff, only keep main and
>> open_controller, do not link with the native library, you can confirm
>> that this same program runs without trouble?
>>
>
> Without Xenomai related stuff, it runs OK.
You sure of that? The exact same code, with the same kernel, with the
mlockall?
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
