How to choose a Microcontroller

article source: http://www.ehow.com/how_2319026_choose-microcontroller.html

There was a time when the microcontroller selection available was pretty much limited. Now there are so many available, it is a task to find the right one. Choosing a microcontroller depends on what you want to accomplish.When choosing a microcontroller, you have to ask yourself the right questions and research the different type of microcontrollers before making your choose.If you don’t know what a microcontroller is or what it is used for, you may want to research it before trying to understand the information given in this article.

Answer

  • 1- Ask yourself what your needs are in terms of programmability and reprogrammability. This will help in determining memory requirements of the microcontroller.
  • 2- Decide what peripherals you will be using or wanting to use in the future.
  • 3- Decide on the physical packaging and the limitations that can be associated with it.
  • 4- Decide on memory aspects. More complexed systems will need more memory, and thus, bigger chips.
  • 5- Decide on the architecture of the system you are planning.
  • 6- Think about hardware and software tools that are manufactured with the microcontrollers compared to what you will be needing.
  • 7- Think about costs and what you have budgeted to spend on the microcontroller. Above anything, this will probably sway your decision on which one you will purchase if your are strictly restricted where costs are concerned.

After deciding on steps 1 to 7, choose an appropriate microcontroller. Some that you many want to research are the microchip, Atmel AVR, Intel 8051, Texas Instruments MSP 430, ARM, Cypress PSOC, Renesas H8, Zilog Z8, modules and hidden microcontrollers.
article source :http://www.ehow.com/how_2319026_choose-microcontroller.html

Advertisements

HARVARD ARCHITECTURE vs. VON NEUMANN

HARVARD ARCHITECTURE vs. VON NEUMANN

If you are new to Microcontrollers one of the arguments you are going to
hear bantered about is Harvard Architecture versus the Von Neumann
Architecture.

THE VON NEUMANN ARCHITECTURE

Most computers we are familiar with use an architecture called Von Neumann.
The term arose out of Neumann’s 1945 draft report on the ADVAC computer. He
was not, however the original inventor of it.

A Von Neumann machine has one large monolithic RAM structure that contains
both program memory and data memory mixed together. Since both program steps
and data must be loaded from the same place, it can create a problem called
the Von Neumann Bottle-Neck.

THE HARVARD ARCHITECTURE

Most microcontrollers use a different system called Harvard architecture.
The larger program storage and the smaller data memory are separated. The
first such machine, the Harvard Mark I had it’s programs hard-coded on
paper-tape and the volatile data was loaded into electric relays.

Harvard style machines allow program steps to be fetched at the same time as
data, thereby creating potentially faster through-put and less of a
bottle-neck. They also have the benefit that run away processes can’t damage
the program stored in the non-volatile program area so they’re more stable.
Many C programs lack proper boundary checking and a null pointer or an
over-run buffer can overwrite and crash a program that shares RAM with data.
If you are new to this architecture you need to keep this in mind. When
creating a routine that needs a few bytes of storage, I would normally
create that space within the routine itself. On a Harvard machine, those
bytes would not be in volatile RAM but part of the hard coded program memory
stored in ROM (or FlashRAM).

source :http://sci.tech-archive.net/Archive/sci.electronics.misc/2006-04/msg00057.html

Memory Types in Embedded Systems

Embedded Systems Memory Types

By Michael Barr

SRAM or DRAM? EEPROM or flash? What types of memory will you use in your next embedded systems design?

Many types of memory devices are available for use in modern computer systems. As an embedded software engineer, you must be aware of the differences between them and understand how to use each type effectively.

In our discussion, we will approach these devices from the software developer’s perspective. Keep in mind that the development of these devices took several decades and that their underlying hardware differs significantly.

The names of the memory types frequently reflect the historical nature of the development process and are often more confusing than insightful. Figure 1 classifies the memory devices we’ll discuss as RAM, ROM, or a hybrid of the two.

common memory types

Figure 1. Common memory types in embedded systems

Types of RAM

Static RAM (SRAM) and dynamic RAM (DRAM).

The primary difference between them is the lifetime of the data they store.

SRAM retains its contents as long as electrical power is applied to the chip. If the power is turned off or lost temporarily, its contents will be lost forever.

DRAM, on the other hand, has an extremely short data lifetime-typically about four milliseconds. This is true even when power is applied constantly.

Simple piece of hardware called a DRAM controller can be used to make DRAM behave more like SRAM. The job of the DRAM controller is to periodically refresh the data stored in the DRAM. By refreshing the data before it expires, the contents of memory can be kept alive for as long as they are needed. So DRAM is as useful as SRAM after all.

When deciding which type of RAM to use, a system designer must consider access time and cost.

SRAM devices offer extremely fast access times (approximately four times faster than DRAM) but are much more expensive to produce. Generally, SRAM is used only where access speed is extremely important.

A lower cost-per-byte makes DRAM attractive whenever large amounts of RAM are required. Many embedded systems include both types: a small block of SRAM (a few kilobytes) along a critical data path and a much larger block of DRAM (perhaps even Megabytes) for everything else.

Types of ROM

Memories in the ROM family are distinguished by the methods used to write new data to them (usually called programming), and the number of times they can be rewritten.

This classification reflects the evolution of ROM devices from hardwired to programmable to erasable-and-programmable. A common feature of all these devices is their ability to retain data and programs forever, even during a power failure.

The very first ROMs were hardwired devices that contained a preprogrammed set of data or instructions. The contents of the ROM had to be specified before chip production, so the actual data could be used to arrange the transistors inside the chip. Hardwired memories are still used, though they are now called “masked ROMs” to distinguish them from other types of ROM. The primary advantage of a masked ROM is its low production cost. Unfortunately, the cost is low only when large quantities of the same ROM are required.

One step up from the masked ROM is the PROM (programmable ROM), which is purchased in an unprogrammed state. If you were to look at the contents of an unprogrammed PROM, you would see that the data is made up entirely of 1’s. The process of writing your data to the PROM involves a special piece of equipment called a device programmer. The device programmer writes data to the device one word at a time by applying an electrical charge to the input pins of the chip. Once a PROM has been programmed in this way, its contents can never be changed. If the code or data stored in the PROM must be changed, the current device must be discarded. As a result, PROMs are also known as one-time programmable (OTP) devices.

An EPROM [UV-EPROM] (erasable-and-programmable ROM) is programmed in exactly the same manner as a PROM. However, EPROMs can be erased and reprogrammed repeatedly. To erase an EPROM, you simply expose the device to a strong source of ultraviolet light. (A window in the top of the device allows the light to reach the silicon.) By doing this, you essentially reset the entire chip to its initial–unprogrammed–state. Though more expensive than PROMs, their ability to be reprogrammed makes EPROMs an essential part of the software development and testing process.

Hybrids

Hybrid memories can be read and written as desired, like RAM, but maintain their contents without electrical power, just like ROM. Two of the hybrid devices, EEPROM and flash, are descendants of ROM devices. These are typically used to store code. The third hybrid, NVRAM, is a modified version of SRAM. NVRAM usually holds persistent data.

EEPROMs are electrically-erasable-and-programmable. Internally, they are similar to EPROMs, but the erase operation is accomplished electrically, rather than by exposure to ultraviolet light. Any byte within an EEPROM may be erased and rewritten. Once written, the new data will remain in the device forever–or at least until it is electrically erased. The primary tradeoff for this improved functionality is higher cost, though write cycles are also significantly longer than writes to a RAM. So you wouldn’t want to use an EEPROM for your main system memory.

Flash memory combines the best features of the memory devices described thus far. Flash memory devices are high density, low cost, nonvolatile, fast (to read, but not to write), and electrically reprogrammable. These advantages are overwhelming and, as a direct result, the use of flash memory has increased dramatically in embedded systems. From a software viewpoint, flash and EEPROM technologies are very similar. The major difference is that flash devices can only be erased one sector at a time, not byte-by-byte. Typical sector sizes are in the range 256 bytes to 16KB. Despite this disadvantage, flash is much more popular than EEPROM and is rapidly displacing many of the ROM devices as well.

The third member of the hybrid memory class is NVRAM (non-volatile RAM). Nonvolatility is also a characteristic of the ROM and hybrid memories discussed previously. However, an NVRAM is physically very different from those devices. An NVRAM is usually just an SRAM with a battery backup. When the power is turned on, the NVRAM operates just like any other SRAM. When the power is turned off, the NVRAM draws just enough power from the battery to retain its data.

NVRAM is fairly common in embedded systems. However, it is expensive–even more expensive than SRAM, because of the battery–so its applications are typically limited to the storage of a few hundred bytes of system-critical information that can’t be stored in any better way.

Table 1 summarizes the features of each type of memory discussed here, but keep in mind that different memory types serve different purposes. Each memory type has its strengths and weaknesses. Side-by-side comparisons are not always effective.

Type

Volatile?

Writeable?

Erase Size

Max Erase Cycles

Cost (per Byte)

Speed

SRAM

Yes

Yes

Byte

Unlimited

Expensive

Fast

DRAM

Yes

Yes

Byte

Unlimited

Moderate

Moderate

Masked ROM

No

No

n/a

n/a

Inexpensive

Fast

PROM

No

Once, with a device programmer

n/a

n/a

Moderate

Fast

EPROM

No

Yes, with a device programmer

Entire Chip

Limited (consult datasheet)

Moderate

Fast

EEPROM

No

Yes

Byte

Limited (consult datasheet)

Expensive

Fast to read, slow to erase/write

Flash

No

Yes

Sector

Limited (consult datasheet)

Moderate

Fast to read, slow to erase/write

NVRAM

No

Yes

Byte

Unlimited

Expensive (SRAM + battery)

Fast

Table 1. Characteristics of the various memory types


This article was published in the May 2001 issue of Embedded Systems Programming.

why Linux for Embedded Systems ?

Question: Why Linux is the choice for Embedded Systems?


Answer: There are multiple reasons for choosing Linux for the Embedded Systems. Some of the reasons are given below.
Linux is based on Open source concept and it is going to be the future of embedded software. Most of the embedded systems are built using Linux as they significantly bring down the product cost simply because it is open. 

There are ample amount of tools and debugging mechanisms provided by Linux for an embedded systems developer right from the editor to memory analyzer. These tools play a major role in embedded system development as they reduce the development time. 

Linux is customizable for almost all processor architectures and it is scalable at all levels.

Question: What are the building blocks of BIG Embedded Systems from a programmer’s perspective?

Question: What are the building blocks of BIG Embedded Systems from a programmer’s perspective?

From a programmer’s perspective there are four building blocks for any system namely

Boot-loader,
Operating system,
Device drivers
and Networking subsystem apart from the device’s main functionality.

When the system gets powered up, the boot-loader is the first program that gets activated from the non-volatile memory or NVM. This boot loader will vary from one system to another, because it mainly depends on the way system is configured. This boot loader will in turn revoke the operating system by calling its entry point, which in-turn initializes various operating system services (memory, tasks, scheduler etc…).

Once the operating system services are initialized, all the low level device drivers followed by other subsystems (like networking) are brought up. At this point we can say that the platform is built for the system. After this initialization is complete, the system would be in a position to perform its expected functionality. This functionality will vary from device to device as each system is built for a different purpose. Say for example a router’s main functionality would be to route the packets but a microcontroller’s functionality may be measuring the temperature using a sensor. Finally functionality programming is the main core of embedded system which requires a powerful programming skill.

What kind of boards and hardware experience one should learn ?

Question: What kind of boards and hardware experience one should learn to get experience in Embedded Systems?

Answer: To start with, Micro controller based boards are good ones to learn the board level programming. After that one need to get hands on experience in boards like : PIC, Mechatronic and ARM board. If an engineer get an opportunity to work on customized boards, which are used in live projects it would be really useful to get a good knowledge.


How Embedded Systems programming is different ?

Question: How Embedded Systems programming is different from normal programming? What are the technical challenges involved?

Answer: Even though embedded systems vary in various functionalities, the programming fundamentals remain almost the same. The challenges in embedded systems programming is because of the following reasons.
Embedded systems have very limited resources (in terms of memory, storage, processing power) compared to a general purpose computing device like PC.

Because of the less memory availability and requirement of faster response, embedded systems have Real Time Operating Systems (RTOS). These RTOS have flat memory model where all processes in the system run under the same memory space. This will lead to lot of memory corruption and inter process communication errors. Debugging these errors are really challenging.

Embedded systems have a pre-defined performance requirements and response time.

Since the embedded software will be running in a dedicated hardware, troubleshooting them requires strong system level understanding and debugging skills.

more about flat memory model here