at91_enthus wrote:
> On Mon, Jan 24, 2011 at 11:02 PM, Gilles Chanteperdrix <
> [email protected]> wrote:
>
>> 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.
>>
>
> Oh. I assumed without mlockall (it wasn't part of my original code).
> Now, I placed mlockall in my original code (right before open_controller())
> and the pin gets toggled according to my scope.
Ok. Show me the Makefile then. And the code which works. Including the
value of the defines please (not all of them, only those the program
uses for open_controller).
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
