PC Meets Mac- LabVIEW

Restarting this project is timely for me as last summer I got together with a guy called PJ at National Instruments and we chatted about the upcoming release of LabVIEW Embedded Module for ARM Microcontrollers that enables embedded software development using the LabVIEW graphical programming environment on ARM MCUs. If you have a generation 2 Lego Mindstorms robotics kit the programming environment in that is a cut down version of LabVIEW and the microcontroller that controls your robotic creations is ARM-based. (Note to wife: Remember I have a birthday in July)

Over lunch in Austin back in July I told him about the LogStick project and he reckoned it would be a great project to demonstrate how easy it would be to create a real embedded application using LabVIEW. Time passed and suddenly the Embedded Systems Conference 2008 in San Jose was upon us with the imminent launch of the LabVIEW for Embedded Module for ARM Microcontrollers. National Instruments and ARM put together a joint presentation for PJ and me at the conference to present the two different approaches to creating the LogStick and show how easy it was with LabVIEW. And boy was it easy! Despite having not really talked since August about the project and only having my blog to go on, PJ successfully put together a most impressive demo of how the LogStick could be created using LabVIEW in what I reckon was a matter of a few hours.

So I am I going to take PJ’s design and say “The End”? Certainly not! There are a number of pro’s and con’s to both approaches and I like using the software tools I have to explore and drive the nitty-gritty of the MCU rather than have all that done for me. Now if I was trying to ship a product by Christmas that wasn’t so very cost sensitive it would be a different story. However, I think my approach will make the design slightly more efficient and for a cost sensitive device that is all important.

The photo at the top is a mockup of a typical user measuring wind speed with the LogStick I used during the presentation. The LogStick is a mockup not the user.

Getting in a State

The last thing I was looking at before I took my “creative break” was the high level design how the LogStick would operate. The most logical way to represent this for me would seem to be a state machine with the following states:

uploading, logging, dormant, full, configuring

With a quick bit of hacking I put together a state machine function whose main core looks like:

switch (status) {

case uploading:
TRANSITION( dormant )
break;

case logging:
TRANSITION( dormant )
break;

case dormant:
TRANSITION( logging )
break;

case full:
TRANSITION( full )
break;

case configuring:
TRANSITION( dormant )
break;

default:
printf ("Event not caught Error\n");
break;
}

Return to the Stick

Well I’ve been away from this blog and the LogStick project for quite some time, but decided now is a good time restart it. 2007 was nothing if not incredibly busy, but now with my 2007 role at ARM as Über development tools product manager complete I can take a deep breath and start to have fun with development tools in the evenings again. Not that I didn’t have fun last year when I was looking after the “big” development tools during the day. It’s just that managing tools for my day job and using tools on a hobby project was just too much for me, so I went off and did something else in the evenings (what evenings I had, my wife points out).

Starting out with RTX

The one thing I did do before I took my creative break was start getting to grips with the RTX real-time kernel that is supplied royalty-free as part of the RealView Microcontroller Development Kit. From what I can see, it has pretty much all of the standard resources and features you would expect to find in a modern day real-time kernel. I started out playing with some of the examples and then quite unlike my normal hackish behavior, I started to write an RTX-based application from scratch.

My simple 4-task application built just fine, but when I ran it I discovered that it sat in the SWI handler forever. I took the source of one of the RTX examples and pasted that into my project, and found that that, too, got stuck in the SWI handler. "Curiouser and curiouser," I thought. I now had exactly the same configuration and the example code in my project and yet it didn't work. Conclusion: Something was not the same. So I "diffed" every file in the example directory against every file in my applications directory and there in the example startup code were the following lines...

; IMPORT SWI_Handler

Undef_Handler B Undef_Handler
;SWI_Handler B SWI_Handler ; Handled by RTL

My application did not comment out the SWI handler code. I checked the documentation and the Knowledge Base and could find nothing on this requirement. I finally decided to check in with Reinhard Keil and found that this was indeed a weakness in the documentation. Reinhard quickly put together a Knowledge Base article here that explains what to do.

Now my example works just fine, so it's on to the next phase of the project.

Hacky New Year

I took a bit of a creative break over the holidays in order to regroup, look at this project with a fresh pairs of eyes and think about the spec. I didn't stop completely; my mind was working away quietly in the background worrying about the one-button interface and whether one button was one going make it simple or make it unusable. I guess it depends on if you are a Mac or a PC kind of guy.

The idea of "Press button to start logging" and "Press button to stop logging" seemed simple enough, but upon consideration this makes it too easy for kids to mess up. It would be pretty easy to accidentally press the button when taking the LogStick to and from the field and start/stop it logging. I could go for double clicking but that seemed less intuitive and kids don't always double click the way adults do. So I came up with the idea of the length of time you press the button being significant. A long press could start logging and a short press could pause rather than halt logging. A long press can't be accidental and a short press will only pause logging rather than starting all over again.

Santa was good to me and I got a great book in my stocking.

This has some very interesting projects that I think would easily become LogStick applications.

A/Ding at last

In my travels around the net looking for information regarding the A/D converter, I came across several examples. I have now distilled them into one simple example of software-driven A/D conversion, which can be found here. The program initializes channel 1 on AD Converter 0 for software-driven A/D with 10 bits of accuracy. The function ADC_Read powers on A/D Converter 0 and starts the conversion. When the conversion is "Done," A/D Converter 0 is powered down again (gotta save those batteries).

I have hacked the script that changes the voltage on an input pin to make that pin AD01. You can start the script running using the Analog ON button in the toolbox when you are in the uVision debugger. If you run this example, you can see the value of the Analog Input AD01 changing, and the result of the A/D conversion shows up in the RESULT portion of the A/D Global Status Register. The RESULT also appears as a 10 bit number in the result variable in the debugger watch window. Just for fun, I added the AD01 input and the result variable to the Logic Analyzer and you can see these values change in step. This sort of thing would be useful if there were long delays between reading the A/D, in which case the result graph would become more a series of steps than a straight line, and it would be easy to determine what data was being lost between sampling of the analog input.

Maybe RTFMing was the problem

In my defense, looking again at user.manual.lpc2141.lpc2142.lpc2144.lpc2146.lpc2148.pdf, it isn't really clear that AD0.0 doesn't exist. In the section that describes the Input pins, AD0.0 is not listed, but the accompanying text gives an example of AD0.0 and AD0.1 being used as ADC0 inputs. Also, in the section describing the bits of the A/D Control Register, the section describing bits 7:0 states that setting bit 0 selects Pin AD0.0, and, moreover, the reset state is having bit 0 set! How confusing is that?

I contacted a friend at the company formerly known as Philips, and he confirmed that the AD0.0 and AD0.5 did not exist on the LPC2148, and this was because they had used pins 10 and 11 for the USB interface. The user manual for the 214X family was derived from the 213X family user manual, and it will be updated.

I guess this was a case where the simulator was more correct than the documentation for the real silicon!