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
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.
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.
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
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.
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.