Charlieplexing ( LoL Shield library) and DS3231 RTC (Chronodot) CONFLICT HELP!

Hey All,

As stated, I am using the Charlieplexing library from the LolShield ( slightly modified for only 72 LEDs -- I am NOT using the LoLShield) and a Chronodot DS3231 RTC.

When I call the req'd "LedSign::Init()" in the void.setup(), it seems the sketch crashes.

In the example below, when the LedSign::Init is commented out, The Serial Monitor shows:

init command before the fouling Init
made it command following the fouling (but commented out) Init
get time the proper operations in the loop()
...
... and works properly (it won;t show every second, as there are a number of debugging delay() statements)

When LedSign::Init() is active, all I get in the serial monitor is:

init command before the fouling Init
...
(chirping crickets)
...

I posed this question on the Adafruit website here: Chronodot and LoL Shield conflict HELP! - adafruit industries and I got alot of thought-provoking suggestions, but nothing that yielded any result.

The code below is a test sketch written by Eric Ayars for his DS3231 library - which is cleanly written and from what I know, the most comprehensive library for the Chronodot . (Thanks for his great work) I emailed him, and he replied in about 30 minutes - gotta love that! The issue isn't with his sketch or library.

More below the code...

Here is the test sketch:

/*
DS3231_test.pde
Eric Ayars
4/11

Test/demo of read routines for a DS3231 RTC.

Turn on the serial monitor after loading this to check if things are
working as they should.

*/

#include <DS3231.h>
#include <Wire.h>
#include <Charliplexing.h>

DS3231 Clock;
bool Century=false;
bool h12;
bool PM;
byte ADay, AHour, AMinute, ASecond, ABits;
bool ADy, A12h, Apm;

byte year, month, date, DoW, hour, minute, second;

void setup() {
	
	// Start the serial interface
	Serial.begin(9600);

delay(1000);

    Serial.println(" init ");            //  <-- This prints, ++
delay(1000);

 //  LedSign::Init();                   //  <-- when this is enabled

delay(1000);
    Serial.println("made it");      //  <-- this doesn't print ++
delay(1000);                             //  <-- Nothing after the LedSign command executes

// Start the I2C interface
	Wire.begin();

}

void loop() {
	// send what's going on to the serial monitor.
	// Start with the year



	Serial.print("get time"); delay(1000);
	Serial.print('\n');
	delay(1000);

	// Display the time once more as a test of the getTime() function
	Clock.getTime(year, month, date, DoW, hour, minute, second);
	Serial.print(year, DEC);
	Serial.print(month, DEC);
	Serial.print(date, DEC);
	Serial.print(DoW, DEC);
	Serial.print(hour, DEC);
	Serial.print(minute, DEC);
	Serial.println(second, DEC);
}

The 2 libraries are to be found:

Chronodot -- http://physics.csuchico.edu/~eayars/code/DS3231.zip
Charlieplexing -- Google Code Archive - Long-term storage for Google Code Project Hosting.

Along the debugging process, I have:

-Cut out most of the above sketch's contents (dozens of read & print statements) - looking for memory issues
-Rolled back my otherwise functional changes in the Charlieplexing Library back to 126 LEDs - no luck.
-Used Charlieplexing Example code, and insterted Chronodot support - caused a similar crash - but I am going to dig deeper in that direction now, as I have been focused on the LedSign::Init() crashing the above sketch.
-Tried this on my Arduino Duemilanove and my Pro-Mini 328/5V/16Mhz each with a different Chronodot (testing Board and the breakout board at the same time I guess)

Yes, I know there are plenty of workarounds - everything from manipulating the pins within my sketch dumping the library to moving into PWM LED controllers (which is a good idea)

I would think that someone else has tried to combine the LoL Shield & Chronodot as they seem like a pretty natural fit.

Thanks in advance :wink:

I'm surprised...

I figured that someone else had encountered -and possibly even solved - this issue.

I also thought that someone would chime in with the painfully obvious, ie: Are you sure you connecting all those wires to an Arduino, and not an old VGA video card for your first PC?

I have been combing through the .h & .cpp looking for something in that occurs when the Init occurs.
No Luck.

C',mon peeps, I'm really stuck here...

Still no replies? I'm surprised...

c'mon peeps. SOMEONE has got to be able to see what is wrong here.

This might be at least part of the problem. In Charliplexing.cpp:

#define MEASURE_ISR_TIME
#ifdef MEASURE_ISR_TIME
uint8_t statusPIN = 19;
#endif

The Chronodot is an I2C device which will therefore use ANALOG pins 4 and 5 for the I2C communication. These are also known as DIGITAL pins 18 and 19 and the above code allows the Charliplexing stuff to use analog pin 5.
Try commenting out the define and see if it makes any difference:

//#define MEASURE_ISR_TIME

Pete

I will investigate that immediately...

Thanks for the tip and the scrutiny on the code!

Still no luck...

I commented out the DEFINE, no luck, and then the 3 references to MEASURE_ISR_TIME, and again no luck.

Still just freezes in the same spot.

Let's see if it is a problem with ram.
Add this function to your code:

int freeRam () {
  extern unsigned int __heap_start, *__brkval; 
  int v; 
  return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval); 
}

And then put

Serial.print(F("freeRam = "));
Serial.println(freeRam());

immediately after Serial.begin() in setup()

Run the code with the call to LedSign::Init() commented out and then run it again with it in and see what values are printed for freeRam.
You might also try putting LedSign::Init() after the Wire.begin() to see if that makes any difference.

Pete

It isn't ram space. I downloaded and installed the two libraries, messed with them to get them to compile with V1.0.1, and then ran your test which fails as expected.
I fiddled with the charlieplexing library until I found that it is failing when it calls SetBrightness(). This requires that Timer2 cause an interrupt before the function can proceed and so it appears that Timer2 isn't interrupting.
It also crashes even if the Wire.begin() is removed so it isn't a conflict with the DS3231 library which as far as I can tell doesn't use anything other than the I2C Wire library.
If I have time I'll try to dig deeper into this but I'm not familiar with the bit-banging of hardware registers that is used in the charlieplexing library.

Pete

Yeah, I am baffled.

I haven't had any issues running the Charlieplexing code, until that wire.begin gets put in.

I have had luck without the Charlieplexing library and the DS3231, directly manipulating the output pins with the usual

 {
    pinMode( pins[0], OUTPUT );
    digitalWrite( pins[0], HIGH );
    pinMode( pins[1], OUTPUT );
    digitalWrite( pins[1], LOW );
  }

where pins[x] calls an array.

I don't get any brightness control, and I do get minor random flickers, which is why I want to use the Charliplexing library, it (normally) works like a charm, in my limited experience.

bumping...

Still can't get these 2 bits to play nice.

PLEASE HELP!

el_supremo? Crossroads? ANYONE???

Line 328 of the Charlieplexing.cpp file...

Someone nicely added:

    Serial.end();

Remove this line and all is well. Actually the code was running happily on, its just that Serial communications were turned off and so none of the other Serial.print()'s sent anything.

(Here's a quick debugging tip. I found that by slowly moving a pair of Serial.print("hi"); Serial.print("bye"); statements through the Charlieplexing.cpp with the bye working up from the end, and hi down from the start. That way, you can work out where the bye starts printing and you have found where the issue lies.)

Serial.end() ?!?

wow... I never would have even thought to look for that.

Gonna check it out right now.