slashwhy develops time-critical embedded software for sensors, control systems, and actuators.
slashwhy develops time-critical embedded software for control systems, sensors, and actuators, both bare-metal on microcontrollers and RTOS-based. We take over development once the hardware platform and HAL are in place, and get the actual functionality up and running.
Real-time isn't about doing something especially fast. It's about doing it within a guaranteed, defined time window, regardless of system load or concurrent tasks. How tight that window needs to be depends directly on the potential harm: systems that protect people have tougher requirements than systems where only product quality is at stake.
Whether a project needs a real-time operating system (RTOS) like FreeRTOS or Zephyr, or whether bare-metal is the right choice, is something we decide together with you early in the project, based on the timing requirements, hardware resources, and expected system complexity. Switching to an RTOS later would mean refactoring.
Real-time application development is part of slashwhy's embedded software portfolio. Depending on the project, we also bring in our experts for embedded Linux, IoT and cloud integration, firmware development, and graphical user interfaces, whenever a system needs connectivity or a display alongside its time-critical functions.
Interested? On this page, you'll find everything about slashwhy as your partner for real-time application development.
Your starting point
Real-time is a requirement placed on an application, not a property of a technology. A system has what we call real-time requirements when a missed deadline leads to a defined kind of harm, not because it needs to be especially fast. How hard that requirement is depends directly on the potential harm: a safety switch that fails to stop a running motor in time can put people at risk. A control cycle that runs too late can destroy a workpiece. An audio output that's off by a few milliseconds disrupts the user experience. All three are real-time applications, with very different consequences for architecture, technology choice, and depth of testing.
Companies develop real-time applications with slashwhy when their product has to respond to specific events within a defined time window and under real operating conditions. The starting points vary, but the underlying question is always the same: what happens if the system responds too late?
Every real-time project begins with one question: what happens if a deadline isn't met? Together with the customer, we clarify the specific timing requirements, distinguish between hard and soft real-time, and derive the right system architecture from that. On that basis, we decide whether bare-metal or a real-time operating system (RTOS) is the right choice, and if RTOS, which one. We make that decision early, because switching later means a complete refactoring. The licensing model, community support, and the specific hardware platform factor into the decision just as much as the functional requirements.
We define the system's task structure: which tasks run concurrently, what priorities they get, and how higher-priority tasks preempt lower ones. Poorly planned scheduling is one of the most common causes of timing violations in growing systems. We design the priority hierarchy so that the available time window for task execution, what we call the timing budget, is met even as the feature set grows.
Concurrent tasks need to exchange data and coordinate resources without blocking each other. We implement the right synchronization mechanisms (such as semaphores, mutexes, or message queues) depending on what the system's communication pattern requires. Deadlocks and race conditions come from bad design, not bad luck. We prevent them with a clean resource architecture from the start.
Real-time applications respond to events, such as signals from sensors, switches, or external systems. We implement the interrupt handling so that interrupt service routines (ISRs) stay short and deterministic, and compute-intensive processing steps are offloaded to tasks. On the actuator side, we drive relays, motors, and other output devices so that the response chain from input to output runs within the available time window.
We analyze the system's timing behavior under real operating conditions. That includes looking at the worst-case execution time (WCET) of critical tasks and measuring interrupt latencies and jitter. When the timing budget gets tight, we identify the bottlenecks and optimize where it counts: by adjusting task priorities, reducing context-switch overhead, or moving computations elsewhere. Systems that behave differently under load than they do in testing are a common problem in projects that have grown over time. We make the timing behavior measurable and traceable.
Debugging real-time systems is fundamentally different from debugging regular embedded software. An attached debugger changes the system's timing behavior: bugs that show up in normal operation sometimes can't be reproduced under debugging conditions. The same goes for logging output. We rely on methods that affect the system's behavior as little as possible: hardware tracing, minimally invasive logging, and targeted timing measurements via dedicated debug pins. We track down deadlocks and race conditions systematically.
Sometimes the RTOS in an existing system is no longer the right choice, for example because license costs are rising, vendor support is ending, or the platform is changing. We handle the migration from proprietary or outdated RTOS solutions to modern open-source systems like FreeRTOS or Zephyr. That includes analyzing the existing system, redefining the task structure on the target platform, and porting the functionality step by step.
RTOS: FreeRTOS, Zephyr; proprietary systems on customer request
Bare-metal: ARM Cortex-M (STM32, NXP, Nordic)
Languages: C, C++, Rust
Debugging & tracing: SEGGER J-Link, JTAG, SWD, hardware tracing, Percepio Tracealyzer, debug-pin measurements
IDEs & toolchains: STM32CubeIDE, IAR Embedded Workbench, Keil MDK, GCC
HAL integration: platform-specific, vendor-independent development
Customized real-time applications are highly sophisticated systems. We are happy to work with our customers to identify their actual requirements. As a technology and development partner, we provide reliable and tailored advice in this area.
Dr. Joachim Wilharm
Managing Director at slashwhy
Our fundamental questions
Before slashwhy writes a single line of time-critical code, we ask three questions. The answers shape the architecture, the technology choice, and the testing effort for the entire project. These decisions come early and are hard to undo. We make these decisions together with the customer, based on the specific product and project requirements.
The first question determines everything else. With hard real-time, a missed deadline is a system failure, with potentially safety-critical consequences for people or machines. With soft real-time, a delay leads to a measurable drop in quality, but not a failure. We work out this classification together with the customer, around one concrete question: what happens if the system responds too late? The answer determines the architectural depth, the testing requirements, and how tight the timing specification needs to be.
For a system with a few clearly defined tasks and limited hardware resources, bare-metal is often the better choice. As soon as the system gets more complex and has to coordinate several concurrent tasks, an RTOS makes more sense. We make this decision based on the system complexity, the available hardware resources, and the question of how the product should grow in the future.
Once we've decided on an RTOS, the next question follows: FreeRTOS, Zephyr, or a proprietary system? FreeRTOS is mature, widely used, and has a large community, but when problems come up, you have to dig into the source code yourself. Zephyr offers a more modern architecture and broad hardware support, but it's younger. Proprietary systems like VxWorks or QNX come with commercial support, but they tie the customer to license costs and vendor lock-in. If the customer already has an RTOS in place, we evaluate together whether it meets the requirements.
We come in once the hardware platform and hardware abstraction layer (HAL) are in place. We don't do board bring-up or hardware development, that's in better hands with the manufacturer or a specialized hardware partner. From the point where the hardware is running and it comes down to the actual functionality, we take over: scheduling, interrupt handling, task design, and the integration of sensors and actuators.
Both are possible. If the customer already uses an RTOS, we build on that, provided it meets the project's requirements. If we choose an RTOS together, the licensing model, community support, hardware support, and the specific system complexity all factor into the decision.
That's one of the central challenges in real-time systems. An attached debugger changes the system's timing behavior, and bugs that appear during operation sometimes disappear under debugging conditions. That's why we work with minimally invasive methods: hardware tracing, targeted timing measurements via debug pins, and stress tests under real load. We make timing problems measurable before we fix them.
That's a familiar problem in real-time systems that have grown over time. More features, more tasks, the same microcontroller. At some point, deadlines might start getting missed as requirements grow. At handover, we document the task structure, the scheduling, and the timing measurements so that your internal team or a future partner knows where the available time window could get tight. If the system needs support after handover, we're here as your point of contact.
With hard real-time requirements, a missed deadline is a system failure with potentially serious consequences. With soft real-time requirements, a delay leads to a drop in quality, such as stuttering in audio or video processing, but not a failure. The two scenarios call for different architectures and decision logic.
Nice to know
With PREEMPT_RT, you can configure the Linux kernel to meet soft and, within limits, hard real-time requirements. That's relevant for systems that need a network stack, file system, or graphical interface alongside their time-critical functions, and run on more powerful hardware. For purely soft real-time requirements, a standard Linux kernel is often enough. PREEMPT_RT Linux isn't a replacement for a dedicated RTOS when safety requirements are hard, but for many industrial applications it's a pragmatic alternative. The decision depends on the specific latency requirements and the target platform.
Our approach
Every real-time project is different. The hardware platform, the criticality of the requirements, and the maturity of the existing system shape what a project at slashwhy actually looks like. The process below describes the basic approach.
1 | Clarify requirements and define the architecture
We start with the timing requirements, not with the technology. What happens if a deadline isn't met? How often does an event occur, and how long can the response take? We always look at the whole system: for control tasks, the inertia of the actuators is part of that picture too. Based on these answers, we distinguish between hard and soft real-time and decide whether bare-metal or an RTOS is the right architecture. We make this decision right at the start of the project, because it shapes every step that follows. Switching later means refactoring.
2 | Design the task structure and scheduling
We define which tasks the system runs concurrently, what priorities they get, and how they communicate with each other. That includes defining interrupt service routines, setting the synchronization mechanisms, and making a first estimate of the worst-case execution time of critical tasks. Because bad scheduling is hard to correct, we plan it carefully before we implement.
3 | Implementation and integration
We implement the control logic, connect sensors and actuators, and integrate the software on the target platform. If the customer brings an existing RTOS, we build on that. If we've selected an RTOS together, we handle the configuration and integration of the kernel. The implementation follows the task structure defined in step 2. We document any deviations from it and assess their impact on the timing.
4 | Timing analysis and debugging
We measure the system's timing behavior under real operating conditions. We test interrupt latencies, jitter, and context-switch overhead under peak load. Timing problems that don't show up under normal conditions often only appear under load. Since an attached debugger changes the timing behavior, we rely on minimally invasive methods: hardware tracing and targeted measurements via debug pins.
5 | Handover, documentation, and next steps
We hand over working, tested software with complete documentation of the task structure, the scheduling, and the timing measurements. This gives the customer a foundation that their own team, another partner, or the slashwhy team can build on. If the product also needs an app, cloud connectivity, or a graphical user interface, for example, we can take that on seamlessly, without things getting lost at the hand-offs between different partners.
When time-critical software works in the nominal case, that's far from a guarantee for real-world use in the field. Real-time systems typically fail under conditions that don't show up in normal testing, such as peak load, aperiodic events, or after long run times. So we don't just test whether the system produces correct results, but whether it does so within the defined time windows, consistently, and under real operating conditions.
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
Working with us
We build software by people, for people. And all these people have very different needs. Users want to get their tasks done efficiently, our customers want to create real value. And us? We want to create software that solves real challenges, makes everyday life easier, and is fun to use.
Global players and hidden champions
Real-time requirements arise wherever software meets physical processes and a delayed response has consequences. In industrial automation, these are control systems that read sensors cyclically and drive actuators at defined points in time. In agricultural machinery, these are control units that have to respond reliably and deterministically under harsh field conditions. In medical technology, requirements are hard, because a missed deadline can mean harm to people. In consumer electronics and building technology, the requirements are softer, but latency and jitter directly affect product quality and the user experience. slashwhy works across industries with various market leaders. What always remains is the underlying question of every project: what happens if the system responds too late?
A regular operating system like Windows or standard Linux is optimized for throughput and usability. It tries to distribute resources as efficiently as possible, but it gives no guarantees about response times. A real-time operating system (RTOS) guarantees that a defined action will be completed by a specified point in time. The difference isn't speed, it's predictability. An RTOS can be slower than a general-purpose OS, but it's deterministic.
Bare-metal means the software runs directly on the hardware, without an operating system. You have maximum control over the timing behavior, and there's no operating system overhead. That makes sense for simple systems with a few clearly defined tasks. An RTOS comes with a scheduler, task management, and synchronization mechanisms. Especially in complex systems, that brings advantages in maintainability and structure, but it adds overhead. The choice depends on the system complexity, the hardware resources, and the question of how the system should grow in the future.
FreeRTOS is one of the most widely used open-source real-time operating systems for microcontrollers. It's lightweight, well documented, and supports a large number of hardware platforms. The MIT license allows commercial use without license fees. FreeRTOS is a good fit for systems with moderate complexity, several concurrent tasks, and limited hardware resources. For systems with IoT connectivity and broad hardware support, Zephyr is an increasingly relevant alternative.
In this context, determinism means that a system's timing behavior is predictable. A deterministic system always delivers the same response time under the same conditions. In practice, that means: interrupt latencies have an upper bound, context-switch times are known, and the worst-case execution time of critical tasks can be calculated. No real system is perfectly deterministic.
But a well-designed real-time system is deterministic enough to meet deadlines under all defined operating conditions. Memory management is part of that: in the time-critical runtime path, real-time systems avoid dynamic memory allocation with default behavior, because it can cause unpredictable delays. So memory is usually reserved during the initialization phase or allocated statically from the start. Where dynamic allocation at runtime is still necessary, deterministic allocators with a guaranteed worst-case time come into play.
Do you already have a concrete project idea and want to find out whether slashwhy is the right embedded partner for real-time applications for you? Or are you still at the beginning of your journey and looking for the ideal starting point? Either way, our team of experts would love to hear from you and is here for a no-obligation consultation.
slashwhy develops time-critical embedded software for control systems, sensors, and actuators, both bare-metal on microcontrollers and RTOS-based. As a partner for real-time applications, we take over development from the point where the hardware platform and HAL are in place. We get the actual functionality up and running: scheduling, interrupt handling, task design, and the integration of time-critical control logic.
Real-time systems come with different requirements than regular embedded software. The distinction between hard real-time and soft real-time shapes the architecture, the depth of testing, and the technology choice. Whether a project needs a real-time operating system like FreeRTOS or Zephyr, or whether bare-metal is the right decision, is something we work out early in the project, based on the specific timing requirements and the expected system complexity.
Time-critical software development is harder to debug than regular embedded development. We work with minimally invasive methods like hardware tracing, timing analysis under real load, and targeted measurements via debug pins. We make the timing behavior of real-time systems measurable and traceable.
Real-time applications are part of slashwhy's embedded software portfolio. When a time-critical system needs connectivity or a cloud connection alongside control logic, we cover that with our own teams for embedded Linux and IoT and cloud integration. If the product also needs a graphical user interface or an app, our embedded teams work directly with our colleagues from UX & UI design and application development. For companies that want to develop digital products end-to-end, that makes slashwhy a single point of contact across the entire stack.
Our customers come from industries where time-critical control logic is at the core of the product: industrial automation, AgriTech, HealthTech, CleanTech, and consumer electronics. What they share is the underlying question of every real-time project: what happens if the system responds too late? slashwhy develops at four locations in Germany as a direct point of contact for complex real-time systems, without nearshore risks and without coordination overhead across borders.
