Skip to content

Open-source embedded systems for intelligent physical devices

From open hardware and secure boot to a real-time OS, developer tools, and on-device AI.

Open infrastructure for physical AI. Shipped profile: eAI Edge = eNI → eIPC → eAI

23Repositories
83Boards
14Books
The EoS Learn RP2350 teaching board in black solder mask, ray-traced from its KiCad files

EoS Learn RP2350 · Teaching board

Built around the RP2350A.

A dual-core Cortex-M33 microcontroller, with its 12 MHz crystal and 128 Mbit QSPI flash right beside it.

Ray-traced from the KiCad files

52.6 × 51.6 mm. Four layers.

Main chip
RP2350A
Copper layers
4
Checked in
KiCad 10.0.6
0ERC violations
0DRC errors
0unconnected items

Every board passes KiCad 10.0.6 with 0 ERC violations, 0 DRC errors and 0 unconnected items.

The board’s real routing

Every trace, in the open.

Drawn here from the board’s own KiCad file. Native KiCad files are downloadable.

Front copperBack copper
See all fifteen boards

eCAD Hardware

One board. Every industry.

125 product lines and 292 named models across eighteen eCAD domains, plus eAgriTech, and a full-body robot built from five of them. Pick an industry to see its design and the EoS profile it runs.

  1. 01eHealth365A ring for vitals, a patch for chemistry
  2. 02eosHealthA health band on the wrist
  3. 03eMedicalA 12-lead ECG on battery power
  4. 04eRadar360360° awareness from the windshield
  5. 05eTransportCharts on the bridge
  6. 06ePAMA four-seat tilt-rotor
  7. 07eAerospaceAn inspection drone
  8. 08eRoboticsA whole robot, built from five designs
  9. 09eAgriTechA tractor that steers itself
  10. 10eFrontierA robot arm for space
  11. 11eIndustrialA controller for the plant floor
  12. 12eEnergyA board that watches every cell
  13. 13eSmartCityStreet lights that report back
  14. 14eMiningFour gases, one warning
  15. 15eEdgeAIFour eyes, one decision
  16. 16eElectronicsDown to the silicon
  17. 17eConsumerOne hub for the whole home
  18. 18eCybersecurityA vault for keys
  19. 19eDefenseA computer with no fan to fail
  20. 20Full-body robotThe board docks, and a body wakes up
  21. 21Full-body robotTwo eyes for depth, one laser for the room
  22. 22Full-body robotWalking is a real-time job
  23. 23Full-body robotHands that pick, check and place
  24. 24Full-body robotStops in one call, updates over the air
  25. 25Every industryEighteen domains, one open collection
01 · eHealth365

A ring for vitals, a patch for chemistry

eHealth365 pairs two wearable designs. The Smart Ring Pro is designed to measure heart rate, HRV, SpO₂, body temperature, sleep stages and activity. The Smart Patch Pro, worn one patch a week, is designed to measure glucose, sweat electrolytes, hydration and skin pH.

From eHealth365_CAD_Design/README.mdBoth are designed to connect to one mobile app over Bluetooth LE

eCAD Hardware · Design stageEoS profile: wearable
eHealth365 · 2 lines · 2 models

Smart Ring Pro + Smart Patch Pro

Design stage

Two wearables, one ring and one patch, each with its own sensors and a shared phone app.

Devices
2
Smart Patch ProSmart Ring Pro

eHealth365_CAD_Design

EoS · wearable profile

How EoS would run it

Profile in eosNot validated on this hardware

Docked here, the core board would boot EoS built with the wearable product profile: 17 features switched on, 4 of them services with working code today.

How EoS would work here
  1. Heart-rate, SpO₂ and temperature samples would pass through the EoS sensor service, whose filtering and calibration are working code.
  2. Bluetooth LE to the phone app would use the BLE HAL class, which is a stub today.
  3. Updates would land through the OTA service: its A/B state machine and SHA-256 checks are in code, but it does not write flash yet.
GPIOUARTSPItimerADCBLEdisplaytouchIMUNFCflashRTCcryptoOTAfilesystempowersensor

eos · products/wearable.h

Parts, and what EoS does with them

  • The deviceA wearable profile build of EoS would run the sensor loop and the BLE link.Working
  • Smart Ring ProHeart rate, HRV and SpO₂ samples would go through the EoS sensor service.Working
  • Designed to measureThe sensor service filters and calibrates each reading (average, median or low-pass).Working
  • Smart Patch ProA week on one patch is a battery target; the EoS power service is bookkeeping only today.In code
  • Bluetooth LEThe link to the phone app would use the BLE HAL class, a stub today.Docs or descriptor

Designs in the eHealth365 line

  • Smart Patch Pro
  • Smart Ring Pro
02 · eosHealth

A health band on the wrist

eosHealth holds four EoS Health designs: HEALTH-KEY ULTRA, HEALTH-BAND Neuro, HEALTH-RING and HEALTH-LAB. The HEALTH-BAND Neuro design is a wristband with a 44 mm case and a 1.4-inch AMOLED display, rated IP68.

From eosHealth_CAD_Design/HEALTH-BAND-Neuro/product_datasheet.mdCase 44 × 38 × 12 mm · 42 g with band

eCAD Hardware · Design stageEoS profile: watch

HEALTH-BAND Neuro A 44 × 38 × 12 mm case with a 454 × 454 AMOLED display, an LRA haptic motor and a medical-grade silicone band.

Parts, and what EoS does with them

  • The deviceA watch profile build would run the PPG sensors, the display and BLE.Working
  • HEALTH-BAND NeuroSensors through the sensor service; the 1.4-inch display needs the ui service, off by default.In code
  • Application MCUstm32h743 is one of the 13 named EoS board descriptors.Docs or descriptor
  • PPG LEDsPPG readings are sensor-service channels; LED timing uses the timer HAL (STM32F4 register code only).In code
03 · eMedical

A 12-lead ECG on battery power

eMedical covers diagnostic, patient-care, surgical and laboratory designs. The eECG-12 design is a battery-powered 12-lead ECG with a 7-inch touch display, BLE 5.3 and Wi-Fi 6, designed for eight hours on its battery and to the IEC 60601-1 safety standard.

From diagnostic_equipment/product_datasheet.md · Design PhaseSTM32H7B3 MCU · ADS1298 8-channel 24-bit ECG front end

eCAD Hardware · Design stageEoS profile: medical
eMedical · 4 lines · 19 models

eECG-12

Design stage

A 12-lead ECG design with a 7-inch 1024 × 600 touch display and a 7.4 V 5000 mAh battery.

Leads
12
Battery
8h design
eECG-12eEEG-32eUS-ProePM-500eBA-100ePCR-96eCentri-24KeSeq-NanoeSpec-UVeLab-AutoeVent-ProeInfuse-200eO2-5LeRehab-ArmeProsth-HandeSurgBot-7eESG-400eEndo-4KeSurgNav-3D

eMedical_CAD_Design

EoS · medical profile

How EoS would run it

Profile in eosNot validated on this hardware

Docked here, the core board would boot EoS built with the medical product profile: 13 features switched on, 4 of them services with working code today.

How EoS would work here
  1. The ADS1298 ECG front end talks SPI. EoS's SPI driver is register code for STM32F4 only, so the STM32H7 here needs its own port.
  2. Each lead would be a sensor-service channel with filtering (working code).
  3. The os service keeps an audit log and integrity checks, and the security service holds keys and an access list (working code). No EoS build is certified for medical use.
GPIOUARTSPItimerADCBLEdisplaycryptosecuritypowersensorsafetyaudit

eos · products/medical.h

Parts, and what EoS does with them

  • The deviceA medical profile build would keep an audit log and integrity checks.Working
  • eECG-12Each of the 12 leads would be a sensor-service channel with filtering.Working
  • Designed to IEC 60601-1A hardware safety target. No EoS build is certified for medical use.Not in the repos yet
  • MCUNearest board descriptor: stm32h743, also a Cortex-M7. The SPI driver is STM32F4 register code only.In code

Designs in the eMedical line

  • eECG-12
  • eEEG-32
  • eUS-Pro
  • ePM-500
  • eBA-100
  • ePCR-96
  • eCentri-24K
  • eSeq-Nano
  • eSpec-UV
  • eLab-Auto
  • eVent-Pro
  • eInfuse-200
  • eO2-5L
  • eRehab-Arm
  • eProsth-Hand
  • eSurgBot-7
  • eESG-400
  • eEndo-4K
  • eSurgNav-3D
04 · eRadar360

360° awareness from the windshield

eRadar360 (Aegis One for OEMs) is a windshield-mounted car safety design. It is designed to fuse four sensor types: front and rear 77 GHz FMCW radar, five laser detectors spaced 72° apart for 360° coverage, and V2X radio.

From eRadar360_CAD_Design/README.md2× TI AWR2944 77 GHz radar · 5× InGaAs APD laser detectors · V2X

eCAD Hardware · Design stageEoS profile: automotive

Aegis One A windshield unit that combines radar, laser detection and vehicle-to-everything radio.

Parts, and what EoS does with them

  • The deviceA high-priority kernel task would fuse radar, laser and V2X events.Working
  • Aegis OneThe priority scheduler and message queues it would use are working code.Working
  • Front + rear radarRadar would plug into the radar/LiDAR HAL class, a stub today.Docs or descriptor
  • 5 laser detectorsEach detector is an analog input; the ADC HAL class is a stub today.Docs or descriptor
  • V2XThere is no V2X stack in EoS yet; sockets work on host builds only.Not in the repos yet
05 · eTransport

Charts on the bridge

eTransport covers automotive, maritime and rail electronics. The eNav-ECDIS design is an electronic chart display for ships, with a 27-inch sunlight-readable display and encrypted S-57/S-63 electronic navigational charts.

From maritime_systems/product_datasheet.md · IEC 61174, SOLASNXP i.MX 8M Plus · NMEA 2000, NMEA 0183, AIS, Ethernet

eCAD Hardware · Design stageEoS profile: cockpit

eNav-ECDIS A bridge console design built around a 27-inch 1920 × 1200 IPS display on 24 VDC power.

Parts, and what EoS does with them

  • The deviceA cockpit profile build would drive the chart display and the bridge network.In code
  • eNav-ECDISThe chart display needs the display HAL and the ui service, neither built by default.Docs or descriptor
  • S-57/S-63S-63 protects charts with Blowfish and DSA; EoS has neither yet.Not in the repos yet
  • NXP i.MX 8M PlusNearest EoS board descriptor: imx8m, the i.MX 8M Mini.Docs or descriptor
06 · ePAM

A four-seat tilt-rotor

ePAM holds personal air and mobility designs: the Urban Drone, a space shuttle avionics board, an eco car and a combo unit. The Urban Drone design is a four-seat tilt-rotor eVTOL, shown here as a scale model.

From ePAM_CAD_Design/urban_drone/product_datasheet.mdWingspan 12 m extended, 4 m folded · MTOW 1,400 kg

eCAD Hardware · Design stageEoS profile: aerospace

Urban Drone A tilt-rotor eVTOL design for one pilot (or autonomous flight) and three passengers.

Parts, and what EoS does with them

  • The deviceAn aerospace profile build: GNSS, IMU, CAN, watchdog and redundancy.In code
  • Urban DronePosition would come through the gps service's NMEA parser (working code).Working
  • 8x tilt-rotorsEight rotors fit the motor service's limit of eight; the motor HAL itself is a stub.In code
  • CanopyTint control is a PWM or DAC output; both HAL classes are stubs today.Docs or descriptor
  • Flight controllerEoS multicore (spinlocks, inter-core interrupts, shared memory, AMP) is working code.Working
07 · eAerospace

An inspection drone

eAerospace has the most models of any domain: avionics, CubeSats, flight control, navigation, launch systems and UAVs. The eMR-400 design is a multirotor inspection drone in the UAV and drone line.

From uav_drone_systems/product_datasheet.md · Design PhaseeMR-400 design targets: 1 kg payload, 45 min endurance, 10 km range

eCAD Hardware · Design stageEoS profile: drone
eAerospace · 17 lines · 57 models

eMR-400

Design stage

A multirotor inspection drone design; the line also includes fixed-wing, VTOL cargo and swarm designs.

Payload
1kg target
Endurance
45min target
eATM-3000eATM-RSUeATM-TWReAPT-900eAPT-VDGSeAPT-APReFC-1000eNAV-500eADC-200eFD-1080eCOM-400eXPDR-1090eCUBE-3U-OBCeCUBE-EPSeCUBE-ADCSeCUBE-3UeFCS-2000eFCS-2000MeACE-400eGNSS-400+37 more

eAerospace_CAD_Design

EoS · drone profile

How EoS would run it

Profile in eosNot validated on this hardware

Docked here, the core board would boot EoS built with the drone product profile: 23 features switched on, 6 of them services with working code today.

How EoS would work here
  1. Four motors fit inside the motor service's limit of eight: its PID speed loops and trajectories are working code.
  2. The motor (ESC) and IMU HAL classes are stubs today, so nothing drives real hardware yet.
  3. GNSS position comes from the gps service (NMEA parsing, working code); updates would arrive through the OTA A/B service.
GPIOUARTSPItimerADCPWMwifiBLEcameramotorGNSSIMUradarDMAOTAflashWDTfilesystempowernetsensormotor ctrlsafety

eos · products/drone.h

Parts, and what EoS does with them

  • The deviceA drone profile build: motor control, GNSS, IMU and OTA.In code
  • eMR-400Four motors would run on the motor service's PID speed loops (working code).Working
  • Core boardeBoot checks the signed image here, then EoS boots on this board.In code
  • PayloadPayload sensors would register with the sensor service, which holds 16.Working
  • Design targetsEndurance is a battery target; the EoS power service is bookkeeping only today.In code

Designs in the eAerospace line

  • eATM-3000
  • eATM-RSU
  • eATM-TWR
  • eAPT-900
  • eAPT-VDGS
  • eAPT-APR
  • eFC-1000
  • eNAV-500
  • eADC-200
  • eFD-1080
  • eCOM-400
  • eXPDR-1090
  • eCUBE-3U-OBC
  • eCUBE-EPS
  • eCUBE-ADCS
  • eCUBE-3U
  • eFCS-2000
  • eFCS-2000M
  • eACE-400
  • eGNSS-400
  • eGNSS-400T
  • eGNSS-ANT
  • eGS-1200
  • eGS-RCU
  • eGS-LNA
  • eLV-500
  • eLV-AFTS
  • eLV-SEQ
  • eINS-900
  • eINS-900L
  • eINS-AHRS
  • ePCU-700
  • ePCU-EP
  • ePCU-RCS
  • eRAD-100
  • eRAD-LCL
  • eRAD-SCRUB
  • eSAT-8000
  • eSAT-PCU
  • eSAT-RIU
  • eSat-Bus-100
  • eCubeSat-3U
  • eRW-0.1
  • eST-200
  • eSA-50
  • eEPS-5
  • eSWX-200
  • eSWX-PD
  • eSWX-MAG
  • eTLM-600
  • eTLM-DAU
  • eTLM-GRX
  • eFW-1000
  • eMR-400
  • eVT-5000
  • eGCS-100
  • eSwarm-10
08 · eRobotics

A whole robot, built from five designs

eRobotics covers industrial robots, autonomous systems and robot components. This robot is assembled from five of them: the eAMR-500 mobile base, the eArm-7 seven-axis arm, the eGripper-3F hand, eVision-4K stereo eyes and the eLiDAR-360.

From autonomous_systems, industrial_robots and robot_components datasheetseAMR-500: 500 kg payload, 2 m/s, LiDAR SLAM · eArm-7: 10 kg, 1.3 m reach

eCAD Hardware · Design stageEoS profile: robot
eRobotics · 3 lines · 15 models

A full robot from five designs

Design stage

An autonomous mobile manipulator: base, arm, gripper, vision and LiDAR are each an eRobotics design.

Designs combined
5
Arm axes
7
eAMR-500eWarehouse-1TeDelivery-BoteAgri-TractoreSecurity-PatroleArm-7eWeld-6eAssemble-4ePick-DeltaeCobot-5eServo-200eActuator-50eGripper-3FeVision-4KeLiDAR-360

eRobotics_CAD_Design

EoS · robot profile

How EoS would run it

Profile in eosNot validated on this hardware

Docked here, the core board would boot EoS built with the robot product profile: 15 features switched on, 3 of them services with working code today.

How EoS would work here
  1. The arm's 7 joints plus the base's 4 hub motors make 11 motors, more than the 8 the motor service tracks per image today, so this robot needs that limit raised or two EoS images.
  2. LiDAR, cameras and the IMU sit behind HAL stub classes; the sensor service (working code) holds up to 16 sensors.
  3. The priority scheduler keeps the safety stop ahead of everything else, and eos_motor_ctrl_emergency_stop() halts a motor in one call (working code).
GPIOUARTSPII2CtimerADCPWMwifiBLEcameramotorIMUnetsensormotor ctrl

eos · products/robot.h

Parts, and what EoS does with them

  • The deviceA robot profile build: motor control, sensors, camera, IMU, Wi-Fi and BLE.In code
  • eAMR-500Its four hub motors would run on motor-service PID speed loops (working code).Working
  • eArm-7Seven joints plus four hub motors make 11, over the motor service's 8 per image.In code
  • eGripper-3FRS-485 would go through the UART driver, register code for STM32F4 only.In code
  • eVision-4KThe cameras would use the camera HAL class, a stub today.Docs or descriptor
  • eLiDAR-360The LiDAR would use the radar/LiDAR HAL class, a stub today.Docs or descriptor
  • Core boardeBoot verifies the image, then the robot profile build of EoS boots here.In code

Designs in the eRobotics line

  • eAMR-500
  • eWarehouse-1T
  • eDelivery-Bot
  • eAgri-Tractor
  • eSecurity-Patrol
  • eArm-7
  • eWeld-6
  • eAssemble-4
  • ePick-Delta
  • eCobot-5
  • eServo-200
  • eActuator-50
  • eGripper-3F
  • eVision-4K
  • eLiDAR-360
09 · eAgriTech

A tractor that steers itself

The website lists eAgriTech as its own industry. Its design lives in the eRobotics autonomous-systems line: the eAgri-Tractor, an autonomous tractor designed to navigate by RTK GPS and LiDAR.

From eRobotics_CAD_Design/autonomous_systems/product_datasheet.mdeAgri-Tractor · design speed 3 m/s

eCAD Hardware · Design stageEoS profile: autonomous

eAgri-Tractor An autonomous tractor design in the eRobotics autonomous-systems family.

Parts, and what EoS does with them

  • The deviceAn autonomous profile build: GNSS, LiDAR, CAN and multicore.In code
  • eAgri-TractorPerception and control could run on separate cores with the kernel's AMP support.Working
  • RTK GPSRTK fixes arrive as NMEA sentences, parsed by the gps service (working code).Working
  • LiDARThe LiDAR would use the radar/LiDAR HAL class, a stub today.Docs or descriptor
  • Design speedDrive and steering could use motor-service PID loops and trajectories (working code).Working
10 · eFrontier

A robot arm for space

eFrontier explores bioelectronics, nanotechnology, neuromorphic computing, photonics, quantum control, space robotics and swarms. The eSRB-900 design is a space-robotics controller for a seven-axis arm on a rad-hard processor.

From space_robotics/product_datasheet.mdGR712RC dual-core LEON3FT · 50 krad(Si) dose target

eCAD Hardware · Design stageEoS profile: satellite

eSRB-900 A controller design for a 7-axis space manipulator with harmonic drives and a 6-axis force/torque sensor.

Parts, and what EoS does with them

  • The deviceA satellite profile build: watchdog, multicore and integrity checks.Working
  • eSRB-900The os service's watchdog and the RTOS fault log would support autonomous safing.Working
  • 7 axesSeven joint loops fit inside the motor service's limit of eight (working code).Working
  • 6-axis force/torqueSix force and torque channels would fit the sensor service's 16 slots.Working
  • GR712RCLEON3 exists as a board descriptor (generic-sparc); there is no SPARC port yet.Docs or descriptor
11 · eIndustrial

A controller for the plant floor

eIndustrial spans industrial electronics, sensors and infrastructure equipment. The ePLC-1000 design is a modular PLC for IEC 61131-3 programs on an NXP i.MX 8M Plus, with 32 digital inputs, 32 digital outputs, 16 analog inputs and 8 analog outputs.

From industrial_electronics/product_datasheet.md · Design PhaseFieldbus: PROFIBUS DP, PROFINET, EtherCAT, Modbus TCP/RTU

eCAD Hardware · Design stageEoS profile: plc

ePLC-1000 A modular PLC design that mounts on a DIN rail, with fieldbus, analog and digital I/O.

Parts, and what EoS does with them

  • The deviceA PLC profile build: GPIO, ADC/DAC, CAN, Ethernet, watchdog and motor control.In code
  • ePLC-1000IEC 61131-3 programs need a PLC runtime on top of EoS; none is in the repos yet.Not in the repos yet
  • FieldbusThere is no PROFINET or EtherCAT stack in EoS yet.Not in the repos yet
  • I/ODigital I/O via GPIO (STM32F4 register code); analog via ADC/DAC HAL classes, stubs today.In code
  • CPUNearest EoS board descriptor: imx8m, the i.MX 8M Mini.Docs or descriptor
12 · eEnergy

A board that watches every cell

eEnergy covers battery products, renewable energy and power electronics. The eBMS-100A battery-management design is designed to monitor each cell, sense pack current, balance cells actively and protect against over-voltage, under-voltage, over-current, overheating and short circuits.

From battery_products/product_datasheet.md · Design PhaseeBMS-100A communication: CAN FD, SMBus, RS-485, BLE

eCAD Hardware · Design stageEoS profile: ev
eEnergy · 3 lines · 15 models

eBMS-100A

Design stage

A battery-management design with per-cell monitoring and active balancing.

Interfaces
4
eBMS-100AeLiPack-10kWheESS-100kWhePPS-5kWeSBM-SmarteDCDC-5kWeUPS-10kVAeMotorDrive-22kWePDU-SmarteBreaker-SmarteSolarInv-10kWeSolarTrackereWindCtrl-50kWeMicrogrid-100eSCC-60A

eEnergy_CAD_Design

EoS · ev profile

How EoS would run it

Profile in eosNot validated on this hardware

Docked here, the core board would boot EoS built with the ev product profile: 31 features switched on, 9 of them services with working code today.

How EoS would work here
  1. The LTC6813 talks SPI, and each cell would be a sensor-service channel with filtering (working code). Its 18 cells exceed the service's 16 channels today.
  2. Over-voltage, over-current and short-circuit protection would run as the highest-priority kernel task.
  3. CAN FD and BLE are HAL stubs, and the power service is bookkeeping only, so real readings come from the BMS itself.
GPIOUARTSPItimerADCDACPWMCANethernetmotorIMUGNSSdisplaytouchDMAflashRTCWDTcellularwifiBLEcryptosafetyauditpowernetsensormotor ctrlOTAfilesystemmulticore

eos · products/ev.h

Parts, and what EoS does with them

  • The deviceAn EV profile build: sensors, CAN, motor control and OTA.In code
  • eBMS-100AProtection would run as the highest-priority kernel task (scheduler: working code).Working
  • Active balancingBalancing decisions would run on a software timer in the kernel (working code).Working
  • Cell monitoringThe LTC6813 talks SPI; its 18 cells exceed the sensor service's 16 slots today.In code
  • MCUThere is no STM32G4 board descriptor; the nearest is stm32f4.Docs or descriptor

Designs in the eEnergy line

  • eBMS-100A
  • eLiPack-10kWh
  • eESS-100kWh
  • ePPS-5kW
  • eSBM-Smart
  • eDCDC-5kW
  • eUPS-10kVA
  • eMotorDrive-22kW
  • ePDU-Smart
  • eBreaker-Smart
  • eSolarInv-10kW
  • eSolarTracker
  • eWindCtrl-50kW
  • eMicrogrid-100
  • eSCC-60A
13 · eSmartCity

Street lights that report back

eSmartCity has 13 lines, from civic sensing to waste management. The eSL-400 design twists into a street light's NEMA socket. It is designed to dim the lamp by ambient light, motion and schedule, meter its energy and report faults over LoRaWAN.

From street_lighting/product_datasheet.md · Design PhaseSocket: ANSI C136.41 7-pin NEMA twist-lock

eCAD Hardware · Design stageEoS profile: iot
eSmartCity · 13 lines · 25 models

eSL-400

Design stage

A NEMA twist-lock lighting controller design with dimming, metering and LoRaWAN.

Product lines
13
eCS-200eDIS-600eGOV-500eEMR-800eHUM-400eKSK-900ePS-1200eRUR-700eSL-400e5G-SmalleIoT-GWeRouter-ProeNetMonePrivNeteTrafficCtrleParkSensoreStreetLighteEnvStationeSafety-CameSM-3P+5 more

eSmartCity_CAD_Design

EoS · iot profile

How EoS would run it

Profile in eosNot validated on this hardware

Docked here, the core board would boot EoS built with the iot product profile: 17 features switched on, 5 of them services with working code today.

How EoS would work here
  1. LoRaWAN is not in EoS yet; it appears only in the docs.
  2. Dimming from 1% to 100% would use the PWM HAL class and 0–10 V the DAC class; both are stubs today.
  3. Metered voltage and current fit the sensor service's voltage and current types (working code).
GPIOUARTSPItimerADCwifiBLEcellularflashRTCWDTcryptoOTAfilesystempowernetsensor

eos · products/iot.h

Parts, and what EoS does with them

  • The deviceAn IoT profile build: sensors, OTA, Wi-Fi and BLE.In code
  • eSL-400LoRaWAN appears only in the EoS docs so far.Docs or descriptor
  • SocketMetered voltage and current fit the sensor service's voltage and current types.Working
  • DimmingDimming would use the PWM HAL class, and 0–10 V the DAC class; both are stubs today.Docs or descriptor
  • ControllerThere is no STM32G4 board descriptor; the nearest is stm32f4.Docs or descriptor

Designs in the eSmartCity line

  • eCS-200
  • eDIS-600
  • eGOV-500
  • eEMR-800
  • eHUM-400
  • eKSK-900
  • ePS-1200
  • eRUR-700
  • eSL-400
  • e5G-Small
  • eIoT-GW
  • eRouter-Pro
  • eNetMon
  • ePrivNet
  • eTrafficCtrl
  • eParkSensor
  • eStreetLight
  • eEnvStation
  • eSafety-Cam
  • eSM-3P
  • eWM-DN50
  • eGM-100
  • eLeakDetect
  • eUtilMonitor
  • eWM-300
14 · eMining

Four gases, one warning

eMining covers mining equipment, industrial safety and construction robots. The eGasDetect-4 design is a four-gas detector for oxygen, carbon monoxide, hydrogen sulphide and flammable gas, with audible, vibrating and visual alarms, designed to IP67.

From industrial_safety/product_datasheet.md · Design PhaseATEX design target: Ex ia IIC T4 Ga, Zones 0, 1 and 2

eCAD Hardware · Design stageEoS profile: industrial

eGasDetect-4 A four-gas detector design with electrochemical and catalytic-bead sensors.

Parts, and what EoS does with them

  • The deviceAn industrial profile build: sensors, watchdog and safety.Working
  • eGasDetect-4Each gas would be a sensor-service channel of the gas type.Working
  • SensorsReadings get the sensor service's filtering and calibration (working code).Working
  • AlarmsA high-priority alarm task, restarted by the watchdog if it stalls (working code).Working
  • MCUThere is no STM32L4 board descriptor; the nearest is stm32f4, also a Cortex-M4.Docs or descriptor
15 · eEdgeAI

Four eyes, one decision

eEdgeAI is eight lines of edge-AI hardware: accelerators, inference servers, NPUs, sensor fusion, SLAM, speech, TinyML and vision. The eVIS-600 design synchronises four global-shutter cameras and runs object detection at 30 fps in 1080p on an i.MX 8M Plus NPU. Research horizon: AGI-enabling methods for autonomous physical systems. No achieved AGI system is claimed as available today.

From vision_processing/product_datasheet.md4× MIPI CSI-2 · <1 µs inter-camera skew · 850 nm IR strobe

eCAD Hardware · Design stageEoS profile: ai_edge
eEdgeAI · 8 lines · 8 models

eVIS-600

Design stage

A four-camera embedded vision design with a hardware ISP, IR strobe and GigE Vision output.

Cameras
4
NPU
2.3TOPS
eAI-2000eINF-4000eNPU-800eSFU-500eSLM-700eSPX-300eTML-100eVIS-600

eEdgeAI_CAD_Design

EoS · ai_edge profile

How EoS would run it

Profile in eosNot validated on this hardware

Docked here, the core board would boot EoS built with the ai_edge product profile: 22 features switched on, 6 of them services with working code today.

How EoS would work here
  1. Detection on the NPU would go through eAI, whose default build returns stub inference today.
  2. The four cameras would use the camera HAL class, a stub today.
  3. The nearest EoS board is imx8m (i.MX 8M Mini); the kernel's AMP support would split vision from strobe timing (working code).
GPIOUARTSPItimerUSBethernetwificameraaudioGPUPCIeDMAflashRTCSDIOcryptoOTApowernetsensorfilesystemmulticore

eos · products/ai_edge.h

Parts, and what EoS does with them

  • The deviceAn AI-edge profile build: camera, GPU/NPU, DMA, multicore and OTA.In code
  • eVIS-600Detection on the NPU would go through eAI, which returns stub inference by default.In code
  • 2.3MP global shutterThe four cameras would use the camera HAL class, a stub today.Docs or descriptor
  • 850nm IR strobeStrobe timing would use the timer HAL, register code for STM32F4 only.In code
  • NXP i.MX 8M PlusNearest EoS board descriptor: imx8m, the i.MX 8M Mini.Docs or descriptor

Designs in the eEdgeAI line

  • eAI-2000
  • eINF-4000
  • eNPU-800
  • eSFU-500
  • eSLM-700
  • eSPX-300
  • eTML-100
  • eVIS-600
16 · eElectronics

Down to the silicon

eElectronics designs the parts themselves: components, semiconductors and emerging technology. The eASIC-Vision design is a computer-vision chip on a 7 nm process with 32 MB of on-chip SRAM, in a 25 × 25 mm BGA-576 package.

From semiconductor_products/product_datasheet.md · Design PhaseDesign targets: 100 TOPS (INT8) at 5 W typical

eCAD Hardware · Design stageEoS profile: computer

eASIC-Vision A vision ASIC design with PCIe 4.0 ×4, four MIPI CSI-2 inputs and LPDDR5.

Parts, and what EoS does with them

  • The deviceEoS would run on the host processor that drives this chip.In code
  • eASIC-VisionA vision ASIC would plug into eAI's accelerator layer; non-CPU back ends are stubs.In code
  • BGA-576The package is hardware; EoS sees it as a PCIe device on the host.Docs or descriptor
  • DieOn-chip SRAM is managed by the chip itself, not by EoS.Docs or descriptor
  • PCIe 4.0 ×4PCIe and DMA HAL classes are stubs today.Docs or descriptor
17 · eConsumer

One hub for the whole home

eConsumer covers smart home, smart devices and personal devices. The eHub-Pro design is a smart-home hub that speaks Matter 1.3, Zigbee 3.0, Z-Wave 700, BLE 5.3 and Wi-Fi 6, built on an NXP i.MX 8M Mini.

From smart_home/product_datasheet.md · Design PhaseThe same line includes a thermostat, a video doorbell, an indoor camera and an AI speaker

eCAD Hardware · Design stageEoS profile: smart_home

eHub-Pro A multi-protocol smart-home hub design.

Parts, and what EoS does with them

  • The deviceA smart-home profile build: Wi-Fi, BLE, display, crypto and OTA.In code
  • eHub-ProDevice credentials would sit in the security service's keystore (working code).Working
  • Matter 1.3There is no Matter, Zigbee or Z-Wave stack in EoS yet.Not in the repos yet
  • CPUMatches the imx8m board descriptor, the i.MX 8M Mini.Docs or descriptor
  • GbEOn Linux builds, EoS sockets are real; MQTT and mDNS are stubs.In code
18 · eCybersecurity

A vault for keys

eCybersecurity designs hardware for trust: roots of trust, secure elements, TPMs and security appliances. The eHSM-9000 design is a network-attached hardware security module designed to generate, store and use keys inside a tamper-responsive boundary, and to erase them if its active mesh is breached.

From hardware_security_modules/product_datasheet.md · Design PhaseM-of-N smartcard quorum · certification target FIPS 140-3 Level 4

eCAD Hardware · Design stageEoS profile: crypto_hw

eHSM-9000 A hardware security module design with an active tamper mesh and a smartcard quorum.

Parts, and what EoS does with them

  • The deviceA crypto-hardware profile build: crypto, security, audit and watchdog.Working
  • eHSM-9000SHA-256, SHA-512, AES and Ed25519 verification are working code; RSA and ECC fail closed.Working
  • M-of-N quorumAccess lists and a keystore come from the security service (working code).Working
  • Active tamper meshZeroisation would be a GPIO interrupt into the top-priority task; GPIO is STM32F4 register code.In code
  • Core boardeBoot verifies the image before EoS runs inside the tamper boundary.In code
19 · eDefense

A computer with no fan to fail

eDefense has 19 lines, from ruggedised computing to sonar. The eRGD-2000 design is a rugged mission computer that cools by conduction through its chassis, so it needs no fan and can be sealed to IP67. It is designed for MIL-STD-810H shock and vibration.

From ruggedized_computing/product_datasheet.md · Design PhaseNXP i.MX 8M Plus with NPU · −40 °C to +71 °C operating

eCAD Hardware · Design stageEoS profile: server

eRGD-2000 A sealed, fanless rugged computer design.

Parts, and what EoS does with them

  • The deviceA server profile build: multicore, watchdog, filesystem and security.Working
  • eRGD-2000Mission tasks would be isolated by the multicore layer and restarted by the watchdog.Working
  • Conduction coolingBoard temperatures would go through the sensor service (working code).Working
  • IP67 sealedA hardware rating; on Linux, EoS adds SELinux, IMA/EVM and dm-verity helpers.Working
  • NXP i.MX 8M PlusThe NPU sits behind eAI, which returns stub inference by default.In code
20 · Full-body robot

The board docks, and a body wakes up

At the centre of the hall stands a full-body robot built only from eRobotics designs: eServo-200 drives in its 26 rotary joints, eActuator-50 push rods at the ankles, eGripper-3F hands, eVision-4K eyes and an eLiDAR-360 crown. The core board docks behind the chest window, and EoS brings the body up.

Concept · assembled from eRobotics datasheetsEvery part is an eRobotics design; the body itself is not a datasheet product

Concept · built from eRobotics partsEoS profile: robot
EoS · robot profile

The same board, docked in the chest

Profile in eosConcept body

The core board that toured the hall docks behind the chest window. It would boot EoS built with the robot product profile: 15 features, including motor control and sensors.

Features
15
Joints
30
GPIOUARTSPII2CtimerADCPWMwifiBLEcameramotorIMUnetsensormotor ctrl

eos · products/robot.h

EoS · boot order

EoS wakes the body

Kernel + init · working codeeBoot · host-tested

Power-on follows the same chain as the Chain of Trust story; then EoS brings the body up from the inside out, joint by joint.

Boot, step by step
  1. eBoot's stage-0 checks stage-1, which verifies the Ed25519-signed EoS image (host-tested; not yet booted on hardware).
  2. The kernel starts its priority scheduler, and the init service starts each service in dependency order, with restart policies and a watchdog.
  3. In this concept, sensors come up before motors, so every joint knows where it is before it may move.
eBootkernel schedulerinit servicesensor servicemotor service

eBoot · eos kernel/ · services/init

Parts, and what EoS does with them

  • Core boardEoS, robot product profileeBoot verifies the image; the kernel and services are working code.Working
  • Battery packConcept · 48 V classThe EoS power service is bookkeeping only today.In code

Full-body robot

  • eServo-200 ×26
  • eActuator-50 ×4
  • eGripper-3F ×2
  • eVision-4K
  • eLiDAR-360
  • robot profile
  • eBoot
  • init service
21 · Full-body robot

Two eyes for depth, one laser for the room

eVision-4K gives the head 4K stereo cameras with depth over Gigabit Ethernet. The eLiDAR-360 crown sweeps the whole hall: 360°, 100 m of range and 0.1° resolution. EoS would turn both into data the rest of the body can use.

From robot_components/product_datasheet.mdeVision-4K: 4K stereo + depth, GbE · eLiDAR-360: 100 m, 0.1°, Ethernet

Concept · built from eRobotics partsEoS profile: robot
eRobotics · eVision-4K

Stereo eyes with depth

Design stage

Two 4K cameras, a hand's width apart, see depth the way people do. The datasheet lists 4K stereo plus depth over Gigabit Ethernet.

How EoS would see
  1. EoS would read the cameras through its camera HAL class, a stub today.
  2. Frames would go to eAI for detection; eAI's default build returns stub inference.
Output
4Kstereo + depth
Link
GbE
camera HALEthernet HALeAI

eRobotics_CAD_Design/robot_components

eRobotics · eLiDAR-360

A full turn of laser range

Design stage

The crown sweeps the hall. Every dot is a simulated return from the floor, the pedestals and the designs standing on them.

How EoS would map the room
  1. EoS would take the point cloud over Ethernet; the radar/LiDAR HAL class is a stub today.
  2. The sensor service (working code) filters and calibrates up to 16 sensors, so a full point cloud would need its own path.
Range
100m
Resolution
0.1°
radar/LiDAR HALsensor servicesockets (host builds)

eRobotics_CAD_Design/robot_components

Parts, and what EoS does with them

  • eVision-4K4K stereo + depth over GbEThe camera HAL class is a stub today.Docs or descriptor
  • eLiDAR-360360°, 100 m range, 0.1° resolutionThe radar/LiDAR HAL class is a stub today.Docs or descriptor

Perception

  • camera HAL
  • radar/LiDAR HAL
  • Ethernet HAL
  • sensor service
  • eAI
22 · Full-body robot

Walking is a real-time job

Every step means reading the IMU and the 23-bit joint encoders, then updating every drive on time. Each eServo-200 closes its own 20 kHz current loop; EoS would run the joint loops and keep the balance task ahead of everything else.

From robot_components/product_datasheet.mdeServo-200: 200 W at 48 V, EtherCAT CoE (CiA 402), ±0.01° position accuracy

Concept · built from eRobotics partsEoS profile: robot
eRobotics · eServo-200

A servo drive in every joint

Design stage

Each rotary joint is an eServo-200 EtherCAT drive whose own STM32G474 closes a 20 kHz current loop. Two eActuator-50 push rods move each ankle.

How EoS would drive the joints
  1. EoS's motor service (working code) runs PID speed and position loops and trajectories for each motor.
  2. It tracks 8 motors per image today, so a 30-joint body needs that limit raised or one EoS controller per limb.
  3. EtherCAT itself is not in EoS yet.
Drives
26
Encoders
23bit
motor servicemotor HALEtherCAT

robot_components · eos services/motor

EoS · real time

Balance is a deadline

Kernel · working codeIMU HAL · stub

The amber ring is the centre of mass; the green outline is the support polygon under the feet. Keep one inside the other on every cycle, and the robot stays up.

How EoS would keep it upright
  1. The kernel's priority scheduler would run the balance task first, and priority-inheritance mutexes stop a slower task from blocking it.
  2. Message queues would carry joint targets from the planner to the motor task, paced by software timers.
  3. The IMU HAL class is a stub today; the kernel and the sensor service are working code.
priority schedulerPI mutexesmessage queuessoftware timersIMU HAL

eos kernel/src/task.c · sync.c · ipc.c

Parts, and what EoS does with them

  • eServo-200 · elbow200 W at 48 V, 23-bit encoderThe motor service runs PID position loops (working code); 8 motors per image today.Working
  • eServo-200 · kneeEtherCAT CoE, 20 kHz current loopEtherCAT itself is not in EoS yet.Not in the repos yet
  • eActuator-50 · ankle50 mm stroke, 500 N, CAN FDCAN is a HAL stub class today.Docs or descriptor
  • IMUBalance at the centre of massThe IMU HAL class is a stub; the sensor service is working code.Docs or descriptor

Real time

  • priority scheduler
  • PI mutexes
  • message queues
  • software timers
  • motor service
  • IMU HAL
  • EtherCAT
23 · Full-body robot

Hands that pick, check and place

Each hand is an eGripper-3F: three adaptive fingers, an 80 mm span and 50 N of grip, on RS-485. The robot picks up a part, lifts it to its eyes to check it, then places it in a tray.

From robot_components/product_datasheet.mdeGripper-3F: 3-finger adaptive gripper · 80 mm span · 50 N · RS-485

Concept · built from eRobotics partsEoS profile: robot
eRobotics · eGripper-3F

Three fingers that adapt

Design stage

Two fingers and an opposed thumb close around the part with up to 50 N and report back over RS-485.

How EoS would grip
  1. EoS would talk to the gripper over a UART-based RS-485 link; the UART driver is register code for STM32F4 only.
  2. The reach itself is a motor-service trajectory for each arm joint (working code).
Span
80mm
Grip
50N
UART HALmotor trajectories

eRobotics_CAD_Design/robot_components

EoS + eAI

Eyes guide the hand

eAI · stub inference

Before placing the part, the robot lifts it to its eyes and checks it with stereo depth.

What it would take
  1. Recognising the part is a job for eAI, the planned on-device AI layer; its default build returns stub inference today.
  2. The eNI → eIPC → eAI pipeline described in the docs is not wired up in code yet.
eAI runtimeeIPCcamera HAL

eAI · eIPC

Parts, and what EoS does with them

  • eGripper-3F3 fingers, 80 mm span, 50 NRS-485 through the UART driver (STM32F4 register code only).In code
  • eGripper-3F3 fingers, 80 mm span, 50 NGrasps are motor-service trajectories (working code).Working

Hands

  • eGripper-3F
  • UART HAL
  • motor trajectories
  • eAI
  • eIPC
24 · Full-body robot

Stops in one call, updates over the air

An emergency stop has to beat every other task. EoS's motor service stops a motor in one call, and the scheduler runs that task first. Afterwards, new firmware arrives over the air into the spare A/B slot, and eBoot checks its signature before switching.

From eos services/motor and services/otaeos_motor_ctrl_emergency_stop() · A/B slots with SHA-256 checks

Concept · built from eRobotics partsEoS profile: robot
EoS · motor service

Stop in one call

e-stop · working code

An emergency stop zeroes a motor's target speed, PID output and integrators in a single call, and every light on the body turns red.

How EoS would stop it
  1. eos_motor_ctrl_emergency_stop() is working code; a full-body stop would call it for every joint, then hold position.
  2. The eArm-7 datasheet targets ISO 10218-1 and IEC 62061 SIL 2 for the arm; a whole humanoid would need its own safety case.
e-stop callfunctional-safety case

eos services/motor/src/motor_ctrl.c

EoS · OTA + eBoot

Update without a cable

OTA · partialeBoot · host-tested

New firmware drops into the spare A/B slot. eBoot verifies its Ed25519 signature and version before switching, and can roll back.

How the update would land
  1. The EoS OTA service is an A/B state machine with SHA-256 checks; today it hashes chunks but does not write flash.
  2. eBoot's slot selection, signature checks and anti-rollback are host-tested and have not run on hardware yet.
OTA serviceeBoot A/B + rollbackEd25519 verify

eos services/ota · eBoot

Safety

  • e-stop call
  • watchdog
  • OTA A/B
  • eBoot rollback
  • Ed25519 verify
25 · Every industry

Eighteen domains, one open collection

Every design in this hall, and every part of the robot at its centre, is part of eCAD Hardware: 125 product lines and 292 named models. Each carries a datasheet, and most add a bill of materials and a power simulation. All are at design stage; no routed PCB or Gerbers yet. The repository is published under the MIT licence, except the original EoS development boards, which are all rights reserved, and the manufacturer designs mirrored under boards/cad, which keep their manufacturers' licences.

Ten future conceptseBCI-Lite, eCubeSat-1U, eEdu-Kit, eFarm, eHand, eHive, eHydro, eMeshGrid, eRover-Mini, eVision

eHealth365eosHealtheMedicaleRadar360eTransportePAMeAerospaceeRoboticseAgriTecheFrontiereIndustrialeEnergyeSmartCityeMiningeEdgeAIeElectronicseConsumereCybersecurityeDefenseFull-body robot
WorkingIn codeDocs or descriptorNot in the repos yet

Every design here is at design stage: a datasheet, most with a bill of materials and a power simulation; no routed PCB or Gerbers yet. Target standards are targets, not certifications held.

The making of

One board, end to end.

The EoS Learn RP2350 told through its own files: the schematic, the parts and what each one does, the four copper layers, the checks it passes, and what happens in its first second of boot. 1 min 23 s, silent. Jump to any part below.

0:00 / 1:23

EoS boards

Fifteen original boards.

Teaching boards, development boards, a debug probe and compute module carriers. Every one passes KiCad 10.0.6 with 0 ERC violations, 0 DRC errors and 0 unconnected items.

EoS Learn RP2350, ray-traced from its KiCad files

Teaching board

EoS Learn RP2350

A teaching board for the RP2350A, with every GPIO broken out in pin order.

Main chip
RP2350A
Size
52.6 × 51.6 mm
Layers
4
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • RP2350A with a 12 MHz crystal and 128 Mbit QSPI flash.
  • USB-C (5 V sink) with ESD protection, a polyfuse and a Schottky diode, so 5 V fed into the header can power the board but never reach the USB host.
  • All 30 GPIOs on two 1×20 headers in pin order, plus Qwiic, a 3-pin SWD debug connector, BOOTSEL and RUN buttons.
  • The RP2350A core layout is kept unchanged, checked at KiCad’s 1 nm resolution.
Open the design files

Development board

EoS ESP32 DevKit

A breadboard development board for the ESP32-WROOM-32E module, in an original design.

Main chip
ESP32-WROOM-32E module
Size
27.94 × 48.76 mm
Layers
2
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • USB-C in, a CP2102N USB-UART bridge with esptool’s automatic reset into the bootloader, a 1 A 3.3 V regulator, EN and BOOT buttons.
  • Every usable GPIO on two 1×19 headers, on the ESP32-DevKitC V4 grid.
  • Power from USB-C, the 5V pin or the 3V3 pin; the antenna keep-out lies off the board.
  • No mounting holes: it is meant for a breadboard or a socket.
Open the design files

Debug probe

EoS Probe S3

An ESP32-S3 debug probe for Arm SWD/JTAG targets and their UART, working at the target’s own I/O voltage from 1.65 to 5.5 V.

Main chip
ESP32-S3-WROOM-1 module
Size
62 × 30 mm
Layers
2
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • The target voltage is read from VTref through one level shifter per line; if either supply is off, both ports go high-impedance.
  • Arm 10-pin Cortex Debug header (1.27 mm) and a 1×4 UART header.
  • USB-C (5 V sink) with ESD protection and a polyfuse.
  • No firmware is included: the pins are assigned for CMSIS-DAP, but none has been ported or run.
Open the design files

Compute module carrier

EoS CM5 Base

A carrier board for Compute Module 5, with USB-C power, Gigabit Ethernet, a USB 2.0 host port, microSD and the 40-pin GPIO header.

Main chip
Compute Module 5
Size
90 × 80 mm
Layers
4
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • One USB-C for power in and USB 2.0 device (rpiboot flashing, gadget mode); the module negotiates its own power.
  • USB-A host, a Gigabit Ethernet MagJack, microSD (CM5 Lite) and the 40-pin GPIO header.
  • Fan connector with PWM and tacho, an RTC coin cell, a power button, power and activity LEDs.
  • Two 100-pin module connectors, all 200 pads checked at 1 nm; copper kept clear under the module antenna.
Open the design files

Compute module carrier

EoS CM4 Base

A carrier board for Compute Module 4.

Main chip
Compute Module 4
Size
90 × 80 mm
Layers
4
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • USB-C power in (5 V / 3 A sink).
  • One USB 2.0 port switched by jumper between USB-C (device: rpiboot flashing, gadget mode) and USB-A (host).
  • Gigabit Ethernet MagJack, microSD (CM4 Lite), the 40-pin GPIO header and a 5 V fan connector.
  • HDMI, PCIe and MIPI are left off on purpose.
Open the design files

PocketBeagle cape

EoS Sense Cape

A sensor cape for BeagleBoard.org PocketBeagle, its fit checked pin for pin against PocketBeagle’s own board file.

Main chip
BME280, LIS3DH, APDS-9306 sensors
Size
55 × 60 mm
Layers
2
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • BME280 (temperature, humidity, pressure), LIS3DH accelerometer and APDS-9306 ambient light on I2C1.
  • A 24LC256 EEPROM on I2C2 for cape identity.
  • An NTC, a trimmer, two buttons, two LEDs on PWM pins and Qwiic / STEMMA QT.
  • PocketBeagle plugs in on top; all 72 socket pads are checked at 1 nm.
Open the design files

FeatherWing

EoS Motion Wing

An accelerometer and temperature FeatherWing.

Main chip
ADXL343 accelerometer, ADT7410 temperature
Size
50.8 × 22.86 mm
Layers
2
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • An ADXL343 3-axis accelerometer and an ADT7410 16-bit temperature sensor share the Feather’s I2C bus.
  • I2C addresses selectable by jumper; pull-ups through a cuttable jumper.
  • Interrupt lines reach D5, D6, D10 and D11 through solder jumpers.
  • Outline and headers follow Adafruit’s Feather Specification.
Open the design files

Development board

EoS STM32 64

A 3.3 V Cortex-M4F board in the Nucleo-64 format, with morpho and Uno headers and an external debug connection.

Main chip
ST STM32F411RE (Cortex-M4F)
Size
70 × 82.5 mm
Layers
2
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • STM32F411RET6 with 8 MHz and 32.768 kHz crystals.
  • Arduino Uno V3 headers and both ST morpho headers where a Nucleo-64 has them, with the same signals.
  • Two USB-C ports: a CP2102N serial bridge, and the MCU’s own USB for ROM DFU flashing with no probe.
  • A 10-pin Cortex Debug connector replaces ST-LINK.
Open the design files

Development board

EoS LPC55S69 Board

A dual Cortex-M33 board with Uno R3 shield headers, full-speed USB, a serial bridge and external SWD.

Main chip
NXP LPC55S69 (dual Cortex-M33)
Size
68.58 × 53.34 mm
Layers
4
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • LPC55S69JBD100 with 16 MHz and 32.768 kHz crystals.
  • Two USB-C sinks feed a power mux; full-speed USB0 on one, a CP2102N debug UART on the other.
  • An Arm 10-pin SWD header replaces LPC-Link2.
  • Uno R3 headers at 3.3 V logic, an RGB LED, reset, ISP and user buttons.
Open the design files

Development board

EoS TM4C123 Board

A BoosterPack-compatible (40-pin) development board for the TI TM4C123GH6PM.

Main chip
TI TM4C123GH6PM (Cortex-M4F)
Size
50.8 × 60 mm
Layers
2
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • A USB-C device port on the MCU’s own USB and a second USB-C with a CP2102N on UART0.
  • A jumper picks which port powers the board, so one host never feeds the other.
  • Arm Cortex Debug 10-pin header (SWD/JTAG); TI’s ICDI is not on the board.
  • RGB LED, user, reset and WAKE buttons, four BoosterPack headers.
Open the design files

Development board

EoS KL25 Board

An NXP Kinetis KL25 development board that fits Uno R3 shields.

Main chip
NXP MKL25Z128 (Cortex-M0+)
Size
68.58 × 53.34 mm
Layers
2
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • The KL25’s own full-speed USB on one USB-C port, a CP2102N USB-UART bridge on a second.
  • An 8 MHz crystal, an RGB LED, a LIS2HH12 accelerometer and a reset button.
  • An Arm Cortex 10-pin SWD header in place of OpenSDA.
  • 3.3 V I/O: use 3.3 V shields, or shields that follow IOREF.
Open the design files

Development board

EoS ATmega328P Board

An ATmega328P development board that fits Uno R3 shields.

Main chip
Microchip ATmega328P
Size
68.58 × 53.34 mm
Layers
2
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • ATmega328P-AU at 16 MHz from 5 V.
  • Power from USB-C or a 7–12 V barrel jack, with a power mux that blocks reverse current.
  • A CH340C bridges USB to the UART and resets the MCU from DTR, so sketches upload over USB the usual way.
  • Not an Arduino product; no bootloader is included or tested.
Open the design files

Development board

EoS MSP430G2 Board

A BoosterPack-compatible (20-pin) MSP430G2553 board with the chip in a DIP-20 socket.

Main chip
TI MSP430G2553
Size
56 × 80 mm
Layers
2
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • The socketed chip can be swapped, or programmed here and moved to another board.
  • Two 1×10 BoosterPack headers; USB-C feeds a CP2102N serial bridge and an LDO.
  • A 14-pin MSP-FET connector (Spy-Bi-Wire) takes the place of TI’s eZ-FET.
  • A jumper lets an ammeter measure the MCU alone.
Open the design files

Development board

EoS KE16Z Board

An NXP Kinetis KE16Z development board that fits Uno R3 shields.

Main chip
NXP MKE16Z64
Size
68.58 × 53.34 mm
Layers
2
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • Cortex-M0+ at 48 MHz, 64 KB flash, 8 KB SRAM, MSCAN.
  • A USB-C port with a CP2102N USB-UART bridge on the Uno’s D0/D1 pins.
  • An Arm Cortex 10-pin SWD header in place of OpenSDA; MSCAN pins broken out for a CAN transceiver.
  • 3.3 V I/O; VIN is not connected.
Open the design files

Development board

EoS RA2E1 Board

A Renesas RA2E1 development board that fits Arduino Uno R3 shields and Digilent Pmod modules.

Main chip
Renesas RA2E1 (Cortex-M23)
Size
68.58 × 53.34 mm
Layers
2
KiCad 10.0.6
0 ERC · 0 DRC · 0 unconnected
  • Runs at 3.3 V from the RA2E1’s 48 MHz on-chip oscillator; no main crystal.
  • One USB-C powers the board and carries a CP2102N bridge: the console and, with the MD jumper fitted, the flash programmer.
  • An Arm 10-pin SWD header replaces the J-Link OB.
  • Two Pmod host ports (SPI and I²C, 3.3 V only).
Open the design files
15 boards · ray-traced from their KiCad files
Design files, not yet manufactured or bench-tested. Board designs © Kartikeydheer Srivastava, all rights reserved; EmbeddedOS may use them.Native KiCad files on GitHub →

Talk to the team

Schedule a call.

A 30-minute video call with the people who build EmbeddedOS: the kernel, the tools and the boards.

Mention your topic in the booking form so the right people join.

  • Platform demoA walk through the EoS kernel, eBoot and the tools, on your use case.
  • Partnership or OEMRunning EmbeddedOS on your hardware, or building it into your product.
  • Research collaborationJoint projects, grant proposals and papers on embedded systems.
  • University or educationCourse labs, student projects and teaching with EmbeddedOS.
  • EoS boards and hardwareEvaluating, licensing or manufacturing an EmbeddedOS board.

EmbeddedOS Ecosystem

EoS KernelCoreeBootSecurityeIPCPlatformeAIAIeosllmAIeNINeuraleDBDataeAppsAppseBrowserUIeOfficeAppsebuildBuildEoStudioIDEEoSimSimulationeCAD HardwareHardwareKids EditionEducationeNetPlannedeSecPlanned

23

Repositories

83

Boards

300+

APIs

60+

Apps

4

Health devices

14

Books

The board, part by part

Every component, and the bus that reaches it

Click or tap any part. U1 runs EoS; every other part hangs off its own bus, and each says how EoS uses it today. The board is illustrative; the statuses come from the code.

EMBEDDEDOS · EoS REFERENCE · REV A

Our Mission

Embedded computing should be free to learn and free to build on

The Embedded Operating Systems Research Foundation is a 501(c)(3) public charity (EIN 41-4821627). We exist to advance open-source embedded systems research, education, and technology for the public benefit, accountable to our community, not to shareholders. Every line of code we publish is MIT licensed and free, forever.

  • Open-source software, permanently free

    The kernel, bootloader, drivers, build tools, and every application we ship are MIT licensed and developed in public on GitHub. No paid tiers, no license fees, no vendor lock-in.

  • Free education for engineers and students

    14 full-length technical books, free certification exams, a Kids Edition for classrooms, and paid internships for students and new graduates, all at no cost to learners.

  • Public-benefit research

    We publish our research openly, including patent filings for health-monitoring hardware, so that clinicians, universities, and other nonprofits can build on the work rather than license it.

Architecture and maturity

An Illustrative Reference Architecture

Seven layers, the same ones you scrolled through, each with what is built and tested and what is still planned. Illustrative reference only. Individual projects and integrations have different maturity levels; planned elements are not yet available products.

eBoot

Two-stage secure boot: Ed25519 + SHA-512 image check, A/B slots and recovery. Host-tested; key storage needs board hooks.

WorkingKeys: board hooks

EoS HAL

One driver API on every target. The dispatch layer, GPIO on Linux and the devicetree parser work; 28 extended classes are stubs.

Dispatch28 stubs

EoS kernel

Priority scheduler, priority-inheritance mutexes, semaphores, events, queues and a validated heap. 45 CTest suites on hosts.

Working

EoS services

18 libraries: motor and sensor control, OTA, crypto, networking, files and debug. Flash writes and an MCU network stack are planned.

In codeSome planned

eIPC · eDB

Authenticated messages between services and devices; a multi-model data store with 38 endpoints. Both are working prototypes.

Prototypes

Apps

The eApps catalogue (124 entries), the eBrowser engine and 11 eOffice apps; packages install as verified .eapp files. Many apps are templates.

In codeTemplates

On-device AI

eosllm runs models with three real back ends; eNI works in simulation; eAI's runtimes are placeholders today.

eosllmeAI runtimes

The ecosystem

The Complete Embedded Ecosystem

Every component you need to build, deploy and manage embedded systems, each described as it stands in its repository today.

On the device9 repositories

  • eBootWorking

    Signed two-stage boot with A/B slots and recovery; not yet booted on hardware.

  • EoS kernelWorking

    Real-time kernel with priority scheduling, sync and queues; tested on hosts.

  • eIPCPrototype

    Authenticated messages between processes and devices; Go core and a C SDK.

  • eDBPrototype

    Multi-model data store: five models, 38 endpoints, 42 passing tests.

  • eosllmWorking

    Runs language models on the device with three real back ends; 160 tests.

  • eAIFramework

    The on-device AI layer; its model runtimes are placeholders today.

  • eBrowserEngine

    Browser engine for embedded displays; JavaScript and the sandbox are planned.

  • eOfficePrototype

    11 office apps with 741 tests.

  • eAppsCatalogue

    124 catalogue entries; many apps are templates.

To build and test it3 repositories

  • ebuildWorking

    One CLI to create, build, flash and simulate; knows 171 MCUs, 826 tests.

  • EoStudio7 of 13

    Design studio and IDE: 7 of its 13 editors are real; 40 code generators.

  • EoSimWorking

    Simulator with 153 platforms and 2,117 passing tests.

Health Technology

4 Health Devices · 2 Patents Pending

In-development open hardware designs for health-monitoring research. Physical reliability and clinical validation are pending.

All four designs
  1. 01

    HEALTH-KEY ULTRA

    A USB-C research design for exploring ECG, blood-oxygen, breath-alcohol, temperature, UV and motion sensing. Validation is pending.

    Patent pendingU.S. App. No. 64/073,334

  2. 02

    HEALTH-BAND Neuro

    A wristband research design for sEMG gesture studies, biometric sensing and TENS exploration. No therapeutic benefit is claimed.

    Patent pendingU.S. App. No. 64/076,078

  3. 03

    HEALTH-RING

    A concept ring for researching optical and electrical sensing. Clinical measurement has not been validated.

    ConceptResearch design

  4. 04

    HEALTH-LAB

    A biosensor patch concept for health-monitoring research.

    ConceptResearch design

Open Hardware

eCAD Hardware · 18 domains, 292 models

Open designs from smart rings to a tilt-rotor eVTOL, in 125 product lines. Every one is at design stage with a datasheet, and most add a bill of materials and a power simulation. A dev-board CAD database adds 322 reference boards, 186 of them verified.

View all eCAD Hardware

Why EmbeddedOS

The Operating System for Every Device

Built by embedded engineers, for any embedded hardware. Every design decision prioritizes reliability, security, and developer experience.

  • Real-Time Scheduling

    Priority-driven scheduling with priority inheritance; timing is characterized per target.

  • Signed From the First Instruction

    Ed25519-signed boot and authenticated messages; hardware key storage needs board hooks.

  • Connectivity, Honestly

    Wi-Fi, BLE, Ethernet and CAN are defined in the HAL; sockets work on hosts and MCU stacks are planned.

  • Developer Friendly

    ebuild, EoStudio and EoSim, 14 technical books, documentation and free certification.

  • Modular Architecture

    Use only what you need, from the bare kernel to the full application stack.

  • Broad Hardware Coverage

    83 board descriptors across 55 architectures. Maturity varies by target; a descriptor is not a validated port.

Foundation Community

Built by the Community, for the Community

EmbeddedOS is a 501(c)(3), community-driven project, built by embedded engineers for any embedded hardware. Every line of code, every document, and every tool prioritizes reliability, security, and developer experience.

  • 25 repositories in public

    Developed openly on GitHub, 23 of them MIT licensed.

  • 14 books to learn from

    Full-length technical books, free for everyone.

  • 10 fuzz harnesses

    Plus CodeQL and Scorecard across the organisation.

  • Every claim checked

    This page says what works, what is partial and what is planned.

Open Source · 501(c)(3) · MIT License (software)

Ready to build on EmbeddedOS?

Join engineers building the next generation of embedded systems. Free, foundation-backed, and 501(c)(3) forever.