Code for Using the ADC on the MoBo Stamp
FarmerRichie
Posts: 6
I've got some MoBo stamps and prototyping daughtercards that I've used for·a laboratory process control application with success. In that case I used all the available Stamp I/O·pins, but made no use of the AVR coprocessor capabilities. One day I'll·clean up my notes and hand drawn schematics·and post in the completed projects forum. Now I'd like·to·use one of the·10·bit ADCs in another application to monitor a 0-5V analog DC signal at 10sec intervals for about 24 hours. I've seen a snippet of code in the·GPIO firmware PDF file, so that's a place ot start, but I thought I'd see if anyone had any complete examples of reading and logging data with the MoBo Stamp they would like to share. I also·plan to·use a clock chip to keep track of the time.·Comments and redirections welcome.
This is a great set of forums and·monitoring the posts has helped me a lot with my projects. Thanks to all!
This is a great set of forums and·monitoring the posts has helped me a lot with my projects. Thanks to all!
Comments
1. Will you be using onboard EEPROM, or else an external device to store your values?
2. How do you want to handle:
····a) initialization?
····b) full EEPROM? (Stop reading or circular buffer?)
3. Will you be loading a separate program to read out the values? (Perhaps this program could also reinitialize the EEPROM.)
BTW, if you've uploaded the GPIO3.hex file from Parallax's website to the onboard AVRs, I recommend you download the latest version and use it instead. OTOH, if you haven't messed with it, you don't need to. The version preloaded into the MoBo at the factory is correct, as is the one currently available (since 11 June 2007) on the MoBoStamp product page.
-Phil
In the future, I'll explore storage on an external device later so the data won't be quite so volatile.
2,3 Not really an issue with the present plan, but if I go with using a seperate program to read the data it is a great idea to just reinitialize there.
As far as I know, I am using the preloaded GPIO3. I will check the firmware as my first exercise talking to the AVRs. I don't quite understand the syntax, but should be able to figure it out by trial and error. It looks like all the parameters are sent in hex which is new to me.
The commands and arguments are expressed in hex (e.g. $0B is the command to read a 10-bit value from ADC channel 0) but are actually sent as binary bytes. The hexadecimal notation is handy since the arguments are packed bit-aligned, instead of decimal digit-aligned. For example, to read a 10-bit value from channel one instead, the command is $1B. In decimal, these two commands would be 11 and 27, respectively, which is not nearly so intuitve.
Here's an example subroutine to read a 10-bit value from ADC 0 in daughterboard socket "A", using Vdd as a reference:
owio PIN 10 Busy VAR Bit Result VAR Word ... GOSUB ReadData ... ReadData: OWOUT owio, 0, [noparse][[/noparse]$0B] DO OWIN owio, 4, [noparse][[/noparse]Busy] LOOP WHILE Busy OWIN owio, 0, [noparse][[/noparse]Result.HIGHBYTE, Result.LOWBYTE] RETURN-Phil
The·example code for ADC aquisition works great. I'm only collecting one ADC channel right now, but went ahead and·programmed for all four. In so doing, it became clear to me·that you·talk to each coprocessor using the following sort of pin definition:
OwioA PIN 10···· 'stamp talks to coprocessor A
OwioA PIN 6······ 'stamp talks to coprocessor B
For data aquisition, I decided to use Stamp DAQ (dowloaded from Parralax) and an Exce spreadsheet·so I could get "real time" output to monitor the progress of my experiment. However, I·still needed to do a little process control housekeeping before starting my experiment (prime some pumps, fill a bath, set up a sample) and needed to communicate with the Stamp·via the debug window. A separate program for the housekeeping wouldn't work because many of the MoBoStamp ports are pulled high. When·a stamp resets, my pumps run for a second or to until everything is initialized. My solution was to put·a pause·in the program using DEBUGIN after the pumps were primed and the bath filled. Once I'm·ready to proceed, I press a key and the program continues.·After a short delay, giving me time to close the Debug Window and initiate·data aqusition from Excel. the Stamp DAQ code is executed·and we are off to the races.
All in·all, I've got to say that the MoB0 Stamp is a great·little board. However, I've been scratching my head working with the output pins that are pulled high by·the MoBo circuitry.· For my pumps (on Stamp pins 0,1,2,3) if the pin is low they are off, if high they are on. I had absolutley no luck turning the pumps off by changing the output bits. I·read the manual and sort of understand the input,·output and·direction bits.· I decided I should be able to use the direction bit to sink the current and get the pins to go low (DIRA = $1111). This works,·and I can turn a pump on by setting the corresponding bit to 0 (eg DIRA = $1110 to turn on the pump connected to Pin 0), but I just wondered if there·was a 'better' way?
Richard
OwioB PIN 6 'stamp talks to coprocessor B
Sorry
I'm glad you're enjoying the MoBoStamp!
LOW n can also be used to set pin n to an output and pull it low. HIGH n will do the same, but make it go high. That way you don't have to mess with the direction register.
Now, as a matter of safety, I wonder if you could alter your pump-driving circuitry so the pumps are on when their corresponding BASIC Stamp pins are low. One advantage of having pullups is that the pins take a known state when the Stamp is powered up or reset. If this state corresponded to an "off" situation, there'd be less chance of errant pump operation, danger to an unwary operator, or wear and tear on the pump motors.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 6/22/2007 5:04:27 PM GMT