Shop OBEX P1 Docs P2 Docs Learn Events
PropBASIC - DS1307RTC — Parallax Forums

PropBASIC - DS1307RTC

RsadeikaRsadeika Posts: 3,837
edited 2010-05-26 17:13 in Propeller 1
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

Comments

  • JonnyMacJonnyMac Posts: 9,208
    edited 2010-05-23 21:55
    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.


    [noparse][[/noparse] 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.

    [noparse][[/noparse] 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
  • RsadeikaRsadeika Posts: 3,837
    edited 2010-05-24 11:32
    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
  • JonnyMacJonnyMac Posts: 9,208
    edited 2010-05-24 13:52
    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 CHelen C Posts: 34
    edited 2010-05-24 14:23
    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
  • JonnyMacJonnyMac Posts: 9,208
    edited 2010-05-24 16:05
    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 [noparse][[/noparse]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
  • RsadeikaRsadeika Posts: 3,837
    edited 2010-05-24 18:46
    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
  • JonnyMacJonnyMac Posts: 9,208
    edited 2010-05-24 19:24
    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! 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
    1280 x 800 - 731K
  • RsadeikaRsadeika Posts: 3,837
    edited 2010-05-24 19:31
    Sorry JonnyMac, I will not be bothering you anymore.

    Ray
  • RsadeikaRsadeika Posts: 3,837
    edited 2010-05-25 11:34
    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
  • JonnyMacJonnyMac Posts: 9,208
    edited 2010-05-25 13:52
    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
  • RsadeikaRsadeika Posts: 3,837
    edited 2010-05-25 19:16
    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
  • JonnyMacJonnyMac Posts: 9,208
    edited 2010-05-25 20:08
    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. tongue.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon McPhalen
    Hollywood, CA
    640 x 480 - 459K
  • JonnyMacJonnyMac Posts: 9,208
    edited 2010-05-25 20:22
    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
  • RsadeikaRsadeika Posts: 3,837
    edited 2010-05-25 20:33
    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
  • jazzedjazzed Posts: 11,803
    edited 2010-05-25 21:19
    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[noparse]:)[/noparse]

    --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.
  • JonnyMacJonnyMac Posts: 9,208
    edited 2010-05-25 22:30
    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
  • RsadeikaRsadeika Posts: 3,837
    edited 2010-05-25 22:47
    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
  • JonnyMacJonnyMac Posts: 9,208
    edited 2010-05-26 01:42
    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
  • RsadeikaRsadeika Posts: 3,837
    edited 2010-05-26 10:46
    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 = 0°C to +70°C, TA = -40°C to +85°C.) (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
  • RsadeikaRsadeika Posts: 3,837
    edited 2010-05-26 12:26
    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
  • JonnyMacJonnyMac Posts: 9,208
    edited 2010-05-26 15:11
    Take the battery out of the module and re-test; it it's bad it might be affecting the DS1307.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon McPhalen
    Hollywood, CA
  • RsadeikaRsadeika Posts: 3,837
    edited 2010-05-26 17:13
    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
Sign In or Register to comment.