Cool project. Thanks for doing a write-up that includes so much detail.
I do a lot of PCB review for students and makers, so if you're interested I wrote up some notes. Consider this an incomplete review because I only had so much free time, but hopefully this information can be helpful for your next rev or next project.
Design:
- Add ESD protection to all pins exposed by connectors and around the buttons. A simple TVS will work. However, the capacitance of the TVS needs to be small enough to minimize burden on your higher speed lines like USB and VGA. I'd use a cheap TVS for the low speed pins and then maybe look at some dedicated USB-HS protection parts and then just re-use those on the VGA lines. The USB3300 part you're using looks to have some minimal built-in ESD protection but as you observed it's probably not enough for real world use.
- Consider a buffer between your resistor DAC and the output. This could be an op-amp or a dedicated buffer chip. This will let the resistor DAC operate without significant load, isolated from the cable. You can then put a 75 ohm resistor in series with the buffer output to get optimal impedance matching with the 75-ohm VGA cable and load. You can get away with resistors connected straight to the VGA cable for demo purposes, but having it properly buffered and impedance matched will clean up the edges even further.
- Look into the design of an R-2R DAC as an alternative to the weighted-summing configuration you've used. You would want 0.1% resistors at 8-bit depth but you'd only have to buy and manage 2 resistor values (R and 2R) which is helpful when doing hand assembly.
- Better yet: This project is a good place to use a real DAC chip. Resistor DACs are cool to play with and useful for ultra-cheap demo boards where manufacturing cost is a high priority (Like the RP2040 VGA demo) but for a hand-assembled project like this a good DAC chip is great choice. It would shrink your PCB, reduce assembly time, and allow you to choose a physically smaller MCU package because you don't need 24 IO pins for the resistors.
Schematic:
- When using hierarchical schematics it's a good practice to avoid putting ICs and components in the root sheet. I suggest adding additional sheets for the MCU and other parts, then connect the blocks in the root. Treat the root page like a block diagram.
- KiCAD's bus functionality could help reduce a lot of the pins going into your blocks, like USB_D[0:7] and VGA_R[0:7]
- Breaking up that big STM symbol into a couple parts would be a good way to learn how to use KiCAD's symbol editor and would allow everything to fit on standard A4 sheets
- Don't hesitate to add notes to the schematic that might be helpful during debugging, assembly, or for your future self when you return to the project.
- I like to do a cleanup pass on schematics to make sure all labels are readable and there's enough space to comfortably see everything. It's a good practice to get into and pays off when you're tired from a long debugging session and trying to read a schematic. I suggest using the empty space on some of your pages to space components out more so no text is overlapping or hard to read.
PCB:
- You used 0.15mm (5.9 mil) traces almost everywhere. It's best to avoid using small traces unless you have to. You want to stay away from the minimum trace/space of your PCB manufacturer by default and reserve those for only the places where you need it. It will improve yields and make rework easier. Many of your traces could be 0.25mm or 0.5mm without any problem.
- Likewise, avoid letting traces run too close to pads unless you really need to. It's okay when you need to squeeze a trace into a narrow spot, but by default you should try to give as much room between pads and traces and between adjacent traces as you can. The tighter the spacing, the easier it becomes to accidentally short something out during assembly.
- Similar story with vias: Try not to use the absolute smallest vias everywhere when you have space.
- A lot of your vias are grouped together in a way that creates large slots in your ground plane. This doesn't matter too much at the low speeds you're working with, but it's good practice to avoid creating large cutouts in ground planes. The return current has to flow somewhere and those big slots will force it to take a longer path, which increases emissions and distorts high speed signals.
The example image for blanking from pyroelectro.com seems off to me. The blanking was on all sides of the images, not just two sides. The beam was off before reaching the end of the line, during the retrace, and still partially at the beginning of the line. The same for the retrace back to the top. The vertical blanking at the top of the image was important as things like CC and VITC were encoded there (as well as some other non-standard uses). Essentially, the active picture was window boxed in the blanking. This example image does not represent that well at all
I also produce hardware projects and share them open source but unfortunately at a certain level of complexity people don't reproduce them. It's kind of sad but also I'm glad to be able to give back as I've had people help me learn to code in the past, sit down with me through video and yeah. Or people sharing knowledge in question answer forums.
There is the inspiration aspect too I've had some of my repos get forked/modded so that's something but yeah ultimately gotta do it for yourself. Getting published in tech websites is cool though, like I had a project get picked up by a Japanese website that was neat.
> I like the Raspberry Pi RP2040 a lot. It's relatively cheap (around $1 USD) and has tons of on-board RAM - 264 KB in fact! It also has what is called Programmable IO, or PIO.
I wonder how benchmarks would compare between the RP2040 and, say, a Z80.
It would destroy the Z80. It's a 32bit, dual core CPU running at 133MHz. Even single cored it'll thrash a Z80. Heck, I bet you could create a drop-in replacement board for the Z80 using an RP2040.
Yes, I understand that, but I wonder about the multiple (obviously there is more to it than clock speed). I chose the Z80 because of its long-standing reputation.
My sweet spot of choice between power and price is the ESP32 S3 (2x core @ 240mhz) at ~$6 per board, but yeah, the power to dollar ratio is crazy these days, across the board. And they are absolutely tiny and sip power if you write the code well.
The key here is the "PIO" which you won't find on a Teensy. It lets you do extreme "bit banging" tricks including generating video. People have even implemented Ethernet on it. I've used it for some custom serial protocols ("Weigand") used by alarm panels.
The Pico PIO has an instruction set and can be programmed.
You write PIO assembly that runs autonomously on a state machine, with explicit timing (e.g., out, in, set, mov, jmp, wait) and cycle‑accurate interfaces. The CPU communicates via small FIFOs, and interrupts are optional; the PIO can be “fire‑and‑forget” for many protocols.
The RP2040 is a Cortex-M0, which is about the smallest core you find on modern systems but still a pipelined 32 bit RISC machine running in the dozens of MHz.
Note though, that the article is really about the PIO device on these SOCs', which isn't part of the main CPU at all. It's sort of a very limited programmable hardware engine for the specific task of doing PCB level interconnect using GPIO and lightly buffered streaming. In some sense it's like a thematic midpoint between an FPGA and a CPU.
It's... honestly it's just really weird. And IMHO has really, really, REALLY limited application. It's for people who would otherwise be tempted to bitbang an I2C or UART, but not for ones who can put hardware on the board themselves, or who have a FPGA handy, or even for people who want to do non-trivial stuff like QSPI displays[1] or whatnot.
Basically PIO smells like a wart to me. I genuinely don't know who wants it. Regular hackers aren't sophisticated enough to use it productively and the snobby nerds have better options.
[1] The linked article appears to be doing a quarter-VGA display in 3-bit/8-color, and is sort of right at the limit of the power of the engine.
> The linked article appears to be doing a quarter-VGA display in 3-bit/8-color, and is sort of right at the limit of the power of the engine.
The resolution and color depth restrictions were the product of the low data rate of USB FS (~12 Mbps), not inherent limitations of PIO.
> It's... honestly it's just really weird. And IMHO has really, really, REALLY limited application.
I'd agree with "weird". But it's useful weird; it turns out that there are a lot of situations where PIO can avoid the need for an application-specific peripheral, and can provide that function in a more flexible fashion than a fixed-function peripheral could. Dmitry's SDIO device emulator is a great example - almost every other SDIO peripheral on the market is host-only.
> it turns out that there are a lot of situations where PIO can avoid the need for an application-specific peripheral
And I can only repeat: I think that's an aspirational delusion. I'm not aware of anyone shipping a PIO solution to anyone in volume. It's "useful weird" to Hackerspace nerds like us, and that leads to some epistemological skew.
Hardware needs to be boring and reliably supported (by people you can sue!) or else no one will bet a 10k unit PCB run on it. This is anything but.
>Basically PIO smells like a wart to me. I genuinely don't know who wants it. Regular hackers aren't sophisticated enough to use it productively and the snobby nerds have better options.
I mean, I applaud your work. But let's also be honest (in the "tough love" sense): those are all toys with significant limitations that preclude anyone shipping any of them on an actual device to an actual consumer. I mean, your SOC (maybe a $2 one) surely already includes a SPI master and USB host!
Actual interconnects that solve real market problems have big boring spec books and competing implementations and silicon vendors. The application for PIO is basically limited to "I have to connect to this crazy old junk and no one makes the part I'd otherwise need".
Having dealt with the errata sheets for microcontrollers with all those fancy IO devices that solve real marketing problems etc, I'd kill to fix those problems with a software upgrade.
Cool project. Thanks for doing a write-up that includes so much detail.
I do a lot of PCB review for students and makers, so if you're interested I wrote up some notes. Consider this an incomplete review because I only had so much free time, but hopefully this information can be helpful for your next rev or next project.
Design:
- Add ESD protection to all pins exposed by connectors and around the buttons. A simple TVS will work. However, the capacitance of the TVS needs to be small enough to minimize burden on your higher speed lines like USB and VGA. I'd use a cheap TVS for the low speed pins and then maybe look at some dedicated USB-HS protection parts and then just re-use those on the VGA lines. The USB3300 part you're using looks to have some minimal built-in ESD protection but as you observed it's probably not enough for real world use.
- Consider a buffer between your resistor DAC and the output. This could be an op-amp or a dedicated buffer chip. This will let the resistor DAC operate without significant load, isolated from the cable. You can then put a 75 ohm resistor in series with the buffer output to get optimal impedance matching with the 75-ohm VGA cable and load. You can get away with resistors connected straight to the VGA cable for demo purposes, but having it properly buffered and impedance matched will clean up the edges even further.
- Look into the design of an R-2R DAC as an alternative to the weighted-summing configuration you've used. You would want 0.1% resistors at 8-bit depth but you'd only have to buy and manage 2 resistor values (R and 2R) which is helpful when doing hand assembly.
- Better yet: This project is a good place to use a real DAC chip. Resistor DACs are cool to play with and useful for ultra-cheap demo boards where manufacturing cost is a high priority (Like the RP2040 VGA demo) but for a hand-assembled project like this a good DAC chip is great choice. It would shrink your PCB, reduce assembly time, and allow you to choose a physically smaller MCU package because you don't need 24 IO pins for the resistors.
Schematic:
- When using hierarchical schematics it's a good practice to avoid putting ICs and components in the root sheet. I suggest adding additional sheets for the MCU and other parts, then connect the blocks in the root. Treat the root page like a block diagram.
- KiCAD's bus functionality could help reduce a lot of the pins going into your blocks, like USB_D[0:7] and VGA_R[0:7]
- Breaking up that big STM symbol into a couple parts would be a good way to learn how to use KiCAD's symbol editor and would allow everything to fit on standard A4 sheets
- Don't hesitate to add notes to the schematic that might be helpful during debugging, assembly, or for your future self when you return to the project.
- I like to do a cleanup pass on schematics to make sure all labels are readable and there's enough space to comfortably see everything. It's a good practice to get into and pays off when you're tired from a long debugging session and trying to read a schematic. I suggest using the empty space on some of your pages to space components out more so no text is overlapping or hard to read.
PCB:
- You used 0.15mm (5.9 mil) traces almost everywhere. It's best to avoid using small traces unless you have to. You want to stay away from the minimum trace/space of your PCB manufacturer by default and reserve those for only the places where you need it. It will improve yields and make rework easier. Many of your traces could be 0.25mm or 0.5mm without any problem.
- Likewise, avoid letting traces run too close to pads unless you really need to. It's okay when you need to squeeze a trace into a narrow spot, but by default you should try to give as much room between pads and traces and between adjacent traces as you can. The tighter the spacing, the easier it becomes to accidentally short something out during assembly.
- Similar story with vias: Try not to use the absolute smallest vias everywhere when you have space.
- A lot of your vias are grouped together in a way that creates large slots in your ground plane. This doesn't matter too much at the low speeds you're working with, but it's good practice to avoid creating large cutouts in ground planes. The return current has to flow somewhere and those big slots will force it to take a longer path, which increases emissions and distorts high speed signals.
This is great advice! Thanks!
The new RP 2350 has an enhanced PIO that relaxes some of the constraints the author ran into here.
Also the new HSTX (high-speed serial transmit) unit is really well suited for rapid line coding.
Here's a different project that generates a high resolution high depth VGA signal from the RP 2350: https://www.breatharian.eu/hw/disphstx/index_en.html
And here's NTSC composite using just the original PIO: https://github.com/obstruse/pico-composite8
The example image for blanking from pyroelectro.com seems off to me. The blanking was on all sides of the images, not just two sides. The beam was off before reaching the end of the line, during the retrace, and still partially at the beginning of the line. The same for the retrace back to the top. The vertical blanking at the top of the image was important as things like CC and VITC were encoded there (as well as some other non-standard uses). Essentially, the active picture was window boxed in the blanking. This example image does not represent that well at all
Philosophical tangent
I also produce hardware projects and share them open source but unfortunately at a certain level of complexity people don't reproduce them. It's kind of sad but also I'm glad to be able to give back as I've had people help me learn to code in the past, sit down with me through video and yeah. Or people sharing knowledge in question answer forums.
There is the inspiration aspect too I've had some of my repos get forked/modded so that's something but yeah ultimately gotta do it for yourself. Getting published in tech websites is cool though, like I had a project get picked up by a Japanese website that was neat.
CRT tech is neat, the flat ones are cooler
https://www.youtube.com/watch?v=pjzK-Lppa1c
Cool project! I've been doing software for so long but originally got an EE degree. I miss messing around with hardware.
> I like the Raspberry Pi RP2040 a lot. It's relatively cheap (around $1 USD) and has tons of on-board RAM - 264 KB in fact! It also has what is called Programmable IO, or PIO.
I wonder how benchmarks would compare between the RP2040 and, say, a Z80.
It would destroy the Z80. It's a 32bit, dual core CPU running at 133MHz. Even single cored it'll thrash a Z80. Heck, I bet you could create a drop-in replacement board for the Z80 using an RP2040.
Note it was possible to use a Z80 to function as a display controller, people used to do it back in the day...
https://archive.org/details/Cheap_Video_Cookbook_Don_Lancast...
Yes, I understand that, but I wonder about the multiple (obviously there is more to it than clock speed). I chose the Z80 because of its long-standing reputation.
Crazy what you can buy nowadays like the Teensy 4.0 with 600MHz base clock
Granted that's $20 not $1
My sweet spot of choice between power and price is the ESP32 S3 (2x core @ 240mhz) at ~$6 per board, but yeah, the power to dollar ratio is crazy these days, across the board. And they are absolutely tiny and sip power if you write the code well.
The key here is the "PIO" which you won't find on a Teensy. It lets you do extreme "bit banging" tricks including generating video. People have even implemented Ethernet on it. I've used it for some custom serial protocols ("Weigand") used by alarm panels.
Really I guess I don't know what that is then as I buy the Teensy since it has so much IO, multiple UART, multiple I2C busses, sd card reading, etc...
edit: interesting
(Teensy | Pico)
Special Features: CAN Bus (3x), SDIO, S/PDIF | PIO (Programmable I/O) (8 SMs)
The Pico PIO has an instruction set and can be programmed.
You write PIO assembly that runs autonomously on a state machine, with explicit timing (e.g., out, in, set, mov, jmp, wait) and cycle‑accurate interfaces. The CPU communicates via small FIFOs, and interrupts are optional; the PIO can be “fire‑and‑forget” for many protocols.
That's cool, I'm not at that level right now, side note I bought an FPGA like 5 years ago and still haven't used it.
The RP2040 is a Cortex-M0, which is about the smallest core you find on modern systems but still a pipelined 32 bit RISC machine running in the dozens of MHz.
Note though, that the article is really about the PIO device on these SOCs', which isn't part of the main CPU at all. It's sort of a very limited programmable hardware engine for the specific task of doing PCB level interconnect using GPIO and lightly buffered streaming. In some sense it's like a thematic midpoint between an FPGA and a CPU.
It's... honestly it's just really weird. And IMHO has really, really, REALLY limited application. It's for people who would otherwise be tempted to bitbang an I2C or UART, but not for ones who can put hardware on the board themselves, or who have a FPGA handy, or even for people who want to do non-trivial stuff like QSPI displays[1] or whatnot.
Basically PIO smells like a wart to me. I genuinely don't know who wants it. Regular hackers aren't sophisticated enough to use it productively and the snobby nerds have better options.
[1] The linked article appears to be doing a quarter-VGA display in 3-bit/8-color, and is sort of right at the limit of the power of the engine.
> The linked article appears to be doing a quarter-VGA display in 3-bit/8-color, and is sort of right at the limit of the power of the engine.
The resolution and color depth restrictions were the product of the low data rate of USB FS (~12 Mbps), not inherent limitations of PIO.
> It's... honestly it's just really weird. And IMHO has really, really, REALLY limited application.
I'd agree with "weird". But it's useful weird; it turns out that there are a lot of situations where PIO can avoid the need for an application-specific peripheral, and can provide that function in a more flexible fashion than a fixed-function peripheral could. Dmitry's SDIO device emulator is a great example - almost every other SDIO peripheral on the market is host-only.
> it turns out that there are a lot of situations where PIO can avoid the need for an application-specific peripheral
And I can only repeat: I think that's an aspirational delusion. I'm not aware of anyone shipping a PIO solution to anyone in volume. It's "useful weird" to Hackerspace nerds like us, and that leads to some epistemological skew.
Hardware needs to be boring and reliably supported (by people you can sue!) or else no one will bet a 10k unit PCB run on it. This is anything but.
driving complex displays with no spu use: https://dmitry.gr/?r=06.%20Thoughts&proj=09.ComplexPioMachin... (my work)
pretending to be memory stick and sd card at dozens of mhz as a slave to a sync bus (my work)
ethernet: https://github.com/kingyoPiyo/Pico-10BASE-T (not my work)
68k bus slave (my work)
usb host https://github.com/sekigon-gonnoc/Pico-PIO-USB (not my work)
all on a $1 chip
> what are you blathering on about, sir?
Please don't.
I mean, I applaud your work. But let's also be honest (in the "tough love" sense): those are all toys with significant limitations that preclude anyone shipping any of them on an actual device to an actual consumer. I mean, your SOC (maybe a $2 one) surely already includes a SPI master and USB host!
Actual interconnects that solve real market problems have big boring spec books and competing implementations and silicon vendors. The application for PIO is basically limited to "I have to connect to this crazy old junk and no one makes the part I'd otherwise need".
Having dealt with the errata sheets for microcontrollers with all those fancy IO devices that solve real marketing problems etc, I'd kill to fix those problems with a software upgrade.