This blog was written by members of the Zephyr community in Japan. The meetup speakers are referred to by their Discord names throughout the blog.
On June 26, 2026, the Zephyr Project Meetup returned to Sapporo, Hokkaido, bringing together Zephyr users, embedded developers, hardware engineers, researchers, and open source contributors for an afternoon of technical talks and community discussion.
Photo: The area around Sapporo Station is undergoing significant changes in preparation for the arrival of high-speed rail from Tokyo. Just as it has this year, the landscape will likely look different again next year.
The event was hosted by Space Cubics in central Sapporo, bringing the Japanese Zephyr community together one day before Open Source Conference 2026 Hokkaido. That timing made the meetup more than a single afternoon event. It became the start of a full open source weekend in Hokkaido, with Zephyr on Friday, OSC on Saturday, and local community activities continuing into Sunday.
Previous Zephyr meetups in Japan have visited cities such as Osaka, Toyosu, Nagoya, and Kochi. Sapporo added its own flavor: a compact venue, a practical engineering atmosphere, and talks that focused less on “hello world” demos and more on what happens after real hardware starts fighting back.
The meetup started with a familiar embedded systems moment: audio and streaming setup trouble. After a little live debugging of microphones, speakers, and feedback loops, the event moved ahead. In a way, it set the tone for the day. The talks were about the same kind of reality: imperfect systems, incomplete documentation, unexpected behavior, and engineers finding a path forward.
Nordic Semiconductor also continued its support for the Japanese Zephyr meetup series. At the Nagoya meetup, Nordic provided nRF54L15 DKs to on-site participants, and the Kochi tutorial later used those boards for hands-on exercises. In Sapporo, Nordic development kits and community materials were again available at the venue, helping lower the barrier for participants who wanted to try Zephyr on current wireless SoCs.
Several Topics on Raspberry Pi 5 – @soburi
The first talk, by @soburi, covered several topics around Raspberry Pi 5 PCIe, starting from recent work to boot Zephyr on Raspberry Pi 5.
The session began with the current state of Zephyr bring-up on Raspberry Pi 5. Zephyr was able to boot, and board button interrupts were working. However, the talk quickly moved to a deeper problem: hardware documentation. Broadcom SoC information is not fully public, and many available clues come from Linux source code. Since Linux is GPL-licensed and Zephyr is Apache 2.0-licensed, such material needs to be carefully handled. This led to a discussion of cleanroom-style implementation and the difficulty of supporting real hardware when public documentation is incomplete.
The talk then shifted to PCIe endpoint development. Many developers are familiar with the host side of PCIe, also known as the Root Complex side. The endpoint side is less common, especially when the goal is to write device-side firmware with an RTOS instead of Linux. @soburi explained the Linux Endpoint Framework model, including the separation between endpoint controller and endpoint function, and discussed how similar concepts might be useful for Zephyr.
The session also included a hardware hacking story. @soburi modified open hardware data for an M.2 to OCuLink adapter, keeping the four-layer board structure and 0.8 mm thickness while reducing cost by removing unused parts, moving components to one side, and choosing more readily available connectors and passives. The result was a practical example of how open hardware data can be adapted for experimentation.
Finally, the talk touched on ArduinoCore-Zephyr work for the NXP FRDM-MCXN947 board. To make Arduino header pin definitions usable from Zephyr DeviceTree data, @soburi wrote a large C macro that recursively processes the DeviceTree structure. It was a good reminder that board support often depends on this kind of unglamorous integration work: not just making hardware boot, but making it usable for other developers.
Zenoh on Zephyr on LiteX towards Robot IoT Systems Capable of Rapid Recovery Using 3D-Stacked LSI/FPGA – @takasehideki
Hideki Takase presented a research-oriented session connecting Zephyr, LiteX, Zenoh, and ROS 2.
The background was a research project on robot and IoT systems that can recover quickly from power interruptions, using 3D-stacked LSI/FPGA technology and non-volatile memory. In that context, LiteX provides a flexible way to build custom SoCs on FPGA using Python-based configuration. For this demo, Takase used a Digilent Arty A7 board with a VexRiscv soft core, Ethernet, and Zephyr.
One practical point was the connection between FPGA-generated hardware and Zephyr configuration. When the hardware design changes, the software needs updated DeviceTree and Kconfig information. The talk showed how LiteX-generated configuration data can be converted into Zephyr overlay files, helping keep the hardware and software sides aligned.
Takase then brought up Zenoh-Pico on Zephyr. Zenoh-Pico is the C implementation of Zenoh for constrained environments. Getting it running on Zephyr required work around POSIX compatibility, thread settings, stack sizes, heap size, and network buffers. The demo showed bidirectional Pub/Sub communication between the FPGA board and a host PC through a Zenoh router.
The most memorable part connected the system to ROS 2. By using Zenoh with ROS 2, the board could send accelerometer data and control Turtlesim. This made the architecture easy to understand: Zephyr running on a soft-core FPGA system was not just blinking LEDs. It was participating in a robotics communication flow.
The talk also pointed toward future work around Rust, no_std environments, Zenoh, and embedded ROS 2. For a Zephyr meetup, this was an important theme: Zephyr is increasingly being explored not only as a small RTOS, but as part of larger distributed systems.
Debugging Zephyr: Choosing the Right Tool When Things Go Wrong – @yasushishoji
Yasushi Shoji’s talk focused on a practical question every embedded developer eventually faces: when something goes wrong, which tool should you use first?
The session started with build-time problems. RAM overflows, link-time errors, and DeviceTree mistakes can be difficult to understand, especially when the error message appears far away from the real cause. The talk explained how to approach these failures and introduced DT Doctor as a way to make DeviceTree-related problems easier to inspect.
Logging was another major topic. Zephyr’s default deferred logging mode is useful during normal operation because it reduces immediate runtime cost. However, deferred logs may not appear if the system crashes before the log thread has a chance to print them. Immediate logging is not always the right answer, but it can be valuable during early boot debugging or crash investigation.
The talk also emphasized the Zephyr shell as a practical bridge between software and hardware teams. Shell commands can list devices, inspect kernel threads, check stack usage, control GPIOs, and scan buses such as SPI and I2C. This can turn a firmware image into a board-debugging tool that hardware engineers can use directly.
Shoji also covered simulation and testing. Native Sim allows Zephyr logic to run as a Linux process, where tools such as GDB and Valgrind can be used. QEMU provides another path for testing without physical hardware. Before opening pull requests or relying on CI, Twister can help run tests across many configurations.
The message was simple but important: debugging is not one tool. It is a set of choices. The right tool depends on whether the failure happens at build time, boot time, runtime, on real hardware, or before hardware is even available.
Trying Zephyr in an FPGA Development Competition – @misoji_engineer
@misoji_engineer shared an FPGA development project that used Zephyr as part of a hardware monitoring and control system.
The starting point was heterogeneous FPGA SoCs, where application processors, real-time processors, and programmable logic coexist. On AMD/Xilinx KV260 and KR260 boards, the talk focused on Cortex-R5 real-time cores. These cores are often less visible than the Cortex-A application cores, but they are useful for deterministic control tasks.
In the demo architecture, Linux running on the application side starts Zephyr on the Cortex-R5 side. This creates a practical split: Linux can handle heavier application-level work, while Zephyr can handle real-time control and monitoring.
One interesting example was an AI safety monitor concept. Zephyr running on the real-time side inspected registers of a DPU implemented in the FPGA fabric through AXI. This showed a useful pattern for AI-enabled embedded systems. Zephyr does not need to run the AI model itself to be valuable. It can supervise, monitor, and control the hardware around the AI accelerator.
The talk was also a good example of community inspiration. The speaker described being motivated by space-grade FPGA systems and wanting to reproduce a similar architecture using accessible development boards and personal hardware projects. That connection between professional systems and hobbyist experimentation is one of the strengths of regional meetups.
Trying Zephyr on a Flexible PCB – @misoji_engineer
The next session by @misoji_engineer moved from FPGA systems to flexible hardware.
The project used a flexible printed circuit board designed in KiCad, with a Nordic wireless SoC and sensors, running Zephyr. The board was not only a software demo. It was also a hardware experiment: what happens when Zephyr is put onto a board that bends?
The talk covered several physical design issues. Flexible PCBs are mechanically fragile. Components can peel away, wiring can break, and the parts of the board that need to bend must be treated differently from the parts that hold ICs and connectors. Reinforcement plates were added in selected areas to protect the board while keeping other parts flexible.
Wireless design introduced another challenge. The board used 2.4 GHz BLE, so antenna layout and impedance mattered. Because the ground pattern had to support bending, RF behavior was not as straightforward as on a rigid PCB. Even under those constraints, the board demonstrated BLE operation, DFU, and HID behavior.
This was one of the most visually memorable sessions of the day. It showed that Zephyr can run on hardware very different from a standard evaluation board, but it also showed that firmware portability does not remove the need to consider RF, mechanical, and manufacturing constraints.
Following Zephyr Safety: Joining the WG and Contributing Requirements – @Kurokawa
Harunobu Kurokawa reported on participation in the Zephyr Safety Working Group and the work needed to contribute requirements.
The main topic was safety documentation. Traditional functional safety processes often assume a V-model, where requirements are written first, then implementation and tests follow. Open source projects are different. Mature code and tests may already exist before safety documentation is created.
Kurokawa introduced the Route 3 approach, where requirements are reconstructed from existing mature implementations and connected back to documentation and tests. This is not the most glamorous part of software development, but it is essential if Zephyr is to be used in safety-related domains such as automotive and industrial systems.
The talk also described the human side of the work. The Safety Working Group meets late at night for Japan-based contributors, and there is a shortage of reviewers who understand both software development and functional safety. That combination makes sustained contribution difficult, but also very valuable.
One practical experiment used AI assistants to help compare pull requests, regulations, and documentation. The point was not to replace human review. It was to prepare materials so that expert reviewers could spend more time on judgment and less time on mechanical comparison work.
The Return of Live CFP Submission – @soburi
The final main session brought back a meetup tradition: submitting a conference proposal live in front of the audience.
@soburi used the PCIe endpoint framework topic from earlier in the day as material for a proposal for Open Source Summit Japan (https://events.linuxfoundation.org/open-source-summit-japan/program/cfp/). He drafted an English abstract, refined it with help from ChatGPT, and entered it into Sessionize during the session.
The value of the session was psychological as much as technical. Many engineers have good work to share but hesitate to submit to international conferences, especially in English. By showing the process live, including an imperfect first draft and later edits, the session lowered the barrier for future speakers.
The message was practical: submit first, improve later, and if the proposal is accepted, then prepare the material seriously.
For a local meetup, this was a fitting closing session. It connected the Japanese Zephyr community to the global open source conference circuit and encouraged more people to share their work outside Japan.
Lightning Talk: Implementation of IP driver to SoC – @khayash1
The first issue was licensing. Even when a similar Linux driver exists, GPL-licensed code cannot simply be copied into Zephyr. The implementation needs to be based on specifications and independent work.
The second issue was the phrase “general-purpose.” In practice, IP blocks described as general-purpose may only have been tested in limited vendor environments. During bring-up, assumptions hidden in those environments can appear as hard-coded register values, timing-sensitive behavior, or bugs that only show up on real hardware.
One memorable point was that adding debug output could change timing enough to affect behavior. This is a classic embedded systems problem, and a useful reminder that debugging tools can change the system being debugged.
Photo: The traditional group photo, taken after the last talk.
Social Gathering and Community Weekend
After the talks, the conversation continued at the social gathering. As with many Zephyr meetups in Japan, the most valuable part of the event was not only the formal program, but also the informal discussion around it: hardware bring-up stories, debugging tips, future talk ideas, and plans for upcoming community events.
The Sapporo meetup was also part of a longer open source weekend in Hokkaido. The next day, many participants continued on to Open Source Conference 2026 Hokkaido, held at the Sapporo Industrial Promotion Center. This made the Zephyr meetup feel less like a standalone event and more like the embedded systems gathering point for a broader open source community weekend.
On Sunday, a smaller group visited the Nikka Whisky Yoichi Distillery. It was not a technical session, but it added another memorable Hokkaido element to the weekend. Walking through the distillery, learning about whisky production, and continuing conversations outside the conference room helped strengthen the personal connections that make regional open source communities sustainable.
By the end of the weekend, the meetup had become more than a series of talks. It was a three-day community experience: Zephyr on Friday, open source in Hokkaido on Saturday, and local culture in Yoichi on Sunday.
[Photo: OSC Hokkaido]
Photo: “Open Source Conference Hokkaido” is one of the largest open source events in the region. The Zephyr community participated through exhibitions and presentations, following the Zephyr Project Meetup held the previous day.
Photo: The Zephyr community typically exhibits jointly with the Automotive Grade Linux (AGL) community. Here, too, they showcased a demo in which AGL and Zephyr run side-by-side on the Xen Hypervisor.
Photo: On that day, @yashi performed a live hack on a board displayed at another booth and submitted the results as https://github.com/zephyrproject-rtos/zephyr/pull/112278.
[Photo: Yoichi Distillery visit]
Photo: Yoichi Distillery: About a 90-minute train ride from Sapporo, where the meetup was held.
Photo: A pot still used for distilling whisky. It is wrapped in a rope that signifies it is a sacred space, much like a Japanese shrine.
Photo: Tasting: This is something we simply can’t skip!
Key Takeaways
The Sapporo meetup showed that Zephyr use in Japan is moving beyond simple bring-up demos.
First, Zephyr is being explored on increasingly complex and unusual hardware: Raspberry Pi PCIe, FPGA soft cores, AMD/Xilinx heterogeneous systems, flexible PCBs, wireless SoCs, and custom SoC IP blocks.
Second, the community is now discussing the difficult parts of real deployment. Licensing, cleanroom implementation, DeviceTree complexity, logging behavior, simulation, RF impedance, safety documentation, and test coverage all appeared during the meetup.
Third, the Japanese Zephyr community is contributing in many forms. Code is important, but so are board support, documentation, safety requirements, demos, conference proposals, and local events that connect people across software and hardware disciplines.
Thanks
Thank you to all speakers, attendees, online participants, organizers, and everyone who helped make the Sapporo meetup possible.
Special thanks to Space Cubics for hosting the event, and to the Zephyr Project community for continuing to support regional meetups in Japan.
The Sapporo meetup showed a community that is practical, curious, and increasingly connected to the global Zephyr ecosystem. From PCIe and FPGA systems to safety work and flexible hardware, the event captured what makes Zephyr development exciting: real hardware, real problems, and people willing to share what they learned.
Next Meetup
We are planning our next meetup for November 6 in Kumamoto. Following the July 28 earthquake, we are coordinating closely with local community members and will confirm the event details with safety and recovery conditions in mind. We hope the meetup can provide an opportunity to reconnect with and support the local open source community.
https://zephyr-rtos.connpass.com/event/404251/ (details to be announced)
Links
Zephyr Project Meetup: Sapporo, Japan 2026: https://zephyr-rtos.connpass.com/event/386410/