I am struggling with which cortex to choose.
Currently I have a design guy that will give me an M0 with memory for initial development but I want to use M0+ eventually.
Assuming I give up the optional features of the M0+ (MPU and MTB), can I transfer the M0 code to the M0+ without any changes?
I mean, is it the same libraries? same build commands? Linker?
What differences should I consider? I know they have the same ISA so I figured it shouldn't be a problem.
Thanks.
If you just consider M0 versus M0+ and not the system peripherals, all code compiled for Cortex-M0 should work on a Cortex-M0+ platform. They use the same instruction set and programmer model.
The main differences are about MPU and MTB, but also the fact that Cortex-M0 has no User-mode support (All code runs in privileged, ie CONTROL.nPRIV cannot be 1).
Related
The Cortex M7 provides the possibility to disable dual-issue.
I understand the benefit of dual issue functionality but I don't really see the drawback.
Are there some programs that are more efficient without dual issue ? (perhaps programs withe many branches ?)
Is it linked to power consumption ?
Answer from an expert of ARM architectures: disabling dual-issue might be used (among other solutions) when the processor is overheating. Less transistors are used.
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 to use Neon co-processor of Ti Sitara am335x processor. To enable neon, I have to enable the 30th bit of FPEXC(floating point exceptional register). For that I need to get into the privilaged/system mode.
Some of them suggested to attain this by sending interrupts. How to do that for cortex A8? Could anyone explain me?
Thanks.
You can use interrupts or svc to get into privileged mode, but then your OS code will be running and you would have no control. How do you then propose to enable neon by accessing fpexc?
Your best bet will be recompile your OS with floating point / neon enabled. This will enable the vfp/neon unit at bootup. Also when vfp/neon is enabled ,the task switcher will need to save restore the fpu registers along with general purpose registers.
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)