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!

RTFM Rod!

I further confirmed today that A00 and A05 inputs were missing, by opening the A/D Converter 0 peripheral dialog in the simulator. It was only then that I re-read the user manual for the LPC2148 and discovered that it does indeed not have an A00 input or an A05 input. A/D converter 0 has 6 analog inputs and AD converter 1 has 8. Doh!

Applying some Volts

On first pass, I could not get the script from the RTX Measure example that pokes a voltage onto the analog pins to load into the debugger. The debugger kept moaning that ain0 was not defined. But what was ain0 anyway? It didn't have a definition in the script. ain0 turned out to be a Virtual Target Register (VTREG), which is a register that is part of the simulator. A VTREG is specific to a particular MCU simulation and can be read or written to either by a script or directly from the debugger's command line. So the statement:

ain0 = volts

sets analog input 0 on the MCU to the value of voltage.

I had been using a VTREG when I was poking the pin 2 of PORT0 in the button example. I just hadn't really thought about it.

Typing:

DIR VTREG

gave me a list of all of the virtual target registers in the simulation, and for the LPC2148 I found that the analog inputs had been renamed AD< converter number >< channel number >. The weird thing, though, was that there was no AD00 and no AD05. There were, however, a full compliment of AD10..AD17 inputs for the second A/D converter. Odd?

Going bottom up again

One of the other pieces of low level software that I will have to create will be the A to D code. There was some in the RTX Measure example and I have decided to break that out and take a look at it. Luckily, the A to D registers in the LPC2148 appear to be a super set, so I can pretty much use the code from the LPC213X that is part of the Measure example.