Shenzhen Xiao R Geek Technology (XiaoR GEEK) SamuRoid is a 22-DOF bionic humanoid robot built around a Raspberry Pi 4 Model B. Designed for researchers, educators, and robotics developers, the robot combines a traditional Robot Operating System (ROS) environment with modern embodied AI capabilities.

The concept of SBC-powered humanoid robots is not new, and we have previously seen similar robots, such as the Tonybot and PiMecha, which focused on basic servo control, OpenCV vision, and beginner-friendly programming. Compared to those, SamuRoid is priced significantly higher but offers a more advanced setup with tighter hardware-software integration and support for multimodal interaction that combines vision, voice, and large language models. We have also seen a simpler, but larger bipedal robot like the Mini π.

SamuRoid specifications

• SBC – Raspberry Pi 4 Model B (4GB or 8GB RAM options)
• Actuators – 22x XRS-series bus servos delivering ≥ 30 kgf · cm of torque at 12V
  • 2x for head
  • 2x for shoulders
  • 4x for arms
  • 2x for hands
  • 10x for legs
  • 2x for feet
• Display – 0.96-inch OLED screen for IP address, battery level, current status, and mode
• Camera – 1080p wide-angle camera on a 2-DOF gimbal (170° Field of View (FOV) with 180° Pan and 130° Tilt)
• Audio – Built-in USB Microphone for voice commands
• Connectivity – Dual-band 802.11 b/g/n/ac WiFi 5 and Bluetooth 5.0 (via Raspberry Pi 4)
• Sensors – MPU6050 6-axis IMU for self-balancing,
• Expansion – PWR.ROSBOT.X expansion board that breaks out all 40 Raspberry Pi GPIO pins, supporting over 40 additional modular sensors
• Misc
  • 3x buttons (Mode switch, function, self-check, or custom)
  • Support for PS2 Controller input
• Power – 12V/3,000mAh Lithium Battery yielding approximately 1 hour of runtime
• Dimensions – 389.81 x 190.98 x 141.6 mm
• Weight – 2.3 kg

The SamuRoid features an aluminum alloy chassis and XRS-series high-voltage serial bus servos (specifically the XR-S270 and XR-S15HV models), which have metal gears, aluminum casings for heat dissipation, and built-in protection against temperature, voltage, and stalling.

The robot also features a dual-hip-joint “yaw” design that allows leg rotation along the Z-axis, improving turning ability and agility, and making its walking motion more natural. It also includes mechanical grippers on both hands with open/close functionality and built-in overload protection, enabling safe and effective pick-and-place tasks.

To keep the Raspberry Pi stable under heavy computational loads, the humanoid robot includes a “Hurricane” cooling design. Additionally, a built-in MPU6050 6-axis IMU continuously monitors posture in real time. Combined with an inverted pendulum algorithm, this allows the robot to tune its gait in real-time and automatically recover if it falls over. It also features automatic self-diagnostics at startup, checking components like servos, camera, controller, and IMU. If an issue is found, the robot alerts the user with voice prompts and visual indicators.

The robot runs on Ubuntu 18.04 with the ROS Melodic framework; both are now end-of-life but still widely used for stable robotics education. It supports programming in Python and C++, along with RoboManager PC software or mobile app, which enables easy drag-and-drop motion programming without coding, including real-time joint feedback on angle, voltage, and temperature. The samurai-like robot comes preloaded with over 70 built-in actions, such as martial arts, dancing, and greetings, and is backed by 10 structured learning modules, covering everything from a quick-start guide to OpenCV vision courses and large language model (LLM) experiments. More information about the software and download links can be found on GitHub.

The robot uses a 1080p wide-angle camera on a 2-DOF pan-tilt gimbal for vision, powered by OpenCV. It can handle tasks like line following, object sorting, face recognition, color tracking, and target detection. With cloud-based LLM (DeepSeek, Doubao, and Tongyi Qianwen) integration, it combines voice, vision, and reasoning for real-time interaction. Using its microphone and speaker, it can understand commands, analyze scenes, recognize objects, and respond through natural voice conversations while performing actions.

The SamuRoid “Professional Edition” is currently available and sold for $1,565.92 on AliExpress, where the Developer Edition ($1,794.54) and the Flagship Edition ($2,019.10) are also listed with accessories like a keyboard, gamepad, and 7-inch display, but both are currently out of stock. Alternatively, the robot is available from the XiaoR GEEK store for $1,072.55 (base package only), which includes the fully assembled robot, charger, controller, SD card reader, and accessories.

The post SamuRoid – A Raspberry Pi-powered 22-DOF humanoid robot with Multimodal LLMs and ROS support appeared first on CNX Software - Embedded Systems News.

Challenger+ RP2350 NB-IoT is a Feather-compatible board pairing a Raspberry Pi RP2350 microcontroller and a certified NB-IoT cellular module with built-in GNSS, suitable for long-range, low-power connectivity.

It looks to be a variant of the earlier Challenger+ RP2350 WiFi6/BLE5 board that replaces an ESP32-C6 WiFi 6, BLE, and 802.15.4 module with an STMicroelectronics ST87M01 NB-IoT and GNSS module. It still offers

Challenger+ RP2350 NB-IoT specifications:

• Microcontroller – Raspberry Pi RP2350A MCU
  • CPU
    • Dual-core Arm Cortex-M33 processor @ 150MHz
    • Dual-core 32-bit RISC-V processor @ 150MHz
    • Up to two cores can be used at a given time
  • Memory – 520KB internal RAM
  • 8KB OTP Storage
  • Package – QFN-60; 7×7 mm
• Memory – 8MB PSRAM
• Storage – 8MB SPI flash
• Cellular connectivity
  • Module – STMicro ST87M01-1301
    • LTE Cat NB2 (NB-IoT), 3GPP Release 15
    • Worldwide regional bands coverage – B1, B3, B5, B8, B20, and B28
    • Single-tone / Multi-tone / Extended TBS and 2 HARQ
    • Data rate – Up to DL: 127 kbps, UL: 159 kbps
    • Up to +23 dBm power output
    • Low power
      • eDRX and PSM support
      • Sleep current of 1.2 µA (PSM), dropping to 0.5 µA in power-off mode (eDRX)
    • Location
      • GPS L1 and Galileo
      • Assisted GNSS available over the NB-IoT link for fast first fix.
      • Wi-Fi positioning via 802.11b access point scanning for indoor location fallback
    • Package – 12.8 x 10.6 mm (LGA-51)
  • Nano SIM card slot; optional 1NCE IoT SIM card with 500 MB data, 250 SMS
  • Antennas – 2x IPEX connectors for cellular and GNSS antennas
• USB – USB 1.1 Type-C (12 Mbps) port for power, data, and programming
• Expansion
  • 16-pin + 12-pin headers
    • Up to 20x GPIO
    • 1x SPI, 1x I2C, 1x UART
    • 4x analog inputs
    • All pins can be used as PWM
    • Reset and Enable signals
    • VUSB (5V), 3.3V, VBAT, and GND
  • 2x BConnect connectors: 1x I2C, 1x SWD + UART
• Misc
  • Reset and Boot buttons
  • Charging LED, user LED
• Power Supply
  • 5V via USB-C port or VUSB pin
  • 1.25mm pitch JST connector for 3.7V LiPo battery
  • Onboard LiPo charger with 500mA standard charge current
• Dimensions – 50.8 x 22.9 (Adafruit Feather form factor)
• Weight – 9 grams
• Certifications – GCF, RED (EU), RED-DA, RoHS

The Challenger+ RP2350 NB-IoT board can be programmed with the Arduino IDE and CircuitPython, but it also supports the Raspberry Pi Pico C and MicroPython SDK. Firmware updates are supported both over-the-air via Differential FOTA over LwM2M and locally over UART. Code samples are coming soon, and you can find work-in-progress documentation for the Challenger+ RP2350 NB-IoT board itself and the STM87M01 NB-IoT module in particular on the product page/store linked at the end of this article.

Target applications include asset tracking and logistics, smart metering (water, gas, electricity), Smart City infrastructure (e.g., street lighting control), Industrial IoT monitoring and factory automation, environmental sensing with long-interval reporting, and remote alarm and event notification systems. It’s the first RP2350 board with NB-IoT connectivity I’ve seen, and the closest alternative I can think of is the Walter ESP32-S3 board with a Sequans GM02SP NB-IoT & GNSS modem.

The Challenger+ RP2350 NB-IoT board is sold for 549 Swedish Kronas, or about $60 US, on the iLABs store. As I understand it, the antenna is not included, but you can add an LTE antenna for 68 kr (~$7.5 US). I’m less clear about the GPS antenna, and it appears you are expected to source your own.

The post Raspberry Pi RP2350 board offers NB-IoT cellular connectivity, GNSS, and Wi-Fi indoor location appeared first on CNX Software - Embedded Systems News.

LeafKVM is a wireless and PoE open-source hardware IP KVM based on Rockchip RV1126B SoC with 512MB RAM and a microSD card slot for storage. Like other IP KVMs, it enables remote access to computers and servers, even at the BIOS level or when the machine is unresponsive, by emulating keyboard, mouse, and video through HDMI/VGA and USB ports.

Other features include a 2.4-inch touchscreen display for configuration and guest video mirroring, a USB-C port for serial debug, a USB Type-A port for expansion (e.g., power control), and an ultra-low latency of less than 100ms.

LeafKVM specifications:

• SoC – Rockchip RV1126B
  • CPU – Quad-core Arm Cortex-A53 up to 1.6 GHz
  • GPU – 2D Graphics Engine
  • VPU
    • Video Decoder – H.265/H.264 up to 3840×2160 @ 30fps
    • Video Encoder  – H.265, H.264, JPEG up to 12Mbps @ 30fps
    • JPEG Decoder
  • AI accelerator – Rockchip NPU engine up to 3 TOPS (INT8); likely not used in the KVM
• System Memory – 512 MB DDR3L
• Storage – MicroSD card slot
• Display – Built-in 2.4-inch touchscreen display
• Video capture
  • HDMI input port up to 4Kp30 compatible with HDMI and DVI
  • Optional VGA adapter
  • Lontium LT6911C CSI video bridge
  • 4Kp30 or 1080p90 H.264 or H.265 video encoding and Opus audio encoding
  • Low latency of less than 100 ms
• Networking
  • 10/100 Mbps Fast Ethernet RJ45 port with PoE support (IEEE 802.3af)
  • WiFi 5 and Bluetooth via RealTek RTL8821CS module
• USB
  • USB Type-C “Aux” port for serial debug + power
  • USB Type-C “Control” port for keyboard + mouse + mass storage emulation (HTTP mount only) + power
  • USB Type-A port for expansion
• Misc
  • ESD protection + EMI filtering on all ports
  • Rugged CNC‑milled aluminum for passive cooling
• Power Supply
  • 5V/1A via USB-C port
  • 37-57V PoE (802.3af) via Ethernet port
  • Power consumption @ 5V
    • Idle – ~250 mA with Wi‑Fi or Ethernet connected
    • Active video input – Up to ~400 mA
• Dimensions – 90 × 65 × 25 mm
• Weight – 195 grams

The LeafKVM runs a Buildroot-based Linux distribution with a Rust control backend and a lightweight web frontend. It also supports OTA firmware upgrades. It does not require any special software since you can access it through a web browser, and for remote access, Tailscale VPN is supported. Alternatively, you can also use the RustDesk open-source app on a PC or a mobile phone. If you have really good eyes, you could also make use of the 2.4-inch interface for control. Check the bottom left screenshot, or watch the video at the end of the post. The documentation has more details to get started.

The market for low-cost IP KVM has exploded in recent years, with products such as JetKVM, PiKVM, Sipeed NanoKVM series, and GL.iNet Comet Pro. I often receive emails about alternatives from smaller companies, but for security reasons, it’s safer to go with the more popular or open-source projects, since it’s easy to get things wrong, inadvertently giving access to customers’ hardware over the Internet to bad actors. The LeafKVM was compared to some of the most popular projects that also come with a built-in display.

The main benefit of the LeafKVM IP KVM is that the software will be fully open-source, and the hardware will also be somewhat open since the schematics (PDF?) will also be released. It’s also the only solution to provide Debug UART access through USB-Cm and its display is a little larger than competitors. One potential downside not shown in the table above is the lack of support for power control, and the USB-A port is mainly used for external storage and cellular dongles, rather than power accessories like a Fingerbot or an ATX power control board. It would just require a software update, so it might be implemented over time. An oddity is that US users won’t be able to mount ISO files from mass storage due to patent issues, and the LeafKVM only supports HTTP ISO mount in the United States…

The LeafKVM has just been launched on Crowd Supply with a $10,000 funding target. A $119 pledge is asked for the LeafKVM with a 1 GB microSD card, an HDMI video cable, and a USB Type-A to Type-C cable, while the optional HDMI to VGA adapter adds $19. Shipping is free to the US and $12 to the rest of the world. Deliveries are scheduled to start by mid January 2027.

The post LeafKVM open-source hardware IP KVM offers WiFi 5, PoE, USB-C serial console, and 2.4-inch touchscreen display (Crowdfunding) appeared first on CNX Software - Embedded Systems News.

Waveshare UGV Beast is an off-road robot with tracked wheels designed for Raspberry Pi 4 or 5 SBC handling AI vision and strategy planning, while an ESP32 sub-controller takes care of motion control and sensor data processing.

If the design feels familiar, it’s because it’s a variant of the UGV Rover unmanned ground vehicle we covered in 2024, which replaces the six wheels of the original model with two continuous tracks, as found in military tanks, for better driving in difficult terrain.

Waveshare UGV Beast specifications:

• Supported SBCs – Raspberry Pi 4B or Raspberry Pi 5
• Multi-function driver board/sub-controller
  • Main SoC – ESP32 wireless microcontroller with WiFi, Bluetooth, ESPNOW connectivity
  • Motor drivers – 2x TB6612FNG chips
  • Peripheral interfaces
    • 4x motor control connectors
    • 2x servo connectors
    • Lidar USB (4-pin) and UART (USB-C) connectors
    • 2x 4-pin I2C connectors
  • Sensor – 9-axis attitude sensor (ICM20948) for image stabilization
  • Misc – EN and user buttons
  • Power
    • 2x 12V switch controllers by ESP32 IO4 and IO5 pins
    • Battery voltage monitoring via INA219
• Audio driver board
  • SSS1629A5 USB audio chip
  • APA2068 audio amplifier
  • Stereo speaker
  • Stereo microphone
  • 3.5mm audio jack
  • USB-C port
  • 4-pin Lidar UART interface
• Pan-and-tilt camera  (optional)
  • 5MP camera with 160° FoV
  • ST3215 servo with 30kg.cm torque
  • DoF – 2 (pan and tilt)
  • 360° horizontal and 120° vertical rotation
  • High-brightness LED light for clear images in low-light conditions
• Connectivity
  • Gigabit Ethernet, WiFi 5, and Bluetooth 5 on Raspberry Pi 4/5 SBC
  • 2.4 GHz WiFi and Bluetooth on ESP32, including ESP-NOW support
  • Optional 4G LTE/5G cellular module
• Expansion – 40-pin GPIO header
• Mechanical features
  • 2mm thick aluminum alloy body
  • 2x 1020 European standard profile rails for peripherals, including D500 lidar, STL-27L lidar, and pan-and-tilt camera.
  • Suspension material – Stainless steel
  • 2x continuous wheels
    • Track width – 40mm
    • Minimum turning radius – 0M (In-situ rotation)
    • Default Max speed – 0.35m/s, or 1.26 km/h
  • Smartphone holder support
• Power Options
  • Holder for 3x 18650 Lithium batteries
  • 3S UPS module
• Dimensions and Weight
  • Without camera – 232×197×122mm | 2.034 kg
  • With PT camera – 232×197×252mm | 2.35 kg

The Raspberry Pi 4/5 SBC runs Debian Bookworm  (I assume Raspberry Pi OS) and ROS2-HUMBLE-LTS. No app is required, and instead, the UGV Beast can be controlled from a smartphone, tablet, or computer through a web browser. Waveshare explains that they implemented a lightweight Flask web application with WebRTC ultra-low latency real-time transmission. The company also mentions that JupyterLab is used for interactive tutorials, graphic tutorials, and video tutorials, but that part appears to be under construction (it’s empty).

The robot can also be programmed with Python. OpenCV is supported for color recognition, automatic targeting, face recognition, gesture control, line tracking, and more. The OpenCV library and MediaPipe open-source framework can also be combined for more complex computer vision applications and real-time video analytics. The company also highlights support for the ESP-NOW peer-to-peer communication protocol for low-latency robot-to-robot communication. More details about software resources and tutorials are available on the wiki.

It’s not the first tracked wheel robot we’ve covered here, and alternatives include the Raspberry Pi CM4-powered Doly robot and the Arduino-compatible Makeblock Ultimate 2.0 educational robot kit. However, those are for indoor use only, and the UGV Beast is a larger Raspberry Pi 4/5 robot with off-road capabilities and additional features.

The UGV Beast chassis starts at about $360 on AliExpress and $370 on Amazon without a Raspberry Pi 4/5 and camera. However, the company also sells kits with a PT camera, and full kits with the camera and Raspberry Pi 4 or 5 reloaded with ROS2 for up to $591.55 on AliExpress (same link) and $899.99 on Amazon, where I can also see a NVIDIA Jetson Orin Nano 4GB kit for about $1200. Alternatively, it’s also available directly on the Waveshare shop for $264.99 to $500.99 plus shipping.

The post UGV Beast – An off-road tracked AI robot built for Raspberry Pi 4/5 appeared first on CNX Software - Embedded Systems News.

SendspinZero is an open-source, DIY Sendspin audio receiver for your amplifier that relies on off-the-shelf parts costing around $10 and a 3D printed enclosure. It integrates with Home Assistant for multi-room audio synchronization.

It sounds good, but what is Sendspin exactly? It’s a royalty-free, open protocol developed by the Open Home Foundation for synchronized audio playback across multiple devices and rooms. Besides audio, it also supports screens for album art and control music, and sound-activated lights (coming soon feature). The protocol enables open-source products that compete against proprietary systems like Sonos, AirPlay, or Google Cast, and integrates nicely with the Music Assistant add-on for Home Assistant.

Sendspin audio receiver key components:

• Waveshare ESP32-S3-Zero board with 2MB PSRAM (About $4-$6 on AliExpress, $12 on Amazon), ideally the version without pre-soldered headers
• Optional 1.54-inch LCD screen (About $5 on AliExpress)
• Optional 3-6V, 22mm bi-color button (About $2 to $3)
• Audio output options:
  • 3.5mm audio jack using PCM5102A DAC board ($1-$2 on AliExpress)
  • Optional optical (A1) or coax S/PDIF (RCA) connector (the PCM5102A board is not used)
• A few wires…

Prices are approximate since I’m shown “welcome deals” for $0.99 for most items. The total for the display + 3.5mm audio jack module should be a little over $10 before taxes and shipping, unless you get discounts.

You can build nine different variants with three audio output options (Coax S/PDIF, Analog Stereo, optional S/PDIF) and no display, a 1.54-inch display, or a bicolor button.

You’ll also need a 3D printer for the case, and a soldering iron to solder the wires in a way that fits inside the enclosure. It doesn’t seem too complicated to reproduce, and you could also test it with a breadboard.

The ESP32-S3 board simply needs to run ESPHome with YAML configuration files for all nine versions and 3D files for the enclosures available on GitHub, along with detailed instructions.  If you scroll down, you’ll also find other variants, including a 1.9-inch display + bi-color button model, which looks pretty neat.

There’s no information about the Home Assistant + Music Assistant integration part on GitHub, and for that, you may want to check the official documentation.

Thanks to Hedda for the tip.

The post DIY Sendspin audio receiver supports multi-room audio synchronization, integrates with Home Assistant appeared first on CNX Software - Embedded Systems News.

Ezurio Tungsten 510 and Tungsten 700 SMARC 2.1 compliant system-on-module powered by MediaTek Genio 510 hexa-core and Genio 700  octa-core Cortex-A78/A55 AIoT SoCs with an up to 4 TOPS NPU.

The SMARC modules feature 4GB or 8GB LPDDR4 memory and 16GB flash by default (upgradeable up to 128GB), offer dual Gigabit Ethernet, WiFi 6 and Bluetooth 5.2 connectivity, and various interfaces exposed through a standard 314-pin MXM connector, including  HDMI, DisplayPort, eDP, and MIPI DSI display interfaces, two MIPI CSI camera interfaces, two I2S audio interface, PCIe Gen2 x1, and more.

Ezurio Tungsten 510/700 specifications:

• SoC (one or the other)
  • MediaTek Genio 510 (MT8370)
    • CPU – Hexa-core processor with 2x Arm Cortex-A78 core up to 2.2 GHz, 4x Cortex-A55 cores up to 2 GHz
    • GPU – Arm Mali-G57 MC2 GPU
    • VPU – 4Kp60 H.265, AV1, VP9, H.264 video decoding, 4Kp30 H.265 and H.264 video encoding
    • Accelerators – Up to 3.2 TOPS AI accelerator, HiFi5 audio DSP
  • MediaTek Genio 700 (MT8390)
    • CPU – Octa-core processor with 2x Arm Cortex-A78 core up to 2.2 GHz, 6x Cortex-A55 cores up to 2 GHz
    • GPU – Arm Mali-G57 MC3 GPU up to 950 MHz
    • VPU – 4Kp75 H.265, AV1, VP9, H.264 video decoding, 4Kp30 H.265 and H.264 video encoding
    • Accelerator – Up to 4.0 TOPS AI accelerator, HiFi 5 audio DSP
• System Memory – 4GB or 8GB LPDDR4-3200
• Storage – 16GB eMMC 5.1 flash with HS400 speed  (up to 128GB)
• Networking
  • KZS9031 Gigabit Ethernet controller (RGMII)
  • LAN8750 USB 2.0 “Gigabit” Ethernet controller (so limited to around 400 Mbps)
  • Sona MT320 module based on MT7921 WiFi 6 and Bluetooth 5.2 chipset
• 314-pin MXM edge connector
  • Storage – 4-bit SDIO
  • Display
    • HDMI 2.0b up to 4Kp60
    • DisplayPort 1.4 up to 4K60 (10-bit)
    • embedded DisplayPort 1.2 interface up to 1920×1440 @ 60Hz
    • 2x 4-lane MIPI DSI interfaces (one DSI multiplexed with eDP)
  • Camera
    • 2x 4-lane MIPI CSI interfaces
    • Single camera: 32MP @ 30fps
    • Dual camera: 16MP + 16MP @ 30fps
    • Video High Dynamic Range (HDR) with stagger HDR sensor: up to 16 MP at 30 fps
  • Audio – 2x I2S interfaces
  • Networking – 2x Gigabit Ethernet interfaces
  • USB – 2x USB 3.0, 2x USB 2.0, 1x USB 2.0 OTG
  • PCIe – PCIe Gen2 x1
  • Low-speed I/Os – 3x UART, 5x I2C, 3x SPI
• Debug Interface  – JTAG connector
• Security – Arm TrustZone
• Misc – 2x MHF4 connectors: main antenna for Wi-Fi and BT; aux antenna for Wi-Fi only
• Power Supply
  • 5V via edge connector
  • MT6319 + MT6365 PMICs
• Dimensions – 82 x 50 (SMARC 2.1 form factor)
• Temperature Range – Commercial: 0°C to +70°C; industrial: -40°C to +85°C

The company provides support for Android, Yocto Linux, and Buildroot Linux, as well as Zephyr RTOS and FreeRTOS. The modules were introduced a few months ago, but I found the Genio 510/700 SoM in the recent Linux 7.0 release, meaning it’s supported, at least partially, in mainline Linux. You’ll find hardware and software documentation on the support website.

Ezurio also provides a “Universal SMARC Carrier Board” called “SMARC_CAR_BRD” providing access to all I/Os from the system-on-module, including the display and dual GbE interfaces. The company also offers a kit with antennas, a power supply, and a DB9 cable.

It’s not quite the first SMARC system-on-module based on the MediaTek Genio 510/700 SoCs, but the Tungsten 510/700 provides an alternative to products such as the SECO SOM-SMARC-Genio500/SOM-SMARC-Genio700 and VIA SOM-5000, and a range of other Genio SoMs in different form factors.

The Ezurio Tungsten 510 SoM starts at $148.21 per unit for 1K orders (4GB RAM, 16GB flash, no wireless, commercial-grade variant), and the Tungsten 700 SoM at $178.46 in the same configuration, but the company mentions the modules can be sold for as low as $79 and $96, I assume in higher quantities. The SMARC_CAR kit goes for $219 without a module. More details may be found on the product page.

The post Ezurio Tungsten 510/700 SMARC SoM features MediaTek Genio 510/700 AIoT SoC, dual GbE, WiFi 6 appeared first on CNX Software - Embedded Systems News.

LILYGO’s T-Watch Ultra is an ESP32-S3-based smartwatch development platform that appears to be an upgrade over the previous T-Watch-S3 Plus (1.3-inch display and a 940mAh battery), with a larger 2.01-inch AMOLED touch display, a higher-capacity 1,100mAh battery, and an IP65 waterproof and dustproof rating.

The device integrates a u-blox MIA-M10Q GNSS module for positioning, a SX1262 LoRa transceiver for long-range communication, and a Bosch BHI260AP smart sensor for motion-based AI applications. Additionally, it features an RTC chip, NFC, a built-in microphone, a haptic driver, a microSD card slot, and a USB Type-C port for programming and charging. The watch targets applications such as Meshtastic nodes, GPS tracking, wearable IoT interfaces, edge AI sensing, and custom smartwatch firmware development.

LILYGO T-Watch Ultra specifications:

• SoC – Espressif ESP32-S3R8
  • CPU – Dual-core Tensilica LX7 microcontroller up to 240 MHz with vector instructions for AI acceleration
  • Memory – 512KB SRAM, 8MB PSRAM
  • Wireless – WiFi 4 and Bluetooth 5.0 LE + Mesh connectivity
• Storage
  • 16MB QSPI flash
  • MicroSD card slot
• Display – 2.01-inch AMOLED display with 410 x 502 resolution, 16.7M colors, and capacitive touch (CST9217)
• Audio – Built-in microphone, MAX98357A I2S Class-D amplifier
• Wireless Connectivity
  • 2.4 GHz WiFi 4 (802.11 b/g/n) and Bluetooth 5.0 LE (from ESP32-S3 itself)
  • GNSS – u-blox MIA-M10Q module
  • LoRa – Semtech SX1262 LoRa transceiver (868MHz, 915MHz, or 920MHz options available)
  • NFC – STMicroelectronics ST25R3916
• USB – USB Type-C port for charging and programming
• Sensors – Bosch BHI260AP AI smart sensor (IMU)
• Misc
  • PCF85063A RTC (Real-Time Clock)
  • DRV2605 haptic driver motor (ERM and LRA)
  • Hardware Reset and Boot buttons
• Power
  • 1,100mAh (4.07 Wh) battery
  • AXP2101 highly integrated Power Management Unit (PMU)
• Dimensions – 63.5 x 49 x 22 mm
• Ingress Protection – IP65 (waterproof and dustproof)

In terms of software support, the smartwatch works with the Arduino IDE, PlatformIO, the ESP-IDF framework, and MicroPython. LILYGO provides the LilyGoLib library on GitHub with example projects (including factory test code) and drivers for peripherals such as the AMOLED display, LoRa radio, GNSS, NFC, and sensors. The company clarifies that to program the board with Arduino IDE, you will need the Arduino-ESP32 core version 3.3.0-alpha1 or newer, and board settings must be configured for the correct radio variant (e.g., SX1262). Since PlatformIO does not yet fully support the newer ESP32 Arduino core, developers need to use the separate LilyGoLib-PlatformIO repository as a workaround.

The documentation on GitHub clearly states that if the USB device keeps connecting and disconnecting, which can occur after installing third-party firmware such as Meshtastic, you may need to manually put the device into download mode before uploading new firmware.

Previously, we have written about various other ESP32-based watch development platforms, including NASA Artemis Watch 2.0 (NASA-inspired wearable kit for education), Waveshare ESP32-S3 2.06-inch AMOLED touch, and watch-like penetration testing tools, like the Deauther Watch X and Deauther Watch V4S IR, but it’s harder to find a watch devkit with built-in LoRa connectivity.

The LILYGO T-Watch Ultra is available on AliExpress for around $95, with different LoRa bands including 433 MHz, 868 MHz, 915 MHz, 920 MHz, and 2.4 GHz (SX1280). It can also be purchased from the official LILYGO store for $78.32 with standard and express shipping options available, and we suspect it might eventually show up on the company’s Amazon store. Note that at the time of writing, only the 868 MHz, 915 MHz, and 920 MHz options are available on AliExpress or the LILYGO store.

The post LILYGO T-Watch Ultra – An IP65-rated ESP32-S3 smartwatch with 2.01-inch AMOLED, LoRa, and GNSS appeared first on CNX Software - Embedded Systems News.

Twenty years ago, it was easy for an operating system kernel to go idle: when there were no tasks to run, “the idle loop” would be scheduled. Early idle loops were basically empty infinite loops that did nothing while waiting for the next interrupt to happen. This saved power simply by avoiding running instructions that needed power-hungry components such as the cache or FPU!

Over time, changing technology has allowed multiple additional hardware mechanisms to reduce power to be introduced. With these new options available today, the idle loop is responsible for choosing and deploying the “best” way to go idle.

As a brief reminder, entering and returning from an idle state has a cost, and that cost can be measured both in time and in energy. Typically, the shallowest idle state is “nearly free” to enter/exit, whilst deeper idle states have increasingly higher costs to enter and exit. If the system enters a deep idle state and wakes up soon after sleeping, then energy will have been wasted because the energy cost to enter the deep idle state is greater than the energy saved whilst residing in that state.

cpuidle is the kernel subsystem that governs idle state transitions. Like cpufreq, mechanism is separated from policy, through the use of drivers and governors.

• cpuidle drivers provide the mechanism needed to enter and exit idle states. They enumerate the available idle states to the governor. As part of that, they describe to the governor the energy-saving properties of each state. Finally, drivers are able to enter idle states at the request of the governor.​
  ​
  Drivers can be fully customized for the unique properties of each System-on-Chip (SoC). However, CPU idle states are often well supported by low-level platform firmware and made available to the kernel using standard interfaces such as PSCI (Power State Coordination Interface) on Arm and SBI (Supervisor Binary Interface) on RISC-V. Thus, whilst there is scope for per-SoC drivers, in reality, these are becoming unusual. Most modern architectures, including both Arm and RISC-V, define standardized interfaces allowing a single Arm and single RISC-V driver to be shared by a wide range of SoC families.

• cpuidle governors provide policy and are responsible for choosing the “best” idle state from among those available.​
  ​
  The governors use the information from the drivers, together with gathered data about historic or known-future events (such as timer wakeups) to make an “educated guess” about when the CPU will need to leave the idle state due to an interrupt. Based on the estimated wake-up time, it can select the idle state likely to save the greatest amount of energy.

How do cpuidle governors make decisions?

cpuidle governors receive data about the physical characteristics of the system from the cpuidle driver. This takes the form of a list of idle states, where each state is annotated with a target residency. Target residency is the minimum time a CPU must spend in an idle state to save energy compared to shallower states. In other words, although the target residency is measured in time, it actually provides data that allows the governor to compare the energy cost of entering and exiting the different idle states. There are three possibilities when a system leaves an idle state:

1. If a system is awakened before reaching the target residency time, then the system wasted energy by selecting an idle state that was too deep
2. If a system remains in an idle state for longer than the target residency time of a deeper idle state (if there is one), then the system wasted energy because the deeper idle state would have saved more energy
3. If a system was woken after reaching the target residency time for our selected state but before reaching the target residency of a deeper idle state, then the choice was optimal

All cpuidle governors keep track of historic idle entry/exit timings; in fact, they make them visible for each CPU at /sys/devices/system/cpu/cpu<N>/cpuidle, so you can check them yourself!

The governors assume that the length of recent idle periods can be used to predict the future. In fact, the ladder governor (used in systems with a regular scheduler tick) and haltpoll governor (specialized governor for virtual machines) work exclusively using historic data.

Other governors, such as menu and teo (timer-event oriented), receive a glimpse into the future, although that view is rather limited. In general, drivers don’t report when they expect their interrupts to fire, but there is one interrupt that can be predicted “perfectly”: we always know when the next timer interrupt is due. Thus, the upper bound for any idle period is the time to the next timer interrupt. For many use-cases, timer interrupts are significantly more frequent than any other. That means that, providing historic entry/exit tracking suggests we are running shows that we are running a use-case dominated by the timer interrupt, then it is an excellent predictor of idle time.

The final factor at play in governance decisions is the energy cost of the decision-making itself! All computation has an energy cost. It doesn’t matter if the governor makes the best decision if it burns too much energy making the decision! This is especially true when the system is experiencing short idle periods. In that case, making a fast decision to enter the shallowest idle state is extremely desirable!

The menu and teo governors both use the timer to inform decisions but adopt different strategies:

• The menu governor seeks to generate a predicted sleep time by taking the next wake-up time and applying a correction factor derived from recent history to adjust it. Once it has made a prediction, it can look up the best idle state.​
• The teo governor quantizes the historic information into bins based on the target residency times for each idle state. The quantized data does not allow prediction of the idle time, but because each bin corresponds to a specific idle state, it is still able to predict which idle state will be best! It then uses the next wake-up time to improve the choice by selecting a shallower mode if the timer will fire shortly.

Additional detail about the menu and teo governors in the Linux kernel documentation.

Tuning Idle Behaviour for Lower Power Consumption

All cpuidle governors share something in common with the schedutil governor: the governors themselves do not offer any tunable values to tweak their heuristics. As we saw before, that doesn’t mean there is nothing for us to tune, just that to conserve power (or improve performance), we have to look outside of the governor itself. Today, we’ll be discussing some of those options.

Going tickless

For many years, Linux managed the flow of time by establishing a timer that fired 100 times per second and using this “scheduler tick” to swap processes and handle timer expiry in drivers. This tick is configurable, and the scheduler tick can be set to 100, 250, or 1000Hz. Changing CONFIG_HZ can have profound effects on system behaviour, and it is an interesting kernel tunable when seeking to balance power consumption and interactivity (although which value results in the lowest power consumption varies with workload).

When CONFIG_HZ is set to the minimum value and the system is waking up 100 times a second, the system can never go idle for more than 10ms. Waking up this frequently can reduce the effectiveness of deep-idle states, and should be avoided on systems that seek to conserve energy this way.​
​
Tickless kernels either disable the scheduler tick when the system goes idle (CONFIG_NO_HZ_IDLE=y) or when there is only a single task running on the CPU
(CONFIG_NO_HZ_FULL=y). Setting either option allows longer residency in idle states. The exact difference between these options is subtle and not in scope for this post. See NO_HZ: Reducing Scheduling-Clock Ticks, if you are interested in learning more!

Finally, we should note that there is little point in going tickless if there is a driver that wakes up 100 times a second to poll, for example, an SPI peripheral! If you have gone tickless, you should also make sure that the code running on your system doesn’t introduce unnecessary periodic ticks by polling for status. Note also that if polling cannot be avoided, then it’s still important to ensure the driver shuts the polling down when there are no clients.​

Try a different cpuidle governor

If you have a tickless system, there is a choice of two governors: menu and teo (timer-event oriented).

The menu governor is the default and works by predicting how long the system will be idle. It monitors the historic wake-up intervals and the due time of the next timer interrupt, filtering them to identify the “typical” wake-up interval. It then uses that prediction to choose from the menu of choices offered by the cpuidle driver.

The teo governor uses the same sources of data, but tracks the statistical data to directly predict the best idle state, without predicting exactly how long it expects the system to remain idle. When the system wakes up frequently, this allows it to avoid the (relatively expensive) peek at the timer queue, reducing the energy costs of its decision making.

The governor can be inspected and changed via sysfs: /sys/devices/system/cpu/cpuidle/current_governor.​

Power Management Quality of Service (PM QoS) Requests

As mentioned in the introductory sections, entering/leaving idle state has a cost that can be measured in both time and energy. The cpuidle governor usually makes decisions based on energy cost, but there are situations where we have to consider the time cost as well. For example, if we are in a deep idle state, it can take a long time to get the CPU running again. What if an important interrupt arrives during a deep idle state and we don’t respond fast enough? We don’t want the idle system to cause us to miss real-time deadlines, such as refilling an audio buffer.

One way to solve this is to disable the deep idle state, but doing that globally will cause energy to be burned unnecessarily when not running time-sensitive applications.​
​
A better way to address this is to ensure all drivers and userspace register their latency tolerance with the PM QoS framework. The latency tolerance is a value in microseconds that expresses how much additional latency due to CPU idling a driver or userspace process can tolerate before their performance is degraded. cpuidle chooses the lowest values among all drivers and processes and prevents the governor from adopting deep idle states if the entry/exit time is too long.​
​
This is great for modal systems where entering deep idle states is useful for conserving power, but it is not appropriate to enter deep idle states in all modes.

Wrapping up

In this blog post, we have covered how cpuidle works and also looked at the ways we can tune systems using modern features based on schedutil and the timer-event oriented (teo) CPU idle governor.

This has been limited to cpuidle and the hardware on which it is built. There are many other avenues we could explore. For example, we haven’t looked at how runtime PM allows us to manage the energy used by peripheral devices. Even having focused on the CPU, there’s still plenty we could say on topics like thermal management or SMP load balancing. Load balancing is especially interesting on heterogeneous CPUs such as Arm’s pioneering big.LITTLE technology since it provides the chance to conserve power by migrating tasks to more efficient processors.

For now, let’s close by noting that power management tuning is a practical skill that requires embedded Linux developers to understand the requirements and limitations of the workload. We’ve focused on features here rather than hardware. In fact, the Arm laptop used for examples wasn’t selected because it’s a great example of an embedded Linux system, it was selected because we knew it was free of any NDAs! Reviewing your own hardware is a great way to augment what you learned here. Combining knowledge about the kernel tools, your workload, and your platform puts you in the best position to build systems with state-of-the-art battery life and performance

The post Idle CPU power management: cpuidle appeared first on CNX Software - Embedded Systems News.

Back in January 2024, Firefly released the CT36L AI smart security cameras, built around the Rockchip RV1106G2 SoC with a 0.5 TOPS NPU and Power over Ethernet (PoE) support. Now, Firefly has introduced two new AI cameras, the CQ38W-1126B and CQ38W-3576, which use a similar IP67-rated enclosure but come with much more powerful processors.

Both new models no longer support PoE and instead use a 12V DC input, and they also add an RS485 interface. In terms of performance, the CQ38W-1126B is built around the Rockchip RV1126B with a 3 TOPS NPU and can run small multimodal AI models. The higher-end CQ38W-3576 features an octa-core Rockchip RK3576 with a 6 TOPS NPU, making it suitable for more demanding AI workloads, including YOLO and large language models. Both cameras are available with 3MP or 5MP sensors and come in Commercial or Industrial (J-suffix) variants. The 3576 series also adds an Automotive-grade (M-suffix) option.

Firefly CQ38W-1126B and CQ38W-3576 specifications:

• SoC
  • CQ38W-1126B – Rockchip RV1126B or RV1126BJ (industrial-grade version)
    • CPU – Quad-core Arm Cortex-A53 up to 1.6 GHz with 32KB L1 I-Cache and 32KB L1 D-Cache, unified 512KB L2 Cache
    • GPU – 2D Graphics Engine
    • VPU
      • Video Decoder – H.265/H.264 up to 3840×2160 @ 30fps
      • Video Encoder  – H.265, H.264, JPEG up to 12Mbps @ 30fps
      • JPEG Decoder
    • AI accelerator – Rockchip NPU engine up to 3 TOPS (INT8); supports INT4, INT8, INT16, and FP16 models; TensorFlow, ONNX, PyTorch, and Caffe frameworks.
  • CQ38W-3576 – Rockchip RK3576 /RK3576J/ RK3576M (commercial/industrial/automotive version)
    • CPU – Octa-core  CPU with 4x Cortex-A72 cores at 2.2 GHz, 4x Cortex-A53 cores at 2.0 GHz (1.6GHz for Industrial and Automotive)
    • GPU – Arm Mali-G52 MC3 GPU with support for OpenGL ES 1.1, 2.0, and 3.2, OpenCL 2.0, and Vulkan 1.2
    • NPU – 6 TOPS (INT8) AI accelerator with support for INT4, INT8, INT16, BF16, TF32 mixed operations.
    • VPU
      • Video Decoder
        • H.265, VP9, AV1, and AVS2 up to 8Kp30 or 4Kp120
        • H.264/AVC and MJPEG up to 4Kp60
      • Video Encoder – H.264, H.265, MJPEG up to 4Kp60
• Memory
  • 1GB, 2GB, or 4GB LPDDR4/LPDDR4X (CQ38W-1126B only)
  • 4GB, 8GB, or 16GB LPDDR4/LPDDR4X (CQ38W-3576 only)
• Storage
  • 8GB, 16GB, or 64GB eMMC flash (CQ38W-1126B only)
  • 16GB to 256GB eMMC flash (CQ38W-3576 only)
• Camera options
  • 3MP SONY SC3336 1/2.8″ CMOS sensor (2304×1296) with an F2.56 aperture (F2.0 on the 1126B), 3.95mm focal length, and manual focus
  • 5MP SONY IMX335 1/2.8″ CMOS sensor (2592×1944) with an F2.0 aperture (F2.56 on the 1126B), 4mm focal length, and fixed focus
  • All the variants of the smart camera can be configured with 3MP or 5MP cameras
• Networking – 1x 10/100Mbps Ethernet (RJ45)
• Serial – RS485 via 2-pin 3.5 mm Phoenix terminal block
• Power – 12V DC/2A via 5.5×2.1mm barrel jack
• Dimensions – 69.72 x 69.72 x 174.21 mm
• Weight – Approximately 336 grams
• Ingress Protection Rating – IP67 waterproof and dustproof
• Environment – Temperature range: -20°C to 50°C; humidity: 15%~90%RH (non-condensing)

In terms of software, the CQ38W-1126B supports Debian 12 and Linux systems built with Buildroot + Qt GUI, while the CQ38W-3576 is said to support Ubuntu 22.04 and Debian 12. Both cameras are compatible with common AI frameworks for models. The CQ38W-1126B can run lightweight multimodal and LLM models up to ~2B parameters, including the Qwen series, Gemma2-2B, Phi2, and MiniCPM, and supports optimizations such as weight sparsification and W4A16/W8A16 mixed-precision quantization. The higher-end CQ38W-3576 supports deployment of YOLO and larger language models for more demanding AI workloads. Firefly generally provides a wiki for all of its products, but at the time of writing, I can see that the Wiki is available only for the CQ38W-3576 camera.

Both cameras utilize an “AI-ISP” (an 8MP one in the 1126B and a 16MP one in the 3576), where the 1126B pairs this with AI Remosaic technology to allow for adaptive day/night dual-mode operation without wasting the main NPU’s resources. According to the datasheet, the 1126B features 6-DOF stabilization to actively eliminate high-frequency jitter. It’s kind of weird that the higher-tier RK3576 variant does not have these stabilization features. It’s highly likely the RK3576 variants are based on the Firefly CAM-3576 series SBC we covered last December.

Other AI-enabled smart security cameras include Seeed Studio’s Modbus Vision RS485 and SenseCAP A1102 (LoRaWAN) outdoor Edge AI cameras, the Reolink Floodlight 4K, and camera kits like All-in-One Raspberry Pi CM5 AI Camera Kit from Arducam.

The CQ38W-3576 AI camera is listed on the Firefly store for $149.00. Pricing for the CQ38W-1126B has not been announced yet. More details about the CQ38W-1126B and CQ38W-3576 smart AI cameras are available on their respective product pages.

The post IP67-rated AI security camera feature Rockchip RV1126B or RK3576/J/M SoC for commercial, industrial, and automotive applications appeared first on CNX Software - Embedded Systems News.

Loona Deskmate is a screen-aware AI desktop companion for iPhone designed to act as a hands-free co-worker that understands your workflow, responds conversationally, and executes tasks directly across your apps. Instead of packing an expensive internal SoC and display into the robot, the Deskmate relies on a docked iPhone to act as its “brain” and face, while the base serves as a 165W GaN desktop charging station.

It features real-time voice interaction (~0.5s response time), screen awareness, and a 3-DOF motorized head for lifelike motion and responsive behavior. The system relies on a smartphone (iPhone 12+) for computing and uses its camera and sensors for visual and contextual input. The base integrates a 165W GaN power hub with multiple ports (3× USB-C + 1× USB-A), allowing it to function as a desk charging station. Overall, the hardware combines a robotic form factor with a practical docking and power solution designed for desktop use.

Loona Deskmate features and specifications:

• Compute and display – Relies on a docked iOS device (Requires iPhone 12 or newer running iOS 16+). Currently, Android devices are not supported
• Mechanical base – 3-DOF (Degrees of Freedom) bionic motion utilizing three near-silent brushless servo motors for yaw, pitch, and roll movements.
• Interaction – Multimodal (voice, vision, screen context, gestures)
• AI features
  • Screen-aware AI with access to PC/Mac display context
  • Uses smartphone camera and microphones for contextual understanding
  • Vision + audio fusion for intent detection and user tracking
  • Supports natural language interaction (no prompt-based workflow)
  • Local processing for sensitive data (face, attention, context)
  • Hybrid processing – on-device (phone) + cloud for advanced tasks
• USB (for charging)
  • 3x USB Type-C ports
  • 1x USB Type-A port
• Power / GaN Charging
  • Acts as a 165W GaN power station
  • 1x Magnetic wireless charging pad for the docked iPhone
  • 3x USB Type-C ports
  • 1x USB Type-A port
• Form factor – Desktop AI companion / robotic docking station for smartphone
• Dimension – TBD

The docked iPhone processes biometric data, including facial recognition and attention tracking, entirely on-device. The solution also supports a “Cross-Device Context Sync” feature that lets it access and understand your desktop screen, enabling contextual interaction without taking screenshots. The system integrates with 50+ third-party services, including Gmail, Slack, Google Calendar, and Zoom, through a companion mobile app (probably Hello Loona) and desktop sync layer (macOS/Windows) for workflow automation and context sharing. It also provides developer support via APIs and the OpenClaw framework, including CLI tools and model key integration for custom agents and workflows. However, the campaign does not provide detailed information about the required apps, system requirements, or implementation instructions for these features.

In short, the system operates on a “task-oriented agent stack” rather than a simple chat interface, as found on products like Espressif’s EchoEar and M5Stack’s StackChan or Echo Pyramid. This allows it to maintain continuity across multiple active threads, draft emails, schedule meetings, or pull up documents simply by conversing with it.

Because AI API calls and advanced third-party task execution incur costs, the ecosystem uses a subscription model. While basic everyday interactions (commands, daily briefings, and multimodal understanding) remain free, advanced tasks like deep web research, document generation, and heavy workflow automation require credits. However, Kickstarter backers are being offered a lifetime “Plus” tier and a 1-year “Pro” subscription as part of their pledge.

The company mentions that at launch, the device will support English, French, German, Spanish, Italian, and Chinese. Other languages, such as Japanese, Korean, Cantonese, Dutch, Russian, Portuguese, Polish, and Arabic, will be introduced later via OTA updates.

Jianbo’s Loona Deskmate AI desktop companion is available on Kickstarter and has already surpassed its $10,000 funding goal, raising around $550,000 so far, with a couple of weeks left in the campaign. Pledges start at $219 for the “Launch Special Offer” tier, or $239 for the “Super Early Bird” tier. Both tiers include the Deskmate base, power adapter, adapter connector, user manual, and the aforementioned subscription perks. It will be available in either Black or White colorways. According to their timeline, mass production was slated for March 2026, with shipping scheduled to begin in late May 2026.

The post Loona Deskmate – An iPhone-powered AI desktop companion that doubles as a 165W GaN charging station (Crowdfunding) appeared first on CNX Software - Embedded Systems News.

BeagleBoard.org Foundation’s BeagleConnect Zepto “$1 computer” is an upcoming open-source hardware board powered by Texas Instruments MSPM0L117 Cortex-M0+ MCU, part of the MSPM0 family introduced in 2023.

It’s a tiny board with mikroBus-compatible headers, a TAG-CONNECT JTAG connector, two Qwiic connectors for expansion (or one Qwiic connector + USB-C depending on the variant), Boot and Reset buttons, and an RGB LED.

BeagleConnect Zepto specifications:

• MCU – Texas Instruments MSPM0L117
  • CPU – 32MHz Arm Cortex-M0+ core
  • Memory – 16KB SRAM
  • Storage – 128KB dual-bank flash
  • Package – QFN32 (5×5 mm)
• USB – Optional USB-C port for power (multiplexed with one of the Qwicc JST connectors)
• Expansion
  • mikroBUS headers supporting a choice of about 2,000 ClickE add-on boards; one of the sides is compatible with some Raspberry Pi HATs (note limited to 12 pins)
  • Up to 2x Qwicc connectors with full Grove function: I2C, UART, ADC, GPIO
• Debugging – 8-pin TAG-CONNECT JTAG connector
• Misc
  • Reset and User buttons
  • RGB LED
• Power Supply – 5V via USB-C port or Qwicc/ JST connector
• Dimensions – 33.7 x 25.4 mm (2-layer PCB)

The Qwiic connectors also allow the user to connect the Zepto to BeaglePlay, BeagleBadge, or other Qwiic-enabled hosts or targets, meaning the BeagleConnect Zepto board could also be connected to Linux hosts for internet connectivity or prototyping. The foundation notably highlights support for BeagleConnect Greybus for Zephyr to control mikroBUS modules over Linux without having to develop additional microcontroller firmware.

Several solutions will be offered on the firmware side:

• A Zephyr-based SDK – A hard-to-brick MCUBOOT-based USB bootloader
• BeagleConnect firmware exposing mikroBUS to Linux/Zephyr hosts (Greybus)
  • Gateway function on USB
  • Node function on both USB and JST
• Micropython firmware on top of Zephyr
• Microblocks-based on Zephyr and Arduino Core

Jason Kridner is also working on a gaming environment that runs on BeagleBadge and uses BeagleConnect Zepto as the controllers. Right now, the GitHub repo comes with the KiCad hardware design files, some hardware documentation, and renders. There’s also a table that shows the board may be offered with different MSPM0 MCU variants and prices. The MSPM0L117 offers a good price/features ratio to target a $1 computer board with minimal margins.

The firmware and software resources will be released later, although I can see a Zephyr implementation repo for the Zepto. The announcement calls for people wanting to get involved, as prototypes are available now. If you are interested, you can check out the forum.

The target is to sell the board for one dollar with virtually no margin for the BeagleBoard.org Foundation, but in a way “where TI, PCB assemblers and distributors are happy with the margin they make” and a price sustainable for over 10 years. If you like this kind of cheap board, Olimex has its own one Euro board: the RVPC computer kit. It’s sold for one Euro plus shipping, as a WCH CH32V003 kit to be soldered, and looks more like a real computer than the BeagleConnect Zepto since it features a VGA connector for a display and a PS/2 connector for a keyboard.

The post BeagleConnect Zepto – A “$1 computer” based on TI MSPM0L1117 Cortex-M0+ MCU appeared first on CNX Software - Embedded Systems News.

SunFounder has sent us a sample of the Pironman 5 Pro Max tower PC case for Raspberry Pi 5 for review alongside a PiPower 5 UPS board. The “Pro Max” builds upon the Pironman 5 Max we reviewed last year, but adds a 4.3-inch capacitive touchscreen display, a 5MP camera module, two speakers, a USB microphone, and a 3.5mm audio jack. The PiPower 5 is a UPS HAT designed for Raspberry Pi Zero/Model B single board computers, and not directly compatible with the Pironman cases, but we’ll still try to use it.

I’ll start this review with an unboxing of the Pironman 5 Pro Max and PiPower 5 packages, followed by an assembly guide for the Pironman 5 Pro Max, a test of the new features (display, camera, audio interaction), and finally, I’ll have a quick test of the UPS HAT with the Raspberry Pi 5 enclosure.

Unboxing of Pironman 5 Pro Max and PiPower 5

I received two retail packages for the devices. The PiPower 5 package had a rough trip and was a bit damaged, but more importantly, its content survived.

Each package provides basic information. The PiPower 5 ships with a 2,000 mAh battery, supports up to 45W DC input (5/15V via USB-C), outputs up to 5V/5A, and implements I2C battery monitoring and safe shutdown. The Pironman 5 Pro Max comes with a 4.3-inch IPS display, two M.2 sockets, a 5MP camera (written 500 MP due to mistranslating 500 “Wan” MP), a 0.96-inch OLED, three RGB fans, two speakers, and a USB microphone.

There are many more parts than in the original Pironman 5 case, so reserve about two hours to assemble the Pro Max enclosure with a Raspberry Pi 5. I was unable to find the usual printed assembly guide found in previous versions of the Pironman 5 enclosures, which was a disappointment.

Let’s now open the PiPower 5 package.  It ships with the PiPower 5 HAT+ itself, a  7.4V/2,000 mAh Lithium Ion battery, an acrylic plate, a screw driver, a wrench, various zip bags with screws, standoffs, and a heatsink, and an assembly guide.

The bottom side of the PiPower 5 HAT+ lists basic features of the board:

• USB Type-C – 5V/3, 9V/3A, 12V/3A, 15V/5A power input
• Screw terminal – 5V-15V DC input
• Output – 5V/5A
• Charge power – Up to 20W
• Battery – 7.4 2S Li-Ion

Pironman 5 Pro Max assembly

I usually start working on my computer at 9 am, and will typically perform tasks like teardown and assembly earlier in the morning without using my phone or laptop. But the assembly guide was not provided in the package, so I went to the documentation page and printed the “assembly instructions” (PDF) out myself on A4 paper.  The guide is not designed for this paper size, so the text was rather small and hard to read. I eventually managed, but not before making a few errors due to misreading a couple of times.

The build instructions are very similar to the ones for the Pironman 5 Max enclosure, so I haven’t taken as many photos this time around. Assembly starts by separating the two metal parts of the case, installing the Pironman 5 HDMI USB adapter and your own Raspberry Pi 5 with the microSD card extender, and inserting various cables (MIPI, PCIe, fan) and the two speakers. I also added the three thermal pads provided in the kit.

Two important steps here are to insert the provided RTC battery and cable (I completely forgot about these two), insert the 4-pin power header, and configure the speaker jumper (left default: ON). I had to reopen the case to insert the RTC battery and cable, and let’s say it’s much better to do it while assembling the case than after.

After that, I installed the ICE cooler, inserted the dual NVMe PiP and Pironman 5 Pro Max HAT+ boards, connected the wires as instructed, and also installed an NVMe SSD and a Hailo-8 AI accelerator (my own parts, not part of the kit).

We can now start working on the second metal part by installing two RGB LED fans and two speakers on it. I also added the OLED (bottom left), and inserted the MIPI CSI cable into the camera opening.

We can now secure both metal parts of the enclosures and place the OLED in its location, after peeling the 3M protective film. It’s easy to lose a few screws during installation, but SunFounder has got you covered since they always provide some spares for screws and standoffs.

The next step is to install the 4.3-inch DSI capacitive touch display on the acrylic using the two provided brackets.

Once done, you can secure two acrylic plates (one with the display, one with the power button) to the metal chassis, install the camera mount and 5MP camera (Raspberry Pi Camera Module v1.3). The angle of the camera can easily be adjusted as needed.

The final step is to insert the USB microphone, and we are done.

Pironman 5 Pro Max configuration and system info

We are now ready to start our computer. But first, we need to select an operating system. In the aforelinked documentation, SunFounder lists support for Raspberry Pi Desktop/Full/Lite, Ubuntu Desktop/Server 25.05/25.10, Kali Linux, Home Assistant, Homebridge, and Umbrel OS 1.5.

I just inserted a microSD card preloaded with Raspberry Pi OS Trixie Desktop, and connected an Ethernet cable and an official 27W Raspberry Pi USB-C power supply to get started.

I hadn’t changed anything in the OS configuration so far, and the display worked out of the box with touchscreen function.

Here’s some system information from inxi:

pi@raspberrypi:~ $ sudo inxi -Fc0
System:
  Host: raspberrypi Kernel: 6.12.62+rpt-rpi-2712 arch: aarch64 bits: 64
  Console: pty pts/1 Distro: Debian GNU/Linux 13 (trixie)
Machine:
  Type: ARM System: Raspberry Pi 5 Model B Rev 1.0 details: N/A rev: b04170
    serial: 696387f5901070da
CPU:
  Info: quad core model: N/A variant: cortex-a76 bits: 64 type: MCP cache:
    L2: 2 MiB
  Speed (MHz): avg: 2400 min/max: 1500/2400 cores: 1: 2400 2: 2400 3: 2400
    4: 2400
Graphics:
  Device-1: bcm2712-hdmi0 driver: vc4_hdmi v: N/A
  Device-2: bcm2712-hdmi1 driver: vc4_hdmi v: N/A
  Display: wayland server: X.org v: 1.21.1.16 with: Xwayland v: 24.1.6
    compositor: LabWC driver:
    gpu: drm-rp1-dsi,vc4-drm,vc4_crtc,vc4_dpi,vc4_dsi,vc4_firmware_kms,vc4_hdmi,vc4_hvs,vc4_txp,vc4_v3d,vc4_vec
    tty: 80x24 resolution: 1: 1920x1080
  API: EGL v: 1.5 drivers: swrast,v3d platforms: gbm,surfaceless,device
  API: OpenGL v: 4.5 compat-v: 3.1 vendor: mesa v: 25.0.7-2+rpt4
    note: console (EGL sourced) renderer: V3D 7.1.10.2, llvmpipe (LLVM 19.1.7
    128 bits)
  API: Vulkan v: 1.4.309 drivers: v3dv,llvmpipe surfaces: N/A
  Info: Tools: api: eglinfo, glxinfo, vulkaninfo wl: kanshi,wlr-randr
    x11: xdriinfo, xdpyinfo, xprop, xrandr
Audio:
  Device-1: bcm2712-hdmi0 driver: vc4_hdmi
  Device-2: bcm2712-hdmi1 driver: vc4_hdmi
  Device-3: Texas Instruments PCM2902 Audio Codec
    driver: hid-generic,snd-usb-audio,usbhid type: USB
  API: ALSA v: k6.12.62+rpt-rpi-2712 status: kernel-api
Network:
  Device-1: Raspberry Pi RP1 PCIe 2.0 South Bridge driver: rp1
  IF: wlan0 state: down mac: 2c:cf:67:83:d7:8f
  IF-ID-1: docker0 state: down mac: 86:77:f2:53:8f:49
  IF-ID-2: eth0 state: up speed: 1000 Mbps duplex: full
    mac: 2c:cf:67:83:d7:8e
Bluetooth:
  Device-1: bcm7271-uart driver: bcm7271_uart
  Report: hciconfig ID: hci0 state: up address: 2C:CF:67:83:D7:90 bt-v: 5.0
  Device-2: bcm7271-uart driver: ctrl
Drives:
  Local Storage: total: 506.48 GiB used: 22.1 GiB (4.4%)
  ID-1: /dev/mmcblk0 model: USD00 size: 29.54 GiB type: Removable
  ID-2: /dev/nvme0n1 vendor: Intel model: SSDPEKNU512GZ size: 476.94 GiB
Partition:
  ID-1: / size: 28.5 GiB used: 22.02 GiB (77.3%) fs: ext4 dev: /dev/mmcblk0p2
Swap:
  ID-1: swap-1 type: zram size: 1.96 GiB used: 325.1 MiB (16.2%)
    dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 68.3 C mobo: N/A
  Fan Speeds (rpm): N/A
Info:
  Memory: total: 2 GiB available: 1.96 GiB used: 1017 MiB (50.7%) igpu: 8 MiB
  Processes: 221 Uptime: 13m Init: systemd Shell: Sudo inxi: 3.3.38

Everything is detected, including a Texas Instruments PCM2902  audio codec and the 500GB NVMe SSD I had installed inside. We can find the Hailo-8 card with lspci:

pi@raspberrypi:~ $ lspci
0001:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 30)
0001:01:00.0 PCI bridge: ASMedia Technology Inc. ASM1182e 2-Port PCIe x1 Gen2 Packet Switch
0001:02:03.0 PCI bridge: ASMedia Technology Inc. ASM1182e 2-Port PCIe x1 Gen2 Packet Switch
0001:02:07.0 PCI bridge: ASMedia Technology Inc. ASM1182e 2-Port PCIe x1 Gen2 Packet Switch
0001:03:00.0 Co-processor: Hailo Technologies Ltd. Hailo-8 AI Processor (rev 01)
0001:04:00.0 Non-Volatile memory controller: Intel Corporation SSD 670p Series [Keystone Harbor] (rev 03)
0002:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 30)
0002:01:00.0 Ethernet controller: Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge

We are not done with the configuration since the OLED, RGB LEDs, and fans are not working.

The first step is to start raspi-config in a terminal:

<span class="n">sudo</span> <span class="n">raspi</span><span class="o">-</span><span class="n">config</span>

Now go to Advanced Options → A12 Shutdown Behaviour, and select the Full power off option. This will make sure the OLED, fans, and RGB LEDs are turned off when the Raspberry Pi 5 is turned off.

After a reboot, we can download and install the pironman5 module/daemon that controls the fans, OLED…:

pi@raspberrypi:~ $ git clone -b pro-max https://github.com/sunfounder/pironman5.git --depth 1
pi@raspberrypi:~ $ cd pironman5/
pi@raspberrypi:~/pironman5 $ sudo python3 install.py

After a reboot, the OLED display, the fans, and the RGB LEDs will all be active.

Pironman 5 Pro Max features testing

I’ll mostly focus on the new features in that section. I’ve already tested the touchscreen display with the terminal and Firefox using the software keyboard.

Time for a camera test with an rpicam sample:

rpicam-hello -t 60s

All good. The camera inclination can be adjusted on one axis, so it’s quite convenient to use, a bit like a webcam on a laptop.

The new Pironman 5 Pro Max case also adds two internal speakers and a 3.5mm audio jack. I tested both with a YouTube video.

If I connect my USB-powered speakers to the audio jack, we can hear the audio through the external speakers. If I disconnect the cable from the audio jack, the system will switch to the internal speakers.

Another new feature is the USB microphone that ships as part of the kit. We could just do a recording and play it back, but SunFounder provides something more fun to play with in the “Think · Talk · Drive — AI-Powered with Multi-LLMs” section of the documentation. So we can run text-to-speech, speech-to-text, chat with local or online LLMs, or even implement a full voice assistant. Let’s install the necessary tools and libraries:

sudo apt install espeak libttspico-utils sox portaudio19-dev
git clone https://github.com/sunfounder/sunfounder-voice-assistant.git
sudo pip install ./sunfounder-voice-assistant --break

All demos are very similar to the ones we used in the Fusion HAT review. So I’ll go straight to the full voice assistant demo using Piper text-to-speech, Vosk speech-to-text engine, and Google Gemini LLM. We’ll first need to go to the example directory

cd sunfounder-voice-assistant/examples/

Create a secret.py file with the GEMINI_API_KEY (refer to the SunFounder documentation or the Fusion HAT review to find out how to get a key)

GEMINI_API_KEY="AIxxxxxxxxxxxxxxxxxxxxxxxxx"

And edit voice_assistant.py to enable Google Gemini 2.5 Flash:

from sunfounder_voice_assistant.voice_assistant import VoiceAssistant
from sunfounder_voice_assistant.llm import Gemini as LLM
from secret import GEMINI_API_KEY as API_KEY

llm = LLM(
    api_key=API_KEY,
    model="gemini-2.5-flash",
)

# Robot name
NAME = "Buddy"

# Enable image, need to set up a multimodal language model
WITH_IMAGE = True

# Set models and languages
LLM_MODEL = "gemini-2.5-flash"
TTS_MODEL = "en_US-ryan-low"
STT_LANGUAGE = "en-us"

I selected Google Gemini because it’s one of the rare online LLMs that still offers a free tier without having to enter credit card information, just for testing a few requests. We can start the voice assistant as follows:

python3 voice_assistant.py

To try the voice assistant, simply say “Hey! Buddy”, get acknowledged, and ask a question. It will be processed on Google servers, and the text-to-speech function will start once the full answer is received, so you typically have to wait for a few seconds before the audio answer starts:

pi@raspberrypi:~/sunfounder-voice-assistant/examples $ python3 voice_assistant.py 
2026-04-18 12:07:18.450110034 [W:onnxruntime:Default, device_discovery.cc:164 DiscoverDevicesForPlatform] GPU device discovery failed: device_discovery.cc:89 ReadFileContents Failed to open file: "/sys/class/drm/card1/device/vendor"
Failed to cache model list: [Errno 13] Permission denied: '/opt/vosk_models/model-list.json'
[1:10:06.815927173] [43860]  INFO Camera camera_manager.cpp:340 libcamera v0.7.0+rpt20260205
[1:10:06.828200070] [44452]  INFO RPI pisp.cpp:720 libpisp version v1.4.0 23-03-2026 (13:29:05)
[1:10:06.901125515] [44452]  INFO IPAProxy ipa_proxy.cpp:180 Using tuning file /usr/share/libcamera/ipa/rpi/pisp/ov5647.json
[1:10:06.908768597] [44452]  INFO Camera camera_manager.cpp:223 Adding camera '/base/axi/pcie@1000120000/rp1/i2c@88000/ov5647@36' for pipeline handler rpi/pisp
[1:10:06.908815935] [44452]  INFO RPI pisp.cpp:1181 Registered camera /base/axi/pcie@1000120000/rp1/i2c@88000/ov5647@36 to CFE device /dev/media2 and ISP device /dev/media0 using PiSP variant BCM2712_D0
[1:10:06.911997310] [43860]  INFO Camera camera.cpp:1215 configuring streams: (0) 640x480-XBGR8888/sRGB (1) 640x480-GBRG_PISP_COMP1/RAW
[1:10:06.912138842] [44452]  INFO RPI pisp.cpp:1485 Sensor: /base/axi/pcie@1000120000/rp1/i2c@88000/ov5647@36 - Selected sensor format: 640x480-SGBRG10_1X10/RAW - Selected CFE format: 640x480-PC1g/RAW
>>> heard: hey buddy
Waked, Listening ...
heard: why is a sky blue

That's a great question! The sky is blue due to a phenomenon called **Rayleigh scattering**. Here's a simple breakdown:

1.  **Sunlight is White Light:** Sunlight actually contains all the colors of the rainbow, which combine to look white to us.
2.  **Earth's Atmosphere:** Our atmosphere is made up of tiny gas molecules, primarily nitrogen and oxygen.
3.  **Scattering:** When sunlight enters the atmosphere, these tiny molecules scatter the light in different directions.
4.  **Blue Light Scatters More:** These gas molecules are much smaller than the wavelengths of visible light, and they scatter shorter wavelengths (like blue and violet) much more effectively than longer wavelengths (like red, orange, and yellow).
5.  **Blue Sky:** Because blue light is scattered in all directions across the sky, no matter where you look, you see this scattered blue light, making the sky appear blue.
6.  **Red Sunsets:** At sunrise or sunset, the sunlight has to travel through much more of the atmosphere to reach our eyes. Most of the blue light has been scattered away, leaving the longer-wavelength red and orange light to pass directly through, which is why we often see beautiful red and orange hues at those times.

Google Gemini is quite verbose; you may want to change the instructions to make the AI assistant provide more concise answers:

# Set instructions
INSTRUCTIONS = f"""
You are a helpful assistant, named {NAME}.
"""

The answer has many asterisks, and the text-to-speech will also repeat “asterisk” each time it meets one. Here’s a “short” demo where I ask what a Raspberry Pi single board computer is. I cut the video at around two minutes, but because it was not finished just yet :).

The audio quality of the built-in speakers is quite decent for this type of application, and the microphone can pick up the “Hey! Buddy” wake words quite far away. I tested it successfully about 10 meters away. It didn’t quite get my follow-up question at that distance, however.

I won’t do detailed tests of the NVMe SSD and Hailo-8 AI accelerator, RGB LED configuration, OLED display, and more since I already did this in the earlier Pironman 5 Max review. You can still monitor the system and/or configure various parameters with the web-based dashboard at http://raspberrypi.local:34001

Advanced users may prefer the pironman5 command-line utility to automate some of the tasks or configure the system remotely:

pi@raspberrypi:~ $ pironman5
usage: pironman5 [-h] [-v] [-c] [-drd [DATABASE_RETENTION_DAYS]]
                 [-dl [{DEBUG,INFO,WARNING,ERROR,CRITICAL,debug,info,warning,error,critical}]]
                 [-rd] [-cp [CONFIG_PATH]] [-eh [ENABLE_HISTORY]]
                 [-re [RGB_ENABLE]] [-rs [RGB_STYLE]] [-rc [RGB_COLOR]]
                 [-rb [RGB_BRIGHTNESS]] [-rp [RGB_SPEED]]
                 [-rl [RGB_LED_COUNT]] [-u [{C,F}]] [-oe [OLED_ENABLE]]
                 [-or [{0,180}]] [-op [OLED_PAGES]] [-os [OLED_SLEEP_TIMEOUT]]
                 {start,stop,launch-browser} ...

Pironman 5 Pro Max command line interface

options:
  -h, --help            show this help message and exit
  -v, --version         Show version
  -c, --config          Show config
  -drd, --database-retention-days [DATABASE_RETENTION_DAYS]
                        Database retention days
  -dl, --debug-level [{DEBUG,INFO,WARNING,ERROR,CRITICAL,debug,info,warning,error,critical}]
                        Debug level
  -rd, --remove-dashboard
                        Remove dashboard
  -cp, --config-path [CONFIG_PATH]
                        Config path
  -eh, --enable-history [ENABLE_HISTORY]
                        Enable history, True/true/on/On/1 or
                        False/false/off/Off/0
  -re, --rgb-enable [RGB_ENABLE]
                        RGB enable True/False
  -rs, --rgb-style [RGB_STYLE]
                        RGB style: ['solid', 'breathing', 'flow',
                        'flow_reverse', 'rainbow', 'rainbow_reverse',
                        'hue_cycle']
  -rc, --rgb-color [RGB_COLOR]
                        RGB color in hex format without # (e.g. 00aabb)
  -rb, --rgb-brightness [RGB_BRIGHTNESS]
                        RGB brightness 0-100
  -rp, --rgb-speed [RGB_SPEED]
                        RGB speed 0-100
  -rl, --rgb-led-count [RGB_LED_COUNT]
                        RGB LED count int
  -u, --temperature-unit [{C,F}]
                        Temperature unit
  -oe, --oled-enable [OLED_ENABLE]
                        OLED enable True/true/on/On/1 or False/false/off/Off/0
  -or, --oled-rotation [{0,180}]
                        Set to rotate OLED display, 0, 180
  -op, --oled-pages [OLED_PAGES]
                        OLED pages, split by ',': mix,performance,ips,disk
  -os, --oled-sleep-timeout [OLED_SLEEP_TIMEOUT]
                        OLED sleep timeout in seconds

Subcommands:
  {start,stop,launch-browser}
    start               Start Pironman5
    stop                Stop Pironman5
    launch-browser      Launch browser

I don’t see any new commands related to the touchscreen display, speakers, or microphone here, so it’s about the same as for earlier cases.

People who care about low-power consumption will probably not consider this case, but for reference, the idle power consumption is 10.5W with the touchscreen display and Ethernet.

I did a quick stress test to measure CPU and GPU temperature under heavy loads:

pi@raspberrypi:~ $ stress-ng -c 4
stress-ng: info:  [134619] defaulting to a 1 day run per stressor
stress-ng: info:  [134619] dispatching hogs: 4 cpu

After a couple of minutes, the CPU temperature was stable at about 65-66°C in an air-conditioned room at an ambient temperature of 31°C. All Pironman 5 enclosures are over-engineered when it comes to cooling with an ICE cooler and two enclosure fans, so cooling should never be an issue, even when overclocking.

PiPower 5 UPS assembly and test

Let’s now play with the PiPower 5 UPS HAT. As shown in the documentation below, it’s mainly designed for the Raspberry Pi Zero or Model B single board computers.

However, I don’t have a spare Raspberry Pi with me right now, and I wanted to use it with the Pironman 5 Pro Max enclosure, so I assembled it in a different way using the provided accessories.

This allowed me to insert the kit into the case, but it’s not ideal, since it’s thicker than needed, and also partially hide the display, depending on the angle…

With hindsight, it would have been better to just stick the battery on top of the case and insert the PiPower 5 HAT+ without using standoffs and the acrylic plate. So for testing, I placed the battery mounted on the acrylic enclosure on top of the case instead.

There’s an opportunity here for a future UPS module for Pironman cases that looks a little neater…

The PiPower 5 HAT also requires its own software, as explained in the documentation. Let’s install it:

git clone https://github.com/sunfounder/pipower5
cd pipower5
sudo python3 install.py

Once installed, we have access to additional “Battery” and “Raspberry Pi Power” widgets in the web dashboard (http://raspberrypi.local:34001) that report the voltage, current, power, level, and charging status for the battery, and voltage, current, power, and power source for the Raspberry Pi.

We also have new options in the Settings, such as Shutdown Strategy and Power Failure Simulation.

SunFounder also provided the pipower5 command-line utility to perform battery monitoring, and there’s also an option to send an email.

pi@raspberrypi:~ $ pipower5
usage: pipower5 [-h] [-v] [-c] [-drd [DATABASE_RETENTION_DAYS]]
                [-dl [{debug,info,warning,error,critical}]] [-rd]
                [-cp [CONFIG_PATH]] [-sp [SHUTDOWN_PERCENTAGE]] [-iv] [-ic]
                [-ov] [-oc] [-bv] [-bc] [-bp] [-bs] [-ii] [-ichg] [-do] [-sr]
                [-pb] [-cc] [-a] [-fv] [-pfs [POWER_FAILURE_SIMULATION]]
                [-seo [SEND_EMAIL_ON]] [-set [SEND_EMAIL_TO]]
                [-ss [SMTP_SERVER]] [-smp [SMTP_PORT]] [-se [SMTP_EMAIL]]
                [-spw [SMTP_PASSWORD]] [-ssc [SMTP_SECURITY]] [-bzo [BUZZ_ON]]
                [-bzv [BUZZER_VOLUME]] [-bzt [BUZZER_TEST]] [-u [{C,F}]]
                [{start,stop}]

PiPower 5

positional arguments:
  {start,stop}          Command

options:
  -h, --help            show this help message and exit
  -v, --version         Show version
  -c, --config          Show config
  -drd, --database-retention-days [DATABASE_RETENTION_DAYS]
                        Database retention days
  -dl, --debug-level [{debug,info,warning,error,critical}]
                        Debug level
  -rd, --remove-dashboard
                        Remove dashboard
  -cp, --config-path [CONFIG_PATH]
                        Config path
  -sp, --shutdown-percentage [SHUTDOWN_PERCENTAGE]
                        Set shutdown percentage, leave empty to read
  -iv, --input-voltage  Read input voltage
  -ic, --input-current  Read input current
  -ov, --output-voltage
                        Read output voltage
  -oc, --output-current
                        Read output current
  -bv, --battery-voltage
                        Read battery voltage
  -bc, --battery-current
                        Read battery current
  -bp, --battery-percentage
                        Read battery percentage
  -bs, --battery-source
                        Read battery source
  -ii, --is-input-plugged_in
                        Read is input plugged in
  -ichg, --is-charging  Read is charging
  -do, --default-on     Read default on
  -sr, --shutdown-request
                        Read shutdown request
  -pb, --power-btn      Read power button
  -cc, --charging-current
                        Max charging current
  -a, --all             Show all status
  -fv, --firmware       PiPower5 firmware version
  -pfs, --power-failure-simulation [POWER_FAILURE_SIMULATION]
                        Power failure simulation
  -seo, --send-email-on [SEND_EMAIL_ON]
                        Send email on: ['battery_activated', 'low_battery',
                        'power_disconnected', 'power_restored',
                        'power_insufficient', 'battery_critical_shutdown',
                        'battery_voltage_critical_shutdown']
  -set, --send-email-to [SEND_EMAIL_TO]
                        Email address to send email to
  -ss, --smtp-server [SMTP_SERVER]
                        SMTP server
  -smp, --smtp-port [SMTP_PORT]
                        SMTP port
  -se, --smtp-email [SMTP_EMAIL]
                        SMTP email
  -spw, --smtp-password [SMTP_PASSWORD]
                        SMTP password
  -ssc, --smtp-security [SMTP_SECURITY]
                        SMTP security, 'none', 'ssl' or 'tls'
  -bzo, --buzz-on [BUZZ_ON]
                        Buzz on: ['battery_activated', 'low_battery',
                        'power_disconnected', 'power_restored',
                        'power_insufficient', 'battery_critical_shutdown',
                        'battery_voltage_critical_shutdown']
  -bzv, --buzzer-volume [BUZZER_VOLUME]
                        Buzz volume
  -bzt, --buzzer-test [BUZZER_TEST]
                        Test buzzer on selected event.
  -u, --temperature-unit [{C,F}]
                        Temperature unit

I did a quick UPS test by removing the USB-C cable from the PiPower 5 UPS HAT and letting the system run on battery. No problem during the switch.

I did that five times, and there weren’t any issues. We can also hear beeps when the power circuitry switches between the battery and USB power adapter and vice versa. The dashboard also reflects the status correctly when running on batteries.

For another test, I kept the default 10% battery level threshold in the Shutdown Strategy section, and disconnected the power with a 89% charge. The system cleanly turned off after about one hour. After reconnecting the power supply and restarting the Raspberry Pi 5, I went to check the charge level, and it was 37%, quite a bit higher than the 10% threshold, but at least the system shut down cleanly, protecting your data.

Conclusion

The Pironman 5 Pro Max is another neat little Raspberry Pi 5 tower PC case from SunFounder that builds upon previous models, but is suitable for video and audio applications without external hardware, thanks to a 4.3-inch touchscreen display, a 5MP camera, stereo speakers, and a USB microphone. Besides the hardware, the company provides good documentation, notably for creating your own AI-powered voice assistant/smart speaker.

Like other Pironman 5 cases, the Pro Max is over-engineered, but as we noted in previous reviews, that’s part of the charm, and cooling works great with the large heatsink with built-in fan and two RGB fans. The latter two can actually be turned off most of the time since the heatsink already does a proper job. Pironman 5 Pro Max model retains a downside of the Max due to ASM1182e 2-Port PCIe x1 Gen2 that does not allow for PCIe Gen3 x1, so the SSDs and AI accelerators are limited to 5GT/s speed. The Pironman5 script does increase the CPU load along with the Influx database it relies on when the dashboard is active, but nothing dramatic (under 10%), and you can lower that by completely disabling the web dashboard.

The PiPower 5 HAT kit does its job as a UPS with the provided 2,000 mAh battery, and the software handles graceful shutdown when the battery level gets too low, protecting your data in the process. I tried to simulate multiple power failures, some very short, some longer, and I never had unexpected reboots.  It’s better suited for direct use with the Raspberry Pi Zero or Model B boards, as while it’s possible to use it with the Pironman 5 Pro Max enclosure, it looks more like a hack than a nicely packaged solution, since the HAT must be placed on the outside, and the battery on top of the enclosure.

I’d like to thank SunFounder for sending the Pironman 5 Pro Max tower PC enclosure for the Raspberry Pi 5 and the PiPower 5 UPS kit for review. The Pironman 5 Pro Max is sold for $145.99 on Amazon and the SunFounder store before eventual tariffs and VAT.  The PiPower 5 is offered for $34.99 on the SunFounder store, $32.99 on AliExpress, and you’ll find it as part of the Pironman 5 Pro Max + PiPower 5 kit for $178.99 on Amazon.

The post Pironman 5 Pro Max Review – A Raspberry Pi 5 Tower PC case with integrated video and audio capabilities, optional UPS kit appeared first on CNX Software - Embedded Systems News.

Boardcon Tiny1126B shrinks the company’s MINI1126B-P Rockchip RV1126B system-on-module (SoM) from 38x30mm to 34x30mm, targeting even more compact AI vision systems such as smart cameras, smart door locks, inspection cameras, cleaning/logistics robots, DMS (Driver Monitoring Systems), BSD (Blind Spot Detection) solutions, and smart displays.

Despite its smaller size, the Tiny1126B features two 0.4mm pitch 100-pin connectors, instead of two 0.5mm pitch 80-pin connectors for its predecessors, offering even more I/Os. It’s notably gaining a USB 3.0 DRD (Dual-Role Device) interface, an extra SDMMC interface, one additional SPI and I2C interfaces, Fast Ethernet, and more. The rest of the specifications, including memory capacity (up to 4GB LPDDR5) and storage (up to 256GB eMMC flash), remain the same.

Boardcon Tiny1126B system-on-module

Boardcon Tiny1126B specifications:

• SoC – Rockchip RV1126B
  • CPU – Quad-core Arm Cortex-A53 up to 1.6 GHz with 32KB L1 I-Cache and 32KB L1 D-Cache, unified 512KB L2 Cache
  • GPU – 2D Graphics Engine
  • VPU
    • Video Decoder – H.265/H.264 up to 3840×2160 @ 30fps
    • Video Encoder  – H.265, H.264, JPEG up to 12Mbps @ 30fps
    • JPEG Decoder
  • AI accelerator – Rockchip NPU engine up to 3 TOPS (INT8); supports INT4, INT8, INT16, and FP16 models; TensorFlow, ONNX, PyTorch, and Caffe frameworks.
• System Memory – 2GB or 4GB LPDDR4
• Storage – 8GB, 16GB, 32GB, 64GB, 128GB, or 256GB eMMC flash
• Networking chip – Realtek RTL8211F-CG GbE PHY (moved to carrier board if needed)
• 2x 100-pin, 0.4mm pitch female board-to-board connectors
  • Storage – 2x SDMMC, SDIO
  • Display I/F – RGB LCD, MIPI DSI
  • Camera I/F – 2x MIPI CSI
  • Audio – 2x MIC, 1x DSM (Digital Speaker Module)
  • Networking – Gigabit Ethernet, Fast Ethernet PHY
  • USB – USB 2.0 Host, USB 2.0 OTG, USB 3.0 DRD (Dual-Role Device)
  • Other peripherals – 3x UART, 3x I2C, 2x SPI, 7x SARADC IN, 2x CAN, GPIO, etc.
• Supply Voltage – 5V DC; PMIC: RK809-9 (also audio codec)
• Dimensions – 34 x 30 mm (8-layer PCB)
• Weight – 5 grams (previous model was 6.1 grams)
• Temperature Range – -20°C to +85°C

On the software side, Boardcon provides support for Debian 12 using the Buildroot build system with Linux 6.1.141 and u-Boot 2017.09. None of the development resources is public, and the company only provides an SDK to customers.

SBC1126B single board computer and development board

Besides the Linux SDK, Boardcom also offers the SBC1126B single board computer and development board to evaluate the Tiny1126B and quickly get started with software development.

SBC1126B specifications:

• Supported SoM – Boardcom Tiny1126B as described above.
• Storage – MicroSD card slot
• Display I/F – 26-pin MIPI DSI header for displays up to 1920×1080 @ 60 Hz
• Camera I/F – 2x 30-pin 4-lane MIPI CSI FPC connectors
• Audio
  • 2-pin MIC connector
  • 2-pin Speaker connector
  • 8-pin I2S connector
• Networking
  • Gigabit Ethernet RJ45 port via Realtek RTL8211F-CG controller
  • Fast Ethernet RJ45 port
  • Note: The two Ethernet ports are mutually exclusive (shared GMAC)
  • 2.4GHz WiFi (802.11b/g/n) and Bluetooth 4.2
• USB
  • 1x USB 3.0 DRD Type-A connector
  • 4x USB 2.0 Type-A host ports
• Serial
  • 3-pin serial debug connector
  • 6-pin UART (4-wire) connector
  • 2x 3-pin RS485 connectors
• Expansion
  • 2x CAN Bus via 2-pin connectors
  • 6x GPIO via 4-/6-pin connectors
  • 6x ADC via 8-pin connector
  • 1x SPI (SPI1_M2) via 6-pin connector
• Misc
  • Reset, Recovery, and Power keys
  • Supercap-powered RTC
  • Infrared receiver connector
• Power Supply
  • 12V/3A DC input jack
  • 7.4V Li-ion battery via 3-pin connector
• Dimensions – 120 x 95 mm
• Temperature Range – 0 to 70°C

Boardcon didn’t provide pricing information for the new Rockchip RV1126 system-on-module and single board computer. Further details may be found on the product page.

The post Boardcon Tiny1126B is a smaller and lighter Rockchip RV1126B system-on-module, yet with more I/Os appeared first on CNX Software - Embedded Systems News.

Hack The Board’s WiQwiic-32 is a small USB-C IoT development board based on an ESP32-S3-WROOM-1 Wi-Fi and Bluetooth module, and equipped with a 1.14-inch LCD and eight Qwiic ports for easy prototyping with compatible modules.

It also features a microphone and a buzzer for audio interaction, four buttons, two RGB LEDs, and a power LED.  There aren’t any through-holes for GPIO pins, so expansion is only possible through the Qwiic connectors, although you can always add a Qwiic to header converter module if you ever need breadboard-compatible GPIO headers.

WiQwiic-32 specifications:

• Wireless Module – ESP32-S3-WROOM-1
  • SoC – Espressif Systems ESP32-S3
    • CPU – Dual-core Tensilica LX7 up to 240 MHz with vector extension for AI/ML workloads
    • RAM – 512KB SRAM
    • Storage – TBD
    • Wireless – WiFi 4 and Bluetooth LE 5
  • Antenna – PCB antenna
• Display – 1.14-inch TFT display
• Audio
  • On-board buzzer
  • Built-in microphone for voice and sound detection
• USB – USB Type-C male port for power and programming
• Expansion
  • 8x Qwiic connectors for I2C expansion modules
  • 3.3V/5V I/O voltage selection switch
• Misc
  • Reset and Boot buttons
  • 2x user buttons
  • 2x RGB LEDs + power LED
• Power Supply – 5V via USB-C port
• Dimensions – TBD (small)

Besides the WiQwiic-32 board itself, “Hack the Board” also designed a few Qwiic add-on boards:

• A BME280 environmental sensor breakout for temperature, humidity, and pressure data
• An IR transceiver breakout for infrared receiver and blaster functions
• A 2-channel relay breakout
• A GPIO expander breakout (MCP23017) to add more GPIOs through a Qwiic connector
• A Qwiic to header converter for breadboard prototyping
• An RGB LED breakout with 5x WS2812B
• A dual-button breakout
• An LED breakout with Red and Green 5mm LEDs
• An analog sensor breakout with a potentiometer and a light sensor

You should also be able to use any other Qwiic module from Sparkfun, Adafruit, and others, with hundreds, if not thousands, of modules on the market.

It looks to be purely a hardware project, as there aren’t any educational materials or sample code that I could find. You should be able to use Arduino, MicroPython, the ESP-IDF framework, or any other language/framework compatible with the ESP32-S3. We are told the Qwiic board can be used for a range of applications without any soldering required, such as web-based control systems, smart automation systems, IR-based home automation, sound-reactive LED solutions, and so on.

There are plenty of MCU boards with Qwiic connectors, but usually they have only one or two, and the WiQwiic-32 with eight Qwiic is unique in that respect. However, since you can daisy-chain I2C devices, some projects will rely on Qwiic I2C expander modules such as the Sparkfun Qwiic Multiport module (about $4).

While I like the concept, price should also be considered here, since the WiQwiic-32 board starts at about $65 on Kickstarter, and a starter kit with the board, a BME280 sensor, a button breakout, and an LED breakout goes for $94. There are also various bundles with a mix of WiQwiic-32 boards and Qwiic modules. Shipping adds 12 Euros, and deliveries are expected to start in July 2026.

The post WiQwiic-32 – A compact USB-C IoT board with eight Qwiic connectors (Crowdfunding) appeared first on CNX Software - Embedded Systems News.

Seeed Studio reBot Arm B601-DM is a fully open-source 6-axis robotic arm (plus a parallel gripper) designed to lower the barrier to entry for embodied AI learning and teleoperation. Built around high-performance Damiao actuators, the arm offers up to 767mm of reach, a 1.5kg payload capacity, and high-precision 0.2mm repeatability.

Designed for researchers and robotics developers, the B601-DM is compatible out of the box with major AI and robotics frameworks, including ROS 1/2, Hugging Face’s LeRobot, NVIDIA Isaac Sim, and Pinocchio.

Seeed Studio reBot Arm B601-DM specifications:

• Communication – CAN bus @ 1Mbps) and UART @ 921600bps
• Degrees of Freedom (DOF) – 6-axis arm + 1 parallel gripper
• Motors / Actuators – 7x Damiao motors
  • 4x DAMIAO 4310 (DM-J4310-2EC)
  • 3x DAMIAO 4340P (DM-J4340P-2EC) high-torque motors
• Payload – 1.5kg (without gripper, at recommended 70% reach)
• Reach – 767mm (with gripper), 607mm (without gripper)
• Repeatability – < 0.2 mm
• Joint torque and range
  • Joint 1 – 27 N·m, ±2.61 rad
  • Joint 2 – 27 N·m, -3.7 to 0 rad
  • Joint 3 – 27 N·m, -3.7 to 0 rad
  • Joint 4 – 7 N·m, ±1.57 rad
  • Joint 5 – 7 N·m, ±1.57 rad
  • Joint 6 – 7 N·m, ±1.57 rad
  • Gripper – -325° to 0° (-5.7 rad to 0 rad, 0 to 100mm width)
• Encoders – 14-bit Single-turn magnetic encoders
• Control Modes – MIT Mode, Speed Mode, and Position Mode
• Max Velocity – Up to 200 rad/s on J4/J5/J6/Gripper, 50 rad/s on J1/J2/J3
• Safety
  • Driver/Motor over-temperature protection
  • Over/Under-voltage protection
  • Over-current protection
  • Communication loss timeouts
• Power Supply – DC 24V, 15A
• Dimensions
  • Base width – 140 mm
  • Base height – ~140.2 mm
  • Main vertical arm length – ~264 mm
  • Upper arm segments
    • 211.42 mm
    • 101.50 mm
    • 160.21 mm
• Weight – ~4.5 – 4.7 kg
• Operating Temperature – -20°C to 50°C
• Material
  • CNC-machined Aluminum Alloy 5052 for core structural links
  • ABS and PLA for 3D-printed brackets, filler plates, and decorative covers

The arm does not come with a built-in computer or controller (like a Raspberry Pi). So the USB-CAN board must be plugged into a host PC or edge computing device, such as an NVIDIA Jetson board or a PC, to act as the brain.

The arm supports the MIT mode, a hybrid control scheme (popularized by the MIT Cheetah robot) that enables the controller to send position, velocity, and torque (current) commands simultaneously in a single CAN packet. It is crucial for dynamic, compliant movements like a robot arm interacting safely with a human.

The B601-DM comes with a well-supported and actively developed software stack. It includes a Python SDK based on “Motorbridge,” a motor control library that supports various types of joint motors. The arm also supports the Pinocchio framework, an open-source C++ library for rigid body dynamics. This is important for robotics developers, as it handles the complex math needed to determine the arm’s position in 3D space (forward kinematics) and calculate the required joint angles to reach a target point (inverse kinematics).

While the hardware is already available, some software features are still being completed. Full ROS2 (Humble) support, including optimized MoveIt2 drivers, is currently in development. Support for importing USD models into NVIDIA Isaac Sim for simulation and teleoperation is also being added, and integration with the Hugging Face LeRobot framework is expected by late April 2026. More information about software support can be found on the company’s GitHub repository.

The company mentions AI on its product page, but does not clearly explain how it is implemented in the arm. Based on the available information, it appears to rely on Hugging Face’s LeRobot framework, which uses imitation learning—where a human manually moves the B601-DM arm, and the AI learns to replicate those movements.

From the GitHub repository, I can see that the company is also working on a reBot Arm B601-RS, an identical robotic arm that swaps the Damiao actuators for Robstride motors. The company also mentions that the v1.0 GitHub BOM is explicitly optimized for developers to 3D print and CNC machine their own parts at the lowest possible cost. The official retail kits purchased directly from Seeed feature premium upgrades not found in the raw BOM, such as laser-engraved anti-error markings, upgraded braided wire harnesses, and the replacement of several 3D-printed load-bearing brackets with machined metal parts for enhanced durability.

We have covered several robotic arms on CNX Software before, ranging from low-cost ESP32-based desktop robots like Waveshare RoArm-M3-Pro and RoArm-M3-S, and industrial cobots like Elephant Robotics myCobot 280 Pi, and various low-cost options like Yahboom DOFBOT 6, and WLKATA Robotics’ Haro380 6-axis mini robotic arm, compared to all that the reBot Arm B601-DM sits in between, with an open-source design and higher payload capacity for its price.

Because the reBot Arm B601-DM is a DIY platform, Seeed Studio sells it in separate modules. This lets developers who already have compatible motors, or want to use their own parts, buy just the components they need. The system is broken down into the following five distinct variants available for pre-order:

• reBot Arm B601-DM Bundle ($1,197.00): This is the complete DIY kit. It includes all three sub-kits, including the Body Motor Kit, Body Structure Kit, and Gripper Kit, required to build the fully functional 6+1 DOF arm.
• A. reBot Arm B601-DM Body Motor Kit ($829.00): This kit includes the electronics and motors for the main arm, such as six Damiao motors (three 4310 and three 4340P), a USB-CAN driver board, a power board, and the required XT30 cables.
• B. reBot Arm B601-DM Body Structure Kit ($169.00): This kit includes only the mechanical parts of the arm (without the gripper), including metal components, 3D-printed components, screws, and pins. It is meant for users who already have compatible motors. The kit contains 21 metal parts and 17 3D-printed components.
• C. reBot Arm B601-DM Gripper Kit ($199.00): This kit includes the gripper (end-effector), with its mechanical parts and one Damiao 4310 motor to control it.
• reBot Arm B601-DM Assembled Kit with Gripper ($1,499.00): This is the fully assembled version for those who do not want to handle assembly and wiring.

All the reBot Arm B601-DM open-source AI robotic arm kits are listed for pre-order on the Seeed Studio store, with the Body Structure Kit estimated to be available on April 24, 2026.

The post reBot Arm B601-DM – An open-source 6+1 DoF robotic arm for embodied AI and teleoperation applications appeared first on CNX Software - Embedded Systems News.

After several leaks, the Intel Core Series 3 “Wildcat Lake” entry-level processor family is now official. Intel describes it as the first “hybrid AI-ready Core Series processor”.  As expected, the “Computer & CPU tile” comes with up to six cores (2x P cores + 4x LPE cores), up to 2-core Intel Xe 3 graphics, up to 40 TOPS of combined AI performance, and LPDDR5x/DDR5 memory interfaces.

The “Platform controller tile” integrates six PCIe Gen4 lanes, two Thunderbolt 4 interfaces, two USB 3.2 and eight USB 2.0 interfaces, as well as WiFi 7 and Bluetooth 6.0 connectivity. The Computer & GPU tile is manufactured using an Intel 18A process, while the Platform controller tile is manufactured with another “External” process (TSMC?).

Single-channel memory is confirmed, and it looks like eMMC flash will be replaced with UFS 3.0 memory for edge systems with soldered-on memory, although many systems will make use of PCIe Gen4 NVMe SSD instead. Some readers complained about the low number of PCIe lanes, but Intel says it’s for your good:

Intentionally designed PCIe to give the right amout of support, targeting to no unused PCIe lanes

I suppose it might make sense for laptops and edge computers the company has in mind… But it won’t be ideal for devices with multiple storage and networking options.

The leaks for the SKUs were mostly right, but the company lists SKUs for PCs and Edge applications, many of which overlap. All SKUs have a PBP of 15W and an MTP of 35W, 6MB Intel Smart Cache, and support up to 48GB LPDDR5x-7467 or 64GB DDR5-6400 of memory. One part, the Intel Core 5 305, does not come with NPU at all, and is reserved for Edge applications.

We previously assumed the Wildcat Lake family would be the successor of the Alder Lake-N and Twin Lake families, but Intel compares the Intel Core 7 360 SoC to the Intel Core 7 150U Raptor Lake 10-core (2P+8E) processor instead.  The new Wildcat Lake processors notably deliver up to 2.1x faster creation and productivity in the Topaz Video benchmark.

GPU performance is up to 2.7x better on AI workloads such as Procyon AI Image Gen SD 1.5 Light and Geekbench AI 1.6.

The Intel Core 7 360 is also much more efficient than the Intel Core 7 150U, with up to 64% reduction in power consumption, especially for video playback on YouTube and Netflix, and for video conferencing applications like Zoom. Battery life has been measured on the Intel Wildcat Lake reference platform, lasting up to 18.5 hours while watching YouTube, 12.5 hours for office productivity tasks, and 9.6 hours using Zoom with AI effects.

Intel also mentions that compared to a typical five-year-old PC based on an Intel Core i7-1185G7, the Core Series 3 delivers up to 47% better single-core performance, up to 41% better multi-core performance, and up to 2.8x better GPU AI performance. Photo editing (31%), web browsing (45%), and productivity (26%) have also all improved.

The Intel Core Series 3 also targets edge applications such as robotics, smart buildings, point-of-sale (POS) terminals, and smart metering, and to that effect, compared the Intel Core 7 350 to the Jetson Orin Nano. The Intel SoC delivers up to 1.5x higher object detection performance, up to 1.9x faster image classification, and up to 2.2x higher performance for video analytics.

Intel claims over 70 devices from partners are in the works, and some are available now. This notably includes laptops from Acer, Asus, Colorful, Dell Technologies, Hasee, Haier, Honor, HP, Infinix, Lenovo, Samsung, and others. Edge systems powered by Intel Core Series 3 will become available later in Q2 2026. You’ll find additional information, including more presentation slides, in the announcement as well as the product page. The Intel Ark website has yet to be updated, but it’s probably a question of hours or days.

The post Intel Core Series 3 “Wildcat Lake” processor family launched for entry-level laptops and Edge AI systems appeared first on CNX Software - Embedded Systems News.

Conclusive Engineering KSTR-SAMA5D27  is an ultra-compact (70x50mm) single board computer (SBC) powered by a Microchip SAMA5D27 Arm Cortex-A5 processor microprocessor clocked at 500 MHz paired with 256MB LPDDR2 (system-in-package).

The board also features a microSD card slot and EEPROM for storage/configuration, Fast Ethernet, WiFi 4, and Bluetooth 4.1 connectivity, a USB-C port, two GPIO headers, and supports USB and battery power. It’s designed for IoT devices, smart systems, and edge computing applications.

Conclusive Engineering KSTR-SAMA5D27 specifications:

• SiP –  Microchip SAMA5D27
  • CPU – Arm Cortex-A5 microprocessor @ 500 MHz
  • System Memory – 256 MB LPDDR2
• Storage
  • MicroSD card slot
  • 4KB EEPROM
• Networking
  • 10/100Mbps Ethernet RJ45 jack
  • 2.4 GHz WLAN IEEE 802.11 b/g/n and Bluetooth 4.1
• USB
  • 1x USB 2.0 OTG Type-C connector
  • 1x USB 2.0 Host on expansion header
• Expansion
  • 34-pin and 30-pin connectors
    • 2x Flexcom (configurable: I2C, SPI, UART)
    • I2C
    • 6-channel ADC with Vref
    • 10-bit ISC (Image Sensor Controller), 10-bit and 12-bit sensors support
    • 4-channel PWM
    • Timer I/O
    • CAN Bus
    • USB
    • PDMIC audio input
    • Console UART
    • 3.3 V, 2.5 V, 1.8 V, 5.0 V, and VBAT power supply pins
  • Qwiic connector
• Debug
  • Console debug UART on the expansion header
  • Conclusive Developer Cable connector
    • System UART
    • JTAG port
    • System I2C bus (EEPROM programming)
• Security
  • Arm TrustZone
  • Secure Boot
  • Hardware encryption engine
  • Memory Integrity Monitor
• Misc
  • Reset button
  • 3x status LEDs – Power Indicator, System Heartbeat, user programmable
  • Real-time clock (RTC) on MPU
  • Battery backup (CR1220) for RTC and static RAM
  • VDDIO voltage switch pins (3.3 V or 1.8 V selection)
• Power Management
  • 5V DC via USB Type-C port
  • External Li-Ion battery with charging, charge level, and temperature monitoring support via 3-pin connector and solder pads.
  • Consumption (SoC)
    • Less than 200 μA low power state with fast wake-up
    • 5 μA backup mode
• Dimensions – 70 x 50 mm

Conclusive Engineering provides support for Linux 6.1 & 6.5, U-Boot, the Yocto Project, Buildroot, and Ubuntu, while FreeBSD support is available on request. You’ll find documentation to get started and links to OS images and the source code on the wiki.

The SAMA5D2 family was first unveiled in 2018, and most boards and modules we covered were introduced from 2019 to 2021, including the Jupiter Nano, the tiny HaneSOM system-on-module, Arrow Shield96, and the misnamed “Giant” board with Adafruit Feather form factor. While the chip itself is about 8 years old, the KSTR-SAMA5D27 appears to be relatively new, and samples have been available on the company’s online store since last year.

Samples of the Microchip SAMA5D27 SBC can be purchased for $119 (+ VAT) on the Conclusive store.  Additional information may be found on the product page.

The post Conclusive Engineering KSTR-SAMA5D27 is an ultra-compact, low-power SBC based on Microchip SAMA5D27 SiP appeared first on CNX Software - Embedded Systems News.

ADLINK OSM-MTK520 is a 45 x 45mm OSM Size-L system-on-module (SoM) powered by a MediaTek Genio 520 AIoT processor with a 10 TOPS NPU for Edge AI workloads.

It’s basically an upgrade to the company’s OSM-MTK510 OSM Size-L module with a Genio 510 hexa-core SoC (3.2 TOPS NPU), up to 32GB eMMC flash, and 8GB LPDDR4 with a Genio 520 octa-core SoC (10 TOPS NPU), up to 256GB or 512GB UFS 3.1 storage, and up to 16GB LPDDR5 memory. There are also some minor changes to I/Os with an extra USB OTG interface, DisplayPort instead of HDMI, an extra MIPI CSI camera interface, fewer I2C interfaces, and more GPIOs.

ADLINK OSM-MTK520 specifications:

• SoC – MediaTek Genio 520 (MT8371)
  • CPU – Octa-core processor with 2x Cortex-A78 cores @ up to 2.2 GHz and 6x Cortex-A55 cores @ up to 2.0 GHz
  • GPU – Arm Mali-G57 MC2 GPU up to 880 MHz
  • VPU
    • H.265/HEVC or H.264 encoding up to 4Kp30
    • H.265/HEVC or H.264 decoding up to 4Kp60
  • AI accelerator – 10 TOPS NPU
• System Memory – 2GB, 4GB, 8GB, or 16GB LPDDR5
• Storage
  • 64GB, 128GB, 256GB, or 512GB UFS 3.1 flash
  • Optional SPI NOR flash
• 662 contacts with
  • Storage – 2x SDIO (4-bit), compatible with SD/SDIO standard, up to version 3.0
  • Display Interfaces
    • 4-lane DisplayPort 1.4
    • 4-lane MIPI DSI (multiplexed with LVDS)
    • 4-lane eDP 1.4
    • single-channel LVDS (multiplexed with MIPI DSI)
  • Camera – 2x 4-lane MIPI CSI
    • Compatible with the MIPI Alliance Interface Specification v2.1
    • Up to 4 data lanes, with a maximum data rate of 2.5 Gbps per lane
  • Audio
    • 2x I2S interfaces
    • I2S audio codec (located on the carrier)
  • Networking – Gigabit Ethernet with TSN
  • USB – 1x USB 3.1, 2x USB 2.0, 1x USB 2.0 OTG
  • PCIe – PCIe Gen2
  • Low-speed I/Os
    • 4x UART interfaces (UART A has Tx/Rx/CTS/RTS)
    • 3x SPI interfaces
    • 2x I2C interfaces
    • 22x GPIO with interrupts
• Security (as part of SoC)
  • Arm TrustZone
  • Security Boot (RSA4096)
  • Crypto Engine
  • True random number generation RNG
• Supply Voltage – 5V DC +/-5%
• Power Consumption – Under 5W
• Dimensions  – 45×45 mm (SGET OSM Size-L form factor)
• Temperature Range
  • Standard –  0°C to +60°C
  • Rugged –  -40°C to +85°C (optional)
• Humidity
  • 5-90% RH operating, non-condensing
  • 5-95% RH storage (and operating with conformal coating)
• Shock and Vibration
  • IEC 60068-2-64 and IEC-60068-2-27
  • MIL-STD-202F, Method 213B, Table 213-I, Condition A and Method 214A, Table 214-I, Condition D
• HALT – Thermal Stress, Vibration Stress, Thermal Shock, and Combined Test

ADLINK provides a Yocto Linux BSP for the module (not yet updated for OSM-MTK520) and can support Android and/or Ubuntu upon request.

I could not find any development for the MediaTek Genio 520 OSM module per se, but the company now offers an I-Pi OSM 510 Development Kit, combining the earlier OSM-MTK510 module with the OSM-EB4 carrier board. The latter might be reused with the OSM-MTK520 as is, or with minor modifications.

While it’s the first OSM module based on Genio 520 SoC we’ve seen, the processor was previously spotted in AMobile SoM-SD520 SO-DIMM system-on-module and Radxa NIO 5A SBC.

Two SKUs are currently listed for the ADLINK module: the OSM-MTK520-4G-64G-CT and OSM-MTK520-4G-64G-ER. Both are OSM Size-L modules with an octa-core Genio 520 SoC, 4 GB LPDDR5, and 64 GB UFS, but the former is standard, and the latter is rugged. More details. including a datasheet and a user manual, can be found on the product page.

The post ADLINK OSM-MTK520 – A MediaTek Genio 520-based OSM Size-L system-on-module appeared first on CNX Software - Embedded Systems News.

AAEON CEXD-INTRBL is an “open robotics development system” powered by a 16-core, 180 TOPS Intel Core Ultra X7 Processor 358H (Panther Lake) SoC and designed for the development of AI-enhanced humanoid robots and autonomous vehicle platforms.

The Edge AI computer features four 2.5GbE ports with support for IEEE1588 PTP (Precision Time Protocol), two FAKRA connectors for up to eight GMSL2 cameras, four USB 3.2  Type-C ports, two USB 2.0 ports, a CAN Bus connector, and a 40-pin HAT connector with 22 GPIOs.

AAEON CEXD-INTRBL specifications:

• SoC – Intel Core Ultra X7 358H
  • CPU – 16-core (4P + 8E + 4LPE) Panther Lake processor @ up to 4.8 GHz
  • Cache – 18 MB Smart Cache
  • GPU – 12-core Intel Arc B390 GPU @ up to 2.5 GHz (122 TOPS)
  • AI accelerator  – 50 TOPS; CPU + GPU + NPU combined: 180 TOPS
  • PBP – 25 Watts
• System Memory – Up to 64GB LPDDR5 8533MT/s
• Storage – 256GB NVMe SSD (default) via M.2 Key-M socket
• Display Interfaces
  • HDMI 1.4 up to 3840 x 2160 @ 30Hz
  • DP 1.4 up to 3840 x 2160 @144Hz
  • Up to 2x independent displays
• Camera interfaces
  • 2x FAKRA connectors for up to 8 GMSL2 cameras
  • 2x internal MIPI CSI connectors
• Audio
  • Realtek ALC897 audio codec
  • 3.5mm jack, Line-Out, Mic-in
  • 5W speaker via 2-pin header
• Networking
  • 4x 2.5GbE RJ45 ports via Intel I226-V 2.5Gbps Ethernet controllers
  • Optional WiFi and Bluetooth via M.2 socket
• USB
  • 4x USB 3.2 Gen 1 Type-C ports, used for the LiDAR, infrared, and depth sensors required for robotics
  • 2x USB 2.0 Type A ports
• Serial
  • CAN Bus
  • 2x RS-232
  • 2x RS-485
• Expansion
  • 40-pin HAT connector with 22x GPIO
  • M.2 2280 M-Key PCIe x4 socket fitted with 256GB NVMe SSD by default
  • M.2 2280 B-Key PCIe x2 socket
  • M.2 2230 E-Key socket for WiFi/Bluetooth
• Security – TPM 2.0
• Misc
  • UEFI with Wake-on-LAN (WoL), watchdog timer
  • 3V/240mAh Lithium battery for RTC
• Power
  • 19V – 24V DC input via 4-pin DIN Plug
  • AT mode
  • Consumption – 200W to 250W
• Dimensions – 137 x 135 x 86mm
• Temperature Range
  • Operating: 0°C – 50°C with 0.7m/sec air flow
  • Storage: -40°C – 85°C
• Humidity – 0% ~ 95% relative humidity, non-condensing
• MTBF – TBD
• Vibration – IEC 60068-2-24 , 5-500Hz ; 2grms
• Drop – ISTA PROJECT 1A (with Packing box)
• Altitude – 3000m (TBC)
• EMC – CE/FCC Class A

AAEON and Intel provide support for Windows 11 64-bit and Ubuntu 24.04/25.04 and later. You may wonder why it’s called an “open robotics development system”.  It’s apparently because it’s supported by the Open Edge Platform, and Intel provides reference setup scripts for various kinds of Intel platforms and GPUs on supported systems.  The CEXD kit is not listed on that page yet, but it is on the Intel website, and the scripts might be the same as for the UP Xtreme PTL Edge SBC. You can also watch a video demo with two robotics arms (leader/follower) using the CEXD-INTRBL system below.

AAEON sells the CEXD-INTRBL open robotics development systems on its eShop for $3,200 (pre-order, availability by the end of June). A few more details may also be found on the product page.

The post Intel Core Ultra X7 358H-powered open robotics development system targets humanoid robots and autonomous vehicles appeared first on CNX Software - Embedded Systems News.

TWOWIN Technology has introduced the TW-T808P-G, a rugged, fan-cooled, IP65 edge AI computer built around the NVIDIA Jetson Orin NX system-on-module (SoM). Designed specifically for autonomous driving, unmanned delivery vehicles, and smart inspection scenarios, the system provides up to 157 TOPS of AI performance and features various connectivity options for real-time processing in industrial and smart infrastructure environments.

Housed in an aluminum alloy enclosure, the device features aviation-grade M12 and M16 connectors for Gigabit Ethernet (PoE), RS232/RS485 serial communication, and power. Other features include two FAKRA connectors for up to eight GMSL2 cameras, USB 3.0, CAN Bus, GPIO, HDMI, and M.2 NVMe storage. It also supports optional Wi-Fi, 4G/5G, and RTK GPS for centimeter-level positioning. With a wide 9–36V input, a zero-power standby design using automotive ACC (ignition) control, and an operating range of -40°C to +70°C, the system is designed for applications such as security monitoring, smart gas stations, petroleum systems, power transmission inspection, and autonomous vehicles, supporting multi-channel video analytics and parallel AI workloads.

TWOWIN TW-T808P-G specifications:

• SoM – NVIDIA Jetson Orin NX module
  • CPU
    • 8GB Version – 6-core Arm Cortex-A78AE v8.2 64-bit CPU, 1.5MB L2 cache + 4MB L3 cache
    • 16GB Version – 8-core Arm Cortex-A78AE v8.2 64-bit CPU, 2MB L2 cache + 4MB L3 cache
  • GPU
    • 1024-core NVIDIA Ampere architecture GPU with 32 Tensor Cores
    • 1x NVDLA v2 @ 614MHz for 8GB and 2x NVDLA v2 @ 918MHz for 16GB
    • PVA v2 vision accelerator
  • Memory – 8GB/16GB 128-bit LPDDR5, 102.4GB/s
  • Video encode
    • 1x 4K60 (H.265) | 3x 4K30 (H.265)
    • 6x 1080p60 (H.265) | 12x 1080p30 (H.265)
  • Video decode
    • 1x 8K30 (H.265) | 2x 4K60 (H.265) | 4x 4K30 (H.265)
    • 9x 1080p60 (H.265) | 18x 1080p30 (H.265)
  • AI Performance – Up to 117 TOPS (8GB) or 157 TOPS (16GB) in Super mode
• Storage – M.2 M-Key socket supports 2280 NVMe SSDs (see Expansion section)
• Video Output – 1x HDMI 2.0 port
• Camera Inputs
  • Up to 8x GMSL2 cameras  via 2x FAKRA / Mini-FAKRA connectors
  • Configurations – 4x 8MP or 8x 2MP cameras
• Networking
  • 5x Gigabit Ethernet via 8-pin M12 aviation connectors (4x share a single network card with PoE support up to 25W; 1x independent Gigabit port)
  • 2.4/5.8GHz Wi-Fi (Optional)
  • 4G/5G cellular connectivity via Nano-SIM card slot (Optional)
• GNSS – Centimeter-level GPS (RTK/INS) outputting at 10Hz (Optional)
• USB
  • 2x USB 3.0 Type-A ports (5V/1A)
  • 1x USB 2.0 Type-C port (OTG, used for flashing)
  • 1x USB 2.0 Type-C Debug serial port
• Serial
  • 2x CAN bus ports supporting CAN FD (Mttcan+Spican)
  • RS232 M12 serial port
  • RS485 M12 serial port
• Expansion
  • 4x Isolated GPIO (2x GPI, 2x GPO available in 3.3V@1mA or 12V@1mA)
  • M.2 M-Key socket for PCIe x4 NVMe 2280 SSDs
• Misc
  • Power, RUN, USER, and SSD LED indicators
  • Reset and Recovery buttons
  • RTC (Real-Time Clock)
  • Mini-FAKRA antenna interfaces (shared for 4G/5G and WiFi/GNSS)
  • Active fans for cooling
  • PTP, PPS input/output, PWM output (Time Synchronized)
• Power
  • 9V to 36V wide DC input via M16 6-pin aviation connector
  • Maintains a dedicated Main Power and Backup Power (ACC) line for automotive ignition detection
  • Consumption – 45W (Typical)
• Dimensions – 295 x 214.3 x 76.5 mm
• Weight – ~4.0 to 4.3 kg
• Standard Operating Temperature – -20°C to +60°C
• Optional Wide Temperature – -40°C to +70°C (Note: -40°C power-on time takes 10±5 mins with <150W heating consumption)
• Storage Humidity – 5% to 95% non-condensing
• Ingress Protection – IP65
• Mounting – Flat or wall installation

On the software side, the TW-T808P-G comes pre-installed with Ubuntu from the NVIDIA Jetpack SDK. Because the custom carrier board utilizes proprietary interface drivers, the company explicitly advises users to back up their sources.list before performing standard apt-get upgrade commands so as not to overwrite the custom device tree.

The company also provides various utilities to manage the hardware. For networking, cellular modules (like the Quectel CM) can be configured via terminal scripts to auto-dial and fetch IPs. For vision applications, TWOWIN includes a graphical tool called tw_cfg_camera_ui to easily map specific GMSL deserializers and sensor models (like the MAX9295A and IMX390) to the board’s /dev/video nodes for multi-stream processing via GStreamer. More information about it is available in the user guide.

The company also discusses the ACC automotive ignition feature, in which if the main power remains connected to the battery but the ACC line drops, the system detects the power-failure signal and safely initiates a software shutdown, protecting the NVMe drive from data corruption.

The 8x GMSL2 camera support reminds me of the Lanner EAI-I351, Firefly EC-ThorT5000, Firefly EC-AGXOrin, and AAEON BOXER-8645A, all of which support 8x GMSL2 cameras, but the TW-T808P-G stands out with its IP65 ratings enabled by M12/M18 connectors.

As with most other industrial systems, pricing for the TWOWIN TW-T808P-G is not publicly available; you need to contact the company via the product page for details. However, we noticed the “Tuwei TW-T808P/TW-T808PG” with a similar design on AliExpress, but listing some odd memory options (4GB/8GB/16GB), while NVIDIA does not offer any Jetson Orin NX 4GB module. Also note the “Chip Board House Store” on AliExpress also list products with some massive markups (sometimes 2x).

The post IP65-rated TWOWIN T808P-G Edge AI computer features 8x GMSL2 cameras, aviation-grade M12/M16 connectors appeared first on CNX Software - Embedded Systems News.

Orange Pi Zero 3W is Raspberry Pi Zero-sized SBC powered by an Allwinner A733 octa-core Arm Cortex-A76/A55 SoC paired with up to 16GB of LPDDR5 RAM, a microSD card slot, and footprints for eMMC flash or UFS storage.

Other features include a 4K-capable mini HDMI port, two USB-C ports, one with DP 1.4 Alt mode, a MIPI DSI display connector, two MIPI CSI camera connectors, a WiFi 6 and Bluetooth 5.4 module, and a 40-pin GPIO header.

OrangePi Zero 3W specifications:

• SoC – Allwinner A733
  • CPU
    • Dual-core Arm Cortex-A76 @ up to 2.00 GHz
    • Hexa-core Arm Cortex-A55 @ up to 1.79 GHz
    • Single-core RISC-V E902 real-time core up to 200 MHz
  • GPU – Imagination Technologies BXM-4-64 MC1 GPU with support for OpenGL ES 3.2, Vulkan 1.3, OpenCL 3.0
  • VPU
    • 8Kp24 H.265/VP9/AVS2 decoding
    • 4Kp30 H.265/H.264 encoding
  • AI accelerator – 3 TOPS NPU
• System Memory – 1GB, 2GB, 4GB, 8GB, 12GB, or 16GB LPDDR5 at 4,800 MT/s
• Storage
  • MicroSD card slot up to 128GB
  • Footprint for optional 8GB, 16GB, 32GB, 64GB, or 64GB eMMC flash module
  • Footprint for optional 32GB, 64GB, or 128GB 2-lane UFS 3.0 module
• Video Output
  • Mini HDMI 2.0 port up to 4Kp60 resolution
  • 4-lane MIPI DSI connector
  • USB-C port with DisplayPort Alt mode up to 4Kp60
  • Support for dual independent display setups
• Camera interface – 2x 4-lane MIPI CSI connectors
• Networking – Dual-band WiFi 6 and Bluetooth 5.4 module (Cdtech 20800D8-00) + IPEX antenna connector
• USB
  • USB 3.1 OTG Type-C port with DisplayPort 1.4 Alt. mode
  • USB 2.0 Type-C power port
• Expansion
  • 40-pin color-coded GPIO header supporting GPIO, UART, I2C, SPI, and PWM.
  • PCIe Gen3 x1 FPC connector
• Misc
  • Power and BOOT through holes
  • 2-pin fan header
• Power Supply – 5V/3A via USB-C connector
• Dimensions – 65 x 32 mm
• Weight – 14 grams

Orange Pi plans to provide Orange Pi OS (Arch), Ubuntu, Debian, and Android (15) images for the Pi Zero 3W, but all links on the product page currently point to empty Google Drive shares. They should become available in the next few days or weeks.

The Orange Pi Zero 3W is very similar to the Radxa Cubie A7Z introduced last year, but replaces the micro HDMI port with a mini HDMI port and LPDDR4 with LPDDR5,  and adds one MIPI CSI camera connector, one MIPI DSI display connector, as well as a footprint for an eMMC flash. We were previously promised mainline Linux support for the Allwinner A733 SoC, but it’s clearly not happening when looking at recent Linux changelogs, including the one for the just-released Linux 7.0.

The 16GB version is not available yet, but Orange Pi released pricing for the Zero 3W SBC as follows:

• 1GB RAM – $25
• 2GB RAM – $35
• 4GB RAM – $50
• 6GB RAM – $60
• 8GB RAM – $80
• 12GB RAM – $99.90
• Cooling fan – $5.99

Those prices seem reasonable in a world where the Raspberry Pi 5 8GB now sells for $175. You can purchase the boards with the cooling fan on AliExpress and on Amazon with a small markup.

The post Orange Pi Zero 3W – An Allwinner A733 SBC in Raspberry Pi Zero form factor appeared first on CNX Software - Embedded Systems News.

With the price of RAM getting out of control, it might be a good idea to remind Linux users to enable ZRAM so they can get better performance without upgrading memory, or save money on their next single board computer by selecting a board with the right amount of memory.

I had already written about the subject when I enabled ZRAM on a ODROID-XU4Q in 2018 using zram-config, and did the same on my Ubuntu laptop at the time. In recent days, I found Firefox crashing often due to running out of memory on my system with 16GB of RAM, and the Linux 7.0 release reminded me about ZRAM, since there were some related changes. So I decided to check the current swap configuration on my Ubuntu 24.04 laptop:

jaufranc@CNX-LAPTOP-5:~$ zramctl 
NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle       7.6G  6.6G  2.1G  2.1G         [SWAP]
jaufranc@CNX-LAPTOP-5:~$ swapon
NAME       TYPE      SIZE USED PRIO
/swapfile  file        8G 5.6G   -2
/dev/zram0 partition 7.6G 7.3G    5
jaufranc@CNX-LAPTOP-5:~$ free -mh
               total        used        free      shared  buff/cache   available
Mem:            15Gi       9.6Gi       4.3Gi       2.4Gi       3.4Gi       5.7Gi
Swap:           15Gi        12Gi       2.7Gi

lzo doesn’t look like a recent compression algorithm, and I think I’ve seen Zstandard compression used on other systems before. However, the zram-config utility appears to be an older solution, and it’s now been replaced with zram-tools. So I decided to replace it. If you haven’t already enabled ZRAM with zram-config, you don’t need to do that, but in my case, I had to disable swap and purge the package:

sudo swapoff -a
sudo swapoff /dev/zram0 2>/dev/null || true
echo 1 | sudo tee /sys/block/zram0/reset 2>/dev/null || true
sudo modprobe -r zram
sudo apt purge --autoremove zram-config

Once done, I installed zram-tools:

sudo apt install zram-tools

and edited the /etc/default/zramswap file as follows:

# Compression algorithm selection
ALGO=zstd
# Specifies the amount of RAM that should be used for zram
# based on a percentage the total amount of available memory
# This takes precedence and overrides SIZE below
PERCENT=75
...

# Specifies the priority for the swap devices, see swapon(2)
# for more details. Higher number = higher priority
# This should probably be higher than hdd/ssd swaps.
PRIORITY=100

To be on the safe side, you may want to check zstd if supported by your kernel:

jaufranc@CNX-LAPTOP-5:~$ cat /sys/block/zram0/comp_algorithm
lzo-rle lzo lz4 lz4hc [zstd] deflate 842

I then restarted the service with the new parameters:

sudo systemctl start zramswap.service

Finally, let’s check if everything is enabled as expected:

jaufranc@CNX-LAPTOP-5:~$ cat /sys/block/zram0/comp_algorithm
lzo-rle lzo lz4 lz4hc [zstd] deflate 842 
jaufranc@CNX-LAPTOP-5:~$ zramctl
NAME       ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd         11.4G   7G  1.4G  1.5G         [SWAP]
jaufranc@CNX-LAPTOP-5:~$ swapon --show
NAME       TYPE       SIZE USED PRIO
/dev/zram0 partition 11.4G 7.8G  100
jaufranc@CNX-LAPTOP-5:~$ free -mh
               total        used        free      shared  buff/cache   available
Mem:            15Gi        12Gi       561Mi       2.4Gi       3.8Gi       2.8Gi
Swap:           11Gi       7.8Gi       3.6Gi
jaufranc@CNX-LAPTOP-5:~$

It looks good. The swapfile on my NVMe SSD is not used anymore, but I’ll try to use my system that way, and only re-enable it in case the system runs out of memory.

Finally, I wanted to make sure it was enabled on my Raspberry Pi 5 with 2GB of RAM, and I forgot that it’s indeed enabled by default on Raspberry Pi OS:

pi@raspberrypi:~ $ zramctl 
NAME       ALGORITHM DISKSIZE   DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd            2G 181.9M 22.7M 29.6M       4 [SWAP]
pi@raspberrypi:~ $ free -mh
total used free shared buff/cache available
Mem: 2.0Gi 1.2Gi 213Mi 38Mi 794Mi 808Mi
Swap: 2.0Gi 178Mi 1.8Gi

Note the config for rpi-swap is in a different location: /etc/rpi/swap.conf, and follows a different format:

#  This file is part of rpi-swap.
#
#  Defaults are provided as commented-out options. Local configuration
#  should be created by either modifying this file, or by creating "drop-ins" in
#  the swap.conf.d/ subdirectory. The latter is generally recommended.
#
#  See swap.conf(5) for details.

[Main]
#Mechanism=auto

[File]
#Path=/var/swap
#RamMultiplier=1
#MaxSizeMiB=2048
#MaxDiskPercent=50
#FixedSizeMiB=

[Zram]
#RamMultiplier=1
#MaxSizeMiB=2048
#FixedSizeMiB=
# Writeback settings (for zram+file mechanism):
#WritebackTrigger=auto
#WritebackInitialDelay=180min
#WritebackPeriodicInterval=24h

More details about this specific implementation can be found on GitHub. If you are using a different operating system on any SBC, you may want to check ZRAM (or  zswap) is enabled.

The post Reminder: enable ZRAM on your Linux system to optimize RAM usage (and potentially save money) appeared first on CNX Software - Embedded Systems News.

The LimeSDR Micro M.2 2280 software-defined radio (SDR) card combines an NXP LA9310 baseband processor and a Lime Microsystems LMS7002M transceiver, and targets integration into portable or embedded solutions with a spare M.2 PCIe Gen3 x1 socket.

The module is offered in a 1T2R configuration by default, but can be expanded to 1T4R via an FPC connector, supports a 30 MHz to 3.8 GHz frequency range, and up to 100 MHz bandwidth. Target applications include 4G LTE/5G, future RAN research, custom user equipment/modems, drone communications, IoT, satellite communications, and custom waveform generation.

LimeSDR Micro M.2 SDR card specifications:

• SoC – NXP LA9310 programmable baseband processor
  • Vector Signal Processing Accelerator (VSPA) Gen 2 up to 80 GFLOPs
  • Control Processor – Arm Cortex-M4 at up to 307 MHz
• Storage – 512 Kbit EEPROM memory for NXP LA9310 initial configuration
• RF
  • Lime Microsystems LMS7002M RF transceiver
  • Channels – 1T2R expandable to 1T4R via two analogue baseband inputs on an FPC connector (see Connectors section below)
  • Frequency Range – 30 MHz to 3.8 GHz
  • Bandwidth – 100 MHz TDD or half-duplex operation and 50 MHz FDD
  • Analogue Filtering – 0.75 – 100 MHz
  • Sample Rate – Up to 160 Msps half-duplex (Tx or Rx) and TDD, and up to 61.44 Msps FDD
  • Connectors
    • 3x MHF4 RF (TX, RX1 & RX2)
    • 15-pin FPC external analogue I/Q baseband input (RX3 & RX4)
• Host Interface – PCIe Gen 3 x1 via M.2 Key -B+M edge connector
• I/O expansion via 8-pin FPC connector
  • 4x GPIOs 3.3V on GPIO connector
  • I2C on GPIO connector (shared with on-board devices)
• Sensor – TMP1075NDRLR temperature sensor
• Clock Subsystem
  • Rakon E6245LF 30.72 MHz VCTCXO
  • VCTCXO may be tuned by an onboard 16-bit DAC
  • Reference clock input and output connector
  • 4x MHF4 clock and PPS I/O
• Misc
  • 2x Green LEDs
  • Optional GNSS Receiver: Antenova M10578-A3 3 for location, time of day, and generating a VCTCXO DAC value. A future firmware update might add GSPDO support (TBC)
• Power Supply –  3.3V via M.2 edge connector
• Dimensions – 80 x 22 mm; note: the card may not be suited to installation in certain space-constrained systems, e.g., laptops, due to the non-standard module height of up to ~4mm from the PCBA top side.

LimeMicro has offered SDR solutions based on the LMS7002M RF transceiver for years, but they were all FPGA-based so far. They’ve now switched to the NXP LA9310 ultra-low-power baseband processor for applications needing to meet specific size, weight, and/or power requirements.

It’s still 100% programmable, and the company points to the NXP LA9310 Reference Manual and VSPA2 Instruction Set Manual both available without NDA, open source VSPA kernels for functions such as FFT, inverse FFT, CRC generation, FIR filters, mixer, and modulation/demodulation (some compatible with MATLAB), as well as the existing documentation for the LMS7002M chip which is supported by the Lime Suite NG driver stack and the wider SDR ecosystem with integration with projects such as SoapySDR, GNU Radio, Amarisoft 4G/5G, OpenAirInterface, and srsRAN. The company will also release the hardware design for the M.2 module, and the  DSP firmware and Arm firmware have already been released on GitHub.

The company also designed the LimeFEA HF Micro to add a third receive path with a frequency range of 0 – 30 MHz to LimeSDR Micro with the following key features.

• Medium Wave (MW) broadcast notch filter
  Band filters
  • 0 – 2 MHz LPF
  • 2 – 12 MHz BPF
  • 12 – 30 MHz BPF
• 90 dB gain
• 72 dB programmable step attenuation
• 5x MHF4 to SMA transition
• TDD switching out

Two other products are the LimeSDR Micro Pro, which combines the LimeSDR Micro and the LimeFEA HF Micro to provide a USB4 (40 Gbps mode only) peripheral with an aluminum enclosure, and the LimeFEA M.2 2280 full-size PCIe x4 card with a 2×2 MIMO RF front-end (RFE), which integrates low-noise amplifiers in the receive paths (100 MHz to ~4 GHz receive frequency range) and power amplifier (PA) drivers in the transmit paths (100 MHz to 6 GHz transmit frequency range).

Lime Microsystems had launched the LimeSDR Micro M.2 SDR card and associated products on Crowd Supply with a $100,000 funding target. Rewards start at $199 for the LimeSDR Micro basic and $299 for the LimeSDR Micro GNSS. A pledge of $199 is asked for the LineFEA HF Micro card,  $299 for the LimeFEA M.2 2280 PCIe card, and $799 for the LimeSDR Micro Pro system. Shipping adds $8 to the US, $18 to the rest of the world, and deliveries are scheduled to start by September 30, 2026.

The post LimeSDR Micro M.2 2280 SDR card pairs NXP LA9310 baseband processor with LMS7002M RF transceiver (Crowdfunding) appeared first on CNX Software - Embedded Systems News.

Waveshare PocketTerm35 is a portable handheld terminal for the Raspberry Pi 4 or 5 single board computers featuring a 3.5-inch touchscreen display and a built-in QWERTY keyboard.

The device also features Gigabit Ethernet and USB 3.0/2.0 ports from the Raspberry Pi SBC, gaming buttons, a built-in stereo speaker, a 3.5mm audio jack, a USB Type-C port for power, and an optional 5,000 mAh battery.

PocketTerm35 specifications:

• Compatible SBC – Raspberry Pi 4 Model B and Raspberry Pi 5
• MCU – Raspberry Pi RP2040 MCU for keyboard, brightness, and volume
• Storage – Optional 64GB microSD card with OS
• Display – 3.5-inch 640 × 480 IPS display with 5-point capacitive touch; toughened glass panel, 6H hardness
• Audio
  • Built-in 8Ω 2W stereo speaker
  • 3.5mm audio jack
• Networking – Gigabit Ethernet ports (on Pi 4/5)
• USB – 2x USB 3.0 ports, 2x USB 2.0 ports (on Pi 4/5)
• User Input
  • 67 keys QWERTY silicone keyboard
  • D-Pad
  • X, Y, A, B, L, R, Start, and Select buttons
• Misc
  • Power button – Short press to turn on, double-press to turn off
  • Reset and BOOT buttons
  • Battery level LEDs
• Power
  • USB-C charging port
  • 2-pin battery header for optional 5,000 mAh Lithium battery
  • UPS power management supports simultaneous charging and operation
• Dimensions – 168.5 x 93.5 x 37 mm (thickness: 21.6 to 37 mm)
• Case material
  • CNC-machined aluminum front cover
  • PC + ABS plastic back cover

The PocketTerm35 is designed to run Raspberry Pi OS, and you’ll find an assembly guide for the kits without Raspberry Pi SBC, software configuration instructions (changes to config.txt and DTBO update), and basic hardware details on the documentation website. They’ll also soon release a image with the changes, but it’s not available for download just yet.

config.txt changes:

dtparam=i2c_arm=on
  dtoverlay=waveshare-35dpi-4b
  dtoverlay=waveshare-35dpi-5b
  dtoverlay=dwc2,dr_mode=host

I was about to say the PocketTerm35 reminds me of the Pilet portable computer, just with a smaller 3.5-inch display, but the massively delayed project has just announced a switch from Raspberry Pi 5 to Raspberry Pi CM5, to the anger of backers. Other Raspberry Pi 5 handheld computers, like the PiBoy DMGx, have quite a different design.

It looks especially well-suited for (retro) gaming with the choice of buttons, but can also be used as a terminal device and a portable HMI controller, although the small 3.5-inch display might not be suitable for everybody.

The PocketTerm35 is sold as a kit or a complete system in four configurations:

• PocketTerm35-Pi4 – With Raspberry Pi 4B 2GB,  64GB microSD card with Raspberry Pi OS, and a 5,000mAh Lithium battery
• PocketTerm35-Pi5 – With Raspberry Pi 5 1GB,  64GB microSD card with Raspberry Pi OS, and a 5,000mAh Lithium battery
• PocketTerm35-RPI-ACCE – Without Raspberry Pi board and microSD card, but the 5,000mAh lithium battery is included
• PocketTerm35-RPI-ACCE-EN – Minimal system without Pi, microSD card, or battery

You’ll find the Raspberry Pi 4/5 handheld for  $87.99 to $179.99 on the Waveshare store. It used to be on AliExpress a few days ago, but it’s now out of stock, and might soon show up on the company’s Amazon store.

Thanks to Thomas for the tip.

The post PocketTerm35 – A Raspberry Pi 4/5-based handheld Linux terminal with 3.5-inch touch display and built-in keyboard appeared first on CNX Software - Embedded Systems News.

WCH CH32V205 is a 32-bit RISC-V MCU clocked at up to 192 MHz with 32KB SRAM, 256KB flash, and a USB 2.0 high-speed Host/device interface with a 480 Mbps PHY.

The new microcontroller also features another USB 2.0 full speed (12 Mbps) Host/Device interface, a USB PD port, eighty GPIOs, a 16-channel 12-bit ADC, a 16-channel touchkey interface, and other interfaces such as CAN Bus, USART, I2C, SPI, and QSPI.

WCH CH32V205 specifications:

• MCU core – QingKe 32-bit RISC-V3B core processor up to 192 MHz
• Memory & Storage
  • 32KB SRAM
  • 256KB Flash
  • Flexible Static Memory Controller (FSMC)
• Peripherals
  • USB
    • 480Mbps high-speed USB 2.0 controller and PHY
    • Full-speed USB 2.0 controller and PHY
    • USB PD and Type-C controller and PHY
  • 8x USARTs, 2x I2C, 2x SPI , 1x QuadSPI
  • 1-wire (default)/ 2-wire serial debug interface
  • 1x CAN 2.0B
  • Up to 80x GPIO with 16 external interrupts
  • Programmable Protocol I/O Controller (PIOC). Note: likely something similar to Raspberry Pi RP2040/RP2350’s programmable IOs (PIO)
  • Analog
    • 2x groups of analog voltage CMP
    • 2x groups of OPA/PGA/CMPs
    • 16-channel 12-bit ADC
    • 16-channel TouchKey
  • 2x groups of 16-channel general-purpose DMA
  • Timers – 4x groups of timers
• Power Management
  • Supply voltage – 3.3V
  • Low-power modes – Sleep/Stop/Standby
  • Power on/off reset, programmable voltage monitor
• Packages – LQFP48, LQFP64, LQFP100

The CH32V205 appears to build upon the earlier CH32V203, but offers more GPIO, a 480 Mbps USB HS port, and USB-C PD support, and other changes. As a side note, if you’d rather get a more powerful RISC-V MCU with a USB 3.0 interface, then the WCH CH32H417 might be worth a look.

The English versions of the CH32V205 datasheet and reference manual can be found on the download page, but for C code samples (CH32V205EVT.ZIP), you currently need to head over to the download page in Chinese. Development can be done through the MounRiver IDE, but CNLohr’s GCC toolchain (CH32fun) might soon support the new RISC-V microcontroller, since CH32V203 and CH32V208 are already supported.

I found out about the CH32V205 chips today, as WCH has started to sell bundles of 5 samples for $6.67 on AliExpress, or about $1.34 per unit (CH32V205CCT6 – 48-pin package). However, the CH32V205RCT-R0-1v0 evaluation board doesn’t seem to be available for sale at this stage.

The post 192 MHz WCH CH32V205 RISC-V MCU offers a 480 Mbps USB 2.0 interface appeared first on CNX Software - Embedded Systems News.

Designed by SmartHomeGuys in the UK, the DeskUp Pro is an ESP32-based standing desk controller compatible with Home Assistant, Homey Pro, and other Smart Home hubs, using the desk’s standard RJ11/RJ12 connection.

Many modern standing desks come with a controller from Jiecang or another company featuring an RJ12 port. The DeskUp Pro plugs directly into this port, draws power without an external USB supply, and bridges the desk’s controls to your 2.4 GHz Wi-Fi network. This allows you to automate your desk height, set health-focused standing reminders, or use voice assistants like Google Home and Alexa, all while keeping the desk’s original physical keypad fully functional.

DeskUp Pro specifications:

• MCU – Espressif Systems ESP32-C6 or ESP32-S3 microcontroller with 2.4GHz Wi-Fi and Bluetooth LE
• Desk connectivity – Built-in RJ11/RJ12 cable for data and power
• USB – USB Type-C port for initial setup and firmware flashing
• Misc
  • Supported Jiecang control boxes
  • JCB36NE2 (used in Desktronic Home One)
  • JCB36N2HAG-230 (used in Boho Office),
  • JCHT35K72C, JCB35M11C, and JCHT35K9-003-v4
• Power Supply – Powered directly from the desk controller via the RJ12 connection
• Dimensions  – TBD
• Enclosure – Custom 3D-printed case

The developer created this project to automate standing reminders, helping reduce issues like sciatica caused by prolonged sitting. It is built using community reverse-engineered desk commands, allowing the DeskUp Pro to convert smart home commands into the signals needed to control the desk’s motor.

He also mentions that desk manufacturers frequently change their internal electronics and software (even under the same model number), so compatibility is not universally guaranteed. However, known working models include the Maidesite Premium/Standard lines, Desktronic Home One, Boho Office Basic Line, and the IKEA Uppspel. Note that Maidesite removed the RJ12 port on their Standard controllers manufactured after July 2025.

The DeskUp Pro standing desk controller comes pre-flashed with ESPHome firmware and exposes up to 32 entities in Home Assistant, including height control, sensor values, and preset positions, enabling full desk automation and monitoring. It also features a built-in web interface and REST API, allowing integration with other smart home platforms that support API requests, making it flexible beyond a single ecosystem. Initial setup can be done via USB-C or Bluetooth, and the project is open-source with documentation, example dashboards, and automation templates available for customization or DIY builds.

The DeskUp Pro is available on Ebay UK (57.42 GBP) and Tindie for $75, with the price dropping to $65 when buying multiple units. If you prefer a DIY approach, you can build your own using the provided wiring instructions and YAML configuration from its GitHub repository. But keep in mind that the open-source project is licensed for personal, non-commercial use only.

The post DeskUp Pro smart standing desk controller integrates with Home Assistant and Homey Pro Smart Home hubs appeared first on CNX Software - Embedded Systems News.

vicliu624’s Trail Mate is an open-source firmware for off-grid communication and GPS coordinates sharing, leveraging the Meshtastic, MeshCore, and other projects, and designed for ESP32 handhelds such as LILYGO’s T-LoRa Pager or M5Stack’s Tab5 with a LoRaWAN module.

The Trail Mate firmware provides a fixed north-up GPS map, direct LoRa text messaging through Meshtastic or MeshCore mesh networks without relying on a smartphone, and prioritizes stability, efficiency, and interoperability over feature density.

Trail Mate user interface highlights:

• Simple main menu with four icons: GPS, LoRa chat, tracker, and system utilities.
• GPS map
  • Fixed North-Up map orientation (no rotation)
  • Fully offline map rendering from SD card tiles (png/jpg files)
  • Three switchable base layers: OSM / Terrain / Satellite
  • Optional contour overlay for terrain shape awareness
  • Real-time position marker for the current GPS fix
  • Discrete zoom levels optimized for embedded systems
  • Simple breadcrumb trails for path awareness
  • Fast in-page layer switching via map layer menu (no page restart)
• GNSS Sky Plot
  • Real-time sky plot of visible satellites (azimuth/elevation)
  • SNR status and constellation coloring (GPS/GLONASS/Galileo/BeiDou)
  • Clear indication of satellites used in the current fix
  • Summary of USE/HDOP/FIX for fast diagnostics
• Energy Sweep (Sub-GHz Scan) provides a fast Sub-GHz occupancy view for channel planning in the field.
• LoRa Chat (Meshtastic + MeshCore Compatible) with English and Chinese text support, Bluetooth connectivity to mobile companion apps,
• SSTV Receiver (Slow-Scan TV) to receive audio and decode to images on-device (See video below at the end of the article)
• Contacts –  Shows discovered nodes, recent activity, and quick actions to jump into direct or team conversations.
• Data Exchange  – A PC Link connects the device to a host computer and exposes a structured HostLink stream for real-time APRS/iGate integration, diagnostics, and data capture.
• Team Mode – Designed for small groups that are physically together, the handhelds pair over ESP-NOW at close range to exchange a team key, then all team operations run over LoRa.
• Track Recording & Route Following
• Walkie Talkie
  • FSK + Codec2 voice walkie-talkie
  • Half-duplex PTT (press to talk/release to listen)
  • Jitter buffering and fixed playback cadence for stability

The following hardware platforms are currently supported or under development:

• PlatformIO/Arduino-based targets
  • LILYGO T-LoRa Pager (SX1262) – Reference platform, default environment; SX1280 variant is also supported, but less tested
  • LILYGO T-Deck – Primary validation target
  • GAT562 Mesh EVB Pro – Resource-constrained target, some features are trimmed
  • LILYGO T-Deck Pro – Under development
  • LILYGO T-Watch S3 – Experimental target
• Targets using the ESP-IDF framework
  • M5Stack Tab 5 –  Main large-screen IDF bring-up target. The shared shell runs, hardware-specific work is in progress
  • LILYGO T-Display P4 – Alternative IDF development device

That means the LILYGO T-LoRa Pager is the preferred platform. It can be purchased for just under  $100 on AliExpress and on Amazon.

You’ll find the code and resources to get started on GitHub, with everything released under an AGPLv3 license. These days, many software projects rely on AI coding, even the Linux kernel, and Trail Mate is no different:

All code in Trail Mate is 100% generated by AI under human guidance. The project itself is a long-term experiment in human–AI collaboration for real engineering systems.

LILYGO installed Trail Mate on the T-LoRa Pager and you can watch a short SSVT image transmission demo in the video embedded below.

#LILYGO #LoRa #Meshtastic #OpenSource– perfect for off-grid messaging & outdoor adventures!
Open-source & ready to flash → https://t.co/d5JG1wVlws
Thanks for the great work! Who’s building next?
Exciting community project alert!
T-LoRa Pager running Trail Mate firmware… pic.twitter.com/KugejoIrvu

— LILYGO (@lilygo9) February 10, 2026

The post Trail Mate open-source firmware leverages Meshtastic and MeshCore for ESP32 off-grid handhelds appeared first on CNX Software - Embedded Systems News.

Linus Torvalds has just released Linux 7.0 on LKML:

The last week of the release continued the same “lots of small fixes” trend, but it all really does seem pretty benign, so I’ve tagged the final 7.0 and pushed it out.

I suspect it’s a lot of AI tool use that will keep finding corner cases for us for a while, so this may be the “new normal” at least for a while. Only time will tell.

Anyway, this last week was a little bit of everything: networking (core and drivers), arch fixes, tooling and selftests, and various random fixes all over the place.

Let’s keep testing, and obviously tomorrow the merge window for 7.1 opens. I already have four dozen pull requests pending – thank you to all the early people.

Linus

This follows the Linux 6.19 release about two months ago, which brought us PCIe link encryption and secure device authentication, BTRFS and EXT-4 file systems improvements, and color pipeline API for HDR support, among various other changes. There’s nothing specific about Linux 7.0, and it’s not a major release, but Linus usually updates the “major” number once we reach 19. So it’s Linux 7.0 instead of Linux 6.20.

Notable changes in Linux 7.0

Some newsworthy changes to Linux 7.0 include:

• AI Coding Assistants documentation – Linux 7.0 introduced documentation regarding AI coding tools. It’s fine to use AI in the Linux kernel, but the human submitter is responsible for reviewing all AI-generated code, compliance, and taking responsibility for the contribution. Only humans can use “Signed-off”, and the AI tools must be reported with the “Assisted-by” tag:
  

  Assisted-by: Claude:claude-3-opus coccinelle sparse

• Rust support is no longer experimental. Individual subsystem maintainers are still free to keep it out of their subsystems.
• New generic API for file IO error reporting – So far, each filesystem on Linux has had its own mechanism for reporting metadata corruption and file I/O errors to userspace via fsnotify. Linux 7.0 introduces a generic fserror infrastructure that gives filesystems a standard way to queue metadata and file I/O error reports for delivery to fsnotify.
• Better swapping performance with swap table, phase II – We had previously reported that Linux 6.18 used the swap table infrastructure as a swap cache backend, leading to 5 to 20% performance. Phase II of the swap table code further cleans up and speeds up the swapping code. See LWN article for details.
• zram implements compressed data writeback. Previously, the kernel would have to decompress the pages before writing them to the physical device (uncompressed data writeback), unnecessarily wasting CPU cycles and battery, but now page writeback can directly write zram-compressed data. See commit for details.

Linux 7.0 changes for the Arm architecture

• Support for atomic 64-byte loads and stores (FEAT_{LS64, LS64_V}) on Arm CPUs that provide the feature (Armv8.7 and greater).
• Allwinner
  • Device tree changes for Linux 7.0
    • A523 – Support for SPI controllers.
    • Some cleanup of old ARM device tree files to fix DT binding validation errors.
    • D1 and A100 SoCs gained support for their LED controller.
    • D1 and T113 SoCs gained support for the internal thermal sensor.
  • New devices – N/A
• Rockchip
  • Pinctrl – Fix configuration of deferred pin in the Rockchip driver
  • MFD – Add support for the Rockchip RK801 PMIC, including core MFD and regulator drivers
  • ASoC  – S/PDIF: cleanups and port features
  • DRM
    • RK3368 HDMI Support
    • Get rid of atomic_check fixups
    • RK3506 support
    • RK3576/RK3588 improved HPD handling
    • Convert Rockchip’s inno HDMI support to a proper bridge
    • Get rid of atomic_check fixups, add Rockchip RK3506 Support
  • VPU – Add H.264/H.265 video decoders for RK3576 and RK3588
  • ARM64 DTS
    • Fix SD card support for RK3576 Nanopi R76s and RK3576 EVB1
    • Add overlay for PCIe slot, enable HDMI and analog sound on RK3576 EVB1
    • Enable HDMI sound on Luckfox Core3576, FriendlyElec NanoPi M5
    • Enable UFS controller on FriendlyElec NanoPi M5
    • Add dma-coherent for pcie and gmac of RK3576
  • New devices
    • Radxa CM3J system-on-module (RK3568J) + support for Raspberry Pi CM4 IO board
    • Radxa Compute Module 5 (CM5) based on RK3588S SoC + IO board
    • Orange Pi CM5 module + baseboard
    • Anbernic RG-DS game console (RK3568)
    • QNAP TS-133 NAS (RK3566)
• Amlogic
  • SPI
    • spifc-a4: unregister ECC engine on probe failure and remove() callback
    • amlogic-spisg: Fix memory leak in aml_spisg_probe()
    • spifc-a4: Remove redundant clock cleanup
    • Fix DMA mapping error handling
  • Pinctrl – Move pretended generic pin control functionality out of the core and into the Amlogic AM4 driver.
  • Clock
    • Add support for Amlogic T7 clock controllers (peripherals, SCMI, PLL)
    • Add video clocks on Amlogic S4 (S805X2/S905Y4)
    • HDMI PLL post divider fixes on Amlogic gx/g12 SoCs
  • Amlogic Drivers for Linux 7.0 – New SoC ID for S905Y4
  • ARM device tree – drop iio-hwmon in favour of generic-adc-thermal
  • ARM64 device tree for Linux 7.0
    • Cleanups:
      • Use lowercase hex
      • Use hyphens in node names
      • Move CPU OPP table and clock assignment to SoC.dtsi
      • Drop useless assigned-clock-parents
    • MMC clock fixup across multiple families
    • Add a Type-C controller on Radxa Zero 2 and enable NPU
  • New device – Khadas VIM1s SBC based on Amlogic S905Y4
• Samsung
  • Pinctrl – Exynos 9610 (ARM64) pin control support
  • PHY – Update ExynosAuto v920 USB3, combo hsphy and ssphy support
  • Clock driver
    • Add new clock controllers:
      • MFD for ExynosAuto v920 SoC
      • Display Process Unit (DPU) for Google GS101 SoC.
    • Implement automatic clock gating mode (HWACG) for Google GS101 SoC clock controllers (but also used on almost all modern Exynos SoCs), opposed to the currently used mode: manual mode.
  • SoC Drivers
    • Several improvements in Exynos ChipID Socinfo driver and finally adding Google GS101 SoC support.
    • Few cleanups from old code.
    • Documenting Axis Artpec-9 SoC PMU (Power Management Unit).
  • DTS ARM changes – N/A
  • Samsung DTS ARM64 changes for Linux 7.0
    • ExynosAuto v920 – Add MFD clock controller node.
    • Google GS101:
      • Add True Random Number Generator (TRNG) and OTP nvmem nodes.
      • Correct the PMU (Power Management Unit) compatibles by dropping fallback to syscon. The PMU on Samsung devices serves the role of syscon, however on GS101 it cannot be used via standard Linux syscon interface, because register accesses require custom regmap. It was simply never correctly working with “syscon” compatible fallback.
      • Add phandles to System Registers SYSREG blocks in clock controllers, necessary for enabling automatic clock control later.
    • Add DPU clock management unit nodes to Google GS101.
  • Defconfig changes – N/A
  • New Device – N/A
• Qualcomm
  • New SoCs
    • Qualcomm Milos – Snapdragon 7s Gen 3 (SM7635) mobile phone SoC built around Armv9 Kryo cores of the Arm Cortex-A720 generation. Used in the Fairphone Gen 6
    • Qualcomm Kaanapali – SoC based around eight high-performance Oryon CPU cores.
  • Pinctrl – Qualcomm Mahua TLMM (ARM64) pin control support
  • Audio – USB:  update Qualcomm USB audio Kconfig dependencies and license
  • Soundwire – Support for Qualcomm v2.2.0 controllers
  • DMA engine – Add support for Qualcomm Kaanapali and Glymur GPI DMA engine
  • PHY
    • Add support for Qualcomm Glymur PCIe Gen4 2-lanes PCIe phy, DP and edp phy, USB UNI PHY, and SMB2370 eUSB2 repeater
    • SC8280xp gains QMP UFS PHY
    • Kaanapali gains PCIe phy and QMP PHY,
    • Added support for QCS615 QMP USB3+DP PHY
  • LED – Ensure the Qualcomm LPG driver detects hardware write failures by checking the return value of regmap_bulk_write() during LUT programming
  • Backlight – Extend the Qualcomm WLED driver to support the specific over-voltage protection (OVP) values required for the PMI8994 and PMI8950 variants
  • Clock
    • Qualcomm Kaanapali global, tcsr, rpmh, display, gpu, camera, and video clk controllers
    • Qualcomm SM8750 camera clk controllers
    • Qualcomm MSM8940 and SDM439 global clk controllers
    • Convert clock dividers from round_rate() to determine_rate()
    • Fix the SDCC RCGs to use shared_floor_ops across a variety of platforms
  • remoteproc – Refactor the Qualcomm secure-world helpers and add support in the Qualcomm PAS remoteproc driver for reading a resource-table from the secure world. Use this to configure the IOMMU on newer targets where Linux runs in EL2
  • PCIe controller driver
    • Merge SC8180x DT binding into SM8150
    • Move SDX55, SDM845, QCS404, IPQ5018, IPQ6018, IPQ8074 Gen3, IPQ8074, IPQ4019, IPQ9574, APQ8064, MSM8996, APQ8084 to dedicated
      schema
    • Add DT binding and driver support for SA8255p Endpoint being configured by firmware
    • Parse PERST# from all PCIe bridge nodes for future platforms that will have PERST# in Switch Downstream Ports as well as in Root Ports
  • WiFi drivers:
    • ath11k – support for Channel Frequency Response measurement
    • ath12k
      • Significant driver refactor to support multi-wiphy devices and and pave the way for future device support in the
        same driver (rather than splitting to ath13k)
      • Support for the QCC2072 chipset
  • Arm64 device tree updates
    • QCS6490 – The TC9563 PCIe switch controller is described on RB3 Gen2
    • SA8775P/QCS9075
      • The GPU and crypto blocks are added.
      • IO-regions and clocks are added to interconnect nodes to allow QoS configuration.
      • GPU, TPM and USB support are enabled on the evaluation
        kit (EVK).
    • QCS8300
      • The two PCIe controllers, the camera subsystem, tsens, display subsystem, crypto, CPUfreq, and coresight are added.
      • On the evaluation kit (EVK) the PCIe busses are enabled, together with an AMC6821-based fan controller and the ST33 TPM chip.
    • MSM8939 – The camera subsystem is described. The Asus ZenFone 2 Laser/Selfie gains battery and hall sensor support.
    • Agatti-based RB1 board – PM8008 is described and an overlay for the Vision mezzanine is introduced.
    • SDM630 – The compute DSP remoteproc, FastRPC and related entites are described. The LPASS LPI pinctrl node is described.
    • SDM845
      • The bootloader framebuffer and its resources are described on the OnePlus device
      • Devices from OnePlus, SHIFT, and Xiaomi ath10k calibration variants are specified.
      • The sensor remoteproc is enabled on Xiaomi Pocophone F1.
    • SM7225 –  Fairphone FP4 regulators for the cameras are described, and the camera EEPROM is added.
    • SM8650  – The camera subsystem is described. On the QRD the Samsung S5KJN1 camera sensor is added, and for the HDK an overlay for the “Rear
      Camera Card” is added.
    • SM8750 – CPUfreq, SDCHCI and Iris (video encode/decode) support are added, and missing – required – properties for the BAM DMA is added.
      These are then enabled on the MTP.
    • SM6150/QCS615 – PMU, DisplayPort, and USB/DP combo PHY are added. DisplayPort is enabled on the Talos Ride board.
    • Snapdragon X Elite (Hamoa)
      • Gains crypto engine, missing TCSR reference clocks, and random number generator block.
      • The soc bus address width is corrected to match the hardware.
      • Lenovo Thinkpad T14s HDMI and audio playback over DisplayPort is introduced.
      • HDMI, Iris (video encode/decode) and PS8830 retimers are described for the ASUS Vivobook S 15.
      • The Hamoa evaluation kit (EVK) gains PCIe busses, WiFi, backlight, TPM and RG (red/green) LEDs
    • Enable QSEECOM, and thereby UEFI variable access, on the Medion SPRCHRGD 14 S1.
    • Enable ADSP FastRPC and add missing GPU memory regions on Agatti. Also add the missing GPU regions on SM6115.
    • Describe the application subsystem watchdog on Hamoa and enable this in the EL2 configurations.
    • Add the camera control interface (CCI) I2C controller on MSM8953, and describe the camera regulators and the camera EEPROM on Fairphone FP3.
    • Specify clock frequency for the i2c4 bus on OnePlus 6, to silence the warnings about missing frequency definition.
    • Add FastRPC and associated heap memory, as well as Coresight, on SM8750
    • Switch a variety of platforms to use the generic RPMPD_ constants, instead of target-specific duplicates, to allow us to drop these from the header files.
    • Drop the invalid opp-shared on the QUP OPP table for Talos.
  • Arm32 device tree updates
    • Migrate the MSM8974 remoteproc power supplies to RPM provided power-domains, to match what is done on most other platforms.
    • Give the LG Nexus 5 its more human-friendly model name.
    • MSM8226 is switched to generic RPMPD_ indices, to allow dropping the duplicate platform-specific constants.
    • MSM8960 – Two additional GSBIs and I2C controllers are introduced. Accelerometer, Magnetometer, NFC, and Light/Proximity sensors are then enabled on the Samsung Galaxy Express.
  • Arm64 defconfig updates for Linux 7.0
    • Enable drivers needed to boot the Kaanapali and Milos platforms.
    • Enable EC-drivers found on various Qualcomm-based laptops.
  • New Devices
    • QCS6490-based Rubik Pi 3 board
    • Arduino UNO Q (QRB2210),
    • X Elite-based Medion SPRCHRGD 14 S1 and Surface Pro 11 laptops
    • SDM845-based Pixel 3 and Pixel 3 XL smartphones
    • Initial support for Fairphone Gen 6
• MediaTek
  • DMA Engine – Mediatek support for Dimensity 6300 and 9200 controller
  • PHY – Nediatek MT8188 HDMI PHY
  • SoC Driver
    • Mediatek MT8196 DVFS power management and mailbox support
    • A socinfo entry for the MT8371 Genio 520 SoC
    • Support for the Dynamic Voltage and Frequency Scaling
    • Resource Controller (DVFSRC) version 4, found in the new MediaTek Kompanio Ultra (MT8196) SoC
    • Initial support for the CMDQ mailbox found in the MT8196.
    • A memory leak fix in the MediaTek SVS driver’s debug ops.
  • Thermal control
    • Support multiple temp to raw conversion functions for the Mediatek LVTS thermal driver and add the MT8196 and MT6991 support
    • Add support for the Mediatek LVTS driver for MT7987
  • Memory Controller – Mediatek SMI: Fix old struct device reference leaks during error paths and device unbinding.
  • DRM
    • mtk_hdmi_v2: Remove unneeded semicolon
    • Move DP training to hotplug thread
    • Convert legacy DRM logging to drm_* helpers in mtk_crtc.c
    • mtk_dsi: Add support for High Speed (HS) mode
    • Add HDMI support for Mediatek Genio 510/700/1200-EVK and Radxa NIO-12L boards
  • Mailbox
    • Introduce mtk-vcp-mailbox driver and bindings for MT8196 VCP
      Expand mtk-cmdq for MT8196 with GCE virtualization, mminfra_offset, and instruction generation data
  • Bluetooth – add support for MediaTek MT7920
  • ARM32 updates – N/A
  • ARM64 device tree updates for Linux 7.0
    • MT7981b gains support for PCI-Express, USB, Ethernet and for the “GED” WiFi HW offload
    • OpenWRT One board gains support for the same
    • MT8188/8195/8390/8395 gains support for the DPI1 interface and HDMI output from the SoC’s HDMI Tx controller, along with its HDMI PHY and DDC IPs, usable on a selection of boards that expose an HDMI connector, namely:
      • All MT8390 Genio EVK-based boards
      • All MT8395 Genio EVK-based boards
      • Radxa NIO-12L (MT8395)
    • dtbs_check warning fixes for many of the MTK devicetrees, including MT6795, MT7981, MT7986, MT7988, MT8173, MT8183, MT8186, MT8188, MT8192, and a dts coding style fix for Airoha EN7581-EVB.
    • Fix for the new devicetree overlay warnings, adding dtbs with applied overlays for all of the devices having at least one overlay.
  • Defconfig updates – Enabling the MediaTek HDMIv2 driver to compile as a module.
  • New devices
    • Ezurio Tungsten 510 (MediaTek Genio 510 SoC)
    • Ezurio Tungsten 700 (MediaTek Genio 700 SoC)
• Other new Arm hardware platforms and SoCs
  • ASpeed – Facebook/Meta Anacapa BMC (AST2600),  ASRock Rack ALTRAD8 BMC (AST2500), and
  • Intel – Carrier board for Intel Agilex 5 SoM (Agilex5 Modular board)
  • Marvel – Carrier board for Armada 7020 (Marvell DB-98CX85x0)
  • Microchip – PCB8385 reference board for 32-bit Microchip LAN9668
  • NXP
    • NXP i.MX8QP and i.MX952, feature-reduced versions of i.MX8QM and i.MX952, with fewer CPU cores and I/O interfaces.
    • Several boards based on NXP LS1028a, i. MX 8M Nano, i.MX 8M Plus, i.MX 91, i.MX 93, and i.MX 95.
    • Carrier board based on NXP i.MX 8Q Plus
  • Realtek – RTD1501s, RTD1861b, and RTD1920s Kent family SoC based on Arm Cortex-A78 cores.
  • Removed SoCs due to no related board – Samsung s3c6400, ST spear320s, ST stm32mp21xc/stm32mp23xc/stm32mp25xc, Renesas r8a779m0/r8a779m2/r8a779m4/r8a779m6/r8a779m7/r8a779m8/r8a779mb/r9a07g044c1/r9a07g044l1/r9a07g054l1/r9a09g047e37, and TI am3703/am3715.
  • Removed Broadcom/Cavium/Marvell ThunderX2 and its only machine
• Raspberry Pi-specific changes
  • Broadcom BCM2712 – Enable RNG, add watchdog
  • Regulator – Mark the Raspberry Pi 7″ Display 1 ATTINY-based regulator as GPIO controller, because the hardware behaves that way in addition to being a regulator. Add fixed gpio-cells as well.
  • Media – i2c: ov5647
    • Add V4L2_CID_LINK_FREQUENCY and V4L2_CID_HBLANK control
    • Tidy up PIXEL_RATE control and mode registers
    • Use the same PLL config for full, 1080p, and binned modes
    • Separate out the common registers.

RISC-V updates in Linux 7.0

There were a good number of changes and updates related to the RISC-V architecture, too:

• Add support for control flow integrity for userspace processes. The kernel gains support for the RISC-V Zicfiss and Zicfilp extensions, used to provide hardware-assisted control-flow-integrity tracking in user space.
• Improve ptrace behavior regarding vector registers, and add some selftests
• Optimize strlen() assembly
• Enable the ISO-8859-1 code page as built-in, similar to ARM64, for EFI volume mounting
• Clean up some code slightly, including defining copy_user_page() as copy_page() rather than memcpy(), aligning us with other architectures; and using max3() to slightly simplify an expression in riscv_iommu_init_check()
• Alibaba T-Head – Support for CPU frequency scaling on the T-HEAD TH1520 by allowing the PLL rate used for the CPU cluster to be reconfigured.
• Allwinner – D1 gains LED controller and thermal sensor support
• Microchip
  • Pinctrl – Microchip Polarfire MSSIO (RISC-V) pin control support
  • GPIO – The GPIO controller on PolarFire SoC supports more than one type of interrupt and needs two interrupt cells.
  • CAN Bus – Add CAN resets to MPFS
  • Clock – Adjust the PolarFire driver Kconfig section as the driver is now used by non-PolarFire devices
• SiFive – IRQ – – Fix frozen interrupt bug in the sifive-plic driver
• Sophgo
  • PCIe controller driver – Disable ASPM L0s and L1 on Sophgo 2044 PCIe Root Ports
  • Device tree
    • CV18xx – Update RX/TX FIFO size to fix the USB transfer issue.
    • SG2042
      • Optimize the DTS file format, including moving PLIC/CLINT nodes into cpu dtsi and sorting peripheral nodes by address.
      • Enable RTC for Pioneerbox.
    • SG2044 – Add “b” ISA extension to fix dtbs_check warnings.
• SpacemiT
  • Added K3 8-core (16-core) RISC-V chip supporting RVA23 profile
  • Pinctrl – Spacemit K3 (RISC-V) pin control support
  • Clock – K3 clock drivers
    • APBC – UART, GPIO, PWM, SPI, TIMER, I2S, IR, DR, TSEN, IPC, CAN
    • APBS – Various PPL clocks control
    • APMU – CCI, CPU, CSI, ISP, LCD, USB, QSPI, DMA, VPU, GPU, DSI, PCIe, EMAC…
    • DCIU – SRAM, DMA, TCM
    • MPMU – Various PLL1-derived clocks, UART, WATCHDOG, I2S
• StarFive
  • Cache – fix device node leak in starlink_cache_init()
  • Watchdog – Fix PM reference leak in probe error path

MIPS changelog

As is often the case, the changes for the MIPS architecture can simply be summarized as “cleanups and fixes”. Here are some of the commits:

• Revert “clk: microchip: core: allow driver to be compiled with COMPILE_TEST”
• Revert “clk: microchip: fix typo in reference to a config option”
• MIPS: Implement ARCH_HAS_CC_CAN_LINK
• MIPS: rb532: Fix MMIO UART resource registration
• MIPS: Work around LLVM bug when gp is used as global register variable
• MIPS: Loongson64: env: Fixup serial clock-frequency when using LEFI
• MIPS: Loongson2ef: Use pcibios_align_resource() to block io range
• MIPS: Loongson2ef: Register PCI controller in early stage
• clk: microchip: fix typo in reference to a config option
• MIPS: Loongson64: dts: fix phy-related definition of LS7A GMAC
• clk: microchip: core: allow driver to be compiled with COMPILE_TEST
• MIPS: drop unused pic32.h header
• watchdog: pic32-wdt: update include to use pic32.h from platform_data
• watchdog: pic32-dmt: update include to use pic32.h from platform_data
• serial: pic32_uart: update include to use pic32.h from platform_data
• rtc: pic32: update include to use pic32.h from platform_data
• pinctrl: pic32: update include to use pic32.h from platform_data
• mmc: sdhci-pic32: update include to use pic32.h from platform_data
• irqchip/irq-pic32-evic: update include to use pic32.h from platform_data
• clk: microchip: core: update include to use pic32.h from platform_data

You can check out the full Linux 7.0 changelog for the full list of changes, generated with the command git log v6.19..v7.0-rc7 --stat to show commit messages only. You can also read Kernelnewbies’ summary for another look at the latest Linux 7.0 changes.

The post Linux 7.0 Release – Main changes, Arm, RISC-V, and MIPS architectures appeared first on CNX Software - Embedded Systems News.

The Homture Magic Frame is the world’s first smart photo display that integrates generative AI video and a 60 GHz mmWave radar.

Artificial intelligence transforms static photos into interactive, living windows of memory, while the 60 GHz radar detects a person’s presence within a 2-meter range. So when someone walks by, the frame’s AI model gives life to the character(s) in the photo to greet people or follow their movement with their gaze.

Homture Magic Frame specifications:

• Storage
  • 64GB local storage
  • Unlimited cloud storage hosted on US-based AWS servers.
• Display – 10.1-inch Full HD (1920×1200) touchscreen display
• Wireless – Dual-band WiFi (2.4GHz / 5GHz)
• Sensor – 60 GHz mmWave radar
• AI features
  • AI Photo-to-Video Magic – Generates multiple dynamic videos from a single photo
  • Old Photo Restoration – Scans vintage physical photos, repairs fading, and animates them.
  • Smart Motion Interaction – The frame can greet you or have characters look in your direction when the built-in radar detects movement.
  • Gift-Giving Experience
    • Hands-on Gifting – Givers can scan a QR code on the box to pre-load photos and a message
    • Remote Gifting – Generate a gift code for recipients to enter and display your surprise remotely.
  • Works with people, pets, animals, and scenery
  • 2000-credit benefit card for about 20 AI videos; once used up, additional credits can be purchased
• Power Supply – 5V/2A
• Dimensions: –  265 x 183 x 12.5 (23.5 max) mm; plastic + aluminum alloy enclosure
• Weight – 550 grams

The user can upload pictures and videos, manage family members, change frame settings, and view AI creations through the Homture mobile app available for Android and iOS.

The company is currently offering a steep discount for the Mother’s Day shopping season. The Homture Magic Frame sells for 29% OFF with the Amazon coupon code CRQHY74P until May 31, 2026.  You can purchase the device on Amazon or the company’s online store.

The post Homture Magic Frame smart photo display integrates generative AI and 60 GHz mmWave radar (Sponsored) appeared first on CNX Software - Embedded Systems News.

UmbrelOS is a Debian-based home cloud OS with a neat web-based interface that works on devices like Raspberry Pi SBCs, mini PCs, old computers, and more.

Having been first released in 2020, the OS is not exactly new, but I only discovered it today after noticing it was one of the supported operating systems for the Pironman 5 Pro Max enclosure for the Raspberry Pi 5. It initially launched as a tool for running a Bitcoin full node on a Raspberry Pi easily, but eventually turned into a home cloud OS that competes against other open-source solutions such as OpenMediaVault or CasaOS/ZimaOS.

UmbrelOS highlights:

• Intuitive web dashboard at umbrel.local or your device’s IP.
• Umbrel App Store — Over 300 apps, including Nextcloud or Immich for media and document storage, Jellyfin for media streaming, Home Assistant automation framework, Vaultwarden password manager, Bitcoin and Lightning nodes, AdGuard Home adblocker, and AI-related tools like Ollama and OpenClaw.
• Self-hosted — Runs apps in Docker containers
• Automatic encrypted backups to another Umbrel device or a NAS on your network, or an external USB drive.
• Rewind in Files – Restore specific files and folders from any point in the past.
• Network mounts in Files app
• External USB storage and formatting on AMD64
• GPU acceleration for apps
• Hardware compatibility – Raspberry Pi 4/5, x86 64-bit (AMD64) systems, virtual machines.

Source code, instructions, and OS images for AMD64 systems, Linux virtual machines, and Raspberry Pi 4/5 can be found on GitHub. While most people will likely install UmbrelOS on their own hardware, the company also released two hardware devices, the Umbrel Home and Umbrel Pro, which run the same software but offer priority support. Since UmbrelOS has been tested on the Umbrel hardware, features like WiFi, data migration, and external USB storage support are also guaranteed to work.

The small Umbrel Home pairs a quad-core Intel N150 CPU with 16GB of DDR5 RAM and up to a 4 TB SSD and offers Gigabit Ethernet connectivity and a few USB 3.0 ports, while the Umbrel Pro is powered by an octa-core Intel Core i3-N300 CPU coupled with 16GB LPDDR5 and up to 32TB SSD storage (4x 8TB), and features 2.5GbE networking, and two 10 Gbps USB 3.2 ports.

You can find more details about UmbrelOS and the two Umbrel devices on the project’s website.

The post UmbrelOS – A Debian-based personal home cloud OS with a slick user interface appeared first on CNX Software - Embedded Systems News.

A few days ago, we looked at the WeAct Studio STM32U585CIU6 development board, which features an ultra-low-power STM32U5 Cortex-M33 MCU and was added to MicroPython v1.28. If you’re looking for another STM32U5-based option, especially for compact UI projects, Maker Go now offers an STM32U575 board with a display connector, a microSD card slot, and many more GPIOs

While the STM32U585 on the WeAct board features cryptographic accelerators, the STM32U575VGT6 MCU on the Maker Go board is closely related and still offers the same high-performance Cortex-M33 core running at 160 MHz, along with ultra-low-power capabilities. This new board also adds 8MB of external flash and is designed to accept 1.47-inch or 2.0-inch LCDs directly via a ribbon cable.

STM32U575VGT6 board specifications:

• Microcontroller – ST STM32U575VGT6
  • Core – Arm Cortex-M33 Armv8-M core clocked at up to 160 MHz with FPU, Arm TrustZone
  • Memory – 786 KB SRAM
  • Flash – 1024 KB (1 MB) flash
  • GPU – Chrom-ART accelerator (DMA2D) for 2D graphics
  • Package – LQFP100 (14 x 14 mm)
•  Storage
  • 8MB SPI Flash (WSON8 package)
  • MicroSD card slot
• Display – FPC expansion interface compatible with 1.47-inch (320×172) and 2.00-inch (320×240) displays
• USB – USB Type-C port for power and programming (supports USB download)
• Expansion – 2x 48-pin headers exposing GPIOs, 3.3V, 5V, and GND
• Debugging/Programming:
  • Dedicated SWD download interface (3v3, RST, RX, TX, 5V, GND, DIO, CLK)
  • Supports Downloader, USB, and Serial port burning methods
• Misc
  • Reset and User/Boot (two-in-one) buttons
  • Power LED and RGB LED
  • High-speed crystal oscillator
  • RTC
• Power Supply – 5V via USB Type-C; 1A high-current DC-DC power supply with ESD protection
• Dimensions – 59.7 mm x 35.8 mm (2350.0mil x 1410.0mil)

The board uses a breadboard-friendly layout, though you will need to solder the provided header pins yourself. The manufacturer mentions that the three primary ways to flash the board are via a standard SWD downloader (like an ST-Link), directly over USB, or via the serial port.

On the software side, there aren’t any specific resources for this board, but STMicroelectronics provides the STM32Cube IDE and HAL libraries for C/C++ development. While there is no official MicroPython firmware release specifically for this board, the MicroPython v1.27 update added core support for the STM32U5 series, which means you should technically have support for the MCU. You can also check out the official STM32CubeU5 GitHub repository for more information.

The STM32U575 development board is available on AliExpress for $15.00, but there aren’t any options to purchase it bundled with a display. While Maker Go mentions “QSZNTEC” and “IO Impulse”, I couldn’t find any information about either, although we suspect the former is a brand and the latter might be the nickname of the hardware designer. Besides Maker Go, the board can also be found on other AliExpress stores at different price points.

The post $15 STM32U575 development board features FPC display connector, microSD card slot, two 48-pin GPIO headers appeared first on CNX Software - Embedded Systems News.

Based on Raspberry Pi Zero 2 W, the Bee Write Back writerdeck is another DIY project that should be relatively easy to reproduce, since it relies on off-the-shelf parts, including an OLED and mechanical key switches and caps, as well as a 3D printed enclosure.

Simon (shmimel) had trouble falling asleep and found out that journaling helped him a lot, but he was not so fond of writing in a physical journal. So instead, he created the Bee Write Back journal/writerdeck as a distraction-free writing machine, and the result looks pretty neat.

Bee Write Back key components:

• Raspberry Pi Zero 2 W SBC with Broadcom BCM2711 quad-core Cortex-A53 SoC, 512 MB RAM, WiFi 4 and Bluetooth 4.2
• Display – 5.5-inch AMOLED screen with 1280 x 720 resolution($52 on AliExpress)
• Keyboard accessories
  • 47x switches
  • 47x keycaps
  • YMDK Air40 keyboard PCB (about $30 on AliExpress)
• Power – Seengreat Pi Zero UPS USB HUB with 18650 battery holder ($25 on Amazon)
• Cables and fixtures
  • Mini HDMI to Mini HDMI cable
  • 2x USB-C to USB-A cables
  • USB-C male to female cable
  • Standaoffs and screws
• 3D printed parts –  Screen cover, keyboard plate, base, screen retainer
• BoM cost – About $200 excluding shipping and printed parts

You’ll find the complete instructions to build the hardware and assemble the kit on GitHub, along with two (vibe-coded) Python scripts:

• writerdeck – A minimal TUI writing program for a dedicated writing device.
• claude-chat.py – A pager-style terminal chat client for the Anthropic API

That type of machine would probably not work for me, as my bad eyes would not tolerate a 5.5-inch display when typing text (I’m currently using a 32-inch 4K monitor), and some people may find the relatively noisy keyboard to be a distraction. However, this type of writerdeck obviously works great for some people. You can watch a short video and check out the assembly guide in the video embedded below.

Via Liliputing

The post Bee Write Back – A Raspberry Pi Zero 2 W-based DIY writerdeck with 5.5-inch OLED and mechanical keyboard appeared first on CNX Software - Embedded Systems News.