Networking & Communications
Making things talk to each other.
Making things talk to each other.
Design, build, and connect wired or wireless node(s) with network or bus addresses.
Send a message between two projects.
This week, I designed yet another new board.
Based around the ESP32 microcontroller which has a self-contained antenna, this one is capable of supporting wifi and bluetooth connectivity.
I'm hoping this will be useful for my final project, since I want to be able to transmit data from my smart eggs back to a user dashboard.
Because (A) I'm not 100% certain of all my final components yet and (B) I think this will be useful for future projects and future HTMAA students, I chose to take a devkit approach to my initial ESP32 board. That meant configuring a board that would probvide access to as many pins as possible for tinkering and prototyping purposes.
After week #8's adventure with (re)designing a SAMD21 devkit based on Quentin's example, I'm pleased to say I was able to tackle this one with much less help!
This week, we connected two ESP32 boards to make them communicate. This was directly relevant to Treyden's final project, where he hoped to use multiple boards networked together.
DECIPHERING THE DATASHEET - AKA: CHALK TALKS WITH QUENTIN:
TA Quentin helped explain some of the ESP32's components after I struggled with new terminology on its data sheet.
We have dubbed his helpful little lessons "chalk talks," and I think they should become a core part of HTMAA. They're full of great stuff, and he's an excellent explainer (even if it can get a little overwhelming in the wee hours of the morning when you're suddenly learning more--or at least in more depth--than you bargained for).
Here's what I learned this time:
I learned that the ESP32 has 5mb of memory compared to 256kb for the SAMD21-18 chips—a significant difference.
The datasheet also told me that six pins, IO6-IO11, were entirely off limits (a good thing to know, since I was planning to connect all of the pins to headers). These are internally connected for external flash and PSRAM.
I Last but not least, there are four additional pins that are input only (they can't be used for output at all): IO34, IO35, IO36, IO39.
I would have to design around all of these constraints.
SCHEMATIC DESIGN:
The first step to actuaally designing was, as always, to choose my necessary components in Eagle.
I went through a few iterations for my design direction, adding (and swapping) parts along the way. For example, I initially added an LED in sequence to indicate whether the board was receiving power, and then went back and added an additional LED connected to a GPIO pin as well. A programmable LED would allow me to run a simple blink program, which would help me debug later on by isolating whether any issues were due to my board or the code.
Note that some classmates (like Treyden and Selin) chose to incorporate a SAMD11 into their ESP32 designs, which allowed them to also add a USB header directly to their boards. I opted for the standard FTDI header instead, meaning I'd need an adapter in order to connect my board to my computer. It did save space, but I think I would take the SAMD11+USB approach if I chose to redesign this devkit in the future. It does just make things a bit easier.
In any case, here's the parts list I ended up with:
With my parts in place, it was time to connect components.
My goal was to assign each pin on the microcontroller to its own header. This would allow me to use jumper cables to connect to any of them, thus maximizing the board's utility as a devkit.
Remembering that IO6 - IO11 were off limits, I started using nets—which look like long lines—to connect everything else.
Note: I did have to mirror and rotate two of my five female headers, just like in my SAMD21 design, in order to get the pads to alternate nicely when I stacked two perfectly side-by-side (meaning I effectively ended up with two faux 1x10 pin headers and one standard 1x5 pin header from my five original 1x5 headers).
Somewhere during this process, TA Quentin took a look and suggested that flags/names/labels might be easier. This is an approach where you draw a tiny, short net to nowhere branching off from each component. You then assign it a name which appears in text (or on a flag) right beside it. By assigning two or more nets the same name, you can magically connect them in the background.
I tried this out by using flags to label the six pins that were off limits per the data sheet, giving each one a different name so they wouldn't automatically connect to each other per the name-the-same-to-connect mechanism.
However, I otherwise stubbornly clung to my tried-and-true nets method, maintaining that solid lines that extended all the way between different components made it easier to visually trace connections. (Spoiler alert: I changed my mind later in the process.)
LAYING TRACES:
Once I got everything netted, I navigated over to the board design to begin routing my traces. As always, everything started off as a tangled mess.
As has become habit at this point, I began by positioning things in a way (I hoped) made sense. Then, I started to route traces.
At some point, I realized that untangling things would be easier if I shifted my pin-to-header connections slightly.
Here's a before-and-after shot from the schematic:
Sadly, even after making this switch, I was still struggling. I really needed to shift everything one position counterclockwise. (I'd previously had both my power and ground headers side-by-side, and wanted to break them apart.)
This was the moment where I realized that using the naming convention would have come in handy... Instead of deleting and redrawing 20+ full nets, I could just rename their connection points.
So, I set out to shift things and assign names/flags after all.
Thankfully, this made life much easier and I was finally able to get my traces nicely laid out.
I even ended up needing only one 0-ohm resistor as a bridge, which I was pretty proud of!
EDITING THE ESP32'S FOOTPRINT IN EAGLE
Around this point, I decided to adjust the footprint for the ESP3 to narrow its pads2. TA Quentin suggested that they might be a little too close together for comfort, and I really didn't want to run into problems milling and/or soldering later on.
Thankfully, this proved to be simpler than I thought:
After editing my foorptint, I added an LED on a programmable pin so I could morer easily test the board's programmability. (I chose which pin purely based on convenience in terms of where I could most easily add one to my existing layout).
l also added "p" and "r" labels to differentiate between "program" and "run" modes for my slider switch—and, at the last minute, my name. (This was my first time adding text to a board! I found that 60pt font or larger worked nicely.)
Then I gave my board an outline (make sure you leave room for the FTDI header pins to hang over the edge!) and exported my PNGs for milling.
Note: the hole in the board was to prevent the copper on the back of the double-sided board from interfering with the antenna signals.
MILLING:
The first attempt didn't go well, since my tape released part way through and I ended up with a mess. Attempt #2 went much more smoothly, but I had swapped colors for the hole for my antenna. Because mods cuts with the kerf in the black and I initially made my hole white, it cut around the outside of the hole. The extra kerf width was enough to sever a key trace, meaning I couldn't use the board at all.
Thankfully, the third time was the charm. The board milled beautifully.
SOLDERING
After using some fine-grain sand paper to get rid of any teeny copper hairs and gently washing my board, it was time to stuff it.
I generally enjoy soldering, but found the ESP32 to be the most challenging compoment I've encountered yet.
The ESP32 has ground pads on its back. This means you'll need to use the heat gun. I tried a few strategies here, but what finally seemed to work wsa flowing a little bit of solder to coat the pads on both the board and microcontroller, adding a tiny bit of solder paste on top of that, and then proceeding as usual.
Note: I could not get this to work at first, because the chip kept moving. I finally abandoned my approach of sticking the ground pads down first, and instead tackled the pins first. Then, after my chip was securely fastened via its pins, I went back and used the heatgun from the back of the board to finish up the ground pads. I was super nervous that this wouldn't work, but it did!
Additionally, instead of just little surface-mount feet, the ESP32 has little grooves up its sides. The solder didn't want to travel up these easily. (For those tackling the ESP32 going forward: I'd suggest putting flux into these grooves before soldering!).
The rest of the board was pretty straightforward, and went much more quickly.
I added the capacitors, resistors, headers, and voltage regulator and was done.
This was, by far, the trickiest step this week.
TA Quentin graciously spent hours debugging with me, and we still couldn't get my board to program from my mac. It worked perfectly frorm his PC, though! (Selin couldn't get her board to work on a mac either, which is interesting since hers is an M1 and mine is an older intel version.)
Regardless, the first step should be to download the appropriate Arduino IDE libraries for the ESP32. Then, if you've taken my approach and used an FTDI header rather than a SAMD-11 + USB incorporated directly onto the board, hook that up.
NOTE: My FTDI header was backwards relative to the pins on the adapter.
To get things to line up appropriately, I had to turn the adpater around backwards. Thankfully, things lined up so that the circuit didn't close the first time around, so I didn't accidentally fry anything before realizing this issue—but I easily could have! DOUBLE CHECK THIS.
Also important for bootloading: Instead of using freedap like we did for the SAMD chips, the ESP family requires something called vcp.
Once you have things bootloaded, you should be able to flash the board! In my case, this worked on Quentin's PC but not on my mac. Boooooo.
I'm grateful I added a programmable LED at the last second, since this gave us an easy way to test flashing the board. (The feeling when it successfully blinked was magical, since I was worried about this one!)
Quentin and I double-checked libraries. We installed, deinstalled, and re-installed python. We tried many different upload speeds, including some we input manually instead of choosing off the pre-populated menu. We also did MUCH googling. Alas: no luck. We kept getting the same "exit status" error, though it switched betweeen exit status 1 and exist status 2. (The former seemed to occur when the board was unplugged and re-connected between attempts, whereas the second arose when we tried multiple flashes without disconnecting between them.)
A few things that stayed constant throughout the process: 1) always reset (press the button) between uploads, and 2) make sure the toggle switch is in "program" mode (as opposed to "run").
This debugging began Saturday night and resumed Sunday afternoon with little progress. We even tried Quentin's hacker lunchbox kit (technically called a dataa analyzer, but same thing). This allowed us to see when data was being communicated between the computer and the board. In the simplest terms: when the computer talks to the board, and when (or if) the board answers back.
We were able to get farther along in the upload process throughout our debugging, but never all the way.
In the end, we used Quentin's computer to flash the board. He set up his wifi hotspot, and I was able to flash the board with a program that allowed it to connect to a website with a specific IP address via that hotspot. Thus, I was able to turn the LED on my board on and off again via a button on that webpage.
Very cool! Now I'll have to figure out how to get it to work on my mac going forward.
created with
Website Builder .