Stampworks 2.0, Ex #33
Hello.· I've read #33 of Stampworks (Using RTC DS1307).
As I understand it, the program continuously reads time from the chip and displays it.
But what if the Stamp module has other processing it must do (while displaying clock)?
How can the Stamp know that time has changed?· Is polling the only way (i.e. read time frequently and compare vs. previous time)?· This seems wasteful.
Is it possible to be "interrupted"?· Then Stamp would read the new time and display it (be it every second or minute).
If this chip hasn't that capability of "interrupting" (or other means of signaling), is there another chip that anyone has used that has such capability?
Thank you.
·
As I understand it, the program continuously reads time from the chip and displays it.
But what if the Stamp module has other processing it must do (while displaying clock)?
How can the Stamp know that time has changed?· Is polling the only way (i.e. read time frequently and compare vs. previous time)?· This seems wasteful.
Is it possible to be "interrupted"?· Then Stamp would read the new time and display it (be it every second or minute).
If this chip hasn't that capability of "interrupting" (or other means of signaling), is there another chip that anyone has used that has such capability?
Thank you.
·
Comments
Although it may not seem appropriate at first, you might want to consider the words of my favorite poet:
"Nae man can tether time or tide". Robert Burns: Tam O’Shanter
or said differently "Time and tide wait for no man" unknown author. Time goes on whether we want it to or not, and so too the DS-1307 RTC, as an external source of time,·will advance the time appropriuately without any intervention from anyone.
So, when you ask the question "How can the Stamp know that time has changed?", the answer to that is it doesn't need to know, that's the job of the DS-1307, as you can be assured it WILL change. I suspect however that you've asked the wrong question here. I suspect what you meant to ask is "How can I determine·if at least nn period of time has passed, so I can re-fetch the time and update my display or transmit the new time down the line?
The answer to that is the following:
You COULD go through the rather labor and time·intensive process of timing out your entire program exactly, so you would know how long each segemnt takes. Then at every (approximately) nn-1 interval you can fetch the time until it changes to the new value.
If that is more than you care to do, then you can just access it at regular intervals (as the sample program does) to fetch the time, based on the granularity and accuracy that you require. Then you have restricted the number of accesses which seems to be your (unnecessary) concern.
In conclusion, none of the PBASIC Stamps offer true interrupt capability, but the BS-2p? series does offer a polling capability. I offer back to you the following·somewhat rhetorical question -
Even if the PBASIC Stamp did have interrupt capability, when would you expect these interrputs to occur - every nano-second, every microsecond, every millisecond, every "what", and would you expect that you could "set" that interval? The reason why I offer that such a question is rhetorical is based on the following REAL question -
Regardless of that proposed interval isn't THAT INTERVAL going to "waste" more time than the present method, presuming it exceeds (and probably will) the accuracy that you require? Please keep in mind the time it takes to process interrupts which is indeed "wasted time", if a re-fetch of the time doesn't occur.
I'd think about··that above·first, before I went looking in a different direction. Just my thoughts on the subject.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
Here is the situation.· Let's say that I have a display that shows clock in hh:mm (i.e. updates every minute).
I don't want to look at the RTC chip every few msec. to see if time has changed.· I would prefer that the RTC chip tell me when time has changed (hopefully I can choose resolution...minute in this case).
Then, using the polling capability of BS2p, I can write a routine that will "know" that minute has elapsed, then fetch new time and update my display.
As it is now, it appears that I have to fetch time many many times unnecessarily (wasting processing time) before a minute actually elapses.
I hope this is more clear...
Set the Square Wave to 1Hz, count the pulses and when you are up to 60 pulses, get the time from the chip...
This might just complicate the whole thing but I'm not really sure what you are doing...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...
Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...
/Bamse
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen
My $0.02:
If the Stamp isn't doing anything else (i.e. it's already executed all the instructions in the main body of the program) then why not just have it query the RTC chip before reiterating the main loop? If your code isn't very processor intensive and can retire all the instructions in much less than a minute then, yes, you will be querying the RTC many times a second (a "waste") but you aren't "wasting" processing time if you aren't using that processing time for anything else.
One could argue that if there was an interrupt feature then the Stamp would be doing nothing while it waits for the interrupt to come in whereupon it would query the RTC and update the display and then fall back to waiting for the next interrupt. This method would leave the Stamp free to perform other functions but if there isn't anything else to do then isn't this "wasted" processing time too?
If you really don't want to check the RTC more often than once a minute then put a PAUSE statement in the main loop RTC query code (doesn't matter where--before the RTC fetch or after or even before the display update, whatever). You'll have to experimentally determine or WAG (wild *** guess) a PAUSE value that waits for the majority of the minute left-over after the time required to execute the display and RTC fetch code...a PAUSE of probably more than 59.9s. During the the execution of the PAUSE statement, the Stamp will be "busy" so no processor cycles are going to waste because they will be "consumed" executing the PAUSE statement AND you won't query the RTC more than once a minute.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I wouldn't connect that if I were you...
Vive Le Tour!
July 1 - July 23
Post Edited (aalegado) : 7/21/2006 2:52:09 PM GMT
The Stamp still has to poll that signal line to see when the event happens. If you have a BS2p series, you could possibly use the POLLWAIT or POLLRUN commands.
It is slightly easier to poll a single pin than it is to send an I2C command to poll for a change in the minutes register.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
http://forums.parallax.com/showthread.php?p=531080
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com