Specifications of Microcontrollers Is it all same?

Question

I am complete virgin in Electronics. Though I am very experienced in Programming. I've never played anything with electronics.

What are the Specifications of Microcontrollers ?

No. of digital Pins:
No. of Analog Pins:
SRAM:
EEPROM:
Flash:
Operatng Voltage:

If only these few are the characteristics of microcontroler. Why the come with long pdf Datasheet ?

Now a days they can all be programmed in C. and while coding only the first 5 informations are needed all others can easily be found in headers. So why don't the manufacturer companies just give out these few infos only and with some links of here and there ?

and If all vendors(Atmel/Motorola/Philips etc..) makes the same thing why professional people don't use AVR much. rather hobbyist people uses AVR.(got this info from another thread Why are Atmel AVRs so popular?)

Answer 1

The list of parameters that you have quoted is just the beginning. The important things (for me) are the number and type of peripherals built in to the processor silicon, which pins are they available from and how they are driven by the software. The different processor families, even different ranges within the same family from a single manufacturer, have very different peripheral sets and operating modes. Providing the level of support that is available through a major operating system, such as you would get on a desktop system is just not possible within the processor memory resources.

All of the peripheral devices have their own set of control registers, all of which will be different to those found on other processor families. This has to be documented to allow the device to be used.

A simple example.
On the AVR32 most modules have separate registers to set and clear the interrupt enable bits for a peripheral. To enable an interrupt you write a 1 to the bit in the enable register. To disable it you write a 1 to the bit in the disable register. To find out if it is enabled you read the bit state from a third register. On the MSP430 to enable the interrupt you write a 1 to the single interrupt enable register, to disable it you write a 0 to this bit, to find out whether it is enabled you read the state of the bit in this one register.

Without all of the detail in the datasheet you would never manage to work this out. This is then repeated for each of the registers available for every peripheral within the device and you can see why the datasheet gets so big so quickly.

I have used a number of ARM, AVR32 and MSP variants and, while each comes with a number of header files and device libraries to allow the use of the on chip peripherals, these libraries are, to be quite honest, of variable quality (the LINT errors from some of the code have to be seen to be believed) and often do not cover the interrupt mode of operation that is needed for my application. The information in the datasheet allows me to write and debug the software to get the optimum performance for my application. My requirements, normally extremely low power dissipation, will mean that my code has to be written using the device in a different way to that where the priority is data throughput.

Your final point about AVR not being used much in professional systems - there are many processors in the market and each has its strengths and weaknesses. I tend to use MSP430 because of its very low power requirements. I have used AVR32 in preference to the ARM-M3 for the same reason. Price is very important. On chip peripheral mix and their fit to my application will make one processor a killer and another very similar device a dud. For me the AVR and AVR mega did not have the right mix of processing power, peripherals and power consumption and were discounted very early in the processor selection process.

Answer 2

One of the main reasons for the very long (sometimes hundreds of pages) datasheets is that each microcontroller family tends to have unique ways of controlling such things as serial ports (UART, I2C, SPI, USB), ADCs and DACs, timers/PWM, clock generators, parallel ports, interrupts, and flash memory programming. Each of these peripherals is configured and controlled by several internal registers.

Even though the registers can be programmed in C, each bit in each register still has to be documented.

The number of pins and the amount of memory is just a small part of the specification.

Answer 3

I'm attempting to answer a few points in your question more directly, to give examples of where this data does not suffice. The basic specifications you list aren't complete, but only an overview. Each can be divided into more related questions, which should be answered in the datasheets:

No. of digital Pins:

How many are 5V tolerant? Higher voltages? Open collector or emitter? Available for higher level peripherals (timers, bit shifters, etc)? How many can be read or updated simultaneously?

No. of Analog Pins:

Input or output? How many bits of precision? Technology (delta-sigma, PWM, R2R..)? How often can they be measured? It's not unusual at all that they can't be measured at the same time.

SRAM:

Does the stack go in the RAM, or separate? How wide is it? Can parts be powered down for lower current draw? Can code be run from RAM?

EEPROM:

Again, width? How long does it take to read or write? What are the power requirements (often a higher voltage is needed to complete a write here)?

Flash:

Self programmable (so one might have a bootloader)? Can data be read out of Flash? Can all those bits be used for data? How many operations (and of what scale) can I fit into this size?

Operatng Voltage:

For which frequency ranges? Do the I/Os tolerate higher voltages than the power supply? Do we need separate supply rails for analog and digital, core and I/O?

Now a days they can all be programmed in C. and while coding only the first 5 informations are needed all others can easily be found in headers.

Actually, a few can be programmed in something only resembling C, and much information will not be present in the headers, such as what port maps to which pin. Often this will vary depending on the package. This is also only scraping the surface, as you'll find some controllers implement hardware for very different purposes, such as threads, IPC, event systems, DMA and so on that may be critical for one use and irrelevant for another.

So within a family an overview of the type you show can be enough, but usually there will be many more parameters to compare (number of timers, for instance). It depends very much on the task.

FWIW, the AVRs are popular in industry too, but sometimes avoided for specific reasons - such as single supplier, availability and resilience.

Answer 4

The major thing missing in your list is on-chip peripherals, like (peripherals you may or may not find on certain NXP Cortex-M3 controllers)

General purpose timers (how many?)
External interrupts (how many?)
Real Time Clock
Watchdog timer
(Motor) PWM (how many?)
UARTs (how many?)
I2C interfaces (how many?)
CAN interfaces (how many?)
SPI interfaces (how many?)
USB interfaces (how many?, speed?, on-the-go?)
LCD controller
Ethernet
ADC channels (how many?, how many bits?)
DAC channels (how many?, how many bits?)

So there's a lot more to a microcontroller than a memory map and I/Os. BTW, even general purpose I/O needs specifying: some may have high current drivers, others may have interrupt capabilities.
Each of these has to be described in a programming model; which registers control the interface and at which addresses can they be accessed. What happens if you read from the register? (Contrary to what you're used to with common storage, reading a register may modify bits in other registers.)
All this are reasons why the NXP LPC1759 has a 73-page datasheet, complemented by a 840-page user manual (which describes the family's common features).

If you take all features into account, not all vendors make the same thing, even controllers built around the same core (like ARM Cortex) show great differences between manufacturers. One thing they try to make themselves stand out with is the choice of on-chip peripherals. Except for the smallest ones almost all microcontrollers have a couple of UARTs. Seems some users need more of them, so certain manufacturers provide up to 8 UARTs (last I heard).

If engineers use less Atmel AVRs in projects (I don't know if that's true), it may have to do with more than just the product's specs. A few things which come to mind:

price,
supplier's support (does he have an FAE specialized in the product?),
available toolchain(s),
product lead times,
number of engineering changes (how stable is the product?),
is there a complete family offered? (can I easily switch to similar devices, pin-compatible or in another package)

Answer 5

I too don't have much experience, but here are some thoughts of this matter:

Some reasons of different vendors of chips:

They often use different architectures and such things can be important when programming. Some instructions take longer to execute and some take shorter amounts of time. RISC designs solve that to some level, but there are still few instructions which take more than one cycle. Of course, this is more important if you are programming directly in assembly.

Not all C compilers are that good. I've heard people complaining about behavior of C compilers for various embedded platforms and the large number of quirks which are often present.

There is also social factor. In my country PIC became generic name for microcontroller. PICs became everyone's default choice when deciding which microcontroller to use.

Another point are physical differences among chips themselves. Some have different operating temperatures, different power consumption, fail in different ways and so on. All this things are very important when making a serious product.

Now for information: The closest thing to datasheet in programming world would be language specification. There simply needs to be one authoritative source for all information about that chip and that is its datasheet. All those things in those long long PDF files are very important to some users. For example while it is enough to know few basic libraries to make C++ programs, there are users who need to read the whole ISO/IEC 14882:2003 standard. So how would you make a compiler for a chip if you don't know what a chip actually does?

There are also important electrical characteristics of the chip which affect entire circuit in which the chip is used. There are lowest and highest voltages for each pin and they can on some chips change with change of frequency and temperature. There is time needed for one cycle to execute (while it may not be important from programming point of view, it is important of you need to synchronize the rest of the circuit with the chip). All these things are important when choosing microcontroller for a project.