#circuitpython — Public Fediverse posts on home.social

Akkana Peck @akkana · 2026-04-30 · 16:15 UTC

How to Re-initialize a Stuck #ESP32 (in #CircuitPython) -- something I needed when working on my particulate air quality #sensor but I'm sure I'll need it for many other projects:

https://shallowsky.com/blog/hardware/esp32-reconnect.html

#hardware #maker

#esp32 #circuitpython #sensor #hardware #maker

Whatisgoingon @[email protected] · 2026-04-26 · 12:54 UTC

@tobozo I tried it. What a difference!

Now the RSSI is at around -40 to -42 and there are no send errors, send retries or send timeouts since I added the antenna.

Very cool 😎 as I can keep using these modules after all.

I also figured out how to get them fully running on CircuitPython.

This was my first time soldering after probably more than 20 years ...

#esp32 #esp32s3 #soldering #diy #circuitpython

#soldering #diy #circuitpython #esp32 #esp32s3

Andy Warburton ❌❌❌ @[email protected] · 2026-04-22 · 08:27 UTC

I finally wrapped up my custom mini #cyberdeck build last night. Uses a #waveshare ESP32-S3 touchscreen and a mini "OS" built using #circuitpython I wrote a blog post about the build (including links to download the #3dprint models and code) https://andywarburton.co.uk/post/gr3ml1n-a-compact-handheld-cyberdeck-built-for-chaos

#electronics #diy #maker #esp32 #3dprinting

#electronics #diy #maker #esp32 #3dprinting #cyberdeck

gallaugher @[email protected] · 2026-04-11 · 17:18 UTC

"Ghost Catch", an accessibility game I'm prototyping for the Campus School at Boston College, which allows children with severe motor restrictions to pass an animation back and forth. https://youtu.be/98N8J6Ri4L4 GitHub repo in description. #CircuitPython #MakerSpace #TechForGood #Accessibility #CSed

#circuitpython #makerspace #techforgood #accessibility #csed

gallaugher @[email protected] · 2026-04-09 · 15:00 UTC

Last night was #robot arm class in Physical Computing & the #MakerSpace was electric with #CircuitPython #RaspberryPiPico #3dprinting arms battling to pick up candy! Learn such badassery at YouTube.com/@BuildWithProfG

#robot #makerspace #circuitpython #raspberrypipico #3dprinting

gallaugher @[email protected] · 2026-04-01 · 02:27 UTC

Trouble remembering to take your meds? Build this reminder box with <$20 in parts to light up when it's prescription time. I leave mine by my coffee maker so I never forget it. Updated lesson for classroom build https://youtu.be/imafYENxZ_U #TechForGood #CircuitPython #MakerSpace #AssistiveTech #raspberrypipico

#techforgood #circuitpython #makerspace #assistivetech #raspberrypipico

gallaugher @[email protected] · 2026-03-27 · 14:18 UTC

Such a nice profile of the #AssistiveTech work being done by my Boston College Physical Computing students. https://www.bc.edu/content/bc-web/sites/bc-news/articles/2026/spring/the-class-that-makes-a-difference-.html May be interesting to folks in the #CSed #MakerSpace #RaspberryPi and #CircuitPython communities.

#assistivetech #csed #makerspace #raspberrypi #circuitpython

gallaugher @[email protected] · 2026-03-22 · 13:28 UTC

90 min newbie intro to #CircuitPython #raspberrypipico workshop. Lights, sound, potentiometer, and servo! Slides I use with parts & code for all #csed & #makerspace educators can be found at https://bit.ly/pico-workshop If you want to see a student demo video see: https://bsky.app/profile/gallaugher.bsky.social/post/3mhnmurcaqk2f

#circuitpython #raspberrypipico #csed #makerspace

gallaugher @[email protected] · 2026-03-05 · 19:24 UTC

Diplo on your Pico! Build a polyphonic multi-sound DJ board on a sheet of paper using CircuitPython and a RaspberryPi Pico! https://bit.ly/pico-dj-board a super fun classroom build for the #CSed fam. @adafruit Adalogger Cowbell allows gigabytes of sound from the @raspberrypi Pico #circuitpython #raspberrypi #RaspberryPiPico #dj

#csed #circuitpython #raspberrypi #raspberrypipico #dj

Tod Kurt (todbot) @[email protected] · 2026-03-04 · 02:21 UTC

Happy World 303 Day! I’m celebrating by noodling on my “TBish” code in #CircuitPython #303day #tb303

#circuitpython #303day #tb303

gallaugher @[email protected] · 2026-03-02 · 02:30 UTC

Fun lesson - Build a @raspberrypi.com pico DJ board while learning to use the @adafruit.com $8 Adalogger Cowbell to expand file storage to 32GB, & add a STEMMA-QT port with no wiring! My students built this in the MakerSpace last class & it was a blast! https://youtu.be/yZdR7oGbTX8?si=HQveNpNpnvKJrTJK #CircuitPython #CSEd

#circuitpython #csed

Tod Kurt (todbot) @[email protected] · 2026-02-15 · 20:07 UTC

Finally getting around to playing with my synthiota board and porting my CircuitPython “tbish” TB-303-like synth code. It finally has a UI of sorts! In real time, you can edit steps/mutes/accents/slides & edit 8 synth parameters. It's pretty fun. #tb303 #circuitpython
https://www.youtube.com/watch?v=MjE2wdevc3M

#tb303 #circuitpython

gallaugher @[email protected] · 2026-02-15 · 19:11 UTC

#MakerSpace, #makered, STEMed and #csed folks, here's a super-fun challenge lesson I use in class: Build a Baby Groot who talks when his plant is touched. Uses #Adafruit #CircuitPython a Circuit Playground, a 3D printed planter, laser-cut box, but lots of options abound. https://youtu.be/gEmyZ7ZWMIo

#makerspace #makered #csed #adafruit #circuitpython

cnx-software.com [Unofficial] @[email protected] · 2026-01-26 · 03:08 UTC

ACEBOTT QD023 ESP32-based gesture control glove tracks finger movements with potentiometers

https://web.brid.gy/r/https://www.cnx-software.com/2026/01/26/acebott-qd023-esp32-based-gesture-control-glove-tracks-finger-movements-with-potentiometers/

#espressif #hardware #video #arduino #ble #bluetooth

gallaugher @[email protected] · 2026-01-18 · 15:43 UTC

Some of my @bostoncollege.bsky.social Physical Computing students delivering their #CircuitPython based assistive tech projects to their clients in the BC Campus School. I’m so lucky to work with such wonderful young people. https://www.instagram.com/p/DTljI53jW9h/?img_index=9&igsh=MWFkZ21xdDB2c215Yg== #csed #assistivetech

#circuitpython #csed #assistivetech

gallaugher @[email protected] · 2026-01-12 · 01:24 UTC

New #CircuitPython School lesson introduces key concepts: variable naming conventions, print & input for maker / electronics debugging, & AI code completion in PyCharm w/helpful & incorrect results. Also: Using AI for CircuitPython code explanations w/prompting examples. https://youtu.be/-wIqy7drCN8 #CSed

#circuitpython #csed

gallaugher @[email protected] · 2026-01-06 · 22:25 UTC

Good luck #CSed faculty prepping for next semester. Show me your maker closets! Here's the cart with many (although not all) of the parts I use for PhysicalComputing: Art, Robotics, and Tech for Good - the #CircuitPython course I teach accessible from new-to-code through advanced CS students.

#csed #circuitpython

Adrian McEwen @[email protected] · 2025-12-06 · 12:10 UTC

My plan for the day is to see if I can turn these components into something that makes noise, following @todbot's CircuitPython synthio tutorials

https://github.com/todbot/CircuitPython_Synthio_Tutorial/tree/main?tab=readme-ov-file

#CircuitPython #synthio #ESP32C3 #weeknotes

#circuitpython #synthio #esp32c3 #weeknotes

Kevin's Blog @[email protected] · 2025-11-15 · 18:13 UTC

TD4 4-bit DIY CPU – Part 6

Having now successfully built my own version of the TD4 4-bit CPU in Part 5, I’m now chewing over some of the ways I’d like to try to expand it.

Part 1 – Introduction, Discussion and Analysis
Part 2 – Building and Hardware
Part 3 – Programming and Simple Programs
Part 4 – Some hardware enhancements
Part 5 – My own PCB version
Part 6 – Replacing the ROM with a microcontroller
Part 7 – Creating an Arduino “assembler” for the TD4
Part 8 – Extending the address space to 5-bits and an Arduino ROM PCB

I already have a list of others extended projects at the end of Part 4, so I might be drawing on some of them for inspiration moving forward. Many of these are very similar projects, but with a completely different architecture. But really at this stage rather than build a different, more capable, 4-bit CPU from someone else’s design, I’m interested in seeing how far the TD4 design can go. So, ultimately, like all my projects, the fun here is in the reinventing and learning on the way.

One of the questions I have is can I replace the DIP switches with something that can provide the data in a better way? This would be particularly critical if I expand the address space in the future. A ROM is the obvious option, but something more dynamic might be an interesting experiment too.

This post looks at options for replacing the DIP switches with microcontrollers.

Now I feel like I really ought to state right up front that this is a pretty ludicrous thing to do.

At the more charitable end of the endeavor I’m using a 16MHz 8-bit AVR microcontroller with 2kB of RAM to serve up 16 8-bit values to a 10Hz 4-bit CPU.

At the most extreme end I’m using a 125MHz, dual-core, 32-bit ARM Cortex M0+ CPU with 264 kB of RAM running an entire interpreted programming environment requiring (probably) millions of lines of low-level code to implement it, to do the same thing.

So why bother? Well – why not?

TD4 without the ROM

To interface to a microcontroller, I’m after two things:

Ability to read the 4 address lines.
Ability to drive the 8 data lines.

The best place to get at these signals is on the interface to the ROM itself – the 74HC540 octal line driver, and 74HC154 4-to-8 line decoder.

Conveniently, these signals can be broken out quite easily on my board as shown below.

The pink shaded area shows which components are needed for a ROM-less build. The two yellow highlights show where headers should be soldered to permit access to the address lines (top) and data lines (bottom).

In this build, the following components are omitted from the full board:

74HC154
74HC540
16x 8-way DIP switches
128x small signal diodes
8x 10k pull-up resistors

I’ve used 6-way and 10-way pin header sockets to allow me to patch in a microcontroller. This allows for each header to conveniently include 5V and GND too. I’ve included the USB socket for power to the PCB but expect I’ll probably power the board via these 5V and GND links from the microcontroller.

Using Arduino

The natural choice here is to use one of the older Arduino boards, as these are all 5V IO which makes interfacing with the 4-bit CPU fairly straight forward.

Using Arduino direct PORTIO should also make it pretty trivial to read address lines and write the data. I’ve configured the connections as follows:

TD4 SignalArduino GPIOArduino PORTIOA0A0PORTC:0A1A1PORTC:1A2A2PORTC:2A3A3PORTC:3D0D8PORTB:0D1D9PORTB:1D2D10PORTB:2D3D11PORTB:3D4D4PORTD:4D5D5PORTD:5D6D6PORTD:6D7D7PORTD:7

I’m avoiding D0/D1 (PORTD[0:1]) and D13 as they all have other hardware attached (serial port and LED in this case).

Accessing the data corresponding to any specific address is as simple as follows:

uint8_t ROM[16];

loop:
    unt8_t addr = PINC & 0x0F
    PORTB = (PORTD & ~(0x0F)) | (ROM[addr] & 0x0F);
    PORTD = (PORTD & ~(0xF0)) | (ROM[addr] & 0xF0);

The code could be simplified if I didn’t mind trashing whatever is configured for the other GPIO pins via the PORTIO, but it is good practice to preserve those values when only writing to a subset of the IO ports.

In the final code below, I’ve included a toggle for A5 which allows me to do some timing measurements too.

uint8_t ROM[16] = {
    0xB1, 0x01, 0xB2, 0x51,
    0xB4, 0x01, 0xB8, 0x51,
    0xB4, 0x01, 0xB2, 0x51,
    0xF0, 0x00, 0x00, 0x00
};

void setup() {
  DDRB |= 0x0F;
  DDRD |= 0xF0;
  DDRC |= 0x20;
}

int toggle;
void loop() {
  if (toggle == 0) {
    toggle = 1;
    PORTC |= 0x20;
  } else {
    toggle = 0;
    PORTC &= ~(0x20);
  }

  uint8_t addr = PINC & 0x0F;
  PORTB = (PORTD & ~(0x0F)) | (ROM[addr] & 0x0F);
  PORTD = (PORTD & ~(0xF0)) | (ROM[addr] & 0xF0);
}

Running the code in a loop like this gives a scan frequency of around 500kHz and a response time of something like 2-3 uS for each read. That seems pretty responsive and I’m sure will be fine for a 10Hz CPU. And it is – it works great!

Using Circuitpython

One thing that would be really nice is a workflow that allows more of a “direct save to the CPU” approach to programming it. One option is to use a more modern microcontroller that supports a filesystem.

The obvious choice here is a 32-bit microcontroller that supports Circuitpython. But will IO in Circuitpython be fast enough to respond to the CPU? There is one obvious way to find out – give it a try.

There is another complication too – most Circuitpython boards run at 3.3V not 5V so that needs to be addressed too.

Level Shifting

I’m going to use a 74LVC245. The Adafruit product page puts it best:

“essentially: connect VCC to your logic level you want to convert to (say 3.3V), Ground connects to Ground. Wire OE (output enable) to ground to enable the device and DIR (direction) to VCC. Then digital logic on the A pins up to 5V will appear on the B pins shifted down to the VCC logic.”

This is an 8-way bi-directional bus transceiver and should be powered by 3V3, then the direction pin will determine the direction of the conversion as shown[ below.

Two devices will be required. The address lines will need a 5V to 3V3 conversion; the data lines will need 3V3 o 5V.

Here is how I’ve wired these up for a Raspberry Pi Pico:

The Pico is connected as follows:

INPUT: GPIO 10-13 = A0-A3
OUTPUT: GPIO 2-9 = D7-D0 (not the ordering!)

CircuitPython ROM

The basic algorithm will be as follows:

ROM = [16 command byte values]

LOOP:
  Read four address lines
  Set data lines from ROM[address]

For performance reasons it would be best to optimise both the reading of the address lines and the writing of the data lines, ideally into a single access. But as this is for a CPU that runs at a maximum of 10Hz, so for now, I’m just going with simple and see how it goes.

import board
import digitalio

ROM = [
    0xB1, 0x01, 0xB2, 0x51,
    0xB4, 0x01, 0xB8, 0x51,
    0xB4, 0x01, 0xB2, 0x51,
    0xF0, 0x00, 0x00, 0x00
    ]

Tpin = digitalio.DigitalInOut(board.GP21)
Tpin.direction = digitalio.Direction.OUTPUT

A0pin = digitalio.DigitalInOut(board.GP10)
A1pin = digitalio.DigitalInOut(board.GP11)
A2pin = digitalio.DigitalInOut(board.GP12)
A3pin = digitalio.DigitalInOut(board.GP13)

D0pin = digitalio.DigitalInOut(board.GP2)
D0pin.direction = digitalio.Direction.OUTPUT
D1pin = digitalio.DigitalInOut(board.GP3)
D1pin.direction = digitalio.Direction.OUTPUT
D2pin = digitalio.DigitalInOut(board.GP4)
D2pin.direction = digitalio.Direction.OUTPUT
D3pin = digitalio.DigitalInOut(board.GP5)
D3pin.direction = digitalio.Direction.OUTPUT
D4pin = digitalio.DigitalInOut(board.GP6)
D4pin.direction = digitalio.Direction.OUTPUT
D5pin = digitalio.DigitalInOut(board.GP7)
D5pin.direction = digitalio.Direction.OUTPUT
D6pin = digitalio.DigitalInOut(board.GP8)
D6pin.direction = digitalio.Direction.OUTPUT
D7pin = digitalio.DigitalInOut(board.GP9)
D7pin.direction = digitalio.Direction.OUTPUT

def doOutput (data):
    if (data & 0x01):
        D0pin.value = True
    else:
        D0pin.value = False
    
    if (data & 0x02):
        D1pin.value = True
    else:
        D1pin.value = False
    
    if (data & 0x04):
        D2pin.value = True
    else:
        D2pin.value = False
    
    if (data & 0x08):
        D3pin.value = True
    else:
        D3pin.value = False
    
    if (data & 0x10):
        D4pin.value = True
    else:
        D4pin.value = False
    
    if (data & 0x20):
        D5pin.value = True
    else:
        D5pin.value = False

    if (data & 0x40):
        D6pin.value = True
    else:
        D6pin.value = False

    if (data & 0x80):
        D7pin.value = True
    else:
        D7pin.value = False

while True:
    Tpin.value = True
    addr = 0
    if (A0pin.value == True):
        addr = addr + 1
    if (A1pin.value == True):
        addr = addr + 2
    if (A2pin.value == True):
        addr = addr + 4
    if (A3pin.value == True):
        addr = addr + 8

    Tpin.value = False
    doOutput(ROM[addr])

I’ve included a timing pin to GPIO21 so I can see how long it takes to access the IO.

It turns out that it takes something of the order of 50-60uS to read the four address lines and something in the region of 70-80uS to write out the 8 data lines. The above simple Circuitpython code to do this is running with a frequency of around 7kHz.

Now at this point I ought to be reading through the datasheets for the ICs used in the CPU to check response times and timing tolerances so see if this is ok. But I didn’t bother with any of that as it all appears to work!

Conclusion

The Circuitpython is obviously a lot slower than the Arduino running optimised PORTIO code, even though the Circuitpython is running on a 125MHz processor compared to the Arduino’s 16MHz. Of course, if performance was critical then switching to direct GPIO access in C on the Pico would be a lot faster again. Even just having a way to do a single block-access of GPIO would probably make quite a difference.

But for this application, either as they are seem to work absolutely fine.

The ability to quickly edit the ROM contents is pretty useful with the Circuitpython. But I am now wondering how difficult it would be to have some kind of uploader to the Arduino over the serial port. There are only 16 bytes to transfer after all.

In fact it might even be possible to create a simple interactive assembler that allows code to be typed in over the serial port using proper word-based op-codes (like ADD, IN, OUT, etc). At the very least a simple serial port interface to type in numeric values would be relatively straight forward I think. It might also be possible to allow the microcontroller to reset the CPU too.

I’m not sure the added complications of logic shifting, etc, make it worth carrying on with a Pico version at this stage, so I think improving the Arduino is probably the way to go for now.

Kevin

#4bit #arduinoUno #circuitpython #PORTIO #raspberryPiPico #TD4

#4bit #arduinouno #circuitpython #portio #raspberrypipico #td4

gallaugher @[email protected] · 2025-10-30 · 01:15 UTC

Here's a link to today's CircuitPython exam: https://docs.google.com/presentation/d/1BeWUK_b5BKbo_GEi4BZVstnwV_1LJY5QNgVuA7ZbpdE/mobilepresent?slide=id.p
Students had to complete 8 builds in 2.5 hrs. Themes: "Magic-8 Ball Yoda", "Diwali Musical Chairs", An anti-cat distance-activated Turkey, & "Yip Yip Yip" martians from Sesame Street. Solution folder in the open course Google Drive at Gallaugher.com. #csed #maker #circuitpython

#csed #maker #circuitpython

Olimex @[email protected] · 2025-09-22 · 12:52 UTC

New Open Source Hardware board in stock: RP2350-PICO2-BB48 exposes all 48 GPIOs in a breadboard friendly layout https://olimex.wordpress.com/2025/09/22/new-rp2350-pico2-open-source-hardware-development-board-with-all-48-gpios-exposed-in-breadboard-friendly-layout/ #raspberrypi #pico #pico2 #micropython #circuitpython

#raspberrypi #pico #pico2 #micropython #circuitpython

Simple DIY Electronic Music Projects @[email protected] · 2025-07-27 · 18:48 UTC

Pico Touch Board Audio

I wanted to go back to my Pico Touch Board PCB Design and see if there was a way to make it more stand-alone. The original design was to make it a MIDI controller, but that isn’t the only option.

https://makertube.net/w/tADSyrPrUdR1mx7yKRXZTC

Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!

These are the key Arduino tutorials for the main concepts used in this project:

If you are new to microcontrollers, see the Getting Started pages.

Parts list

Pico Touch Board PCB – built
Resistors: 1x 220Ω, 1x 1K
Capacitor: 1x 100nF ceramic, 1x 22uF electrolytic
Breadboard and jumper wires

The Circuit

Most of the GPIO are linked out to the touch pads, but the three analog inputs are still available. They are added on to the header on the right hand side of the board at the top, so we can use one of these as an audio output.

Initially, I thought of connecting it to an 8Ω speaker. If I was using an Arduino then I’d use a 220Ω resistor in series to limit the current to less than 20mA. But as I’m using a Pico, the maximum current has to be a lot less. I seem to recall it is a little complicated, and there are some options, but I have a figure of around 4mA that I tend to work to. It is also running at 3.3V, which means that it would need an in series resistor of 3.3 / 0.004 = 825Ω. This would work, but the speaker will be really quiet!

So I ditched that idea (there is a software reason too, but I’ll talk about that in a moment) and went straight to a PWM output with a low-pass filter to try to give me some vaguely useful as a line-out signal.

I’ve not done the calculations, but instead went a bit “hand-wavy”, combing a 1K and 220Ω resistor to drop the voltage, along with a 100nF capacitor. I’ve also added a 22uF capacitor to remove the DC bias.

That seems to give me something useful, but as you can see from the trace below of a square wave PWM output, there is a lot of room for improvement!

Update

Ok, so going back and doing this semi-properly as per my notes from Arduino PWM Output Filter Circuit, I can see that the 1K and 220Ω resistors can be treated as a 180Ω equivalent (take them as two in parallel) for the filter circuit, which means a cut-off of around 8kHz which ought to be pretty good….

But reducing a 3V3 signal to around 20% leaves for quite a low level of audio – around 660mV peak to peak. It would probably be better to aim for a reduction of around a half.

Using a 1K and 500Ω resistor would be an equivalent resistance of 333Ω, so putting that into a low pass filter calculator gives a cut-off frequency of around 5kHz for a 100nF capacitor.

Weirdly the only thing that really seems to improve things is to raise that capacitor value to 1uF. My calculation would suggest a cut-off frequency of around 480Hz which is pretty small for an audio signal. But it seems to work.

The PWM frequency I was seeing was coming in at around 120kHz so should be plenty high enough to get filtered out. In the Circuitpython code, it is apparently chosen to support the number of bits required at the base clock frequency whilst being inaudible. For the RP2040 running at 125MHz, and with the chosen 10 bit resolution (more here) this is:

125,000,000 / 1024 = 122,070 Hz

A 5kHz (or even 8kHz) cut-off I thought ought to be fine, but Davide Bucci on Mastodon explained for me:

“120kHz is 25 times 4.7kHz, that is about 1.4 decades and with a first-order filter you have a tad less than 30dB of attenuation, that is not a lot. A signal at 3.3V peak to peak at 120kHz becomes about 100 mV on the output after the filter.”

So switching to 1uF, as Davide explains: “if you put 1µF, you are indeed filtering a decade lower, therefore you gain 20dB in the attenuation and the 100mV become 10mV, much less noticeable.”

The alternative is to repeat the 1K+100nF stage and add a second order filter which also seems to work pretty well.

The final circuit that works fine for me at present, will be on of the following.

The first is less components but assumes that the frequencies won’t go much about ~1KHz or so. That is ok for my current setup but would limit the audio range a fair bit.

This is the output of the two-stage filter. It is so much better!

The Code

I wanted to stick with Circuitpython, so my initial thought was to use simpleio.tone() to generate a tone based on a frequency from an IO pin. However, this has the problem that the code is blocking whilst the tone is playing which isn’t very useful.

Instead I went straight to synthio. It turns out that using synthio was actually a lot easier than the “simple” simpleio…

Here is the basic code to generate an ASR-shaped square wave on a PWM audio output on GPIO 28 based on the touch pads as input.

import board
import touchio
import synthio
import audiopwmio
from adafruit_debouncer import Debouncer, Button

audio = audiopwmio.PWMAudioOut(board.GP28)
synth = synthio.Synthesizer(sample_rate=22050)
audio.play(synth)
synth.envelope = synthio.Envelope(attack_time=0.1, release_time=0.6, sustain_level=1.0)

touchpins = [
    board.GP2, board.GP3, board.GP4, board.GP5,
    board.GP6, board.GP7, board.GP8, board.GP9,
    board.GP10, board.GP11, board.GP12, board.GP13,
    board.GP14, board.GP15, board.GP16, board.GP17,
    board.GP18, board.GP19, board.GP20, board.GP21, board.GP22
]

THRESHOLD = 1000
touchpads = []
for pin in touchpins:
    t = touchio.TouchIn(pin)
    t.threshold = t.raw_value + THRESHOLD
    touchpads.append(Button(t, value_when_pressed=True))

while True:
    for i in range (len(touchpads)):
        t = touchpads[i]
        t.update()
        
        if t.rose:
            synth.press(60+i)

        if t.fell:
            synth.release(60+i)

I did experiment with overclocking the Pico to give double the PWM frequency, using

microcontroller.cpu.frequency = 250_000_000

But although this did double the PWM frequency to around 244kHz, it didn’t seem to make much difference for the filtered signal.

Battery Power

One last thing I wanted to explore was if it was possible to power the touchboard with batteries. I left in a number of power options, so for this one I’m using the 5V/GND pin header. I’ve included a couple of capacitors for smoothing, and need to add the 1N5817 diode as shown below.

This requires the following additional components:

1x 1N5817 Schottky diode.
1x 100nF ceramic capacitor.
1x 47uF electrolytic capacitor.
Jumper wires.
3 or 4 battery box.

The 5V/GND header pins connect to the Raspberry Pi Pico’s VSYS pin via the Schottky diode. The 1N5817 has a typical voltage drop of 0.45V, so combined with the Raspberry Pi’s accepted input voltage of 1.8V to 5.5V this means that ideally two or three AA batteries (at 1.5V each) would work. Four 1.2V rechargeables might be an option too.

It might be possible to get away with four 1.5V AAs, but that would give an input voltage of just over 5.5V, so I think that is probably pushing things too far. It might be a good use for some spent AAs though that are no longer reading a full 1.5V…

One of the downsides of battery power is that the touch works best when your fingers are at the same GND potential as the board. It works best if the GND pin of the (unpopulated) barrel jack is touched when using the board.

Closing Thoughts

With hindsight it would have been useful to have included a simple PWM output stage on the original board, but it is relatively straight forward to add one.

It might even be worth me making an add-on board that will connect to the header pins of the power and analog pins containing the simple passive filter components.

What is pretty impressive though, is how easy it is to use synthio with Circuitpython.

Kevin

#circuitpython #pwm #raspberryPiPico #synthio #touch

#circuitpython #pwm #raspberrypipico #synthio #touch

Andy Warburton ❌❌❌ @[email protected] · 2025-07-19 · 19:31 UTC