There's a moment in every embedded project where the excitement hits a wall. You've got your proof-of-concept working beautifully on your development board—maybe a Raspberry Pi, maybe a Jetson dev kit. The AI model is performing well, the interfaces are responsive, stakeholders are excited.
Then someone asks the inevitable question: "Great, now how do we get this into production?"
What follows is usually weeks or months of painful retargeting work. New BSPs, different drivers, modified build configurations, and often a complete rebuild of everything you've already proven works. You're essentially maintaining two different systems: your development environment and your production target.
This is the retargeting tax that embedded teams have been paying for decades.
Today, I want to show you a different way.
Last week, I had one of those moments that reminded me why we built Avocado OS in the first place. I was working with a Raspberry Pi 4 running a computer vision application— a proof-of-concept that demonstrated the core functionality we needed.
But instead of duplicating a bunch of config files, performing hours of rebuilds and manual deploys, I was able to retarget the entire application to a production-ready device in under ten minutes. Same application code, same AI models, same system configuration. The only thing that changed was the hardware target.
The production device? Seeed Studio's reTerminal—an industrial HMI with the same Raspberry Pi 4 compute module at its heart, but wrapped in a touchscreen interface, expanded I/O, and a form factor designed for real-world deployment.
Here's what makes this interesting: Seeed Studio isn't just selling you a dev kit. They're a contract manufacturer. That reTerminal can be customized with your logo, your specific I/O requirements, your enclosure modifications. There's an actual production story here, not just a slightly more polished development board.
The reason this retargeting worked so seamlessly comes down to how Avocado OS handles hardware abstraction and system composition.
Instead of baking everything into a monolithic system image, we use systemd's extension capabilities to create composable, layered filesystems. Your application logic, AI models, and system services exist as separate extensions that can be built for any compatible hardware target.
When I built my computer vision application for the Raspberry Pi 4, I wasn't just creating a custom image—I was creating reusable system extensions that could be deployed anywhere the underlying compute architecture / platform matches.
The reTerminal shares the same ARM64 architecture and Raspberry Pi 4 compute module. From Avocado OS's perspective, it's the same target with different peripherals. The extension system automatically handles the hardware differences while preserving everything that matters: your application logic, your model pipeline, your system configuration.
Every embedded team knows the retargeting pain, but we rarely quantify what it actually costs us.
What if retargeting was so easy that you could treat hardware selection as a late-stage optimization decision rather than an early architectural constraint?
The Raspberry Pi to reTerminal story is compelling because it's concrete and immediate. But the real opportunity is much larger.
This same pattern works across silicon vendors and hardware classes. We're seeing it with NVIDIA Jetson dev kits moving to Advantech industrial cameras. We're building it for NXP evaluation boards moving to production SOMs and gateways. The pattern scales because the underlying challenge is universal: how do you preserve your software investment while adapting to production hardware requirements?
The key insight is that most retargeting complexity is artificial. We've been rebuilding everything because our tools forced us to, not because the underlying software actually needed to change.
When you separate your application logic from your hardware-specific configuration, when you compose systems from reusable extensions rather than monolithic images, retargeting becomes a configuration change rather than a development project.
This approach doesn't just benefit product teams—it fundamentally changes the value proposition for silicon vendors.
Today, silicon companies invest heavily in creating development boards and evaluation kits, but they struggle to provide a clear path from evaluation to production. Customers get excited about the dev kit experience, then get frustrated when production deployment feels like starting over.
With composable system architectures, silicon vendors can offer continuity across their entire ecosystem. The same software stack that works on your evaluation board works on your production SOM. The same development tools, the same debugging interfaces, the same update mechanisms.
This creates a stickiness that traditional embedded approaches can't match. Instead of competing purely on hardware specs, you're competing on the total developer experience from evaluation through production deployment.
The Raspberry Pi to reTerminal demo is just the beginning. Over the next few weeks, we'll be expanding this retargeting story across multiple silicon platforms and form factors.
We're working on NVIDIA Jetson to Advantech industrial cameras—same AI inference capabilities, production-ready packaging. We're building support for NXP platforms that let you move from evaluation boards to industrial gateways. We’re extending Raspberry Pi to production gateways like OnLogic’s FR201. We're exploring partnerships with SOM manufacturers who can provide the production scalability that startups and enterprises need.
The goal isn't just to support more hardware—it's to eliminate the artificial boundaries between development and production that have been constraining embedded innovation for too long.
Here's what gets me most excited about this approach: it fundamentally changes how fast teams can iterate.
When retargeting is easy, you can experiment with different hardware configurations throughout your development cycle. You can optimize for different price points, different performance profiles, different form factors—all without throwing away your software investment.
You can pursue multiple hardware strategies in parallel. Start with a Pi 4 for rapid prototyping, evaluate a Jetson for AI performance, test an industrial gateway for production deployment—all while maintaining the same application codebase.
You can make hardware decisions based on real data rather than early estimates. Build your MVP, measure actual performance requirements, then optimize your hardware selection based on what you've learned.
This kind of flexibility isn't just about individual projects—it's about changing how we approach embedded product development entirely.
The development-to-production gap has been an accepted reality in embedded development for too long. But it doesn't have to be.
If you're tired of maintaining parallel development and production systems, if you want to treat hardware selection as an optimization rather than a constraint, if you believe embedded development should be as agile as any other software discipline—this is for you.
The Raspberry Pi to reTerminal demo is live in our developer center, complete with step-by-step documentation and video walkthroughs. But more importantly, it's a proof point for a different way of thinking about embedded systems.
The future of embedded development isn't about choosing between development velocity and production readiness. It's about having both. 🥑
—Justin
---
Want to see the retargeting story in action? We’ll be going live on YouTube on Aug. 22nd @ 1pm ET - don’t miss it!