Hello,
I'm going to start the porting of Orocos RTT 2.3 to the ARM Cortex-A8/A9
(ARMv7 instruction set). I know that there's a "arm-port" branch in peter's
github account for Orocos 1.x. From what I remember, there had been
discussions about atomic operations that used irq_save and irq_restore. For
ARMv6 architecture and over, there seems to exist atomic operations
involving exclusive load/store instead of irqs. My plan is to re-use these
atomic operations from the linux kernel to implement the orocos atomic
operations. Does anyone has any concerns about this implementation because
it would require a ARMv6 architecture or over?
Philippe
Porting Orocos 2.3 to ARM Cortex-A8 and A9-MPcore
On 03/30/2011 07:52 PM, Philippe Hamelin wrote:
> Hello,
>
> I'm going to start the porting of Orocos RTT 2.3 to the ARM Cortex-A8/A9
> (ARMv7 instruction set). I know that there's a "arm-port" branch in
> peter's github account for Orocos 1.x. From what I remember, there had
> been discussions about atomic operations that used irq_save and
> irq_restore. For ARMv6 architecture and over, there seems to exist
> atomic operations involving exclusive load/store instead of irqs. My
> plan is to re-use these atomic operations from the linux kernel to
> implement the orocos atomic operations. Does anyone has any concerns
> about this implementation because it would require a ARMv6 architecture
> or over?
Do you plan to run on ARM and linux, or without any OS ? Or a
microcontroller-specific kernel ?
In the first case, a project at DFKI already runs RTT on gumstix using
omniorb and it works fine (including some image processing). Obviously,
they are not using lock-free data structures ;-)
Sylvain
Porting Orocos 2.3 to ARM Cortex-A8 and A9-MPcore
2011/4/1 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 03/30/2011 07:52 PM, Philippe Hamelin wrote:
>
>> Hello,
>>
>> I'm going to start the porting of Orocos RTT 2.3 to the ARM Cortex-A8/A9
>> (ARMv7 instruction set). I know that there's a "arm-port" branch in
>> peter's github account for Orocos 1.x. From what I remember, there had
>> been discussions about atomic operations that used irq_save and
>> irq_restore. For ARMv6 architecture and over, there seems to exist
>> atomic operations involving exclusive load/store instead of irqs. My
>> plan is to re-use these atomic operations from the linux kernel to
>> implement the orocos atomic operations. Does anyone has any concerns
>> about this implementation because it would require a ARMv6 architecture
>> or over?
>>
>
> Do you plan to run on ARM and linux, or without any OS ? Or a
> microcontroller-specific kernel ?
>
> In the first case, a project at DFKI already runs RTT on gumstix using
> omniorb and it works fine (including some image processing). Obviously, they
> are not using lock-free data structures ;-)
>
>
We are going to use Linux. We will also use OmniORB, since it's small and
almost easy to cross-compile. I integrated Boost, OmniORB, Orocos
log4cpp/rtt/ocl to buildroot in order to automate the deployment process on
an embedded platform. It worked fine for our Xilinx Virtex-5 platform
(PPC440), but new projects are going on ARM. For the next year, we will
develop on the Beagleboard xM (Cortex-A8) and the Pandaboard (Cortex
A9-MPcore), but the long-term plan is to use the Xilinx Zynq 7000 [1] when
it will become available (2012). I will try to implement the atomic
operations to enable lock-free mechanism. I will gladly share these patches
with the community.
[1] http://www.xilinx.com/technology/roadmap/processing-platform.htm
Philippe
Porting Orocos 2.3 to ARM Cortex-A8 and A9-MPcore
On Apr 1, 2011, at 09:08 , Philippe Hamelin wrote:
> 2011/4/1 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 03/30/2011 07:52 PM, Philippe Hamelin wrote:
> Hello,
>
> I'm going to start the porting of Orocos RTT 2.3 to the ARM Cortex-A8/A9
> (ARMv7 instruction set). I know that there's a "arm-port" branch in
> peter's github account for Orocos 1.x. From what I remember, there had
> been discussions about atomic operations that used irq_save and
> irq_restore. For ARMv6 architecture and over, there seems to exist
> atomic operations involving exclusive load/store instead of irqs. My
> plan is to re-use these atomic operations from the linux kernel to
> implement the orocos atomic operations. Does anyone has any concerns
> about this implementation because it would require a ARMv6 architecture
> or over?
>
> Do you plan to run on ARM and linux, or without any OS ? Or a microcontroller-specific kernel ?
>
> In the first case, a project at DFKI already runs RTT on gumstix using omniorb and it works fine (including some image processing). Obviously, they are not using lock-free data structures ;-)
>
>
> We are going to use Linux. We will also use OmniORB, since it's small and almost easy to cross-compile. I integrated Boost, OmniORB, Orocos log4cpp/rtt/ocl to buildroot in order to automate the deployment process on an embedded platform. It worked fine for our Xilinx Virtex-5 platform (PPC440), but new projects are going on ARM. For the next year, we will develop on the Beagleboard xM (Cortex-A8) and the Pandaboard (Cortex A9-MPcore), but the long-term plan is to use the Xilinx Zynq 7000 [1] when it will become available (2012). I will try to implement the atomic operations to enable lock-free mechanism. I will gladly share these patches with the community.
>
> [1] http://www.xilinx.com/technology/roadmap/processing-platform.htm
>
> Philippe
We are interested in this effort. I investigated this very avenue of development (Orocos + OmniORB + Boost) a few months back, with an eye to getting Orocos + CORBA running on an iPad. It certainly seemed doable, we just didn't have the resources available at the time ...
S
Porting Orocos 2.3 to ARM Cortex-A8 and A9-MPcore
On Wednesday 30 March 2011 19:52:52 Philippe Hamelin wrote:
> Hello,
>
> I'm going to start the porting of Orocos RTT 2.3 to the ARM Cortex-A8/A9
> (ARMv7 instruction set). I know that there's a "arm-port" branch in peter's
> github account for Orocos 1.x. From what I remember, there had been
> discussions about atomic operations that used irq_save and irq_restore. For
> ARMv6 architecture and over, there seems to exist atomic operations
> involving exclusive load/store instead of irqs. My plan is to re-use these
> atomic operations from the linux kernel to implement the orocos atomic
> operations. Does anyone has any concerns about this implementation because
> it would require a ARMv6 architecture or over?
I think your plan is ok. although I have no experience with ARM architectures.
How would you communicate with that device ? Using CORBA? Since Diamondback,
ROS got much more modular and might be easier to port as a transport to other
architectures/OS'es. They manage that with the eros tools, which manages cmake
toolchain files and building dependencies.
Peter
Porting Orocos 2.3 to ARM Cortex-A8 and A9-MPcore
2011/4/1 Peter Soetens <peter [..] ...>
> On Wednesday 30 March 2011 19:52:52 Philippe Hamelin wrote:
> > Hello,
> >
> > I'm going to start the porting of Orocos RTT 2.3 to the ARM Cortex-A8/A9
> > (ARMv7 instruction set). I know that there's a "arm-port" branch in
> peter's
> > github account for Orocos 1.x. From what I remember, there had been
> > discussions about atomic operations that used irq_save and irq_restore.
> For
> > ARMv6 architecture and over, there seems to exist atomic operations
> > involving exclusive load/store instead of irqs. My plan is to re-use
> these
> > atomic operations from the linux kernel to implement the orocos atomic
> > operations. Does anyone has any concerns about this implementation
> because
> > it would require a ARMv6 architecture or over?
>
> I think your plan is ok. although I have no experience with ARM
> architectures.
> How would you communicate with that device ? Using CORBA? Since
> Diamondback,
> ROS got much more modular and might be easier to port as a transport to
> other
> architectures/OS'es. They manage that with the eros tools, which manages
> cmake
> toolchain files and building dependencies.
We are going to use CORBA with OmniORB. Although ROS is becoming
increasingly popular, we do not see yet see the value of considering it
since Orocos almost meets 100% our actual needs. Also, we're a little
reluctant to add another framework in our systems. As you know, each
additional dependency requires staff training, long-term maintenance, etc..
So there should be a very significant gain to justify that.
Philippe