rtems-users Digest, Vol 13, Issue 35 (On Vacation August 27 - August 31)
Robert Deschambault
Robert.Deschambault at comdev.ca
Wed Oct 24 17:01:02 UTC 2007
Hi,
I will be away on vacation from Oct 24th to Oct 26st, returning to the office on Oct 29th.
Bob
>>> rtems-users 10/24/07 13:00 >>>
Send rtems-users mailing list submissions to
rtems-users at rtems.com
To subscribe or unsubscribe via the World Wide Web, visit
http://rtems.rtems.org/mailman/listinfo/rtems-users
or, via email, send a message with subject or body 'help' to
rtems-users-request at rtems.com
You can reach the person managing the list at
rtems-users-owner at rtems.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of rtems-users digest..."
Today's Topics:
1. Correct return values for _Objects_Get_class()? (Phil Torre)
2. Comtrol RocketPort Universal PCI (Arquer Stephane)
3. Re: Correct return values for _Objects_Get_class()?
(Joel Sherrill)
4. Re: Correct return values for _Objects_Get_class()?
(Joel Sherrill)
5. interrupt on arm9 (Rochat Jo?l)
----------------------------------------------------------------------
Message: 1
Date: Tue, 23 Oct 2007 12:40:49 -0700
From: Phil Torre <ptorre at zetron.com>
Subject: Correct return values for _Objects_Get_class()?
To: RTEMS User List <rtems-users at rtems.org>
Message-ID: <20071023194049.GD3813 at dharma.zetron.com>
Content-Type: text/plain; charset=us-ascii
I have a question about the _Objects_Get_class() utility function.
(RTEMS 4.6.0, on powerpc 8xx, custom BSP)
This comes up during a call to pthread_getspecific(). If called in the
context of a classic API task, _Objects_Get_class() returns 1. If
called from a POSIX thread, it returns 2. These seem to be in conflict
with the definition of type Object_APIs, which maps classic to 2 and
POSIX to 3. Which one is correct, or is there a subtle "off by one"
that is supposed to be there?
The reason I noticed is that when pthread_key_create() is called, it
allocates an array of key values for each API, and the size of each
array is taken from the current "maximum" value for that API. When
those allocations are made, they look correct. If I have 50 classic
tasks configured, I get ((50+1)*4) bytes of workspace allocated and
pointed to by the_key->Values[2]. It seems that pthread_key_create()
and pthread_getspecific() are in disagreement about the "class" part
of the object IDs.
Does anyone know why that is?
Thanks much,
-Phil
--
=====================================================================
Phil Torre phone: 425-820-6363 x234
Design Engineer email: ptorre at zetron.com
Switching Systems Group fax: 425-820-7031
Zetron, Inc. web: http://www.zetron.com
------------------------------
Message: 2
Date: Wed, 24 Oct 2007 09:46:25 +0200
From: "Arquer Stephane" <stephane.arquer at c-s.cnes.fr>
Subject: Comtrol RocketPort Universal PCI
To: <rtems-users at rtems.org>
Message-ID:
<092785B790DCD043BA45401EDA43D9B5F2622B at cst-xch-003.cnesnet.ad.cnes.fr>
Content-Type: text/plain; charset="us-ascii"
Hello,
For our project, we plan to use a Comtrol RocketPort UPCI plus quad/octa
(4 serial ports) with Rtems.
Does anyone have already use this board with Rtems or a similar one ?
Thanks.
sa
------------------------------
Message: 3
Date: Wed, 24 Oct 2007 06:37:10 -0500
From: Joel Sherrill <joel.sherrill at oarcorp.com>
Subject: Re: Correct return values for _Objects_Get_class()?
To: Phil Torre <ptorre at zetron.com>
Cc: RTEMS User List <rtems-users at rtems.org>
Message-ID: <471F2E66.5070402 at oarcorp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Phil Torre wrote:
> I have a question about the _Objects_Get_class() utility function.
>
> (RTEMS 4.6.0, on powerpc 8xx, custom BSP)
>
> This comes up during a call to pthread_getspecific(). If called in the
> context of a classic API task, _Objects_Get_class() returns 1. If
> called from a POSIX thread, it returns 2. These seem to be in conflict
> with the definition of type Object_APIs, which maps classic to 2 and
> POSIX to 3. Which one is correct, or is there a subtle "off by one"
> that is supposed to be there?
>
> The reason I noticed is that when pthread_key_create() is called, it
> allocates an array of key values for each API, and the size of each
> array is taken from the current "maximum" value for that API. When
> those allocations are made, they look correct. If I have 50 classic
> tasks configured, I get ((50+1)*4) bytes of workspace allocated and
> pointed to by the_key->Values[2]. It seems that pthread_key_create()
> and pthread_getspecific() are in disagreement about the "class" part
> of the object IDs.
>
> Does anyone know why that is?
>
Looks like an off by 1 case. Both set and get specific
need to subtract 1 from the number returned by
_Objects_Get_API from what I can tell at 6am.
If you are looking at a version that uses _Objects_Get_class
instead of _Objects_Get_API, then that is even more broken.
I see a log that I fixed that much in Nov 2006.
--joel
> Thanks much,
> -Phil
>
>
------------------------------
Message: 4
Date: Wed, 24 Oct 2007 08:48:41 -0500
From: Joel Sherrill <joel.sherrill at oarcorp.com>
Subject: Re: Correct return values for _Objects_Get_class()?
To: Phil Torre <ptorre at zetron.com>
Cc: RTEMS User List <rtems-users at rtems.org>
Message-ID: <471F4D39.3080006 at oarcorp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Joel Sherrill wrote:
> Phil Torre wrote:
>
>> I have a question about the _Objects_Get_class() utility function.
>>
>> (RTEMS 4.6.0, on powerpc 8xx, custom BSP)
>>
>> This comes up during a call to pthread_getspecific(). If called in the
>> context of a classic API task, _Objects_Get_class() returns 1. If
>> called from a POSIX thread, it returns 2. These seem to be in conflict
>> with the definition of type Object_APIs, which maps classic to 2 and
>> POSIX to 3. Which one is correct, or is there a subtle "off by one"
>> that is supposed to be there?
>>
>> The reason I noticed is that when pthread_key_create() is called, it
>> allocates an array of key values for each API, and the size of each
>> array is taken from the current "maximum" value for that API. When
>> those allocations are made, they look correct. If I have 50 classic
>> tasks configured, I get ((50+1)*4) bytes of workspace allocated and
>> pointed to by the_key->Values[2]. It seems that pthread_key_create()
>> and pthread_getspecific() are in disagreement about the "class" part
>> of the object IDs.
>>
>> Does anyone know why that is?
>>
>>
> Looks like an off by 1 case. Both set and get specific
> need to subtract 1 from the number returned by
> _Objects_Get_API from what I can tell at 6am.
>
I am wrong. The allocation does this to set the
pointer to the keys:
the_key->Values[ the_api ] = table;
where the_api = 1..OBJECTS_API_LAST. So the code
in get/set specific should directly use _Objects_Get_API.
I believe the current code in CVS and RTEMS 4.7 is correct.
The code for get/set specific in 4.6 is using class where it
should be using API.
> If you are looking at a version that uses _Objects_Get_class
> instead of _Objects_Get_API, then that is even more broken.
> I see a log that I fixed that much in Nov 2006.
>
Apparently this was fixed between 4.6 and 4.7 and was
not back ported to the 4.6 branch. For sure this is
NOT correct in 4.6.0. You could be suffering from other
bugs as well with 4.6.0 since we made it all the way
to 4.6.6. :-D
--joel
> --joel
>
>
>
>
>> Thanks much,
>> -Phil
>>
>>
>>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>
------------------------------
Message: 5
Date: Wed, 24 Oct 2007 16:55:44 +0200
From: Rochat Jo?l <jrochat at netplus.ch>
Subject: interrupt on arm9
To: rtems-users at rtems.org
Message-ID: <1193237744.471f5cf083606 at webmail.netplus.ch>
Content-Type: text/plain; charset=ISO-8859-1
Hello,
I'm relative young in rtems developpment. I'm using a board with an ARM9
(at91rm9200) cpu on it with csb337 as bsp.
The tools I've test such as event, timers, semaphores are working well. I
also managed to write some code to 'listen' to
an interrupt. I write this code manually :
void handlerIRQ (void) __attribute__ ((interrupt ("IRQ"))) ;
void handlerIRQ (void)
{
doIsr = TRUE ;
//clear irq
AT91C_BASE_AIC->AIC_EOICR = (1 << AT91C_ID_IRQ5) ;
AT91C_BASE_AIC->AIC_ICCR = (1 << AT91C_ID_IRQ5) ;
}
void initIRQ ()
{
//Level sensitivity and priority of interrupt
AT91C_BASE_AIC->AIC_SMR[AT91C_ID_IRQ5] =
AT91C_AIC_SRCTYPE_EXT_POSITIVE_EDGE | 1 ;
//give fonction to call when interrupt comes
AT91C_BASE_AIC->AIC_SVR[AT91C_ID_IRQ5] = (unsigned long)handlerIRQ ;
//enable irq
AT91C_BASE_AIC->AIC_IECR = (1 << AT91C_ID_IRQ5) ;
}
This code works fine. But I try now to use rtems interrupt tools. But I'm a
littel bit lost with it here is the code i used
//the isr routine
rtems_isr user_isr(rtems_vector_number vector)
{
gTick = TRUE ;
}
//the catch methode
status = rtems_interrupt_catch(user_isr, ARM_EXCEPTION_IRQ, &old_isr_handler) ;
//then unabled the irq for level 3
rtems_interrupt_enable(3) ;
When I launch this code on the board it stops one time in the isr routine.
Do I have to reste the interupt or somthing like that ?
Did someone use the at91rm9200 with interrupt ?
How can I say to RTEMS that I want to listen to IRQ5 for exemple ?
Think you have a nice day.
Joel R.
------------------------------
_______________________________________________
rtems-users mailing list
rtems-users at rtems.com
http://rtems.rtems.org/mailman/listinfo/rtems-users
End of rtems-users Digest, Vol 13, Issue 35
*******************************************
More information about the users
mailing list