To achieve the goals described in Part 1 in this series - portability, seamless multiprocessing support, design visualization and a rich content library - an XML-based configuration environment framework has been developed. Within it, designs are defined in compact XML (extensible markup language) using a multi-layered abstraction methodology.

This new development environment makes use of data driven techniques for monitoring resource usage for programming a microcontroller. It includes a configuration and design system with integrated datasheet information and three independent, but integrated workspaces to provide a programmer an organized way of displaying configuration and design information.

Figure 3: User Module Selection, Placement and Routing

The three workspaces (Figure 3, above) include a user module selection workspace, a user module placement workspace and a user module pin out workspace for allowing the programmer to select desired function components for a target microcontroller device. The configuration and design system includes data files that specify hardware resources that are tracked as the designer selects user modules to program the microcontroller.

Resource usage values are cumulatively tracked and displayed interactively in a resource manager workspace to enable the designer to keep constant track of the type of resources and the amount of resources used.

A resource display manager system provides real-time histogram view (e.g., a graphical view showing cumulative usage) of the resources being used by the programmer to design the desired microcontroller.

The resource display manager enables the programmer to only select only enough user modules that the microcontroller provides resources. If the programmer selects a module that requires more resources than is available, the design software of the present invention will not allow such a selection. The resource manager displays hardware resource usage by type and contents occupied/vacant, etc.

The user selection module provides a catalog of selectable user modules that are available for the programmer to select and a schematic display of a selected user module with corresponding datasheet information. This sub-workspace allows the designer to select the appropriate user module for a particular function.

Also included in this multilayered framework are system design blocks that are used by the programmer to place selected user modules to help program the target microcontroller. The design system blocks are analog and digital hardware resource or peripheral blocks of a target microcontroller device that are customized by the placement and configuration of the user modules.

Gluing It all together with XML data files
The glue that holds the various elements and workspaces together are XML data files associated with specific user modules and which indicate, among other things, the hardware required by the user module.

These user module data files provide the programmer a data entry environment to interactively enter desired data information of portions or sub-portions of the functional components of the user modules. The data files can easily be updated by the programmer without having to change the underlying resource manager code to reflect the resource tracking that the programmer desires.

Data values from the selected modules are cumulatively presented to the resource monitor display generator, which creates a file for each hardware resource that needs to be monitored.

Updates to the user modules in the resource database require only a change from the contents of an associated data file module without requiring corresponding changes in the underlying design system code. The component information database stores detailed description of the components that form the modularized functional blocks of the user modules.

Using the framework
Using this multilayer design framework, it is possible for a user to create a design targeted at a silicon device that has not yet been produced, graphically selecting and arranging objects that model real-world devices (or internal processor features), define the behavioral relationships between the objects (the system logic), and simulate the design on a computer to verify correctness.

While waiting for the (sometimes slow) silicon design, test and production process, the user can build a version of the design into an existing silicon device that has enough resources to support it (or cut the design down to fit an existing device), verifying with real-world hardware what the simulated behavior demonstrated.

As soon as the new desired silicon arrives (along with the appropriate hardware abstractions), the user can build, or target, his design into the new silicon, with a few mouse clicks, and remain confident in the results. Or similarly, begin a design with a certain size/cost device, add or remove features and then build into a different device, again preserving the design behavior.

The key to this portability is the hardware abstraction layers, and the common interface description between the desired resources of a design and provided resources of a device.

To see how this works in reality, let us use the earlier thermistors and fans example (Shown in Figure 1 in Part 1). We start by selecting our temperature inputs (actual devices we will use, thermistors originally) and place as many as we need on the screen, which was 5 in our example.

Figure 4: Partial Listing Of Input Devices Including Various Temperature Sensors

Figure 4 above shows a partial listing of available input devices (those trusted components) including various types of temperature sensing devices. Next we add our fan outputs, choosing from among different types and ratings of fans (and if portability is achieved, we needn't worry about our initial selections, since we can change them later). Again, a partial list of available output devices is shown in Fgure 5, below.

Figure 5: Partial Listing Of Output Devices Including Various Fans

Now we will define the behavior of our fans. For simplicity let us find the maximum temperature of thermistors 1, 2 and 3, and use that to define the duty cycle of one fan (how hard we drive the fan, starting at 30% in our case at 30°C up to 100% at 65°C), and then do the same with thermistors 4 and 5 for the other fan.

To do this we define some internal logic, first performing a sequence of "If-Then" comparisons to get the maximum temperatures (Figure 6, below); then using the maximum temperatures we perform a threshold comparison against setpoints of 30°C and 65°C.

Figure 6: Maximum Temperature Determination

And finally, with a truth table we define the fan drive to be at 0% (or OFF) when temperature is below 30°C, at 100% (or Fully ON) when temperature is above 65°C, and between 30°C to 65°C we will linearly ramp the fan drive from 30% to 100% (Figure 7 below shows all of the logic).

Figure 7: Set Points, Truth Table and Ramp Functions

After doing likewise for the second fan and thermistors 4 and 5, the resulting design is shown below  in Figure 8 and the simulation display Figure 9.

Figure 8: Design View Of Fan Controller

Figure 9: Simulation View of Fan Controller

All logic and design has been defined using real-world concepts rather than device-specific hardware concepts: temperature and percentage fan drive rather than ADC counts and pulse width modulation (PWM) counts or period.

To port this design to a specific target device, choose build and a list appears of represented devices (for which there exists a hardware description with the abstraction layer defined) that have sufficient resources to support the design (enough analog input channels for the thermistors and PWM outputs for the fans). Figure 10 below shows a screen capture of list of represented devices.

Figure 10: Build Screen Showing Available Target Devices

Since hardware targets rely upon specific circuit incarnations, which for a microcontroller means pins and package types, the user chooses the target device and, if desired, the assignment of pins (another aspect of portability, for adapting to a legacy design). Figure 11 below shows an automatic pin assignment on the left and a user-selected pinout on the right. If you want to change device or pinout, choose build again and make your new selections.

Figure 11: Pin Assignment, Automatic On The Left, User-defined On The Right

What about seamless multiprocessing?
We have seen three of the required Utopian ingredients in operation: design visualization, rich content library and portability. What about seamless multiprocessing? Moving a design like the one in Figure 1  to match the design of Figure 2 in the earlier Part 1 is an example of using multiprocessing.

We can adapt the single-controller-design sensing 5 thermistors directly (hard-wired) to a design that accesses, via an I2C communications bus, 5 thermistors sensed by two other remote microcontrollers (enabled as I2C slave devices). To create the remote devices, start with our original design (Figure 7 earlier), and remove all of the fans and 2 of the thermistors. The result is shown in Figure 12, below.

Figure 12: Original Design Cut Down To three Thermistors Only

What's left in the design is only what's necessary to sense and report the temperature of 3 thermistors. Now we enable this device to act as an I2C slave by adding an interface (choose one with an address pin as shown in Figure 13, below). Setting the base address to 4, the single address pin will allow this device's address to be either 4 (if address pin is held low) or 5 (if address pin is held high).

Figure 13: Communications Interface Selections, I2C Slave Shown

Choose build, select the target device and the program code as well as a project datasheet is generated. Notice how the datasheet defines the communications protocol and the subaddress or offset for the register holding each thermistor value (Figure 14, below).

Figure 14: Project Data Sheet Excerpt Showing I2C Register Map And Protocol

Let's assign the device with its address line held low as the one that senses thermistors 1, 2, and 3 (I2C Address 4, the upper left circuit board of figure 2) and the one with its address line held high as the one that senses thermistors 4 and 5 (I2C Address 5, the lower left circuit board of Figure 2 in Part 1). To adapt the main (fan controlling) device to use these remote sensors rather than hard-wired thermistors, we switch the temperature devices in the design (one at a time) from a thermistor to an I2C remote slave, then set the I2C address (4 or 5 as appropriate) and the subaddress offset (from the generated datasheet, 0, 2 or 4 for thermistor 1, 2, or 3 respectively).

Based on the the individual remote temperature device settings inputted, Figure 15 below shows the updated design. Switch to simulation and you will see that the new design operates the same as the hard-wired design.

Figure 15: Fan Controller Using 5 I2C Slave Remote Temperature Sensors

Choose build and select the target device to generate the program code, along with the project datasheet showing the new pinout (Figure 16, below). Notice the difference between this pinout and the one in Figure 10 earlier using thermistors.

Figure 16: Project Datasheet Excerpt Shows New Pinout

Is this seamless? Within the constraints of a sampling control system, yes it is. Each control loop iteration, whether the temperature inputs are sampled analog signals or digital I2C values the inputs are refreshed, the logic performed and the fans updated. In our design we only chose how these temperatures would be determined, everything else was generated for us.

You should be able now to imagine how a system can be broken down into many small tasks, across many devices, and where necessary, data from one device can be accessed by another. Although we used I2C as our communications medium, there is nothing built into the design that precludes using any other medium (standard serial, SPI, one-wire, USB or RF).

What's The Catch? Is There A Chicken?
The only possible catch is that, like any other relatively new methodology that relies upon content, a certain amount of content must exists before a useful design is possible, and for more content to appear people need to be using the system (creating useful designs).

There is support for over two hundred devices right now (in Q3 of 2006) and new drivers are appearing at a faster rate each quarter. The content rules and architecture are defined in a driver developer guide and publicly available, so that anyone can review and understand the low-level implementation details and learn to create their own.

The ever-growing complexity of embedded systems, those all-in-one designs, do not necessarily indicate a trend toward greater productivity and higher quality. But if you accept the premise that more small manageable devices solving a larger problem through extreme partitioning is a valid solution, then you need a design tool that provides portability, seamless multiprocessing, design visualization and a rich library of trusted components.

To read Part 1 go to "Defining the ideal embedded development."

Jon Pearson is the product manager for PSoC development tools at Cypress Semiconductor Corporation. Jon has been with the PSoC product line since its first offering in 2000 and led the definition of PSoC Express. Prior to joining Cypress, Jon developed embedded systems using controllers of various size and complexity for projects as diverse as satellite modem controls and aircraft electric power generation. You can reach Jon with questions and comments by email at jpx@cypress.com.