Having gotten my first taste of Altium, I decided to try my hand at something more complex. Digging through my box of samples, I came across the MK66FN2M0VMD18 which is in the same family of chip used in the FRDM-K66F and Teensy 3.6. Since this was my first time using Ethernet in a design, it was very helpful to be able use the FRDM-K66F schematics for reference and rely on Mbed for software support. At the end of the day, this board took a week to design from ideation to PCB order – a stark departure from my usual 4 hour process – but I ended up with something I’m quite proud of.


One of the things that I really like about Altium is just how well it does things like hierarchical designs and harnesses. With schematics no longer fitting on one page, I’ll link the PDF and show a picture of the top level sheet. The top level sheet basically shows the major components of the board in a way that encourages reuse.


As for the details of the individual sheets, the design was driven by the goal of buying as few parts as possible and using things from my personal stock instead. Getting something working at home was more important than making it work in all environments which as usual meant removing things that weren’t absolutely necessary.

For the PHY, I actually bought a KSZ8091 instead of the KSZ8081 but since it has more features and appear to be in the same family, I correctly guessed I could just drop it in. Chances are any PHY would work depending on how the Mbed driver works, but better safe than sorry. The RMII signals usually need series termination to remove reflections, but given my traces were so short I omitted them.


The layout was really quite the challenge, taking me the majority of my design time. This board marks my most expensive OSH Park order, but I’m pretty happy with how small I was able to squeeze it. BGAs are an interesting part to route and I can definitely see where some people are coming from when they say it’s easier than a QFN. With the traces so short, I didn’t do any kind of length matching or impedance control on the RMII lines. I did try playing with Altium’s differential routing for the USB and Ethernet lines.


As my first time using a solder stencil, I have to say it is well worth the money. Instead of spending over an hour squeezing paste, I can do the whole thing in a swipe. It took a few tries, but I got a working technique down. To avoid the stencil shifting and merging pads, my technique is to initially apply a mostly vertical force when moving the paste over the stencil. Then I alternate between that and a mostly horizontal force to squeeze the paste into all the crevices.

Zephyr RTOS

After testing the board using Mbed and confirming everything worked, I tried porting it over to Zephyr which I just learned about. Having used Mbed for a few years, I feel that it’s best suited for quickly bringing boards up with the same chip as a supported target but quickly gets messy when you try to push beyond that. My initial impressions of Zephyr are that it trades off higher initial overhead for a very Linux-y feel to everything which makes organizing and modifying things much easier. Adding new boards and managing multiple version controlled projects feel like something that was actively thought about.

Of course, Zephyr is not without its little quirks. While porting this board over, I learned that due to how the clocks are setup, I couldn’t make USB work without lowering the clock speed or modifying that setup. It looks like an NXP specific thing, but when defining pins I have to do it both in both the pinmux code and the DTS which seems redundant. In addition, like with Mbed, there isn’t a generic PHY framework but instead each vendor’s driver looks specific to the PHY they use in their dev boards. Likewise, it’s pretty clear looking at the DTS files which boards came first and which had support added later. Still, I really like Zephyr.

Anyway, it ended up working! Here’s the repo where I’ll be putting all of the boards I design and add Zephyr support for.