Embedded Systems – An Overview

By Jairam Sankar. He is currently pursuing B.Tech in ECE from RSET, Cochin

52020
Advertisement

There is a variety of ways that this can be written:

Machine code: Machine code is the most basic code that is used for the processor unit. The code is normally in hex code and provides the basic instructions for each operation of the processor. This form of code is rarely used for embedded systems these days.

Programming language: Writing machine code is very laborious and time consuming. It is difficult to understand and debug. To overcome this, high level programming languages are often used. Languages including C, C++, etc are commonly used.

Embedded System Architecture

There are two basic types of embedded system architecture. When data and code lie in different memory blocks, then the architecture is referred as Harvard architecture. In case data and code lie in the same memory block, then the architecture is referred as Von Neumann architecture.

Von Neumann Architecture

The Von Neumann architecture was first proposed by a computer scientist John von Neumann. In this architecture, one data path or bus exists for both instruction and data. As a result, the CPU does one operation at a time. It either fetches an instruction from memory, or performs read/write operation on data. So an instruction fetch and a data operation cannot occur simultaneously, sharing a common bus. The basic block diagram is shown below:

Von Neumann Architecture
Von Neumann Architecture

Von-Neumann architecture supports simple hardware. It allows the use of a single, sequential memory. Today’s processing speeds vastly outpace memory access times, and we employ a very fast but small amount of memory (cache) local to the processor.

Harvard Architecture

The Harvard architecture offers separate storage and signal buses for instructions and data. This architecture has data storage entirely contained within the CPU, and there is no access to the instruction storage as data. Computers have separate memory areas for program instructions and data using internal data buses, allowing simultaneous access to both instructions and data. The basic block diagram is given below:

Harvard Architecture
Harvard Architecture

Programs needed to be loaded by an operator; the processor could not boot itself. In a Harvard architecture, there is no need to make the two memories share properties.

Peripheral Devices in Embedded Systems

Embedded systems communicate with the outside world via their peripherals, such as following:

  1. Serial Communication Interfaces (SCI) like RS-232, RS-422, RS-485, etc.
  2. Synchronous Serial Communication Interface like I2C, SPI, SSC, and ESSI
  3. Universal Serial Bus (USB)
  4. Multi Media Cards (SD Cards, Compact Flash, etc.)
  5. Networks like Ethernet, LonWorks, etc.
  6. Field buses like CAN-Bus, LIN-Bus, PROFIBUS, etc.
  7. Timers like PLL(s), Capture/Compare and Time Processing Units.
  8. Discrete IO aka General Purpose Input/Output (GPIO)
  9. Analog to Digital/Digital to Analog (ADC/DAC)
  10. Debugging like JTAG, ISP, ICSP, BDM Port, BITP, and DP9 ports

Conclusion

Many embedded systems have requirements that differ significantly both in details and in scope from desktop computers. In particular, the demands of the specific application and the interface with external equipment may dominate the system design. Also, long life-cycles and in some cases extreme cost sensitivity require more attention to optimization based on these goals rather than maximizing the computational throughput.

The business and cultural climates in many embedded system design situations are such that traditional simulation-based computer design techniques may not be viable in their current form. Such methodologies may not be cost-effective given constraints on categories of expenditures, may not be seen as worthwhile by non-computer-trained professionals, or may simply be solving the wrong problems.

Recent interest in hardware/software code-design is a step in the right direction, as it permits trade-offs between hardware and software that are critical for more cost-effective embedded systems. However, to be successful future tools may well need to increase scope even further to include life-cycle issues and business issues.


Advertisement


4 COMMENTS

SHARE YOUR THOUGHTS & COMMENTS

Please enter your comment!
Please enter your name here