Running the same binary code on the ARM Cortex M family

Hi

I am looking into using the ARM Cortex M family for a new project. I
like the Cortex M series, since in "principle" code should be pretty
simelar from one device to another, if you limit the functionality to
the core and some limited periphials.

Just released is the M0+ with only 9uA/MHz current consumption and
that would fit well for a small application.

So, if it is possible to define the allowed instruction set for the
M0+, would it then be possible to scale up to a larger device (M0, M1,
M3, M4) without recompiling core code?

That would allow us to use a OS with a API layer (to provide
flexibility between the periphial differences), and have the core code
running with the same binary code across the M family?

Anyone have practical experience with porting code this way?

Thanks

Klaus

Kvik wrote:
>I am looking into using the ARM Cortex M family for a new project. I
>like the Cortex M series, since in "principle" code should be pretty
>simelar from one device to another, if you limit the functionality to
>the core and some limited periphials.

As things stand today, I would not expect the peripherals to be
compatible unless you are staying with a single vendor.

>So, if it is possible to define the allowed instruction set for the
>M0+, would it then be possible to scale up to a larger device (M0, M1,
>M3, M4) without recompiling core code?

>That would allow us to use a OS with a API layer (to provide
>flexibility between the periphial differences), and have the core code
>running with the same binary code across the M family?
>
>Anyone have practical experience with porting code this way?

Yes - We *do* recompile for different processors and chip vendors.
If you want your code to be 100% portable think of using a byte code
interpreter. (Forth, Java, Lua, .NET, etc.)
--
Roberto Waltman

[ Please reply to the group,
return address is invalid ]

On 24 Apr., 14:48, Roberto Waltman <use...@rwaltman.com> wrote:
> *Kvik *wrote:
> >I am looking into using the ARM Cortex M family for a new project. I
> >like the Cortex M series, since in "principle" code should be pretty
> >simelar from one device to another, if you limit the functionality to
> >the core and some limited periphials.
>
> As things stand today, I would not expect the peripherals to be
> compatible unless you are staying with a single vendor.
>
> >So, if it is possible to define the allowed instruction set for the
> >M0+, would it then be possible to scale up to a larger device (M0, M1,
> >M3, M4) without recompiling core code?
> >That would allow us to use a OS with a API layer (to provide
> >flexibility between the periphial differences), and have the core code
> >running with the same binary code across the M family?
>
> >Anyone have practical experience with porting code this way?
>
> Yes - We *do* recompile for different processors and chip vendors.
> If you want your code to be 100% portable think of using a byte code
> interpreter. *(Forth, Java, Lua, .NET, etc.)
> --
> Roberto Waltman
>
> [ Please reply to the group,
> * return address is invalid ]

Well, we have looked at Java Card (developed for ATM cards), but I
think the API is too much tailored for the Card business and we won't
have any use for it in a microcontroller solution.

We have looked at .NET Micro Framework, which is said to be able to
run on a Cortex M3 with 256kB Flash and 64kB RAM. But, it's not easy
finding references to anyone having used this on a small
microcontroller :-(

Thanks

Klaus

Kvik <> wrote:

>Hi
>
>I am looking into using the ARM Cortex M family for a new project. I
>like the Cortex M series, since in "principle" code should be pretty
>simelar from one device to another, if you limit the functionality to
>the core and some limited periphials.
>
>Just released is the M0+ with only 9uA/MHz current consumption and
>that would fit well for a small application.
>
>So, if it is possible to define the allowed instruction set for the
>M0+, would it then be possible to scale up to a larger device (M0, M1,
>M3, M4) without recompiling core code?

IIRC the machinecode is thumb2 for all these processors. You have to
check though.

>That would allow us to use a OS with a API layer (to provide
>flexibility between the periphial differences), and have the core code
>running with the same binary code across the M family?
>
>Anyone have practical experience with porting code this way?

Yes. I use Eclipse as a C development IDE. Inside a project you can
have multiple targets. For some devices I designed I had up to 10
different types of firmware which in theory(*) could run on two
hardware versions. One hardware version had an ARM7TDMI the other
Cortex M3. There are always differences between microcontrollers so
its difficult to have one library to cover all. I never create
libraries for hardware handling; its much easier to just copy them
into a project.

(*) The reason for two hardware versions where limitations of the
hardware for version 1. Software that takes advantage of the extra
hardware on version 2 could not run on version 1.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

On 24 Apr., 14:33, Kvik <klaus.kragel...@gmail.com> wrote:
> Hi
>
> I am looking into using the ARM Cortex M family for a new project. I
> like the Cortex M series, since in "principle" code should be pretty
> simelar from one device to another, if you limit the functionality to
> the core and some limited periphials.
>
> Just released is the M0+ with only 9uA/MHz current consumption and
> that would fit well for a small application.
>
> So, if it is possible to define the allowed instruction set for the
> M0+, would it then be possible to scale up to a larger device (M0, M1,
> M3, M4) without recompiling core code?
>
> That would allow us to use a OS with a API layer (to provide
> flexibility between the periphial differences), and have the core code
> running with the same binary code across the M family?
>
> Anyone have practical experience with porting code this way?
>
> Thanks
>
> Klaus

as far as I understand M4 is a superset of M3 which is a super set of
M1/0
so I assume code that runs on M0 will run on all the other M*

But why not recompile?

-Lasse

On 24/04/2012 13:33, Kvik wrote:
> Hi
>
> I am looking into using the ARM Cortex M family for a new project. I
> like the Cortex M series, since in "principle" code should be pretty
> simelar from one device to another, if you limit the functionality to
> the core and some limited periphials.
>
> Just released is the M0+ with only 9uA/MHz current consumption and
> that would fit well for a small application.
>
> So, if it is possible to define the allowed instruction set for the
> M0+, would it then be possible to scale up to a larger device (M0, M1,
> M3, M4) without recompiling core code?
>
> That would allow us to use a OS with a API layer (to provide
> flexibility between the periphial differences), and have the core code
> running with the same binary code across the M family?
>
> Anyone have practical experience with porting code this way?
>
> Thanks
>
> Klaus

Sorry - my answer to this part went to your other thread as I didn't
realise there were two threads.

The M0 instruction set is a sub-set of the M3, which is a sub-set of the
M4. For example, there are instructions in the M0 that can only access
the low general purpose registers, whereas the M3 equivalents can access
all of them. The theory is they are backward binary compatible, but
only if you don't want the core to talk to anything else (peripherals) -
at which point changing chips will mean you have to recompile.


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 7000 downloads per month.

+ http://www.FreeRTOS.org/trace
15 interconnected trace views. An indispensable productivity tool.

> We have looked at .NET Micro Framework, which is said to be able to
> run on a Cortex M3 with 256kB Flash and 64kB RAM. But, it's not easy
> finding references to anyone having used this on a small
> microcontroller :-(

I always get a big chuckle when anybody says that. That and a one ton
feather.

JJS

Kvik <> wrote:

>On 24 Apr., 14:48, Roberto Waltman <use...@rwaltman.com> wrote:
>> =A0Kvik =A0wrote:
>> >I am looking into using the ARM Cortex M family for a new project. I
>> >like the Cortex M series, since in "principle" code should be pretty
>> >simelar from one device to another, if you limit the functionality to
>> >the core and some limited periphials.
>>
>> As things stand today, I would not expect the peripherals to be
>> compatible unless you are staying with a single vendor.
>>
>> >So, if it is possible to define the allowed instruction set for the
>> >M0+, would it then be possible to scale up to a larger device (M0, M1,
>> >M3, M4) without recompiling core code?
>> >That would allow us to use a OS with a API layer (to provide
>> >flexibility between the periphial differences), and have the core code
>> >running with the same binary code across the M family?
>>
>> >Anyone have practical experience with porting code this way?
>>
>> Yes - We *do* recompile for different processors and chip vendors.
>> If you want your code to be 100% portable think of using a byte code
>> interpreter. =A0(Forth, Java, Lua, .NET, etc.)
>> --
>> Roberto Waltman
>>
>> [ Please reply to the group,
>> =A0 return address is invalid ]
>
>Well, we have looked at Java Card (developed for ATM cards), but I
>think the API is too much tailored for the Card business and we won't
>have any use for it in a microcontroller solution.
>
>We have looked at .NET Micro Framework, which is said to be able to
>run on a Cortex M3 with 256kB Flash and 64kB RAM. But, it's not easy
>finding references to anyone having used this on a small
>microcontroller :-(

I don't think anyone uses that. I'd stay away from any MS product.
Before you know it it gets dropped.

I understand (in more than one way) you don't want to use C. Did you
look at this:

http://luaforge.net/projects/elua/

Lots of people use Lua these days.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------