I just received a DS1307 break-out board from Sparkfun and decided to try it out. So I downloaded Sjunnesson's library from the playground. I hooked everything up and ran the example code. That worked fine.

I then decided to send the output to an LCD instead of the serial port. So I mounted up a 16x2 LCD. To test my hook up, I loaded up the LCD "Hello World" example and ran it. It functioned fine.

... and it functions as one would anticipate (after cycling the power). The word "Time" shows up on the first line of the LCD and the time that updates every second on the second line. What the heck am I missing?

Well I tried it. It didn't work. A bar of blocks was displayed on the first line of the LCD and nothing else. After trying it, I couldn't get anything to display from the real time clock. Even using the code that worked before. The LCD "Hello World" app however still works. Now I'm really confused. The DS1307 example code also still works.

I am suspecting some kind of interference between the libraries as well. The behavior is just too random and unpredictable and I'm too green to find it.

Quote

* (Without having looked at the DS1307 library) Do you need any initialization calls to use the RTC.get() functions? I don't see anything in your setup () function.

There was none in the DS1307 example code.

Quote

* Have you tried, in your loop () function, using Serial.println calls along with lcd.print in order to verify that you are getting good data and converting them to strings properly?

The example code uses serial.Print to send out the data gleaned from the DS1307. I hadn't tried sending it both to the LCD & serial simultaneously.

Quote

* (Again without looking at libraries) Why do you have WProgram.h and Wire.h included in your program? Does DS1307 need them?

I presume that it does because they were in the DS1307 example code.

Quote

* The fact that you say the LCD and RTC tests work independently of each other makes me suspect interference between them.

My thoughts exactly, but where and how?

Quote

* The boolean parameter passed to RTC.get seems to be for a refresh option. Why do you have some true and some false?

Because you don't want to update the data you're reading prior to reading all of it. Imagine reading the time directly at 59 minutes, 59.9999 seconds. You get the proper hour, but suddenly the minute value reads "00" because you've updated and it rolled and you're data is now erroneously an hour old.

How is the RTC chip getting initialized? By that I mean, are you sure that it has valid time data in it and the battery powering it is good?

Are you getting the actual time from your computer and then loading that into the RTC ?

There are some RTC.set() functions in the library that you can use to load values into the clock chip, and there are RTC.start() and RTC.stop() calls to control it. The example I saw did use these.

Your latest test program only attempts to show the seconds; I assume that was just to test?

I don't know how the libraries might interact with each other and I don't know exactly which ones you have downloaded and are using, etc.

If I were trying to debug this, I would reduce it to the simplest case I could formulate, and try to get that working, then add in more stuff.

A simple case might be to push known values into the RTC (stop, set, set, set...) without starting it, and then verify you can get those values back and see them via serial and lcd output. Then put the values in and start the clock (stop, set, set, set... start) and see that you are getting updates. Do this without the sprintf buffer first.

Then once you know you are getting good data, add in the sprintf formatting and continue the verification.

I think you have too many floating unknowns right now and you need to reduce the problem to narrower test cases.

If I had one of those modules, I would happily play with it, as I plan to develop an RTC app soon myself.

Two things to propose: - try outputing a constant integer, instead of the seconds. - try updating the LCD more slowly. put a delay_microsecodns in the loop, delay for half a second and output something.

OK, now you've shuffled some things around and you can repeat the same tests.Does the LCD driver work by itself (as in the previous occasion). If so - does adding the DS1307 driver make things worse?Because now you show the opposite behavior than before - the clock working, and adding the LCD "sends things south".The connections seem OK to me. I would check if the drivers in their initialization parts make some strange assumptions and initialize other ports and pins than the ones they need. Also if some strange and long delays are used.