A new way to do firmware development on programmable devices - Embedded.com

A new way to do firmware development on programmable devices

In this Product How-To article Mark Saunders describes a new methodology for doing firmware development for the Cypress’ Arm-based Programmable SoCs, using the company’s PSoC Creator in combination with Arm’s uVision IDE.

Programmable devices are really cool and powerful, if you are a hardware designer. If you are a software developer, they can be a real headache, giving that you’ll be charged with writing the firmware for this ever-changing target. Device vendors typically solve this problem by incorporating software development features into their tools to create an all-inclusive environment that claims to support both disciplines.

The difficulty with this approach is that it forces software engineers to adapt to the tools hardware designers use, a situation that is less than ideal when you consider the heavily skewed ratio of software to hardware designers on a typical project.

Sometimes a single tool does work, but often not well for a distributed team of engineers with sophisticated and mature development flows already in place. These engineers need tools that reverse-engineer their thinking and incorporate hardware design into existing third-party software development flows, such as Cypress’ PSoC Creator coupled with ARM’s uVision IDE.

This combination satisfies the needs of both sides, freeing hardware engineers to innovate in silicon without creating a software development bottleneck.Just as the programmable capacity and CPU performance of today’s programmable devices vary enormously, so does the size and make-up of the design teams that use them. It is still common for successful applications to be built by a single engineer with expertise in both hardware and software.

More and more often, however, products are being designed by small teams with fairly differentiated roles: the hardware experts handle device configuration and write just enough software to verify that the system works as expected, leaving the software team to develop the application code. These distributed teams may not work in the same building or even the same country for that matter.

Your Tools, Your Way
All of these users can benefit from an integrated tools approach to software development. The lone ranger typically does not have the time to learn a new tool. Small software groups have their favorite products and do not welcome new environments being forced upon them. Finally, multi-site teams have too much infrastructure investment in place to be able to slot in a new environment for every project based on the current silicon decision.

Put simply, where including software development in the hardware configuration tool is a nice-to-have feature, feature-rich and reliable support for commercial and other popular software IDEs is just plain essential.

Before going into detail about how software IDEs can be integrated into hardware environments, it is useful to understand a little about PSoC and its design environment. PSoC is a fully programmable embedded system-on-chip integrating configurable analog and digital peripheral functions, memory, and a microcontroller on a single chip.

While the technology is very different, with much more analog content, the design flow is similar to what you would see in today’s FPGA devices, especially those that integrate a hard microprocessor core.The PSoC Creator tool provides an extremely flexible visual embedded design methodology that includes preconfigured, user-defined peripherals, and hierarchical schematic entry.

When a design is built in the tool, many software files are created. The most visible of these are the API files generated for each of the components used and placed in the project. With easily remembered names like Counter_Start() and ADC_SetValue(), these APIs form a consistent, simple-to-use means of controlling the hardware peripherals without having to know all about the implementation details.

All good tools for programmable devices should generate the software interface because “by construction” is the only way to ensure efficient and error-free code. In addition to the APIs are the boot files, which include the code to configure the programmable array. These are files that applications always use but typically do not modify, and are an important part of the IDE export feature.

In addition to this hardware-centric functionality, PSoC Creator includes the usual software features developers have come to expect: source editing, project management, integrated compilers, device programming, and on-chip debugging. This is all very normal fare in a modern tool but the problem with this approach is simple; many people like using PSoC but not all of them want to use the Cypress software tool for application development.

A Sample Design
Let’s start with a simple PSoC design for illustration’s sake. PSoC Creator’s schematic capture and parameterized components make it easy to draw up this peak detector circuit.


Clickon image to enlarge.

Figure 1: Peak Detection Schematic in PSoC Creator

This design uses two main components: a comparator (Comp) and a mixer (Peak_Mixer). The comparator simply compares two input analog voltages and outputs a digital result. The mixer, which is configured in Sample mode, outputs the difference between its reference and input signals and updates that value on every clock cycle. Because the reference voltage is ground (Vssa) in this design, the mixer always outputs its sampled input voltage to another pin (Peak).

The output of the mixer is also fed into the reference input (-) of the comparator. When the voltage on the pin (Sig_In) is low, the comparator output is also low and the clock to the mixer is blocked by the AND gate.

As a result, the mixer does not sample the voltage and continues to output its last-sampled peak voltage. When the pin voltage is higher, the comparator changes output, the clock is no longer gated, and the mixer updates its output with the new peak voltage.

Building this design results in a number of APIs being generated. For our purposes, we just want to turn on the circuit:

1 – Comp_Start()
2 – Peak_Mixer_Start()

To write this code, we need to create the uVision project. This is done from the PSoC Creator Project menu, which offers the “Export to IDE” wizard.


Clickon image to enlarge.

Figure 2: Step One – Choose the Target IDE

After selecting the uVision IDE, we have the option of creating a new uVision application or updating the device settings on an existing application project. This second option is only used when there have been major changes to an existing design (more on this later). Pick a directory, choose names for the workspace and application project then click “Next” again to advance.


Clickon image to enlarge.

Figure 3: Step Two – Choose Project File Names and Location

Next, the dialog asks if you wish to include source code in the application project. Whether you do this depends on your style and how your team works. Sometimes hardware designers write just enough software to test the device configuration.

This code is not production-worthy and the hardware team may want to share it with software professionals. In other cases, the hardware teams develop useful low-level interfaces to the systems they have designed in PSoC Creator and want to export these to the application developers.


Clickon image to enlarge.

Figure 4: Step Three – Export Application Code?

The important decisions are now made and clicking “Next” takes you to a review step, where you can see the actions that will occur during the export process. One more “Next” and the export is completed, with a checklist presented along with a checkbox option to launch uVision.


Clickon image to enlarge.

Figure 5: Steps Four & Five – Review Actions and Launch uVision

Exporting to uVision involves the creation of a number of files: the PSoC design library project, the application project, and a multi-project workspace that allows users to open, and build, both projects in a single invocation of uVision.

The library project contains all the PSoC-specific details, including important API files and initialization code. When the project is built, a “*_PSoCxlib.lib” library file is generated that is linked directly with the application.

The application project is typically something of a shell when it is created (unless you export source files for PSoC Creator).


Clickon image to enlarge.

Figure 6: Viewing the Exported Projects and API Files in uVision

It is dependent upon the library, meaning it links that project’s .lib file, and is the project to which that software developers will add source code, run the debugger and, ultimately, complete the product. It is in this project’s source files that the calls to those two APIs, above, will be made.

Modifying an Existing Design
Imagine now that you wish to extend the design to detect minima on the input signal at the same time as you track peaks. This is a straightforward modification to the PSoC Creator design. Inverting the output of the comparator (i.e. make it high when the input voltage is below the reference) and routing that as the clock input to another mixer, which has a high voltage reference (Vdda) instead of ground, provides a trough-detecting circuit.

With a multiplexer in front of the comparator, the software is able to switch between detecting minimum and maximum voltages with the two mixers. The Start API for the new mixer, and the software to switch channels, needs to be called and this could create a problem if the integration was not sophisticated.

However, building the design automatically re-generates the library project (but not the workspace or application project files) and so, when uVision is launched again, the Trough_Mixer API files are immediately available to the software developer. Even though two separate tools are used to make edits, changes in both the hardware and software can be completed, built, and verified in just a few minutes.


Clickon image to enlarge.

Figure 7: Modified Schematic Showing Simultaneous Peak and Trough Detection

One of the reasons why this approach to software development has not been seriously tried before is the inherent issue with two environments sharing files.

This is not so much a problem of two tools editing the same source file simultaneously – there are many approaches to this issue ranging from simple “sandbox” development to powerful source control systems – but actually managing the ownership of the project file for the software tool.

The uVision tool keeps a lot of information about a project in its uvproj file and does not expect to have another tool modifying it. The challenge becomes how you can reliably make changes to the project in one tool and maintain coherence with the other.

The short answer is that, for uVision, you don’t. Splitting the design into a library and an application means that the software developers can change whatever they like in the application without impacting the PSoC initialization and component API code. Similarly, PSoC Creator can update the hardware design in complete isolation from the application code.

About the only time after the generation of the original project files that PSoC Creator needs to change the application project is if the design team makes a dramatic change, such as switching to a new processor. PSoC Creator supports both the PSoC 3, an 8051-based device, and PSoC 5, which boasts an ARM Cortex-M3. You can switch platforms in a few minutes, just by choosing a new part number and re-building.

The tool switches compilers automatically and targets the new architecture. Understandably, this would create problems with an ARM-based application trying to link with an 8051 PSoC design. To avoid this problem, PSoC Creator watches for such changes when you are working with the IDE and notifies you to update the application project file.

This is achieved from the “Update device settings on an existing uVision application project” option in the usual Export dialog. The path through the dialog is very short; provide the application project file name and the tool updates that file with the new device type, compiler selection, and settings. It retains all your previous source code and so, after re-exporting, your project is ready to be migrated to the new device architecture.

Clearly, the integration of PSoC Creator with uVision is only a first step. There are several other high-quality IDEs available to software developers these days, and the strategy of enabling designers to use the tools of their choice hinges upon support for them all.

Stay tuned for announcements about new IDE support throughout 2012 and, perhaps more tellingly, look out for similar approaches from other programmable platform vendors. If you believe, like we do, that one tool cannot fit everyone’s needs, then surely the time is right for truly integrated approaches to software development on today’s sophisticated devices.

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.

Leave a Reply

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