Building correct by design embedded systems using a high level graphical programming environment: Part 2 - Embedded.com

Building correct by design embedded systems using a high level graphical programming environment: Part 2

To achieve the goals described in Part 1 in this series -portability, seamless multiprocessing support, design visualization anda rich content library – an XML-basedconfiguration 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 driventechniques for monitoring resource usage for programming amicrocontroller. It includes a configuration and design system withintegrated datasheet information and three independent, but integratedworkspaces to provide a programmer an organized way of displayingconfiguration and design information.

Figure3: User Module Selection, Placement and Routing

The three workspaces (Figure 3,above ) include a user module selection workspace, a user moduleplacement workspace and a user module pin out workspace for allowingthe programmer to select desired function components for a targetmicrocontroller device. The configuration and design system includesdata files that specify hardware resources that are tracked as thedesigner selects user modules to program the microcontroller.

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

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

The resource display manager enables the programmer to only selectonly enough user modules that the microcontroller provides resources.If the programmer selects a module that requires more resources than isavailable, the design software of the present invention will not allowsuch a selection. The resource manager displays hardware resource usageby type and contents occupied/vacant, etc.

The user selection module provides a catalog of selectable usermodules that are available for the programmer to select and a schematicdisplay of a selected user module with corresponding datasheetinformation. This sub-workspace allows the designer to select theappropriate user module for a particular function.

Also included in thismultilayered framework are system design blocks that are used bythe programmer to place selected user modules to help program thetarget microcontroller. The design system blocks are analog and digitalhardware resource or peripheral blocks of a target microcontrollerdevice that are customized by the placement and configuration of theuser modules.

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

These user module data files provide the programmer a data entryenvironment to interactively enter desired data information of portionsor sub-portions of the functional components of the user modules. Thedata files can easily be updated by the programmer without having tochange the underlying resource manager code to reflect the resourcetracking that the programmer desires.

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

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

Using the framework
Using this multilayer design framework, it is possible for a user tocreate a design targeted at a silicon device that has not yet beenproduced, graphically selecting and arranging objects that modelreal-world devices (or internal processor features), define thebehavioral relationships between the objects (the system logic), andsimulate the design on a computer to verify correctness.

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

As soon as the new desired silicon arrives (along with theappropriate hardware abstractions), the user can build, or target, hisdesign into the new silicon, with a few mouse clicks, and remainconfident in the results. Or similarly, begin a design with a certainsize/cost device, add or remove features and then build into adifferent device, again preserving the design behavior.

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

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

Figure4: Partial Listing Of Input Devices Including VariousTemperature Sensors

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

Figure5: Partial Listing Of Output Devices Including Various Fans

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

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

Figure6: Maximum Temperature Determination

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

Figure7: Set Points, Truth Table and Ramp Functions

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

Figure8: Design View Of Fan Controller
Figure9: Simulation View of Fan Controller

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

To port this design to a specific target device, choose build and alist appears of represented devices (for which there exists a hardwaredescription with the abstraction layer defined) that have sufficientresources to support the design (enough analog input channels for thethermistors and PWM outputs for the fans). Figure 10 below shows a screencapture of list of represented devices.

Figure10: Build Screen Showing Available Target Devices

Since hardware targets rely upon specific circuit incarnations,which for a microcontroller means pins and package types, the userchooses 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 pinassignment on the left and a user-selected pinout on the right. If youwant to change device or pinout, choose build again and make your newselections.

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

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

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

Figure12: Original Design Cut Down To three Thermistors Only

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

Figure13: Communications Interface Selections, I2C Slave Shown

Choose build, select the target device and the program code as wellas a project datasheet is generated. Notice how the datasheet definesthe communications protocol and the subaddress or offset for theregister holding each thermistor value (Figure14, below ).

Figure14: Project Data Sheet Excerpt Showing I2C Register Map And Protocol

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

Based on thethe individualremote temperature device settings inputted, Figure 15 below shows the updateddesign. Switch to simulation and you will see that the new designoperates the same as the hard-wired design.

Figure15: Fan Controller Using 5 I2C Slave Remote Temperature Sensors

Choose build and select the target device to generate the programcode, along with the project datasheet showing the new pinout (Figure 16, below ). Notice thedifference between this pinout and the one in Figure 10 earlie r using thermistors.

Figure16: Project Datasheet Excerpt Shows New Pinout

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

You should be able now to imagine how a system can be broken downinto many small tasks, across many devices, and where necessary, datafrom one device can be accessed by another. Although we used I2C as ourcommunications medium, there is nothing built into the design thatprecludes using any other medium (standard serial, SPI, one-wire, USBor RF).

What's The Catch? Is There AChicken?
The only possible catch is that, like any other relatively newmethodology that relies upon content, a certain amount of content mustexists before a useful design is possible, and for more content toappear 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 areappearing at a faster rate each quarter. The content rules andarchitecture are defined in a driver developer guideand publicly available, so that anyone can review and understand thelow-level implementation details and learn to create their own.

The ever-growing complexity of embedded systems, those all-in-onedesigns, do not necessarily indicate a trend toward greaterproductivity and higher quality. But if you accept the premise thatmore small manageable devices solving a larger problem through extremepartitioning is a valid solution, then you need a design tool thatprovides portability, seamless multiprocessing, design visualizationand a rich library of trusted components.

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

Jon Pearson is the product managerfor PSoC development tools at Cypress Semiconductor Corporation.Jon has been with the PSoCproduct line since its first offering in2000 and led the definition of PSoCExpress. Prior to joining Cypress, Jon developed embeddedsystems using controllers of various size and complexity for projectsas diverse as satellite modem controls and aircraft electric powergeneration. You can reach Jon with questions and comments by email at jpx@cypress.com .

Leave a Reply

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