I would like to know which is a better (in performance) option :
To get a Intel Dual core atom based board
To get a Arm cortex A9 based board (pandaboard etc)
I would like to run some light version of linux and do some very cpu intensive
computations like Image/Video processing (maybe 3D later) and also process audio
on them. Of-course all floating point mathematics.
Definitely #2, Pandaboard is an OMAP4 platform.
OMAP4 contains not only the ARM Cortex A9 (which is not likely to compete on it's own with dual core Atom), but, and this is crucial, a full C674x DSP core, both floating and fixed point mathematics.
The embedded DSP core in OMAP4 is fully capable of handling 1080p H.264 decode, with some resources to spare. I'm yet to see an Atom platform capable of that.
(shameless plug - my company is using OMAP3 and evaluating OMAP4 for some of our niche markets, and we might be interested in assisting in yours as well)
Related
I'm trying to follow these steps in order to use the FFT for my project, but every tutorial I follow keeps giving me the same error region 'FLASH' overflowed by 49836 bytes.
I understand that the microcontroller I'm using doesn't have enough space in it's memory to hold all the library (since it's full of tables to speed up the math) but it doesn't make sense that ST won't provide a native way of doing signal processing for Cortex M3 microcontrollers.
I would like an efficient way of doing FFTs with this microcontroller. Even Arduinos can do this with their own limitations.
Microcontroller specs:
STM32F103C8 (the board is a BluePill), 64KB Flash, 20KB RAM.
You can go to the CMSIS github repo and generate the library without the tables that go unused. That might help. Otherwise try a different library preferably one that doesn't precalculate the bit twiddle tables before hand at the cost of performance.
I have experience with Cortex-M controllers (LPC series from NXP) and Keil.
I want to move for cortex-A because my logic needs some better speed.
I found from internet that these processors will come with linux in it.
How can i use my code directly rather than using linux??
I don't need IO pins.
Where should i start?? What IDE should i use??
And i found debugging of Cortex-A controllers is tough because it is involving OS. is it true?
And is there any way without going for cortex A but achieving higher speeds (around Giga Hz)
By Cortex-M series, I suppose you have experience with M0 and M3. Right?
If you plan on using A-Series, you should know that they are more designed to run operating systems (than M-Series). (For example they have virtual memory management units...) That's why you may not find much bare-metal programming guides with these processors.
Also, these devices don't usually have on-board ROMs. So, you don't have an embedded flash... Therefore, you basically use an SD-Card or eMMC to boot them.
You may use Linux (Easier for you but won't be real-time), or an RTOS (also easier). If that doesn't suit you, you may use "UBoot" from SD-Card or eMMC and do a couple non-trivial steps (dependent on architecture) to run your bare-metal software (which is loaded from SD-Card or eMMC).
I suggest you buy a beagle bone and start from there.
You can still use Cortex-A for normal bare metal application adn with this way you will have something similair to what to what you had with application running on cortex-m
However it really depends from what you want:
if you want to understand how cortex-a is working or you are bringing
up a custom platform which is not that stable so bare metal coding is
your answer and with it you will be able learn a lot bout cortex-a
functionality
If you want to use Cortex-A from user point of view so you need to
compile your linux kernel for your cortex-a based board and start
using developing on top of your running kernel
In the case of x86 the same (real mode) bootloader works on virtually any x86 device.
Is that possible on ARM or do I need to create a specific bootloader for each 'cortex'?
x86 or lets say PC compatible systems are ... pc compatible. They support the ancient bios calls so that there is massive compatibility. by design, by the chip vendor (intel) the software vendors (bios, operating system) and the motherboard vendors.
ARM is in now way shape or form like that. There are instruction sets you can choose that work almost or all the way across, but remember ARM systems you buy an ARM core and add it to your special chip, you and your special/custom stuff, then that is put on one or more different boards. There is little to no compatibility. Instruction set and arm core is a small part of the whole picture most of the code is for the non-arm stuff.
u-boot and perhaps others are fairly massive bootloaders, pretty much an operating system themselves, and have to be ported just like an operating system to each chip/board combination. The chip vendor, if this is a linux compatible system, most likely has a reference design and a BSP including a u-boot port and/or some other solution (rasberry pi is a good example). it is fairly trivial to boot linux or used to be, there is no reason for the massively overcomplicated u-boot. without a DTB you setup a few memory locations a register or two and branch to the kernel, thats it (again look at the raspberry pi), I assume with DTB you build the dtb then put it somewhere, setup a few registers and branch to the linux kernel (raspberry pi? ntc chip?)
There is a Arm open source project that can cover Armv7/v8 Cortex-A processors bootloaders.
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/
Another open source project for Cortex-M processors:
https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/
I have an open-source Atari 2600 emulator (Z26), and I'd like to add support for cartridges containing an embedded ARM processor (NXP 21xx family). The idea would be to simulate the 6507 until it tries to read or write a byte of memory (which it will do every 841ns). If the 6507 performs a write, put the address and data on some of the ARM's I/O ports and let the ARM code run 20 cycles, confirm that the ARM is floating its data bus, and let the ARM run for another 38 cycles. If the 6507 performs a read, put the address on the ARM's I/O ports, let the ARM run 38 cycles, grab the data from the ARM's I/O port (hopefully the ARM software will have put it there), and let the ARM run another 20 cycles.
The ARM7 seems pretty straightforward to implement; I don't need to simulate a whole lot of hardware features. Any thoughts?
Edit
What I have in mind would be a routine that would take as a parameter a struct holding the machine state and pointers to a memory access routine. When called, the routine would emulate the ARM's instruction engine, generating appropriate reads, writes, and code fetches. I could then write the memory access routine to regard appropriate areas as flash (with roughly-approximated wait states), RAM, I/O ports, and timer registers. Some other areas would be marked as don't-care, and accesses to any other areas would flag an error and stop the emulator.
Perhaps QEMU uses such a thing internally. Since the ARM emulation would be integrated into an already-existing emulation engine (which I didn't write and don't fully understand--the only parts of Z26 I've patched have been the memory read/write logic) I would need something with a fairly small footprint.
Any idea how QEMU works inside? Any idea what the GPL licence would require if I just use 2% of the code in QEMU--whether I'd have to bundle the code for the whole thing, or just the part that I use, or what?
Try QEMU.
With some work, you can make my emulator do what you want. It was written for ARM920, and the Thumb instruction set isn't done yet. Neither is the MMU/cache interface. Also, it's slow because it is an interpreter. On the bright side, it's all written in C99.
http://code.google.com/p/gp2xemu/
I haven't worked on it for a while (The svn trunk is 2 years old), but if you're going to use the code, I'll be glad to help you out with the missing features. It is licensed under MIT, so it's just the same as the broad BSD license.
I am interested in learning how to do embedded system programming in c. However, I will need some hardware.
I am wondering is there any software that can simulate what the control board will do?
The control board is listed in the following tutorial
http://www.learn-c.com/hardware.htm
Many thanks for any advice
The board you linked to is not an embedded system board, it is an I/O interface for a PC. If you want to simulate that, you can simply write PC code stubs for the I/O functions that simulate connected devices' behaviour. However, you will not learn much about embedded systems from this. You may learn a little about PC based control, but since the board does not support interrupts or DMA, I suggest again that you will not learn much of that either.
Moreover the board is designed for an ISA bus slot. Modern PCs no longer have such slots. And modern operating systems prevent access to hardware I/O in user level code.
If you are serious about learning embedded systems development, you might for example download Keil's MDK-ARM evaluation; it includes an ARM simulator with on-chip peripheral simulation for a number of commonly available ARM based micro-controllers, and real hardware is available at reasonable cost.
If PC based control is of more interest, then you would be better off starting with a USB based I/O device, such as this example.