I am using the code provided by pkournay on his GitHub repository that allows the LCD to work with a Spark Core.
I made a few changes (commented out SYSTEM_MODE(MANUAL); and while (!Serial.available()) SPARK_WLAN_Loop(); parts) and uploaded the Hello World example that was provided, along with the associated .cpp and .h files.
Everything works as advertised but after several minutes, instead of displaying Hello World and accruing numbers under that, it turns into a scrolling, jumbled mess. It also turns the screen from white to yellow.
At this point, I’m not entirely sure what to do or what my next step should be. I have the USB cable connected to a 5v battery charging backpack and running the 5v from those pins into VIN and GND on the Spark Core.
I’m not quite sure how to read the schematics of that display - whether it has 4k7 pull-up resistors on board or requires them, but I’d try adding two 10k pull-ups from D0/D1 to Vin and see if this changes anything.
Maybe @peekay123 could also chime in as he’s the one who ported the library.
I am looking here and it appears there are two 4.7k resistors (it’s been a few years but I was the one who assembled it). I am assuming that they are pull-ups for the I2C connection.
Are you thinking the logic level for the I2C connection is too low for the LCD? That has crossed my mind and I have pulled out a SN74LVC245 logic level converter. However, the datasheet and the product description appears like it isn’t bi-directional and wouldn’t work with I2C. I have a 74AHCT125N quad level shifter handy, too.
I plugged it up and let it run on the drive home from work and it ran for nearly 30 minutes without any corruption or issues. I did, in fact, notice something I didn’t before: occasionally, the numbers on the LCD will lag but when it starts back again, it is a few digits higher, so, the net result is accurate time but there was latency in writing the numbers to the LCD. I feel I worded that in a confusing way. Please let me know if you need me to explain further.
As I am typing this, I’m at the house and I have it plugged in and running. It was good for about 15 minutes but now it is jumbled all over again.
I also wanted to add that if I hold down any of the buttons, the text scrolls to the left at a faster rate and then goes back to its normal rate once I let it go. Could it be a timing issue on SCL?
I’m not sure what is going on. Do I still need to add 10k resistors to the I2C connections on D0 and D1?
EDIT: After it went and jumbled itself up, I left it and came back to find the counter at 3314 seconds (+55 minutes) and it appears to have righted itself. I didn’t restart it after it got scrambled as I wanted to see what would happen if I left it (see if it would restart on its own, lock up completely, or anything other than fix itself). This is interesting.
I did add lcd.clear() to the select button and flashed that before I left work a couple hours back just to see if I could correct the issue that way. It doesn’t fix it, in case you’re wondering.
@eavery and @ScruffR, I believe I have one of these units laying around. The issue may be related to either timing or the MCP23017 GPIO expander. I’ll do some testing and post my results.
No, the pull-ups cater for the high level the Photon only pulls low, that's the pretty thing with I2C, you won't need level shifting. The I2C pins on the Core are 5V tolerant, so you can lose the level shifter.
My confusion with the schematic was that I couldn't decide if the shown pull-ups were ment as present or as ext. components to add. Since the are drawn off an Arduino Uno R3 and these tend to bring their own pull-ups. But if they are there, no need for extras.
The more I think about the issue, the more I think it is a timing issue. What throws me off is that the timing for I2C on the SCL line should be provided by the master (STM32). In that case, the MCP23017 should get it’s timing from that line.
@eavery, when I say timing it was not regarding the I2C clocking but more about the timing between commands. I haven’t had the chance to test yet. Which version of system firmware are you testing with?
@peekay123 Just wanted to touch base with you and let you know that this is no longer an issue. The actual problem isn’t resolved but I don’t need to write to the LCD once every second. Once I trimmed down the writing frequency, I haven’t had it happen the first time.
I think you were right in that it is a timing issue. The offset seems like it will be so small that it wouldn’t be immediately obvious until differential scenarios were run and the emergent nature revealed itself.
For the meantime, I have a stable firmware image.
Thanks for your help! If you happen to come across anything, please let me know. You don’t become good at something by only doing what is easy.
