slashwhy develops firmware for microcontroller-based products, from architecture to automated testing.
Firmware development is a core part of embedded software development: the hardware-related software that controls a device's peripherals, communication interfaces, and control logic. slashwhy handles this part end to end, from software architecture and feature implementation to automated unit, integration, and system testing.
Firmware is one of five embedded disciplines that slashwhy supports as a service partner. Depending on the product, Embedded Linux, real-time applications, IoT and cloud connectivity, or graphical user interfaces come into play. These disciplines interconnect in many projects. We know how they fit together and can deliver both focused firmware projects and the integration into a larger system context.
We work with the most widely used microcontroller families in the embedded space, such as STMicroelectronics (STM32), Espressif (ESP32), and Nordic Semiconductor (nRF5x). Across many projects, we have worked with a wide range of controllers. The choice of platform directly shapes every architecture decision, which is why this knowledge is a core part of firmware development for us.
Whether bare metal, a real-time operating system (RTOS), or Embedded Linux: we choose the execution environment together with you, based on your specific requirements, such as real-time behavior, power consumption, and complexity. The result is a reasoned, tailored decision rather than a one-size-fits-all answer for every customer.
Cyber security is increasingly becoming a must in firmware projects. With the Cyber Resilience Act (CRA) taking effect in 2027, many embedded products will have to meet specific security requirements. slashwhy knows the relevant requirements and factors them in from the start. Functional safety is a topic in its own right, with formal certification requirements. Where it matters, we address it early.
Interested? Then you'll find everything you need to know about slashwhy as a firmware development partner right here on this page.
Your starting point
Most companies that come to slashwhy already have the hardware. What's missing is the software. Without an experienced partner, this tends to create familiar problems: firmware architecture that doesn't fully account for the hardware's limitations, narrowing the room for later adjustments. Software that grows too large and forces a more expensive controller, or in the worst case makes a hardware revision necessary. Or a codebase that has grown over time, blocking new features and producing unexpected side effects with every change.
slashwhy brings embedded experience from many projects. We know the decisions that have to be made early, and we know the consequences they carry. This keeps the architecture maintainable and avoids follow-up costs that only surface later. The four most common situations in which customers reach out to slashwhy:
We define the module structure, choose the execution environment, and lay the foundation for maintainable, extensible code before the first line is implemented. A well-thought-out architecture determines how quickly new features can be added later, and whether the firmware fits on the planned hardware or forces a more expensive controller.
We implement the functionality you need: cleanly structured, documented, and tuned to the target hardware. We work iteratively and review the scope with you regularly. That keeps requirements and implementation in sync, even when things change over the course of the project.
Where it makes sense, we integrate a bootloader and a real-time operating system (RTOS) such as FreeRTOS or Zephyr as part of the firmware architecture. The bootloader enables secure updates without physical access to the device. The RTOS structures concurrent tasks and makes the firmware more scalable and maintainable.
We connect sensors, actuators, and communication interfaces: I2C, SPI, UART, CAN, Bluetooth, WiFi, and more. Connecting peripherals is one of the most error-prone parts of firmware development. Clean drivers and clear abstraction layers (HAL) make sure that hardware changes don't later affect the entire codebase.
We prepare the firmware for secure updates, locally or over-the-air (OTA), depending on the product requirements. A well-thought-out update strategy matters especially for devices in the field: it enables bug fixes and new features without a recall, and under the Cyber Resilience Act (CRA) it becomes mandatory for many product categories from 2027.
Unit, integration, and system tests are a fixed part of our development process and are automated wherever it's useful and feasible. Firmware that goes into production untested produces bugs that are more expensive to fix in the field than during development, and in the worst case lead to product recalls.
Many firmware projects come with security requirements, both on the functional safety side and on the cyber security side. slashwhy knows the relevant requirements and factors them into the project: in the architecture, the update strategy, and the peripheral integration. For projects with formal certification requirements under IEC 61508 or ISO 26262, we work closely with the customer. The certification itself stays with the customer or a specialized partner.
When a hardware platform is being changed, a controller is being discontinued, or existing firmware needs to be ported to a new MCU, we take over the migration. We analyze the existing codebase, identify platform-specific dependencies, and port the firmware to the target platform in a structured way. This includes RTOS migrations as well as refactoring legacy code that has grown over the years.
Firmware development is a discipline where you have to understand both worlds: you can't just write code and hope the hardware plays along. You need to know what's happening on the circuit traces, what the schematic is telling you, and where the hardware development on the customer's side might have gone wrong. That's what makes it demanding and, honestly, deeply satisfying when it all comes together.
Dr. Joachim Wilharm
Managing Director at slashwhy
Our platform expertise
slashwhy develops firmware for the most common microcontroller families in the embedded space. Customers bring their hardware, we bring the platform experience to the project. That means no ramp-up time at your expense, no avoidable beginner's mistakes, and an architecture that fits the target hardware from the start. The platforms we work with most often:
The STM32 is one of the most common microcontroller families in industrial and consumer projects. slashwhy develops firmware across the entire STM32 line: for control units in agricultural machinery, household appliances, and industrial equipment, as well as for IoT sensors and Bluetooth devices. Its mature ecosystem, with solid toolchain support and extensive documentation, saves development time and reduces sources of error.
The ESP32 combines microcontroller functions with integrated WiFi and Bluetooth on a single chip, making it a first choice for connected IoT devices because it simplifies the board design and lowers hardware costs. slashwhy develops firmware for ESP32-based products: from connected sensors and smart home actuators to industrial gateway solutions, on both ARM and RISC-V architectures.
The nRF5x family is optimized for minimal power consumption and supports Bluetooth Low Energy (BLE), Thread, and Zigbee. slashwhy develops firmware for nRF5x-based devices: Bluetooth accessories, location trackers, heat cost allocators, and wireless sensors where battery life and radio reliability are critical.
Some projects come with a platform outside the three families above. When that happens, slashwhy gets up to speed on it. Architecture principles, peripheral integration, and test strategies carry over across platforms. What changes is the specific toolchain and the specific registers.
Programming languages: C, C++, Rust
RTOS: FreeRTOS, Zephyr
Tools: GCC, CMake, Git, JTAG debuggers, in-circuit emulators
Wired: I2C, SPI, UART, CAN, RS232, RS485, Ethernet, USB
Wireless: Bluetooth, BLE, WiFi, ZigBee, Thread, Matter, LoRaWAN
slashwhy works in both models. We either take over the firmware part completely or integrate as an extended team directly into your existing team. In the latter case, we work closely with your developers, align on architecture and code conventions, and adapt to your existing processes and tools. Which model makes sense is something we figure out together at the start.
It depends on the task. For early development phases, we can also start with development boards (dev kits), and slashwhy helps pick the right one. As soon as there's a first customer board, we step in, even if it's still a functional prototype. Hardware revisions during development are normal and not an obstacle. What we need is a defined hardware base we can develop and test on. We don't take on custom hardware development ourselves; we're the development partner for custom software.
Follow-up contracts for bug fixes and new features are possible. What slashwhy doesn't offer is maintenance contracts for ongoing operations. If you need continuous support for running your product, it's best to raise it early so we can work out together what makes sense.
Through clean documentation, structured code, and iterative reviews with the customer throughout the entire project. The code and all artifacts belong to the customer. The goal is always firmware that can be developed further even without slashwhy, whether by your team or another partner.
Yes. Besides firmware, slashwhy also develops apps, cloud backends, and IoT integrations. For the customer, that means a single point of contact for all software layers of the product, without things getting lost at the hand-offs between different providers. Which services you actually need is something we clarify in a first conversation.
Intuitive operation through a modern UI matters a lot to us. Our customers shouldn't have to wrestle with the technology, they should have fun with the products and the application.
Oliver Kortekamp
Team Leader & PO at Oase
We always feel that slashwhy takes ownership of the product. Everyone involved fully identifies with it. That's different with other service providers.
Dr. Melanie Schuh
Product Management at W&H
With slashwhy, we have a partner that doesn't just deliver code, but supports the entire process from concept to implementation, a partner that identifies with the product and actively improves it.
Friedrich Laube
Director Digital Products & Services Smart Home at Miele
The agile mindset of everyone on the slashwhy project team is impressive and contagious in the best way. We work with slashwhy as equals in agile project teams and reach our goals together, faster.
Markus Rose
Director CHARX control Division Charging Infrastructure at Phoenix Contact
The big benefit of the solution we developed with slashwhy is that we can continue developing our production products in parallel with new development projects.
Axel Schröder
Director Advanced Engineering at CLAAS E-Systems
We can save a completed commissioning in the app and, especially on large construction projects, reuse that template again and again to set up identical gates. That's a clear advantage and a real benefit of the app.
Tobias Lange
Projectmanager at Hörmann
Resource optimization
A wireless sensor that needs new batteries every three months is hard to sell. Firmware that's too large forces a more expensive controller, and that cost hits every unit you produce. slashwhy solves both problems through structured power optimization and the targeted reduction of wasted resources directly in the firmware.
We factor energy efficiency into the architecture decision from the start. Start too late and you pay for it in more expensive hardware, shorter battery life, or costly rework. That's why we keep an eye on these levers from day one.
We measure power consumption at runtime and map it to individual program states, so we can intervene where it counts.
We reduce clock rates to the necessary minimum, because every unnecessary CPU cycle costs power.
We actively switch off peripherals that aren't needed, instead of leaving them in standby permanently.
We maximize sleep times and put the controller into low-power mode as often and as long as possible.
Where the hardware offers low-power coprocessors, we use them to take load off the main processing unit.
We run runtime analyses to identify compute-time bottlenecks that keep the controller busy longer than necessary.
We analyze static memory usage and reduce it in a targeted way.
We reduce code size so the firmware fits on smaller, more affordable controllers and lowers the per-unit hardware cost.
Nice to know
The most cost-effective controller is the one whose firmware is efficient enough that you never need a bigger one. Every line of code that unnecessarily takes up memory or wastes CPU cycles drives up the per-unit hardware cost, in every single unit you produce. At quantities in the five-figure range, that adds up fast. That's why at slashwhy, resource efficiency feeds into every architecture decision from the start.
Our approach
Every firmware project is different. The hardware is different, the requirements are different, and the customer's starting situation is different. What stays the same is the way we work: iteratively and with regular reviews. So the following steps don't describe a rigid sequence, because architecture decisions get refined over the course of the project, requirements change, and hardware revisions happen. In each of these moments, we stay adaptable and keep working in an agile way.
1 | Analyzing hardware and requirements
We read schematics, clarify pin assignments and hardware behavior, and work out a clear feature scope together with the customer. Where there's no final hardware yet, we work with eval boards and build technical spikes, meaning first working implementations that show whether a component, a sensor, or a communication protocol behaves as expected.
2 | Defining the architecture
We define a first architecture: execution environment, module structure, and the boundaries between firmware, drivers, and application. These decisions are a starting point. As our understanding of the project grows, we refine them iteratively.
3 | Iterative development with testing built in
We implement the feature scope in iterations. Unit and integration tests run alongside development, not at the end. After each iteration, there's a review with the customer. Insights from development feed back in, sometimes into the requirements, sometimes into the architecture. The result is firmware that fits the hardware and the product perfectly.
4 | System testing and acceptance
We test the firmware on real hardware under real conditions. Edge cases, error states, communication flows: all of it is checked systematically before the code goes into production.
5 | Handover, documentation, and next steps
The finished code is handed over and documented. Follow-up contracts for bug fixes and new features are possible. If the product also needs an app, a cloud connection, or a graphical user interface, slashwhy can handle that seamlessly, without things getting lost at the hand-offs between different providers.
A bug that costs an hour in development costs a week in the field, or even a product recall. That's why at slashwhy, testing is a fixed part of our development process and of every iteration. Unit tests, integration tests, and system tests run alongside development. Every line of code we ship is tested accordingly.
Working together
We build software by people, for people. And all these people have very different needs. Users want to solve their tasks efficiently; our customers want to create real value. And us? We want to design software that solves real challenges, makes everyday work simpler, and is fun to use.
Global players and hidden champions
slashwhy develops firmware for control units in agricultural machinery, industrial equipment, and vehicles, for household appliances like washing machines, dryers, and cooktops, for wireless IoT sensors and actuators, and for Bluetooth accessories like headphones, location trackers, and audio products. In the energy sector, we develop firmware for energy management systems and charging infrastructure. In medical technology and healthcare, we work on devices with heightened requirements for reliability and safety. Our customers come from AgriTech, Consumer Electronics, Industry, Building Technology, CleanTech, and HealthTech, from hidden champions to global players like CLAAS, Miele, and Phoenix Contact.
There's no one-size-fits-all answer here. It depends on too many factors. What matters most is the complexity of the hardware, the scope of the features you want, the choice of execution environment, the testing effort, and whether an existing codebase is being developed further or started from scratch. A manageable project for a single microcontroller with clearly defined functions is a different scale of effort than firmware for a connected device with OTA updates, multiple communication interfaces, and security requirements. The fastest route to a realistic estimate is a first conversation where we go through the requirements together.
With bare metal, the code runs directly on the microcontroller, without an operating system. The main loop and interrupt service routines control the flow. This is the right choice for deterministic control tasks with strict real-time requirements and for low-power applications where every CPU cycle counts. An RTOS makes sense when several concurrent tasks need to be coordinated and a clean task structure significantly improves maintainability. The decision depends on the specific requirements, such as real-time behavior, complexity, and power consumption, and at slashwhy it's made deliberately and with clear reasoning.
C is the dominant language in firmware development. It offers direct hardware control and minimal overhead, and it's available on almost every microcontroller platform. C++ is used where object-oriented structures make the codebase more maintainable. Rust is gaining importance in firmware development: its language design catches memory errors already at compile time. That's a real advantage over C, where memory errors account for a large share of bugs. slashwhy develops primarily in C and C++. Where it makes sense, we deliberately optimize code so the compiler can translate it more efficiently.
Firmware in the narrow sense runs directly on the microcontroller, without an operating system as an intermediary. Embedded Linux means that a full Linux operating system runs on the hardware, with the application running on top of it. Embedded Linux is the right choice when the application needs network stacks, file systems, or complex user interfaces, and the hardware is sufficiently powerful for it. For simpler control tasks, low power consumption, or strict real-time requirements, classic firmware is the better choice.
That depends heavily on the scope. A manageable project with a clearly defined feature scope can be finished in a few weeks. More complex projects with multiple communication interfaces, RTOS integration, OTA updates, and extensive testing take several months. What matters most is that the architecture and requirements are clearly defined from the start, that's the biggest lever for predictable development timelines. In many cases, we can give a first estimate after an initial conversation about the specific requirements.
Do you already have a concrete project idea and want to find out whether slashwhy is the right embedded partner for your firmware development? Or are you still at the start of your journey, looking for the ideal starting point? Either way, our team of experts would love to hear from you and is happy to offer a no-obligation consultation.
slashwhy is a German software development partner with locations in Osnabrück, Hamburg, Bielefeld, and Kiel. Firmware development is one part of our embedded expertise, alongside Embedded Linux, real-time applications, IoT & cloud integration, and graphical user interfaces for embedded systems. Embedded, in turn, is one of six disciplines at slashwhy: if you also need UX & UI design, application development for mobile, web, and desktop, IoT & cloud, or AI-driven solutions alongside firmware, you'll find in slashwhy a reliable development partner for the entire product.
In firmware development, we take over the complete development of microcontroller-based products, from software architecture and feature implementation to automated unit, integration, and system testing. Our expertise covers bare-metal development, RTOS integration with FreeRTOS and Zephyr, bootloaders, OTA update strategies, and the integration of wired and wireless communication interfaces. We work with ARM-based controllers from STMicroelectronics, Espressif, and Nordic Semiconductor, as well as with RISC-V architectures.
Companies work with slashwhy when internal capacity is short, the necessary embedded expertise isn't available in-house, or existing firmware needs to be migrated to a new platform. Our customers come from sectors like AgriTech, Consumer Electronics, Industry, Building Technology, CleanTech, and HealthTech, from hidden champions to global players like CLAAS, Miele, and Phoenix Contact.
