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
Related
I read somewhere that learning c programming gives us the actual idea of what is happening in the hardware level i.e. C programming teach us the real programming like how the memory is being utilised, how the hardware resources are used and it allows us to interfere with hardware level stuff like we are the one who can use and can control these resources in our own way as we want but other high level languages don't allow this.
Now I am learning C programming but I am not able to understand that how I am controlling my hardware resource ?
I have no idea how it is allowing us to use my computer resources independently.
In user mode, using a 32 or 64 bits multitask operating system, even C won't show you a tiny bit of hardware - lowest level you'll see is operating system itself.
You may ask the OS to draw a window, to save a file, to send data through a network - you won't touch directly GPU, disk controller or Ethernet MAC/Phy chip to be able to do that. In fact, you probably won't even be able to tell which KIND of hardware is behind... Is it a Nvidia card? An old SVGA one? A mechanical hard drive, or a NVMe drive? A 10BaseT NIC, or a 10 Gb/s optical fiber network card? You can't tell just with C. Only OS knows it, and it's OS that may tell it. You'll get that in C exactly like you would have got it with, let's say, Python.
To see hardware and how it works, you'll need to be able to touch hardware with software instructions. On a modern OS, it means being in kernel mode. Or to use an old-timer OS, like MS-DOS, or even no OS at all - called "bare metal development", often encountered with microcontrollers like Arduino and similar devices.
In this world, you'll need to learn what a register is, how GPIO works, how you address an UART, and if you use specific controllers, you'll have to read (and understand!) their datasheets if you want to make them work.
Indeed, it's often easier to do such low-level code in C, rather than in Assembler - especially since each CPU has its own assembler, so that may become a lot of languages to master in fine. But it's not mandatory. It can also be done with any language, as long as you can produce an absolute (=relocated), standalone (=no dependencies) and ROMable binary that can be written in Flash/EEPROM for your microcontroller. It can be done in assembler, C, C++, ADA for the most common ones, and virtualy any language that don't need a (too) big runtime library.
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 will preface by saying that I am fairly new to programming at the hardware level and that I'm interested in building apps based on the MSP432 microcontroller by Texas Instruments.
I understand that to program this controller, one writes C code, links to the MSPWare library/drivers, and compiles with gcc. Is it possible to take the code written for this controller and deploy to other controllers that are also based on the the Cortex M4 32-bit architecture? What sorts of differences are there between the various implementations of the Cortex M4?
I will say generally not, unlike an x86 pc or a mac, where the masses at least are used to one operating system and that operating system allows for a lot of reverse compatibility, you write a program today on a dell and it works on an acer, and will probably run for another 10 years or more on your daily driver computer or at least many 10 year old or more programs run today, actually in 10 years todays programs probably wont run (on your phone or brain implant).
the cortex-m4 is a processor core, arm doesnt make chips they make processor cores that chip companies buy and surround with chip company stuff. So instead of saying I can drive a car move me from one car to another and there is a pretty good chance I can drive it, instead this is I am a specific sized tire and move me from one car to another and it is quite likely I dont work.
almost all of the code in the libraries that you are making calls to are for things within the chip, but outside the arm core, the chip vendor specific stuff. So while that particular chip vendor may make libraries that are close to the same from one of their arm chips to another within a class of chips or within the same production time frame or whatever, that doesnt mean that that code apis or how the peripherals work is in any way portable from one family of chips in that company to another and certainly not from one chip vendor to another. your ti code is likely not close to what you see on an atmel or nxp or st arm based chip.
Now saying that there are folks trying, the mbed stuff is an attempt to be arduino like where arduino is an attempt to make a high enough set of libraries and port them to specific boards (which are mostly within a family of chips from one vendor). There are some arm based attempts to make arduino libraries such that code developed on a real arduino will compile for these arm based things and just work, but those arm based things are specific boards designed to be ardunio compatable and the libraries are thick and hold all the conversion magic from avr/atmel peripherals to whatever arm based chip was chosen.
mbed is probably closer to it, originally just nxp chips but now some st boards with st chips that are trying to be both arduino compatible and mbed compatible. not sure how that will work out.
then there are phones of course but that is a lot closer to the windows thing write an iphone app and it will/should work on all the iphones for some period of time, even though those phones all use different arm based chips from different vendors with vastly different peripherals.
This question likely will be closed for being primarily opinion based, since it is not really a black and white fact question. I suggest you just enjoy the board you bought, make the leds blink and stuff, get used to dealing with a whole new environment compared to operating system stuff, and the very limited resources compared to a laptop/desktop.
If you have a specific porting question or something that is more of a question with a more specific answer then ask it that way. If you are wanting to play with this but ultimately do X with it (port the code to an stm32f4 for example), will it work.
Now, it is quite likely that if you wanted to create your own abstraction layer, then you could create it such that it works on top of multiple chips/platforms.
Arm has this cmsis thing but I think that is for the debuggers to get common access to the board, you may or may not know or have noticed that the access to the stellaris launchpad now tiva C is a different interface/protocol than the one used now. The one used now is on the hercules and now msp432 (I hate that, it is in no way shape or form related to the msp430, perhaps this is a pic vs pic32 thing which in no way are related to each other except for being from the same parent company) uses the same XDS100 compatible front end. The thing that was formerly a board with an attempt to be arduino like easy to use web based environment (arduino is java based not web based, but run anywhere is the idea) and a lot of libraries so you dont have to know as many details, this is mbed, now mbed appears to becoming an rtos or something so kind of like writing for arduino or for android, you might...might...be able to develop on top of that and have it port. Understand the more layers the thicker the abstraction layer the more resources you need the more power you consume the more the chip cost, etc. So it is a tradeoff of saving a little bit of software development time vs the price or size or power consumption of the product. We dont know, nor necessarily need to know, what you are making, that is your business but, there are tradeoffs to making the software "simpler", portable, readable, etc...
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.