Measuring Measure

I spent some time over the past few days measuring Measure. I wanted to see what sort of performance ceiling it had. I found there there are in fact two versions of Measure. The first did the actual measuring using an interrupt service routine. The foreground application code predominantly performed polled serial IO. The second version used the RTX real-time kernel and had a measure task that was called by an interval task. I decided to measure the RTX based version (since it was closest to what I think the LogStick application will look like).

The RealView Microcontroller Development Kit contains a Performance Analyzer which records and displays execution times for functions and program blocks. Bar graphs display the time spent in each part of the application and there is a column showing the percentage time spent function or program block. I ran the RTX based Measure application and opened the performance analyzer. I hoped to see most of the applications time being spent in the idle task (named os_idle_demon). However, what I saw was that 48% of the time was spent in os_idle_demo but another 48% of the time was spent in a module called Startup. Spending time in the startup code seemed odd, and I dug deeper to discover that it contains the interrupt table and what appeared to happening was that 48% of my time was being spent in the scheduler! This made no sense at all so I sent off a quick email to support.us@keil.com asking what I was doing wrong. The answer was "Nothing!" I had actually found a bug in the simulator and within 48 hours the bug was fixed and a knowledge base article has been placed here

Button interrupt example available

The fully working button interrupt example is now available here

Mystery of Measure solved.

Last week I had some time to play around with the Measure example some more while I was staffing the stand at the ARM Developers' Conference.

I didn't see you there. Where were you? :-)

I also had a chat with my esteemed colleague Mr. Keil, who told me that there are a set of options in (funnily enough) the "Options for target" dialog called "Restore Debug Session Settings." These allow you to save breakpoints, watchpoints, memory and the toolbox settings between debug sessions. This means that if you set the toolbox option in that dialog (and it is set by default), you only have to define your buttons once and they are stored along with the rest of your project settings. They also override any attempts to define other buttons, which is why I was seeing what I was seeing.

Mystery solved!

The Magic of Measure

Now the button is working, it's time to move back up the application and take a look at the overall logic.
There's a real-time kernel is included in the RealView Microcontroller Development Kit as a binary object and the kit comes with quite a few examples of using it. I had a look at the Measure Example (a simple data logger) that is in:

\Keil\ARM\RV30\RTL\Kernel\Examples\Measure

From a first pass this comes pretty close to what I want to do. It reads and records an analog input with a time stamp. When run in simulation, you can push a button to generate a varying 0-3 Volt analog input which is duly recorded by the application.

The weird bit for me is that the initialization code doesn't seem to contain anything to define the buttons which stimulate it. The code to generate the 0-3 Volts is there but the code to bind that to a button is not. I wonder where it is?