This specific call to readData(...) in the RealTimeClockDS1307 library seems to break Serial.println(...)
I know because if I comment out the call to readData(...) then the println("In loop()..."); in my loop function outputs the expected text in the serial monitor.
If I uncomment the call to readData(...) then I do not see the expected text in the serial monitor.
Does anyone have an explanation and a fix?
bool CRTC::isDaylightSavings() // I have defined this class and function
{
return RTC.readData(m_nDS1307StartRAMAddr) > 0;
}
byte RealTimeClockDS1307::readData(byte regNo)
{
if(regNo > 0x3F) { return 0xff; }
Wire.beginTransmission(DS1307_I2C_ADDRESS);
Wire.write(regNo);
Wire.endTransmission();
Wire.requestFrom(DS1307_I2C_ADDRESS, 1);
return Wire.read();
}
Well OK but it doesn't seem to have anything to do with my code.
I have gone through all the calls to the RTC object (provided in the DS1307 library) in my code and commented them out one by one until I found the RTC function call that stopped Serial.println working.
#include <Wire.h>
#include <RealTimeClockDS1307.h>
#include "RTC.h"
/*********************************/
/* class CRTC */
/*********************************/
const int CRTC::m_nDS1307StartRAMAddr = 0x08;
CRTC::CRTC()
{
doCheckDayLightSavings(RTC.getDayOfWeek(), RTC.getMonth(), RTC.getHours(), RTC.getMinutes());
}
CRTC::~CRTC()
{
}
bool CRTC::isDaylightSavings()
{
return false;//RTC.readData(m_nDS1307StartRAMAddr) > 0;
}
int CRTC::getDOW()
{
return RTC.getDayOfWeek();
}
int CRTC::getDOM()
{
return RTC.getDate();
}
int CRTC::getMonth()
{
return RTC.getMonth();
}
int CRTC::getYear()
{
return 2000 + RTC.getYear();
}
int CRTC::getHour()
{
return RTC.getHours();
}
int CRTC::getMinutes()
{
return RTC.getMinutes();
}
int CRTC::getSeconds()
{
return RTC.getSeconds();
}
void CRTC::doCheckDayLightSavings(const int nDayOfWeek, const int nMonth, const int nHour, const int nMinute)
{
bool bDayLightSaving = isDaylightSavings();
if (nDayOfWeek == 0)
{
if (!bDayLightSaving && ((nMonth >= 10) || ((nMonth == 10) && (nHour == 2) && (nMinute == 0))))
{
RTC.writeData(m_nDS1307StartRAMAddr, 1);
RTC.setHours(3);
RTC.setClock();
}
else if (bDayLightSaving && ((nMonth >= 4) || ((nMonth == 4) && (nHour == 3) && (nMinute == 0))))
{
RTC.writeData(m_nDS1307StartRAMAddr, 0);
RTC.setHours(2);
RTC.setClock();
}
}
}
CRTC MyRTC;
I take it back....it does have something to do with my code.
I don't really understand it but, if I move the call to doDaylightSavingsCheck(...) to a new functions called Iinit() and then call this functions from the arduino setup() function, then it does not break Serial.println.
Serial.println(); has shown funny behavior for me and I have tried three things.
First, put some characters inside the Serial.println("Text string");
Second, emulate the style sometimes seen in Adfruit logger text.
They seem to shy away from println();
Instead write: Serial.print("\n\nText String");
Third, modularize the code. Specifically, move all the Serial.print and println statements to a single function.
I had some oddball problem appear as I was adding a real time clock and SD card to a one-wire logger program.
I had Serial.print debugging statements all over the place. It was spaghetti city! Moving the Serial.print statements and the OneWire activities to separate functions reduced the unwanted bug to less than once in a thousand temperature readings.
LeeMcK:
Serial.println(); has shown funny behavior for me and I have tried three things.
First, put some characters inside the Serial.println("Text string");
Second, emulate the style sometimes seen in Adfruit logger text.
They seem to shy away from println();
Instead write: Serial.print("\n\nText String");
Third, modularize the code. Specifically, move all the Serial.print and println statements to a single function.
I had some oddball problem appear as I was adding a real time clock and SD card to a one-wire logger program.
I had Serial.print debugging statements all over the place. It was spaghetti city! Moving the Serial.print statements and the OneWire activities to separate functions reduced the unwanted bug to less than once in a thousand temperature readings.
I ended up writing my own string class using a dynamic C string style string that shrinks and grows as you assign and concatenate etc. I.E. Using delete... and new char[...].
I tried the same string operations with CMyString objects and they hung the arduino.
So then I changed my string class to use a static char buffer, I.E. I had a C style string member variable declared as char[100].
Then all the CMyString assignment and concatenation operations worked as expected and Serial.print(...) output the expected text.
So there is something odd going on with dynamic memory allocation with the arduino, and I did find a web page stating that there are unresolved bugs concerning dynamic memory allocation with arduino.
Using Serial.print to output millis and micros, how accurate are my function timing outputs likely to be?
How much of the function execution time is likely to be taken up by calls to Serial.print?
Does anyone have a rough idea at least?