Designing embedded controllers with building blocks - Embedded.com

Designing embedded controllers with building blocks

It's child's play. Baruch Evenor describes a new building-block approach for designing embedded controller systems destined for mid-range apps with limited memory space.

One day several years ago, the quick response product development team at our company was asked to do the impossible: develop a new project and deliver a working prototype of a broad-band (5 MHz to 20 GHz) long-range fiber-optical analog link system to a government contractor in 30 days.

This system needed to contain portable microwave-modulated optical transmitters, receivers and power-supplies modules, and be controlled and monitored by embedded controller (EC) chips. Of course, we couldn’t use off-the-shelf modules because each module had stringent optical, electrical, environmental, and mechanical requirements.

Since we were a one-year-old start-up company, we had to deliver. Our existence was at stake. We desperately needed that contract. Needless to say, our customer was skeptical we could deliver, but we had to prove him wrong. Working around the clock, the designing, manufacturing, and populating of the printed circuit boards for all these modules took us about 16 days. Likewise, designing, machining, and assembling the mechanical enclosures of all the modules took us about the same time. Integrating the fiber-optical components and testing took us another six days.

The prototype was “kind of” ready in 29 days.

All was working according to the specifications except, of course, the software for the embedded controllers. Since we made all the modules such that they can still perform all the critical functions without the software, our customer was kind enough to accept the delivery and gave us the go ahead to begin the production (pending our software completion within three months). We delivered the first production lot three months later with the first software version. Twenty-two software versions proceeded until we completed the delivery of all the lots 20 months later.

Everyone seemed to accept the fact that software design is a never-ending process where each new version fixes some (but never all) of the problems. None of the managers would dare challenge the mysterious ways by which the software code was developed.

Because our programmers worked around the clock, they received a large bonus and to this day, no one (but perhaps the originators) can actually comprehend the resulting code. Due to the rush, there where practically no documents of that software. We knew that the life cycle of our system was short, so no one bothered documenting.

Two years later, when the same customer needed a very similar product, we started the software design from scratch, as if nothing ever existed. Unfortunately by then, the two programmers who wrote that code retired, and we found out that EC programmers are a rare breed. Apparently, today EECS students and teachers prefer “cleaner” software not burdened by hardware, or at least, software that already has an operating system.

Time to change
This story is an old story to us and one that repeats again and again, I am sure, for almost any software developer who has been doing this for any length of time. By this time, I had participated and led the design of numerous EC systems for airborne and ship-board electronic counter measures (against radar, missiles, and communications); missile electronics; radar and communication electronics; and fiberoptic communication systems—all with similar problems.

But after this last experience, I made up my mind to do something. Having an EE degree as well as a master’s and PhD in electronics with minor in computer science, I decided to combine my multidisciplinary background in systems design, electronics hardware design, and computer programming, to develop a new method for software design for mid-range EC systems that have no room for a conventional operating system.

The new concept is born
My team and I spent more than five years developing a new design method for EC software (and the interface hardware). We wanted to name this new method “Lego-Code” since the system’s design methodology (of both the software and interface hardware) resembled the way people construct “castles” with Lego blocks. However, since the word Lego is already a trade name, we named our method “Game-Blocks-Code.” We also named Game-Blocks-Code’s automatic code generator Embedded-Controller-Code-Maker or ECCM.

We started this development with few simple questions:

1. Why does a typical design of electronic board take 10 days while the code development of its EC takes several months and is never bug free?

2. How can we make code development as simple as hardware design?

3. Why are student and teachers “afraid” of learning and teaching EC design?

4. How can we make the process of EC systems design (software and interface hardware) simple, visual, and more fun?

5. How can we make the process such that an entry level EE or programmer (with basic knowledge in hardware) can perform the design?

6. How can we take the “mystery” out of the code generation and replace it with consistent methodology and simplicity so that the designer can direct his or her creativity to aspects of the system design, rather than the code itself?

7. How can we make the software and the hardware merge into one visual block diagram that everyone can easily comprehend?

After spending more than five years answering these questions, we believe that our Game-Blocks-Code approach can hit a wide range of targets and is also fun to use. In rest of this article, I describe our concept and provide a link to an operational code example (including the source code for Microchip’s PIC16XXX) for a simple operating system that can schedule three tasks. By using such a Game-Blocks-Code method, you can extend a simple operating system within hours rather than several weeks and add functions to it, such as:

• Analog-to-digital and digital-to-analog conversion.

• Clocks and timers.

• Pulse capture and pulse generate.

• Digital filtering.

• Math equations and software algorithms.

• Multiprocessing systems.

The Game-Blocks Method
A simple way to understand Game-Blocks-Code is to compare it with standard approaches to electronic hardware design. Obviously what made the design of electronic hardware easier was the introduction of the integrated circuit (IC). Typically, each IC replaced thousands of discrete electronic components and was treated by the designer as a black box.

Prior to the IC, a typical design cycle of a printed circuit board (PCB) lasted more than six months, and required high level of knowledge in electrical circuit design. Now, when designing with ICs, a typical design cycle of a PCB may last one to three weeks. Designing with ICs doesn’t require the understanding of the thousands of components (located inside the IC). The designer needs only to understand the properties of the input and outputs (I/O) of the IC (and the relationship between the I/O).

That black box (the IC) has a set of well-defined I/O pins, and the relationship between them is specified by a datasheet. To design a certain electronic hardware system, the designer needs to be familiar only with the datasheets of the ICs that are required for his or her system (but not with the internal components of these ICs). In general, the design process of an electronic hardware system, for example, consists of three (relatively simple) steps:

Step_1: The designer selects all the ICs that are required for his project.

Step_2: The designer interconnects the output pins of certain ICs with the inputs pins of other ICs.

Step_3: The designer debugs the resulting project but doesn’t need to debug the ICs.

Similarly, the Game-Blocks-Code approach also is a three-step process, but rather than one to three weeks, the typical design cycle is just a few hours, certainly no more than one day.

The role of SIMs
The fundamental building block of the Game-Blocks-Code concept is the software/ hardware integrated module (SIM). Conceptually a SIM is similar to a hardware IC. Both the SIM and IC have predefined (by a set of specifications or a datasheet) I/O ports. In general, when using both (the SIM and IC), a designer can develop a system by interconnecting multiple ICs or multiple SIMs. The block diagram of both the SIM and IC (and the ability to easily depict them) allows the designer to depict the entire system simply by depicting the interconnection between the I/O ports of the SIM and the IC .

But there are fundamental differences also. The interconnections between the I/O of the IC are achieved via copper lines (lines), while the interconnections between the I/O of the SIM are achieved via abstract connections (named wires) in the software code. Similar to designing hardware with an IC, when designing software with Game-Blocks-Code SIMs, the designer isn’t required to deal with the software instructions associated with each SIM. Instead, he or she only deals with the I/O ports of the SIM and the relation between them, as specified by the datasheet of the SIM.

Although a SIM may contain hundreds of software instructions, it’s easy to define it by its datasheet. The datasheet simply specifies the functions of the software I/O ports of the SIM and the relationship between them. If that SIM also contains hardware functionality (such as analog, digital, or pulse I/O), the SIM and its block diagram include the needed hardware I/O ports (or pins) in addition to the software I/O ports. The generic block diagram of a SIM is depicted in Figure 1 , while the block diagram of a SIM that has only software I/O is shown in Figure 2 .


Click on image to enlarge.


Click on image to enlarge.

When using a SIM-based Game-Blocks approach, there are only three relatively simple steps:

1. Select the modules and create their code;

2. Define the interconnects between the modules and integrate the code; and

3. Maintain and modify the software and hardware.

Step #1: Selecting the modules and creating their code. After the designer selects all the SIMs that are required for his or her project, the designer uses Game-Blocks-Code’s modules tool, which contains the datasheet for each SIM in order to automatically create the code for each SIM.

The code associated with the specific designer’s requirements is automatically created (for each SIM) by the modules tool, based on answers designers interactively provide to “questions” posed by the modules tool.

Also, Game-Blocks-Code creates the code of each SIM so that the resulting code of the SIM can be automatically integrated with the code of the other SIMs. Thus, the key parameters of the code are defined by the user, but the I/O ports are kept (by Game-Blocks-Code) compatible with standardized I/O ports of the remaining SIMs.

Like the IC, each SIM has a datasheet, however the datasheet of the SIM is an active datasheet, which contains macros or other high-level language programs that convert the user’s answers and clicks into the required assembler code (in other words, the assembler code of that EC chip).

Step #2: Defining the interconnections between the modules and integrating the code: The designer defines the interconnections between the I/O ports of the participating SIMs and then activates Game-Blocks-Code’s integrator tool (by a click on a button). The interconnections are defined simply by providing to the integrator tool the WIRE_LIST, a two-column table where each entry specifies the SIM ID and the port ID to be connected.

The integrator tool automatically modifies the code (previously generated by Game-Blocks-Code’s modules tool) of all the SIMs according to the WIRE_LIST. It also automatically rearranges the code of all the SIMs and loads the rearranged code in predefined code zones of a certain SIM whose code is activated by the CPU reset. The predefined code zones separate the code of each SIM into the specific EC chip’s memory locations, such as:

RESET_VECTOR, INTERRUPT_VECTOR,
INTERRUPT_SERVICE_ROUTINES,
CODE OF SUBROUTINES, CODE OF MAIN , etc …

The resulting “final system code” is loadable assembly language that’s ready to be assembled and loaded into the CPU chip’s memory (or into a simulator/emulator). All this integration process is performed automatically by the integrator tool, without user intervention.

Step #3: Maintaining and modifying the software and hardware. By using the block diagram of the SIMs and the wires between them, the designer can now draw and visualize the interconnections between the SIM’s software I/O as well as the interface between the SIM’s hardware I/O to the external electrical components (such as ICs, switches, transistors, resistors, capacitors). More importantly, using Game-Blocks-Code, the designer can now maintain and upgrade the system code in the following ways:

1. To change parameters of the system: revise the answers to Game-Blocks-Code’s modules tool.

2. To add certain functionality to the system: select the additional SIM(s), answer the associated questions, update the WIRE_LIST, then activate Game-Blocks-Code’s integrator tool.

3. To integrate two (or more) subsystems that were designed by the Game-Blocks-Code tools: create a combined WIRE_LIST that replaces the individual WIRE_LIST of each subsystem. Figure 3 illustrates this process in a bit more detail.


Click on image to enlarge.


Flexible SIMs.
In some cases, the available SIMs can’t provide all the answers to the designer. Therefore Game-Blocks-Code provides the flexible SIMs, where each of them can hold a subroutine and still be integrated with other SIMs.

Generating high-level language code

Currently, most of the high-level software development tools for ECs are C language compilers that require significant on-chip memory space (typically unavailable). This approach has several limitations:

1. The code generated by the C compiler doesn’t provide visualization of the software/hardware system.

2. ECs incorporate many on-chip hardware devices (such as timers, pulse capture and generate, analog-to-digital and digital-to-analog converters) that have to be controlled by assembler code. Therefore, the resulting code is a mixture of C and assembly that is obscure and difficult to manage.

Algorithm-generating SIMs.
Using an algorithm-generating SIMs, it’s possible to create code in a special Basic language by clicks on code templates. These SIMs, have well-defined software I/O ports (easy to visualize and simple to integrate with other SIMs) allowing the designer to create complex algorithms in Basic by using a simple interactive code-generation technique based on code templates.

The datasheet of each algorithm-generator SIMs contains code templates (in Basic) that can be clicked by the user to create the Basic code for the algorithms. So, unlike C compilers, when using algorithm-generating SIMs, the code templates are automatically provided to the user (by a click on a certain instruction). Also, code templates contain all the syntax and parameters associated with each instruction, thus preventing syntax errors.

A click on a button converts the Basic code into assembly code, and, unlike C compilers, the design tool automatically includes the functions that are needed. Finally, the resulting assembler code of the algorithm generator is created such that it can be automatically integrated with the assembler code of other SIMs.

To conclude, we’ve made many “Game-Blocks generators” that can automatically and interactively create code for modules capable of analog-to-digital and digital-to-analog conversion; clocks, timers, and scheduling; pulse capture and pulse generation; digital filtering; and math-equation and software-algorithm creation—all by clicking on code templates that are provided in high-level language. We’ve even used our Game-Blocks generators to create multiprocessing systems, among many other functions. Finally, we made sure that the code-integration tool can seamlessly and automatically integrate the code of these modules as needed.

Putting the concept to work
To illustrate how the Game-Blocks-Code can be used, I developed a design example consisting of a simple operating system that schedules (executes) three periodic tasks with user-defined periods and which I created using Game-Blocks-Code. The source code for this example, written in assembly is in a separate text file named MY_SIMPLE_OS_SOURCE_CODE.asm, downloadable at www.eetimes.com/design/embedded/source-code/4210739/MY-SIMPLE-OS-SOURCE-CODE.

A block diagram of this example’s Game-Blocks system code is shown in Figure 4. (Editor’s note: Figures 4 through 8 and Table 1 are available as PDFs. Click on figure number to access the PDF.) The block diagram consists of four ECCM modules (selected out of the more than 50 available) and the interconnections between them. After we defined the participating ECCM modules (as depicted in Figure 4), we created the WIRE_LIST, available in Table 1.

The four ECCM modules used in this example are illustrated in Figures 5, 6, 7, and 8 (click to access) and consist of modules for S2A_MAIN_INFINITE_LOOP, S5E_TIMER0_CLOCK_MODULE, S11A_REAL_TIME_SCHEDULER, and S901A_MONITOR_ME.

For details about each of these elements, refer to Table 1 online and to the corresponding elements as noted:

• DO_1.1—>_1.3: Initializes and activates the modules of this code (achieved by module S2A_MAIN_INFINITE_LOOP).

• DO_2: Generates the clock-tics (CLK_TICs) in this system (achieved by module S5E_TIMER0_CLOCK_MODULE).

• DO_3.1—>_3.3: Generates scheduling periods that can activate events (done by module S11A_REAL_TIME_SCHEDULER).

• DO_3.1—>_3.3: Provides a place-holder for future code containing user created events (done by S901A_MONITOR_ME).

The two-column Table 1 (click for PDF) contains the WIRE_LIST that was provided to the code integration tool and was used by the tool to create the final system code. It defines the connections between the output and input software ports of all the SIMs that are used in the design of a certain embedded system. Each interconnecting port is defined by the SIM’s ID followed by the port’s ID (see Figure 4 for example of SIM and port ID). Next to the two-column entry (on the right in Table 1), I included a short comment (marked as DO_1,2,) about the objective of that software wire.

We’ve created many Game-Blocks generators that can automatically and interactively generate the code for modules capable of a wide variety of functions, from analog-to-digital and digital-to-analog conversion; pulse capture and pulse generation, and other functions mentioned earlier, to creating a multiprocessing system, among many other functions. We’ve also made sure that the code integration tool can seamlessly and automatically integrate the code of these modules as needed.

Baruch Evenor represents the ECCM company (www.embedded-controller-code-maker.com). He has a PhD and master’s in electrical engineering and a minor in computer science from the Naval Postgraduate School in Monterey, Calif., as an ex-Naval officer. He is also an EE graduated of the Technion Engineering School and has been involved in the design of systems for a wide variety of defense electronics systems for electronic counter-measures, missile, and fiber-optic based telecom systems. He can be contacted at .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.