I’m experiencing a strange issue with a DFRobot DFR0972 I2C DAC module on my Arduino Mega 2560. I’m trying to control the DAC output while also using a Waveshare LCD1602 display, SSD1306 display and Rotary encoder (ADA5880).
Here’s the problem:
When I place the code to set the DAC output before the LCD initialization in my setup() function, the DAC works perfectly. I can see the output change as expected (measured with a multimeter).
However, if I move the DAC output code after the LCD initialization, the DAC output remains fixed at its initial value and doesn’t respond to any subsequent changes. The codes operation shows in the serial display that the DAC decimal values is changing via the code but no physical changes are happening on the DAC itself.
I suspect there might be an I2C bus conflict or timing issue between the DAC and LCD libraries. Here are the steps I’ve taken so far:
Simplified Code: I’ve removed all unnecessary libraries and code to isolate the problem. The DAC operates fine with no other I2C devices programmed. 2C Scanner: I’ve used an I2C scanner to verify the DAC’s address. I have no duplicating address. Checked Power: Verified that the DAC and LCD have adequate power.
My Questions:
Has anyone else encountered similar I2C conflicts when using the DFRobot DFR0972 DAC with other I2C devices?
Are there any known timing issues or initialization conflicts between the Waveshare LCD1602 library and the GP8302 DAC library?
Are there any specific I2C bus settings or configurations that I should check?
Any suggestions for further troubleshooting or debugging steps?
Could the library order have any effect on this issue?
Hardware Details:
Arduino Mega 2560
DFRobot GP8302 I2C DAC Module (DFR0972)
Waveshare LCD1602
ADA5880 I2C Stemma QT Rotary Encoder
CE09493 I2C OLED Display (SSD1306)
Any help or insights would be greatly appreciated. Thank you!
Hey @Scott284998
Welcome to the forums. Good to have you with us.
Total bizarre problem.
I can tell you I had a lot of trouble with an LCD1602 (not dfrobot, some generic thing from Jaycar) around inits.
So I had something like …
lcd.begin(cols, rows);
// *** <--- program would never reach this line
char[] poem = Serial.readBytes(12) // read 12 characters off serial ready for display
… and for some reason the serialized data I was writing would just hang out on the bus. It was never read by the program which would never progress.
The solution was that I had to set the cursor before I did anything else.
lcd.begin(cols, rows);
lcd.setCursor(15,0); //apparently locating the cursor is critical!
// *** <--- made it! yay!
// blah blah blah programmy programmy
Maybe you have something similar?
Would you mind sharing the simple code so we can help you debug
P.S. Scott this is a quality post my dude. Knowing how to ask a question on the internet is a skill.
Hi Scott
I too had no end of trouble with a Waveshare 1602 (complete with RGB backlight). Could not get past “Waveshare” on the demo screen. As soon as I tried to print numbers or anything outside string quote marks (" ") only got gibberish.
Into the too hard basket.
Resurrected recently for a play and followed a suggestion to use a DFRobot library. Seems to be working but still experimenting.
This seems to be not too bad on its own. I am not sharing I2C with anything else.
I mention this as I had a look at a few things including the Waveshare library. This thing uses several I2C addresses for different tasks I think rom memory some are to do with the RGB backlight. I would be very surprised if you are not having some sort of conflicts here. I have not had time to go into this too deeply but I think this device might respond to more than one address. Something funny going on anyway.
Since the initial problem I have tended to back away from anything Waveshare but I stress that is only my mentality, for what that is worth.
Cheers Bob
PS Have you tries another 1602. I have had success with a generic 1602 plus that little backpack device to handle I2C that is sold by Core.
Subject: Re: DFRobot GP8302 DAC Failing to Update After LCD Initialization (I2C Conflict?) - Thank You & Update
Thank you all so much for your helpful responses, I really appreciate your time.
Sorry its been a while I’m still working through it.
To further investigate the DAC problem, I’ve developed a simplified test sketch. I’ve discovered that the DAC operates as expected when all LCD code is removed, indicating a possible conflict between the LCD library and the DAC I2C devices.
The code below uses a counter to simulate a 0-100% range and scales the DAC output to 4-20mA (this might be helpful for someone else wanting to test an I2C DAC, the IDE library’s didn’t have anything like this). I’ve added comments to the code highlighting the specific lines that, when enabled, prevent the DAC from changing its mA output. Notably, the serial monitor shows no changes in the calculated values when the lines are enabled, but the actual mA output (measured with a multimeter) remains static. I’m hoping someone can identify any potential errors i may have done in the code, I’ll also be testing Liam’s suggestion of using separate I2C buses.
