Fresh from earning my Bachelor of Engineering in Electrical Engineering and Information Technology, I felt a strong desire to solidify my theoretical knowledge with practical experience. While my academic journey had provided a solid foundation, I recognized a gap in my skillset: PCB design.
This wasn't just about filling a resume bullet point; it was about truly understanding the intricate dance between hardware and software. I firmly believe that hands-on creation is the most effective way to learn, and I was eager to put that belief to the test.
This personal project wasn't just about building a board; it was about building my understanding of embedded systems from the ground up. I wanted to move beyond the pre-made development boards and delve into the intricacies of custom hardware design.
My previous microcontroller experience revolved around Arduino and SparkFun boards, staples of university courses. However, the announcement of the Raspberry Pi Pico and its RP2040 microcontroller sparked a new wave of interest. As a Raspberry Pi 3B owner, I was already familiar with the Raspberry Pi ecosystem. The RP2040's detailed datasheet, its wide availability, and the option to purchase the chip separately offered a level of flexibility and control that resonated with me.
The Raspberry Pi Hardware Design Guide served as an invaluable resource, providing the necessary technical information to guide my project. The RP2040's dual-core architecture and programmable I/O capabilities presented an exciting opportunity to explore more advanced embedded system concepts. I saw this project as a chance to push my boundaries and learn by doing.
My choice of software was heavily influenced by the limitations of my Chromebook. I needed a robust design tool that could operate seamlessly in a cloud-based environment. After extensive research, I discovered flux.ai, a cloud-native, AI-powered schematic and PCB design platform. Its intuitive interface and powerful features made it an ideal choice for my project.
With flux.ai, I quickly set about designing the Alyx Base V1. I meticulously followed the Raspberry Pi Hardware Design Guide, ensuring that my design adhered to the recommended specifications. However, I decided to add a touch of modernity by incorporating a USB-C port, reflecting my desire to stay current with emerging technologies.
The journey from concept to tangible hardware is rarely without its stumbles. My initial attempt, the Alyx Base V1, highlighted several critical design flaws that necessitated a complete overhaul.
The original design's complexity, characterized by double-sided component placement and inefficient layer utilization, proved to be a significant hurdle. Recognizing the need for a more streamlined approach, I embarked on a redesign, aiming for simplicity and manufacturability.
In this redesign, I drew inspiration from the Raspberry Pi Zero/µHAT form factor, envisioning a compact and versatile board. While the Alyx Base V2 ultimately diverged from strict header compatibility, the underlying principle of a small, efficiently designed board remained central to the new design.
One of the key lessons learned from the Alyx Base V1 was the importance of accurate component footprints. To mitigate the risk of future errors, I opted for a readily available, fully specified USB-C part from JLCPCB. This ensured compatibility and simplified the assembly process. Additionally, while retaining the 0402 component size for its compactness, I made the strategic decision to leverage JLCPCB's assembly services. This move not only streamlined production but also minimized the potential for human error during the assembly phase.
Despite meticulous planning and careful execution, the Alyx Base V2 project was not immune to human error. Three critical issues surfaced, highlighting the complexities of hardware development:
Flash Chip Misidentification: A 16MB flash chip was incorrectly labeled and, crucially, had an incorrect part number within flux.ai. This discrepancy led to the chip's omission during the JLCPCB assembly process, a costly oversight.
USB-C Port Footprint Inaccuracy: The USB-C port footprint, despite careful review, remained incorrect within flux.ai. While JLCPCB graciously agreed to a workaround by manually trimming the part, this highlighted the importance of precise footprint verification.
LDO Voltage Discrepancy: The LDO part number was also incorrect within flux.ai, resulting in the installation of a 5V version instead of the required 3.3V. This voltage mismatch posed a significant risk to the RP2040 and necessitated immediate rectification.
To address these errors, I procured the correct LDOs and flash chips from DigiKey. The LDO replacement was successfully completed across all boards, restoring the correct operating voltage.
However, the flash chip replacement proved more challenging, with only two out of five boards successfully soldered. Fortunately, the RP2040's ability to operate in RAM-only mode prevented the complete loss of the remaining boards.
With the correct voltages and partial flash functionality, the boards were recognized as drives by my PC. However, a new hurdle emerged: programs would not execute after being dragged onto the boards. After extensive online research, I discovered the root cause: the crystal oscillator's response time was too slow for the RP2040. The solution involved modifying the Alyx Base V2's board header file to increase the wait time, allowing the RP2040 to properly initialize.
Finally, after overcoming these challenges, I had a functional and programmable board. This milestone marked a significant step forward, enabling me to begin developing and testing applications on my custom RP2040 board.
This process highlighted the iterative nature of hardware development and the importance of persistence in the face of setbacks.
Now that I've designed and assembled my custom RP2040 microcontroller board, it's time to bring it to life with code. The cornerstone of RP2040 development is the Raspberry Pi Pico SDK (Software Development Kit). This comprehensive SDK, provided and meticulously maintained by Raspberry Pi, equips someone with all the necessary tools to craft robust C and C++ applications for a rp2 microcontroller.
To tailor the SDK for my custom board, a crucial step is creating a custom board header file. This involves forking the official pico-sdk repository on GitHub and adding an unique header. This file acts as a blueprint, defining the specific configuration of my board. It details:
GPIO Pin Assignments: Specifies which GPIO pins are allocated for various interfaces (e.g., UART, SPI, I2C). This ensures the software interacts correctly with the hardware components connected to those pins.
Flash Memory Size: Defines the total flash memory capacity of the board, allowing the compiler to optimize code and data storage.
Crystal Oscillator Details: Specifies the frequency and characteristics of the crystal oscillator, which provides the timing reference for the microcontroller.
Creating a custom header file ensures that the compiler understands the unique hardware configuration of the board, preventing conflicts and ensuring optimal performance.
Developing a program for the RP2040 involves more than just writing C code. I also need to create a CMake file, which acts as a build configuration script. This file instructs the compiler on:
File Inclusion: Specifies which C/C++ files should be included in the compilation process.
Dependencies: Lists the required libraries from the SDK, such as those for GPIO control, UART communication, or other peripherals.
Build Settings: Defines compiler flags and other build parameters.
CMake simplifies the build process, especially for larger projects with multiple source files and dependencies If you're new to CMake, numerous online tutorials and resources can guide you through the process.
Once the code is compiled into a binary file, flash it onto the RP2040's flash memory. There are several methods to achieve this:
USB Drag-and-Drop: This beginner-friendly method involves placing the compiled binary file onto the RP2040's mass storage device, which appears when the board is connected in bootloader mode.
Picotool: A command-line utility that provides more advanced flashing capabilities. Picotool offers greater control and flexibility, allowing us to flash the board directly from the command line.
Initially, I opted for the simplicity of USB drag-and-drop. However, as I became more comfortable with the development process, I transitioned to using Picotool. Its efficiency and command-line interface proved to be a more streamlined approach for my workflow.
Using picotool allows for automation of the flashing process, and helps when using a continious integration or continious deployment pipeline.
By mastering the C SDK, CMake, and the flashing process, one can unlock the full potential of a custom RP2040 microcontroller board.
My initial custom board, while a great learning experience, had some flaws. I've been hard at work on a new revision that addresses these issues head-on. Here's a breakdown of the key improvements:
Robust Power Delivery: I'm thickening the power traces to ensure stable performance. The 5V rail will now handle a beefy 3A, and the 3.3V rail will support 1A. This makes the board much more reliable, especially for projects with power-hungry components.
Component Size Optimization: To create a more compact and elegant design, I've shifted away from the many 0402-sized components. I've also swapped out the crystal oscillator for a smaller model, which frees up valuable board space.
User-Friendly Features: A new 3.3V power LED and a user LED on GPIO0 will be added. This simple addition makes debugging and status monitoring so much easier.
Clearer Pinout: I'm adding the pinout directly to the silkscreen. No more searching for a datasheet—the information is right there on the board.
Improved Routing: The Flash IC has been relocated to a more optimal position to simplify routing and improve signal integrity.
Wrong Flash Size: Originally I wanted to have a Flash IC with 16MB but I accidentilly used a 2MB Flash instead. I changed the board header file to fit the correct size.
Designing the board was one thing, but the real test came when the manufactured boards arrived. That’s when I ran into a major problem. My design software, flux.ai, had an issue with its Gerber file export. It automatically generated stitching vias that, unfortunately, created unfixable short circuits across the board. The result was a batch of unusable boards. This was a frustrating setback, but every problem is a chance to learn.
I reached out to flux.ai's support, explained the situation, and to their credit, they were very responsive. They acknowledged the issue and provided a reimbursement for my entire order. While I appreciated the quick resolution, this experience also made me re-evaluate my tools. Given that the free tier of flux.ai was removed shortly after I decided to move on.
Looking ahead, I'm incredibly excited about the next steps. I'm already thinking about a future board based on the new RP2350 chip. This new chip promises some interesting advancements, and I'm particularly keen on exploring a board with an integrated RM2 module. This could open up a whole new world of possibilities for wireless connectivity and more advanced applications.
Stay tuned for updates on the new board Alyx Base V3 and it's wireless version Alyx Base V3 W. I can’t wait to show you the final product and start building some amazing projects with it!