FAQ's

E1M™ is a family of low-power, vendor-agnostic Edge AI System-on-Modules (SoMs) designed for fast deployment in industrial automation, robotics, drones, agriculture, energy, and infrastructure applications. 

E1M™ focuses on modular hardware design, long-term availability, and software portability across multiple processor vendors. 

E1M™ modules can be integrated into embedded systems such as IoT devices, robots, drones, and industrial controllers. 

Depending on the selected module variant, E1M™ supports bare-metal and FreeRTOS-based software environments. 

No. E1M™ is supported by clear documentation, examples, and SDKs that allow developers with different experience levels to get started quickly. 

More advanced users can access lower-level features for fine-grained control when needed. 

E1M™ is suitable for a wide range of industries, including: 

• Industrial automation 
• Robotics 
• Drone and UAV systems 
• Agriculture and environmental monitoring 
• Energy and infrastructure applications 
• Vision  
• Edge-AI 

You can get started by: 

• Downloading the ALP SDK 
• Running applications using mock drivers without hardware 
• Requesting an E1M™ Dev Kit for hardware evaluation 
• Contacting Alp Lab for technical guidance or custom solutions 

Yes. E1M™ is designed as a modular platform and can be customized based on project requirements, including processor selection and hardware configuration. 

Yes. E1M™ is designed to be vendor-neutral. 

Its modular hardware approach, combined with ALP SDK’s abstraction layer, allows integration with multiple processor vendors across different E1M™ variants. 

Documentation, examples, and updates are available through Alp Lab’s Developer Center and GitHub repositories. 

For direct assistance, you can contact: 
contact@alplab.ai 

Security features depend on the selected E1M™ variant and processor. 

E1M™ supports industry-standard security mechanisms such as secure boot and encryption where available and is designed to align with regulations such as the EU Cyber Resilience Act. 

Yes. You can request an E1M™ Dev Kit to evaluate the platform and explore E1M™ and ALP SDK in a real hardware environment. 

ALP SDK is a vendor-independent, CMSIS-compatible software abstraction layer designed to run on E1M™ modules. 

It enables portable application development by isolating application logic from vendor-specific hardware drivers. 

E1M™ provides the hardware platform, while ALP SDK provides the software layer that enables hardware-agnostic development across E1M™ variants. 

Together, they reduce vendor lock-in and simplify long-term maintenance. 

No. E1M™ modules can be used directly with native vendor SDKs. 

However, ALP SDK is recommended if you want portability, testability, and the ability to switch hardware platforms with minimal software changes. 

ALP SDK currently supports Alif Semiconductor Ensemble processors. 

Support for Renesas RZ/V2N is under development and will be added in a future release. 

ALP SDK currently supports: 

• Bare-metal (no-OS) 
• FreeRTOS 
• ZephyrOS (coming) 

Support for additional operating systems may be added in the future. 

added in a future release. 

Yes. When using ALP SDK, application logic is isolated from vendor-specific drivers. 

Switching hardware vendors typically require changes only in the platform driver layer, not in the application code. 

Support for additional operating systems may be added in the future. 

added in a future release. 

Yes. ALP SDK includes mock drivers that allow applications to compile, run, and be tested on a desktop PC without any vendor SDK or physical hardware. 

This enables early development, CI testing, and faster iteration. 

only in the platform driver layer, not in the application code. 

Support for additional operating systems may be added in the future. 

added in a future release. 

No. ALP SDK works on top of vendor SDKs when running on real hardware. 

It provides a clean abstraction layer while still allowing access to vendor-specific features when required. 

ALP SDK is designed for embedded systems. 

In production builds, the abstraction layer resolves to a single function pointer call per operation, resulting in minimal and deterministic overhead.