Embedded systems designers deserve better than the feature-lacking point-tools available today. Embedded designs should be more than a collection of microcontrollers and discrete components, pulled together by board design tools and software development environments that are not aware of each other presence, let alone integrated together.
Programmable devices are not new. Embedded software is older than most of us! And a lot of embedded design is highly focused on specific interaction between the software and peripherals. So why do we still not have tools that bring all this together and make our lives easier and more productive?
In September 2009, Cypress Semiconductor introduced the PSoC Creator embedded design tool for its new PSoC 3 and PSoC 5 programmable system-on-chip architectures to address this question. PSoC Creator integrates support for PSoC programmable hardware with a full-featured software IDE.
It abstracts away the hardware so you do not need to be an expert on the device you are using or the inner workings of peripherals you program it with. It routes on-chip connections and I/O automatically. And it generates APIs for the peripherals and on-chip functions, which are known as components, to ensure error-free interaction from software.
The nuts and bolts of PSoC Creator
Once you press the build button PSoC Creator uses a number of tools to convert your designs and application code into a flash-able image.
Elaboration. All designs are hierarchical and so the first thing that needs to happen is elaboration; the TopDesign is parsed for all the constituent components and those, in turn, are parsed, all the way down the line. The result is effectively a flattened-out (non-hierarchical) version of your design.
HDL Generation. HDL (Hardware Description Language) generation is the next step. At the lowest level all components are implemented in Verilog. The flattened out design is translated into an HDL netlist.
Synthesis. This is a two-step process; logical and physical. The logical step optimizes the design (i.e. removes unused elements) and generates a simpler register-transfer-level (RTL) representation of (primitive) components and Boolean equations. The physical step identifies and maps the primitives to physical hardware in the device and then connects signals through the “switch fabric” or routing network.
API Generation. Next comes the generation of boot code and API files and their addition to the Workspace Explorer. API files are defined as part of the component and the generated files use the name of the component instance as a prefix so that each instance has its own APIs (no pointers to RAM-based data structures).
Compilation and Linking. PSoC 3 and PSoC 5 use industry-standard CPU architectures; 8051 and ARM Cortex-M3, respectively, so that you can choose your favorite compiler. For PSoC 3, a fully-functional Keil CA51 compiler package is included, free of charge, in the distribution.
To get the best levels of optimization you can upgrade by purchasing the professional version from Keil. For PSoC 5 the GNU GCC compiler is included. Also supported is the RealView compiler, available from ARM Ltd.
Hex File Generation. The final step in the process is the generation of the flash image in a hex file. This file includes the software application and bitstream that was generated by the physical synthesis of the design.
Putting PSoC Creator to work
To illustrate the design flow you would follow in a typical application using Creator, in this article we will take a mixture of digital and analog components, quickly configure them into the PSoC 3 device (Figure 1, below ), then build a simple but useful application that monitors a pin for an over-voltage condition, controls a warning LED, and records the number of events and maximum duration of that state.
You will not need to know the CPU architecture we’re using, or how the analog comparator or digital timer components are implemented. The only thing you need to know about the chip is the pin numbers you want to use for the I/Os, and even these the tool can choose those for you based on your design.
|Figure 1. PSoC 3 device mounted on a PSoC Developers Kit processor module.|
There are three distinct parts to our design. The first is the voltage comparison circuit that uses a comparator to determine the over-voltage condition on a pin (Figure 2, below ).
The second part controls the warning LED; flashing brightly when the voltage is high but remaining on permanently when the voltage returns to a safe level to signal that a dangerous condition has occurred.
Thirdly, we’re generating some statistics on what has happened with a counter that detects how long the voltage is high so that we can record both the number and maximum time of over-voltage conditions.
|Figure 2. Over-voltage monitoring schematic in PSoC Creator|
Let’s start with the voltage comparison circuit. It requires an analog input pin, a Voltage Digital-to-Analog Converter (DAC) that creates a reference voltage and a Comparator that outputs a digital high/low signal to indicate the voltage level.
To create the design, open a new blank project and start dragging and dropping the components into the schematic. Components are presented in a catalog down the right-hand side of the tool.
There’s a search utility at the top of the panel and components are arranged in a familiar tree structure in folders named Analog, Digital, Communication and so on. You can quickly find the Analog Pin in the Ports and Pins folder (Figure 3, below ). Clicking on that gives you a preview of the symbol and access to a datasheet.
|Figure 3. Component Catalog showing an Analog Pin selected.|
To use the Pin, just drag it into the design. Do the same thing with the DAC and the Comparator and, in seconds, you have the makings of the circuit. But wait, you may ask, how did we set up the reference voltage? This is where component parameters come into play.
You simply double-click on the component in the schematic and up pops its Parameter Editor dialog. Components are parameterized so that you can configure them with the attributes you need. The parameters are carefully selected to present the configuration in a manner that makes sense to the designer and abstracts out the implementation.
In the DAC we choose between a low (0V – 1V) and high (0V – 4V) voltage range and simply choose the voltage we want. You do not choose the on-chip resource for the DAC, and there are no register settings, no bit-fields to check, and no masks to apply. Close the dialog and that’s all it takes to create a voltage reference in your design.
To the left of the schematic is a palette of useful design tools, including the wring tool. Single click to draw one wire, and double-click to enter a multiple wire-drawing mode. Draw wires between the component terminals and we’re done – a voltage-testing circuit designed and implemented in about a minute.
We now need to decide what to do when the over-voltage condition occurs. We’re going to flash a warning LED whenever the voltage is high but, rather than forget about the problem once the voltage drops, we’re also going to leave it shining so that, even though you may have missed it, you can still see that an error condition has occurred.
To do that we’ll use a D Flip-Flop component. Drag it into the schematic and wire the Comparator output to its clock input. Notice how the wires are a different color; with analog wires showing as orange, whereas digital wires are automatically drawn in green.
A Logic High (1) component goes on the D input so that, the first time the Comparator outputs a high signal, the Flip-Flop output will go high (and stay that way). This is how we remember that the condition occurred and there is no need to ever reset the Flip-Flop.
A digital MUX is used to select between signals that can get routed to the LED (a digital output Pin). When the voltage is high we use a clock component, set to 10Hz, to flash the LED and, when the voltage is low, the Flip-Flop output signals whether an over-voltage condition has occurred in the past.
The final part of the design uses a Counter component with a 1kHz Clock (Figure 4 below ). This combination is used to count the number of milliseconds that the voltage is high.
|Figure 4. Configuration of a 16-bit Up counter with a 1ms period and falling-edge capture.|
The comparator output is used, once again, to reset the counter (sets the internal counter value back to zero) when the voltage goes low and enable it when the voltage is high. A capture input records the counter value on the falling edge of the Comparator signal and generates an ISR to count the number of over-voltage conditions and record the longest duration.
Building your design
Your PSoC design is now ready to be generated using Creator. Just press the build button on the toolbar and the whole application – schematic and software – will get built into a single flash-able image.
Part of the build process is to generate APIs for the components and stub handlers for the interrupt. These are really useful because, as in all designs, we now need to write a little software.
PSoC Creator projects include all the boot code needed to get the device up and running, so you only work on the application, which gets started in the main.c file. All we need to do is use the APIs to initialize and start running the components; DAC, Comparator, and Counter; then install the ISR and enable interrupts. The code to do that looks like this:
The interrupt handler has its own source file – VoltageLo_isr.c – and that contains user-editable sections, into which we put our handler code (between the `#START` and `#END` comments, like this:
Before we build again we can choose our pins (Figure 5, below ). On a PSoC 3 device you can route any function to any pin – you’re not limited to the manufacturer’s choice. Just open the resources file and drag your pins onto the device I/O of your choice.
|Figure 5.Selecting pins on PSoC 3 device.|
When we run the build process again it creates a “bitstream” of the design, generates the APIs we called from our software above, then compiles and links the software into a single image (hex file). From here you can simply flash the device, reset, and the program runs.
PSoC Creator includes a debugger (Figure 6, below ) just in case, like me, you don’t usually get your designs right the first time. The debugger offers full visibility into the system with C and assembler views, a rich set of debug “windows”, hardware breakpoints and code execution functions, all fully integrated into the IDE.
|Figure 6. The MiniProg3 programmer/debugger is all you need to debug PSoC devices via JTAG or SWD (serial wire debug).|
So now we’ve seen the complete development cycle in PSoC Creator. We’ve drawn the design, generated the APIs, written some C code, chosen our pins, and programmed the built image into the part’s flash memory. Making changes is almost instantaneous; just fix it and flash it!
Perhaps this is the most important attribute of the tool – that it encourages you to play and, as a result, to learn. You get the results of experiments immediately and there’s no cost to trying anything you dream up.
We’re not allowed to design on folded-out cigarette packets any more. We have to use whiteboards and big chunky pens containing noxious-smelling chemicals. With PSoC Creator you can simply draw all your mad, middle-of-the-night ideas straight into a project and test them out. And, we promise, it will never make you cough or go dizzy.
Mark Saunders is a Senior Product Marketing Manager at Cypress Semiconductor. He has a First Class degree from the University of Leeds, England, and over 20 years of experience in embedded software and intellectual property (soft IP). He specializes in the development, support and marketing of embedded software tools, real-time operating systems, protocol stacks and middleware.