Analog Video Output on a Modern Vision Platform, Without a Board Redesign

Project in a Nutshell: A European provider of vision-based safety solutions for professional vehicle applications needed to add analog PAL/NTSC video output to a new-generation platform, to maintain compatibility with existing video infrastructures. Adding this capability through new hardware would have meant a full board revision. Promwad delivered the capability in software by porting and validating a Linux driver on the client's platform, and handed over a working analog output path. The existing board stayed exactly as it was.

Client & Challenge

Our client is a European provider of vision-based safety solutions for professional vehicle applications. In the application domain the client serves, analog PAL/NTSC monitor infrastructures are still in active use.

For the next generation of the client's vision platform, adding analog PAL/NTSC video output was a new capability requirement. Maintaining compatibility with installed customer systems was a key project requirement. Adding this capability through additional hardware would have meant a new board revision, so the client looked for a software route on the existing design.

The client needed embedded Linux driver expertise to add this capability in software.

Need an embedded Linux driver brought up on a new target without a board redesign?

Let's scope it

Solution

The core of the work was a Linux driver port. The source driver was written for a desktop computer on a recent version of Linux. The client's product was based on an embedded Linux environment requiring substantial adaptation effort.

Driver interfaces in Linux change across environments, and closing that gap was the technical core of the engagement.

Since the client's end device was not on our side, we bought the target hardware ourselves and tested against real hardware rather than a simulator.

The team was compact: a software engineer on the porting and integration, a project manager on coordination, and a CTO available for technical escalation. The client got regular written status updates, weekly calls, and monthly progress and billing reports. Sign-off ran against an agreed deliverables list, in writing.

Architecture & Key Decisions

Two decisions defined the outcome:

The first was to solve the problem in software. Adding native analog video to the board would have meant a new hardware revision. Delivering the capability at the driver layer kept the existing board intact. The implementation was optimized to achieve stable video performance matching the project requirements.

The second was image quality tuning on the embedded target. During integration we identified a memory-handling behavior that affected the output image and resolved it inside the driver. We also reworked the driver's color conversion to keep CPU and memory usage inside budget on the embedded board.

Risks & Constraints

Three risks shaped the engagement from day one. We logged them in writing at the start, agreed mitigations with the client, and tracked them until handover.

Results & Business Value

Phase 1 finished with a working driver, validated on real hardware, and accepted by the client in writing. The client now has analog PAL/NTSC video output on the new vision platform without a board redesign. The existing hardware stays on its current track, and the platform maintains compatibility with the analog monitor infrastructures still in active use in the client's application domain.

More of What We Do for Vision Platform Engineering

Android Kernel & System Design: driver, BSP, and kernel work across ARM, x86, and other architectures for embedded products.

360 Truck Camera Systems Development: updating a supplier's 360-degree vehicle vision system without a full board redesign.

FAQ

Do you work with vision systems for commercial vehicles and other professional vehicle applications?

Yes. We build vehicle camera and vision systems for passenger cars, trucks, commercial vehicles, and agricultural machinery, covering ADAS, driver monitoring, digital mirrors, 360-degree view systems, and safety-critical platforms. Where the application asks for it, we align our work with automotive standards such as ASPICE and ISO 26262 (ASIL B).

Do you take on driver ports between different Linux environments and architectures?

Yes. Kernel and driver engineering is one of our core embedded services. Our teams work across Linux distributions, kernel versions, and multi-architecture platforms, including Yocto, Buildroot, and AOSP. Driver porting between source and target environments, along with the associated BSP work, is a routine part of these engagements.

What if our target device is not available to your team during development?

This does not block the work. We can source the relevant boards and peripherals on our side and validate against real hardware rather than a simulator. On these engagements we set up regular written status updates, weekly calls, and structured sign-off against an agreed deliverables list, so progress and risks stay transparent throughout.

We need to extend an existing vision platform without redesigning the hardware. Is that realistic?

Often, yes. New capabilities can be added at the software layer, through driver work, middleware, or firmware updates, while the existing board and enclosures stay untouched. We take on this kind of work regularly, including situations where components must be adapted or new capabilities added without a full hardware revision.

The source driver we have was written for a different Linux environment than our target runs. Can it still be used?

In most cases, yes, but adapting driver code between different Linux environments involves real engineering effort, not just a recompile. Driver-facing interfaces in Linux change across kernel versions and distributions, so a driver written for one environment typically needs porting to match the APIs your target actually exposes. That adaptation is often the technical core of the engagement.