Prop Dev Board time and temperature
Okay, not the most elaborate project ever, but a fun little way to familiarize myself with my new Propeller Professional Development Board. It's a clock and thermometer, using the DS1302 on the board and a DS1620 plugged into the prototyping area, displaying on a 4x20 LCD. There's lots of code stolen from various OBEX objects and demo programs (some in the original French).
It uses a battery backup to retain time when the power is off. I don't have it set up to trickle charge the battery when it's plugged in, and I don't have a way to set the time and date other than by entering them into the code and loading the code. It does seem to keep time just fine. I haven't measured it to the second, but it was still well within a minute of agreement with other clocks around here after a week of sitting there turned off and working off of the battery.
It makes use of three of the DIP switches as well. One can be set "on" to go to the part of the code that sets a new time and date, or left off to work with the current time/date. The other two DIP switches turn on and off the degrees F and degrees C displays (both can be on at once, or either one, or both off).
The obvious next step would be to set up a way to set the clock while running the program, perhaps using a pair of pushbuttons to increment/decrement the current settings and a third one to accept the setting. Alternatively, this might be a fun way to get some experience using the mouse. Oh, and currently the updating of the day/date/month/year is only done when turning it on. I should obviously put that inside the loop so it happens in real time.
Edit: Oops -·I see I never deleted the reference to the servo object from the code I was working from. It is, of course, unnecessary.
Post Edited (sylvie369) : 1/17/2009 5:51:54 PM GMT
It uses a battery backup to retain time when the power is off. I don't have it set up to trickle charge the battery when it's plugged in, and I don't have a way to set the time and date other than by entering them into the code and loading the code. It does seem to keep time just fine. I haven't measured it to the second, but it was still well within a minute of agreement with other clocks around here after a week of sitting there turned off and working off of the battery.
It makes use of three of the DIP switches as well. One can be set "on" to go to the part of the code that sets a new time and date, or left off to work with the current time/date. The other two DIP switches turn on and off the degrees F and degrees C displays (both can be on at once, or either one, or both off).
The obvious next step would be to set up a way to set the clock while running the program, perhaps using a pair of pushbuttons to increment/decrement the current settings and a third one to accept the setting. Alternatively, this might be a fun way to get some experience using the mouse. Oh, and currently the updating of the day/date/month/year is only done when turning it on. I should obviously put that inside the loop so it happens in real time.
Edit: Oops -·I see I never deleted the reference to the servo object from the code I was working from. It is, of course, unnecessary.
Post Edited (sylvie369) : 1/17/2009 5:51:54 PM GMT
3072 x 2304 - 2M
Comments
I noticed that you used the servo headers for the LCD, which is a good thing, but what is the extra power wire running over to the breadboard for?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
It powers the DS1620. I looked to see if it'd run from 3.3V, but the datasheets I have simply say that it uses 5V, so that's what I went with. Would it work on 3.3V?
While I'm at it, the schematic for the 1620 that I worked from (in the Applied Sensors text) has a 1K resistor on the data line even when working with 5V. Since I was putting 1K resistors on the other data lines to connect to Prop pins, I added a second one in series there (didn't have any 2K...). I have no idea whether or not that was necessary. It works, anyway.
The DS1620 will operate on a supply ranging from 2.7V to 5.5V
Reference:
http://pdfserv.maxim-ic.com/en/ds/DS1620.pdf
BTW) Those Lithium-Poly batteries are nice to Prototype with aren't they?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 1/17/2009 11:04:49 PM GMT
I'll give it a shot, then.
Edit: Yup, works like a charm.
Oh, yeah. Especially for us rocket guys. I'm running a SD card datalogger off of a battery that weighs about the same as the amount of black powder I'm using for ejection charges. It's so light that I can use masking tape to hold it in place against the G forces.
Post Edited (sylvie369) : 1/18/2009 12:53:50 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Engineering
How about that? Never saw it. Thanks.
It's still probably easier to power the LCD from the servo headers, or at least that's how I'm used to doing it, though that does answer a question I had about how best to run an LCD at 5V at the same time as I run servos using 6V.
I just added the ability to use the pushbuttons to set the time and date·during runtime, and also put the date/month/year updating inside the loop, so it now runs properly as a clock. It's pretty fun to mess with that, and I learned a few things in the process (as you can see elsewhere in the thread). You're right - the PPDB is a really great way to prototype. These little changes would have taken all day if I'd had to wire up the pushbuttons as well.
One thing I noticed: it makes a big difference what kind of delay you use while reading pushbuttons. It was a little tricky (well, 2 minutes worth of playing, anyway) to set them up so that the button push was read as one and only one push. I've noticed that kind of issue on commercial products, where sometimes a button push is not read. I've always assumed that was because of something physically wrong with the button, but now I realize it's probably because the software doesn't debounce the button press properly (which is kind of reassuring, actually).
Anyway, I set up one button to enter the "Set Time and Date" mode, and once in, you cycle through hours, minutes, seconds, year, month, date, day of week, with buttons to increment and decrement each, and a button to accept the current setting and move to the next variable. For month and day of week, the associated names (January..December, Sunday..Saturday) are displayed while making the changes. I also put lower and upper bounds on each variable. Nothing to keep you from making it February 31st, though.
Tonight I'll demonstrate it all to my girlfriend, who will be totally unimpressed.
Post Edited (sylvie369) : 1/18/2009 4:21:54 PM GMT
Why not have it roll over instead of stopping it? That's what most clocks I've seen do.
I had some roll over and some stop. Let's see here... I guess I had them all roll back to 0 (or 1) if they exceeded the upper bound, but stay at 0 (or 1) if you tried to go below the lower bound. I'll play with it some more and see what my preference is, and also make sure I set all the bounds appropriately. It's a very simple change, of course: just adjusting a single number in the code for each variable.
I guess the next educational change to make would be to run the temperature monitor and display off of a separate cog. Right now I'm not using the multiple cogs at all - it's all run in one cog. I suppose it could be one cog to read temp, one to read time and date, and one to display the values. That'd be pretty significant, but then again, my girlfriend would have no idea why I was so excited about something that's completely invisible.
I really oughta buy a BoeBot. She really got into the pan-and-tilt head thing I made.
Post Edited (sylvie369) : 1/18/2009 5:05:45 PM GMT