gadgetoid

Well that’s wild because I had a disagreement with beziers recently and did a similar thing! [1] albeit with more madness and less polish. Driven by the a/s/d/f keys with find edges snap to reference images and curve fitting to construction geometry.

Feel I should also call out Freyr’s videos for anyone who has missed them - continuity of splines [2] and the beauty of Bézier curves [3]

[1] https://gadgetoid.github.io/asdf

[2] https://youtu.be/jvPPXbo87ds

[3] https://youtu.be/aVwxzDHniEw

I’m more troubled by the fact these emails are hitting my sendgrid only email address.

Is this related to the breach that SendGrid said didn’t happen? I set my account up in 2021 for reasons I don’t recall and it’s since been deleted/deactivated by them.

A pin planner- without the code gen of STM32Cube- would be doable as a website.

I made a basic one for the RP2350- https://rp2350b.pinout.xyz/

Though STM32Cube has a very different approach, handles lots of mutually exclusive features and peripherals and a bunch of extra stuff for controlling code gen IIRC.

I've thought about this on and off for years, trying to find a way to boil the stuff I've learned making Pinouts into some kind of tool.

There are a surprising number of pitfalls, since there's always some complexity most top-level diagrams don't reveal, but I feel is necessary to capture/avoid duplication of work- specifically, I mean documenting the pinout of the chip (RP2350, ATMEGA32U4, STM32H750, RP2 etc) and then translating that to a board layout.

I think the closest I've come is a prototype Pinout rewrite which started with chip [1] and board [2] JSON files.

Then, as you explore, there's the whole problem of presenting this information. I chose to capture information such as header type, orientation and pin-count but sometimes a header is too small (or there are too many headers) to document in-band so the kinda skeuomorphic presentation of the Pico pinouts doesn't work.

Perhaps that's where something like the minimap [3] from my "advanced" RP2350A pinout comes in.

Having a small representation of the board with the pin headers separate could work. It's been a while, IIRC a Fritzing [4] part involved creating a vector graphic of a part and naming the individual pin objects such that they could be mapped to a table of signals. I think SVG is compatible with this approach but... yeah, requiring people to create detailed board artwork (as good as it looks) is a stretch. The same could work for a good photo and just a table of offsets, as you suggest.

TLDR: This is a great idea and something I've wanted to do for ages. But I don't think I've got enough breadth of experience to do it alone.

1. https://github.com/pinout-xyz/pinout-2024/blob/main/chips/bc... 2. https://github.com/pinout-xyz/pinout-2024/blob/main/boards/r... 3. https://rp2350a.pinout.xyz

Once I get the hand of the ESP’s idiosyncratic signal names (I don’t have much experience with them) I should be able to crank them out. But help would be appreciated, thanks - even a canonical list of the pins and functions would be super useful. I get the sense I’m missing something referencing only their pinout diagram.

Nerd snipe successful.

(very beta website)

https://esp32c5.pinout.xyz

In typical fashion I got nerd-sniped into making an ESP32 C5 DevKit-1 pinout. I've disappeared down a hole of making the perfect SVG for the board art.

Will be an interesting experiment!

Thanks... urge to build a version for ESP32-C5-DevKitC-1 rising...

Agreed. Click-to-select-related-pins is something I've been experimenting with on a cut-down Raspberry Pi Pinout [1]

And code gen is something I'm looking at with the RP2350A pinout [2] where the JSON export would allow someone to plug it into any tool they like. (KiCAD symbol gen, C/MicroPython init code, etc)

It's difficult to strike a balance between features/minimalism but I'm increasingly drawn to the idea of a full (STM32Cube-like if you're familiar with it) configurator for Pico/RP2 based boards.

1. https://pi.pinout.xyz 2. https://rp2350a.pinout.xyz

Agreed. Thanks!

I have definitely struggled with making the Pinout spinoffs discoverable- the OG site had ten plus years to bed in.

I recently started building something like this for the RP2350A chip [1], deeply inspired by both STM32Cube and also by avoiding recreating the horror of STM32Cube.

I’m currently failing to not build STM32Cube for Pico though, the idea keeps gnawing away at me. There are some idiosyncrasies that my micro site doesn’t quite capture. Though perhaps it could.

1. https://news.ycombinator.com/item?id=44520091

PIO kinda sorta does this but yeah the Pico could definitely benefit from a more flexible pin mux, since bringing up PIO peripherals is messy.

Pico never quite has a function where it’s needed.

I did something like this called “picopins” (pip install picopins) which gave a CLI ASCII-like pinout with search.

ASCII-only really cuts to the meat of the problem though.

Thank you. You’re welcome on both counts!

In theory you wouldn’t even need to load firmware- you could just manipulate the relevant registers directly over SWD for the silliest IO expander.

In our case it was the only choice. I’d say we’d use UART now but the RP2350 can pretty much do it all in one chip.

We (Pimoroni) actually shipped this technique in PicoVision, used to load the “GPU” firmware (an RP2040 used to offload the HDMI signal generation) at runtime-

https://github.com/pimoroni/picovision/blob/main/drivers/dv_...

I could believe you feel less latency, but suspect that’s more a symptom of matrix scanning working for the general case rather than being optimised for your layout. Scan with an RP2040’s PIO [1] and after debouncing I’d challenge you to measure the difference, much less notice it.

(Of course if you’ve got the pins, you should use ‘em!)

1. https://github.com/isoxliis/firmware-micropython/blob/72687e...

Well this rang the ol’ memory bells and brought me to Daniel’s Nim drivers for our Pico based products (1). He’s probably the guy to talk to.

Not needing a Python wrapper would definitely help slim down FrameOS into something you could stuff into a fast-loading initrd I guess?

I did something similar with Keybow, static binaries and a custom build system (2) to make a sort-of Pi (Zero) based appliance.

1. https://github.com/daniel-j/nim-pimoroni-pico/tree/master

2. https://github.com/ali1234/rpi-ramdisk

This sounds like it could port well to an RP2040-based display. Though I am forever battling against its very constrained RAM for network stuff (not helped by MicroPython needing a chunk for buffers, an GC bitmap for mark/sweep and some other network mystery meat). That said our (Pimoroni) larger Pico W-based Inky has an 8Mbit PSRAM to act as a back buffer for the display. It’s “slow” but when updates take 30s+ anyway that’s kind of redundant. Very little of that 8Mbit is actually used, so with a little tinkering it might be able to cache multiple images for sequential display without having to faff about with SD cards.

Currently I transmute some images (XKCD and NASA APOD) via a scheduled GitHub action into something fit for the various display sizes. An even more extreme approach would be to convert into the packed (4bpp for 7-colour E-ink) framebuffer format server-side. Less network efficient, but more predictable memory usage.

We’ve had JPEG support for a while, but I brought up a PNG decoder (Larry Bank’s PNGdec) recently(ish) and it’s a much better fit than JPEG for palette-based images. It uses a 32K sliding window, however, which can get spicy if you’re not careful.

Our crude (actually Pillow’s IIRC) dither has a certain nostalgic appeal to it, but can definitely be bested by other algorithms. I’m still not totally convinced we have a great perceptual match for the colours either. The approach to get them - take a photo of the screen, use a colour dropper and a bit of eye balling - was crude.

(Hi, I wrote most of the Inky driver and your project is the kind of awesome I wish the Pico/RP2040-based Inky Frame devices could pull off.)

I started putting together a Lua-based toy microcomputer [1] using PicoVision and a USB mini B to A adapter to connect a mouse/keyboard. It’s a hacky mess, but it serves as a proof of concept.

There’s also a herculean work in progress to bring PicoVision support to the 32blit embedded game SDK [2]

(disclaimer: I also worked on PicoVision)

1. https://github.com/gadgetoid/picovision-micro-computer/tree/... 2. https://github.com/32blit/32blit-sdk/pull/829

A PIO LUT instruction with a 256 entry deep, 32bits wide lookup table would absolutely make my day.

Really interested in putting together some kind of USB host to HID over GATT profile or Bluetooth HID to i2c/UART bridge.

We’re (Pimoroni) closing on shipping a dual RP2040 HDMI board (PicoVision) that’s great for bedroom coder style games, but lack of full fat Bluetooth support or USB HID host in MicroPython - and the relative pain of making and supporting a build that includes these features - make adding controllers… tricky.

Now I wish I’d kept the Dreamcast controller I modded with a custom cable to poke Maple bus. Hindsight!

Obligatory shameless plug of https://pinout.xyz where I’ve been maintaining an interactive Raspberry Pi SBC pinout for some years, and the newer https://pico.pinout.xyz where I’ve tried to do the same for the Raspberry Pi Pico board. The latter also became a command-line pinout via the Python package “picopins”

I feel- and of course I’m biased- that if anything is worth bringing to the table for device pinouts it’s interactivity and accessibility. The latter, in particular, is lost in static images. I really leaned into this with the Pico Pinout, including everything from visual accessibility accommodations (avoiding low contrast text background colours), to markup for screen readers to the ability to turn off labels and reduce noise. I’m still unsure if I actually achieved my goal, but it’s been fun.

I’d be remiss not to mention that we (Pimoroni) sit right at the hacker end of the E-ink scale with stuff like Badger2040W [1] and Inky Frame [2], both of which pair (small and less small) E-Ink panels with the RP2040 microcontroller so you can BYO software.

The biggest roadblock to these being super compelling is update rate. The black/white screen on Badger can be driven pretty hard, but overdriving it (a friend built a continuous E-ink zoetrope [3]) has consequences.

Inky Frame’s 7 colour display is awesome for dithered artwork (missing cyan and magenta notwithstanding) but very, very slow to refresh- ~30s after the panels were updated to incorporate an unskippable “clean” phase.

Faster, cheaper and bigger all seem mutually exclusive right now, but I share the authors passion for the format.

1. https://shop.pimoroni.com/products/badger-2040-w?variant=405...

2. https://shop.pimoroni.com/products/inky-frame-7-3?variant=40...

3. https://www.tomshardware.com/news/raspberry-pi-digital-zoetr...

Bear in mind I’m just reading the product page specs here but if you want me to measure mine I can dig it up!