[Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

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

Hi All,

I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when
CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux serial
write then read serial program does not work.

If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.

Any ideas why?????


Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
CC      kernel/xenomai/nucleus/synch.o
kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread':
kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
function 'xnthread_get_rescnt'
kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
function 'xnshadow_send_sig'

I had to go in and make the code for that option be for it always false.

Glen
-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"


[-- Attachment #2: Type: text/html, Size: 2200 bytes --]

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Philippe Gerum]

On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
> Hi All,
>
> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when
> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux
> serial write then read serial program does not work.
>
> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.
>
> Any ideas why?????
>

A possible explanation would be that your application links with the 
Xenomai POSIX lib (libpthread_rt), albeit it should not.

With pervasive support disabled, any routing from the overloaded POSIX 
I/O calls to the Xenomai kernel would then fail.

If so, you should not link against the Xenomai libs if you need no -rt 
service, or prevent symbol wrapping only for the POSIX I/O calls by 
prefixing them by __real_* if you want Xenomai-enabled POSIX services 
except the I/O support.

See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai

>
> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
> CC kernel/xenomai/nucleus/synch.o
> kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread':
> kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
> function 'xnthread_get_rescnt'
> kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
> function 'xnshadow_send_sig'
>
> I had to go in and make the code for that option befor it always false.
>

http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a788b762b5cf662b1d4108


> Glen
> --
> Glen Wernersbach
> President & CTO
>
> Jetsoft Development Co.
> 629 Old St Rt. 74 – Suite 210
> Cincinnati, Oh 45244
> Custom Programming Web Site: www.jetsoftdev.com
> Retail Products Web Site: www.scanhelp.com
> Phone: 513-528-6660
> Fax: 513-528-3470
> Cell 513-240-9929
> ----
> Partner for Software Technology
> Jacobs Automation
> 2365 Progress Drive
> Hebron, KY 41048
> (513) 297-7550
> ----
> "Support Dyslexia Research"
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 
Philippe.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

I don't think this is it directly.

This program was made on the same kernel prior to patching it with Xeno.

It should still run like any other linux program.




On 3/20/12 9:44 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:

> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>> Hi All,
>> 
>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when
>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux
>> serial write then read serial program does not work.
>> 
>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.
>> 
>> Any ideas why?????
>> 
> 
> A possible explanation would be that your application links with the
> Xenomai POSIX lib (libpthread_rt), albeit it should not.
> 
> With pervasive support disabled, any routing from the overloaded POSIX
> I/O calls to the Xenomai kernel would then fail.
> 
> If so, you should not link against the Xenomai libs if you need no -rt
> service, or prevent symbol wrapping only for the POSIX I/O calls by
> prefixing them by __real_* if you want Xenomai-enabled POSIX services
> except the I/O support.
> 
> See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
> 
>> 
>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
>> CC kernel/xenomai/nucleus/synch.o
>> kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread':
>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
>> function 'xnthread_get_rescnt'
>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
>> function 'xnshadow_send_sig'
>> 
>> I had to go in and make the code for that option befor it always false.
>> 
> 
> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a788b76
> 2b5cf662b1d4108
> 
> 
>> Glen
>> --
>> Glen Wernersbach
>> President & CTO
>> 
>> Jetsoft Development Co.
>> 629 Old St Rt. 74 ­ Suite 210
>> Cincinnati, Oh 45244
>> Custom Programming Web Site: www.jetsoftdev.com
>> Retail Products Web Site: www.scanhelp.com
>> Phone: 513-528-6660
>> Fax: 513-528-3470
>> Cell 513-240-9929
>> ----
>> Partner for Software Technology
>> Jacobs Automation
>> 2365 Progress Drive
>> Hebron, KY 41048
>> (513) 297-7550
>> ----
>> "Support Dyslexia Research"
>> 
>> 
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Philippe Gerum]

On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
> I don't think this is it directly.
>
> This program was made on the same kernel prior to patching it with Xeno.
>
> It should still run like any other linux program.

- what does "program not working" mean in your case? Any errno return we 
could interpret? Any strace output?

- what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on?


>
>
>
>
> On 3/20/12 9:44 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>
>> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>>> Hi All,
>>>
>>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when
>>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux
>>> serial write then read serial program does not work.
>>>
>>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.
>>>
>>> Any ideas why?????
>>>
>>
>> A possible explanation would be that your application links with the
>> Xenomai POSIX lib (libpthread_rt), albeit it should not.
>>
>> With pervasive support disabled, any routing from the overloaded POSIX
>> I/O calls to the Xenomai kernel would then fail.
>>
>> If so, you should not link against the Xenomai libs if you need no -rt
>> service, or prevent symbol wrapping only for the POSIX I/O calls by
>> prefixing them by __real_* if you want Xenomai-enabled POSIX services
>> except the I/O support.
>>
>> See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
>>
>>>
>>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
>>> CC kernel/xenomai/nucleus/synch.o
>>> kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread':
>>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
>>> function 'xnthread_get_rescnt'
>>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
>>> function 'xnshadow_send_sig'
>>>
>>> I had to go in and make the code for that option befor it always false.
>>>
>>
>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a788b76
>> 2b5cf662b1d4108
>>
>>
>>> Glen
>>> --
>>> Glen Wernersbach
>>> President&  CTO
>>>
>>> Jetsoft Development Co.
>>> 629 Old St Rt. 74 ­ Suite 210
>>> Cincinnati, Oh 45244
>>> Custom Programming Web Site: www.jetsoftdev.com
>>> Retail Products Web Site: www.scanhelp.com
>>> Phone: 513-528-6660
>>> Fax: 513-528-3470
>>> Cell 513-240-9929
>>> ----
>>> Partner for Software Technology
>>> Jacobs Automation
>>> 2365 Progress Drive
>>> Hebron, KY 41048
>>> (513) 297-7550
>>> ----
>>> "Support Dyslexia Research"
>>>
>>>
>>> _______________________________________________
>>> Xenomai-help mailing list
>>> Xenomai-help@domain.hid
>>> https://mail.gna.org/listinfo/xenomai-help
>>
>


-- 
Philippe.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

I went through and disabled everything in xeno except
CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it works.

Take that option out at anytime it works.

My program basic writes a few characters a serial port and then reads them
back in from the same port. I have a loop back cable connected to the port.

It writes the data but waits forever to read them back in

>From my tests, it appears that the termois tcsetaddr settings is not getting
set when I call it when this option is on.






On 3/20/12 9:57 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:

> On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
>> I don't think this is it directly.
>> 
>> This program was made on the same kernel prior to patching it with Xeno.
>> 
>> It should still run like any other linux program.
> 
> - what does "program not working" mean in your case? Any errno return we
> could interpret? Any strace output?
> 
> - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on?
> 
> 
>> 
>> 
>> 
>> 
>> On 3/20/12 9:44 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>> 
>>> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>>>> Hi All,
>>>> 
>>>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when
>>>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux
>>>> serial write then read serial program does not work.
>>>> 
>>>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.
>>>> 
>>>> Any ideas why?????
>>>> 
>>> 
>>> A possible explanation would be that your application links with the
>>> Xenomai POSIX lib (libpthread_rt), albeit it should not.
>>> 
>>> With pervasive support disabled, any routing from the overloaded POSIX
>>> I/O calls to the Xenomai kernel would then fail.
>>> 
>>> If so, you should not link against the Xenomai libs if you need no -rt
>>> service, or prevent symbol wrapping only for the POSIX I/O calls by
>>> prefixing them by __real_* if you want Xenomai-enabled POSIX services
>>> except the I/O support.
>>> 
>>> See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
>>> 
>>>> 
>>>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
>>>> CC kernel/xenomai/nucleus/synch.o
>>>> kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread':
>>>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
>>>> function 'xnthread_get_rescnt'
>>>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
>>>> function 'xnshadow_send_sig'
>>>> 
>>>> I had to go in and make the code for that option befor it always false.
>>>> 
>>> 
>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a788b
>>> 76
>>> 2b5cf662b1d4108
>>> 
>>> 
>>>> Glen
>>>> --
>>>> Glen Wernersbach
>>>> President&  CTO
>>>> 
>>>> Jetsoft Development Co.
>>>> 629 Old St Rt. 74 ­ Suite 210
>>>> Cincinnati, Oh 45244
>>>> Custom Programming Web Site: www.jetsoftdev.com
>>>> Retail Products Web Site: www.scanhelp.com
>>>> Phone: 513-528-6660
>>>> Fax: 513-528-3470
>>>> Cell 513-240-9929
>>>> ----
>>>> Partner for Software Technology
>>>> Jacobs Automation
>>>> 2365 Progress Drive
>>>> Hebron, KY 41048
>>>> (513) 297-7550
>>>> ----
>>>> "Support Dyslexia Research"
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Xenomai-help mailing list
>>>> Xenomai-help@domain.hid
>>>> https://mail.gna.org/listinfo/xenomai-help
>>> 
>> 
> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Philippe Gerum]

On 03/20/2012 03:07 PM, Glen Wernersbach wrote:
> I went through and disabled everything in xeno except
> CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it works.
>
> Take that option out at anytime it works.
>
> My program basic writes a few characters a serial port and then reads them
> back in from the same port. I have a loop back cable connected to the port.
>
> It writes the data but waits forever to read them back in

Ok, so what about answering the questions below?

>
>> From my tests, it appears that the termois tcsetaddr settings is not getting
> set when I call it when this option is on.
>
>
>
>
>
>
> On 3/20/12 9:57 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>
>> On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
>>> I don't think this is it directly.
>>>
>>> This program was made on the same kernel prior to patching it with Xeno.
>>>
>>> It should still run like any other linux program.
>>
>> - what does "program not working" mean in your case? Any errno return we
>> could interpret? Any strace output?
>>
>> - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on?
>>
>>
>>>
>>>
>>>
>>>
>>> On 3/20/12 9:44 AM, "Philippe Gerum"<rpm@xenomai.org>   wrote:
>>>
>>>> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>>>>> Hi All,
>>>>>
>>>>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when
>>>>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux
>>>>> serial write then read serial program does not work.
>>>>>
>>>>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.
>>>>>
>>>>> Any ideas why?????
>>>>>
>>>>
>>>> A possible explanation would be that your application links with the
>>>> Xenomai POSIX lib (libpthread_rt), albeit it should not.
>>>>
>>>> With pervasive support disabled, any routing from the overloaded POSIX
>>>> I/O calls to the Xenomai kernel would then fail.
>>>>
>>>> If so, you should not link against the Xenomai libs if you need no -rt
>>>> service, or prevent symbol wrapping only for the POSIX I/O calls by
>>>> prefixing them by __real_* if you want Xenomai-enabled POSIX services
>>>> except the I/O support.
>>>>
>>>> See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
>>>>
>>>>>
>>>>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
>>>>> CC kernel/xenomai/nucleus/synch.o
>>>>> kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread':
>>>>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
>>>>> function 'xnthread_get_rescnt'
>>>>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
>>>>> function 'xnshadow_send_sig'
>>>>>
>>>>> I had to go in and make the code for that option befor it always false.
>>>>>
>>>>
>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a788b
>>>> 76
>>>> 2b5cf662b1d4108
>>>>
>>>>
>>>>> Glen
>>>>> --
>>>>> Glen Wernersbach
>>>>> President&   CTO
>>>>>
>>>>> Jetsoft Development Co.
>>>>> 629 Old St Rt. 74 ­ Suite 210
>>>>> Cincinnati, Oh 45244
>>>>> Custom Programming Web Site: www.jetsoftdev.com
>>>>> Retail Products Web Site: www.scanhelp.com
>>>>> Phone: 513-528-6660
>>>>> Fax: 513-528-3470
>>>>> Cell 513-240-9929
>>>>> ----
>>>>> Partner for Software Technology
>>>>> Jacobs Automation
>>>>> 2365 Progress Drive
>>>>> Hebron, KY 41048
>>>>> (513) 297-7550
>>>>> ----
>>>>> "Support Dyslexia Research"
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xenomai-help mailing list
>>>>> Xenomai-help@domain.hid
>>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>
>>>
>>
>


-- 
Philippe.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Philippe Gerum]

On 03/20/2012 03:07 PM, Glen Wernersbach wrote:
> I went through and disabled everything in xeno except
> CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it works.
>
> Take that option out at anytime it works.
>
> My program basic writes a few characters a serial port and then reads them
> back in from the same port. I have a loop back cable connected to the port.
>
> It writes the data but waits forever to read them back in
>
>> From my tests, it appears that the termois tcsetaddr settings is not getting
> set when I call it when this option is on.

Can you strace your app when it runs, please?

>
>
>
>
>
>
> On 3/20/12 9:57 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>
>> On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
>>> I don't think this is it directly.
>>>
>>> This program was made on the same kernel prior to patching it with Xeno.
>>>
>>> It should still run like any other linux program.
>>
>> - what does "program not working" mean in your case? Any errno return we
>> could interpret? Any strace output?
>>
>> - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on?
>>
>>
>>>
>>>
>>>
>>>
>>> On 3/20/12 9:44 AM, "Philippe Gerum"<rpm@xenomai.org>   wrote:
>>>
>>>> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>>>>> Hi All,
>>>>>
>>>>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when
>>>>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux
>>>>> serial write then read serial program does not work.
>>>>>
>>>>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.
>>>>>
>>>>> Any ideas why?????
>>>>>
>>>>
>>>> A possible explanation would be that your application links with the
>>>> Xenomai POSIX lib (libpthread_rt), albeit it should not.
>>>>
>>>> With pervasive support disabled, any routing from the overloaded POSIX
>>>> I/O calls to the Xenomai kernel would then fail.
>>>>
>>>> If so, you should not link against the Xenomai libs if you need no -rt
>>>> service, or prevent symbol wrapping only for the POSIX I/O calls by
>>>> prefixing them by __real_* if you want Xenomai-enabled POSIX services
>>>> except the I/O support.
>>>>
>>>> See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
>>>>
>>>>>
>>>>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
>>>>> CC kernel/xenomai/nucleus/synch.o
>>>>> kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread':
>>>>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
>>>>> function 'xnthread_get_rescnt'
>>>>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
>>>>> function 'xnshadow_send_sig'
>>>>>
>>>>> I had to go in and make the code for that option befor it always false.
>>>>>
>>>>
>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a788b
>>>> 76
>>>> 2b5cf662b1d4108
>>>>
>>>>
>>>>> Glen
>>>>> --
>>>>> Glen Wernersbach
>>>>> President&   CTO
>>>>>
>>>>> Jetsoft Development Co.
>>>>> 629 Old St Rt. 74 ­ Suite 210
>>>>> Cincinnati, Oh 45244
>>>>> Custom Programming Web Site: www.jetsoftdev.com
>>>>> Retail Products Web Site: www.scanhelp.com
>>>>> Phone: 513-528-6660
>>>>> Fax: 513-528-3470
>>>>> Cell 513-240-9929
>>>>> ----
>>>>> Partner for Software Technology
>>>>> Jacobs Automation
>>>>> 2365 Progress Drive
>>>>> Hebron, KY 41048
>>>>> (513) 297-7550
>>>>> ----
>>>>> "Support Dyslexia Research"
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xenomai-help mailing list
>>>>> Xenomai-help@domain.hid
>>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>
>>>
>>
>


-- 
Philippe.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Philippe Gerum]

On 03/20/2012 03:17 PM, Philippe Gerum wrote:
> On 03/20/2012 03:07 PM, Glen Wernersbach wrote:
>> I went through and disabled everything in xeno except
>> CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it
>> works.
>>
>> Take that option out at anytime it works.
>>
>> My program basic writes a few characters a serial port and then reads
>> them
>> back in from the same port. I have a loop back cable connected to the
>> port.
>>
>> It writes the data but waits forever to read them back in
>>
>>> From my tests, it appears that the termois tcsetaddr settings is not
>>> getting
>> set when I call it when this option is on.
>
> Can you strace your app when it runs, please?

The interrupt pipeline release number would help as well 
(/proc/xenomai/hal).

>
>>
>>
>>
>>
>>
>>
>> On 3/20/12 9:57 AM, "Philippe Gerum"<rpm@xenomai.org> wrote:
>>
>>> On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
>>>> I don't think this is it directly.
>>>>
>>>> This program was made on the same kernel prior to patching it with
>>>> Xeno.
>>>>
>>>> It should still run like any other linux program.
>>>
>>> - what does "program not working" mean in your case? Any errno return we
>>> could interpret? Any strace output?
>>>
>>> - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on?
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 3/20/12 9:44 AM, "Philippe Gerum"<rpm@xenomai.org> wrote:
>>>>
>>>>> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that
>>>>>> when
>>>>>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux
>>>>>> serial write then read serial program does not work.
>>>>>>
>>>>>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.
>>>>>>
>>>>>> Any ideas why?????
>>>>>>
>>>>>
>>>>> A possible explanation would be that your application links with the
>>>>> Xenomai POSIX lib (libpthread_rt), albeit it should not.
>>>>>
>>>>> With pervasive support disabled, any routing from the overloaded POSIX
>>>>> I/O calls to the Xenomai kernel would then fail.
>>>>>
>>>>> If so, you should not link against the Xenomai libs if you need no -rt
>>>>> service, or prevent symbol wrapping only for the POSIX I/O calls by
>>>>> prefixing them by __real_* if you want Xenomai-enabled POSIX services
>>>>> except the I/O support.
>>>>>
>>>>> See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
>>>>>
>>>>>>
>>>>>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
>>>>>> CC kernel/xenomai/nucleus/synch.o
>>>>>> kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread':
>>>>>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
>>>>>> function 'xnthread_get_rescnt'
>>>>>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
>>>>>> function 'xnshadow_send_sig'
>>>>>>
>>>>>> I had to go in and make the code for that option befor it always
>>>>>> false.
>>>>>>
>>>>>
>>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a788b
>>>>>
>>>>> 76
>>>>> 2b5cf662b1d4108
>>>>>
>>>>>
>>>>>> Glen
>>>>>> --
>>>>>> Glen Wernersbach
>>>>>> President& CTO
>>>>>>
>>>>>> Jetsoft Development Co.
>>>>>> 629 Old St Rt. 74 ­ Suite 210
>>>>>> Cincinnati, Oh 45244
>>>>>> Custom Programming Web Site: www.jetsoftdev.com
>>>>>> Retail Products Web Site: www.scanhelp.com
>>>>>> Phone: 513-528-6660
>>>>>> Fax: 513-528-3470
>>>>>> Cell 513-240-9929
>>>>>> ----
>>>>>> Partner for Software Technology
>>>>>> Jacobs Automation
>>>>>> 2365 Progress Drive
>>>>>> Hebron, KY 41048
>>>>>> (513) 297-7550
>>>>>> ----
>>>>>> "Support Dyslexia Research"
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xenomai-help mailing list
>>>>>> Xenomai-help@domain.hid
>>>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>>
>>>>
>>>
>>
>
>


-- 
Philippe.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

Working on the Strace.

I don't have the /proc/xenomai/hal file??

Again. Nothing I am running is xeno. Its just a xeno patched kernel.




On 3/20/12 10:31 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:

> On 03/20/2012 03:17 PM, Philippe Gerum wrote:
>> On 03/20/2012 03:07 PM, Glen Wernersbach wrote:
>>> I went through and disabled everything in xeno except
>>> CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it
>>> works.
>>> 
>>> Take that option out at anytime it works.
>>> 
>>> My program basic writes a few characters a serial port and then reads
>>> them
>>> back in from the same port. I have a loop back cable connected to the
>>> port.
>>> 
>>> It writes the data but waits forever to read them back in
>>> 
>>>> From my tests, it appears that the termois tcsetaddr settings is not
>>>> getting
>>> set when I call it when this option is on.
>> 
>> Can you strace your app when it runs, please?
> 
> The interrupt pipeline release number would help as well
> (/proc/xenomai/hal).
> 
>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 3/20/12 9:57 AM, "Philippe Gerum"<rpm@xenomai.org> wrote:
>>> 
>>>> On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
>>>>> I don't think this is it directly.
>>>>> 
>>>>> This program was made on the same kernel prior to patching it with
>>>>> Xeno.
>>>>> 
>>>>> It should still run like any other linux program.
>>>> 
>>>> - what does "program not working" mean in your case? Any errno return we
>>>> could interpret? Any strace output?
>>>> 
>>>> - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on?
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 3/20/12 9:44 AM, "Philippe Gerum"<rpm@xenomai.org> wrote:
>>>>> 
>>>>>> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that
>>>>>>> when
>>>>>>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux
>>>>>>> serial write then read serial program does not work.
>>>>>>> 
>>>>>>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.
>>>>>>> 
>>>>>>> Any ideas why?????
>>>>>>> 
>>>>>> 
>>>>>> A possible explanation would be that your application links with the
>>>>>> Xenomai POSIX lib (libpthread_rt), albeit it should not.
>>>>>> 
>>>>>> With pervasive support disabled, any routing from the overloaded POSIX
>>>>>> I/O calls to the Xenomai kernel would then fail.
>>>>>> 
>>>>>> If so, you should not link against the Xenomai libs if you need no -rt
>>>>>> service, or prevent symbol wrapping only for the POSIX I/O calls by
>>>>>> prefixing them by __real_* if you want Xenomai-enabled POSIX services
>>>>>> except the I/O support.
>>>>>> 
>>>>>> See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
>>>>>> 
>>>>>>> 
>>>>>>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
>>>>>>> CC kernel/xenomai/nucleus/synch.o
>>>>>>> kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread':
>>>>>>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
>>>>>>> function 'xnthread_get_rescnt'
>>>>>>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
>>>>>>> function 'xnshadow_send_sig'
>>>>>>> 
>>>>>>> I had to go in and make the code for that option befor it always
>>>>>>> false.
>>>>>>> 
>>>>>> 
>>>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a7
>>>>>> 88b
>>>>>> 
>>>>>> 76
>>>>>> 2b5cf662b1d4108
>>>>>> 
>>>>>> 
>>>>>>> Glen
>>>>>>> --
>>>>>>> Glen Wernersbach
>>>>>>> President& CTO
>>>>>>> 
>>>>>>> Jetsoft Development Co.
>>>>>>> 629 Old St Rt. 74 ­ Suite 210
>>>>>>> Cincinnati, Oh 45244
>>>>>>> Custom Programming Web Site: www.jetsoftdev.com
>>>>>>> Retail Products Web Site: www.scanhelp.com
>>>>>>> Phone: 513-528-6660
>>>>>>> Fax: 513-528-3470
>>>>>>> Cell 513-240-9929
>>>>>>> ----
>>>>>>> Partner for Software Technology
>>>>>>> Jacobs Automation
>>>>>>> 2365 Progress Drive
>>>>>>> Hebron, KY 41048
>>>>>>> (513) 297-7550
>>>>>>> ----
>>>>>>> "Support Dyslexia Research"
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Xenomai-help mailing list
>>>>>>> Xenomai-help@domain.hid
>>>>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 
> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Philippe Gerum]

On 03/20/2012 03:34 PM, Glen Wernersbach wrote:
> Working on the Strace.
>
> I don't have the /proc/xenomai/hal file??

/proc/ipipe/version then.

>
> Again. Nothing I am running is xeno. Its just a xeno patched kernel.
>

Ok, but you do have the Xenomai co-kernel enabled in your kernel build, 
and the interrupt pipeline is enabled as well, right?

>
>
>
> On 3/20/12 10:31 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>
>> On 03/20/2012 03:17 PM, Philippe Gerum wrote:
>>> On 03/20/2012 03:07 PM, Glen Wernersbach wrote:
>>>> I went through and disabled everything in xeno except
>>>> CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it
>>>> works.
>>>>
>>>> Take that option out at anytime it works.
>>>>
>>>> My program basic writes a few characters a serial port and then reads
>>>> them
>>>> back in from the same port. I have a loop back cable connected to the
>>>> port.
>>>>
>>>> It writes the data but waits forever to read them back in
>>>>
>>>>>  From my tests, it appears that the termois tcsetaddr settings is not
>>>>> getting
>>>> set when I call it when this option is on.
>>>
>>> Can you strace your app when it runs, please?
>>
>> The interrupt pipeline release number would help as well
>> (/proc/xenomai/hal).
>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 3/20/12 9:57 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>>>>
>>>>> On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
>>>>>> I don't think this is it directly.
>>>>>>
>>>>>> This program was made on the same kernel prior to patching it with
>>>>>> Xeno.
>>>>>>
>>>>>> It should still run like any other linux program.
>>>>>
>>>>> - what does "program not working" mean in your case? Any errno return we
>>>>> could interpret? Any strace output?
>>>>>
>>>>> - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on?
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/20/12 9:44 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>>>>>>
>>>>>>> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that
>>>>>>>> when
>>>>>>>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux
>>>>>>>> serial write then read serial program does not work.
>>>>>>>>
>>>>>>>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.
>>>>>>>>
>>>>>>>> Any ideas why?????
>>>>>>>>
>>>>>>>
>>>>>>> A possible explanation would be that your application links with the
>>>>>>> Xenomai POSIX lib (libpthread_rt), albeit it should not.
>>>>>>>
>>>>>>> With pervasive support disabled, any routing from the overloaded POSIX
>>>>>>> I/O calls to the Xenomai kernel would then fail.
>>>>>>>
>>>>>>> If so, you should not link against the Xenomai libs if you need no -rt
>>>>>>> service, or prevent symbol wrapping only for the POSIX I/O calls by
>>>>>>> prefixing them by __real_* if you want Xenomai-enabled POSIX services
>>>>>>> except the I/O support.
>>>>>>>
>>>>>>> See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
>>>>>>>
>>>>>>>>
>>>>>>>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
>>>>>>>> CC kernel/xenomai/nucleus/synch.o
>>>>>>>> kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread':
>>>>>>>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
>>>>>>>> function 'xnthread_get_rescnt'
>>>>>>>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
>>>>>>>> function 'xnshadow_send_sig'
>>>>>>>>
>>>>>>>> I had to go in and make the code for that option befor it always
>>>>>>>> false.
>>>>>>>>
>>>>>>>
>>>>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a7
>>>>>>> 88b
>>>>>>>
>>>>>>> 76
>>>>>>> 2b5cf662b1d4108
>>>>>>>
>>>>>>>
>>>>>>>> Glen
>>>>>>>> --
>>>>>>>> Glen Wernersbach
>>>>>>>> President&  CTO
>>>>>>>>
>>>>>>>> Jetsoft Development Co.
>>>>>>>> 629 Old St Rt. 74 ­ Suite 210
>>>>>>>> Cincinnati, Oh 45244
>>>>>>>> Custom Programming Web Site: www.jetsoftdev.com
>>>>>>>> Retail Products Web Site: www.scanhelp.com
>>>>>>>> Phone: 513-528-6660
>>>>>>>> Fax: 513-528-3470
>>>>>>>> Cell 513-240-9929
>>>>>>>> ----
>>>>>>>> Partner for Software Technology
>>>>>>>> Jacobs Automation
>>>>>>>> 2365 Progress Drive
>>>>>>>> Hebron, KY 41048
>>>>>>>> (513) 297-7550
>>>>>>>> ----
>>>>>>>> "Support Dyslexia Research"
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Xenomai-help mailing list
>>>>>>>> Xenomai-help@domain.hid
>>>>>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>


-- 
Philippe.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

Ipipe version:
1.13-05


Yes, I do have the co kernel and interrupt pipeline enabled


On 3/20/12 10:47 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:

> On 03/20/2012 03:34 PM, Glen Wernersbach wrote:
>> Working on the Strace.
>> 
>> I don't have the /proc/xenomai/hal file??
> 
> /proc/ipipe/version then.
> 
>> 
>> Again. Nothing I am running is xeno. Its just a xeno patched kernel.
>> 
> 
> Ok, but you do have the Xenomai co-kernel enabled in your kernel build,
> and the interrupt pipeline is enabled as well, right?
> 
>> 
>> 
>> 
>> On 3/20/12 10:31 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>> 
>>> On 03/20/2012 03:17 PM, Philippe Gerum wrote:
>>>> On 03/20/2012 03:07 PM, Glen Wernersbach wrote:
>>>>> I went through and disabled everything in xeno except
>>>>> CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it
>>>>> works.
>>>>> 
>>>>> Take that option out at anytime it works.
>>>>> 
>>>>> My program basic writes a few characters a serial port and then reads
>>>>> them
>>>>> back in from the same port. I have a loop back cable connected to the
>>>>> port.
>>>>> 
>>>>> It writes the data but waits forever to read them back in
>>>>> 
>>>>>>  From my tests, it appears that the termois tcsetaddr settings is not
>>>>>> getting
>>>>> set when I call it when this option is on.
>>>> 
>>>> Can you strace your app when it runs, please?
>>> 
>>> The interrupt pipeline release number would help as well
>>> (/proc/xenomai/hal).
>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 3/20/12 9:57 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>>>>> 
>>>>>> On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
>>>>>>> I don't think this is it directly.
>>>>>>> 
>>>>>>> This program was made on the same kernel prior to patching it with
>>>>>>> Xeno.
>>>>>>> 
>>>>>>> It should still run like any other linux program.
>>>>>> 
>>>>>> - what does "program not working" mean in your case? Any errno return we
>>>>>> could interpret? Any strace output?
>>>>>> 
>>>>>> - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on?
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 3/20/12 9:44 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>>>>>>> 
>>>>>>>> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>>>>>>>>> Hi All,
>>>>>>>>> 
>>>>>>>>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that
>>>>>>>>> when
>>>>>>>>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux
>>>>>>>>> serial write then read serial program does not work.
>>>>>>>>> 
>>>>>>>>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.
>>>>>>>>> 
>>>>>>>>> Any ideas why?????
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> A possible explanation would be that your application links with the
>>>>>>>> Xenomai POSIX lib (libpthread_rt), albeit it should not.
>>>>>>>> 
>>>>>>>> With pervasive support disabled, any routing from the overloaded POSIX
>>>>>>>> I/O calls to the Xenomai kernel would then fail.
>>>>>>>> 
>>>>>>>> If so, you should not link against the Xenomai libs if you need no -rt
>>>>>>>> service, or prevent symbol wrapping only for the POSIX I/O calls by
>>>>>>>> prefixing them by __real_* if you want Xenomai-enabled POSIX services
>>>>>>>> except the I/O support.
>>>>>>>> 
>>>>>>>> See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
>>>>>>>>> CC kernel/xenomai/nucleus/synch.o
>>>>>>>>> kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread':
>>>>>>>>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
>>>>>>>>> function 'xnthread_get_rescnt'
>>>>>>>>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
>>>>>>>>> function 'xnshadow_send_sig'
>>>>>>>>> 
>>>>>>>>> I had to go in and make the code for that option befor it always
>>>>>>>>> false.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107
>>>>>>>> a7
>>>>>>>> 88b
>>>>>>>> 
>>>>>>>> 76
>>>>>>>> 2b5cf662b1d4108
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> Glen
>>>>>>>>> --
>>>>>>>>> Glen Wernersbach
>>>>>>>>> President&  CTO
>>>>>>>>> 
>>>>>>>>> Jetsoft Development Co.
>>>>>>>>> 629 Old St Rt. 74 ­ Suite 210
>>>>>>>>> Cincinnati, Oh 45244
>>>>>>>>> Custom Programming Web Site: www.jetsoftdev.com
>>>>>>>>> Retail Products Web Site: www.scanhelp.com
>>>>>>>>> Phone: 513-528-6660
>>>>>>>>> Fax: 513-528-3470
>>>>>>>>> Cell 513-240-9929
>>>>>>>>> ----
>>>>>>>>> Partner for Software Technology
>>>>>>>>> Jacobs Automation
>>>>>>>>> 2365 Progress Drive
>>>>>>>>> Hebron, KY 41048
>>>>>>>>> (513) 297-7550
>>>>>>>>> ----
>>>>>>>>> "Support Dyslexia Research"
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> Xenomai-help mailing list
>>>>>>>>> Xenomai-help@domain.hid
>>>>>>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Philippe Gerum]

On 03/20/2012 03:53 PM, Glen Wernersbach wrote:
> Ipipe version:
> 1.13-05
>
>
> Yes, I do have the co kernel and interrupt pipeline enabled

ldd <your-serial-app> ?

>
>
> On 3/20/12 10:47 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>
>> On 03/20/2012 03:34 PM, Glen Wernersbach wrote:
>>> Working on the Strace.
>>>
>>> I don't have the /proc/xenomai/hal file??
>>
>> /proc/ipipe/version then.
>>
>>>
>>> Again. Nothing I am running is xeno. Its just a xeno patched kernel.
>>>
>>
>> Ok, but you do have the Xenomai co-kernel enabled in your kernel build,
>> and the interrupt pipeline is enabled as well, right?
>>
>>>
>>>
>>>
>>> On 3/20/12 10:31 AM, "Philippe Gerum"<rpm@xenomai.org>   wrote:
>>>
>>>> On 03/20/2012 03:17 PM, Philippe Gerum wrote:
>>>>> On 03/20/2012 03:07 PM, Glen Wernersbach wrote:
>>>>>> I went through and disabled everything in xeno except
>>>>>> CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it
>>>>>> works.
>>>>>>
>>>>>> Take that option out at anytime it works.
>>>>>>
>>>>>> My program basic writes a few characters a serial port and then reads
>>>>>> them
>>>>>> back in from the same port. I have a loop back cable connected to the
>>>>>> port.
>>>>>>
>>>>>> It writes the data but waits forever to read them back in
>>>>>>
>>>>>>>    From my tests, it appears that the termois tcsetaddr settings is not
>>>>>>> getting
>>>>>> set when I call it when this option is on.
>>>>>
>>>>> Can you strace your app when it runs, please?
>>>>
>>>> The interrupt pipeline release number would help as well
>>>> (/proc/xenomai/hal).
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/20/12 9:57 AM, "Philippe Gerum"<rpm@xenomai.org>   wrote:
>>>>>>
>>>>>>> On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
>>>>>>>> I don't think this is it directly.
>>>>>>>>
>>>>>>>> This program was made on the same kernel prior to patching it with
>>>>>>>> Xeno.
>>>>>>>>
>>>>>>>> It should still run like any other linux program.
>>>>>>>
>>>>>>> - what does "program not working" mean in your case? Any errno return we
>>>>>>> could interpret? Any strace output?
>>>>>>>
>>>>>>> - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on?
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/20/12 9:44 AM, "Philippe Gerum"<rpm@xenomai.org>   wrote:
>>>>>>>>
>>>>>>>>> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that
>>>>>>>>>> when
>>>>>>>>>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux
>>>>>>>>>> serial write then read serial program does not work.
>>>>>>>>>>
>>>>>>>>>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.
>>>>>>>>>>
>>>>>>>>>> Any ideas why?????
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A possible explanation would be that your application links with the
>>>>>>>>> Xenomai POSIX lib (libpthread_rt), albeit it should not.
>>>>>>>>>
>>>>>>>>> With pervasive support disabled, any routing from the overloaded POSIX
>>>>>>>>> I/O calls to the Xenomai kernel would then fail.
>>>>>>>>>
>>>>>>>>> If so, you should not link against the Xenomai libs if you need no -rt
>>>>>>>>> service, or prevent symbol wrapping only for the POSIX I/O calls by
>>>>>>>>> prefixing them by __real_* if you want Xenomai-enabled POSIX services
>>>>>>>>> except the I/O support.
>>>>>>>>>
>>>>>>>>> See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
>>>>>>>>>> CC kernel/xenomai/nucleus/synch.o
>>>>>>>>>> kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread':
>>>>>>>>>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
>>>>>>>>>> function 'xnthread_get_rescnt'
>>>>>>>>>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
>>>>>>>>>> function 'xnshadow_send_sig'
>>>>>>>>>>
>>>>>>>>>> I had to go in and make the code for that option befor it always
>>>>>>>>>> false.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107
>>>>>>>>> a7
>>>>>>>>> 88b
>>>>>>>>>
>>>>>>>>> 76
>>>>>>>>> 2b5cf662b1d4108
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Glen
>>>>>>>>>> --
>>>>>>>>>> Glen Wernersbach
>>>>>>>>>> President&   CTO
>>>>>>>>>>
>>>>>>>>>> Jetsoft Development Co.
>>>>>>>>>> 629 Old St Rt. 74 ­ Suite 210
>>>>>>>>>> Cincinnati, Oh 45244
>>>>>>>>>> Custom Programming Web Site: www.jetsoftdev.com
>>>>>>>>>> Retail Products Web Site: www.scanhelp.com
>>>>>>>>>> Phone: 513-528-6660
>>>>>>>>>> Fax: 513-528-3470
>>>>>>>>>> Cell 513-240-9929
>>>>>>>>>> ----
>>>>>>>>>> Partner for Software Technology
>>>>>>>>>> Jacobs Automation
>>>>>>>>>> 2365 Progress Drive
>>>>>>>>>> Hebron, KY 41048
>>>>>>>>>> (513) 297-7550
>>>>>>>>>> ----
>>>>>>>>>> "Support Dyslexia Research"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Xenomai-help mailing list
>>>>>>>>>> Xenomai-help@domain.hid
>>>>>>>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>


-- 
Philippe.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

[-- Attachment #1.1: Type: text/plain, Size: 9411 bytes --]

Don't have a full dev enviroment on my embedded arm. Here is the program.
Very very basic:
-------
#include <stdio.h>
#include <termios.h>
#include <errno.h>
#include <fcntl.h>


/*Artila*/
#define MATRIX500_GET_UART_TYPE        0xe001
#define MATRIX500_SET_UART_TYPE        0xe002
#define MATRIX500_GET_UART_MODE9    0xe003
#define MATRIX500_SET_UART_MODE9    0xe004
#define MATRIX500_UART_SET_BAUD        0xe006

#define MATRIX500_UART_TYPE_232        232
#define MATRIX500_UART_TYPE_422        422
#define MATRIX500_UART_TYPE_485        485
int
main(argc, argv)
    int    argc;
    char    *argv[];
{

    int    fd, ret;
  struct termios term;
    char    buf[]="XBCDEFHIJKM\0";
    char  buf2[1024]    ;

    struct termios T_new;

    /*open tty port*/
    fd = open("/dev/ttyS4", O_RDWR | O_NOCTTY | O_NDELAY);
    if (fd == -1) {
        printf("open /dev/ttyS0 Failed, errno: %d\r\n", errno);
        return 0;
    }

  unsigned long interface2=0;
  ioctl(fd, MATRIX500_GET_UART_TYPE, &interface2) ;
  printf("set UART type: %d...Failed, errno: %d\r\n", interface2, errno);
  
    /*set serial interface: RS-422*/
    interface2 = MATRIX500_UART_TYPE_422;
    if(ioctl(fd, MATRIX500_SET_UART_TYPE, &interface2) != 0) {
        printf("set UART type: %d...Failed, errno: %d\r\n", interface2,
errno);
        close(fd);
        return 0;
    }
    
    unsigned long mode9 = 0;
    ioctl(fd, MATRIX500_GET_UART_MODE9, &mode9);
    printf("mode: %d...Failed, errno: %d\r\n", mode9, errno);
    
    mode9=0;
    
    if (ioctl(fd, MATRIX500_SET_UART_MODE9, &mode9)!= 0) {
        printf("mode: %d...Failed, errno: %d\r\n", mode9, errno);
        close(fd);
        return 0;
    }
//it appears this is not getting set but no error.
    
    if(tcgetattr(fd,&term) != 0) {
                    printf("tcgetattr failed\n");
                
            } 
            term.c_cflag = (B921600 | CS8 | CREAD | CLOCAL | HUPCL);
            term.c_oflag = 0;
            term.c_iflag = 0;
            term.c_lflag = 0;
            if(tcsetattr(fd,TCSANOW,&term) != 0) {
                    printf("tcsetattr failed\n");
                
            } 
    //set baud rate at 4 times 921.6m
    
    unsigned long baud = 921600UL*4;
    if (ioctl(fd , MATRIX500_UART_SET_BAUD , &baud ) != 0) {
        printf("set baud: %d...Failed, errno: %d\r\n", baud, errno);
        close(fd);
        return 0;
    }

    
     close(fd);





     
     fd = open("/dev/ttyS4", O_RDWR | O_NOCTTY | O_NDELAY);
    if (fd == -1) {
        printf("open /dev/ttyS0 Failed, errno: %d\r\n", errno);
        return 0;
    }
    
          
  //write the data to my device which echos them back
  write(fd, buf, sizeof(buf)-1);
  
 //will wait forever here.
    while(1) {
        //wait for all 12 characters to received in fifo and then print them
to the console
        
        
        ret = read(fd, buf2, sizeof(buf)-1);
        if (ret ==sizeof(buf)-1) {
          buf2[ret]  ='\0' ;
          printf("got data %s\n",  buf2) ;
             break;
      
        } 
        
          
    }
    
 
        close(fd) ;
    return 0;
}

------



On 3/20/12 11:06 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:

> On 03/20/2012 03:53 PM, Glen Wernersbach wrote:
>> Ipipe version:
>> 1.13-05
>> 
>> 
>> Yes, I do have the co kernel and interrupt pipeline enabled
> 
> ldd <your-serial-app> ?
> 
>> 
>> 
>> On 3/20/12 10:47 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>> 
>>> On 03/20/2012 03:34 PM, Glen Wernersbach wrote:
>>>> Working on the Strace.
>>>> 
>>>> I don't have the /proc/xenomai/hal file??
>>> 
>>> /proc/ipipe/version then.
>>> 
>>>> 
>>>> Again. Nothing I am running is xeno. Its just a xeno patched kernel.
>>>> 
>>> 
>>> Ok, but you do have the Xenomai co-kernel enabled in your kernel build,
>>> and the interrupt pipeline is enabled as well, right?
>>> 
>>>> 
>>>> 
>>>> 
>>>> On 3/20/12 10:31 AM, "Philippe Gerum"<rpm@xenomai.org>   wrote:
>>>> 
>>>>> On 03/20/2012 03:17 PM, Philippe Gerum wrote:
>>>>>> On 03/20/2012 03:07 PM, Glen Wernersbach wrote:
>>>>>>> I went through and disabled everything in xeno except
>>>>>>> CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it
>>>>>>> works.
>>>>>>> 
>>>>>>> Take that option out at anytime it works.
>>>>>>> 
>>>>>>> My program basic writes a few characters a serial port and then reads
>>>>>>> them
>>>>>>> back in from the same port. I have a loop back cable connected to the
>>>>>>> port.
>>>>>>> 
>>>>>>> It writes the data but waits forever to read them back in
>>>>>>> 
>>>>>>>>    From my tests, it appears that the termois tcsetaddr settings is not
>>>>>>>> getting
>>>>>>> set when I call it when this option is on.
>>>>>> 
>>>>>> Can you strace your app when it runs, please?
>>>>> 
>>>>> The interrupt pipeline release number would help as well
>>>>> (/proc/xenomai/hal).
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 3/20/12 9:57 AM, "Philippe Gerum"<rpm@xenomai.org>   wrote:
>>>>>>> 
>>>>>>>> On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
>>>>>>>>> I don't think this is it directly.
>>>>>>>>> 
>>>>>>>>> This program was made on the same kernel prior to patching it with
>>>>>>>>> Xeno.
>>>>>>>>> 
>>>>>>>>> It should still run like any other linux program.
>>>>>>>> 
>>>>>>>> - what does "program not working" mean in your case? Any errno return
>>>>>>>> we
>>>>>>>> could interpret? Any strace output?
>>>>>>>> 
>>>>>>>> - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on?
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 3/20/12 9:44 AM, "Philippe Gerum"<rpm@xenomai.org>   wrote:
>>>>>>>>> 
>>>>>>>>>> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>> 
>>>>>>>>>>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that
>>>>>>>>>>> when
>>>>>>>>>>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux
>>>>>>>>>>> serial write then read serial program does not work.
>>>>>>>>>>> 
>>>>>>>>>>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does
>>>>>>>>>>> work.
>>>>>>>>>>> 
>>>>>>>>>>> Any ideas why?????
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> A possible explanation would be that your application links with the
>>>>>>>>>> Xenomai POSIX lib (libpthread_rt), albeit it should not.
>>>>>>>>>> 
>>>>>>>>>> With pervasive support disabled, any routing from the overloaded
>>>>>>>>>> POSIX
>>>>>>>>>> I/O calls to the Xenomai kernel would then fail.
>>>>>>>>>> 
>>>>>>>>>> If so, you should not link against the Xenomai libs if you need no
>>>>>>>>>> -rt
>>>>>>>>>> service, or prevent symbol wrapping only for the POSIX I/O calls by
>>>>>>>>>> prefixing them by __real_* if you want Xenomai-enabled POSIX services
>>>>>>>>>> except the I/O support.
>>>>>>>>>> 
>>>>>>>>>> See 
>>>>>>>>>> http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
>>>>>>>>>>> CC kernel/xenomai/nucleus/synch.o
>>>>>>>>>>> kernel/xenomai/nucleus/synch.c: In function
>>>>>>>>>>> 'xnsynch_release_thread':
>>>>>>>>>>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
>>>>>>>>>>> function 'xnthread_get_rescnt'
>>>>>>>>>>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
>>>>>>>>>>> function 'xnshadow_send_sig'
>>>>>>>>>>> 
>>>>>>>>>>> I had to go in and make the code for that option befor it always
>>>>>>>>>>> false.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf061
>>>>>>>>>> 07
>>>>>>>>>> a7
>>>>>>>>>> 88b
>>>>>>>>>> 
>>>>>>>>>> 76
>>>>>>>>>> 2b5cf662b1d4108
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> Glen
>>>>>>>>>>> --
>>>>>>>>>>> Glen Wernersbach
>>>>>>>>>>> President&   CTO
>>>>>>>>>>> 
>>>>>>>>>>> Jetsoft Development Co.
>>>>>>>>>>> 629 Old St Rt. 74 ­ Suite 210
>>>>>>>>>>> Cincinnati, Oh 45244
>>>>>>>>>>> Custom Programming Web Site: www.jetsoftdev.com
>>>>>>>>>>> Retail Products Web Site: www.scanhelp.com
>>>>>>>>>>> Phone: 513-528-6660
>>>>>>>>>>> Fax: 513-528-3470
>>>>>>>>>>> Cell 513-240-9929
>>>>>>>>>>> ----
>>>>>>>>>>> Partner for Software Technology
>>>>>>>>>>> Jacobs Automation
>>>>>>>>>>> 2365 Progress Drive
>>>>>>>>>>> Hebron, KY 41048
>>>>>>>>>>> (513) 297-7550
>>>>>>>>>>> ----
>>>>>>>>>>> "Support Dyslexia Research"
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Xenomai-help mailing list
>>>>>>>>>>> Xenomai-help@domain.hid
>>>>>>>>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"


[-- Attachment #1.2: Type: text/html, Size: 19890 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 30109 bytes --]

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Gilles Chanteperdrix]

On 03/20/2012 04:17 PM, Glen Wernersbach wrote:
> Don't have a full dev enviroment on my embedded arm. Here is the program.
> Very very basic:
>      close(fd);
> 
> 
> 
> 
> 
>      
>      fd = open("/dev/ttyS4", O_RDWR | O_NOCTTY | O_NDELAY);

Why closing and reopening? Are you sure this does not reset configuration?

>     if (fd == -1) {
>         printf("open /dev/ttyS0 Failed, errno: %d\r\n", errno);
>         return 0;
>     }
>     
>           
>   //write the data to my device which echos them back
>   write(fd, buf, sizeof(buf)-1);

missing return value check.

>   


-- 
					    Gilles.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Philippe Gerum]

On 03/20/2012 04:17 PM, Glen Wernersbach wrote:
> Don't have a full dev enviroment on my embedded arm. Here is the
> program. Very very basic:

Ok, actually I was after the link flags used for building this app.

> -------
> #include <stdio.h>
> #include <termios.h>
> #include <errno.h>
> #include <fcntl.h>
>
>
> /*Artila*/
> #define MATRIX500_GET_UART_TYPE 0xe001
> #define MATRIX500_SET_UART_TYPE 0xe002
> #define MATRIX500_GET_UART_MODE9 0xe003
> #define MATRIX500_SET_UART_MODE9 0xe004
> #define MATRIX500_UART_SET_BAUD 0xe006
>
> #define MATRIX500_UART_TYPE_232 232
> #define MATRIX500_UART_TYPE_422 422
> #define MATRIX500_UART_TYPE_485 485
> int
> main(argc, argv)
> int argc;
> char *argv[];
> {
>
> int fd, ret;
> struct termios term;
> char buf[]="XBCDEFHIJKM\0";
> char buf2[1024] ;
>
> struct termios T_new;
>
> /*open tty port*/
> fd = open("/dev/ttyS4", O_RDWR | O_NOCTTY | O_NDELAY);
> if (fd == -1) {
> printf("open /dev/ttyS0 Failed, errno: %d\r\n", errno);
> return 0;
> }
>
> unsigned long interface2=0;
> ioctl(fd, MATRIX500_GET_UART_TYPE, &interface2) ;
> printf("set UART type: %d...Failed, errno: %d\r\n", interface2, errno);
>
> /*set serial interface: RS-422*/
> interface2 = MATRIX500_UART_TYPE_422;
> if(ioctl(fd, MATRIX500_SET_UART_TYPE, &interface2) != 0) {
> printf("set UART type: %d...Failed, errno: %d\r\n", interface2, errno);
> close(fd);
> return 0;
> }
>
> unsigned long mode9 = 0;
> ioctl(fd, MATRIX500_GET_UART_MODE9, &mode9);
> printf("mode: %d...Failed, errno: %d\r\n", mode9, errno);
>
> mode9=0;
>
> if (ioctl(fd, MATRIX500_SET_UART_MODE9, &mode9)!= 0) {
> printf("mode: %d...Failed, errno: %d\r\n", mode9, errno);
> close(fd);
> return 0;
> }
> //it appears this is not getting set but no error.
>
> if(tcgetattr(fd,&term) != 0) {
> printf("tcgetattr failed\n");
>
> }
> term.c_cflag = (B921600 | CS8 | CREAD | CLOCAL | HUPCL);
> term.c_oflag = 0;
> term.c_iflag = 0;
> term.c_lflag = 0;
> if(tcsetattr(fd,TCSANOW,&term) != 0) {
> printf("tcsetattr failed\n");
>
> }
> //set baud rate at 4 times 921.6m
>
> unsigned long baud = 921600UL*4;
> if (ioctl(fd , MATRIX500_UART_SET_BAUD , &baud ) != 0) {
> printf("set baud: %d...Failed, errno: %d\r\n", baud, errno);
> close(fd);
> return 0;
> }
>
>
> close(fd);
>
>
>
>
>
>
> fd = open("/dev/ttyS4", O_RDWR | O_NOCTTY | O_NDELAY);
> if (fd == -1) {
> printf("open /dev/ttyS0 Failed, errno: %d\r\n", errno);
> return 0;
> }
>
>
> //write the data to my device which echos them back
> write(fd, buf, sizeof(buf)-1);
>
> //will wait forever here.
> while(1) {
> //wait for all 12 characters to received in fifo and then print them to
> the console
>
>
> ret = read(fd, buf2, sizeof(buf)-1);
> if (ret ==sizeof(buf)-1) {
> buf2[ret] ='\0' ;
> printf("got data %s\n", buf2) ;
> break;
>
> }
>
>
> }
>
>
> close(fd) ;
> return 0;
> }
>
> ------
>
>
>
> On 3/20/12 11:06 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:
>
>>  On 03/20/2012 03:53 PM, Glen Wernersbach wrote:
>> > Ipipe version:
>> > 1.13-05
>> >
>> >
>> > Yes, I do have the co kernel and interrupt pipeline enabled
>>
>>  ldd <your-serial-app> ?
>>
>> >
>> >
>> > On 3/20/12 10:47 AM, "Philippe Gerum"<rpm@xenomai.org> wrote:
>> >
>> >> On 03/20/2012 03:34 PM, Glen Wernersbach wrote:
>> >>> Working on the Strace.
>> >>>
>> >>> I don't have the /proc/xenomai/hal file??
>> >>
>> >> /proc/ipipe/version then.
>> >>
>> >>>
>> >>> Again. Nothing I am running is xeno. Its just a xeno patched kernel.
>> >>>
>> >>
>> >> Ok, but you do have the Xenomai co-kernel enabled in your kernel build,
>> >> and the interrupt pipeline is enabled as well, right?
>> >>
>> >>>
>> >>>
>> >>>
>> >>> On 3/20/12 10:31 AM, "Philippe Gerum"<rpm@xenomai.org> wrote:
>> >>>
>> >>>> On 03/20/2012 03:17 PM, Philippe Gerum wrote:
>> >>>>> On 03/20/2012 03:07 PM, Glen Wernersbach wrote:
>> >>>>>> I went through and disabled everything in xeno except
>> >>>>>> CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it
>> >>>>>> works.
>> >>>>>>
>> >>>>>> Take that option out at anytime it works.
>> >>>>>>
>> >>>>>> My program basic writes a few characters a serial port and then
> reads
>> >>>>>> them
>> >>>>>> back in from the same port. I have a loop back cable connected
> to the
>> >>>>>> port.
>> >>>>>>
>> >>>>>> It writes the data but waits forever to read them back in
>> >>>>>>
>> >>>>>>> From my tests, it appears that the termois tcsetaddr settings
> is not
>> >>>>>>> getting
>> >>>>>> set when I call it when this option is on.
>> >>>>>
>> >>>>> Can you strace your app when it runs, please?
>> >>>>
>> >>>> The interrupt pipeline release number would help as well
>> >>>> (/proc/xenomai/hal).
>> >>>>
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On 3/20/12 9:57 AM, "Philippe Gerum"<rpm@xenomai.org> wrote:
>> >>>>>>
>> >>>>>>> On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
>> >>>>>>>> I don't think this is it directly.
>> >>>>>>>>
>> >>>>>>>> This program was made on the same kernel prior to patching it with
>> >>>>>>>> Xeno.
>> >>>>>>>>
>> >>>>>>>> It should still run like any other linux program.
>> >>>>>>>
>> >>>>>>> - what does "program not working" mean in your case? Any errno
> return
>> >>>>>>> we
>> >>>>>>> could interpret? Any strace output?
>> >>>>>>>
>> >>>>>>> - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving
> PERVASIVE on?
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On 3/20/12 9:44 AM, "Philippe Gerum"<rpm@xenomai.org> wrote:
>> >>>>>>>>
>> >>>>>>>>> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>> >>>>>>>>>> Hi All,
>> >>>>>>>>>>
>> >>>>>>>>>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found
> that
>> >>>>>>>>>> when
>> >>>>>>>>>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real
> time linux
>> >>>>>>>>>> serial write then read serial program does not work.
>> >>>>>>>>>>
>> >>>>>>>>>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does
>> >>>>>>>>>> work.
>> >>>>>>>>>>
>> >>>>>>>>>> Any ideas why?????
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> A possible explanation would be that your application links
> with the
>> >>>>>>>>> Xenomai POSIX lib (libpthread_rt), albeit it should not.
>> >>>>>>>>>
>> >>>>>>>>> With pervasive support disabled, any routing from the overloaded
>> >>>>>>>>> POSIX
>> >>>>>>>>> I/O calls to the Xenomai kernel would then fail.
>> >>>>>>>>>
>> >>>>>>>>> If so, you should not link against the Xenomai libs if you
> need no
>> >>>>>>>>> -rt
>> >>>>>>>>> service, or prevent symbol wrapping only for the POSIX I/O
> calls by
>> >>>>>>>>> prefixing them by __real_* if you want Xenomai-enabled POSIX
> services
>> >>>>>>>>> except the I/O support.
>> >>>>>>>>>
>> >>>>>>>>> See
>> >>>>>>>>>
> http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this
> error:
>> >>>>>>>>>> CC kernel/xenomai/nucleus/synch.o
>> >>>>>>>>>> kernel/xenomai/nucleus/synch.c: In function
>> >>>>>>>>>> 'xnsynch_release_thread':
>> >>>>>>>>>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit
> declaration of
>> >>>>>>>>>> function 'xnthread_get_rescnt'
>> >>>>>>>>>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit
> declaration of
>> >>>>>>>>>> function 'xnshadow_send_sig'
>> >>>>>>>>>>
>> >>>>>>>>>> I had to go in and make the code for that option befor it always
>> >>>>>>>>>> false.
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf061
>> >>>>>>>>> 07
>> >>>>>>>>> a7
>> >>>>>>>>> 88b
>> >>>>>>>>>
>> >>>>>>>>> 76
>> >>>>>>>>> 2b5cf662b1d4108
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>> Glen
>> >>>>>>>>>> --
>> >>>>>>>>>> Glen Wernersbach
>> >>>>>>>>>> President& CTO
>> >>>>>>>>>>
>> >>>>>>>>>> Jetsoft Development Co.
>> >>>>>>>>>> 629 Old St Rt. 74 – Suite 210
>> >>>>>>>>>> Cincinnati, Oh 45244
>> >>>>>>>>>> Custom Programming Web Site: www.jetsoftdev.com
>> >>>>>>>>>> Retail Products Web Site: www.scanhelp.com
>> >>>>>>>>>> Phone: 513-528-6660
>> >>>>>>>>>> Fax: 513-528-3470
>> >>>>>>>>>> Cell 513-240-9929
>> >>>>>>>>>> ----
>> >>>>>>>>>> Partner for Software Technology
>> >>>>>>>>>> Jacobs Automation
>> >>>>>>>>>> 2365 Progress Drive
>> >>>>>>>>>> Hebron, KY 41048
>> >>>>>>>>>> (513) 297-7550
>> >>>>>>>>>> ----
>> >>>>>>>>>> "Support Dyslexia Research"
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> _______________________________________________
>> >>>>>>>>>> Xenomai-help mailing list
>> >>>>>>>>>> Xenomai-help@domain.hid
>> >>>>>>>>>> https://mail.gna.org/listinfo/xenomai-help
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>
> --
> Glen Wernersbach
> President & CTO
>
> Jetsoft Development Co.
> 629 Old St Rt. 74 – Suite 210
> Cincinnati, Oh 45244
> Custom Programming Web Site: www.jetsoftdev.com
> Retail Products Web Site: www.scanhelp.com
> Phone: 513-528-6660
> Fax: 513-528-3470
> Cell 513-240-9929
> ----
> Partner for Software Technology
> Jacobs Automation
> 2365 Progress Drive
> Hebron, KY 41048
> (513) 297-7550
> ----
> "Support Dyslexia Research"


-- 
Philippe.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

Not much to that as well.

CC = arm-linux-gnueabi-gcc
#CC = gcc

all:    serial
serial:     serial.c
    $(CC) -o serial.o serial.c
    arm-linux-gnueabi-strip serial.o

clean:
    rm -f serial.o



On 3/20/12 11:27 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:

> On 03/20/2012 04:17 PM, Glen Wernersbach wrote:
>> Don't have a full dev enviroment on my embedded arm. Here is the
>> program. Very very basic:
> 
> Ok, actually I was after the link flags used for building this app.
> 
>> -------
>> #include <stdio.h>
>> #include <termios.h>
>> #include <errno.h>
>> #include <fcntl.h>
>> 
>> 
>> /*Artila*/
>> #define MATRIX500_GET_UART_TYPE 0xe001
>> #define MATRIX500_SET_UART_TYPE 0xe002
>> #define MATRIX500_GET_UART_MODE9 0xe003
>> #define MATRIX500_SET_UART_MODE9 0xe004
>> #define MATRIX500_UART_SET_BAUD 0xe006
>> 
>> #define MATRIX500_UART_TYPE_232 232
>> #define MATRIX500_UART_TYPE_422 422
>> #define MATRIX500_UART_TYPE_485 485
>> int
>> main(argc, argv)
>> int argc;
>> char *argv[];
>> {
>> 
>> int fd, ret;
>> struct termios term;
>> char buf[]="XBCDEFHIJKM\0";
>> char buf2[1024] ;
>> 
>> struct termios T_new;
>> 
>> /*open tty port*/
>> fd = open("/dev/ttyS4", O_RDWR | O_NOCTTY | O_NDELAY);
>> if (fd == -1) {
>> printf("open /dev/ttyS0 Failed, errno: %d\r\n", errno);
>> return 0;
>> }
>> 
>> unsigned long interface2=0;
>> ioctl(fd, MATRIX500_GET_UART_TYPE, &interface2) ;
>> printf("set UART type: %d...Failed, errno: %d\r\n", interface2, errno);
>> 
>> /*set serial interface: RS-422*/
>> interface2 = MATRIX500_UART_TYPE_422;
>> if(ioctl(fd, MATRIX500_SET_UART_TYPE, &interface2) != 0) {
>> printf("set UART type: %d...Failed, errno: %d\r\n", interface2, errno);
>> close(fd);
>> return 0;
>> }
>> 
>> unsigned long mode9 = 0;
>> ioctl(fd, MATRIX500_GET_UART_MODE9, &mode9);
>> printf("mode: %d...Failed, errno: %d\r\n", mode9, errno);
>> 
>> mode9=0;
>> 
>> if (ioctl(fd, MATRIX500_SET_UART_MODE9, &mode9)!= 0) {
>> printf("mode: %d...Failed, errno: %d\r\n", mode9, errno);
>> close(fd);
>> return 0;
>> }
>> //it appears this is not getting set but no error.
>> 
>> if(tcgetattr(fd,&term) != 0) {
>> printf("tcgetattr failed\n");
>> 
>> }
>> term.c_cflag = (B921600 | CS8 | CREAD | CLOCAL | HUPCL);
>> term.c_oflag = 0;
>> term.c_iflag = 0;
>> term.c_lflag = 0;
>> if(tcsetattr(fd,TCSANOW,&term) != 0) {
>> printf("tcsetattr failed\n");
>> 
>> }
>> //set baud rate at 4 times 921.6m
>> 
>> unsigned long baud = 921600UL*4;
>> if (ioctl(fd , MATRIX500_UART_SET_BAUD , &baud ) != 0) {
>> printf("set baud: %d...Failed, errno: %d\r\n", baud, errno);
>> close(fd);
>> return 0;
>> }
>> 
>> 
>> close(fd);
>> 
>> 
>> 
>> 
>> 
>> 
>> fd = open("/dev/ttyS4", O_RDWR | O_NOCTTY | O_NDELAY);
>> if (fd == -1) {
>> printf("open /dev/ttyS0 Failed, errno: %d\r\n", errno);
>> return 0;
>> }
>> 
>> 
>> //write the data to my device which echos them back
>> write(fd, buf, sizeof(buf)-1);
>> 
>> //will wait forever here.
>> while(1) {
>> //wait for all 12 characters to received in fifo and then print them to
>> the console
>> 
>> 
>> ret = read(fd, buf2, sizeof(buf)-1);
>> if (ret ==sizeof(buf)-1) {
>> buf2[ret] ='\0' ;
>> printf("got data %s\n", buf2) ;
>> break;
>> 
>> }
>> 
>> 
>> }
>> 
>> 
>> close(fd) ;
>> return 0;
>> }
>> 
>> ------
>> 
>> 
>> 
>> On 3/20/12 11:06 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:
>> 
>>>  On 03/20/2012 03:53 PM, Glen Wernersbach wrote:
>>>> Ipipe version:
>>>> 1.13-05
>>>> 
>>>> 
>>>> Yes, I do have the co kernel and interrupt pipeline enabled
>>> 
>>>  ldd <your-serial-app> ?
>>> 
>>>> 
>>>> 
>>>> On 3/20/12 10:47 AM, "Philippe Gerum"<rpm@xenomai.org> wrote:
>>>> 
>>>>> On 03/20/2012 03:34 PM, Glen Wernersbach wrote:
>>>>>> Working on the Strace.
>>>>>> 
>>>>>> I don't have the /proc/xenomai/hal file??
>>>>> 
>>>>> /proc/ipipe/version then.
>>>>> 
>>>>>> 
>>>>>> Again. Nothing I am running is xeno. Its just a xeno patched kernel.
>>>>>> 
>>>>> 
>>>>> Ok, but you do have the Xenomai co-kernel enabled in your kernel build,
>>>>> and the interrupt pipeline is enabled as well, right?
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 3/20/12 10:31 AM, "Philippe Gerum"<rpm@xenomai.org> wrote:
>>>>>> 
>>>>>>> On 03/20/2012 03:17 PM, Philippe Gerum wrote:
>>>>>>>> On 03/20/2012 03:07 PM, Glen Wernersbach wrote:
>>>>>>>>> I went through and disabled everything in xeno except
>>>>>>>>> CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it
>>>>>>>>> works.
>>>>>>>>> 
>>>>>>>>> Take that option out at anytime it works.
>>>>>>>>> 
>>>>>>>>> My program basic writes a few characters a serial port and then
>> reads
>>>>>>>>> them
>>>>>>>>> back in from the same port. I have a loop back cable connected
>> to the
>>>>>>>>> port.
>>>>>>>>> 
>>>>>>>>> It writes the data but waits forever to read them back in
>>>>>>>>> 
>>>>>>>>>> From my tests, it appears that the termois tcsetaddr settings
>> is not
>>>>>>>>>> getting
>>>>>>>>> set when I call it when this option is on.
>>>>>>>> 
>>>>>>>> Can you strace your app when it runs, please?
>>>>>>> 
>>>>>>> The interrupt pipeline release number would help as well
>>>>>>> (/proc/xenomai/hal).
>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 3/20/12 9:57 AM, "Philippe Gerum"<rpm@xenomai.org> wrote:
>>>>>>>>> 
>>>>>>>>>> On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
>>>>>>>>>>> I don't think this is it directly.
>>>>>>>>>>> 
>>>>>>>>>>> This program was made on the same kernel prior to patching it with
>>>>>>>>>>> Xeno.
>>>>>>>>>>> 
>>>>>>>>>>> It should still run like any other linux program.
>>>>>>>>>> 
>>>>>>>>>> - what does "program not working" mean in your case? Any errno
>> return
>>>>>>>>>> we
>>>>>>>>>> could interpret? Any strace output?
>>>>>>>>>> 
>>>>>>>>>> - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving
>> PERVASIVE on?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 3/20/12 9:44 AM, "Philippe Gerum"<rpm@xenomai.org> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>> 
>>>>>>>>>>>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found
>> that
>>>>>>>>>>>> when
>>>>>>>>>>>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real
>> time linux
>>>>>>>>>>>> serial write then read serial program does not work.
>>>>>>>>>>>> 
>>>>>>>>>>>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does
>>>>>>>>>>>> work.
>>>>>>>>>>>> 
>>>>>>>>>>>> Any ideas why?????
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> A possible explanation would be that your application links
>> with the
>>>>>>>>>>>> Xenomai POSIX lib (libpthread_rt), albeit it should not.
>>>>>>>>>>>> 
>>>>>>>>>>>> With pervasive support disabled, any routing from the overloaded
>>>>>>>>>>>> POSIX
>>>>>>>>>>>> I/O calls to the Xenomai kernel would then fail.
>>>>>>>>>>>> 
>>>>>>>>>>>> If so, you should not link against the Xenomai libs if you
>> need no
>>>>>>>>>>>> -rt
>>>>>>>>>>>> service, or prevent symbol wrapping only for the POSIX I/O
>> calls by
>>>>>>>>>>>> prefixing them by __real_* if you want Xenomai-enabled POSIX
>> services
>>>>>>>>>>>> except the I/O support.
>>>>>>>>>>>> 
>>>>>>>>>>>> See
>>>>>>>>>>>> 
>> http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this
>> error:
>>>>>>>>>>>> CC kernel/xenomai/nucleus/synch.o
>>>>>>>>>>>> kernel/xenomai/nucleus/synch.c: In function
>>>>>>>>>>>> 'xnsynch_release_thread':
>>>>>>>>>>>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit
>> declaration of
>>>>>>>>>>>> function 'xnthread_get_rescnt'
>>>>>>>>>>>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit
>> declaration of
>>>>>>>>>>>> function 'xnshadow_send_sig'
>>>>>>>>>>>> 
>>>>>>>>>>>> I had to go in and make the code for that option befor it always
>>>>>>>>>>>> false.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf061
>>>>>>>>>>>> 07
>>>>>>>>>>>> a7
>>>>>>>>>>>> 88b
>>>>>>>>>>>> 
>>>>>>>>>>>> 76
>>>>>>>>>>>> 2b5cf662b1d4108
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Glen
>>>>>>>>>>>> --
>>>>>>>>>>>> Glen Wernersbach
>>>>>>>>>>>> President& CTO
>>>>>>>>>>>> 
>>>>>>>>>>>> Jetsoft Development Co.
>>>>>>>>>>>> 629 Old St Rt. 74 ­ Suite 210
>>>>>>>>>>>> Cincinnati, Oh 45244
>>>>>>>>>>>> Custom Programming Web Site: www.jetsoftdev.com
>>>>>>>>>>>> Retail Products Web Site: www.scanhelp.com
>>>>>>>>>>>> Phone: 513-528-6660
>>>>>>>>>>>> Fax: 513-528-3470
>>>>>>>>>>>> Cell 513-240-9929
>>>>>>>>>>>> ----
>>>>>>>>>>>> Partner for Software Technology
>>>>>>>>>>>> Jacobs Automation
>>>>>>>>>>>> 2365 Progress Drive
>>>>>>>>>>>> Hebron, KY 41048
>>>>>>>>>>>> (513) 297-7550
>>>>>>>>>>>> ----
>>>>>>>>>>>> "Support Dyslexia Research"
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Xenomai-help mailing list
>>>>>>>>>>>> Xenomai-help@domain.hid
>>>>>>>>>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> --
>> Glen Wernersbach
>> President & CTO
>> 
>> Jetsoft Development Co.
>> 629 Old St Rt. 74 ­ Suite 210
>> Cincinnati, Oh 45244
>> Custom Programming Web Site: www.jetsoftdev.com
>> Retail Products Web Site: www.scanhelp.com
>> Phone: 513-528-6660
>> Fax: 513-528-3470
>> Cell 513-240-9929
>> ----
>> Partner for Software Technology
>> Jacobs Automation
>> 2365 Progress Drive
>> Hebron, KY 41048
>> (513) 297-7550
>> ----
>> "Support Dyslexia Research"
> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Gilles Chanteperdrix]

On 03/20/2012 03:53 PM, Glen Wernersbach wrote:
> Ipipe version:
> 1.13-05

That is completely outdated, please use one of the I-pipe patches which
comes with xenomai 2.6.0 (since you are using xenomai 2.6.0).

-- 
					    Gilles.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

My arm embedded system is set for 2.6.29 so I think I have to use that
patch. It was the latest one for that version.




On 3/20/12 11:12 AM, "Gilles Chanteperdrix"
<gilles.chanteperdrix@xenomai.org> wrote:

> On 03/20/2012 03:53 PM, Glen Wernersbach wrote:
>> Ipipe version:
>> 1.13-05
> 
> That is completely outdated, please use one of the I-pipe patches which
> comes with xenomai 2.6.0 (since you are using xenomai 2.6.0).

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Gilles Chanteperdrix]

On 03/20/2012 04:22 PM, Glen Wernersbach wrote:
> My arm embedded system is set for 2.6.29 so I think I have to use that
> patch. It was the latest one for that version.

The problem is that you may have a bug which has been fixed since then.
Is the code for that matrix500 driver available somewhere?

-- 
					    Gilles.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

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

Here it is. Just a simple modification of the atmel_serial.

The define for it is CONFIG_MACH_MATRIX518


On 3/20/12 11:26 AM, "Gilles Chanteperdrix"
<gilles.chanteperdrix@xenomai.org> wrote:

> On 03/20/2012 04:22 PM, Glen Wernersbach wrote:
>> My arm embedded system is set for 2.6.29 so I think I have to use that
>> patch. It was the latest one for that version.
> 
> The problem is that you may have a bug which has been fixed since then.
> Is the code for that matrix500 driver available somewhere?

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"


[-- Attachment #2: atmel_serial.c.zip --]
[-- Type: application/octet-stream, Size: 13562 bytes --]

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Gilles Chanteperdrix]

On 03/20/2012 05:40 PM, Glen Wernersbach wrote:
> Here it is. Just a simple modification of the atmel_serial.
> 
> The define for it is CONFIG_MACH_MATRIX518

>From a quick glance, I do not see anything conflicting with xenomai.
Note that this driver has the same issue as the vanilla atmel serial: it
may loose characters in case of high irq latencies.

Anyway, could you post the two kernel configurations, the one which
works, the one which does not work?

Other than that, I guess all you can do is try and debug the driver,
starting with the serial irq and trying and understanding how it gets lost.

-- 
                                                                Gilles.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

I actually think in is in the settings because if run just the setup part of the code without reading and writing, on the kernel that works my activity LED turns off. 

On the xeno kernel the LED never changes.

--
Glen Wernersbach
President & CTO
Jetsoft Development Co
629 Old St. Rt. 74 - Suite 210
Cincinnati Ohio 45244
Custom Programming Web Site: www.JetsoftDev.com
Retail Product Web Site: www.ScanHelp.com
Phone: 513-528-6660
Fax: 513-528-3470

On Mar 20, 2012, at 3:38 PM, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.orgmai.org> wrote:

> On 03/20/2012 05:40 PM, Glen Wernersbach wrote:
>> Here it is. Just a simple modification of the atmel_serial.
>> 
>> The define for it is CONFIG_MACH_MATRIX518
> 
> From a quick glance, I do not see anything conflicting with xenomai.
> Note that this driver has the same issue as the vanilla atmel serial: it
> may loose characters in case of high irq latencies.
> 
> Anyway, could you post the two kernel configurations, the one which
> works, the one which does not work?
> 
> Other than that, I guess all you can do is try and debug the driver,
> starting with the serial irq and trying and understanding how it gets lost.
> 
> -- 
>                                                                Gilles.
> 

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Gilles Chanteperdrix]

On 03/20/2012 09:19 PM, Glen Wernersbach wrote:
> I actually think in is in the settings because if run just the setup part of the code without reading and writing, on the kernel that works my activity LED turns off. 
> 
> On the xeno kernel the LED never changes.

I actually think that CONFIG_XENO_OPT_PERVASIVE does not make any
difference which could cause a difference of hardware behaviour. So, it
must be another option triggered by this config change. So, if you want
us to help you, please post the .configs.


-- 
                                                                Gilles.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

I know that there are some compile bugs if you turn off
CONFIG_XENO_OPT_PERVASIVE.

What is the downside to running without it?



On 3/20/12 4:35 PM, "Gilles Chanteperdrix"
<gilles.chanteperdrix@xenomai.org> wrote:

> On 03/20/2012 09:19 PM, Glen Wernersbach wrote:
>> I actually think in is in the settings because if run just the setup part of
>> the code without reading and writing, on the kernel that works my activity
>> LED turns off. 
>> 
>> On the xeno kernel the LED never changes.
> 
> I actually think that CONFIG_XENO_OPT_PERVASIVE does not make any
> difference which could cause a difference of hardware behaviour. So, it
> must be another option triggered by this config change. So, if you want
> us to help you, please post the .configs.
> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Philippe Gerum]

On 03/20/2012 10:20 PM, Glen Wernersbach wrote:
> I know that there are some compile bugs if you turn off
> CONFIG_XENO_OPT_PERVASIVE.
>
> What is the downside to running without it?
>

Don't bother for these build bugs, they were innocuous and due to 2.6.0 
being the first code drop of a major release. The system is stable with 
or without.

PERVASIVE gives you real-time support in userland; if you disable it, 
you only have support for writing apps in kernel space directly on top 
RT drivers.

PERVASIVE is by no mean directly related to hw setup, serial links, etc. 
This is only about switching on/off the userland request channel to the 
Xenomai kernel, nothing else. So any interaction with a serial driver 
could only be really remote, and I can't think of any right now.

Disabling this option might simply change the kernel code layout 
significantly enough to trigger a completely unrelated bug, since the 
Xenomai footprints in kernel shrinks in that case, changing the code 
placement for sure.

Starting investigations from the matrix driver seems the best way to 
find the issue.

>
>
> On 3/20/12 4:35 PM, "Gilles Chanteperdrix"
> <gilles.chanteperdrix@xenomai.org>  wrote:
>
>> On 03/20/2012 09:19 PM, Glen Wernersbach wrote:
>>> I actually think in is in the settings because if run just the setup part of
>>> the code without reading and writing, on the kernel that works my activity
>>> LED turns off.
>>>
>>> On the xeno kernel the LED never changes.
>>
>> I actually think that CONFIG_XENO_OPT_PERVASIVE does not make any
>> difference which could cause a difference of hardware behaviour. So, it
>> must be another option triggered by this config change. So, if you want
>> us to help you, please post the .configs.
>>
>


-- 
Philippe.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

I am going to start trying to see if I can figure out what is not getting
set.

By the way. This board also has 4 other serial ports on a 8250.c driver. It
also fails under the xeno build.




On 3/20/12 4:35 PM, "Gilles Chanteperdrix"
<gilles.chanteperdrix@xenomai.org> wrote:

> On 03/20/2012 09:19 PM, Glen Wernersbach wrote:
>> I actually think in is in the settings because if run just the setup part of
>> the code without reading and writing, on the kernel that works my activity
>> LED turns off. 
>> 
>> On the xeno kernel the LED never changes.
> 
> I actually think that CONFIG_XENO_OPT_PERVASIVE does not make any
> difference which could cause a difference of hardware behaviour. So, it
> must be another option triggered by this config change. So, if you want
> us to help you, please post the .configs.
> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Gilles Chanteperdrix]

On 03/21/2012 05:46 AM, Glen Wernersbach wrote:
> I am going to start trying to see if I can figure out what is not getting
> set.
> 
> By the way. This board also has 4 other serial ports on a 8250.c driver. It
> also fails under the xeno build.

But the serial console works, right? So there is at least on serial port
working.

-- 
                                                                Gilles.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

No I piped in over SSH and putty.

--
Glen Wernersbach
President & CTO
Jetsoft Development Co
629 Old St. Rt. 74 - Suite 210
Cincinnati Ohio 45244
Custom Programming Web Site: www.JetsoftDev.com
Retail Product Web Site: www.ScanHelp.com
Phone: 513-528-6660
Fax: 513-528-3470

On Mar 21, 2012, at 3:43 AM, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.orgmai.org> wrote:

> On 03/21/2012 05:46 AM, Glen Wernersbach wrote:
>> I am going to start trying to see if I can figure out what is not getting
>> set.
>> 
>> By the way. This board also has 4 other serial ports on a 8250.c driver. It
>> also fails under the xeno build.
> 
> But the serial console works, right? So there is at least on serial port
> working.
> 
> -- 
>                                                                Gilles.
> 

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

I figured out the fix. There was a hard coded minor number for a misc device
register for the GPIO.

For some reason PERVASIVE conflicted with it.

Changed it to dynamic assign ID and it worked fine.

Linux serial now works.


On 3/21/12 3:43 AM, "Gilles Chanteperdrix"
<gilles.chanteperdrix@xenomai.org> wrote:

> On 03/21/2012 05:46 AM, Glen Wernersbach wrote:
>> I am going to start trying to see if I can figure out what is not getting
>> set.
>> 
>> By the way. This board also has 4 other serial ports on a 8250.c driver. It
>> also fails under the xeno build.
> 
> But the serial console works, right? So there is at least on serial port
> working.

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Philippe Gerum]

On 03/21/2012 05:46 AM, Glen Wernersbach wrote:
> I am going to start trying to see if I can figure out what is not getting
> set.
>

You could get useful information from the pipeline tracer, by enabling 
CONFIG_IPIPE_TRACE, observing what exactly happens in kernel space from 
the issuing of the ioctl() syscall until the the read() syscall on the 
serial link.

You could set markers using Xenomai's I-pipe trace API in userland to 
highlight portions of interest in your app code, freezing the capture to 
snapshot a particular moment in the execution timeline. See
http://xenomai.org/index.php/I-pipe:Tracer.

NOTE: pay attention to the value in /proc/ipipe/trace/back_trace_points 
to hold enough data.

> By the way. This board also has 4 other serial ports on a 8250.c driver. It
> also fails under the xeno build.
>
>
>
>
> On 3/20/12 4:35 PM, "Gilles Chanteperdrix"
> <gilles.chanteperdrix@xenomai.org>  wrote:
>
>> On 03/20/2012 09:19 PM, Glen Wernersbach wrote:
>>> I actually think in is in the settings because if run just the setup part of
>>> the code without reading and writing, on the kernel that works my activity
>>> LED turns off.
>>>
>>> On the xeno kernel the LED never changes.
>>
>> I actually think that CONFIG_XENO_OPT_PERVASIVE does not make any
>> difference which could cause a difference of hardware behaviour. So, it
>> must be another option triggered by this config change. So, if you want
>> us to help you, please post the .configs.
>>
>


-- 
Philippe.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

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

Hi guys,

One thing about both of these drivers is they have been modified to set some
GPIO pins.

The come down to the pca9539_gpio_set_value() in this file.

Do you see any reason why those would not take under Xenomai?

Glen


On 3/21/12 4:38 AM, "Philippe Gerum" <rpm@xenomai.org> wrote:

> On 03/21/2012 05:46 AM, Glen Wernersbach wrote:
>> I am going to start trying to see if I can figure out what is not getting
>> set.
>> 
> 
> You could get useful information from the pipeline tracer, by enabling
> CONFIG_IPIPE_TRACE, observing what exactly happens in kernel space from
> the issuing of the ioctl() syscall until the the read() syscall on the
> serial link.
> 
> You could set markers using Xenomai's I-pipe trace API in userland to
> highlight portions of interest in your app code, freezing the capture to
> snapshot a particular moment in the execution timeline. See
> http://xenomai.org/index.php/I-pipe:Tracer.
> 
> NOTE: pay attention to the value in /proc/ipipe/trace/back_trace_points
> to hold enough data.
> 
>> By the way. This board also has 4 other serial ports on a 8250.c driver. It
>> also fails under the xeno build.
>> 
>> 
>> 
>> 
>> On 3/20/12 4:35 PM, "Gilles Chanteperdrix"
>> <gilles.chanteperdrix@xenomai.org>  wrote:
>> 
>>> On 03/20/2012 09:19 PM, Glen Wernersbach wrote:
>>>> I actually think in is in the settings because if run just the setup part
>>>> of
>>>> the code without reading and writing, on the kernel that works my activity
>>>> LED turns off.
>>>> 
>>>> On the xeno kernel the LED never changes.
>>> 
>>> I actually think that CONFIG_XENO_OPT_PERVASIVE does not make any
>>> difference which could cause a difference of hardware behaviour. So, it
>>> must be another option triggered by this config change. So, if you want
>>> us to help you, please post the .configs.
>>> 
>> 
> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"


[-- Attachment #2: pca9555_gpio.c --]
[-- Type: application/octet-stream, Size: 12088 bytes --]

/*
 * GPIO driver for Artila M502 based on Atmel AT91SAM9G20 (Thunder)
 *
 *  Copyright (C) 2010 Artila Electronics,Ltd
 *
 */

#include <linux/module.h>
#include <linux/fs.h>
#include <linux/miscdevice.h>
#include <asm/bitops.h> 
#include <asm/uaccess.h>
#include <linux/init.h>
#include <linux/spinlock.h>
#include <mach/hardware.h>
#include <mach/at91_pio.h>
#include <mach/gpio.h>
#include <linux/i2c.h>
#include <asm/pca9539.h>

#define GPIO_MINOR 		254

#define PIN  0
#define OUTP 1
#define INP  2
#define LOW  0
#define HIGH 1

/* IOCTL Commands */
#define GPIO_IOCTL_COUNT	0
#define GPIO_IOCTL_DIPSW	1
#define GPIO_IOCTL_GET		2
#define	GPIO_IOCTL_SET		3
#define	GPIO_IOCTL_CLEAR	4
#define GPIO_IOCTL_OUTPUT	5
#define GPIO_IOCTL_INPUT	6
#define GPIO_IOCTL_MODE		7
#define GPIO_IOCTL_INPUT_SET	8
#define GPIO_IOCTL_STATUS	0xa001


//static DEFINE_SPINLOCK(gpio_lock);

int chips = 0;
int init_error = 0;


#ifdef CONFIG_MACH_M502

#define M504_GPIO_COUNT	24
#define M504_GPIO_SW	2
static int M502_GPIO[M504_GPIO_COUNT+M504_GPIO_SW] = {
	0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,
	AT91_PIN_PC15,
	16,17,
	AT91_PIN_PC1,
	18,19,20,21,22,
	AT91_PIN_PB12,
	AT91_PIN_PB13,
};
static int M502_MODE[M504_GPIO_COUNT+M504_GPIO_SW];

#elif defined(CONFIG_MACH_PAC4010)

#define M504_GPIO_COUNT	16
#define M504_GPIO_SW	0
static int M502_GPIO[M504_GPIO_COUNT+M504_GPIO_SW] = {
	0,1, 2, 3, 4, 5, 6, 7,
	8,9,10,11,12,13,14,16,
};
static int M502_MODE[M504_GPIO_COUNT+M504_GPIO_SW];

#else

#define M504_GPIO_COUNT	21
#define M504_GPIO_SW	0
static int M502_GPIO[M504_GPIO_COUNT+M504_GPIO_SW] = {
	0,1,2,3,4,5,6,7,8,9,10,11,12,13,14, // 15
	21,
	16,17,
	22,
	19,20
};
static int M502_MODE[M504_GPIO_COUNT+M504_GPIO_SW];
#endif

#define M504_TOTAL_GPIO	(M504_GPIO_COUNT+M504_GPIO_SW)
/* ......................................................................... */
#define PCA953X_INPUT          0
#define PCA953X_OUTPUT         1
#define PCA953X_INVERT         2
#define PCA953X_DIRECTION      3

static const struct i2c_device_id pca9539_id[] = {
	{ "pca9539", 16, },
	{ }
};
MODULE_DEVICE_TABLE(i2c, pca9539_id);

struct pca9539_chip {
	unsigned gpio_start;
	uint16_t reg_output;
	uint16_t reg_direction;

	struct i2c_client *client;
};

struct pca9539_chip *save_chip[2];

static int pca9539_write_reg(struct pca9539_chip *chip, int reg, uint16_t val)
{
	int ret;

	ret = i2c_smbus_write_word_data(chip->client, reg << 1, val);

	if (ret < 0) {
		dev_err(&chip->client->dev, "failed writing register\n");
		return ret;
	}

	return 0;
}

static int pca9539_read_reg(struct pca9539_chip *chip, int reg, uint16_t *val)
{
	int ret;
	
	ret = i2c_smbus_read_word_data(chip->client, reg << 1);

	if (ret < 0) {
		dev_err(&chip->client->dev, "failed reading register\n");
		return ret;
	}

	*val = (uint16_t)ret;
	return 0;
}
static int pca9539_gpio_direction_input(unsigned off)
{
	struct pca9539_chip *chip;
	uint16_t reg_val;
	int ret;
	int save = off;
	
	if(M502_GPIO[save] >= 0 && M502_GPIO[save] <= 32) {
		
		off = M502_GPIO[save];
		
		chip = save_chip[off< 16 ? 0 : 1];
		if(off >= 16)
			off = off -16;
		reg_val = chip->reg_direction | (1u << off);
		ret = pca9539_write_reg(chip, PCA953X_DIRECTION, reg_val);
		if (ret)
			return ret;

		chip->reg_direction = reg_val;
	}else 
		at91_set_gpio_input(M502_GPIO[save], 0);
	
	M502_MODE[save] = 1;
	
	return 0;
}

int pca9539_gpio_direction_output(unsigned off, int val, int flag)
{
	struct pca9539_chip *chip;
	uint16_t reg_val;
	int ret;
	int save = off;
	
	if(flag == 1) {

		if(off < M504_TOTAL_GPIO)
		{
			if(M502_GPIO[save] >= 0 && M502_GPIO[save] <= 32) 
			{
				off = M502_GPIO[save];
			}
		}
	 }
	 
	if((off >= 0 && off <= 32 && M502_GPIO[save] >= 0 && M502_GPIO[save] <= 32)) {
		
		chip = save_chip[off < 16 ? 0 : 1];
		
		if(off >= 16)
			off = off -16;

		/* set output level */
		if (val)
			reg_val = chip->reg_output | (1u << off);
		else
			reg_val = chip->reg_output & ~(1u << off);
			

		ret = pca9539_write_reg(chip, PCA953X_OUTPUT, reg_val);
		if (ret)
			return ret;

		chip->reg_output = reg_val;

		/* then direction */
		reg_val = chip->reg_direction & ~(1u << off);
		ret = pca9539_write_reg(chip, PCA953X_DIRECTION, reg_val);
		if (ret)
			return ret;

		chip->reg_direction = reg_val;
		
	}else {
	
		if(flag) 
			at91_set_gpio_output(M502_GPIO[save], 0);
	}
	
	M502_MODE[save] = 0;
	
	return 0;
}

EXPORT_SYMBOL(pca9539_gpio_direction_output);

static int pca9539_gpio_get_value(unsigned off)
{
	struct pca9539_chip *chip;
	uint16_t reg_val;
	int ret;
	int save = off;
	if(M502_GPIO[save] >= 0 && M502_GPIO[save] <= 32) {
		
		off = M502_GPIO[save];
		
		chip = save_chip[off < 16 ? 0 : 1];
		
		if(off >= 16)
			off = off -16;
		ret = pca9539_read_reg(chip, PCA953X_INPUT, &reg_val);
		if (ret < 0) {
			/* NOTE:  diagnostic already emitted; that's all we should
			* do unless gpio_*_value_cansleep() calls become different
			* from their nonsleeping siblings (and report faults).
			*/
			return 0;
		}
		return (reg_val & (1u << off)) ? 1 : 0;
	}
	
	return at91_get_gpio_value(M502_GPIO[off]);

	
}

void pca9539_gpio_set_value(unsigned off, int val , int flag)
{
	struct pca9539_chip *chip;
	uint16_t reg_val;
	int ret;
	int save = off;
	
	if(flag == 1) {
		if(off < M504_TOTAL_GPIO)
		{
			if(M502_GPIO[save] >= 0 && M502_GPIO[save] <= 32) {
				off = M502_GPIO[save];
			}
		}
	}
	
	if(off >= 0 && off <= 32 && M502_GPIO[save] >= 0 && M502_GPIO[save] <= 32) {
		
		chip = save_chip[off < 16 ? 0 : 1];
		
		if(off >= 16)
			off = off -16;
		if (val)
			reg_val = chip->reg_output | (1u << off);
		else
			reg_val = chip->reg_output & ~(1u << off);

		ret = pca9539_write_reg(chip, PCA953X_OUTPUT, reg_val);
		if (ret)
			return;

		chip->reg_output = reg_val;
		
	}else{
	
		if(flag)
			at91_set_gpio_output(M502_GPIO[save], val);
	}
	
}

EXPORT_SYMBOL(pca9539_gpio_set_value);
/*
 * GPIO device is opened, and GPIO starts running.
 */
static int m502_gpio_open(struct inode *inode, struct file *file)
{
	//spin_lock(&gpio_lock);
	//gpio_open_cnt++;
	//spin_unlock(&gpio_lock);
	return 0;
}

/*
 * Close the GPIO device.
 * If CONFIG_GPIO_NOWAYOUT is NOT defined then the GPIO is also
 *  disabled.
 */
static int m502_gpio_close(struct inode *inode, struct file *file)
{
	//spin_lock(&gpio_lock);
	//spin_unlock(&gpio_lock);
	return 0;
}

/*
 * Handle commands from user-space.
 */
static int m502_gpio_ioctl(struct inode *inode, struct file *file,
		unsigned int cmd, unsigned long arg)
{
	void __user *argp = (void __user *)arg;
	int i = *((int __user *) argp);
	
	switch(cmd){
		case GPIO_IOCTL_COUNT:
			*((int __user *) argp) = M504_GPIO_COUNT; 
		return 0;
		case GPIO_IOCTL_DIPSW:
			*((int __user *) argp) = M504_GPIO_SW; 
		return 0;
		case GPIO_IOCTL_GET:
			i = *((int __user *) argp);
			if(i >= M504_TOTAL_GPIO)
				return -EINVAL;	
			if(M504_GPIO_COUNT > i)
				return pca9539_gpio_get_value(i);
			else {
				return at91_get_gpio_value(M502_GPIO[i]);
			}

		case GPIO_IOCTL_SET:
			i = *((int __user *) argp);
			if(i >= M504_GPIO_COUNT  )
				return -EINVAL;	

			if(M502_MODE[i] == 1)
				return -EINVAL;
			else
				pca9539_gpio_set_value(*((int __user *) argp),1,1);
			
		return 0;

		case GPIO_IOCTL_CLEAR:
			i = *((int __user *) argp);
			if(i >= M504_GPIO_COUNT  )
				return -EINVAL;	

			if(M502_MODE[i] == 1)
				return -EINVAL;
			else
				pca9539_gpio_set_value(*((int __user *) argp),0,1);
		return 0;
		
		case GPIO_IOCTL_OUTPUT:
			#if defined(CONFIG_MACH_PAC4010)
				return 1;
			#endif
			i = *((int __user *) argp);
			if(i >= M504_GPIO_COUNT )
				return -EINVAL;
			pca9539_gpio_direction_output(i,0,1);
			return 0;
			
		case GPIO_IOCTL_INPUT:
			#if defined(CONFIG_MACH_PAC4010)
				return 1;
			#endif
			i = *((int __user *) argp);
			//printk("%d\n",i);
			if(i >= M504_GPIO_COUNT)
				return -EINVAL;
			pca9539_gpio_direction_input(i);
			
			return 0;
		case	GPIO_IOCTL_MODE:
			i = *((int __user *) argp);
			if(i >= M504_TOTAL_GPIO)
				return -EINVAL;
				
			if(M504_GPIO_COUNT > i)
				return M502_MODE[i];
			else
				return 1;

		/*case 	GPIO_IOCTL_INPUT_SET:
			i = *((int __user *) argp);
			return at91_set_gpio_input(M504_GPIO_MAP[i][0], 1); 
		*/
		/*case	0xa001:
			for (i = M504_TOTAL_GPIO ; i >= 0 ; i--) {
				status <<= 1;
				if(at91_get_gpio_value(M504_GPIO_MAP[i]))
					status++;
			}
			*((unsigned long __user *) argp) = status; 
			return 0;*/		
		default:return -ENOIOCTLCMD; 
	}
	return -ENOIOCTLCMD;
}

/* ......................................................................... */

static struct file_operations m502gpio_fops =
{
	.owner		= THIS_MODULE,
	.ioctl		= m502_gpio_ioctl,
	.open		= m502_gpio_open,
	.release	= m502_gpio_close,
	//.read		= matrix500_gpio_read,
	//.write		= matrix500_gpio_write,
};

static struct miscdevice m502_gpio_miscdev =
{
	.minor		= GPIO_MINOR,
	.name		= "gpio",
	.fops		= &m502gpio_fops,	
};

static int __devinit pca9539_probe(struct i2c_client *client,
				   const struct i2c_device_id *id)
{
	
	int ret;

	if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C
				     | I2C_FUNC_SMBUS_BYTE_DATA|
				     I2C_FUNC_SMBUS_WORD_DATA)) {
		ret = -ENODEV;
		return -EINVAL;
	}

	save_chip[chips] = kzalloc(sizeof(struct pca9539_chip), GFP_KERNEL);
	if (save_chip[chips] == NULL)
		return -ENOMEM;

	save_chip[chips]->client = client;
	save_chip[chips]->gpio_start = id->driver_data;

	ret = pca9539_read_reg(save_chip[chips], PCA953X_OUTPUT, &save_chip[chips]->reg_output);
	if (ret)
		goto out_failed;

	ret = pca9539_read_reg(save_chip[chips], PCA953X_DIRECTION, &save_chip[chips]->reg_direction);
	if (ret)
		goto out_failed;

	ret = pca9539_write_reg(save_chip[chips], PCA953X_INVERT, 0);
	if (ret)
		goto out_failed;
	
	i2c_set_clientdata(client, save_chip[chips]);
	
	if(chips == 0) {
		
		chips = 1;
	}
	else {
		if(init_error == 0) {
			ret = misc_register(&m502_gpio_miscdev);
			if (ret)
				goto out_failed;
#if defined(CONFIG_MACH_PAC4010)
			for(ret = 0 ; ret < 8 ; ret++) {
					M502_MODE[ret] = 1;
					pca9539_gpio_direction_input(ret);
			}	
			for(ret = 8 ; ret < 16 ; ret++) {
					M502_MODE[ret] = 0;
					pca9539_gpio_direction_output(ret,0,1);
			}
			
			for(ret = 23 ; ret < 25 ; ret++) {
				pca9539_gpio_direction_output(ret , 1 , 0);
				pca9539_gpio_set_value(ret , 1, 0);
			}
#else	
			for(ret = 0 ; ret < M504_GPIO_COUNT ; ret++) {
					M502_MODE[ret] = 1;
					at91_set_gpio_input(M502_GPIO[ret], 0);
			}
			
			if(M504_GPIO_SW != 0) {
				for(ret = M504_GPIO_COUNT ; ret < M504_TOTAL_GPIO ; ret++)
						at91_set_gpio_input(M502_GPIO[ret], 1);
			}
				
			printk("M502 GPIO Driver Ver 1.03 Loaded.\n");
			
			/*START UART SETTING*/
#if defined(CONFIG_MACH_M502)
			for(ret = 24 ; ret < 32 ; ret+=2) {
				pca9539_gpio_direction_output(ret , 1 , 0);
				pca9539_gpio_set_value(ret , 1, 0);
			}
			pca9539_gpio_direction_output(25 , 0 , 0);
			pca9539_gpio_set_value(25 , 0 , 0);
#elif defined(CONFIG_MACH_MATRIX518)
			for(ret = 23 ; ret < 32 ; ret++) {
				pca9539_gpio_direction_output(ret , 1 , 0);
				pca9539_gpio_set_value(ret , 1, 0);
			}
#elif defined(CONFIG_MACH_MATRIX522)
			for(ret = 23 ; ret < 25 ; ret++) {
				pca9539_gpio_direction_output(ret , 1 , 0);
				pca9539_gpio_set_value(ret , 1, 0);
			}
#endif
			/*END UART SETTING*/
#endif
		}
	}
	return 0;

out_failed:
	init_error = 1;
	if(chips == 0) {
		chips = 1;
	}
	kfree(save_chip[chips]);
	return ret;
}

static int pca9539_remove(struct i2c_client *client)
{
	struct pca9539_chip *chip = i2c_get_clientdata(client);
	misc_deregister(&m502_gpio_miscdev);
	kfree(chip);
	return 0;
}

static struct i2c_driver pca9539_driver = {
	.driver = {
		.name	= "pca9539",
	},
	.probe		= pca9539_probe,
	.remove		= pca9539_remove,
	.id_table	= pca9539_id,
};

static int __init m502_gpio_init(void)
{
	return i2c_add_driver(&pca9539_driver);
}

static void __exit m502_gpio_exit(void)
{
	i2c_del_driver(&pca9539_driver);
	
}

module_init(m502_gpio_init);
module_exit(m502_gpio_exit);

MODULE_LICENSE("GPL")
MODULE_AUTHOR("Ace Yang")
MODULE_DESCRIPTION("GPIO driver for M502 based on AT91SAM9G20")

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Philippe Gerum]

On 03/21/2012 03:41 PM, Glen Wernersbach wrote:
> Hi guys,
>
> One thing about both of these drivers is they have been modified to set some
> GPIO pins.
>
> The come down to the pca9539_gpio_set_value() in this file.
>
> Do you see any reason why those would not take under Xenomai?

If these are input GPIOs to deliver IRQs, yes, in which case this might 
be a problem with the interrupt pipeline; as Gilles told you already, 
1.13 is fairly outdated.

But in that case, you should see the problem even with CONFIG_XENOMAI* 
fully disabled, provided CONFIG_IPIPE is still on.

If you don't, meaning that something in the Xenomai core does make a 
difference, then you could try disabling all Xenomai interfaces (i.e. 
CONFIG_XENO_OPEN_SKIN_RTDM, .._NATIVE, .._POSIX, etc.), only leaving the 
core enabled.

>
> Glen
>
>
> On 3/21/12 4:38 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>
>> On 03/21/2012 05:46 AM, Glen Wernersbach wrote:
>>> I am going to start trying to see if I can figure out what is not getting
>>> set.
>>>
>>
>> You could get useful information from the pipeline tracer, by enabling
>> CONFIG_IPIPE_TRACE, observing what exactly happens in kernel space from
>> the issuing of the ioctl() syscall until the the read() syscall on the
>> serial link.
>>
>> You could set markers using Xenomai's I-pipe trace API in userland to
>> highlight portions of interest in your app code, freezing the capture to
>> snapshot a particular moment in the execution timeline. See
>> http://xenomai.org/index.php/I-pipe:Tracer.
>>
>> NOTE: pay attention to the value in /proc/ipipe/trace/back_trace_points
>> to hold enough data.
>>
>>> By the way. This board also has 4 other serial ports on a 8250.c driver. It
>>> also fails under the xeno build.
>>>
>>>
>>>
>>>
>>> On 3/20/12 4:35 PM, "Gilles Chanteperdrix"
>>> <gilles.chanteperdrix@xenomai.org>   wrote:
>>>
>>>> On 03/20/2012 09:19 PM, Glen Wernersbach wrote:
>>>>> I actually think in is in the settings because if run just the setup part
>>>>> of
>>>>> the code without reading and writing, on the kernel that works my activity
>>>>> LED turns off.
>>>>>
>>>>> On the xeno kernel the LED never changes.
>>>>
>>>> I actually think that CONFIG_XENO_OPT_PERVASIVE does not make any
>>>> difference which could cause a difference of hardware behaviour. So, it
>>>> must be another option triggered by this config change. So, if you want
>>>> us to help you, please post the .configs.
>>>>
>>>
>>
>


-- 
Philippe.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

I did disable everything except pervasive and the problem happened.

I disabled pervasive also, it went away.


I can try turning pervasive off and ipipe on and see what happens.
--
Glen Wernersbach
President & CTO
Jetsoft Development Co
629 Old St. Rt. 74 - Suite 210
Cincinnati Ohio 45244
Custom Programming Web Site: www.JetsoftDev.com
Retail Product Web Site: www.ScanHelp.com
Phone: 513-528-6660
Fax: 513-528-3470

On Mar 21, 2012, at 11:07 AM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/21/2012 03:41 PM, Glen Wernersbach wrote:
>> Hi guys,
>> 
>> One thing about both of these drivers is they have been modified to set some
>> GPIO pins.
>> 
>> The come down to the pca9539_gpio_set_value() in this file.
>> 
>> Do you see any reason why those would not take under Xenomai?
> 
> If these are input GPIOs to deliver IRQs, yes, in which case this might be a problem with the interrupt pipeline; as Gilles told you already, 1.13 is fairly outdated.
> 
> But in that case, you should see the problem even with CONFIG_XENOMAI* fully disabled, provided CONFIG_IPIPE is still on.
> 
> If you don't, meaning that something in the Xenomai core does make a difference, then you could try disabling all Xenomai interfaces (i.e. CONFIG_XENO_OPEN_SKIN_RTDM, .._NATIVE, .._POSIX, etc.), only leaving the core enabled.
> 
>> 
>> Glen
>> 
>> 
>> On 3/21/12 4:38 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>> 
>>> On 03/21/2012 05:46 AM, Glen Wernersbach wrote:
>>>> I am going to start trying to see if I can figure out what is not getting
>>>> set.
>>>> 
>>> 
>>> You could get useful information from the pipeline tracer, by enabling
>>> CONFIG_IPIPE_TRACE, observing what exactly happens in kernel space from
>>> the issuing of the ioctl() syscall until the the read() syscall on the
>>> serial link.
>>> 
>>> You could set markers using Xenomai's I-pipe trace API in userland to
>>> highlight portions of interest in your app code, freezing the capture to
>>> snapshot a particular moment in the execution timeline. See
>>> http://xenomai.org/index.php/I-pipe:Tracer.
>>> 
>>> NOTE: pay attention to the value in /proc/ipipe/trace/back_trace_points
>>> to hold enough data.
>>> 
>>>> By the way. This board also has 4 other serial ports on a 8250.c driver. It
>>>> also fails under the xeno build.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 3/20/12 4:35 PM, "Gilles Chanteperdrix"
>>>> <gilles.chanteperdrix@xenomai.org>   wrote:
>>>> 
>>>>> On 03/20/2012 09:19 PM, Glen Wernersbach wrote:
>>>>>> I actually think in is in the settings because if run just the setup part
>>>>>> of
>>>>>> the code without reading and writing, on the kernel that works my activity
>>>>>> LED turns off.
>>>>>> 
>>>>>> On the xeno kernel the LED never changes.
>>>>> 
>>>>> I actually think that CONFIG_XENO_OPT_PERVASIVE does not make any
>>>>> difference which could cause a difference of hardware behaviour. So, it
>>>>> must be another option triggered by this config change. So, if you want
>>>>> us to help you, please post the .configs.
>>>>> 
>>>> 
>>> 
>> 
> 
> 
> -- 
> Philippe.
> 

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Philippe Gerum]

On 03/20/2012 03:07 PM, Glen Wernersbach wrote:
> I went through and disabled everything in xeno except
> CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it works.
>
> Take that option out at anytime it works.
>
> My program basic writes a few characters a serial port and then reads them
> back in from the same port. I have a loop back cable connected to the port.
>
> It writes the data but waits forever to read them back in
>
>> From my tests, it appears that the termois tcsetaddr settings is not getting
> set when I call it when this option is on.

Does this mean you received an error code from tcsetattr()? Or are you 
inferring this from the fact that you don't get any input from the 
serial link?

>
>
>
>
>
>
> On 3/20/12 9:57 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>
>> On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
>>> I don't think this is it directly.
>>>
>>> This program was made on the same kernel prior to patching it with Xeno.
>>>
>>> It should still run like any other linux program.
>>
>> - what does "program not working" mean in your case? Any errno return we
>> could interpret? Any strace output?
>>
>> - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on?
>>
>>
>>>
>>>
>>>
>>>
>>> On 3/20/12 9:44 AM, "Philippe Gerum"<rpm@xenomai.org>   wrote:
>>>
>>>> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>>>>> Hi All,
>>>>>
>>>>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when
>>>>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux
>>>>> serial write then read serial program does not work.
>>>>>
>>>>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.
>>>>>
>>>>> Any ideas why?????
>>>>>
>>>>
>>>> A possible explanation would be that your application links with the
>>>> Xenomai POSIX lib (libpthread_rt), albeit it should not.
>>>>
>>>> With pervasive support disabled, any routing from the overloaded POSIX
>>>> I/O calls to the Xenomai kernel would then fail.
>>>>
>>>> If so, you should not link against the Xenomai libs if you need no -rt
>>>> service, or prevent symbol wrapping only for the POSIX I/O calls by
>>>> prefixing them by __real_* if you want Xenomai-enabled POSIX services
>>>> except the I/O support.
>>>>
>>>> See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
>>>>
>>>>>
>>>>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
>>>>> CC kernel/xenomai/nucleus/synch.o
>>>>> kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread':
>>>>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
>>>>> function 'xnthread_get_rescnt'
>>>>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
>>>>> function 'xnshadow_send_sig'
>>>>>
>>>>> I had to go in and make the code for that option befor it always false.
>>>>>
>>>>
>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a788b
>>>> 76
>>>> 2b5cf662b1d4108
>>>>
>>>>
>>>>> Glen
>>>>> --
>>>>> Glen Wernersbach
>>>>> President&   CTO
>>>>>
>>>>> Jetsoft Development Co.
>>>>> 629 Old St Rt. 74 ­ Suite 210
>>>>> Cincinnati, Oh 45244
>>>>> Custom Programming Web Site: www.jetsoftdev.com
>>>>> Retail Products Web Site: www.scanhelp.com
>>>>> Phone: 513-528-6660
>>>>> Fax: 513-528-3470
>>>>> Cell 513-240-9929
>>>>> ----
>>>>> Partner for Software Technology
>>>>> Jacobs Automation
>>>>> 2365 Progress Drive
>>>>> Hebron, KY 41048
>>>>> (513) 297-7550
>>>>> ----
>>>>> "Support Dyslexia Research"
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xenomai-help mailing list
>>>>> Xenomai-help@domain.hid
>>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>
>>>
>>
>


-- 
Philippe.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

I don't get any error from anything.

I just don't get anything back from the read command.

This is how the program behaved without the tcsetaddr command previously.




On 3/20/12 12:22 PM, "Philippe Gerum" <rpm@xenomai.org> wrote:

> On 03/20/2012 03:07 PM, Glen Wernersbach wrote:
>> I went through and disabled everything in xeno except
>> CONFIG_XENO_OPT_PERVASIVE, did not work. Take that option out and it works.
>> 
>> Take that option out at anytime it works.
>> 
>> My program basic writes a few characters a serial port and then reads them
>> back in from the same port. I have a loop back cable connected to the port.
>> 
>> It writes the data but waits forever to read them back in
>> 
>>> From my tests, it appears that the termois tcsetaddr settings is not getting
>> set when I call it when this option is on.
> 
> Does this mean you received an error code from tcsetattr()? Or are you
> inferring this from the fact that you don't get any input from the
> serial link?
> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 3/20/12 9:57 AM, "Philippe Gerum"<rpm@xenomai.org>  wrote:
>> 
>>> On 03/20/2012 02:48 PM, Glen Wernersbach wrote:
>>>> I don't think this is it directly.
>>>> 
>>>> This program was made on the same kernel prior to patching it with Xeno.
>>>> 
>>>> It should still run like any other linux program.
>>> 
>>> - what does "program not working" mean in your case? Any errno return we
>>> could interpret? Any strace output?
>>> 
>>> - what if you disable CONFIG_XENO_OPT_SKIN_RTDM, leaving PERVASIVE on?
>>> 
>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 3/20/12 9:44 AM, "Philippe Gerum"<rpm@xenomai.org>   wrote:
>>>> 
>>>>> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when
>>>>>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux
>>>>>> serial write then read serial program does not work.
>>>>>> 
>>>>>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.
>>>>>> 
>>>>>> Any ideas why?????
>>>>>> 
>>>>> 
>>>>> A possible explanation would be that your application links with the
>>>>> Xenomai POSIX lib (libpthread_rt), albeit it should not.
>>>>> 
>>>>> With pervasive support disabled, any routing from the overloaded POSIX
>>>>> I/O calls to the Xenomai kernel would then fail.
>>>>> 
>>>>> If so, you should not link against the Xenomai libs if you need no -rt
>>>>> service, or prevent symbol wrapping only for the POSIX I/O calls by
>>>>> prefixing them by __real_* if you want Xenomai-enabled POSIX services
>>>>> except the I/O support.
>>>>> 
>>>>> See http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai
>>>>> 
>>>>>> 
>>>>>> Also, when you turn CONFIG_XENO_OPT_PERVASIVE you get this error:
>>>>>> CC kernel/xenomai/nucleus/synch.o
>>>>>> kernel/xenomai/nucleus/synch.c: In function 'xnsynch_release_thread':
>>>>>> kernel/xenomai/nucleus/synch.c:688:3: error: implicit declaration of
>>>>>> function 'xnthread_get_rescnt'
>>>>>> kernel/xenomai/nucleus/synch.c:689:4: error: implicit declaration of
>>>>>> function 'xnshadow_send_sig'
>>>>>> 
>>>>>> I had to go in and make the code for that option befor it always false.
>>>>>> 
>>>>> 
>>>>> http://git.xenomai.org/?p=xenomai-2.6.git;a=commit;h=41b4f9c0f4bdf06107a78
>>>>> 8b
>>>>> 76
>>>>> 2b5cf662b1d4108
>>>>> 
>>>>> 
>>>>>> Glen
>>>>>> --
>>>>>> Glen Wernersbach
>>>>>> President&   CTO
>>>>>> 
>>>>>> Jetsoft Development Co.
>>>>>> 629 Old St Rt. 74 ­ Suite 210
>>>>>> Cincinnati, Oh 45244
>>>>>> Custom Programming Web Site: www.jetsoftdev.com
>>>>>> Retail Products Web Site: www.scanhelp.com
>>>>>> Phone: 513-528-6660
>>>>>> Fax: 513-528-3470
>>>>>> Cell 513-240-9929
>>>>>> ----
>>>>>> Partner for Software Technology
>>>>>> Jacobs Automation
>>>>>> 2365 Progress Drive
>>>>>> Hebron, KY 41048
>>>>>> (513) 297-7550
>>>>>> ----
>>>>>> "Support Dyslexia Research"
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Xenomai-help mailing list
>>>>>> Xenomai-help@domain.hid
>>>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>> 
>>>> 
>>> 
>> 
> 

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Gilles Chanteperdrix]

On 03/20/2012 05:32 PM, Glen Wernersbach wrote:
> I don't get any error from anything.

You do not know that, as you do not check write return value.

Any chance to see the driver code? Without that, I am afraid we can not
help.

-- 
					    Gilles.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

I added an error check. Passed.

Just sent driver code.

--
Glen Wernersbach
President & CTO
Jetsoft Development Co
629 Old St. Rt. 74 - Suite 210
Cincinnati Ohio 45244
Custom Programming Web Site: www.JetsoftDev.com
Retail Product Web Site: www.ScanHelp.com
Phone: 513-528-6660
Fax: 513-528-3470

On Mar 20, 2012, at 12:42 PM, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.orgomai.org> wrote:

> On 03/20/2012 05:32 PM, Glen Wernersbach wrote:
>> I don't get any error from anything.
> 
> You do not know that, as you do not check write return value.
> 
> Any chance to see the driver code? Without that, I am afraid we can not
> help.
> 
> -- 
>                        Gilles.
> 

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Gilles Chanteperdrix]

On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
> Hi All,
> 
> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when
> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux serial
> write then read serial program does not work.
> 
> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.

Do you get a message on the kernel console about characters lost on
serial device? These seems to be more frequent when the interrupt
pipeline delays the interrupt than without the interrupt pipeline, but
always exists.

-- 
					    Gilles.

Re: [Xenomai-help] Linux Serial Does not work with CONFIG_XENO_OPT_PERVASIVE enabled

[Glen Wernersbach]

As far as I can tell, no kernel messages what so ever.



On 3/20/12 10:50 AM, "Gilles Chanteperdrix"
<gilles.chanteperdrix@xenomai.org> wrote:

> On 03/20/2012 02:28 PM, Glen Wernersbach wrote:
>> Hi All,
>> 
>> I install Xenomai 2.6.0 on AT91SAM9G20 system and have found that when
>> CONFIG_XENO_OPT_PERVASIVE is enabled my standard non real time linux serial
>> write then read serial program does not work.
>> 
>> If I turn off CONFIG_XENO_OPT_PERVASIVE, my serial program does work.
> 
> Do you get a message on the kernel console about characters lost on
> serial device? These seems to be more frequent when the interrupt
> pipeline delays the interrupt than without the interrupt pipeline, but
> always exists.

-- 
Glen Wernersbach
President & CTO

Jetsoft Development Co.
629 Old St Rt. 74 ­ Suite 210
Cincinnati, Oh 45244
Custom Programming Web Site: www.jetsoftdev.com
Retail Products Web Site: www.scanhelp.com
Phone:   513-528-6660
Fax: 513-528-3470
Cell 513-240-9929
----
Partner for Software Technology
Jacobs Automation
2365 Progress Drive
Hebron, KY 41048 
(513) 297-7550
----
"Support Dyslexia Research"