PDA

View Full Version : PropBASIC - DS1307RTC



Rsadeika
05-24-2010, 05:42 AM
I guess the first question is, has anybody done this using PropBASIC? I just downloaded the data sheet for the Maxim chip, and reading the info. So far it looks like the PropBASIC I2C commands can be used to read the address, but the interesting part is getting the info that is stored there, and converting it to a readable form. I did not see any appropriate PropBASIC commands, that I recognized for doing this.

I am open to all suggestions as to the best approach for doing this.

Thanks

Ray

JonnyMac
05-24-2010, 05:55 AM
There are no specific PropBASIC commands for that or any other RTC; you'll have to read/set the registers with I2C commands. There are plenty of PBASIC and SX/B demos for that chip, so it shouldn't be a big exercise to create a working program.


[ Edit ] I found an SX/B program for the DS1307 -- it should give you some clues. Note, though, that one of the functions was written in Assembly. Here's the PropBASIC/PASM translation:




' Use: value = BCD2DEC bcd
' -- converts BCD byte to decimal



FUNC BCD2DEC

ASM
mov __temp1, __param1 ' copy
and __temp1, #$F0 ' isolate 10s digit
shr __temp1, #(4 - 1) ' dec 1s x2
mov __temp2, __temp1 ' copy
shl __temp2, #2 ' x2 x 4 = x8
add __temp1, __temp2 ' x2 + x8 = x10
and __param1, #$0F ' isolate 1s digit
add __param1, __temp1 ' add 10s
ENDASM
RETURN __param1

ENDFUNC



I ran this in a test program to confirm that it works.

[ Edit ] A forum friend pointed out a redundant line in the routine -- it's gone now.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Post Edited (JonnyMac) : 5/24/2010 1:05:52 AM GMT

Rsadeika
05-24-2010, 07:32 PM
I found the DS1307_v2008.SXB program, and I thought I would try to convert that to PropBASIC. Having said that, I just ran into the first problem. There is a line of code 'PUT time, $00, $30, $15, Sat, $16, Feb, $08, 0', and I believe that the 'PUT' is an SX/B command only. I did not find an equivalent for PropBASIC, or at least I did not recognize one. Hopefully the I2C commands work the same way as in SX/B. I just glanced through the code, and it looks like 'PUT' might be the only command that is not supported in PropBASIC.

Ray

JonnyMac
05-24-2010, 09:52 PM
WRBYTE is the analog of PUT. To use WRBYTE you'll need to declare your RTC array (of bytes) in the HUB. If you don't want to do that then you can create a loop that moves the parameters to cog variables -- maybe something like this:



SUB SET_CLOCK

rtcHrs = __param1
rtcMins = __param2
rtcSecs = __param3

ENDSUB


You get the idea.

The key in migrating from one language to another -- even when they're similar -- is to learn to think in the new language. That way you're converting process instead of keywords (which don't always have direct translations, anyway).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Post Edited (JonnyMac) : 5/24/2010 1:57:16 PM GMT

Helen C
05-24-2010, 10:23 PM
Hi Ray,

Have a look at the following thread:
http://forums.parallax.com/forums/default.aspx?f=25&m=438391

I had the same question but about the PCF8593 RTC. I finally managed to work out the required I2C code and posted the code.

Good luck!
Helen

JonnyMac
05-25-2010, 12:05 AM
I found a DS1307 and crystal in my parts box so I soldered them together (you can't plug those crystals into a breadboard -- too much stray capacitance) and whipped up the attached demo -- a WORK IN PROGRESS. It sets the clock to 6:00AM and reads it back, updating the display when the seconds register changes.

I suggest that you use this [WIP] approach when porting programs, instead of trying to do them in one big chunk. While encapsulating I2C routines in SUBs and FUNCs I came across a compiler bug with I2CWRITE (has been reported to Bean). This demo doesn't do any error checking via the ack/nak bit with I2CWRITE so I've disabled that option for the moment and the program runs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Post Edited (JonnyMac) : 5/24/2010 5:39:36 PM GMT

Rsadeika
05-25-2010, 02:46 AM
Thanks Helen C, and JonnyMac for your program examples. JonnyMac, in your program you have three lines of code to set the time:
WR_DS1307 RTC_SEC, 0
WR_DS1307 RTC_MIN, 0
WR_DS1307 RTC_HR, 6
On the screen I get a constant 0e for the hours, and a number that changes every second that starts with a 6 which is supposed to be the minutes display, the seconds stays at 0 all the time. Does this reflect a problem with the FUNC BCD2DEC? I did not see where else it would be writing the 8 bit register on the 1307 chip.

Ray

JonnyMac
05-25-2010, 03:24 AM
Why did you change the demo? It works perfectly as is -- and BCD2DEC (which also works) is not used, so that you're questing that is a little odd. What this reflects is a problem with you not wanting to suck it up and study code provide for you! http://forums.parallax.com/images/smilies/tongue.gif

Do you...
-- have the DS1307 hooked up correctly?
-- have pull-ups on SDA and SCL?
-- have the XI and XO pins (1 & 2) plugged into a breadboard? (see image above)

Honestly, I'm getting very close to keeping my PropBASIC code to myself; every time I hand a working demo to you, you say it's broken.

I just downloaded re-ran the original code; see attached.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Post Edited (JonnyMac) : 5/24/2010 7:30:39 PM GMT

Rsadeika
05-25-2010, 03:31 AM
Sorry JonnyMac, I will not be bothering you anymore.

Ray

Rsadeika
05-25-2010, 07:34 PM
Of course JonnyMac's programs work, all of the time, without exception. Next time I will have to be a lot more careful as to how I word my posts.

The lesson I learned yesterday is that you have to be very careful with the circuits that you are working with. I am using a Propeller Platform (PP) board, and in this case a Futurlec DS1307 Mini-board. I disabled the 4.7 Ohm resisters on the Mini-board, and I was using pins 28,29 on the PP board, which have 10K resisters on line. The program compiled, and ran fine, but I was getting some unexpected results. My guess is that the on board EEPROM, on the PP board, and the DS1307 chip have the same address, the data was being clobbered. When I moved the Mini-board over to pins 27, and 26, enabled the 4.7 Ohm resisters, then I was getting the expected results, from the program.

I am going to have to be a lot more careful when working with the I2C buss, and related boards/parts. I think most assembled boards have a hard wired address, and they cannot be changed very easily, so this can be a challenge in terms of getting them all on the same buss. I think I have the correct understanding of I2C addressing?

Ray

JonnyMac
05-25-2010, 09:52 PM
I2C components use a Slave ID byte which has two parts: the device type in the high nibble and the address (usually %000 through %111) in bits 3, 2, and 1, though the DS1307 doesn't use an address as only one RTC is required per buss (those pins get used for the crystal and battery connections). EEPROMs have a device nibble of %1010 and the DS1307 has a device nibble of %1101 -- this means they can co-exist on the same buss. This is important to me as I'm working on a product design now that has a DS1307 on the Propeller's EEPROM buss.

I moved my DS1307 circuit over to the Propeller PDB so I could use the Propeller's EEPROM pins -- at first it didn't work with either Spin or PropBASIC. Every register read back as $FF. When it didn't work on different pins I concluded that the SDA line as not making a good connection and couldn't pull down the buss. That was the case and now the DS1307 is working on the same buss as the Propeller's EEPROM, and I've tested it in Spin and PropBASIC.

As with my first test, I suspect you're having a connections problem. On the Propeller, the SCL line is pin 28 and the SDA line is pin 29. It's easy to reverse these as the SDA pin on the DS1307 is 5 and the SCL is 6.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Post Edited (JonnyMac) : 5/25/2010 2:04:45 PM GMT

Rsadeika
05-26-2010, 03:16 AM
I just cannot get the Mini-board to work correctly on the PP board pins 29,28 I2C buss. Since the Mini-board works correctly when using pins 27,26 with the on board 4.7K Ohm resisters, I can assume the Mini-board works as advertised. So, what are the differences between the PP board, and the Mini-board, the PP board has the 10K Ohm resisters. Could it be that the 10K Ohm resisters are causing the problem? I am clueless on this, any suggestions will be appreciated.

<edit> After looking at the PP board, I see that there is only one resister, cannot tell if it's on pin 29 or 28. Now I am wondering if both lines have to have a pull-up, in order for this to work correctly as a buss? <edit>


Ray

Post Edited (Rsadeika) : 5/25/2010 7:29:58 PM GMT

JonnyMac
05-26-2010, 04:08 AM
That is a mystery....

As you can see by the attached image, I plugged my DS1307 into the secondary socket of my Propeller Platform. Note that pins 1 - 3 of the DS1307 so not connect to the P/P circuitry (hardwired address for second EEPROM at %001). It works fine.

If you want to have one of those DS1307 modules drop shipped to me, I'll figure it out. http://forums.parallax.com/images/smilies/tongue.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

JonnyMac
05-26-2010, 04:22 AM
The Propeller drives the clock line (in violation of the I2C spec) but this usually doesn't hurt anything; I'm not sure if the PropBASIC I2C commands drive the clock or not. My Spin routines DO NOT drive the clock high, hence I need pull-ups on both lines. It will NOT hurt to have the pull-up, even when the Propeller drives SCL. You could enable both on your board and that should be fine.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Rsadeika
05-26-2010, 04:33 AM
I noticed in the picture that you have two resisters, does that mean that you have both pin 28, and 29 pulled-up? Do you have a PP board with just one resister pull-up? Maybe both lines have to pulled-up in order for this to work correctly. I would like to figure this out, but I may just have to resort to having the Mini-board use pins 27, and 28, plus its on board 4.7K resisters.

Ray

jazzed
05-26-2010, 05:19 AM
Rsadeika said...
I noticed in the picture that you have two resisters, does that mean that you have both pin 28, and 29 pulled-up? Do you have a PP board with just one resister pull-up? Maybe both lines have to pulled-up in order for this to work correctly. I would like to figure this out, but I may just have to resort to having the Mini-board use pins 27, and 28, plus its on board 4.7K resisters.

Ray


FWIW: We had exactly the same problem with the DS1302 Java code on the PPDB until adding proper pull-ups.
Driving I2C SCL for single-master operation is not a problem. Getting multi-master to *work at all* is always a problem:)

--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.

JonnyMac
05-26-2010, 06:30 AM
Rsadeika said...
I noticed in the picture that you have two resisters, does that mean that you have both pin 28, and 29 pulled-up? Do you have a PP board with just one resister pull-up? Maybe both lines have to pulled-up in order for this to work correctly. I would like to figure this out, but I may just have to resort to having the Mini-board use pins 27, and 28, plus its on board 4.7K resisters.

Ray


Yes. I designed the Propeller Platform to have both, knowing that I would use my own I2C routines that don't drive SCL high.

That said, I looked into PropBASIC (PASM output) and the I2C commands -- like the Propeller -- do in fact drive the SCL line high and low. What this means is that you shouldn't need a pull-up on SCL. Since you have them on that board, it would be easy to add in; just connect the jumper.

I don't know if this will prove anything one way or another, but I've attached my Spin DS1307 test; it would be interesting to see if it works differently than PropBASIC on your clock module. You will need pull-ups on both SDA and SCL for my I2C object. Again, you can configure that right on your clock module.

BTW... you are powering your board from 3.3v, right?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Rsadeika
05-26-2010, 06:47 AM
3.3V? I guess that's why the Mini-board does not work any more, does not like 5.0V. I am lucky that the DS1307 is on a socket, now I know I have some DS1307 chips somewhere. I guess I figured out what the problem is. I have to stop before I destroy something else.

Ray

JonnyMac
05-26-2010, 09:42 AM
5v shouldn't hurt your module, but if you're running the Propeller at 3.3v (and you are) you should have them match.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Rsadeika
05-26-2010, 06:46 PM
I tried getting my Mini-board to work, and it is not working. So, now I am at a loss at to what is going on. I also downloaded ver .99, and that did not make the Mini-board work. I used my proto board, and my demo board for the testing, the Mini_board does not work on any of the boards. I guess what ever happened, I will probably never find out.


Below I copied the portion that deals with voltages, according to the chart it supposed work with 5.0V, and 3.0V off of the attached battery. Now, the implication is that if it works off of a 3.0V battery, then it should work from a 3.3V source also.

RECOMMENDED DC OPERATING CONDITIONS
(TA = 0C to +70C, TA = -40C to +85C.) (Notes 1, 2)
PARAMETER SYMBOL CONDITIONS MIN TYP MAX UNITS
Supply Voltage VCC 4.5 5.0 5.5 V
Logic 1 Input VIH 2.2 VCC + 0.3 V
Logic 0 Input VIL -0.3 +0.8 V
VBAT Battery Voltage VBAT 2.0 3 3.5 V

Ray

Rsadeika
05-26-2010, 08:26 PM
I decided to check the voltages of the DS1307 chip, at the Vcc pin, 5.0V, and at the SDA & SCL pins, 3.28V. It seems like it is getting the proper voltages at the pins. I guess I can conclude that the chip is still OK, but it does not want to work with any of the programs. I also tried using different wires for the connections, just to make sure I did not get one that was broken. Anybody have any other ideas as to what should be checked. I am glad I do not make a living doing this stuff, I would have already starved.

Ray

JonnyMac
05-26-2010, 11:11 PM
Take the battery out of the module and re-test; it it's bad it might be affecting the DS1307.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Rsadeika
05-27-2010, 01:13 AM
Thanks JonnyMac, I am calling it quits on this Mini-board. Your program works as advertised, so when I get another DS1307 setup, I know I have something available to test it with. To bad there isn't a shield available with an SD adapter (not uSD), and DS1307 RTC, a shield being the key words. Having it assembled is a plus also, that way you just plug it in, and you are ready to go, hopefully.

Ray