Wireless Mesh Stack for STM32WL, nRF52 and CC13xx: How to Avoid Hardware Lock-In

Wireless products often live much longer than the semiconductor platforms they were originally designed around.

A device may remain in production for 10 years or more.

During that time:

• new MCU families appear,
• radio platforms improve,
• older components reach end-of-life,
• supply chains change,
• memory requirements evolve,
• cost targets move,
• regional frequency requirements change.

Yet many embedded products are designed in a way that tightly couples the communication architecture to one particular chip family.

That can create a serious problem.

Changing the MCU or radio may then mean much more than replacing one component.

It can trigger:

• firmware porting,
• networking changes,
• API changes,
• integration work,
• regression testing,
• new interoperability issues,
• requalification,
• months of engineering effort.

For long-lived industrial and professional IoT products, hardware flexibility should therefore be treated as an architectural requirement.

The key question is not only:

Which MCU should we use today?

It is:

Will our networking architecture still make sense if that MCU changes five years from now?

Why wireless products become tied to semiconductor platforms

Vendor lock-in rarely starts as an intentional decision.

It usually appears gradually.

A development team chooses a radio platform.

Then it selects:

• the vendor SDK,
• the vendor RTOS integration,
• a proprietary networking API,
• device-specific drivers,
• vendor-specific commissioning,
• platform-specific examples.

Over time, more application logic becomes dependent on those interfaces.

The result is that the wireless architecture and the semiconductor platform become difficult to separate.

A simplified architecture may look like this:

Application

    ↓

Vendor networking API

    ↓

Vendor protocol stack

    ↓

Vendor SDK

    ↓

Specific MCU + radio

At first, this is convenient.

The entire software environment is optimized for one platform.

But the long-term consequence may be that replacing the hardware also means replacing part of the networking architecture.

Hardware lock-in is not only a commercial problem

Vendor lock-in is often discussed in terms of pricing or supplier dependence.

In embedded systems, the engineering consequences can be even more important.

If the networking stack is deeply tied to one silicon platform, a hardware migration can affect:

• application interfaces,
• timing,
• threading model,
• memory allocation,
• security implementation,
• network behavior,
• update mechanisms,
• diagnostics,
• certification.

This creates risk in product roadmaps.

The hardware decision becomes difficult to revisit even when another platform would offer:

• lower cost,
• better availability,
• lower energy consumption,
• more memory,
• better radio performance,
• a more suitable frequency band.

A flexible networking architecture therefore protects not only procurement.

It protects future engineering decisions.

Separate the networking architecture from the silicon choice

A more maintainable approach is to introduce a stable abstraction between the application and the hardware.

Conceptually:

Application

    ↓

Stable networking interface

    ↓

Wireless networking stack

    ↓

Hardware adaptation layer

    ↓

MCU / radio platform

In this architecture, the networking model remains largely unchanged even when the underlying chip changes.

The application still sees the same network behavior.

The communication concepts remain the same.

What changes is the hardware-specific adaptation underneath.

This is one of the principles behind hardware-agnostic networking.

It does not mean that every MCU can be exchanged without engineering work.

Radio hardware differs.

Memory architectures differ.

Drivers differ.

But it means the migration can be contained primarily within the hardware integration layer instead of forcing a redesign of the entire communication architecture.

Why this matters especially for industrial IoT

Industrial products often have long commercial lifetimes.

A lighting controller, industrial sensor, mining device or building automation component may remain deployed for many years.

The product architecture therefore has to survive changes in:

• silicon availability,
• sourcing strategy,
• regulation,
• radio bands,
• regional product variants.

The longer the expected product lifetime, the more risky it becomes to make the communication layer inseparable from one hardware roadmap.

This is particularly important when the wireless network itself is complex.

If a product uses:

• mesh routing,
• security,
• OTA,
• diagnostics,
• synchronization,
• large-scale network management,

then recreating all of that during a hardware migration can become expensive.

STM32WL: integrated sub-GHz wireless MCU

STMicroelectronics STM32WL devices combine an STM32 microcontroller with sub-GHz radio functionality.

This type of integrated platform is attractive for products that need:

• sub-GHz communication,
• lower component count,
• long-range propagation,
• compact hardware design.

embeNET supports STM32WL platforms as part of its supported hardware ecosystem.

This makes it possible to build a 6TiSCH-compatible, IPv6-based wireless mesh architecture on top of an STM32WL device without tying the entire application communication model to a proprietary radio protocol.

For teams already working in the STM32 ecosystem, this can make STM32WL a natural hardware choice.

The more important architectural point, however, is that choosing STM32WL does not necessarily have to define the networking architecture for the entire lifetime of the product.

Nordic nRF52 and nRF53: strong 2.4 GHz ecosystem

Nordic Semiconductor’s nRF52 and nRF53 families are widely used in embedded wireless products, particularly in the 2.4 GHz band.

They are attractive because of their:

• embedded performance,
• power efficiency,
• mature development ecosystem,
• widespread adoption in connected products.

embeNET supports nRF52 and nRF53 platforms.

For products where 2.4 GHz communication is appropriate, these devices can therefore serve as a hardware platform while the application continues to use the embeNET networking model.

This matters when product families need multiple variants.

For example:

Product family

2.4 GHz variant → nRF52/nRF53

sub-GHz variant → STM32WL or CC13xx

If the communication architecture is consistent across both, a larger part of the application design can remain shared.

Texas Instruments CC1312 and CC1352: sub-GHz and multi-band options

Texas Instruments CC13xx devices are another important family for industrial wireless products.

embeNET supports platforms including:

• CC1312,
• CC1352.

These devices can be attractive where sub-GHz communication is required, while some variants also provide additional radio capabilities.

From an architecture perspective, they represent another hardware path for deploying the same broader networking approach.

Instead of selecting a communication architecture because a particular chip requires it, teams can reverse the process:

define the network architecture first, then select the hardware that best fits the product requirements.

That is a significantly more flexible engineering model.

2.4 GHz or sub-GHz should be an application decision

Frequency band has a major impact on wireless system behavior.

2.4 GHz offers:

• global availability,
• smaller antennas,
• a broad hardware ecosystem,
• higher potential channel availability.

Sub-GHz can offer:

• better propagation through obstacles,
• greater effective range,
• better penetration in some environments,
• advantages in large industrial or outdoor deployments.

There is no universally better option.

The correct choice depends on:

• environment,
• range,
• regulatory region,
• antenna constraints,
• deployment density,
• interference,
• power requirements.

A hardware-agnostic networking architecture makes it easier to choose the frequency band based on the application rather than on networking software limitations.

embeNET supports both 2.4 GHz and sub-GHz hardware platforms.

What happens when a chip reaches end-of-life?

Consider a simplified scenario.

A company develops an industrial wireless controller around Platform A.

The product has already been deployed to thousands of devices.

Several years later, Platform A becomes difficult to source or reaches end-of-life.

The company now has two options.

Architecture tightly coupled to hardware

Old hardware

    ↓

Old vendor stack

    ↓

Old application integration

Migration may require:

New hardware

    ↓

New vendor stack

    ↓

New networking behavior

    ↓

Application changes

    ↓

Integration testing

    ↓

Network regression testing

This is effectively a partial networking redesign.

Hardware-independent networking architecture

A different model is:

Application

      ↓

Stable networking architecture

      ↓

embeNET

      ↓

hardware adaptation

      ↓

new MCU / radio

The migration still requires hardware integration and validation.

But the application-facing network model does not have to be reinvented.

For products already deployed at scale, this difference can be substantial.

Hardware migration affects more than firmware compilation

It is easy to underestimate what needs to be retested after changing a wireless platform.

Moving to a new MCU may affect:

• timing,
• radio initialization,
• interrupt latency,
• memory usage,
• sleep behavior,
• clock architecture,
• RF performance,
• antenna design,
• power consumption.

The networking layer also needs to behave consistently after migration.

This is why having a networking implementation that has already been ported across different MCU and radio families reduces architectural uncertainty.

The stack does not eliminate platform-specific engineering.

It reduces the amount of networking architecture that has to change because of it.

Product families benefit from the same approach

Hardware flexibility is useful not only for emergency migrations.

It can also simplify deliberate product segmentation.

A manufacturer may need:

• a low-cost version,
• a high-performance version,
• a European sub-GHz version,
• a North American variant,
• a 2.4 GHz model,
• a product with Bluetooth coexistence.

Without abstraction, different hardware variants can gradually evolve into separate software products. With a common networking layer such as embeNET, the same application architecture can be reused across multiple hardware platforms.

 For example, one product variant may use STM32WL for sub-GHz communication, another may use nRF52 for 2.4 GHz, and another may use CC1312 for a different sub-GHz implementation. The hardware changes, but the networking model and much of the application logic can remain the same. This reduces architectural fragmentation and makes it easier to maintain multiple product variants over time.

Standard networking interfaces reduce application dependence

Hardware portability becomes easier when applications do not depend heavily on platform-specific communication concepts.

embeNET provides IPv6 and UDP-based communication to embedded applications.

This means application logic can use familiar concepts such as:

• network addresses,
• UDP transport,
• sockets,
• multicast.

This is important because those concepts remain valid independently of the specific MCU.

A migration from one radio platform to another therefore does not necessarily require a new application communication model.

The physical platform changes.

The logical networking architecture can remain stable.

Avoiding hardware lock-in does not mean avoiding vendors

Hardware-agnostic architecture is sometimes misunderstood.

It does not mean that semiconductor vendors are unimportant.

They are extremely important.

Different platforms have real advantages.

One MCU may provide:

• better power consumption,

another:

• stronger radio performance,

another:

• lower cost,

another:

• better availability.

The point is not to avoid selecting a platform.

The point is to prevent today’s platform decision from unnecessarily constraining tomorrow’s product architecture.

A better design principle is:

Use the best hardware for the current product without making the entire networking architecture dependent on it.

Networking portability also reduces supply-chain risk

Recent years have shown how quickly semiconductor availability can change.

For connected products, a shortage of one specific MCU may stop production entirely.

If the software architecture allows alternative hardware to be introduced without redesigning the whole communication layer, product teams have more strategic options.

This does not make migrations instant.

But it changes the problem from:

We have to redesign networking.

to:

We have to port and validate networking on another supported platform.

Those are very different engineering tasks.

What should teams evaluate when selecting a wireless stack?

Before choosing a networking solution, it is worth asking:

Question	Why it matters
Does it support more than one MCU family?	Reduces dependence on one silicon roadmap
Does it support more than one radio vendor?	Provides sourcing flexibility
Does it support 2.4 GHz and sub-GHz?	Allows frequency choice based on application
Is the application API stable across platforms?	Reduces software migration effort
Is networking based on standard concepts?	Limits proprietary application dependencies
Is platform-specific code isolated?	Simplifies porting
Are multiple platforms already validated?	Reduces migration uncertainty
Can the same network contain long-lived product variants?	Supports product family development
Are diagnostics and OTA independent of the MCU?	Protects operational tooling
Does hardware migration preserve network architecture?	Reduces regression scope

These questions should be answered before the product reaches mass deployment.

Hardware choice and network choice should be separate decisions

A common embedded development sequence is:

Choose MCU

    ↓

Use vendor SDK

    ↓

Use vendor networking technology

    ↓

Design product around it

A more flexible sequence is:

Define application requirements

    ↓

Define networking requirements

    ↓

Choose networking architecture

    ↓

Select the best hardware platform

This changes the role of the MCU.

Instead of defining the architecture, it becomes an implementation choice inside a larger system design.

For long-lived IoT products, this is often a healthier dependency structure.

How embeNET approaches hardware independence

embeNET is designed as a lightweight, hardware-agnostic wireless networking stack.

The platform has been ported across hardware from multiple semiconductor vendors and currently supports families including:

• STMicroelectronics STM32WL5 and STM32WL3
• Nordic Semiconductor nRF52 and nRF53
• Texas Instruments CC1312 and CC1352
• supported RadioControlli modules based on TI platforms.

It supports both:

• 2.4 GHz,
• sub-GHz operation.

Above the hardware layer, embeNET provides the same broader networking architecture built around:

• 6TiSCH compatibility,
• TSCH,
• IPv6,
• UDP,
• mesh routing,
• security,
• diagnostics,
• firmware distribution,
• network synchronization.

This allows product developers to maintain a more consistent communication architecture across different hardware choices.

When hardware independence matters most

Not every project needs multi-platform support.

For a short-lived consumer product built entirely around one semiconductor ecosystem, deep integration with that vendor may be perfectly reasonable.

Hardware independence becomes increasingly valuable when:

• the product lifetime is long,
• the deployment is industrial,
• supply-chain continuity matters,
• multiple hardware variants are expected,
• the system will be deployed at large scale,
• regulatory regions require different RF choices,
• the cost of requalification is high,
• networking software represents significant engineering investment.

The more difficult the network would be to recreate, the more valuable it becomes to separate it from the silicon roadmap.

Switch the chip. Keep the network.

Changing an MCU should not automatically mean redesigning:

• routing,
• addressing,
• diagnostics,
• OTA,
• network management,
• application communication.

The physical implementation may change.

The product architecture does not necessarily have to.

That is the core idea behind hardware-agnostic wireless networking.

For embedded teams designing products expected to remain in the market for many years, the relevant question is therefore not:

Which chip has the best specification today?

It is:

Can we change that chip later without forcing the entire communication architecture to start over?

With a portable networking layer, the answer can increasingly be yes.

Switch the chip. Keep the network.