help on all these different types of processors
I'm new to hardware and also semi new to programming, so bare with me. I'm confused by all the different processors chosen by all these micro controllers.
arduino uses atmega
teensy uses atmega and now arm cortex (which from what I know is an actual cpu?)
pi uses arm 11 (<-- but I assume the cpu is so beefy that it can also do video as well? I guess it has a large enough ramdac for frame buffer where as all these others don't?)
then there is fpga's... I honestly have no clue what these are, but so far anytime major video is required they point you to a fpga.. why? what is special about a fpga?
What makes pi different than the teensy 3? I know the teensy uses a boot loader off chip, but how does the pi work? Boot loader on chip, then checks sd card for os? I assume if the teensy 3 had enough ram, that it could be possible to build a bootloader to check sd for a os? Also, I know the pi uses gpio, and from what it looks like so does the teensy, but the argument I've always heard is gpio is slower than arduino's io compared to the pi? is this because access to the gpio ports are going through a nasty software layer? and how does the teensy deal with this? or is this just a false argument?
most of this is confusing cause then you look at cell phones.. what do they use? currently I think most androids use arm cortex's but how do those cpu's differ from teensy's or pi's? are they really just the same with beefed up specs and setup like the pi?
This is only going to be a high level summary.
First of all, Arduino now has an Arm product as well (the Due).
At the basic level is which chip is in the product. Most of the Arduinos (except Due) use ATmega chips from AVR. These are all 8 bit processors. To deal with larger data, like int or long, multiple instructions will be needed to be done. So for example, to add two 16-bit numbers, might involve two instructions, ADD and ADD-carrying. On a 32-bit chip like the ARM, this would be a single ADD instruction. Now, in general most of the chips used in embedded spaces are not performance critical, as they are using waiting for a device to come back. Sometimes things are performance critical (video and audio for instance), and the 8-bit chips may not be up to the task. One consequence is the int data type is 16-bits. In general, most of the 8-bit chips have small amounts of read/write memory, and moderate amounts of read-only memory for program space. One of the reasons to go with Arm is to get to higher amounts of memory (but it depends on what the actual chip has).
The ARM based chips uses a different instruction set at its core. Think of it as the AVRs internally speak Italian and the ARMs speak German, within each system, assuming you are fluent in the language you can do anything, but speaking German in an area populated only with Italian speakers won't get you very far. The Arm is a scale-able architecture, and it has multiple different levels. Most of the chips for embedded programming tend to be fairly basic Arms, and run at slow clock speeds. The primary reason is power and cost -- running at higher clock speeds consumes more power. Also, adding extra things to the base architecture can also increase the cost, using a newly designed chip vs. an older design that is simpler.
In general, until you get to things like hardware interrupts, writing to machine specific registers, or writing assembly language, most people don't have to worry about the details, and the compiler will compile the code for the appropriate machine (i.e. writing out instructions in Italian or German to use my example). Now, the closer you get to the hardware, the more you have to know what goes on at the hardware level.
My day job is working on the GCC compiler for a completely different chip, and there I have to have extensive knowledge of the machine. However, dealing with Arduinos and Teensy is an after the hours hobby, and so I so far have avoided poking under the covers too much. I know from past jobs, that I generally can only keep a few architectures current in my brain, and I need to swap them out when I'm not dealing with them on a current basis. I've lost track of the number of chips I've looked at over the last 30+ years, but I believe it is now over 20.
Now, the Raspberry Pi is also an Arm chip, but it is a much beefier chip than the Teensy 3.0 chip. instead of having 16 kilobytes of read/write memory and 128 kilobytes of read-only program memory, the R-PI has 256 megabytes or 512 megabytes of read/write memory. It also has full support for running a full operating system (typically Linux, but you could run your own). It also runs at 700 Khz, while the Teensy 3.0 runs at 48 Khz or 96 Khz, and has instructions for doing floating point calculations. Thus if you need to do lots of calculation or process lots of data, you go for the R-PI. However, the R-PI is less friendly for embedding programming, since you typically need to go through the OS which can introduce delays. Also, the Arduinos/Teensys have a lot of pins for controlling devices, while the R-PI only has a few.
Another difference is the R-PI has a separate chip to do video processing. So for things like drawing on a screen, the Arm processor tells the video processor to do stuff at a higher level, and it does it in parallel with the main processor. Unfortunately, the video processor on the R-PI is not open, and so you have less flexibility to run stuff in the video processor, than you might if the design were completely open.
Cell phones are similar, except the newer cell phones now have multiple processors, and maybe can run at even faster rates. But that's the reason most of the smart phones need either big batteries or need to be recharged more often than older phones in the past.
Last edited by MichaelMeissner; 03-01-2013 at 05:00 PM.
Was reading the wiki page on the r-pi and it's a broadcom chip with arm 11 and their vcore 3 gpu. Seems to be a all in one chip compared to the micro controllers. So then you would agree that with the R-PI having to go through a software layer (aka the linux kernal) it causes the gpio to be slow? And thus why teensy doesn't experience this is because Paul (who is awesome) is accessing it directly from within the chips flash vs sd which has a much lower level control point and faster speed.
Since Paul made the teensy 3 to be a off the chip bootloader, does that mean the R-PI just used it's flash on chip to build a boot loader to pull from SD since user control to that flash is denied? I mean why build a off chip boot loader when they know the chip's internal flash will never be used, best to make use of it as a boot loader for and OS on a SD card right?
Making a bit more sense now how all this works really. And Thank you very much Michael! You've been a awesome help!
Generally, microcontroller-based boards, like Teensy and Arduino, are best for interfacing sensors, controlling hardware like motors and lights, and similar tasks. Some microcontrollers offers better CPU performance, but even those are relatively limited. Generally you use boards like Teensy for tasks that involve input/output and modest manipulation of data. Microcontrollers use relatively little power, so they're typically the best choice if your project will run on a battery or need to fit into a very small space.
Small-scale computers, like Raspberry Pi, internet routers and even small PCs are best for complex data manipulation tasks. If you need special networking, like running a web server with scripting in Python, Perl, etc, that's where those platforms really shine. These systems run Linux, which gives you a lot of great multitasking capability and access to lots of software (though much of it is designed to run on more powerful PCs). Raspberry Pi has I/O pins which can interface some things, but generally the I/O capability is less than using a microcontroller. Typically power consumption is a few watts, so usually they aren't run from batteries. These boards can work in moderately sized sealed boxes (little or no airflow), but not the tiny spaces where microcontrollers can fit.
There are a lot of projects where either a microcontroller or small scale computer can do the job. Each has its own strengths. Many people have used them together, where the microcontroller handles I/O tasks and rapid response to special signals, and the small scale computer does data manipulation and networking. Together they can do a tremendous amount.
FPGAs are very specialized hardware, normally used for only very advanced applications. They are much harder to use than microcontrollers or small scale computers. Typically they're needed for very special applications that manipulate tremendous amounts of data at very high speeds. If you're just getting started with electronics, FPGAs are not a good place to start.
Makes sense why fpga's are mostly used in driving larger lcds and such. Heck I'm just glad my teensy 3 can handle the 3.2in I'm using now.
The Raspberry Pi is at 700 Mhz.
Originally Posted by MichaelMeissner
Thanks Paul for the clear presentation!
Just as the Teensy is 24/48/96MHz...
...the OP had the multiplier right even if the frequencies were off by three orders of magnitude.
Originally Posted by linuxgeek
Yes, I obviously was shooting off the cuff in terms of the speeds.
Originally Posted by Constantin
Originally Posted by MichaelMeissner
You'll likely forget in a given day more about programming, CPUs, etc. than I will ever know. Thank you in particular for the many useful posts here and elsewhere re: programming, the GCC compiler, and the many idiosyncrasies of the underlying hardwares you have supported over the years. Perhaps one day I can repay my debt of gratitude with something useful in return, perhaps how to manufacture a part for your steampunk camera - but that is assuming you'd need that help...
Last edited by Constantin; 03-06-2013 at 09:11 PM.