Arduinos, shields, and issues, oh my!

In recent weeks, I’ve become aware of, and interested in, what I’d term “small boards,” electronics experimentation / maker platforms like Raspberry Pi and Arduino. Granted, these things have been out there for years, so you could say I’m a bit slow on the uptake.

Regardless, I’ve been having a certain amount of fun dreaming-up and envisioning projects, primarily on Arduino and Arduino-compatible boards, including a device that notifies me on my iPhone when a particularly important GFCI outlet trips, and another that monitors the water level of my sump pit and uploads data to an online service that graphs that data for me. Fodder for future articles, perhaps, but the subject of this post is a particular headache I’ve had in bringing my latest idea to life.

As I’ve become more steeped in Arduino and microcontroller and maker “stuff,” I’ve become aware of the pieces and parts you can use to assemble interesting projects. It was from that that I came-up with my latest idea: a small connected clock that would display not just the time, but the weather forecast for the next few days by pulling that information via APIs from Weather Underground. The hardware part seemed easy; Arduino board (actually a “RedBoard“), WiFi shield and real-time clock (RTC) from SparkFun, and a color TFT screen from Adafruit; add some C code using the Arduino IDE, and voila: easy, fun, functional project. Except, not really.

The problem arose very early-on in this project; each of the parts I mentioned (the shield, the RTC module, and the TFT screen) all required at least one software library to function. In the case of Adafruit’s TFT screen, it was one library for the screen, one for their graphics library to make it actually do anything, one more if you want to use the touchscreen features, and yet another if you want to read from the display’s built-in microSD card. Oh, and if you want nice-looking fonts? Add one library for each font and font size you want to use.

Anyone familiar with Arduino will now realize what I did not when I started: There’s no way in hell that a regular Uno R3-compatible Arduino board has enough memory to accommodate all that code bloat. And sure enough, I’d barely gotten a test sketch sketched-in (bad pun) before I’d run out of memory without actually having the board do anything. So, now what?

The only real path forward, other than start dropping most of the coolness I’d envisioned from the project entirely (e.g., nice fonts, loading pretty icons from the microSD card, touch features), was to upgrade the board. Thankfully, Arduino offers the Mega2560. It seems, based on reading about it, that most people upgrade to the Mega because it offers a ton more I/O pins. But beyond the pins, it offers a ton more memory, enabling sketches like the one I’ve envisioning to come to life.

The problems started to arise when it came time to try and get the Internet connectivity working. You see, while the Mega provides a mechanical footprint that can support Uno R3-compatible shields, unless your shield is dirt-ass simple, it’s probably not actually going to work with a Mega. The SPI interface pins are not in the same place, and the pins that can support interrupts are not the same. For my SparkFun WiFi shield, that was a particular problem, because for the sake of simplicity, I wanted to use its software serial capability, and while that’s doable on pins 8 and 9 on an Uno R3 board, those pins have no interrupt capabilities on the Mega; you have to move those to pins 10 and 11. SparkFun’s tech support, normally really good, sort of led me astray suggesting that I’d need to deal with the relocated SPI pins too. (I didn’t.)

I spent a lot of hours trying to figure-out how to make all of this actually work together on a Mega, banging my head trying to cull and sort (mis-)information via Googling things, and as I said, from SparkFun support. At the end of the day, I did manage to get it to function. Since there was so little information available on this topic, it seemed an ideal subject for this blog post.

So how do you get the SparkFun WiFi shield to work with an Arduino Mega?

    1. Pin-bending hacks aside, the first requirement was simply to un-stack the shield. Considering that the only benefit from stacking is access to power and the connection of SCL and SDA for I2C (four pins total), and there are so many potential conflicts, there’s no real benefit from stacking.
    2. Un-stacked, there are six required pins total: SCL, SDA, +5V, GND, and the pair of TX/RX pins you want to use, based on whether you’re doing software or hardware serial with the shield. The SCL, SDA, +5V, and GND pins are all connected 1:1 between the shield and the Mega. For software serial (which is what I’m using), connect shield pin 9 to Mega pin 11, and shield pin 8 to Mega pin 10. For hardware, presumably you can connect shield pin 1 to Mega pin 18, and shield pin 0 to Mega pin 19, to utilize the Mega’s UART1 pair. (I didn’t test that configuration.)
    3. You will need to edit the SparkFunESP8266WiFi.h header file to reference the new software serial pins. By default, these are pins 8 and 9, and as outlined above, you need to change those references to pins 10 and 11.

At the end of the day, it wasn’t exactly that difficult — it just wasn’t exactly clear what pins were truly required, it didn’t seem like anyone had come-up with a conclusive way to do this, and to make matters worse, even when I’d stumbled upon the right concept, I had the RX and TX pins reversed so I didn’t even realized at first that I was mostly there. And once that was resolved, and I was able to “talk” directly to the ESP8266 via AT commands, SparkFun’s library didn’t work because I’d failed to change the pin references in the header file. But eventually it did all fall into place.

Finally, I have to say that I’m not terribly impressed with the reliability of the SparkFun WiFi shield. Even before this fiasco, and just playing with it using their RedBoard (Uno R3 compatible Arduino), the shield just seems to “wack out” sometimes. The symptom of that is that the blue status LED on the shield fails to illuminate at all. Multiple power resets and/or sketch uploads seem to kick things into submission eventually. If I had this to do all over again, and had I known I’d need to use the Mega, I would have chosen to implement the connectivity with a cheap ESP8266 board (a few bucks each on eBay, Amazon, etc.), and taken a different path. But I have the shield, it seems to work, and it’ll suit this particular purpose for this particular moment.

So, onward and upward with this project… Look for a post about it at some point when it’s operational.