EmbDev.net

Forum: ARM programming with GCC/GNU tools ARM Integrator/CP and general portability


Author: Jakob Holderbaum (holderbaum)
Posted on:

Rate this post
0 useful
not useful
Hi folks,

I started some simulations with QEMU, targeting developments for the ARM
architecture.

The list of supported architectures and development boards presents the 
(in the title stated) Integrator/CP board as one of the leanest eval. 
boards, regarding to the amount of external hardware.

In the context of my masters thesis I'm building a virtual prototype of 
a distributes measurement system. In the current evaluation phase I am 
thinking about different hardware architectures for the implementation 
of the nodes of the measurement network.

Now to my core question. How big is the difference between the ARM 
Integrator/CP and other distinct ARM926E architecture implementations 
from Atmel or other companies.

Since I am experienced in embedded development/hardware engineering but 
totally new to the ARM-based architecture, I am lacking the professional 
competence to evaluate the extend of the differences between the various 
implementations of this architecture.

The features I need to use boil basically down to one or two UARTs and a 
general amount of GPIO, so no fancy CPU related stuff.

Maybe it is possible to write the firmware in such an encapsulated way, 
that a platform switch only impacts the mapping of the used registers 
and a customization of the linker script and the startup assembler?

Please provide me with your experiences on portability in the context of 
ARM.

Cheers and thanks in advance
Jakob

: Edited by User
Author: Dr. Sommer (Guest)
Posted on:

Rate this post
0 useful
not useful
Jakob Holderbaum wrote:
> The features I need to use boil basically down to one or two UARTs and a
> general amount of GPIO, so no fancy CPU related stuff.
That CPU related stuff is hardly a problem, the UART and GPIO stuff, 
however, is:

The processor core of all implementations of a single ARM architecture 
such as ARM926 (which is old/deprecated, btw) is identical from the 
software viewpoint (i.e. instruction set etc.). There are some 
variations of supported features (such as FPU, Jazelle, MMU, ...), these 
should be documented in the ARMv5 Architecture Reference Manual. So if 
you take care which of those features you use, your code should be 
binary-compatible to all implementations supporting the respective 
features.

Peripherals, such as UART and GPIO pins, are a different story; every 
microcontroller manufacturer defines his own peripherals and interfaces 
to the processor core. If you want your code to be portable across 
multiple implementations, you need to define an abstraction layer around 
the peripheral accesses, and exchange its implementation depending on 
the microcontroller you wish to compile for. There are ready made 
libraries and RTOS that do this.

Remember, ARM only defines processor cores, and not peripherals like 
UART and GPIO.

Author: Dr. Sommer (Guest)
Posted on:

Rate this post
0 useful
not useful
PS: Why don't you build an actual, instead of a virtual, prototype with 
a lean, cheap and also modern eval board such as the STM32F4 Discovery 
Board (Cortex-M4F, ARMv7M, ~15€) while encapsulating the hardware 
accesses into an exchangeable hardware access layer? This allows you to 
use the modern ARMv7M architecture, gets rid of the need for platform 
support by qemu and allows you to presend an actual prototype. Keil 
µVision should also include a simulator for that platform, IIRC.

Author: Jakob Holderbaum (holderbaum)
Posted on:

Rate this post
0 useful
not useful
Hi Dr. Sommer and thanks for your detailed replies.

Your explanation of the ARM architecture makes sense, the abstractions 
for the hardware access you mentioned where kind of the planned way to 
go for me.

I thought about building an actual prototype, but since I want to create 
a distributed system, this setup would become rather big.

My fear is, that the whole debugging process of a physical 
implementation with a shared BUS and multiple controllers will consume 
much more time than running on emulated hardware.

I got the impression, that debugging possibilities are more extensive on 
a virtual platform. Pleae correct me if I am wrong with one of my theses 
here.

You made a strong point with "[..] and allows you to presend an actual 
prototype", I must truly admit that. :)

Have a nice day
Jakob

: Edited by User
Author: Dr. Sommer (Guest)
Posted on:

Rate this post
0 useful
not useful
Jakob Holderbaum wrote:
> I got the impression, that debugging possibilities are more extensive on
> a virtual platform. Pleae correct me if I am wrong with one of my theses
> here.
I don't know about the virtual platform, but on the Cortex-M devices you 
can do step-by-step debugging, code breakpoints, data watchpoints, 
memory examining, and some tracing stuff i don't know much about. This 
might already be sufficient.,,

Jakob Holderbaum wrote:
> My fear is, that the whole debugging process of a physical
> implementation with a shared BUS and multiple controllers will consume
> much more time than running on emulated hardware.
The question is whether working with an emulator is more 
straight-forward. The compiling & linking stuff is probably equivalent, 
but with an actual prototype you can interface actual hardware such as 
LCD's, sensors etc.

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.