Devlog #2Today was mostly spent fighting the software rather than the hardware. Arduino Lab turned out to be much more challenging than I expected because many of the libraries I needed were originally written for older AVR-based boards. Fortunately, most of them weren’t completely incompatiblethey usually just required a few small changes to the source code. The catch is that Arduino doesn’t let you modify installed libraries directly, so I had to clone the repositories myself, place them in the correct location within the filesystem, and patch them manually before I could even start debugging. It was frustrating at first, but I ended up learning a lot about how the Arduino ecosystem and its library management actually work under the hood.On the UI side, I experimented with the new Bricks implementation and built a dashboard that displays live sensor readings along with other useful information such as notes and system status. The feature I’m happiest with, though, is the display loop I wrote. Instead of showing a single static screen, the interface now automatically cycles through different pages, making much better use of the limited display space without requiring any user interaction. It feels polished, works exactly as I imagined, and is probably my favorite improvement I’ve made to the project so far.

Devlog #1 — Laying the Foundation

I’ve always wanted a Flipper Zero, but since it’s difficult to purchase in several countries, including mine, I decided to build my own from scratch. Rather than making a direct clone, my goal is to create a similar handheld platform while adding a few extra capabilities along the way.

For the main controller, I’m using an Arduino Uno Q. One of the reasons I chose this board is its unique architecture: it combines an onboard microcontroller with a dedicated CPU, providing significantly more processing capability than a traditional Arduino. On paper, it’s an excellent foundation for a multifunction hacking device.

The biggest challenge, however, is that the board does not expose enough GPIO pins for the peripherals I want to integrate. To work around this limitation, I’m pairing it with an ESP32-S3 Zero, which will act as a coprocessor for handling audio processing and other GPIO-intensive peripherals. Splitting the workload between the two processors should make the system much more scalable as additional features are added.

Another major obstacle has been software compatibility. Most of the existing libraries for hardware modules commonly used in Flipper-style projects were written for older AVR-based Arduino boards or STM32 platforms. They don’t work on the Uno Q without modification.

To get the project moving, I spent most of my time porting and adapting these libraries instead of building application features. My first target was the PN532 NFC module, which required substantial changes before it could compile and function correctly on the new hardware. After working through the compatibility issues, I successfully ported the library and now have the PN532 running reliably on the board.

Although there isn’t much visible progress yet, this compatibility work forms the backbone of the entire project. With the NFC stack now operational, I can finally start integrating the rest of the hardware and begin implementing the higher-level functionality that will turn this into a fully featured handheld hacking device.