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.
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.
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.
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.
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.
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.
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-
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!)
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]
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.