That program has an awful lot of syntax errors. It was obviously never actully run. I went through and cleaned up the errors, but I don't have a DS1602 so I can't test the functionality.
There is sample code for the DS1307 in the StampWorks manual (which you can download for free). It might be similar enough to the DS1602 to get you going.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
There is also code in industrial controls for the DS1302.(EDIT)
well, now that I went and looked, the DS1302 is a real time clock/calendar while the 1602 has both RTC and elapsed time counter.
in the 1602 one counter tracks real time while on system or battery power while the other counter
tracks elapsed time while under system power and holds count under battery power.
just taking a quick glance at the datasheet, looks like the differences will be minimal, but don't quote me on that ;-)
Thanks for the help. It seems the program works. Now to turn the HEX numbers into DEC do I just change the debug formater? Or is there a different way to make the data human readable?
The DS1302 uses BCD which can be conveniently displayed using the HEX2 modifier.· If you want to convert the BCD value to decimal, you can do it like this with PBASIC:
· myDecVal = myBcdVal.NIB1 * 10 + myBcdVal.NIB0
If you want to send a decimal value to the DS1302 you need to convert it back to BCD -- here's how:
You don't need to do all those steps for the debug statement. You can just do
DEBUG HEX2 hi_count, HEX2 lo_count
It's displaying hex, but since it's actually BCD, it will display as a decimal number. That's because the first digit is in the high nibble and the second digit is in the low nibble. Displaying the byte as hex makes each nibble print as a single digit and since the digits are from 0 to 9, it looks like decimal.
You only need to do the conversion if you'll be performing mathematical operations on the value.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
If you're still running the program I uploaded, all those 1's and 0's are coming from the debug statements in out_byte and get_byte. You want to get rid of those and the "DEBUG 13" line at the end of each subroutine so that you're not looking at bits.
You should also add ", CR" to the end of the "DEBUG HEX2 hi_count, HEX2 lo_count" lines to get your output on separate lines.
Now that I've glanced at the DS1602 datasheet, the only commands I see are reading and writing counters. The description on the datasheet says "The continuous counter can be used to derive time of day, week, month, and year by using a software algorithm." You'll need to find (or write) that algorithm--it's not part of the chip.
Here's another thing I just realized: Jon was talking about the DS1302 using BCD--the DS1602 doesn't use BCD. It's spitting out a 32-bit number that represents a number of counter events.
I don't think the DS1602 is really the chip you want if you're looking for time of day functions. If you just want a chip that tells you what time it is you'll probably be better off with a DS1302 or DS1307.
Also, it's better to attach screenshots as JPG files instead of Word documents.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
Now I have deleted the extra debug statements and now when I run the program I get this in the debug terminal
003C
0000
23A3
0000
Which leads me to belive I don't have the Vcc counter hooked up right but it seems the continuous counter is working. But I still don't know how to turn this into seconds.
Mike15 said...
What I am trying to use the DS1602 for is to stage rocket motors. The booster stage is ignited at launch. Then after a determined amount of time, say ten seconds the next stage is ignited.
In that case, you have exactly the right chip.
I have to get going so I don't have time to spend with the data sheet, but I think the counter simply counts seconds. You might want to clear the counter and then start counting seconds. That way you can ignore the upper 16-bits of the 32-bit value. But that's with just a quick read. Hopefully someone with more experience than I will jump in here and give you some better info.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
Ok. First off, change the HEX2 modifiers in the debug statements to HEX4. The HEX2 was when we thought we were working with BCD. The values you get from the DS1602 are 32-bit, so you want to see 8-digit hex numbers (each digit being four bits). You're right that the Vcc pin doesn't seem to be hooked up correctly because that counter isn't moving. But the continuous counter is working perfectly. The program clears the counters, then waits 60 seconds and displays the counter values. 3C hex is 60 decimal.
The program then sets the continuous counter to $01234567, waits 60 seconds and displays the counter value. Since it's only printing the least significant two digits of each hex value, we're seeing the "23" of "0123" in the high word and "A3" of "45A3" of the low word. Which is exactly what you'd expect. 67 hex is 103 decimal. 103 + 60 = 163 and 163 decimal is A3 hex. So the counter is definitely counting seconds. As long as you don't need better resolution than that, you're fine.
The sample code you got is pretty sloppy. It must have originally been written in a less advanced version of PBASIC. I don't know PBASIC 1.0 syntax because I just started this last week so I came in with PBASIC 2.5. But this code:
clear_counter: ' clears specified counter, $04 - continuous counter
' $02 - V_cc counter
GOSUB begin
IF counter=CONT_CNTR THEN clear_counter_l1
o_byte=$02
GOTO clear_counter_l2
clear_counter_l1:
o_byte=$04
clear_counter_l2:
GOSUB out_byte ' $04 if continuous counter, $02 if V_cc counter
GOSUB ENDD
RETURN
would be a lot clearer like this:
Clear_Counter: ' clears specified counter, $04 - continuous counter
' $02 - V_cc counter
IF counter=CONT_CNTR THEN
o_byte=$04
ELSE
o_byte=$02
ENDIF
GOSUB begin ' Prepare DS1602 to receive a byte
GOSUB out_byte ' Send the byte to the DS1602
GOSUB ENDD ' Take the DS1602 out of receive mode
RETURN
Cleaning up the spacing and avoiding all the unnecessary GOTO statements makes for much more readable code.
Ok, one more:
Write_Counter: ' writes 32 bits contained in hi_count and lo_count
' to specified counter, beginning with least sig bit
IF counter=CONT_CNTR THEN
o_byte=$80
ELSE
o_byte=$40
ENDIF
GOSUB begin ' Prepare DS1602 to receive a byte
GOSUB out_byte ' $80 - continuous counter, $40 - V_cc counter
'now shift out 32 bits beginning with least significant bit
o_byte=lo_count.LOWBYTE ' lo byte of lo word
GOSUB out_byte
o_byte=lo_count.HIGHBYTE ' hi byte of lo word
GOSUB out_byte
o_byte=hi_count.LOWBYTE ' lo byte of hi word
GOSUB out_byte
o_byte=hi_count.HIGHBYTE ' hi byte of hi word
GOSUB out_byte
GOSUB ENDD ' Take the DS1602 out of receive mode
RETURN
I highly recommend reading the section "The Elements of PBASIC Style" in the StampWorks manual.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
The DS1602 doesn't use BCD. The DS1302 & DS1307 use BCD because their values are mainly meant for display. The DS1602 is simply a counter, so its values are plain binary values.
Because you are only using the lower 16 bits of the 32-bit value, you can simply change the debug statement in your main loop to "DEBUG DEC lo_count, CR"
Since the BS2 only deals with 16-bit values, displaying a 32-bit number in decimal isn't so easy. I'm sure there's a way but I haven't done it yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
Comments
There is sample code for the DS1307 in the StampWorks manual (which you can download for free). It might be similar enough to the DS1602 to get you going.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
well, now that I went and looked, the DS1302 is a real time clock/calendar while the 1602 has both RTC and elapsed time counter.
in the 1602 one counter tracks real time while on system or battery power while the other counter
tracks elapsed time while under system power and holds count under battery power.
just taking a quick glance at the datasheet, looks like the differences will be minimal, but don't quote me on that ;-)
Post Edited (Dunnsept) : 4/3/2006 8:08:12 PM GMT
· myDecVal = myBcdVal.NIB1 * 10 + myBcdVal.NIB0
If you want to send a decimal value to the DS1302 you need to convert it back to BCD -- here's how:
· myBcdVal = (myDecVal / 10 << 4) + (myDecVal // 10)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
DEBUG HEX hi_count, HEX lo_count
it should be something like this?
myDecVal =myBcdVal.NIB1 * 10 (being hi_count) + myBcdVal.NIB0 (being lo_count)
DEBUG DEC myDecVal
DEBUG HEX2 hi_count, HEX2 lo_count
It's displaying hex, but since it's actually BCD, it will display as a decimal number. That's because the first digit is in the high nibble and the second digit is in the low nibble. Displaying the byte as hex makes each nibble print as a single digit and since the digits are from 0 to 9, it looks like decimal.
You only need to do the conversion if you'll be performing mathematical operations on the value.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
How do I turn this into time?
You should also add ", CR" to the end of the "DEBUG HEX2 hi_count, HEX2 lo_count" lines to get your output on separate lines.
Now that I've glanced at the DS1602 datasheet, the only commands I see are reading and writing counters. The description on the datasheet says "The continuous counter can be used to derive time of day, week, month, and year by using a software algorithm." You'll need to find (or write) that algorithm--it's not part of the chip.
Here's another thing I just realized: Jon was talking about the DS1302 using BCD--the DS1602 doesn't use BCD. It's spitting out a 32-bit number that represents a number of counter events.
I don't think the DS1602 is really the chip you want if you're looking for time of day functions. If you just want a chip that tells you what time it is you'll probably be better off with a DS1302 or DS1307.
Also, it's better to attach screenshots as JPG files instead of Word documents.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
The booster stage is ignited at launch. Then after a determined amount of time, say ten seconds the next stage is ignited.
I also was thinking of using the RTC to control the recovery system and booster seperation.
Once again thanks for the help.
003C
0000
23A3
0000
Which leads me to belive I don't have the Vcc counter hooked up right but it seems the continuous counter is working. But I still don't know how to turn this into seconds.
I have to get going so I don't have time to spend with the data sheet, but I think the counter simply counts seconds. You might want to clear the counter and then start counting seconds. That way you can ignore the upper 16-bits of the 32-bit value. But that's with just a quick read. Hopefully someone with more experience than I will jump in here and give you some better info.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
The program then sets the continuous counter to $01234567, waits 60 seconds and displays the counter value. Since it's only printing the least significant two digits of each hex value, we're seeing the "23" of "0123" in the high word and "A3" of "45A3" of the low word. Which is exactly what you'd expect. 67 hex is 103 decimal. 103 + 60 = 163 and 163 decimal is A3 hex. So the counter is definitely counting seconds. As long as you don't need better resolution than that, you're fine.
The sample code you got is pretty sloppy. It must have originally been written in a less advanced version of PBASIC. I don't know PBASIC 1.0 syntax because I just started this last week so I came in with PBASIC 2.5. But this code:
clear_counter: ' clears specified counter, $04 - continuous counter ' $02 - V_cc counter GOSUB begin IF counter=CONT_CNTR THEN clear_counter_l1 o_byte=$02 GOTO clear_counter_l2 clear_counter_l1: o_byte=$04 clear_counter_l2: GOSUB out_byte ' $04 if continuous counter, $02 if V_cc counter GOSUB ENDD RETURNwould be a lot clearer like this:
Clear_Counter: ' clears specified counter, $04 - continuous counter ' $02 - V_cc counter IF counter=CONT_CNTR THEN o_byte=$04 ELSE o_byte=$02 ENDIF GOSUB begin ' Prepare DS1602 to receive a byte GOSUB out_byte ' Send the byte to the DS1602 GOSUB ENDD ' Take the DS1602 out of receive mode RETURNCleaning up the spacing and avoiding all the unnecessary GOTO statements makes for much more readable code.
Ok, one more:
Write_Counter: ' writes 32 bits contained in hi_count and lo_count ' to specified counter, beginning with least sig bit IF counter=CONT_CNTR THEN o_byte=$80 ELSE o_byte=$40 ENDIF GOSUB begin ' Prepare DS1602 to receive a byte GOSUB out_byte ' $80 - continuous counter, $40 - V_cc counter 'now shift out 32 bits beginning with least significant bit o_byte=lo_count.LOWBYTE ' lo byte of lo word GOSUB out_byte o_byte=lo_count.HIGHBYTE ' hi byte of lo word GOSUB out_byte o_byte=hi_count.LOWBYTE ' lo byte of hi word GOSUB out_byte o_byte=hi_count.HIGHBYTE ' hi byte of hi word GOSUB out_byte GOSUB ENDD ' Take the DS1602 out of receive mode RETURNI highly recommend reading the section "The Elements of PBASIC Style" in the StampWorks manual.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
In the debug terminal I get 0 to 9 then it goes A to F, is this BCD?
Here is the program I came up with
Because you are only using the lower 16 bits of the 32-bit value, you can simply change the debug statement in your main loop to "DEBUG DEC lo_count, CR"
Since the BS2 only deals with 16-bit values, displaying a 32-bit number in decimal isn't so easy. I'm sure there's a way but I haven't done it yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows