I'm having a tough time implementing a DS1307 rtc into an existing arduino project. The rtc sample project that echoes the time to serial console works fine, but that same example code doesn't return anything valid when running in the other project.
The board is a mega 2560, 128x64 lcd using glcd beta3, a few relays are connected, a few buttons are connected using the internal pull-up resistors, that's about it. I've also tried several rtc libraries without luck.
#define pinSpeaker 2 // speaker
#define pinBtnFWD 3 // menu forwards
#define pinBtnBKWD 4 // menu backwards
#define pinBtnSELECT 5 // select
#define pinBtnMENU 6 // menu
#define pinRelayLCD 7 // relay control
#define pinRelayLCD2 8 // relay control
Only one device (this rtc) is connected to SDA/SCL. Project is using wire.h (for rtc), metro.h and eeprom.h. I tried removing metro & eeprom with no change in functionality.
I'm not exactly sure what glcd library code you are running but any beta code is very much out of date.
There are many issues in the beta code, with respect to the mega2560
as the 2560 did not exist when the beta code was released.
2560 support was added in at glcd v3 RC2.
If you have code prior to glcd v3 RC2, my guess is that the issue is that the glcd code you have
does not work on the 2560. When you run code prior to RC2 the code gets confused on the 2560
and silently incorrectly uses the configuration pins for the standard arduino rather than the pins
for the 1280/2560.
This means that not only will it not be able to talk to the
glcd, but it will also start stomping on the incorrect pins which can cause all kinds of strange issues.
Once the latest glcd library is in place, run the glcd diags
to verify that all the wiring is correct and that the glcd library is able to correctly talk to the glcd.
If there are still issues, since the glcd is the more complicated wiring, I'd
disconnect everything but the wiring to the glcd and then run the glcd library diag sketch
to verify the glcd wiring.
Once the glcd is working, then reconnect the other components.
As I mentioned the lcd and glcd work fine, it's the introduction of the rtc and the rtc that is not working once glcd is initialized.
Distribution files created Sat 04/23/2011 15:01:49.03
=====================================================================
BuildNumber 421
=====================================================================
Does there exist a nightly build folder I might try?
j514:
As I mentioned the lcd and glcd work fine, it's the introduction of the rtc and the rtc that is not working once glcd is initialized.
That suggests to me that somehow the GLCD library is corrupting or changing the behaviour of the SDA/SCL pins. Or fiddling with interrupts. But I am not the expert on that library.
No nightly builds. The code is much more stable than that.
You have the latest version that I've released.
While there have been some updates since that release, they are all very minor,
mostly documentation updates and adding the ability to build the library under linux.
The glcd library does not use any interrupts, does not block interrupts
and only uses the pins defined in the pin configuration file.
For a 2560 that will be glcd/config/ks0108_Mega.h
In fact the glcd library does not use any arduino core code. It has it
own very complex set of macros to convert all the Arduino pin numbers to direct port
i/o to boost the speed up.
The Arduino digitalWrite()/digitalRead() functions are too slow for this type of application.
Looking forward,
I have many new features and updates for a 3.1 release that will be pushed out just after an official
3.0 release which I'm trying to defer until just after the Arduino 1.0 release
So far the Arduino guys have dragged their feet for over a year and made a real
mess of things for this 1.0 release.
Can you explain a bit about what is working/not-working?
Are you saying that the diag sketch runs fine?
Including when everything else is hooked up?
And that it is only i2c that fails when the glcd is hooked up and the glcd library
is initialized?
I'm using a relay to control power to the lcd. At power up time, the lcd is off. The relays flip the lcd on, the glcd.init routines are called and everything works as it should. After 10 seconds or so, the sketch turns the screen off. When the user presses a button, the screen turns on and the glcd.init routines are called and everything works fine. After a set time, the display goes back off as it should. All this works really well, saving oodles of power [citation needed] while the screen is off.
I've traced the fault to the line of code where the relay flips the lcd power on. Once this is done, the i2c communications from the rtc goes unstable.
eg:
GetTimeFromRTC(); // this works fine
digitalWrite(pinRelayLCD, HIGH); // flip LCD relay on
digitalWrite(pinRelayLCD2, HIGH); // flip LCD relay on
GetTimeFromRTC(); // this doesn't work properly
I commented out the lcd power management and the rtc works fine.
I guess this is an internal thing? Comments most welcomed.
@bperrybap: The sketch is working fine it's only the rtc not working. Once the relays turn on the lcd the rtc i2c comms go south for the winter. I hear your frustration regarding the 1.0 release but you should know you still have the best thing going
ok, I remember the discussion of the relays over in the v3 thread.
Still seems a bit iffy with respect to the ks0108 because other lines
going to the ks0108 are still driven even when the ks0108 has no power.
So far it appears to be working for you.
Does everything work fine if you simply hardwire the the glcd on and not use
the relays?
What kind of relays are these and how are you powering the relay coils?
Are you using protection diodes on the coils?
Do you know how much current the relays draw?
I ask because relays can do nasty things to digital hardware.
They can draw large currents when initially turned on and by slamming both at the same time
you are not only being hit with the load of the 2 relay coils but the full load of the glcd module
and the very large load of the backlight pretty much all at the same time.
The momentary load may be too high and cause a voltage glitch.
