Blog - All Comments

RE: Getting Custom RP2040 Boards Produced and Assembled with KiCad, Part 2!

shabaz — Wed, 01 Jul 2026 01:46:59 GMT

I gave it a try! This is the minimal board with the additions I wanted. I uploaded the PCB files, and then at the bottom of the website clicked on PCB Assembly.

The website prompted me for the BoM and Component Positions files (which were auto-generated by KiCad by clicking on the icon that got installed with the Fabrication Toolkit plugin).

Then, I had to visually go over this rendering that the site created, to check all component positions and orientations were correct.

This was the costing for a quantity of 10 (which is excessive, really I should only try a few boards first, but worst case I'll manually do some rework on these boards if needed).

With tax and DHL shipping all included, it worked out to $214 total, which is £169, i.e. £16.90 per board.

RE: Adding Wireless Capability to Custom RP2040/RP2350 Projects: Pi Radio Module 2 - Anyone tried it?

shabaz — Tue, 30 Jun 2026 21:51:29 GMT

Using the schematic mentioned by [mention:330078c07ce64e488ea3c5c4fc602342:e9ed411860ed4f2ba0265705b8793d05] just four GPIO connections are needed to the RP2040, and I was curious roughly were the module could fit on a minimal RP2040 design (e.g. (+) Making a Custom RP2040 Project with KiCad, Part 1! - element14 Community ). The illustration here shows the four required connections in yellow, and approximately where the module could be placed so traces could be routed easily (I'm not planning to do this with the particular circuit I'm working on, but will consider it for future, or maybe place a SIL header there, for wiring up later.

Aside from those four connections, GND and 3.3V is needed of course (The Pimoroni Pico 2 W uses a ferrite bead on the supply), and the module has three GPIO, one of which is used for an LED, and another is wired to a potential divider attached to the USB 5V supply, but seems unnecessary (I don't think the firmware does anything with that, it is just for developer use if they want to see if the USB supply is present, so I think that could be omitted if it simplifies PCB routing).

RE: Adding Wireless Capability to Custom RP2040/RP2350 Projects: Pi Radio Module 2 - Anyone tried it?

wolfgangfriedrich — Tue, 30 Jun 2026 17:46:06 GMT

When I saw this, my first thought was: put it on some sort of m.2 carrier for a more universal wireless card. But the interface does not seem to be fully compatible with whatever m.2 has to offer.

RE: Adding Wireless Capability to Custom RP2040/RP2350 Projects: Pi Radio Module 2 - Anyone tried it?

veluv01 — Tue, 30 Jun 2026 17:16:16 GMT

The pimoroni pico plus 2W has it.The schematic is available for it.

Apparently, it can only be used with the rp2040 and rp2350's.

RE: Adding Wireless Capability to Custom RP2040/RP2350 Projects: Pi Radio Module 2 - Anyone tried it?

embeddedguy — Tue, 30 Jun 2026 17:12:12 GMT

Would be nice to add some sub-ghz module. You can have better range with that.!

RE: Getting Custom RP2040 Boards Produced and Assembled with KiCad, Part 2!

shabaz — Mon, 29 Jun 2026 17:21:09 GMT

I've updated the PCB at the RP2040 custom minimal board repository, so that is uses a surface-mount connector suggested by [mention:333884685f3541cfa8a54caa82a8c2f5:e9ed411860ed4f2ba0265705b8793d05] and it's simplified the USB data lines routing too.

I tried uploading the design to a usual PCB manufacturer, and it looks good.

Here's the costing for ten boards (add your shipping costs and tax on top of that).

Of course, this is just for informational purposes, I'm not going to order this specific board as-is, since it's a minimal design with no GPIO connected (apart from an LED!). It is up to the user to append their own circuitry, e.g. header pins if nothing else).

A couple of points regarding the online assembly service experience so far:

(1) It can happen that the PCB assembly manufacturer is unable to render some of the components in the 3D view. They were displayed with a checkerbox pattern. I believe that means the manufacturer will ckeck the layout manually, so instead I decided to change the component to one that was recognized. This was an annoying iterative process admittedly.

(2) Some components can appear with an offset or incorrect rotation. Rotations can be solved immediately by clicking an icon in the 3D view on the website (this is the simplest way but like me, some might prefer to go back and modify in their files), but if there is an offset, that's more long-winded. I had to move the component in the footprint editor (i.e. select all, then right-click and from the pop-up menu in KiCad go to Position->Move Exactly), which is really annoying since of course that means that the PCB needs to be modified because the component will move. For example, the USB connector was off the PCB by precisely 5 mm (I don't know why!). My original (0,0) position, i.e. origin of the component, was at the location shown with the red arrow. That position made sense to me, because it was the most important reference mechanically, it is where the connector ends. However, I had to move the component such that the origin was at the green arrow location, 5 mm inward. In practise, while this is feasible with the very simple board that I had, with a more complex board you definitely won't want to be doing this. You could edit the positions in the CSV file generated by the Fabrication Toolkit in KiCad, but then you'd need to remember to re-edit that, if you ever re-ran that toolkit. Probably best to make a checklist and add notes for such things for the specific board, so you don't forget.

One other observation, is that all this might seem like a lot of work to set up, and it really is. But then when I thought about it, manufacturing an entire board should rightly be expected to be a lot of work. Normally that's a whole team-worth of work (design engineers, PCB engineers, mechanical engineers, parts procurement and parts library management, and so on), so it's impressive a lot of that can be collapsed into an online ordering process, but you do still need to do an amount of work to get through it.

RE: Making a Custom RP2040 Project with KiCad, Part 1!

arvindsa — Sun, 28 Jun 2026 12:21:04 GMT

I came here from your Part 2 of this post. Looking at the PCB Layout of the original PCB, I see a lot of polygon on top layer for the 3.3V Net. Now before I say something more, I have to say that I believe that when executing an engineering project, one has to design for the robustness for the intended purpose of the project. Anything beyond that would be waste of resource, it could be time, material, money anything. Back to the 3.3V pours with intricate shape, I think it is unnecessary, it could have been thicker traces. and Rpi does not have huge instantaneous power requirement to justify a very short return path and etc. [mention:b0bc65b9ecdc4307bd967592f00e340a:e9ed411860ed4f2ba0265705b8793d05] do you think of any reason why there is these 3.3V copper fills?. One could have just made a rectangular fill instead.

RE: Getting Custom RP2040 Boards Produced and Assembled with KiCad, Part 2!

geralds — Sat, 27 Jun 2026 18:35:42 GMT

Hi [mention:b0bc65b9ecdc4307bd967592f00e340a:e9ed411860ed4f2ba0265705b8793d05]

Wow! superb! They are very fine information's that I can use.

Please look I've answered and uploaded my Ki-Cad files in part 1.

Best Regards Gerald

RE: Making a Custom RP2040 Project with KiCad, Part 1!

DAB — Thu, 25 Jun 2026 20:17:03 GMT

Very good post.

RE: Making a Custom RP2040 Project with KiCad, Part 1!

shabaz — Wed, 24 Jun 2026 20:31:34 GMT

I wonder if the Raspberry Pi people every got one of these PCBs assembled.. they have traces not running through the center of pads. These are lightweight 0402 parts, they will rotate as the solder reflows. For instance, C12 in the screenshot below, would rotate clockwise:

Here's another unusual trace design, on C14. The left side of it has more copper traces attached to it, it may cause the component to slide leftward.

I'm going to try to clean these up, because it will get reflowed, I'm not going to hand-solder this.

For instance, here's a resistor that wasn't in the original circuit. I've brought out both of the traces more aligned, even though it is a longer path.

RE: Making a Custom RP2040 Project with KiCad, Part 1!

wolfgangfriedrich — Wed, 24 Jun 2026 17:53:27 GMT

Thanks for connecting the SPI flash and the crystal to the controller chip with wires and not only net labels on the schematic. This way it is much more well-arranged and understandable on first sight.

RE: Making a Custom RP2040 Project with KiCad, Part 1!

geralds — Wed, 24 Jun 2026 17:09:31 GMT

Hi Shabaz,

Great!

Thank you so much for the informative details.
I'm looking forward to part 2.
Similar, I've planned to create it with the Eagle.

Gerald
---

RE: E-Z USB to I2C Adapter and UART Bridge

genebren — Wed, 10 Jun 2026 22:59:29 GMT

Very cool! I have had some projects where that feature set might have been useful.

A bit of topic, but I have dealt with limited comm ports in several projects (specifically working with laboratory equipment, like pumps and sensors) where I needed more pumps. At one point I developed a comm port multiplexer, where a single comm port connected to a ATmega device could drive multiple slave boards with 2 comm ports. I built and sold several of these devices, along with a comm library to allow the slave ports to appear as actual comm port. This was more than 20 years ago. There are far more capable devices available today.

RE: E-Z USB to I2C Adapter and UART Bridge

DAB — Tue, 09 Jun 2026 19:30:00 GMT

Nice post.

This device could be very useful.

RE: Solving Error: Unknown flash device: An OpenOCD Upgrade for Pi Pico / Xiao and other RP2040 Boards

Coconut1 — Sat, 14 Feb 2026 20:56:10 GMT

I had the exact same problem as described above. Bought 4 cheap Pico Boards online and encountered the connection problem when starting to debug.
With a closer look at the board I could see that there is no 10-pin voltage regulator but a unknown 6-pin and additionally a 2MB Flash 'BY25Q16ES' from
the chines manufacture BYTe Semiconductor. So I was sure, these boards where counterfeit PICOs.
The error message then was
--> Error: Unknown flash device (ID 0x00154068)

The by far easiest way to solve this, is to open the openocd.exe in a text editor and search for the entries of the table shown above.
The 10 values of each line there will be interpreted as:
name, read_cmd, qread_cmd, pprog_cmd, erase_cmd, chip_erase_cmd, device_id, pagesize, sectorsize, size_in_bytes

Now since I knew my Flash device, I download its data sheet and checked for the read/write/prog/erase commands and found that there already is an almost identical device
given with a slightly different device ID 0x001540C8. The rest was easy.
Seraching in a text editor (e.g. np++ in HEX-mode) for the byte-sequence "C8 40 15 00" and finding a "03 00 02 D8 C7 00 00 00" next to it, indicating the correct file position.
Now I changed the "C8" to "68" and saved the modified file openocd.exe.

And it worked!!! The debugger now starts smoothly and every thing is fine ... now after 30+ hours of serching and trying.