We design the behavior of the device

Embedded software and embedded system development

We develop embedded software that reads sensors, controls motors and outputs, and communicates with other devices. We select a microcontroller or embedded Linux architecture according to timing, memory, energy and fault behaviour requirements. For your new board or existing device, we define the firmware development scope together with the hardware, test the specified functions and deliver the source code and build information.

Dedicated control board with debug probe and sensor connections for embedded software testing
Representative application image.
LayerFrom driver to application
IntegrationHardware + communication
FocusPredictable device behavior

Your project, your product

Developed confidentially and delivered with source files.

We may work with a confidentiality agreement (NDA) before sharing technical details. At the end of the project, we deliver the source codes, design files and technical documents we have developed to you.

  • NDA before sharing technical information
  • Clear deliverables agreed at the outset
  • Source and technical files at the end of the project
Our confidentiality and delivery process

VOMRO engineering approach

We develop the software on the board and in the real scenario.

Embedded software operates within different constraints from a desktop application. Processor time, memory, energy and peripheral timing are limited. Regular sensor sampling, stopping a motor on time and moving the device to a defined state after communication loss affect the entire system. VOMRO builds the software architecture around the priorities of these functions.

Just as we can develop software for a new electronic circuit board, we can also evaluate the improvement of an existing device. Initially, the schema, processor, source code, protocols used and known problems are examined. Once the right to use existing software and documentation and the scope of delivery are clarified, a sustainable development plan is prepared.

01

Driver, control and timing in embedded system design

In microcontroller applications based on C/C++, startup code, peripheral drivers, communication and product functions are organized in separate layers. If there is a need for embedded Linux, the operating system, application and device connections are evaluated together. A structure that does not require rewriting the entire application when the processor or board revision changes is targeted.

Depending on the timing need, loop-based structure, interrupts, state machines or real-time operating system options are evaluated. Task priorities and resource allocation are determined by the behavior of the product. Adding more software layers alone is not a measure of quality; It is important that the structure is traceable and testable.

  • Peripheral and sensor drivers
  • State machines and control functions
  • Processor, memory and timing budget
Engineer working with laptop in wired test rig
Engineering study on computer-aided system examination and test setup.
02

Communication, recording and update infrastructure

Communication layers, from in-board interfaces such as I²C, SPI and UART to CAN, RS485, Ethernet and wireless connections, are developed according to the needs of the project. The format of data packets, timeout, retry and error codes are defined. Thus, the device and the upper system interpret the same message in the same sense.

Parameter storage, event logging, device ID and software version simplify the service process. If a local or remote update is required, the boot loader, version control, authorization, and recovery design are evaluated. The update method is selected according to the memory capacity and connection possibilities of the hardware.

  • Device protocols and data model
  • Persistent parameter and event records
  • Software update flow suitable for the project
Wired communication and software testing between two custom embedded control boards
Representative application image.
03

Error states are also a function of the product

We define how the software responds to sensor disconnection, low supply voltage, unexpected restarts and communication loss. Watchdog operation, data validation and error handling are tested through relevant scenarios, rather than merely included in code. Initial and fault states of control outputs are addressed together with the hardware design.

At the end of the project, we deliver the source code, build configuration, programming outputs, protocol descriptions and release notes. The delivery list becomes clear at the beginning. Test findings are associated with specific hardware and software revision; A problem coming from the field can be examined based on which version and under what conditions it occurred.

  • Function and error scenario tests
  • First run with hardware
  • Organising version and build information
Embedded software architecture combining microcontroller, sensor, communication and control functions
Conceptual representation of the technical process.

How it works

A clear process from start to delivery.

Not every project looks the same; however, the measurable requirement, controlled revision, and field verification steps remain unchanged.

  1. 01

    We define behavior

    We document functions, timing, connections and error conditions.

  2. 02

    We build the infrastructure

    We verify drivers, task structure, and communication interfaces with hardware.

  3. 03

    We develop the application

    We gradually combine control, measurement and user functions.

  4. 04

    We verify the version

    We test the defined scenarios and prepare the deliverables and release documentation.

Frequently asked questions

Before starting the project

The technical scope, deliverables and test plan are clarified together according to the requirements of your project.

Can you develop embedded software for my existing board?

The scope can be defined after reviewing the board's schematic, processor details, programming access and required usage rights. Hardware limitations are assessed at the outset.

Can the device work without internet?

Local control and data logging can be designed connection-independently. Which functions will continue offline and how the data will be synchronized when connected is defined in the project.

Are source code and technical documentation delivered?

Yes. We deliver the source code, compilation information and technical documents of the project at the end of the project. File formats and submission list are clear at the beginning; The licenses of third-party libraries used are defined separately.

Can we work with NDA before sharing technical details?

Yes. We can complete the NDA arrangements together before you share your project's technical details.

Let's start with your idea

Let's talk about the product you dream of and the need you want to solve.