How To Develop a PCB on a Low Budget


Last week I have shared with you the issues related to finding and sourcing a SoC for the DragonBox Pyra, an upcoming Linux handheld computer with gaming controls and keyboard. Now, Evil Dragon has shared some additional information regarding the way the team is approaching the PCB (Printed Circuit Board) development. Have a look!

At the FOSDEM event held last week in Brussels, the DragonBox Pyra team has been showing an early prototype of the DragonBox Pyra board in action. In case you missed it, I’m sharing it again below. It was certainly much faster than what the Open Pandora can do, since this board was able to run 2 Playstation emulators full speed at the same time while having other applications running in the background.

But how did they make it work? We know the development of the Pyra has not been going on for a very long time, yet they were able to have something to demonstrate relatively quickly.

Evil Dragon: Designing a PCB takes a lot of time. Not just for the design, but for debugging as well – and what’s worse: You spend a lot of time simply WAITING for the prototype PCBs. A PCB like we need it usually needs 8 layers. The normal production time for an 8 layer bare PCB is 6 weeks – and it’s pretty expensive as well (especially for just doing prototypes). Additionally, populating them with all of the complex parts as well (like the OMAP) costs a lot of money. Both for parts AND the population.

Yeah, while they appear to be relatively flat, PCBs actually have several layers. Here’s what it could look like in case of 4 layers, but the potential number of layers could be much higher. This makes it possible to increase the area for the wiring without expanding the area size of the PCB.


So, how did they avoid doing these 8 layers PCBs in order to make a prototype so far?

ED: We’re using a different approach here. The Pyra PCB right now is a simple two layer-PCB. Can be created in a couple of days for little money. All of our custom parts (keyboard controller, LED controller, nubs, switches, UMTS module, etc.) are populated on the PCB. However, the complex part (the SoC) is still on the devboard. The devboard and the Pyra PCB are connected via a special connector Nikolaus created, which includes an i²c bus, gpios, etc. So basically, our custom parts are connected the exact same way as they will be connected on the final PCB to the SoC. That’s pretty helpful, as we can now use low-cost Pyra PCBs we can get within a couple of days to test all the hardware we want to include. And once everything works as it should, “only” the SoC with components like RAM, power circuits, storage, etc. needs to be transplanted to the Pyra PCB – which will then be the first REAL prototype.

Here’s a video to clarify what ED’s talking about:

Don’t get the wrong idea though. They are nowhere near done.

ED: “Only” sounds like it’s a quick thing to do – but in reality, this is A LOT of work that will need more time than the rest of the design! That way still saves a lot of time and money though.

By working in this way, the final decision regarding the SoC can still be taken at the very last stage. Well, last week ED was pretty much set on using an OMAP from TI, but following some comments on the post I published about it (thanks to everyone who participated, by the way), it now seems that the SnapDragon from Qualcomm could also be an option. Anyway, this has certainly sparked some discussions and the next few weeks will be used to have a fresh look at the SoC options again.

So, why wasn’t that approach taken back in the Pandora development days ?

ED: Well, Michael designed the first prototype when no devboard was available (the BeagleBoard came out after that…) – an impressive amount of work! I’m happy it’s easier this time though!

By the way, the devboard was a simple PCB without any screen attached to it, and there’s a reason for that. So far, they could not make the LCD work, even though it’s going through a standard MIPI interface (I assume it’s going through a DSI interface just like on the Raspberry Pi).


Note that it’s very different from the interface that was used at the time for the Pandora… since a custom LCD cable was required (and many of them suffered through the hinge movements, while the newer ones seem to be sufficiently robust now).


Yet, while they went for a standard interface and cable this time for the Pyra, the display fails to show anything at this point.

ED: MIPI is the standard interface LCDs are using these days – and while “standard” seems to imply it’s something easy to use, it sure isn’t. “Standard” is only the communication protocol – getting the LCD to do something is something else. You need to calculate and set size, timings, etc. everything yourself… After a lot of reading into MIPI and how it generally works and many many patches later, we still didn’t get the LCD to show a picture – but at least we can communicate with it now. What’s missing now is the startup sequence to tell the LCD to actually do something. That’s something the manufacturer should be able to tell us.

It’s probably not a huge issue, but it certainly shows you constantly run into problems you don’t expect in the first place.

Leave a Reply

1 Comment threads
0 Thread replies
Most reacted comment
Hottest comment thread
1 Comment authors
ekianjo Recent comment authors
newest oldest most voted
Notify of