Week 12 - Input Devices
- hero shot
- design, efab, soldering
- mcu datasheet
- logic analyzer
- data output
hero shot >
- Linked to the group assignment page
- Documented what you learned from interfacing an input device(s) to microcontroller and how the physical property relates to the measured results
- Documented your design and fabrication process or linked to previous examples.
- Explained the programming process/es you used
- Explained problems and how you fixed them
- Included original design files and source code
- Included a ‘hero shot/video’ of your board
goal: interface with an i2s microphone I picked up awhile back for my final project.
- design, efab, solder board for mic
- select/identify mcu for i2s interface
- write code/find example to read from i2s and output to serial
design, efab, soldering >
Design proceeded like usual, previous design example here. I’ve steadily become more comfortable w/ fabbing PCBs, even with the 10mil endmill.
This design centers around this i2s mic. The pitch and clearances enter BGA territory, so to make this work, I need to shrink some of the pads and create larger clearances in the footprint. The footprint came from SnapEDA.
This mic happens to have its port on the bottom, which explains the footprint. I believe the GND pads surrounding the port are broken up to prevent formation of a meniscus, which could block the port. Unfortunately, I couldn’t create enough clearance/route well enough to totally implement the intended vision (4 pads to GND, separated), but the resulting pattern works in spirit.
I’ve recently gotten used to creating through hole pads using the 1/32” end mill setting in mods. I first used this technique in machine week, for interfacing with A4988 H-bridge boards.
I use the technique again here to create a mechanical hole for the port.
From previous experiences, I find it hard to trust the hot air gun when it comes to QFN (Quad Flat No-Lead) or similar parts. I have trouble visually identifying solder fillets on the leadframe.
I’m starting to trust more, in part because I have a CNC for quick PCB fab at my disposal. Previously, I would try to fill out a PCB design as much as possible, which made separating design/fab debug much harder.
I verified functionality after selecting a micro to communicate with the mic, and connecting a cheap Saleae clone logic-analyzer. In retrospect, I’ll start with the logic-analyzer first next time.
mcu datasheet >
I started off attemping to interface the mic with the samd11… when I realized that the samd11 lacked an i2s peripheral.
I then looked into the samd21, but then realized I didn’t have any on hand…
…then, I went to the ESP32!
The esp32 is a versatile IoT-oriented micro controller that has great community support. It succeeded the esp8266, though the esp8266 still finds its way into projects occasionally.
I have a couple of DOIT esp32 devkit v1’s on me. These were sourced from Aliexpress awhile ago. However, I would avoid using these with standard 10-column breadboards, especially if you like accessing all of your pins. This dev board is unfortunately too large, and covers too much of the standard breadboard, making one side of the board inaccessible.
Instead, maybe try the NodeMCU-32S, which has a normal footprint that enables access to both sides of the dev board. Here is one such place to acquire this dev board. The board I have on me has a micro-b usb connector, while the one listed has been updated to use usb-c.
top board: DOIT esp32 devkit v1, which prevents using cables on the left side in this case; bottom board: NodeMCU-32S, which has a "normal"-sized board and enables breaking out pins on either side
I spent a good deal of time parsing the esp32 datasheet and technical references to figure out how to configure i2s on the esp32.
I’ll be honest, it’s been awhile since I’ve worked with the esp32 in any meaningful depth. I’ve been meaning to work it into my final project, but unfortunately the chip I want to use is a lot of work for a 10mil endmill. I need to think harder about distributing workload between endmills.
After awhile, I figured out/remembered the following:
- The esp32 has an i/o matrix, which you can arbitrarily map most internal peripherals to
- Some higher-frequency peripherals have special functional blocks to guarantee performance
- Although the datasheet is great and full of information, the esp32 has mountains of example code, here, here, and here.
arduino i2s example code >
At this point, I still hadn’t verified functionality yet (I didn’t realize I had a logic-analyzer on me, actually). I started with example code in the arduino core for esp32. The best I could find was this example.
Unfortunately, while the code does show how to configure the i2s peripheral (i2s_config), it fails to show how to configure pins for accessing the peripheral. In fact, the example never exposes the i2s to the outside world, and only uses it internally.
That’s fine, I can modify it to work for me, right? Wrong.
arduino-esp32 issues >
I spent some time digging through the structure/function/datatype definitions in this page trying to figure out why the Arduino IDE thought datatypes were wrong, among other things.
After an exercise in futility, I googled an error message.
According to the following github issue, there are a lot of problems with the arduino core for esp32.
After running through the back and forth, I finally bit the bullet and went through the esp-idf install process (it wasn’t that bad, I just don’t like the feeling of rediscovering something I’m having trouble remembering).
esp32 i2s example code >
I spent a bit of time digging through examples again, this time in the esp32 repository
After taking a closer look at this page, I answered a lot of questions that I had while attempting to use the arduino core, and even with some of the official examples.
Not only does it describe how to configure the i2s peripheral, but how to setup pins as well, and the important functions required to do something useful with it. Required functions:
Best of all, everything works! Almost like the official repositories are maintained or something, and the arduino esp32 core is not. Go figure.
setting up a new project w/ esp-idf >
After some configuration, referenced the following:
- this page reminded me that I need to change the .mode variable to more fitting variables for my usecase (a master esp32 reading a slave mic).
- logs are effectively print statements w/ more detail
- delays so the output is more readable
logic analyzer >
After getting my logic analyzer setup, I try sampling the signals at 1Mhz. The resulting packets appear to have inconsistencies (in blue, “received…”)
Reading the datasheet, I see that the clock frequency is at max 4Mhz.
Setting the sampling frequency to 4Mhz seems to do away with the inconsistencies.
data output >
I had some issues figuring out the sampling configuration before I ran out of time. My code currently logs the amplitude value of the mic, but not to a reasonable resolution for analysis.
I will include asciinema if I don’t run out of time.