EmbeddedRelated.com
Forums

Running the same binary code on the ARM Cortex M family

Started by Kvik April 24, 2012
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 ]
Kvik <klaus.kragelund@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?
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: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 :-( Thanks Klaus
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 <klaus.kragelund@gmail.com> 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=.) --------------------------------------------------------------