- Instead of installing BigNums2x2 via the Arduino Library Manager, download BigNums2x2.h and BigNums2x2.cpp locally and place them in your sketch folder alongside your .ino file
- Add the library for your given LCD in the normal fashion, and analyze its source to ensure it conforms with the functions used by Arduino’s LiquidCrystal library
- If any exceptions are found (for example, DFRobot’s customSymbol() vs. createChar()), update the local BigNums source to match the library’s nomenclature
- Once you have conformed the BigNums2x2 code to your library’s interface, everything should “just work” – let us know if not, and we’ll be more than happy to help diagnose!
We recently had an inquiry on our original BigNums2x2 Tutorial about using the library, which is designed for parallel interface Hitachi HD44780-based 16x2 LCDs, with an I2C-equipped LCD. We immediately set to work adding I2C compatibility to our library, with the goal of enabling 16x2 LCDs of all kinds to have big numbers. But then things got complicated – complicated enough that we ultimately decided not to incorporate I2C support into our library. Here’s what we learned – hopefully it will help you implement BigNums with whatever I2C LCD you are using!
With the standard HD44780 display, everything worked great once the pins were updated to match our breadboarded example. The DFRobot I2C module, however, presented further challenges. Unlike using the device’s own library, we had to specify the I2C address ourselves; actually, let’s take a moment to unpack what that means: remember the earlier discussion about i2cscanning? Different I2C devices have different addresses – typically a good thing, since it means you can combine them on a single bus. But what this also means is that LCDs from different manufacturers often have different addresses, so you can’t just have a hard-coded value like the individual libraries that were provided by each OEM (and even those typically require hacking if you cut the trace or bridge the pads that allow you to use their alternate address in order to eliminate a conflict with another device) and expect it to work for all. So either the library needs a way to “know” the address of each commonly-used device, in order to provide a seamless experience for users, or, as is the case with new-liquidcrystal, users are required to specify the address during initialization. But, manufacturers don’t always do a good job of making the address clear – in fact, as mentioned, they typically abstract it in the library so that users don’t have to “worry” about it. And in the case of the DFRobot display there was nothing in their wiki or examples, so we had to go digging. Diving into their library source code (again) suggested it was 0x7c, so we updated the example sketch to use this, and: