Is Your Driver Strategy Accelerating Time to Market?

For most teams, the answer is no. An unoptimized driver strategy is a hidden bottleneck. This inefficiency reveals itself through several symptoms:

• Teams wrestle with bloated vendor SDKs.
• Application code depends too heavily on specific hardware.
• The development process stalls as teams wait for functional drivers.

These delays have severe business consequences, directly impacting revenue and market position.

This article presents a clear strategy for accelerating time to market by transforming HiSilicon drivers from a problem into a project accelerator.

Key Takeaways

• Slow driver strategies hurt project timelines and market success.
• Generic vendor SDKs create problems like long build times and hard debugging.
• Tightly linked code makes software hard to change for new hardware.
• A three-step plan helps: build a lean SDK, use a strong HAL, and standardize driver work.
• This plan helps teams work faster and create better products.

DIAGNOSING YOUR HISILICON BOTTLENECK

Identifying the root cause of project delays is the first step toward a solution. For teams working with HiSilicon SoCs, the bottlenecks often hide in plain sight within the development workflow. These symptoms manifest as technical debt and process inefficiencies that quietly sabotage your time to market.

SYMPTOM 1: BLOATED VENDOR SDKS

HiSilicon provides comprehensive software development kits, or SDKs, to support their hardware. While thorough, these packages are built for a wide range of products, not your specific one. This creates a significant burden.

Your team inherits a one-size-fits-all toolkit. It contains thousands of lines of code and numerous vendor drivers that your project will never use.

This excess code is not harmless. It directly impacts project velocity in several ways:

• Longer Build Times: Compiling unnecessary code and linking unused libraries wastes valuable developer time with every build.
• Complex Debugging: A larger codebase increases the search area for bugs. Developers must navigate irrelevant vendor drivers and dependencies to find the source of a problem.
• Delayed Feature Integration: Adding new features requires developers to understand how they interact with the massive base of existing vendor drivers, slowing down the development process.

These generic SDKs force your team to manage complexity that offers no value to your end product.

SYMPTOM 2: TIGHTLY COUPLED CODE

A common anti-pattern is writing application logic that calls low-level hardware registers directly. This practice tightly couples the software to a specific HiSilicon SoC, making the codebase brittle and difficult to maintain. Any hardware revision or shift to a new chip requires a painful, line-by-line code review and rewrite.

This tight coupling often results from:

• Non-standard compiler extensions: Code may use syntax like volatile uint8_t REG @ 0x1234; to access memory. This is not portable across different toolchains.
• Compiler-specific register maps: The predefined register maps from a silicon vendor often rely on non-standard C language features, locking the code to a single compiler.

The grbl project, for example, concentrates its hardware-dependent code in Stepper.c, making that specific module extremely difficult to port. The solution is to enforce a strict separation of concerns using hardware abstraction layers (HAL). A HAL provides a standardized interface for the application to interact with hardware. It hides the complex, chip-specific details of the vendor drivers.

A well-designed HAL defines a generic interface, often using a struct of function pointers. This allows the application to perform actions like I2C_Write() without knowing the specific register bits of the underlying vendor drivers.

/* Example of an I2C HAL Interface */
typedef struct
{
  bool (*Init)(void);
  bool (*Write)(uint16_t const TargetAddress, uint8_t const * const Data, uint32_t const DataLength);
  bool (*Read)(uint16_t const TargetAddress, uint8_t * Data, uint32_t const DataLength);
} I2C_t;

This approach creates high cohesion and low coupling. It isolates the hardware-specific vendor drivers from the application logic, making the system modular, testable, and easy to adapt. The application code for the drivers becomes reusable across multiple projects.

SYMPTOM 3: SEQUENTIAL DEVELOPMENT

Many projects follow a rigid, sequential workflow. The application team cannot begin meaningful work until the hardware team delivers fully functional drivers. This creates a classic dependency bottleneck.

Typical Inefficient Workflow:

Driver Team Develops ➡️ Application Team Waits ➡️ Integration Starts Late 🚶‍♂️.....................................💻

This process introduces significant idle time and extends the entire project timeline. A modern strategy eliminates this dependency through parallel development. By defining clear interfaces (like the HAL described above) early in the project, teams can work simultaneously.

Application developers do not need to wait for physical hardware or complete vendor drivers. They can write and test their code against mock objects or simulators that mimic the behavior of the future drivers. This approach offers key benefits:

• Parallel Workstreams: Application and driver development proceed at the same time, dramatically shortening the overall timeline.
• Early Bug Detection: Teams can identify and fix integration issues in a simulated environment long before the final hardware is ready.
• Improved Collaboration: This process forces clear communication and agreement on interfaces from the start, aligning teams and reducing late-stage conflicts.

Decoupling the hardware and software workstreams transforms the development process from a relay race into a coordinated, parallel effort.

A STRATEGY FOR ACCELERATING TIME TO MARKET

Diagnosing bottlenecks is only the first step. The next is to implement a deliberate, three-tier strategy. This approach transforms how a team manages HiSilicon drivers, turning a source of delay into a tool for accelerating time to market. Each tier builds upon the last to create a streamlined and efficient workflow.

TIER 1: BUILD A LEAN SDK

Teams should stop wrestling with generic vendor sdks. The solution is to build a lean, project-specific SDK. This involves systematically removing all code, libraries, and resources that are not essential for the final product. This practice also enhances security because removing non-essential libraries reduces the potential for exploits.

Creating and maintaining a lean SDK requires a disciplined approach. Best practices include:

• Modular Architecture: Design the SDK in modules. This allows development teams to include only the necessary parts for their specific features.
• Semantic Versioning: Use a MAJOR.MINOR.PATCH versioning system. This clearly communicates the impact of updates, distinguishing between breaking changes, new features, and bug fixes.
• Clear Documentation: Provide comprehensive documentation for every version. This includes migration guides and changelogs to help developers adapt to new releases smoothly.
• Automated Testing: Implement a suite of automated tests for every version. This ensures backward compatibility and prevents regressions, maintaining the reliability of the custom sdks.

This initial step eliminates code bloat, shortens build times, and simplifies debugging. It gives the team a clean, optimized foundation to build upon.

TIER 2: IMPLEMENT A ROBUST HAL

With a lean SDK in place, the next tier is to architect a robust Hardware Abstraction Layer (HAL). A HAL is a software layer that creates a buffer between the application logic and the hardware-specific drivers. It decouples the application from the underlying HiSilicon SoC, making the code portable and easier to maintain.

A well-designed HAL defines a standard set of functions for interacting with peripherals. For a component like GPIO, the essential functions include:

• Initialization
• Write and Read operations
• Setting the pin multiplexer (SetMux)

This abstraction prevents application code from making direct, low-level hardware calls. Instead of being tied to specific registers, the application uses the standardized HAL interface.

The primary benefit of a HAL is enabling parallel workstreams. Application developers can write and test their code against a "mock" version of the HAL. This mock HAL simulates the behavior of the real hardware drivers without needing physical hardware.

This approach offers significant advantages:

• Isolated Testing: Developers can use mock objects to unit test business logic in isolation. This removes hardware dependencies and allows for rapid testing on a development machine.
• Early Bug Detection: Wrapping hardware communication in a HAL module allows teams to catch integration bugs early, long before the final hardware is available.
• Reduced Risk: Changes to higher-level code are less likely to break the hardware interface, as the HAL is treated as a stable and verified component.

TIER 3: STANDARDIZE DRIVER DEVELOPMENT

The final tier unifies the entire process by establishing clear standards for driver development. Standardization ensures that all drivers are reliable, maintainable, and consistent. This begins with adopting a strict coding standard.

For high-reliability systems, standards like MISRA C are essential. MISRA provides guidelines for C and C++ that help developers:

• Enhance Safety: It disallows unsafe language constructs, such as unchecked pointer arithmetic, which is critical in systems where failure is not an option.
• Improve Maintainability: It promotes code clarity and portability, making software easier to update and manage over its lifecycle.
• Ensure Compliance: It provides a framework for meeting strict industry safety standards like ISO 26262 for automotive systems.

Beyond coding rules, teams must standardize the entire workflow. A formal code review process is a critical part of this. Reviewers should check code against a defined set of criteria.

To enforce these standards automatically, teams should implement a Continuous Integration (CI) pipeline. A CI server can be configured to run a sequence of jobs every time code is committed, accelerating time to market by providing rapid feedback. A typical CI pipeline for embedded drivers includes these stages:

1. Build: The pipeline compiles the firmware and generates release binaries.
2. Analysis: Static analysis tools like PVS-Studio, Coverity, or Polyspace automatically check the code for bugs and adherence to MISRA standards.
3. Testing: The pipeline executes all unit, integration, and system tests.
4. Reporting: It collects results from all previous stages to report on build success, code quality, and test coverage.
5. Merge: The new feature is merged into the main branch only if all previous jobs succeed.

This automated, standardized process ensures that every piece of code is built, tested, and verified, resulting in higher-quality drivers and a more predictable project timeline.

---

A deliberate strategy for drivers is a critical business tool. It is not just a technical detail. This approach is key for accelerating time to market. Teams can transform their workflow by adopting a three-tier solution. This solution involves creating lean SDKs, implementing a robust HAL, and standardizing the development of drivers.

This investment in process and skills yields significant returns:

• It improves project outcomes and reduces rework.
• It provides data to identify and fix inefficiencies.
• It fosters a culture of continuous improvement.

Stop letting inefficient drivers create delays. Implement these changes for better products and for accelerating time to market.

FAQ

What is a Hardware Abstraction Layer (HAL)?

A Hardware Abstraction Layer (HAL) is a software layer that separates application code from hardware-specific drivers. This layer enables parallel development and makes software portable across different chips. It is a key tool for accelerating time to market.

Is building a lean SDK difficult?

Building a lean SDK requires discipline. Teams must identify and remove unused code from the vendor's package. This initial effort pays off by reducing build times, simplifying debugging, and improving security.

What is MISRA C?

MISRA C is a set of software development guidelines for the C programming language. It helps teams write safer and more portable code. Adherence is critical for high-reliability systems. Key benefits include:

• Enhanced safety 🛡️
• Improved maintainability
• Assured compliance

How does this strategy help with new HiSilicon chips?

A robust HAL makes porting to new HiSilicon SoCs much faster. The application code remains unchanged. Developers only need to update the HAL's underlying driver implementation for the new chip, saving significant time and effort.