info about Embedded Systems Programming, Programming service, Programming development, SSI Programming, Real Time Embedded Systems Programming, Based embedded system programming

Embedded Systems Programming

Embedded microprocessors appear in everything around us, including televisions, remote controls, DVDs, VCRs, microwaves, refrigerators, cars and washing machines. Of course, computer equipment such as printers, PDAs, routers, firewalls and modems also include embedded microprocessors.

Developing software for embedded processors is normally vastly different than developing standard computer software. An embedded system generally has severe restrictions on the amount of RAM available, CPU processing power and normally has very restricted input/output capabilities. The requirements for developing embedded system software are similar to the methods used in the past for assembly language programming, where small size and speed are generally preferred over ease-of-use and features. Basically the goal is to make the software that is reliable and usable above all else, without worrying much about advanced features.

Microprocessors

Many different companies manufacture microprocessors for the embedded systems market. The major manufacturers are Intel, Motorola, Zilog, AMD, Cyrix, Texas Instruments, National Semiconductor, Rockwell, and others. Each microprocessor is generally designed either as a general-purpose processor, such as the Pentium series, or as a special purpose microprocessor, such as the DSP family from Texas Instruments.

Generally, all microprocessors, whether general or special purpose, do share some common attributes. All microprocessors have internal memory locations known as registers. Registers are used to perform mathematical operations, comparison and act as temporary, reusable memory. Most processors have a limited number of registers. Registers are also limited in the number of bits of information they can store. Each bit is a binary one (1) or zero (0). The number of bits that can be held in each register defines the word size of the processor. Typically modern microprocessors hold 4, 8, 16, 32 or 64 bits in each register and are therefore known as n-bit processors.

Other common attributes of microprocessors include the ability to access memory, communicate with external devices through input/output ports and detect when an external device needs attention via interrupt request lines. These external devices generally have to be read by the processor using special instructions and the memory content is transferred into one or more the internal registers. Once the values are in the registers, they can be compared, calculated or written out to other external devices.

Learn more about embedded system programming from bamafolks.com

Embedded Systems Programming service

August 1994 / Book and CD-ROM Reviews / Embedded Systems Programming

DEVELOPING REAL-TIME EMBEDDED SOFTWARE IN A MARKET-DRIVEN COMPANY, Karen S. Ellison, Wiley, ISBN 0-471-59459-8, $39.95

It must have been providence that arranged to have these two books arrive almost simultaneously. Here's a topic--developing embedded systems--explored by authors in two occasionally overlapping dimensions.

Although these books are complementary and not contradictory, I did encounter passages that suggested placing the authors together in a closed room would make for lively conversation. John Forrest Brown's Embedded Systems Programming in C and Assembly Language has a ``roll up your sleeves and do it'' attitude; Karen S. Ellison's Developing Real-Time Embedded Software in a Market-Driven Company is all about planning. I'll examine Embedded Systems Programming first.

I'm going to admit up front that I was confused about the audience that Brown was targeting. Initially, I was convinced that the audience was embedded systems software developers; specifically, those working in C and assembly language.

Not far into it, I decided I was wrong. True, there are plenty of code examples (and an included disk if you don't want to type everything in), but the book also contains guidelines on the design process. Admittedly, these guidelines are brief, but the appendixes hold reasonably complete requirements and design documents. I concluded that the person most likely to read this book would be a software engineer contemplating an embedded systems project.

For hardware platforms--specifically, CPUs--the book examines only the Intel 80x86 and Motorola 680x0 processors. In all assembly language examples, the au thor provides source code for both CPUs. Although Brown handled the parallel presentation of both CPUs well, I found it disturbing that he ignored a huge slice of the embedded CPU pie. Where are the Intel 8051s or the Zilog Z8s? And the Motorola 6800s?

The author suggests that most embedded architectural schemes are built around either a VME bus--and therefore will use a 680x0--or an STD bus--and therefore will use an 80x86. It seems to me that a more likely answer is that the examples given in the book, which consist of a pilot control panel and an interface box for a guided-missile-to-aircraft interface, are simply too complex to be easily handled by 8-bit embedded processors.

This is a book on C and assembly language, of course, and the author divides the work between those two languages as you might expect. C handles most of the computational work; assembly language picks up the ball when there's an interrupt service routine or start-up code to be managed. Start-up code is important enough t hat Brown devotes an entire chapter to it. In embedded systems, the start-up code is what starts all the digital blood flowing.

Meanwhile, Developing Real-Time Embedded Software is a case study of a ``hypothetical'' design project of an 80188-based drive controller. I put hypothetical in quotes because the documentation is so complete, the author's explanations and analyses so detailed, that I can't be certain that the described system isn't sitting in a computer somewhere.

Where Brown's book is heavy on programming tools and techniques, Ellison's is all on design guidelines. Ellison justifies the book's emphasis: ``System problems usually are not due to poor coding of individual components, but to poor design.'' I was gratified to see Ellison pay so much attention to performance analysis, three chapters in all. The first two such chapters concentrate on the analysis of individual system components (again, using the drive controller as the model project); the third chapter shows you how to pull all the components together and build an overall performance view of the system.

The entire design document--diagrams, tables, text, and all--is in the appendixes. I am tempted to say that if you learn by example, you should go straight for the appendixes. That would, however, be a mistake here. The author's style is too illuminating to miss. Besides, toward the beginning, Ellison suggests three alternative reading approaches. Pick the one you like best.

Is Embedded-System Programming for You?

Developers of embedded systems have to deal with constraints unknown to other coders. That's part of the challenge, but it's not for everyone. To a certain extent, the challenge for developers is to reorient their thinking for the world of embedded systems. "What they need to do is jump through a set of hoops mentally to think of computers and computer programming in a different way," says Barr.

"Writing software for embedded systems is considerably harder than writing software for a PC," contends Nigel Jones, a software consultant specializing in embedded systems. "With a PC, if your code screws up, you can just reboot the computer. You can't do that with embedded systems."

Developers working with PCs have the luxury of lots of computing power and memory. Not so with embedded systems. "If you're the sort of person that likes solving software jigsaw puzzles, then embedded is the place," says Jones. "If you just get pleasure from churning out code, don't go into it."

Help Me Get Into Embedded Systems Programming

I've had the idea for about a year that I should go into embedded systems programming. One reason for this is that many of the things I strive to achieve in my programming (efficiency and reliability) are valued in the embedded world much more than in the desktop GUI market. Another reason is, at least when I was looking a few months ago, I saw lots of job and contract ads looking for embedded programmers that offerred much higher pay than what I was seeing for GUI work.

Another reason is that I think the efforts the industry giants are putting into moving applications to the server (stuff like .Net and web services) are going to kill the GUI application market.

There are a couple of problems though. The embedded systems market has this whole huge body of knowledge and practice that I'm mostly unfamiliar with.

I have done some kernel-level work (mostly in the Mac OS, but I have tinkered with the Linux and the old BSD-based Sun OS kernels) and I've done a lot of work in 68000 and PowerPC assembly code. I also have a bachelor's degree in Physics and have done a lot of experimental work, and took courses in analog and digital electronics at UC Santa Cruz. But I know I have a lot to learn.

So here's how you can help me: recommend books I can read that can help me get started in embedded programming. I'm interested in both theoretical books (like architectural theory for embedded OSes) and I'm also interested in really practical things (like hands-on project books for hooking up toasters to 8-bit microcontrollers), techniques for day-to-day development and debugging, as well as books on learning electronics.

Full article from embedded system from dvogato.org

Programming Embedded Systems in C and C++

Embedded system software is in almost every electronic device designed today. There is software hidden away inside our watches, microwaves, VCRs, cellular telephones, and pagers; the military uses embedded software to guide smart missiles and detect enemy aircraft; communications satellites, space probes, and modern medicine would be nearly impossible without it. Of course, someone has to write all that software, and there are thousands of computer scientists, electrical engineers, and other professionals who actually do.

Each embedded system is unique and highly customized to the application at hand. As a result, embedded systems programming is a widely varying field that can take years to master. However, if you have some programming experience and are familiar with C or C++, you're ready to learn how to write embedded software. The hands-on, no-nonsense style of this book will help you get started by offering practical advice from someone who's been in your shoes and wants to help you learn quickly.

The techniques and code examples presented here are directly applicable to real-world embedded software projects of all sorts. Even if you've done some embedded programming before, you'll still benefit from the topics in this book, which include:

Testing memory chips quickly and efficiently
Writing and erasing flash memory
Verifying nonvolatile memory contents with CRCs
Interfacing to on-chip and external peripherals
Device driver design and implementation
Optimizing embedded software for size and speed
Making the most of C++ without a performance penalty
So whether you're writing your first embedded program, designing the latest generation of hand-held whatchamacalits, or simply managing the people who do, this book is for you.

For more details about this embedded system programming from netrino.com

Embedded Systems Programming in C and Assembler

John Forrest Brown's Embedded Systems Programming in C and Assembler takes a slightly different approach to explaining the integration of C into the embedded-systems-programming world. Some knowledge of both C and embedded-systems programming is presumed, and knowledge of the two major microprocessor architectures (Intel and Motorola) does not hurt, either. Brown begins with a useful introduction defining embedded-systems programming. Although he recognizes that much of what embedded systems used to perform can now be reasonably done using a dedicated PC, he explains the situations in which the flexibility of the PC might not be the asset it normally is. This is a good discussion of the virtues and perils of developing embedded systems in today's ever-changing corporate and technological climate.

After discussing essentially the same issues as Van Sickle with regards to the major parts of embedded-systems programming (interacting with timers, interrupt service routines, analog-to-digital converters, and so on), Brown moves on to several chapters of nuts-and-bolts programming, using examples from both Intel and Motorola wherever possible. Handling interrupts, an essential part of embedded-systems programming, is covered in great detail, showing where C or assembler might be more appropriate as well as the many differences between Intel and Motorola processors that cannot be easily hidden from the embedded-systems programmer. In all cases, Brown discusses possible timing problems, which can be very difficult to diagnose, along with possible solutions. As is fitting in a book devoted to C and assembler programming, mixed-language issues are discussed, shedding light on another area where microprocessor differences cannot be hidden.

Get more embedded system programming by visiting ercb.com

Based on embedded system programming

Based on my own experiences the embedded system programming is quite unfamiliar to many computer science professionals. This is quite a surprising when one thinks about their value to the modern society. Cringely (1998) claims that more than 99% of the microprocessor sold worldwide are used in the embedded systems. That is easy to believe since most cars, cellular phones, televisions, washing machines etc. contain a microprocessor. The amount of the embedded systems in the industry is even more overwhelming.

The embedded systems vary from huge switch board systems to tiny rice cookers. Thus, it is not possible to say what is typical embedded software. However, I try to list the specific features of those embedded systems that I feel are the target of EC++. I’ll concentrate on features that affect programming language selection.

The price of "normal" software results mainly from the design cost. The duplication is almost free. In embedded systems the duplication is not free due the manufacturing cost of the hardware. In order to save in the manufacturing, embedded systems are often build on a cheap technology. Thus, they often have a small amount of memory and a slow processor. The Figure 1 shows typical sizes and typical "future sizes" of some embedded software as reported by Plauger 1998.

Source from niksula.cs.hut.fi