RP2040 Dev Board--More Encoding, Less Breadboarding

Readers: If you want to build the project featured in today's post, please go to PCBWAY's Community pages--a gerber ready to download and/or fabricate as well as KiCAD files and a BOM are here.  

Also please visit PCBWAY's site--using the link here--it will help this blog immensely. Thanks.

====

Pretty quick one this time. 

I had some back-of-the-napkin ideas for a clock multiplier. Instead of breadboarding I had PCBWAY make some development boards to accommodate an RP2040 MCU ("Raspberry Pi Pico"), an OLED display, a rotary encoder, and some GPIO pins. 

Less to go wrong!

Dev board for this post's project...

The dev board primarily uses 1206 surface mount components. 

My thinking: it was easier to swap SMD resistors and capacitors if I needed to change values compared to through hole. Less work and very little risk of damaging pads and traces.

However, changing and rerouting traces when working with really small parts was not as easy as my older through-hole designs. 

I am still puzzling through the best practices here but I know I didn't want this:

Something about breadboarding, with the dookie-duponts going all over, just drives me-----nuts!!!!! 

No more, please!

The dev board's "features" reused ideas from previous posts:

• Rotary encoder with hardware debounce--post is here. After some experimentation, the values for C and R and .1uF and 100K seemed to work OK.  
• OLED 1306 I2C--post about the 1306 embedded C library I will probably use for the multiplier's  UI is here.
• UART output with buffering for handling printf() statements and serial input data. Got this idea from the fantastic YouTube Channel low level learning.  More information about this in the previous post here.

I wrote embedded C test code, that's on GitHub (here), which "seems working": turning the encoder produced "CW" and "CCW" on the display; clicking its switch cycled the 4 LED's.

The RC + CMOS 4011 based debounce worked most of the time, but not all of the time. This drove my crazy for a few evenings, thinking: where is the mistake?

I simulated a rotary encoder in Logisim (here) which informed me the existing debounce--the digital side anyway--should work.  

I looked over my code many times, no, I thought it right. 

I tend to always blame my own crappy work, bad assumptions, sure I'm right when I'm not, etc, but this time maybe it's something else?  

Perhaps the issue was with the encoder itself? The part says "ALPS" on it, which should be a quality encoder, but I bought 20 in bulk for something like 50c each from China.  

The real deal is more like $2.25US and up per unit.  

So my encoder might be a fakecoder, a counterfeit, which is why its performance, even after hardware debouncing, was not spot on. 

I will buy some name brand encoders from Digikey, not fakes, we will see what happens.

Anyway, I got building:

Happiness is new boards from this blog's sponsor PCBWAY

"Parts is parts"

Rev 2 board will have changes to the silkscreening, they always seem to, but otherwise, this dev board "seems working".  I have uploaded the revised board to PCBWay's community site, here. 

Power test. Good news--the 4011 did not fry.

For serial monitoring I used an "Adafruit FTDI Friend" adapter (here) to a Linux PC.

So what's next?  I have some open source algos I found to get the time between GPIO pulses (for instance: here and here. Beats writing the code from scratch!

Next step I figure: as easy (?) as averaging a few readings of  the incoming frequency, then multiplying that value by 10 let's say.   

Then, use PWM (using the  Pico SDK or maybe the library here) to output the 10x frequency. 

But is it ever that easy?  I am sure there foobars I have not thought of yet.

I am really short on time these days, but if I can find time to code this, as I say after an Olzempic pizza and beer chaser: I will let you know how it comes out.