Doctor Micro

Lately, I've primarily focused on the architectural details of the RX microcontroller (MCU) series that provide performance advantages to design teams. Today let's go back and look at the development-tool issue. Renesas has a new RX610 Starter Kit that packs a formidable set of capabilities into a $250 package. The Kit includes a development board, a Renesas E1 emulator, and the Renesas High-performance Embedded Workshop (HEW) Integrated Development Environment (IDE).

The block diagram pasted below best describes the capabilities of the development board. The design includes an LCD module that is supplied as a detachable daughter card. There is a potentiometer provided for use with the integrated analog-to-digital converters (ADCs). You get a variety of switches and LED indicators for use in evaluation of the architecture.

The kit includes a power supply and all of the cables required to connect the development board to a host PC. You get the option of a RS232 serial connection or linking via USB and the E1 emulator.

We should review a couple of the tools included in the Kit such as the emulator. Renesas offers several options of debuggers and an in-circuit emulator for the RX. The E1 is meant as a tool that's sufficiently affordable that every member of a design team can have their own emulator. The E1 has internal trace capabilities for 256 branches or instruction cycles. The emulator alone sells for $150.

The Kit also includes an evaluation version of the HEW and the Flash Development Toolkit that offer full functionality for 60 days. After the evaluation period the tools still function, but you are limited to the size of projects that can be developed.

In an early post I discussed the capabilities of the HEW and how it's used across Renesas' MCU families. The HEW makes it simple to migrate to the RX from other supported MCUs such as the H8 family. Moreover the IDE includes a complete set of tools such as compilers and a debugger. In addition, many third-party tools integrate seamlessly into the HEW.

I'd also be remiss if I didn't remind you once again that Renesas is still offering the RX-Stick Evaluation Platform for free while supplies last. The RX-Stick lacks the robust features found in the Starter Kit but still provides a chance to evaluate the MCU and the HEW. You can register and request and RX-Stick at the Renesas web site.

I've written several times on the subject of interrupt response time and described how the Renesas RX microcontrollers (MCUs) respond to interrupts. It's also important to exit interrupt service routines (ISRs) quickly. A fast exit time allows the MCU to return quickly to the application at hand and also is important when the MCU must service nested interrupts. So today we will take a look at how the fast interrupt feature of the RX and the ability to dedicated registers to an ISR can speed exit times.

The example I'll use here will build on the scenario that I described in a recent post on response to nested interrupts. Renesas application engineers had developed a test in which a timer integrated on the MCU generated an interrupt. Subsequently, a higher-priority external interrupt forces the MCU to exit the timer ISR so that it can service the external interrupt.

The code for the nested interrupt also provided an opportunity to measure the relative advantage of the fast interrupt feature and the use of dedicated registers. I've written previously and described the savings in CPU cycles attributable to the fast-interrupt function and dedicated registers. The fast-interrupt function can be assigned to one high-priority interrupt. It relies on dedicated PC (program counter) and PSW (processor status word) backup registers that eliminate the need to store the RC and PSW to memory. And the dedicated registers eliminate PUSH and POP instructions in the ISR.

The test of how these features speed exit time relied on the use of a scope to measure the time that an I/O signal is in a low state. The timer ISR sets the signal low. And the external interrupt drives the signal back high. The measurement is relative because the timer ISR had to include a delay loop to insure that the external interrupt triggered before the exits from the timer ISR.

First the engineers measured the exit time without the use of the features described above. Next the engineers repeated the test with the timer ISR set to use the fast-interrupt function. The exit required 20.42 nsecs less time with the fast-interrupt function applied to the ISR.

Next the engineers repeated the test with registers R10-R13 dedicated to the timer ISR. That allows the timer ISR to exit without POP operations to restore register values. With both the fast-interrupt function and the dedicated registers applied, the test revealed 80.3 nsecs faster exit time relative to the first test.

Embedded designs often require deterministic and speedy response to interrupts. The RX provides an additional value in lettering design teams cut response times even further for key interrupts.

Let's wrap up our recent discussion of how to get accurate real-time measurements from a thermocouple or other sensor. I first discussed the problem and the fact that the relationship between temperature and voltage is nonlinear with a thermocouple, and described the polynomial that could deliver accurate results. I followed that post with a look at the brute-force approach to reading accurate temperatures with an ADC integrated on a microcontroller (MCU) such as the Renesas RX. A pre-calculated conversion table stored in memory may be a good choice in some applications. But for a minimum memory footprint, and therefore minimum system cost, your design must calculate the polynomial in real-time and a floating-point unit (FPU) can greatly accelerate that task.

You can certainly calculate a polynomial expression with a fixed-point MCU. The programmer must take care in coding the algorithm. First the constants or coefficients for each degree or order of the polynomial must be converted into a format conducive to integer math. Typically a portion of a 32-bit representation is the integer part of the constant and another portion is the fractional component. One such format would use a sign bit, 11 bits to represent the integer, and 20 bits to represent the fraction.

The algorithm would have to calculate each term of the polynomial. And each term would have be precisely shifted before the terms can be added. The integer approach can certainly work in some applications.

Alternatively, a programmer working with a fixed-point MCU could rely on a floating point library. The library handles the complex formatting and shifting operations. But the library approach won't likely yield compact code or optimal performance.

A programmer using a floating point MCU such as the RX has a relatively simple task. In the case of the RX MCU, floating point add instructions execute in four to five clock cycles and multiply instructions can take one cycle less.

Renesas application engineers performed some benchmarks to accurately project both the code size and execution time associated with the different approaches that we've discussed to deriving accurate temperature readings. The tests included both the pre-calculated table stored in memory, and the three approaches that we've discussed here today to calculate the polynomial in real time

The tests were based on evaluating a 5^th order polynomial. And the test were run on an MCU operating at 32 MHz. The table below summarizes the results. The table-look-up approach is the fastest, but has a huge impact on code size. The library approach is clearly a poor choice. Fixed-point math could work in some applications, but the clear winner is using an FPU. The MCU with FPU handles the task in 7 µsecs using only 38 bytes of code.