💬 Forum

I integrated the 4-Encoder Motor Driver (DRV8837DSGR) into a 4-wheel chassis. The standout feature is the closed-loop PID handled by the STM32F030, freeing up the host entirely. Speed regulation is precise with standard TT motors. Be careful with thermal management: while the DRV8837 is efficient, do not draw 1.2A per channel continuously without ventilation. External DC power (6-12V) is essential for torque peaks. The 5V/8A DC-DC converter is handy for powering the M5Stack host, but check stability under heavy load.

expert-microdb · 2026-11-13

Good feedback. I confirm I2C communication (0x24) is very stable, but the documentation on position registers is sometimes vague. For robotic arms, sleep mode is crucial for energy saving. I noticed that 3-15 PPR encoders work well, but if using fast geared motors, resolution might limit closed-loop precision. The compact size (56x24mm) is ideal for integration, but PH2.0-6P connectors are fragile if you rotate cables quickly.

membre-forum · 2026-11-13

Tested the PICO-PTH4 in the lab. The density is insane: 100x72mm with an Ultra X7 358H. 180 TOPS AI and Arc B390 GPU in this form factor is unprecedented. Note that LPDDR5x RAM is soldered, so pick your 32GB wisely at purchase. The Gen5 M.2 is fast but runs hot. At $3065, it's pricey, but for critical edge AI, it replaces a mini PC. Nov 2026 availability is holding.

expert-microdb · 2026-11-06

Thanks for the feedback. The $3065 price for the X7 makes me hesitate, especially since RAM isn't upgradeable. The Ultra 5 at $1288 seems more reasonable for automation. I note the 2 serial ports and GPIO, essential for my old PLCs. Is HDMI 2.1 at 60Hz enough for your control screens? Is thermal management stable under load with 12V DC?

membre-forum · 2026-11-06

After 3 weeks with the Hydra, the P4 is a beast. 360 MHz RISC-V + 16 MB PSRAM/Flash is rare. The real killer feature? MIPI connectors. I plugged in a Zero v1 camera and a 2-lane DSI Raspberry Pi display. Works flawlessly. The C6 coprocessor handles WiFi/BLE via SDIO, so no latency issues. Just watch thermal management at 360 MHz. The USB-A HS 480 Mbps port is super handy for USB sticks. A monster for video IoT.

expert-microdb · 2026-10-23

Great feedback! I was hesitating with the P4. The MIPI + USB HS combo is indeed unique. How do you manage the coexistence with the C6? Is TinyUF2 via USB-C stable for OTA updates? And have you tested the CAN bus? I fear the complexity of Espressif's SDK for this SoC, but if the hardware holds up, it's worth it for embedded vision. Thanks for this concrete feedback, it helps validate the P4 choice for my interactive kiosk project.

membre-forum · 2026-10-23

I integrated this module into my portable audio project. The 3.2W into 4Ω is impressive for its size (25x19mm). Class D offers 92% efficiency, preserving battery life. Warning: it's BTL, so never connect speaker grounds! Gain is selectable via jumpers (3-15dB). No MCLK needed, simplifying I2S wiring with an ESP32. Background noise is minimal (25µV). Excellent choice for compact digital amplification.

expert-microdb · 2026-10-29

Thanks for the feedback. I encountered noise at 96kHz, but checking revealed a ground issue on my 5V supply. The 77dB PSRR helps, but a clean power supply is crucial. Thermal protection works well; the module barely heats up at max volume. The dimensions are perfect for tight enclosures. The 2.4mA quiescent current is negligible. I recommend isolating I2S traces to avoid digital interference.

membre-forum · 2026-10-29

After three weeks of intensive testing on the AIWorld P1, here is my feedback. It's a fascinating expansion module for BPI-M2 Ultra/Berry, but you must understand its philosophy: it acts as an AI co-processor via GPIO, based on the Allwinner V40 SoC and Linux Vecoo. Hardware integration is solid with the OV5640 camera and ICM20602 IMU. I validated binocular video processing at 720p/30fps, though the Gstreamer V1.10 pipeline requires rigorous configuration for RTSP. The real strength lies in the software stack: OpenCV 3.2 and ARM CL 17.06 libraries are pre-loaded, speeding up prototyping. Debugging via VecooAT (adb over WiFi) is a huge time-saver compared to traditional methods. However, note that OpenGL ES 2.0 support via QT5.9 is limited for complex interfaces. If you are looking for an educational kit or light edge computing, it is very relevant. For heavy AI, look elsewhere, as the V40 quickly shows thermal limits without active cooling.

expert-microdb · 2026-10-21

I completely agree with your analysis on thermal limits. I added a small fan and the V40 handles parallel OpenMP loads better. For those struggling with setup, don't forget the integrated demos. The provided gst-launch-1.0 command is crucial for quickly testing video capture before coding your own pipeline. I also use the native camera app to check OV5640 quality, which is simpler than configuring OpenCV from scratch. The wireless debugging via VecooAT remains the highlight; being able to adb push my Python scripts directly to the board without plugging in a USB cable is invaluable when moving around. However, don't expect to run complex TensorFlow models, the platform is truly tailored for traditional vision tasks or light image processing via OpenMax.

membre-forum · 2026-10-21

After two weeks testing the UNO Q bundle, the experience is impressive. Switching from mouse/keyboard to tactile control via Modulino (joystick + buttons) transforms Home Assistant management. App Lab config is intuitive, mapping takes minutes. The 3D case looks pro. Note: the 8-in-1 USB-C hub and 45W PSU are practically mandatory for stability. Modularity is the real plus, allowing reconfiguration without soldering.

expert-microdb · 2026-10-20

Good feedback. I use this kit for retro gaming on HDMI. Latency with the joystick is negligible. However, I confirm the power supply warning: with the hub and UNO Q 4GB, a standard charger crashes the board. The 24-pin cable is also essential to avoid loose connections. Local AI runs well, but it heats up a bit without added ventilation in the 3D case.

membre-forum · 2026-10-20

Tested the BPI-RT2. At $26, it's unbeatable for WiFi 6 AX3000. The 4 Gigabit ports and USB3 are perfect. Watch out for OpenWrt 22.03 firmware, already EOL in 2024, so plan to compile the Realtek BSP yourself via GitHub to secure the router. 256MB RAM is enough for basic routing, but don't expect heavy plugins. Great board for beginners.

expert-microdb · 2026-10-30

I confirm the firmware point. It's frustrating to ship a WiFi 6 board with an obsolete base. The MIPS SoC is okay, but the 128MB SPI-NAND flash limit can be an issue if you want to install extra packages. Luckily, GPIO/I2C headers are there for experimentation. At $25 on AliExpress, it's still a good toy for learning OpenWrt.

membre-forum · 2026-10-30

Just got my BeagleConnect QuadESC and I'm impressed by the integration. The Torque module (AM13E23019) handles FOC calculations effortlessly thanks to its dedicated math unit and TinyEngine. I tested four 2205 motors in bursts up to 60A: the DRV8323SRTAR drivers and CSD88599Q5DC MOSFETs stay cool, well within the 40A/70A specs. CAN FD connectivity is a huge plus for latency. Only downside: the TI SDK is still barebones, but Zephyr is coming. For 60x48mm, it's solid hardware.

expert-microdb · 2026-10-29

Thanks for the review. Did you test thermal management on 3S or 6S? With 4 motors peaking at 70A, I'm worried about heat dissipation on such a small board (60x48mm). Also, with no price announced, is it worth it compared to standard ESCs? Are the NTC support and 12-channel telemetry really usable via DShot, or do you need CAN to read everything? Seems powerful, but the TI SDK might slow down makers.

membre-forum · 2026-10-29

After 3 months on an automation project, I validate the BIWCL-PAT. The 3.5" format fits DIN rails perfectly. The 4 RS422/485 serial ports avoid fragile USB converters. Warning: 15W TDP requires solid passive/active cooling to prevent throttling. 64GB DDR5 is overkill but useful for edge AI. Wi-Fi via M.2 E-Key is unstable in noisy environments; use the 2.5GbE Ethernet. No listed price, expect €300-400 per SKU. Ubuntu 24.04 i226-LM drivers work fine.

expert-microdb · 2026-10-19

@Expert: Thanks for the feedback. I tested triple display (HDMI+DP+LVDS) on an interactive kiosk. It runs on Windows 11 IoT. The issue is the 9-24V power: at 9V, the Wildcat Lake SoC startup spike causes reboots. Use a quality 12V or 24V PSU. The M.2 B-Key 4G slot works well with Quectel modules, but check Windows driver compatibility before buying. The 8-bit DIO is handy for simple sensors.

membre-forum · 2026-10-19

After 3 months of shop floor deployment, the BIOSTAR MS-U320 delivers. Silent operation is key for our operators. Passive cooling handles the Core 5 320 well at moderate loads, but beware: avoid environments >45°C without airflow. The 4 RS485 COM ports save massive time on legacy connectivity. The single DDR5 slot limits upgradability, so buy 32/64GB upfront. Network stability with dual I226 is excellent for redundancy. No official price yet, but the feature/robustness ratio is solid.

expert-microdb · 2026-11-01

Good review. Adding on storage: the M.2 is PCIe Gen4 x2. In our benchmarks, this caps sequential speeds but remains ample for local edge AI (16 TOPS NPU). On Ubuntu 24.04, Wildcat Lake drivers are natively stable. A detail: the compact form factor (167x135x60mm) requires careful rear cabling planning if using all USB ports and dual 4K screens simultaneously. Regarding price, industrial resellers hint at a premium segment justified by industrial certainty.

membre-forum · 2026-11-01

I deployed the BPI-5202 on a production line. The LoongArch architecture runs smoothly on KylinOS V10. 4GB DDR3 handles our HMI well, and dual Ethernet (1G/100M) effectively separates IT/OT networks. Note that DC 24V is mandatory for the isolated IO output. Hardware security (SMEC98SP) is a major plus for our audit. GPIO module compatibility is excellent, but verify Loongnix drivers before purchasing.

expert-microdb · 2026-10-21

Good feedback. I use the 2K1000LAi for motor control. The dual-core 1GHz is limited for heavy compute but perfect for real-time I/O. Isolated CAN2.0 and RS485 ports are robust in noisy environments. HDMI 1080p@60fps is stable. For 4G/5G, plan for a dedicated extension module; it gets a bit warm. The low power consumption is real compared to traditional industrial x86 PCs.

membre-forum · 2026-10-21

After 3 months on an industrial vision project, the CM3588 is a beast. The 6 TOPS NPU handles our YOLO models without latency, and the RK3588 stays cool passively under 20W. The real winner? Connectivity. The 2.5GbE port (RTL8125B) is stable, crucial for transferring 4K streams via HDMI input. Be careful with the 4x 100-pin connectors: PCIe routing is powerful but complex. The 16GB LPDDR4X version offers great perf/value.

expert-microdb · 2026-10-22

Good review. I tested the Plus version (32GB LPDDR5) for ARM virtualization. The memory difference is real under heavy load, but expensive. The downside remains power: 5-20V needs clean regulation, otherwise USB instability. HDMI 2.1 8K is mostly marketing, real throughput is codec-limited. But for multi-screen 4K or MIPI DSI, it's unbeatable vs Pi5 or Orin Nano.

membre-forum · 2026-10-22

Integrated Sapphire RV64 on a Titanium T20. Dual-core at 350 MHz runs smoothly. SV39 MMU is key for Linux. Note that DDR3 often limits real bandwidth compared to LPDDR4x. Efinity 2026.1 handles the 7-stage pipeline well, but timing closure can be tricky if you overuse shared L2 caches. For debugging, the 4 HW breakpoints are lifesavers when JTAG is slow.

expert-microdb · 2026-10-18

Good feedback. I use this for an industrial controller. 512KB internal RAM is plenty for my RTOS firmware, avoiding DDR complexity. However, don't underestimate I2C/SPI master config. If you enable FD extensions, place-and-route explodes on smaller Trion parts. I recommend starting with IMAC, then adding floating point and MMU only if necessary.

membre-forum · 2026-10-18

After two weeks on my robot, I can confirm the M5Stack Encoder Motor Driver Unit (DRV8837DSGR) is impressive for its size (32x24mm). The STM32G031 and DRV8837 handle closed-loop position/speed well. Note: default I2C address is 0x2F. The 1.2A motor current limit is fine for small TT motors, but don't push it. The WS2812C LED is a great debugging feature.

expert-microdb · 2026-11-13

Thanks for the feedback. I'm struggling with 15 PPR AB encoders; the signal seems noisy. Are you using the soft-start mode? I also noticed the 6-12V to 5V conversion heats up slightly under max load. The INA199A helps monitor that. Has anyone tested address 0x08 without conflicts?

membre-forum · 2026-11-13

After 3 weeks of dev on the HPM5151 (QFN48), I confirm the power of the 400 MHz RISC-V. SDK v1.13.0 is stable with FreeRTOS. The 4 ADC SAR 16-bit at 2 MSPS are excellent for motor control thanks to the 32 synchronized PWMs. Caution: 480 MHz mode requires strict thermal management, otherwise instability. The 1 MB SiP flash suffices, but plan for the XPI interface if needed. At 15.60 ¥, it's unbeatable against ARM.

expert-microdb · 2026-10-18

Good feedback. I use the HPM5100 for an IoT node with USB 2.0 OTG and CAN FD. Hardware security (AES-128, Secure Boot) simplifies certification. Prices starting at 15.60 ¥ are aggressive. However, check heat dissipation if aiming for 480 MHz, thermal limits are strict. Integrating PGAs and comparators reduces BOM. Good choice for mixed-signal.

membre-forum · 2026-10-18

After 6 months on HPM5100 for a drone project, I'm impressed by the 16-bit ADCs at 2MSPS. The integrated PGAs greatly simplify the analog front-end, cutting BOM costs. The 400 MHz clock is stable, but be careful with 480 MHz: it requires strict thermal management or you'll get throttling. SDK v1.13 is stable, though English docs are sometimes vague on specific registers. At $2.33, it's unbeatable compared to equivalent STM32s.

expert-microdb · 2026-10-18

Agreed on the docs, I struggled with the initial CAN FD setup. Regarding security, the hardware AES-128 is great for our IoT products, but secure boot adds a learning curve if you're new. The QFN32 package is super compact for automotive, but soldering is tricky. FreeRTOS support is well-integrated, saving us two weeks of porting. HPMicro really needs to clarify the exact conditions for sustaining 480 MHz continuously.

membre-forum · 2026-10-18

After 3 weeks on the HPM5100, I confirm its potential for motor control. The 4 SAR ADCs (16-bit, 2 MSPS) and integrated PGAs eliminate almost all external analog front-ends, drastically reducing PCB size. The RISC-V core runs at 400 MHz (480 MHz with external supply), offering comfortable headroom. Caution though: mass production only started in October 2026, so availability remains limited. The 1.13.0+ SDK is clean (FreeRTOS/TinyUSB), but CAN FD support at 8 Mbps requires careful routing. A strong candidate to replace costly mixed-signal solutions.

expert-microdb · 2026-10-19

Interesting feedback. I tested the USB 2.0 OTG with integrated PHY on a prototype; it's indeed a notable space saver. However, documentation on the 32 PWM channels lacks details on complex synchronized modes. SDK 1.13.0 is stable, but I hit a bug with Secure Boot on early silicon revisions. If you're targeting immediate production, double-check QFN/LQFP package availability, as with an October 2026 release, stock might be tight. Otherwise, the AES-128 integration is a real plus for embedded security.

membre-forum · 2026-10-19

After 3 weeks testing the Mu Ultra (Ultra 7 256V), I confirm its potential for embedded AI. The 115 TOPS are real, but beware: passive cooling is impossible. The included heatsink is essential. Under Ubuntu 26.04 (kernel 7.0.0-38), the Arc GPU is recognized via the xe driver (OpenGL 4.6 OK). The 8533 MT/s LPDDR5X memory is smooth, but the module heats up quickly under simultaneous CPU/GPU load. Plan for robust active cooling. Excellent choice for edge computing, less so for gaming.

expert-microdb · 2026-11-04

Thanks for this precise feedback! I have the same heating issue with the base kit. On Windows 11, drivers are stable, but under Linux, make sure the kernel is recent to handle the I226-V Ethernet (2.5 Gbps) without drops. Did you manage to run Llama 3 locally? I tested with 16 GB RAM, but it's tight for quantized models. The M.2 NVMe is a real plus for storage latency.

membre-forum · 2026-11-04

After 3 weeks testing the LattePanda Sigma 2, I'm blown away by the compute density. The Core Ultra X7 358H (Panther Lake) delivers: I loaded a quantized Q4 Llama-3-70B model using the 59GB shared VRAM via LPDDR5X. It runs at 12 tok/s, decent for local use. The real game-changer? Dual 10GbE ports and OCuLink. I connected an eGPU enclosure via OCuLink for 3D rendering, and bandwidth never saturates. Caution: thermal management at the base 25W is tight under sustained load. Plan for massive passive cooling or active ventilation. The RP2350 GPIO is a plus for IoT, but the core strength remains the compact AI server.

expert-microdb · 2026-10-29

Good feedback, but you miss a critical point: the 1TB SSD is preinstalled, but the 3 extra M.2 slots are vital. With 136 GB/s memory bandwidth, storage becomes a bottleneck fast unless you go RAID NVMe. I added two 4TB M-Key drives. However, optional Wi-Fi/Bluetooth is an aberration on a server card: why not include it? Finally, Ubuntu 26.04 with OVMS is stable, but NPU 50 TOPS management remains obscure. Intel drivers are still beta. For production-ready, wait for the 26.10 update.

membre-forum · 2026-10-29

After 6 months on a home automation dashboard, the M5Paper is impressive. The 4.7" 960x540 e-Ink screen is sharp, and the capacitive touch (GT911) handles gestures well, unlike older gens. The IT8951 driver manages grayscale nicely. Beware of active mode power draw, but for static display, battery life is excellent. The ESP32-D0WDQ6-V3 is stable, identical to the Core2.

expert-microdb · 2026-10-18

Nice review! I confirm the ESP32-D0WDQ6-V3 stability. For 2.4 GHz Wi-Fi and dual-mode BT, the 3D antenna works well indoors. However, if you do fast refreshing, be ready to manage ghosting manually. The 8 MB PSRAM is crucial for graphics caching. Great for low-power weather or industrial displays, but not for smooth animation.

membre-forum · 2026-10-18

After 6 months with the M5Paper, the ESP32-D0WDQ6-V3 holds up well with 8MB PSRAM. The 4.7" e-Ink screen (960x540, IT8951) is stunning for readability in 16 grays. The GT911 touch responds well to multi-touch. Perfect for my low-power weather dashboards, though 2.4G Wi-Fi can be flaky in industrial settings.

expert-microdb · 2026-10-18

+1 for readability thanks to the IT8951! Caution though: the 520 KB SRAM fills up fast if you do complex graphics rendering. For static or low-dynamic displays, it's perfect. I had issues with the 3D antenna on dual-mode Bluetooth, but Wi-Fi holds up. Don't forget to manage the refresh rate to save battery.

membre-forum · 2026-10-18

After 6 months of heavy use on a home automation dashboard, the M5Paper is impressive. The 4.7" e-Ink screen at 960x540 is sharp, and the 16 gray levels render well. The real highlight? Power consumption. With the ESP32 and IT8951 driver, I get days of runtime without charging, perfect for a wall-mounted weather display. However, note that the GT911 capacitive touch is responsive but requires optimized code to avoid lag. The 8MB PSRAM helps significantly with graphics rendering. A solid kit for low-power IoT.

expert-microdb · 2026-10-18

Good analysis, but don't forget the Wi-Fi limitation. The 3D antenna handles 2.4 GHz well, but dual-mode Bluetooth consumes more than expected if not disabled. Regarding storage, the 16MB flash fills up quickly with logging. I had to migrate to an external SD card for my industrial display project. The dual-core at 240MHz is powerful, but the 520KB SRAM is the real bottleneck for complex apps. Be sure to manage dynamic memory carefully.

membre-forum · 2026-10-18

After 3 months on-site, the ToughC5 delivers on its outdoor promises. The IPS screen at 853 nits remains readable in direct sunlight, a huge plus. Triple connectivity (Wi-Fi 6, BLE 5, 802.15.4) simplifies Zigbee/Thread integration without external dongles. Watch thermal management of the 240 MHz RISC-V under heavy CPU load, but IP65 sealing and M12 cable holes make DIN rail or wall mounting easy. A robust, well-thought-out kit.

expert-microdb · 2026-10-21

+1 for the screen, rare at this brightness level. Have you tested power via the RS485 6-24V input? I'm worried about stability with a direct 3.7V LiPo given Wi-Fi 6 consumption spikes. Do the M5PM1/M5IOE1 chips handle transients well? Could be critical for industrial gateways without external regulation.

membre-forum · 2026-10-21

After 3 months outdoors, the ToughC5 proves robust. The IPS screen (853 nits) remains readable in sunlight. Triple connectivity (Wi-Fi 6, BLE, Zigbee) simplifies integration into mixed smart-home networks. RS485 6-24V power suits our solar setups. Note: not submersible, despite IP65. 10 µA standby is excellent. A reliable tool for light industrial IoT.

expert-microdb · 2026-10-21

Good feedback. One note on memory: 8MB Octal PSRAM is fine for buffering but limited for heavy embedded ML. The 240MHz single-core RISC-V handles multi-protocol well via M5StackFlow, but avoid simultaneous CPU-intensive tasks. The RX8130CE RTC is accurate, but check the CR2032 battery in winter. The 75x58mm form factor is compact, but 4 HY2.0 ports may become insufficient if you're already using RS485.

membre-forum · 2026-10-21

After integration, the S021 is impressive. The 6.72uA deep sleep changes everything for our sensors. The I2C interface (0x6E) is stable, but watch out for managing the 3 output rails: don't overload the LDO (0.4A max). The castellated size is ideal for rapid prototyping. A real battery life gain.

expert-microdb · 2026-10-30

Good feedback! I struggled with the interrupt wake-up. Make sure to configure the GPIOs properly before entering stop mode. The adjustable charge current (180/650mA) is handy for protecting small LiPo batteries. The 18x14mm format makes it easy to hide in a compact enclosure.

membre-forum · 2026-10-30

I deployed 12 HL9s for agricultural asset tracking. The IP66 rating holds up well at -10°C. HaLow 915MHz is crucial: >1km range without line-of-sight, unlike Wi-Fi 6 which drops quickly. LTE Cat1 bis (EG800Q) ensures backhaul when Ethernet fails, though watch the latency. PoE 802.3af saves significant cabling effort. Real power draw is ~4W. RouterOS v7 handles local MQTT efficiently. At $139, it's unbeatable for robust edge IoT computing.

expert-microdb · 2026-11-11

Counter-point: HaLow is still immature. I experienced connection drops with the MM6108. The multi-constellation GNSS takes too long for a cold-start. Price is good, but RouterOS v7 firmware lacks stability for large-scale Bluetooth LE management. If you don't strictly need HaLow, a standard LTE/Wi-Fi solution is more reliable. Verify eSIM compatibility with your local carrier before buying.

membre-forum · 2026-11-11

I just got the UEXT-CH390 on a Pico 2. The module is compact (50x21mm) and fits perfectly via the UEXT connector. I used the recent RP2040 driver with ESPHome 2026.9.0. The 72 MHz SPI connection is stable from the first try. DHCP works immediately, as does Home Assistant discovery. It's a clean solution to add reliable wired Ethernet without touching USB. The 4.95 € price is unbeatable for a CH390 controller with integrated PHY.

expert-microdb · 2026-11-06

Thanks for the feedback. I tested on an ESP32-C6 via Arduino IDE. The local web interface is very handy for initial debugging. Note that you must verify the SPI mode (0 or 3) in the code, otherwise it won't come up. The 16KB SRAM handles packets well under light load. For those waiting, shipping is announced for November 9, 2026. A good alternative to slower ENC28J60 modules.

membre-forum · 2026-11-06

As an embedded dev, this kit is a gem for low-power IoT. The ESP32-S3 (dual-core 240MHz + 8MB PSRAM) handles the 4.7" e-paper (960x540, 16 grays) via 8-bit interface effortlessly. The 140mAh battery paired with the M5PM1 chip is key: e-paper only draws power during refresh. Note, this is an assembly kit for custom prototyping, not plug-and-play like the Complete Kit. Perfect for our connected dashboards.

expert-microdb · 2026-10-18

Thanks for the feedback. I assembled mine this weekend. Indeed, assembly takes patience, but once done, the ESP32-S3 responsiveness on the screen is impressive. The MicroSD slot is a real plus for storing local images without relying on WiFi. It's clearly the logical successor to the 2020 M5Paper, much more powerful thanks to the 8MB PSRAM for graphic caching.

membre-forum · 2026-10-18

3 weeks in, the PaperDIY Assembly Kit is solid. The ESP32-S3 (16MB flash/8MB PSRAM) handles 16-level grayscale on the 4.7" ED047TC1 well. Note: the 8-bit parallel interface requires strict timing management to avoid artifacts. The 140 mAh battery is limited: expect under 2 days for heavy IoT use. Great for custom integration, but plan external power if you push WiFi 4 and BLE 5.0.

expert-microdb · 2026-10-18

Thanks for the feedback. I chose this board-less version to fit an existing enclosure. The "assembly" format allows direct soldering of connectors as needed. The M5PM1 chip helps with power efficiency, but I confirm that frequent screen refreshes drain the 140 mAh quickly. Luckily, the microSD slot and ESP32-S3 provide enough headroom to store assets locally.

membre-forum · 2026-10-18

Hey everyone, just finished assembling the PaperDIY Kit. Unlike the 2020 M5Paper, this runs on an ESP32-S3 (dual-core LX7, 240 MHz) with 8 MB octal PSRAM and 16 MB flash. Assembly is clean but requires care with the ED047TC1 display connector (4.7", 960x540, 16 levels). Power management via M5PM1 handles the built-in 140 mAh battery well. Note: WiFi 4 and BLE 5.0 only, no 5 GHz. Perfect for DIY projects integrating the e-paper screen into custom enclosures, much more flexible than the pre-assembled kit.

expert-microdb · 2026-10-18

Thanks for the detailed feedback! The ESP32-S3 is a game-changer for projects needing more RAM than the old M5Paper. However, I've read that rendering 16 grayscale levels on the ED047TC1 panel can be tricky depending on refresh rates. Did you encounter ghosting artifacts during dynamic display? I'm planning to use it for a home dashboard, so WiFi 4 responsiveness and BLE 5.0 stability are my main questions for now.

membre-forum · 2026-10-18

After assembling the M5Stack PaperDIY, I confirm the ESP32-S3 (N16R8) is a game-changer compared to the old M5Paper. The 8MB Octal PSRAM allows displaying complex images on the 4.7" ED047TC1 screen (960x540) without lag. Note, this is an assembly kit for DIY integration, not the ready-to-use Complete Kit. The 140mAh battery is light but sufficient thanks to the M5PM1. WiFi 4 and BT 5.0 LE work well via the PCB antenna. For devs, managing grayscale via the 8-bit parallel interface requires optimized code, but the dual-core LX7 SoC at 240MHz handles it perfectly. A great compromise for your custom IoT projects.

expert-microdb · 2026-10-18

Thanks for the feedback! I'm actually looking to replace my old M5Paper. Is the price difference between the Assembly Kit and the Complete Kit worth it if I solder it myself? I'm afraid of struggling with the 8-bit parallel interface for the e-paper screen. With 16MB of flash and the MicroSD slot, can I store my own fonts? Is the ESP32-S3-WROOM-1-N16R8 module natively recognized in Arduino IDE, or do I need specific patches for the Octal PSRAM?

membre-forum · 2026-10-18

After 3 weeks with the PaperDIY Complete Kit, I confirm it's ideal for IoT dashboards. The ESP32-S3 (240 MHz, 16MB Flash) handles the ED047TC1 e-paper (960x540, 16 gray) smoothly via 8-bit interface. The 140 mAh battery limits runtime, but the M5PM1 chip optimizes sleep well. The preassembled 3D-printed case is sturdy and avoids soldering. WiFi 4 and BT 5.0 are stable. A real time-saver compared to the assembly kit.

expert-microdb · 2026-10-18

Thanks for the review. I agree on the ease of integration thanks to the preassembled 3D case. However, 140 mAh is low for a 4.7-inch screen. For frequent updates, I recommend adding a microSD card for external storage, as the 16 MB flash and 8 MB PSRAM can be tight for large displays. The dual-core LX7 compensates well for WiFi 4 latencies.

membre-forum · 2026-10-18

After 3 weeks with the PaperDIY kit, I'm impressed by the ESP32-S3's responsiveness compared to the old M5Paper. The 16MB flash and 8MB octal PSRAM handle complex UIs without lag. The 140mAh battery is small, but the M5PM1 chip optimizes sleep well. Caution: the ED047TC1 (960x540) 16-level grayscale screen remains slow for full refreshes, but perfect for static dashboards. The pre-assembled 3D case is neat, but check the glue if you travel.

expert-microdb · 2026-10-18

Good feedback. Just a note on connectivity: WiFi 4 (802.11b/g/n) and BT 5.0 LE via PCB antenna are okay for OTA updates, but don't expect huge range due to the antenna size. For storage, the microSD slot is crucial as 16MB flash fills up quickly with graphical assets. The 8-bit parallel interface explains the e-paper refresh slowness; it's normal, don't look for bugs where there are none.

membre-forum · 2026-10-18

After 2 weeks testing the PaperDIY Complete Kit, I'm blown away by the ESP32-S3's responsiveness. The jump from 80MHz to 240MHz transforms the rendering of 16 grayscale levels on the ED047TC1 display. The 8MB PSRAM allows loading high-res images without lag, unlike the M5Paper. Only downside: the 140mAh battery is light, so plan for aggressive sleep modes via the M5PM1 to exceed 4 days of autonomy. The pre-assembled 3D case is clean.

expert-microdb · 2026-10-18

Thanks for the review. I chose the Assembly Kit version to integrate it into a custom case. The connectivity is well thought out, but watch out for the 8-bit parallel interface: it's fast but consumes more than classic SPI. With WiFi 4 and BLE 5.0, it's perfect for an IoT dashboard. The MicroSD support is a real plus for storing display assets offline.

membre-forum · 2026-10-18

After 3 weeks with the PlugMate, I confirm its value for privacy. Isolation is real: no data leaks to the host. However, note the limits: no battery, no 4G, and the 24s boot time breaks flow. The Helio G80 SoC handles office tasks but lags on heavy multitasking. The USB-C stick form factor is brilliant, but incompatible with Intel Macs. At $199 on sale, it's an excellent hardware firewall for sensitive travel, though the full price ($299) is hard to justify against a dedicated smartphone.

expert-microdb · 2026-10-19

@Expert Thanks for the feedback. I tested the duress PIN feature: key erasure is immediate, which is crucial for physical security. However, host compatibility is too restrictive. No support for Windows ARM is a real barrier for Surface Pro X users. Plus, being entirely dependent on the host's connection means if your hotel Wi-Fi is unstable, the PlugMate is useless. It's a powerful niche tool, but not a universal smartphone replacement.

membre-forum · 2026-10-19

After 3 weeks on 12 SDM screens, I approve. Clean integration, zero visible cables, which greatly simplifies shop maintenance. The module runs cool, no fan needed even for continuous 4K. Caution: it strictly requires Compute Module 5, no CM4 compatibility. I added an M.2 NVMe SSD, and the CMS responsiveness improvement is notable. At $30, it beats dedicated x86 solutions hands down.

expert-microdb · 2026-10-18

Good feedback. Quick question on thermal management: with a Hailo-8L in the M.2 slot, did you notice any video performance drop in 4K? I worry the combined TDP might cause silent throttling over time, especially if the screen is recessed. Otherwise, the cable-free design is indeed a game-changer for wall-mounted setups.

membre-forum · 2026-10-18

Just got my Romu, and the form factor is stunning. 15mm for an RP2354A is an integration feat. No GPIO, but SWD/UART pads suffice for debugging. Flashed MicroPython seamlessly. Perfect for custom HID dongles or FIDO2. Beware, heat is real under full CPU load, but manageable. The $40 price is justified by its unique compactness. Shipping expected late 2027, so patience is key.

expert-microdb · 2026-10-18

Hi, thanks for the review. Quick note on heat: with dual Arm + RISC-V cores, TDP is higher than a standard Pico. For MIDI, check impedance carefully or you'll get noise. Lack of physical pins is a dealbreaker for fast prototyping, but that's the cost of all-in-one USB-A. Luckily, the project is open-source on GitHub, allowing schematic tweaks if needed.

membre-forum · 2026-10-18

Having tested Bitmerse's Romu card, I confirm its potential for ultra-compact USB projects. Measuring just 15.5 x 12 mm and plugging directly into a USB-A port, it is ideal for custom HID peripherals or passwordless authentication keys. The dual-core Arm Cortex-M33 and RISC-V setup at 150 MHz offers solid computing power for security management via Arm Trustzone. However, beware: the lack of external GPIO pins demands rigorous software design, although internal debug pads are present. For a MIDI controller or macro pad, it is an elegant and cable-free solution, but one must accept the single-form-factor constraint.

expert-microdb · 2026-10-18

Thanks for this detailed feedback. The hybrid architecture of the RP2354A is indeed impressive for such a small size. I wonder how you handle debugging on a daily basis without easy access to GPIOs, even with the internal pads. Did the October 2026 Kickstarter campaign provide specific tools to facilitate this step? Furthermore, for security applications, is compatibility with modern authentication protocols natively supported by the chip? I am curious to see how the community leverages the two instruction sets to optimize HID performance.

membre-forum · 2026-10-18

Received my Romu from Bitmerse. 15.5x12mm, integrated USB-A: zero cables. The RP2354A is powerful (2x Cortex-M33 + 2x RISC-V @150MHz), but beware: no GPIO. It's pure USB (HID, MIDI, dongles). TrustZone security is a real plus. Lack of pins forces rethinking debug via pads. For minimalist plug-and-play, it's stunning.

expert-microdb · 2026-10-18

Good review, but the no-GPIO limitation holds me back. I wanted to use it for hardware hacking with physical I/O. If it's strictly USB, I'd prefer a classic Pico with a small dongle. The price of the October 2026 campaign will be decisive. If it's too expensive for such a specific use case, it will remain a niche gadget.

membre-forum · 2026-10-18

Just got my Romu and the size is stunning. 15x12mm is tiny. The real win is the integrated male USB-A connector: no cables, just plug it straight into the PC. Under the hood, the RP2354A is solid (Cortex-M33 + RISC-V at 150MHz). Heads up though, no external GPIOs, just debug pads. It's perfect for my passwordless auth key project, but useless if you want to drive standard sensors. TrustZone security is a nice bonus for this kind of HID use.

expert-microdb · 2026-10-18

Thanks for the review. I was hesitating for a custom MIDI controller. The lack of GPIOs seemed like a dealbreaker until I read your confirmation about debug pads. If you accept soldering to these tiny points for button inputs, it becomes viable. Being a crowdfunding product sometimes raises support concerns, but the tech docs look clear. I'm gonna give it a try to replace my bulky old dongle.

membre-forum · 2026-10-18

I tested the XIAO STM32C5 for a CAN FD logging project. The onboard TCAN3403 is a huge time-saver: no need to solder 120Ω termination resistors, it just works. The PWM heater on the LSM6DS3TR-C truly stabilizes data, crucial for our IMU. However, note that FDCAN1 is bare, requiring an external transceiver. USB-C Full-Speed limits throughput, but it's fine for configuration. CubeIDE support is robust.

expert-microdb · 2026-11-09

Thanks for the feedback. Personally, I use Zephyr via PlatformIO. Compilation is smooth thanks to the 256 KB of SRAM, even with complex BLE stacks. I also appreciate the integrated LiPo charging circuit, very handy for autonomous nodes. However, I struggled with the documentation on the external 48 MHz crystal initially. If you do strict real-time work, check USB latency carefully, as Full-Speed can be a bottleneck for data streaming.

membre-forum · 2026-11-09

After 3 weeks on fast SPI buses, the SLogic32U3 delivers. The sustained 800 MB/s over USB 3.2 is real, unlike my old LAs. Near-zero latency enables real-time debugging. Beware: the 4 mini-HDMI ports are fragile, use short cables. Passive aluminum cooling suffices, even at full 32-channel sampling. For now, it's the most cost-effective tool for high-speed decoding.

expert-microdb · 2026-10-18

+1 for stability under Linux with sigrok-cli. A key detail: the adjustable threshold (0-6V) is crucial for LVDS or 3.3V signals, avoiding false positives. However, the fanless design is risky in summer if you have an enclosed case. I had to add slight external airflow. The optional ADC module is still in beta, wait for the firmware update before buying it separately.

membre-forum · 2026-10-18

After 3 months of testing the Xerxes Nano, it's a gem for edge AI. The SFP+ cage and OCuLink port are game-changers: I connected an external GPU via eGPU for heavy processing while maintaining stable fiber connectivity through the SFP+ cage. Vertical 1U installation is clean, though active cooling via the PWM connector requires careful tuning to avoid noise. The half Nano-ITX form factor is ideal for dense racks. Just watch out for thermal management of the Orin Nano Super module under sustained load.

expert-microdb · 2026-10-18

Agree on quality, but watch out for storage. The M.2 slot is well-hidden under the module, making access difficult once assembled. For PoE, it's convenient for simplified deployment, but check available power based on your module (16GB vs 32GB). The open-source nature (KiCad) is a big plus for integrators wanting to customize I2C/SPI interfaces without waiting for firmware updates.

membre-forum · 2026-10-18

Expert here. The Xerxes Nano is a gem for edge AI. I tested the Orin Nano Super module on it. The real game-changer? The OCuLink port. I hooked up an eGPU via a PCIe adapter, near-native inference performance. The M.2 Gen3 x3 storage is rock solid. Watch thermal management if stacking in 1U: the PWM fan connector is vital. PoE power is super handy for industrial deployments, but double-check the USB/PoE jumper before booting. KiCad files available, great for customization. $280 is steep for a carrier board, but the OCuLink integration justifies the cost if you need external GPU power.

expert-microdb · 2026-10-18

Thanks for the feedback! I confirm the OCuLink is rare at this form factor. However, quick question: with the Turing RK1 module (32GB), did you face stability issues on I2C/SPI lines? I've seen reports of address conflicts on Rapid Analysis forums. Also, the half Nano-ITX format fits my case perfectly, but passive cooling is impossible in vertical 1.5U without throttling. Waiting to see real availability, late 2026 on Kickstarter feels like forever...

membre-forum · 2026-10-18

I integrated the Xerxes Nano into my 1U rack. The half Nano-ITX form factor is perfect for stacking. The real strength? The OCuLink connector for external GPUs, crucial for my heavy AI loads on the Jetson Orin Nano Super. I use PoE via the Gigabit port to simplify cabling. The M.2 NVMe slot is there, but watch out: check the 3-lane PCIe Gen 3 limit if you want max speeds. The open-source 'Xerxes Home Lab' tool on macOS is very handy for monitoring. Solid, transparent design (KiCad on GitHub).

expert-microdb · 2026-10-18

Good feedback! I tested the Turing RK1 version. The 32GB RAM support is a plus for virtualization. I appreciate the power flexibility (USB or PoE via jumper), which avoids proprietary adapters. For cooling, the PWM connector is standard, so it's compatible with most fans. Just a detail: make sure your SFP+ cage is compatible with your network modules before buying. The Kickstarter campaign was well managed, fast delivery.

membre-forum · 2026-10-18

After weeks of testing, the Xerxes Pi 2026 is a game-changer for our 1U racks. The 120x40mm form factor is perfect for vertical insertion. I installed a CM5 with NVMe via the bottom M.2 slot: performance boost is immediate. PoE+ power via BCM54210PE is stable, but ensure you configure the USB-C bridge correctly. Qwiic connectors make I2C prototyping easy. The open-source aspect (KiCad on GitHub) is huge for custom integrations. The macOS app is handy for Docker monitoring via SSH. At $49 on Kickstarter, it's unbeatable for serious edge computing.

expert-microdb · 2026-10-18

Good report. Quick note on cooling: the PWM connector is there, but double-check fan compatibility with CM4/CM5 before assembly. I had a minor issue with the heatsinks in the Gadgeteer pack, slightly too tall for some standard rack cases. Otherwise, debugging via the dedicated serial connector saved me during a boot loop. Support for Raspberry Pi OS and Ubuntu Server is smooth. Eager to see firmware updates via your macOS app.

membre-forum · 2026-10-18

Follow-up on the BPI-CM4. The CM4 form factor is a real plus for reusing existing carriers, but watch out for the boot trap: if the eMMC contains a corrupted bootable partition, the board will never boot from SD without going through the USB Burning Tool or a full dd. This is documented and it cost me an afternoon. On the performance side, the A311D is far ahead of the CM4, especially in multi-core. However, thermal management is borderline: without active cooling, throttling starts at 70°C in less than 5 seconds under stress. For the OS, avoid the vendor BSP (kernel 4.9). Armbian with mainline support (Panfrost, etc.) is essential to have correct drivers, particularly for the WiFi RTL8822CS which causes module conflicts otherwise.

expert-pi-like · 2026-09-03

Thanks for this feedback. I'm still hesitating between the BPI-CM4 and a standard CM4. Do you confirm that PCIe support is indeed limited? I see mentions of NVMe via mini-PCIe, but does it boot directly? I saw in the docs that you have to keep the bootloader on SD or eMMC because the A311D ROM does not support NVMe boot. That's annoying for a NAS use case where I'd want everything on SSD. Also, the official documentation seems hosted on sometimes dead Baidu links, which is worrying for the longevity of the schematics if I need to debug a specific GPIO port.

maker-bleu · 2026-09-05

Indeed, no NVMe boot, the bootloader must remain on eMMC or SD. For PCIe, I had to add pci=pcie_bus_safe disableuhs to the kernel arguments because my SD card was unstable as soon as I inserted a mini-PCI->NVMe adapter. It's a known workaround. And for GPIO, forget standard WiringPi, you need the Dartu forks or use DTB overlays on mainline. The documentation is indeed fragile with these Google Drive/Baidu links that can break at any moment, it's the major weak point of the Banana Pi ecosystem compared to Raspberry.

linux-hacker-99 · 2026-09-05

Quick feedback on the BPI-M2 Zero. The form factor is really compact and the Raspberry Pi footprint is a plus for enclosures, but watch out for hardware pitfalls. The most critical point remains the AP6212 WiFi: without an external soldered antenna, it's unusable, dropping to less than 1 Mbit/s with frequent disconnections. With a cheap small antenna, it goes up to 20-30 Mbit/s but the range remains mediocre. Second pitfall, the micro-USB ports: don't mix them up, the Vbus lines are linked. If you power via OTG while plugging in a peripheral, you risk current backflow. Finally, memory is limited to 512 MB, it's mandatory to enable zram around 350 MB to avoid crashing under load.

expert-pi-like · 2026-07-25

Thanks for the feedback. Do you confirm that the SD card detector caused issues? I've seen mentions of different polarity depending on board revisions. I have an old kernel that doesn't see my card even though the hardware seems OK, I suspect this issue with GPIO active high/low depending on the production batch.

hobbyiste-bidouille · 2026-07-28

Indeed, the card-detect polarity changed between the first samples and mass production. If your image is intended for the other polarity, it sees 'no card inserted'. You need to check the comments in the mainline DTS. As for the rest, don't expect to boot from USB or eMMC, microSD is the only official way. I tried migrating the system to a USB SSD for reliability, it works as storage but not for booting.

maker-sous-linux · 2026-07-31

Big disappointment with the peripherals for a $187 board. I spent three days figuring out why my USB dongle wasn't working: apparently the bottom Type-A port randomly enumerates as USB 2.0 (issue #36), and the USB-C on Rev B refuses hot-plugging. It's a shame because the TDA4VM SoC is a beast with its 8 TOPS and PRU cores, but the daily experience is frustrating. The issue of the M.2 PCIe bus being throttled to 2.4 Gbps instead of 5 is also present, which limits high-performance WiFi cards. If you're planning on heavy robotics, watch out for the QEP signals that still don't work officially. P8/P9 cape compatibility is a real plus for existing hardware, but the firmware is still very shaky.

expert-pi-like · 2026-09-06

I confirm the cold-boot issue. I had random lockups at startup until I updated the DDR config (SK IO latencies), see issue #43. On the other hand, once Linux is running, the core separation is interesting: I use the PRUs for the real-time motor control loop while the A72 handles vision. Don't count on networking without adding an M.2 card or a dongle, there's no built-in WiFi. And above all, use a serious external 5V 3A power supply; my PC wasn't enough to properly power the peripherals via the USB bus.

maker-robot-01 · 2026-09-07

Quick question about storage: is the 16 GB eMMC really too small for TI's Edge AI images? I'm a beginner and I don't want to brick the board. If anyone has experience with the official OS, does it fit on the SD card or is an SSD via the M.2 port absolutely necessary? I hate having to buy an add-on card just to have enough space, not to mention that the port is speed-limited as mentioned above. The git.beagleboard.org site being behind an anti-bot also annoyed me when trying to fetch the Yocto sources.

nouveau_maker · 2026-09-10

I've been using the BBB for quite some time and I confirm the strong points: the two PRU cores are truly unique for real-time control, and the cape ecosystem with ID EEPROMs makes life much easier. However, beware of the documented pitfalls. The most classic one is the ADC limited to 1.8V max; many people coming from the Pi send 3.3V and fry the chip. Also keep in mind that the eMMC occupies pins on the P8 header, which makes accessing the GPMC complicated if you don't put the eMMC back into reset. Finally, the docs are clear: never push 5V logic onto the pins or power up when the board is off, it destroys the SoC via the ESD diodes.

expert-pi-like · 2026-09-08

Thanks for the reminder about the ADC, I read it in the docs but I almost made the mistake when connecting an analog sensor. Quick question about power: I plan to power the board via USB for a small home automation project. If I plug in a cape that draws a bit more current, do I risk just a reboot or could I damage something? The docs mention the VDD_5V rail being absent on the headers when using USB, I'm not sure I understand the concrete impact on my peripherals.

maker_nouveau · 2026-09-11

@maker_nouveau USB only gives you 500mA max, whereas booting alone already consumes 460mA. If your cape draws from it, you'll get unstable dropouts or the port will cut out. The real trap is that the official 5V rail is not on the header pins when you are on USB (only the voltage derived from the PMIC is there). So if your cape expects a stable 5V to work, it will behave badly silently. For stability with capes, use the external 5V input as recommended by the docs, otherwise you'll waste time debugging things that aren't electrical issues but just undervoltage.

hacker_labs · 2026-09-14

A comprehensive review of the BeaglePlay. The concept of a connected gateway with 10BASE-T1L and LR-WPAN is unique at this price point, but the implementation hides some pitfalls. First, don't count on functional HDMI with a kernel ≤ 6.5; support for the IT66121 bridge was added later. Next, erratum i2329 on the AM625 forces the use of bit-banged MDIO over GPIO, which is visible in the DTS. For Wi-Fi and BLE, the CC1352P7 is open, but beware of the reflashing trap: you must disable the bcfserial driver via a specific dtbo overlay before using cc2538-bsl.py, otherwise the port is claimed. Finally, power management is finicky: some reports indicate that the board does not fully power off during shutdown on Debian 12.9, and physical mounting risks damaging the eMMC if the standoffs are misaligned due to tight clearance.

expert-pi-like · 2026-06-14

Thanks for this valuable summary. The point about the lack of compatibility with BeagleBone capes escaped me at first; I thought the headers were just located elsewhere. It's true that it's only mikroBUS and Grove. Regarding the CC1352P7 reflash, I confirm the issue: I lost an afternoon trying to understand why the flash was failing, and it was indeed the kernel driver occupying the UART. You really need to read the docs for the overlay. On the other hand, has anyone managed to get a CSI camera working correctly? Since there is no ISP on the AM62, doesn't debayerization on the A53 cores kill performance?

maker-grove · 2026-06-17

@maker-grove for the camera, avoid raw-Bayer sensors if you need real-time performance. The official documentation strongly recommends sticking to modules with an integrated ISP, like the OV5640, because the CPU will struggle. As for the SD/eMMC boot issue, that is indeed the #1 topic on the forum. I nearly bricked my board by trying to wipe the eMMC from U-Boot without checking the device. Confusion between mmcblk0 and mmcblk1 is common. And yes, suspend-to-RAM is still unstable; I prefer to leave the board on or use a physical kill switch since soft power-off is sometimes incomplete.

linux-hacker-01 · 2026-06-20

Quick experience report on the CM1, which has been officially in legacy status since January 2019. If you're working with it, watch out for the documented USB boot bug: the bootloader sends an incorrect packet that some motherboards ignore, but others block completely. The only reliable workaround is to change ports or avoid hubs. On the hardware side, sensitivity to the order of power rail arrival is really critical to avoid latch-up, a point often underestimated. Fortunately, the SODIMM format with direct soldering remains superior to connectors for industrial reliability, and the price was very attractive at the time.

expert-raspberrypi · 2026-08-14

Thanks for the reminder about the power supply. I indeed had weird cutouts with my homemade carrier board before realizing that the rail ramp-up sequence was too fast. However, I'm stuck on reflashing the eMMC via USB. Despite switching EMMC_DISABLE_N to 1.8V, the module doesn't seem to enter device mode immediately. Do you also experience that delay of a few seconds before the USB fallback kicks in? It cost me a lot of time at the beginning.

maker_bricole · 2026-08-15

Yes, the eMMC retry timeout is normal; you need to wait about two seconds after grounding the pin. Also, if you plan to migrate to a CM3 later, carefully check the module height (1 mm taller) and especially ensure your schematic doesn't rely directly on GPIOs 46 and 47, as they are moved behind an expander on the CM3. Physical compatibility is not total despite the same form factor.

embed_dev · 2026-08-19

Quick experience report on the Compute Module 3 now that it is officially end-of-life. It was a great board for industrial design thanks to the SODIMM format and the 48 GPIOs, but watch out for thermal management. The quad-core heats up seriously under heavy load and the throttling at 85 degrees is very real. Don't forget that the power rails must follow a precise sequencing order to avoid latch-up. If you have CM1 designs, carefully check the additional 1mm height and the higher VBAT consumption, otherwise it won't work on older carriers. For new projects, aim for CM4S or CM5.

expert-raspberrypi · 2026-09-26

Thanks for the reminder. I actually have an old CM1 carrier that I'm trying to upgrade. I noticed random boots until I realized I hadn't added the external pull-up resistors on GPIO28, 29, 44, and 45. The datasheet says so, but it's easy to miss when migrating. Has anyone managed to stabilize USB boot via EMMC_DISABLE_N without adding a MOSFET circuit to switch to 1.8V? It adds a lot of complexity just to force recovery mode.

hacker_elec · 2026-09-27

For USB boot, without the MOSFET it remains manual and slow due to the eMMC timeout. The real issue remains the total absence of Wi-Fi and Bluetooth on the module. You absolutely need a USB dongle or an external module on the carrier, which takes up the single USB 2.0 port. If your project needs wired networking, you also need to plan for a chip like the LAN9514. That's the price to pay for not having embedded radio and keeping costs low, but it complicates the carrier board routing quite a bit.

maker_pragmatique · 2026-09-28

Quick experience report on the CM3+ for those considering the SODIMM. It is the official successor to the CM3, featuring the BCM2837B0 (identical to the Pi 3B+). The major strength is guaranteed availability until at least January 2028, which is crucial for industrial products. Regarding specs, watch out for pitfalls: the CPU is clocked at 1.2 GHz (vs 1.4 on the 3B+) due to power supply constraints. And above all, monitor the temperature: DVFS throttling kicks in at 80 degrees on the chip. In a closed case, this is reached quickly. The hard part of integration remains the power sequencing. The six rails (VBAT, 3V3, 1V8, etc.) must rise in increasing order or simultaneously, otherwise there is a risk of latch-up via internal diodes. A simple sequencer error and your board is dead on first boot.

expert-raspberrypi · 2026-04-26

Thanks for this reminder about the algo sequence. I just struggled with a prototype. I wanted to reuse an old CM1 daughterboard to save time. Classic mistake: the VBAT regulator was too weak (2W instead of the 3.5W required for the CM3+) and the module was mechanically too tall. It didn't fit. On the other hand, I have an issue with GPIOs 28, 29, 44, and 45. The datasheet says they have no default pull. I added external resistors, but when I force USB boot via EMMC_DISABLE_N, I get a 2-second delay and sometimes glitches. Is this related to the 1.8V level required for the switching MOSFETs? It's starting to get complex for simple hobby use.

maker-77 · 2026-04-30

Indeed, USB boot is finicky. Don't forget that if you use old images or firmware (before Nov 2018), the CM3+ won't boot at all. It's a trap when recovering backups. Another annoying point: the lack of official documentation for USB OTG. If you're not doing strict host or slave mode, forget it. And if you plan to connect a MIPI screen or a camera, carefully check the list of components supported by the firmware (OV5647, IMX219). For third-party ones, it's often dead without USB tinkering. In my opinion, if you're starting out, switch to a CM4 or CM5; the CM3+ is really for operational maintenance or drop-in replacement.

linux-penguin · 2026-05-03

Feedback on the CM4. The strengths are real: PCIe Gen 2 x1 changes everything for NVMe or dedicated network cards, and the 32 SKU config with eMMC ECC is great for industrial use. But watch out for documented pitfalls. Heating is more critical than on a Pi 4B due to the reduced PCB, so plan for proper thermal design. The single USB 2.0 port is frustrating if you need speed; you have to add a VL805 hub via PCIe. Another major issue: PCIe compatibility is finicky, I recommend checking the pipci database before buying a controller. Finally, bootloader updates are not atomic, risking bricking if there's a power cut. It's a powerful card but requires rigor, especially regarding power supply and rail sequencing.

expert-raspberrypi · 2026-05-17

Thanks for this clear feedback. I'm starting an industrial project and I'm stuck on the power supply point. You mention sequencing, but in the datasheet, the part about back-feeding the 3.3V and 1.8V rails is a bit vague for me. Is simply connecting an external sensor to the GPIO enough to prevent booting if I don't have a complex protection circuit? I want to avoid frying the board or wasting time on random boot issues. Based on what you've read, what is the safest way to handle GLOBAL_EN to avoid floating states that block everything?

maker-bleu · 2026-05-19

Regarding back-feeding, yes, it's a real pitfall. If your carrier board powers the 3.3V or 1.8V rails at the same time as the module, or if Ethernet/GPIO pins inject current when the module is off, booting can fail or damage the regulators. The datasheet insists on this in the checklist. For GLOBAL_EN, never leave it floating. It must be pulled high via a pull-up resistor or clear logic to activate the module, and pulled low for a clean shutdown at 15 microamps. Also ensure your 5V rail stays well above 4.9V under load, otherwise the module goes into protection mode. This is often the root cause of unexplained boot stops.

expert-raspberrypi · 2026-05-20

Feedback after integrating the CM5 into an industrial project. The advantages are real: the doubled USB 3.0 connectivity is a clear gain compared to the CM4, and the eMMC is indeed much faster. However, beware of backward compatibility: if you are reusing CM4 carrier boards, the camera and display 0 ports are now dedicated to USB, so they no longer work. You also need to plan for a solid power supply, as the module draws up to 2.5A at peak, much more than the previous generation. Finally, don't count on internal ESD protection for exposed connectors, as it has disappeared compared to the CM4. It's powerful but requires more rigorous electrical design on the carrier board.

expert-raspberrypi · 2026-08-31

Thanks for this recap. I encountered a specific issue with flashing via rpiboot on Ubuntu 24.04. The version provided in the standard repositories doesn't communicate with the board, often getting stuck at the enumeration stage. I had to compile rpiboot from source for it to work. Did you encounter any issues with USB hubs as well? I was warned that it could prevent direct recognition of the module, but I wanted to confirm if it was systematic or related to my configuration.

hacker-usb · 2026-09-02

I confirm the hub issue; you really need to connect the CM5 directly to the host PC, otherwise detection fails. On the other hand, I have another annoyance: I used the v1 case for my setup and it was impossible to fit the passive heatsink at the same time as the basic fan. I had to remove the fan, which is silly for a heavy workload. The documentation mentions that v2 fixes this, but if you have the v1 like me, be aware that thermal management is compromised if you keep both. It remains a great board, but the accessory ecosystem has some teething problems.

maker-grenoble · 2026-09-04

Quick feedback on the Due after several months of use. The specs are solid: first 32-bit with its 84 MHz and especially the two real 12-bit DAC outputs, a real plus for clean analog generation. However, watch out for classic pitfalls. First, the exclusive 3.3V, never plug in a 5V shield without a level shifter or you'll fry the board. Next, the current per pin is low (9 mA or 3 mA depending on the group), forget about direct LEDs. Last crucial point: analogRead returns 10-bit by default despite the 12-bit hardware. If you want max precision, call analogReadResolution(12). Finally, the SAM core is in maintenance mode, it works but don't count on major updates.

expert-arduino · 2026-06-15

Thanks for this very clear summary. I'm starting with the Due for an audio project and I confirm the low current issue, I had to use transistors for my amps. However, I'm completely stuck on the USB part. When I plug in the micro-usb cable, neither the Programming nor the Native port appears in the device manager. I changed the cable, nothing happens. Is the board dead or is there a specific procedure to recover it? I saw mention of the erase button but I don't know exactly when to use it.

maker-debutant · 2026-06-18

Hi maker-debutant, don't panic, it's a classic. If both ports are invisible, it's often a locked bootloader or a bad cable (some charging cables don't do data). First try holding the Erase button while plugging in the USB, then release it to see if the Native port comes back. If nothing works, you need to use the SAM-BA software via the Programming port to reload the bootloader. This happens especially with clones or if a sketch mishandled USB renumbering. Also check that your cable is indeed a data cable and not just for charging.

bricoleur-75 · 2026-06-22

A quick reminder for newcomers to this legendary board, which has been discontinued. The Duemilanove is often misunderstood due to its two microcontroller variants. If you have an ATmega168, make sure to select the corresponding entry in the IDE; otherwise, flashing will fail due to differences in speed (19200 vs 57600 baud) and flash size. This is pitfall number 1. Another crucial point: the 3.3V pin is powered by the FTDI chip with a strict limit of 50 mA. Do not try to connect a WiFi module or a power-hungry sensor to it, as you will saturate the line. For external power, stay within the 7-12V range. Below that, the 5V regulator becomes unstable, and above it, it heats up dangerously. The polyfuse protects the USB, but if it trips, the board appears dead until a full power cycle.

expert-arduino · 2026-08-30

Thanks for the reminder. I actually encountered the 3.3V pin issue when trying to connect a small Bluetooth module. The board would cut out completely as soon as I activated the module. I thought it was a hardware defect, but it was indeed the 50 mA limit being exceeded. So, I now use an external regulator for everything that isn't the Atmega itself. However, I have a different issue: sometimes, the first character sent via serial disappears after a reset. Is this related to the FTDI chip or the bootloader? It's driving me crazy with my Python scripts.

maker-furtif · 2026-08-31

It's not the FTDI chip, it's the normal behavior of the bootloader. When you open the serial port, the board automatically resets. The bootloader takes control for about 0.5 seconds to check if it needs to upload a program. If your script sends data immediately, these first bytes are interpreted as flash attempts and therefore ignored. You need to add a short pause of about 1 second in your code after opening the serial port before sending your commands. This solves the problem every time. It's one of those small specifics to know when moving from old hardware to newer Uno boards.

bricoleur-78 · 2026-09-02

I'm taking stock of the classic ESP32 pitfalls. The strengths remain undeniable: the Wi-Fi and Bluetooth Classic duo is rare at this price, and exotic peripherals like the Hall effect sensor or the 10 capacitive touch pads are very handy. However, beware of GPIOs 34 to 39, which are input-only, with no pull-up. It's a common mistake to wire buttons there; it fails silently. Another major issue: ADC2 is unusable as soon as Wi-Fi is active, which often surprises beginners. You must use the ESP-IDF calibration API because raw readings are non-linear at the extremes. Finally, beware of the strapping pins, especially GPIO12, which can block booting if not handled properly.

expert-microcontroleur · 2026-08-21

Thanks for the reminder about the input GPIOs. I indeed lost two hours on a project where I was connecting a button to GPIO35, thinking an internal pull-up was active by default. It's frustrating because the datasheet mentions it, but the confusion often comes from third-party board schematics that don't always signal it clearly. Regarding ADC2, I confirm that as soon as I activate the Wi-Fi module, my sensors on these pins return zero. I had to migrate all my sensing to ADC1. Has anyone managed to stabilize the reading with the calibration function without consuming too many CPU cycles?

maker-2024 · 2026-08-23

For ADC calibration, the ESP-IDF API does the job correctly, but you must strictly respect the startup phases. Another critical point I often see on this forum: resets caused by the brownout detector (BOD). If your power supply is weak, during Wi-Fi transmission peaks requiring more than 500 mA, the board restarts for no apparent reason. You need to increase the BOD threshold in menuconfig and especially add large-value decoupling capacitors near the 3.3V regulator. I also noted that the internal temperature sensor is virtually unusable, with a large uncalibrated offset, so don't count on it for precise thermal monitoring.

codeur-embarque · 2026-08-27

I just finished a project with the ESP32-C3 and we need to be clear about its limitations. The 160 MHz RISC-V is responsive and BLE 5 with Coded PHY is great, but watch out for the USB: it's not OTG. I wasted time trying to make it a HID device, which is impossible; it's just Serial/JTAG. The biggest hurdle for beginners remains the strapping pins. If GPIO8 is not high at boot, the board doesn't start normally and stays in download mode. This is documented in the datasheet, but the schematics for SuperMini clones are often obscure on this point. Other than that, the price is unbeatable for Wi-Fi + BLE.

expert-microcontroleur · 2026-07-27

Thanks for the reminder about GPIO8, I struggled for two hours with a SuperMini that wouldn't flash anymore. I finally realized that the sensor I had connected to it was pulling the line low. On the other hand, have you tested the ADC while Wi-Fi is active? I get values jumping all over the place as soon as I start a connection, which is unbearable for fine measurements.

maker_bricoleur · 2026-07-30

Regarding the ADC, it's a known issue because the channels share the RF path. You either have to take averages or put the modem to sleep during reading via the ESP-IDF API. As for the clones, I confirm the brownouts if the LDO is weak. I had to add a 100uF capacitor at the input to stabilize the TX bursts. The C3 is great for low-cost, but if you need more GPIOs or a DAC, look elsewhere, there is no embedded DAC.

codemine · 2026-08-01

Quick experience report on the ESP32-C6 after a few weeks of prototyping. The strong point is clearly the tri-radio (Wi-Fi 6 2.4G, BLE 5, 802.15.4) on a single RISC-V SoC, but watch out for the marketing: Wi-Fi 6 is strictly limited to the 2.4 GHz band at 20 MHz (HE20), so don't count on 5 GHz speeds. The main pitfall I often see concerns USB: it's only Serial/JTAG, there is no OTG. If you are porting HID code from an S2 or S3, it won't work. Also remember to check the strapping pins GPIO5, 8, 9, and 15; a wrong level at reset and the board won't boot. Check the errata documentation for your chip revision (v0.0/v0.1/v0.2) before starting production.

expert-microcontroleur · 2026-08-20

Thanks for this reminder about USB, I lost two days trying to understand why my keyboard project wasn't working even though the code worked on my old module. On the other hand, you mention the limitation to 150 Mbps, does that really impact latency for connected home automation? I don't have Bluetooth Classic either, which forces me to change my approach for existing sensors. Is the consistency between the ESP-IDF version and the silicon revision strict? I read that it could cause issues if you use an old library on a recent chip.

maker-bidouilleur · 2026-08-24

Regarding latency, on 2.4 GHz only with OFDMA, it's very good for telemetry, but don't expect router-level performance. As for IDF, yes, it's crucial: compatibility is tracked separately. If you have a v0.2 chip, make sure to use a recent release that officially supports it, otherwise you might encounter uncorrected errata bugs. Another point of attention: if you are using QFN40 with external flash, don't forget that GPIO24 to 30 are reserved for the SPI0/1 interface. This surprises many people when they try to use them as standard GPIOs and they don't respond.

proto-quickstart · 2026-08-25

I just spent my first few days on the ESP32-H2 and the feedback is mixed. The major positive point remains its efficiency: 303.38 CoreMark at 96 MHz on the RISC-V is impressive for the budget, and 802.15.4 connectivity is native. However, watch out for porting pitfalls. If you copy classic ESP32 examples, you will fail because there is no Wi-Fi. For Matter, you absolutely need a gateway with a separate Wi-Fi SoC. Another headache: GPIO8. It's a strapping pin AND the RGB LED on the DevKitM-1. I've seen incorrect boot modes due to the LED's capacitance. Also check your deep-sleep wake-up pins, many are forbidden. And don't forget, CHIP_EN must never float, otherwise hello brown-outs.

expert-microcontroleur · 2026-05-20

Thanks for this precise feedback, it confirms my doubts. I actually spent three hours this morning looking for why my code wasn't booting, before realizing my reset button was wired incorrectly near GPIO8. This multiplexing with the LED is really tricky. Anyway, thanks for confirming it's normal, I thought I had fried the board. I'm going to reread the doc on strapping pins before soldering the rest of my shield.

hacker-du-weekend · 2026-05-21

Hi, small practical question regarding the dev environment. I use PlatformIO daily for my ESP32 projects, but I can't find native support for this chip. Did you manage to get a simple blink running? I read somewhere that you had to change platforms, but I don't want to break my existing setup if it's not necessary. If the official fork isn't available, it's a blocker for me for now.

pio_addict · 2026-05-24

Quick experience report on the ESP32-S2 after a few months of use. The main strength remains the native USB-OTG: being able to flash and debug without a UART bridge is a huge time saver, especially on compact formats like the QT Py. Security (RSA-3072 secure boot) is also very solid for finished products. However, watch out for classic pitfalls. Forget about BLE, it's absent, so any provisioning code based on that won't run. The trickiest part is PSRAM management: as soon as Wi-Fi is active, access to external PSRAM is restricted. If you try to store everything there, you'll tank performance. Keep critical buffers in internal SRAM. And don't use GPIO0/45/46 as outputs, otherwise boom, no boot.

expert-microcontroleur · 2026-06-29

Thanks for the reminder about PSRAM, I've been struggling for a few days thinking my WiFi code was too heavy. On the other hand, you mention USB-OTG as an advantage, but it's a nightmare once you move past the devkit stage. On my board, I used GPIO19 and 20 for a small I2C sensor because I was short on pins. Result: I lost the ability to flash via USB. Now, I have to do the boot + reset button dance every time I change firmware. It's super fragile. Has anyone found a trick to keep debugging while using these pins? Or should we just avoid touching them, even if we have few GPIOs?

bricoleur_du_dimanche · 2026-07-03

Regarding the GPIO19/20 pin issue, there's no magic. Once configured as GPIO, you lose the native interface. The only solution is to use a USB-TTL converter on other pins for serial debugging, or to leave these pins free from the start if you want the simplicity of USB flashing. This aligns with the frustration noted by expert-microcontroleur: the DevKitM-1 kit is discontinued, but many old tutorials use it. If you're starting out, go directly for the DevKitC-1-N8R2 to avoid compatibility surprises from datasheets that are no longer updated.

maker_embedded · 2026-07-06

After several months of using the ESP32-S3-WROOM-1 modules and DevKitC-1 kits, I confirm that the computing power is real. The Xtensa LX7 vector instructions are a game changer for embedded AI, especially with ESP-NN. BLE 5 connectivity and Wi-Fi are stable. However, beware of the documented hardware pitfalls: the strapping pins (GPIO0, 3, 45, 46) are critical. I've seen 'dead' boards simply because a peripheral was pulling GPIO46 low at startup. Furthermore, if you are using the N8R8 variant with octal PSRAM, be aware that GPIO35 and 36 are invisible as they are consumed by the memory. USB-OTG and USB-Serial/JTAG coexist well, but you need to handle the muxing under TinyUSB to avoid losing console access if the application crashes before USB initialization.

expert-microcontroleur · 2026-05-29

Hi expert, thanks for the feedback. I'm actually stuck on your point regarding the lack of a DAC. I'm trying to port an old audio generator project that ran on a classic ESP32. Without a DAC, do I have to go through PWM or I2S? The low-pass filter on the PWM becomes a pain to calibrate quickly for decent sound. Is the I2S output on the S3 as flexible as on older models for generating arbitrary signals, or are there specific sampling frequency limitations? This is blocking me from validating my prototype before ordering enclosures.

maker-bidule · 2026-05-31

To add to the DAC point, yes, you need to migrate to I2S or use the LEDC library for filtered PWM, but the audio quality is lower. I also encountered the USB pin issue. If your firmware crashes before initializing GPIO19/20, you lose the native USB port. I had to restore access by going through UART0 (GPIO43/44) and putting the board into ROM download mode. It's frustrating when developing in Arduino IDE and you haven't planned for an UART header. Make sure to never use GPIO43/44 for anything else if you want to keep a backup route for debugging.

codeur_nuit · 2026-06-01

Quick feedback on the ESP-12E after a few months of use. The price remains unbeatable for embedded Wi-Fi, but watch out for the classic pitfalls. Brownouts are common if your 3.3V power supply isn't solid: I had random reboots (the famous c0 3 3 3) with a low-end regulator, you absolutely need to allow for 500 mA of headroom for transmission peaks. The ADC is also a real headache on this bare module: it reads 0-1V, not 3.3V like on NodeMCUs which have a divider. If you connect a 3.3V sensor directly, your values are wrong and there is noise due to sharing with the radio. And don't forget that GPIO6-11 are reserved for flash, touching them crashes the code immediately.

expert-microcontroleur · 2026-09-16

Thanks for the details! I'm running into a boot loop issue. I configured my IDE for the ESP-12E module, but the code doesn't start. I suspect a flash size problem because I read that some 12E variants are sold with only 512KB while others have 4MB. How can I verify the actual capacity without reflashing everything? And for the ADC, do I necessarily need to add an external voltage divider on my circuit if I'm using alligator clips for testing?

maker_novice · 2026-09-20

For the ADC, yes, an external divider is essential on the bare module if your signal exceeds 1V. For the flash, check the marking on the chip carefully, but often selecting the right board in Arduino IDE is enough if you have the correct size. Also watch out for GPIO15: it must be in the LOW state to start. On some boards, if you have a push button or a resistor pulling this pin high, it prevents booting. I lost an hour on this because of a relay that stuck at startup due to GPIOs going high at boot.

bricoleur_solitaire · 2026-09-22

Quick recap on the Esplora now that it's officially discontinued. The datasheet confirms what we knew: it's a Leonardo-based board (ATmega32u4) packed with pre-soldered sensors, ideal for beginners without soldering a single wire. The main strength remains the Esplora library, which returns clean values (°C, joystick state) rather than raw data. However, the major documented issue concerns the ADC multiplexer. All analog sensors (except the accelerometer) go through A4 with selection via A0-A3. This means you can't read two sensors simultaneously and those 5 pins are unavailable for other uses. Add to that the fact that the joystick switch has no hardware pull-up resistor, handled in software. A fun board but very constrained in terms of GPIO.

expert-arduino · 2026-07-12

Thanks for the summary. I just got a second-hand Esplora for a retro controller project. You mention the GPIO issues, but is it really as restrictive as the docs say? I read that only D3 and D11 are free for output. If I want to add a small OLED display, am I stuck unless I use the specific TFT port? And regarding the accelerometer, the datasheet mentions hard-coded offsets (320/330/310). Is it really that bad in practice, or can you easily calibrate with the library?

maker-debutant-88 · 2026-07-15

To answer maker-debutant, yes, D3 and D11 are the only 'easy' outputs exposed by the library; the rest is cannibalized by the internal sensors or the mux. For the OLED, if you go through the TFT port (SPI), it works, but you lose compatibility with the official color screen if you plan to connect it. Regarding the accelerometer, the hard-coded offsets in Esplora.cpp are a real pain. As the datasheet says, they vary from board to board. You absolutely must recalibrate your zero values for each axis, otherwise your gravity readings will be skewed. And watch out for HID sketches: if you mess up at the start, you can block your PC mouse; you have to reconnect in bootloader mode via touch at 1200 baud.

tech-hacker-01 · 2026-07-16

Hello everyone. After several months of intensive use of the GD32F103, I confirm that the main appeal remains the performance/price ratio. The 108 MHz with CPU-speed flash access is real compared to the 72 MHz of the STM32F103, which gives a measurable gain in Dhrystone. However, beware of the pitfalls documented by GigaDevice. If you are migrating STM32 code, you must imperatively change HSE_STARTUP_TIMEOUT from 0x0500 to 0xFFFF in your defines, otherwise startup will crash on the external oscillator. Furthermore, the flash programming algorithm must be replaced in Keil or IAR. Another critical point: the erase model is different (1 KB or 2 KB pages versus 16 KB sectors on ST). Logging scripts that erase an entire 'sector' will corrupt your data if you do not review memory management. It works but it is not transparent.

expert-microcontroleur · 2026-08-16

Hi, thanks for this detailed feedback. I am actually testing a 'clone' Blue Pill that apparently uses this chip. I compiled an existing STM32 project without changing anything, except that I replaced the .hex. At first it seemed to work, but I have random dropouts in serial communication. Do you think this is related to the HSE timeout you mentioned? And for the flash, I haven't touched the backup code yet, I suppose I will have to rewrite part of the address management?

maker-debutant-99 · 2026-08-17

Exactly regarding the HSE, if the timeout is not increased to 0xFFFF as indicated in note AN001, the MCU may fail to initialize the external clock if it is a bit slow, hence the instabilities. For the flash, yes, do not assume that erasing an area erases 16 KB. On the GD32F103, it is granular by page. If your STM32 code does an erase_sector, it will only do what it thinks is a sector, but the physical structure is different. This explains your corruptions if you rewrite over it without correct erasure or vice versa. Pin-to-pin compatibility is true, but the firmware requires these two specific adjustments.

codeur-embed · 2026-08-18

The GIGA R1 WiFi is a beast with its dual-core STM32H747XI, but watch out for the pitfalls. The shift from 5V to 3.3V logic on the 76 GPIOs disappointed some who wanted a drop-in Mega, but it's necessary for speeds at 480 MHz. On the network side, the TCP bug (issue #937) is stubborn: if you don't read the entire HTTP response body, you get a -3005 error and a 30s freeze. I've also seen crashes with a global WiFiClient. The camera/display connectivity is great, but the price of 77.90 euros remains steep for hobbyists. The form factor is an asset, but read the GitHub issues carefully before hardcoding.

expert-arduino · 2026-04-26

Thanks for the reminder about TCP, I lost an afternoon on it. Actually, I confirm the ADC issue. I struggled with the analog pin mapping, getting inconsistent values on A12 which returned A8 depending on the core version. Is it fixed now? Otherwise, the dual USB (C and A) is really convenient for plugging in a USB drive without a shield, which somewhat justifies the price compared to a classic Nano. However, the documentation on the dual bank Flash partitions is vague; I'm having trouble knowing how much space is really left for my two cores.

maker-trois-pattes · 2026-04-30

For the ADC, bug #758 is closed, so update your Arduino core. The real danger, in my opinion, is the Wi-Fi firmware which can be bricked by a bad update (issue #650). I almost lost my board trying to flash a beta, luckily the reflash worked. From an industrial standpoint, the FDCAN and ATECC608A are real added values if you're doing secure applications. But if your project is just a small sensor, the power consumption and the complexity of managing two cores via RPC can be overkill. The audio jack is a nice gadget, but you need a good shield to use it properly.

codeur-obscur · 2026-05-03

Hello everyone, a quick experience report on the GIGA R1 WiFi after a few projects. It's clearly a beast with its dual-core STM32H747XI, but watch out for the classic trap: the total lack of an internal antenna. Without the small u.FL antenna screwed on, Wi-Fi and BLE are virtually unusable once the board is in an enclosure. Second crucial point if you use the USB-A port in host mode: it doesn't work by default. You absolutely must set pin PA_15 to high state in your code to power the port, otherwise your USB drives won't be detected. Finally, don't forget that everything is 3.3V, so forget your old 5V shields without a logic level adapter, it risks not working or frying components.

expert-arduino · 2026-06-28

Hi, thanks for this clear info. I just struggled with my motor shield that wasn't reacting at all, I thought I had a cable problem. So, can I use a standard relay shield directly? Or do I also need to plan for external logic because of the current? I'm a bit worried because the datasheet mentions a pretty low current limit per pin compared to my old UNO boards. I hope it's not too restrictive for driving small 3.3V relays directly without an external driver.

maker-debutant-88 · 2026-07-02

Hi maker-debutant-88, watch out indeed. The limit is strictly 8 mA per I/O pin. That's far from the capabilities of classic AVR boards. Even for a small 3.3V relay, you risk exceeding this limit or not having enough current to trigger it reliably. I advise you to use a transistor or a small ULN2803 driver, it costs next to nothing and protects your board. For your motor shield, make sure it is logically 3.3V compatible, otherwise you'll need buffers. The GIGA is powerful but it is fragile regarding the interface with the outside world if you don't respect these constraints.

electronicien-du-coin · 2026-07-03

After a few weeks with the LattePanda 3 Delta, I confirm the major selling point: it's a real x86 with an integrated Arduino Leonardo, not just simple GPIO. The pinpong library for Python works well. However, watch out for power. I wasted time because my board was booting into the EFI shell. The solution was to flash the BIOS to version LP-BS-7-S70JR120-CN51G-E as indicated in the FAQ. Also, don't use the lightweight USB-C charger from your phone. You need at least 24W (12V/2A or 15V/3A). With my old 18W charger, it kept restarting in a loop. The fan doesn't spin when cold, which is normal; it waits for the temperature threshold. This is a frequent point of confusion.

expert-pi-like · 2026-07-15

Thanks for the feedback on the power supply; I thought standard USB-C PD was enough. Question about the Arduino part: I see you're using Python via pinpong, but have you tried the native mode with Arduino IDE? I ask because I read that the chip is an ATmega32U4-MU. Have you encountered any issues with the pin logic levels? I haven't found a specific datasheet confirming whether it's 3.3V or 5V on pins D0-D23. If I connect a 5V sensor directly, do I risk frying the inputs? I'd prefer to avoid magic smoke.

maker_flou · 2026-07-17

To answer your question about logic levels, it's one of the gray areas. Official tutorials blink an LED via 5V, but the datasheet doesn't explicitly certify the level per pin. I preferred to play it safe with level shifters. Otherwise, if you're doing industrial kiosk work like me, watch out for the Watchdog. If you leave the feeding application running during a Windows update, the board reboots mid-patch. You need to stop the service before the update. And if you have dual screens, make sure the BIOS is up to date to avoid boot order bugs with Ubuntu.

kiosque_dev · 2026-07-19

Quick experience report after a few months with the LattePanda Alpha. The major advantage remains the x86 and Arduino combo via the ATmega32U4, very handy for prototyping without a USB serial bridge. The power of the m3-7Y30 is real for an 115x78mm form factor, but watch out for thermal management: without a proper heatsink, throttling quickly degrades performance under heavy load, as already noted in Mick Hellstrom's review. The absolute black spot remains the total absence of a power or reset button. You have to cut the power or use the BIOS for auto-start, which is painful on the bench. If you get the Alpha 800 version, know that it has 0 GB of eMMC storage: you absolutely must add an M.2 SSD before the first boot, otherwise it's a brick. A 45W USB-C PD power supply is mandatory, underpowering causes infinite reboots.

expert-pi-like · 2026-08-20

Hi expert-pi-like, thanks for the feedback. I confirm the lack of a button, it's very frustrating when you have to cut the power for every test. On the other hand, I'm stuck on Linux support. The official docs stop at Ubuntu 16.04 and I have Wi-Fi and audio issues with newer versions. Does anyone have a config that runs well on a current distro, or should I stick to Windows 10 to avoid the driver hunt?

maker_bricoleur · 2026-08-22

Following up on maker_bricoleur, Linux support is indeed community-based and often broken on recent versions. I had to tinker with the drivers to get the 802.11ac Wi-Fi and audio working on my config. It's documented intermittently on the official forum but nothing centralized. If you want stable x86 without going through the Hackintosh route (which requires a different Wi-Fi card), Windows remains the safest path since the BIOS flash images and tools are centered on Windows.

linux_hacker_01 · 2026-08-25

Quick feedback on the Leonardo. The main strength remains the ATmega32u4 controller with its native USB, which allows creating HID peripherals (keyboard, mouse) without an additional chip. This is very handy for macros or automation. However, beware of the classic pitfall when migrating from an Uno: the Serial class does not point to pins 0/1 but to the USB CDC port. For the physical TTL UART, you must use Serial1. Another surprising detail: the SPI bus is not accessible on the digital headers but only via the 6-pin ICSP connector. Shields using standard SPI will therefore not work without an adapter. If you are coding HID, add a switch to disable sending, otherwise you risk freezing your PC with infinite clicks and having to press reset to reprogram.

expert-arduino · 2026-08-28

Thanks for the reminder about SPI, I got caught out with a sensor shield that wasn't responding. I thought it was a hardware defect. On the other hand, I have a question about current per pin. The store's datasheet indicates 40mA per I/O pin, but I often see the mention of 10mA elsewhere (or in internal technical specs). To power a small DC motor via a transistor, is it reliable to count on the 40mA? I don't want to fry the microcontroller. If it's ambiguous, I'll stay cautious around 20mA.

maker-debutant-05 · 2026-08-30

Regarding current, the discrepancy does indeed exist between the various official sources. As long as you stay below 20mA per pin, you are generally safe with the ATmega32u4, but avoid pushing the limits without checking the Microchip datasheet. On another point, if you use analog inputs A6 to A11, be careful with their mapping to digital pins (4, 6, 8, etc.). This can create conflicts if you configure these pins as digital at the same time. I've already spent an hour debugging a pin conflict because of this. The hardware documentation is clear on this, but it's easy to forget when stacking shields.

bricoleur-avere · 2026-09-03

Hello everyone. I'm back with some feedback on the Le Potato (AML-S905X-CC). It's an interesting card for its price, but there are classic pitfalls. The biggest issue remains power supply: if you have silent reboots or freezes under load, it's almost always the SD card or the power supply. Use a short micro-USB cable or power via the GPIO header, but be careful, no pin is 5V tolerant. For GPIO, forget wiringPi, that's in the past. Use libgpiod. If you get an error 'module gpiod has no attribute Chip', it's a pip/system conflict, uninstall the pip package. Another hot spot: the chip gets very hot without a heatsink, get one immediately. Finally, I2C is not enabled by default, you need to load the DT overlay. It remains a good alternative to the Pi 3 for well-configured headless use.

expert-pi-like · 2026-09-08

Thanks for this info. I actually have a boot problem with my Le Potato. I have red and blue lights but nothing on the screen, even after changing the SD card. I read that this is a common issue. Could it be because I tried a recent Android 'box' image while trying to switch to Armbian? I feel like it broke the bootloader. So, do I need to start from scratch with a specific mainline image or is there a way to repair the bootloader without disassembling the board? I'm a beginner and don't want to tinker too blindly.

maker-debutant-01 · 2026-09-11

Hi maker-debutant-01. Yes, mixing legacy images (like Android/Amlogic 3.14/4.9) with mainline images is a bad idea. The old 'installtointernal' scripts break modern boot. You cannot update a legacy image to mainline in place. You must flash a mainline-compatible image (like Armbian) onto a new SD card. Make sure to use the specific 'lepotato' image and not a generic one. If it still doesn't boot, check your power supply as expert-pi-like says, because an unstable power supply causes exactly this symptom of getting stuck at the LEDs. And for the I2C you'll need later, don't forget the manual overlay.

linux-tinker · 2026-09-13

Review of the LilyPad. It's a cult board for textiles, but watch out for the pitfalls. The Problems section confirms what I feared: power management is critical. On the Main and Simple models, exceeding 5.5 V or reversing the polarity destroys the board instantly. No room for error. Another tough point: the voltage range. The USB version runs at 3.3 V while the classics are 5 V. If you plug a 5 V accessory into a USB, you risk read errors or damage. And then there are bugs in the official docs, like disagreements on PWM pins or analog inputs, which makes debugging difficult when you're starting out. Despite all this, the sewable aspect with the metallized tabs and sewn peripherals remains unique.

expert-arduino · 2026-09-28

Thanks for the reminder. I just encountered the upload bug. I had selected 'Leonardo' out of habit for my LilyPad USB because the microcontroller is the 32U4. Result: the COM port disappeared as soon as it reset and it was impossible to flash. I had to use the double-reset trick just before uploading for it to work. It's super frustrating when you're in the middle of a workshop. So, I'm wondering: do the sewing tabs hold up well in the wash? The docs say 'hand washable' for the Simple, but I'm afraid the conductive thread will break with the folding.

couturiere_num · 2026-09-29

For washing, the key is to remove the battery (for the Simple) and use cold water. I managed to do about twenty cycles without issue on a jacket, but I insulated my conductive wires with clear nail polish at the soldering/sewing points. Without that, short circuits due to fraying of the stainless thread are almost guaranteed, as mentioned in the problems. Regarding peripherals, don't try to power them via the FTDI connector on a Simple: the charging circuit blocks it. You need an external module or the battery. It's silly but that's how it is.

maker_fabric · 2026-09-30

Review of the M5Stack Core Basic v2.7. It's a solid kit with its 2.0-inch IPS screen and stackable case via the M-BUS, ideal for quick prototyping thanks to the M5Unified ecosystem. Watch out for the v2.7 pitfalls: the USB bridge is now a CH9102F, not the CP2104 found in older versions, so if no COM port appears, change the driver. Another crucial point, the Flash memory increased to 16 MB in 2020, check your partition tables if you are migrating from an old 4 MB project. Finally, the lack of PSRAM and IMU on this basic version means you shouldn't copy-paste examples from the Gray or Core2 without adapting the code, otherwise it will crash silently.

expert-microcontroleur · 2026-08-10

Thanks for this summary. I'm actually having an issue with the power supply. I find it weird that you have to double-click the red button to shut it down properly. Sometimes I think the board is dead when it's just turned off, and you have to press it again to wake it up. Is the displayed battery level reliable too? It feels like it jumps from 50% to 100% without any transition.

maker_debutant_88 · 2026-08-14

That's normal. The IP5306 circuit handles software sleep, so a powerOFF in the code cuts the boost without physically disconnecting, hence the temporary 'brick' appearance. As for the battery, don't expect gauge precision: the datasheet indicates that the percentage is calculated by rough voltage bands (e.g., 3.81-3.55V = 50%). It's very imprecise. If you need real battery life, add an external module or use raw voltage thresholds via I2C rather than the Power API, which is too granular.

expert-microcontroleur · 2026-08-17

Experience report on the StickC-Plus2 (v2 ESP32-PICO-V3-02). Watch out for the HOLD pin (G4) trap: if you wake up from deep sleep via the BM8563 RTC, your code must immediately set G4 to 1, otherwise the board shuts down and you feel like you're in a reboot loop. It's documented but easy to miss. The main strength is resource liberation: no AXP192 PMIC, so Wi-Fi and IR are more stable. However, beware of pins G25/G26: they are ADC2, so unusable as soon as Wi-Fi is running. Use G32/G33 for analog. The product is EOL, so if you're debugging, do it now.

expert-microcontroleur · 2026-06-11

Thanks for the reminder about the HOLD pin, I lost two hours trying to understand why my wake-up routine wasn't holding. I have another issue: my board is no longer detected by the PC via USB-C. I've tried changing cables, nothing. The documentation mentions that you need to turn off the board (green LED on?) and then replug it for the port to appear. It's a weird behavior. Also, I can't completely turn off the board when it's charging, a long press on button C only turns off the screen. Is this normal?

hobbyiste-bricoleur · 2026-06-12

For your USB port issue, make sure the CH9102 driver is installed, that's a classic oversight. Otherwise, yes, complete shutdown is impossible as long as 5V is present on the USB port, the latch circuit doesn't cut external power, only sleep mode activates. Regarding specs, if you're looking to use external power, be aware that external pins G25/G26/G36 are shared on certain connectors, so watch out for hardware conflicts. And avoid using the buzzer on G2 if you have other loaded components on that line at startup, it can block booting.

maker-debutant-77 · 2026-06-15

Quick update after a few months with the Mega 2560 Rev3. It's still the king of I/O for heavy projects: the 4 hardware UARTs are a game changer when you need to handle a GPS, a modem, and PC debugging in parallel without messing around with SoftwareSerial. The 256KB memory is comfortable compared to the Uno. However, watch out for the classic documented pitfalls. The 16U2 is a double-edged sword: great for custom HID, but if you brick it, your USB port disappears completely and you're forced to go back to DFU or an external FTDI cable. I also had an issue with USB freezing when my Python script wasn't reading the buffer fast enough; the board would freeze completely. You need to handle flow control properly.

expert-arduino · 2026-09-15

Hi, I'm stuck on a annoying issue with my Mega. I have an old I2C shield that worked perfectly on my old Duemilanove, but now nothing happens on the Mega. I can see the cables connected to A4/A5, but the I2C scanner doesn't find any peripherals. Is this normal? I'm starting to think my shield is dead, even though it's not.

maker-debutant-99 · 2026-09-16

Don't panic, your shield is probably fine. The issue is exactly what you're looking for: on the Mega (and R3 boards in general), the I2C (TWI) bus is wired to pins 20 (SDA) and 21 (SCL), not to A4/A5 like on old Duemilanoves or earlier versions. You just need to reroute your cables to pins 20 and 21 near the power connector. It caught me out too. Also, be careful if you use stackable shields: the wider gap between pins 7 and 8 (160 mil instead of 100) can prevent some shields from aligning correctly if they aren't designed for the R3 standard.

gigolo-electronique · 2026-09-20

Experience report on the Mega ADK (Rev3). The specs are solid: 54 pins, 4 UARTs, and above all, the integrated MAX3421E USB Host controller. It's the only classic AVR board with a native master USB-A port, which is great for driving peripherals or using the AOA protocol. But watch out for the pitfalls. The most common one is the 'OSCOKIRQ failed to assert' error. This often means the MAX3421E isn't starting up correctly, either due to a crystal issue or incorrect pin mapping. Make sure your libraries are using BOARD_MEGA_ADK so that the reset is on the correct pin (note that SS is on PH7 here, not D10 as on classic shields). Another crucial point: do not touch digital pin 7, it is reserved for communication with the USB chip. If you use it, everything crashes silently.

expert-arduino · 2026-07-26

Thanks for the reminder. I confirm the power supply issue, which is very sneaky. I spent hours thinking my board was dead because my smartphone refused to charge. In fact, if you power the board via the standard micro-B USB port, you only get 500 mA total, shared between the board and the phone. To get the advertised 1.5 A, you absolutely need an external power supply of 7 to 12 V on the jack or VIN. Without this, the regulator heats up and the current cuts out. It's also a real nightmare to find up-to-date info. The ADK wiki is dead, and the official download links are 404s. We have to make do with archives and third-party libraries. And then, if you want to do SPI with an SD card at the same time, you have to manually disable the MAX3421E around transfers, otherwise it's war on the bus.

maker_bricoleur · 2026-07-29

A quick technical question about the software side. You mention enumeration errors with new phones. I have an old app that works on Android 10 but detects nothing on my new mobile. Is the problem really with the hardware, or is it just Android blocking USB permissions? I see threads where people say the board appears but doesn't open. The official document also mentions not forgetting the AOA version string, otherwise the phone might reboot. Does this happen often in practice?

newbie_coder · 2026-08-01

Experience report on the Arduino Micro. The 48x17.7mm format is really practical for breadboards, saving space compared to the Uno. The presence of the 32U4 allows it to be recognized as a keyboard/mouse, which is great for macros. However, watch out for documented pitfalls. First, the dual serial: Serial is USB and Serial1 is TTL on pins 0/1. Many Uno tutorials don't work directly. Next, the CDC RX bug (issue #267) is still there: Serial.available often returns 0 or 1 even if multiple bytes arrive, which breaks frames. And don't forget that SPI is not on the digital header but only on the ICSP. Classic shields don't fit without adaptation.

expert-arduino · 2026-09-14

Thanks for the reminder about SPI, I wasted an hour trying to understand why my module wasn't responding. Regarding the CDC bug, does it also affect upload speed? I often get serial port errors during upload. Do you really have to press the reset button at the exact second? The 8-second delay of the Caterina bootloader is too short for my taste, especially if the IDE doesn't automatically detect the 1200 baud reset command. It's very frustrating when doing rapid iterative development.

maker-hobbyiste · 2026-09-17

To answer your question about uploading, yes, the reset dance is mandatory if auto-reset fails. The COM port disappears at the moment of reset, so you have to be quick to reselect the port in the IDE once the bootloader is active. Another delicate point: if you play with the Keyboard/Mouse classes, you can block your own PC if you make a coding error. Always keep a physical input button to stop execution or disable HID. Finally, for external power, avoid exceeding 12V on Vin otherwise the regulator heats up, and don't forget that the 3V3 pin is limited to 50mA.

dev-embarque · 2026-09-19

I picked up the micro:bit v2 again for a sensor project. The nRF52833 SoC is solid, but watch out for the documented hardware pitfalls. The speaker is wired to P0, which makes using this pin for analog or touch input very complicated, even with speaker.off. Also, if you read multiple ADC inputs in succession, expect erratic jumps around 1024, an old CODAL issue. Fortunately, drop-and-flash via DAPLink remains super reliable for the school audience. Don't forget that only the KL27 is programmable for the interface; the rest is locked.

expert-microcontroleur · 2026-05-02

Thanks for the reminder, I lost an hour trying to understand why my readings on P0 were weird; it was the conflict with the speaker. On the other hand, I have an issue with serial speed. As soon as I go above 9600 baud, I lose characters. Is that normal? I thought BLE handled everything, but apparently the internal serial link is limited. And do I risk frying something if I power it via the 3V pin with a small LiPo battery? I don't want to be too strict with the components.

maker-debutant-42 · 2026-05-04

Yes, data loss above 9600 baud is due to the lack of hardware flow control between the KL27 and the nRF52833; it's officially documented. Regarding power on the 3V pin, absolute caution: it's the raw V_TGT rail. The documentation strongly advises against USB battery packs due to out-of-range voltages, but a LiPo must be regulated. Avoid exceeding 3.6V or reversing polarity, otherwise you can damage the chips. The current budget is limited to about 190 mA for accessories; don't push it.

bricoleur-silicium · 2026-05-08

Quick feedback on the MKR GSM 1400, which is unfortunately end-of-life. Its main strength remains its integrity: it's the only MKR board with HSPA, SMS, and voice calls. The ATECC508A chip is great for key security via BearSSL. However, beware of the major documented issue: USB power is insufficient for the current peaks of the SARA-U201 module. It is imperative to have a LiPo battery of at least 1500 mAh permanently connected, otherwise the board resets during transmission. Furthermore, the modem does not handle audio (no microphone), so the call examples are only useful for controlling state.

expert-arduino · 2026-08-19

I confirm the power supply issue, it's very frustrating when you're starting out. But my real question is about the MKRGSM library. I see it's frozen at version 1.4.2 and the board is EOL. With the gradual shutdown of 3G networks worldwide, has anyone been able to test if the 2G/GPRS fallback still works correctly? I'm worried about seeing my devices go offline soon. I also read that the bootloader ignores the SAMD security bit, so the code remains readable via bossac, which is problematic for a finished product if you store secrets.

maker-slow · 2026-08-20

For the 2G fallback, it really depends on your local operator, but the risk is real since some countries are also shutting down 2G. Regarding reading the flash via bossac, yes, it's a known unpatched bug because the board is abandoned. If you hardcode the SIM PIN in the code, it's a critical security flaw. To avoid I2C boot locks related to the BQ24195L PMIC, some people patch the library to disable strict initialization, but it's a hack. Honestly, for a new cellular IoT project, I recommend looking at newer NB-IoT or LTE-M boards; the GSM 1400 is becoming a technical dead end.

hacker-0x1 · 2026-08-24

Feedback after several months using the MKR NB 1500. The SARA-R410M-02B module is solid for global LTE-M/NB-IoT, and the ECC508 is a real security plus. But watch out for documented issues: the MKRGSM library remains unstable (issue #66), and the RTS/CTS flow is not enabled by default (issue #689), which causes heavy AT data to crash. The power LED stays on when running on battery, an unnecessary power drain. If you are using MQTT, connection failures are often related to the PSM/keepalive interaction, not the board itself. Make sure your operator covers the supported bands before deploying.

expert-arduino · 2026-06-16

Thanks for the summary. I have exactly this issue with the modem freezing on soft restart. Do you use the hard reset via the RESETN line or secureShutdown? I had a case where I had to completely cut the power. Meanwhile, does the recent version of MKRGSM handle RAT selection (NB-IoT vs LTE-M) better, or do you still have to tinker? It annoys me to have to force a specific mode if auto-selection fails.

maker-trois · 2026-06-18

I confirm the LED issue. I put a switch on the PMIC_IRQ line to manage power consumption a bit better, but it's a hack. However, don't forget that the SARA-R410M needs an external antenna or a very good internal one depending on the installation. I had to move the board 20cm to go from 0 bars to a correct signal in a rural area. NB-IoT range is theoretically large, but in practice it depends a lot on the immediate environment.

solder-queen · 2026-06-19

Quick experience report on the MKR WAN 1300 now that it has been discontinued in favor of the 1310. The MKR format is really convenient and the Murata CMWX1 module does the job in EU868 or US915. However, watch out for known pitfalls. The frame counter issue that blocks transmission after 255 sends (issue #141) is very frustrating during testing. Also, the 2-minute hardware throttle is irreducible, which breaks fast polling schemes. Finally, if you are migrating, always run the firmware updater before using the MKRWAN library to avoid version errors. ABP management has also regressed with v1.0.15. It's a good board, but you need to read the GitHub issues before coding.

expert-arduino · 2026-07-20

Thanks for this clear summary. I just received my 1300 for a water level monitoring project. You mention the frame counter, but is the false failure of joinOTAA systematic or does it depend on the configuration? I read issue #139 but I'm not sure I understand if it's a bug in the library or the module. Otherwise, I plan to use an external battery, so no worries about the missing charger like on the 1310.

maker_loi88 · 2026-07-22

@maker_loi88 the false joinOTAA failure is frequent if you don't handle timeouts correctly, see issue #139. For the throttle, don't try to bypass it, it's serious in EU868. If you need more reliability and an integrated LiPo charger, the 1310 is better, but the 1300 remains functional if you update the firmware. Also watch out for the restart API which is not documented, issue #132.

hacker_99 · 2026-07-23

Hello everyone, I'm starting out with the MKR WAN 1310 for an outdoor temperature monitoring project. I followed the official tutorial for OTAA connection on a local network, but I keep getting stuck. The joinOTAA function returns an error saying something went wrong, even though my keys are correct. In the GitHub issues, there's talk of false positives with the current version of the MKRWAN library. Has anyone managed to work around this problem without downgrading the entire Arduino environment? I'm afraid it might be related to the EU868 frequency configuration.

maker-loi · 2026-07-02

Hi, this issue of false failure with joinOTAA is indeed documented in issue 139 of the MKRWAN repository. Before modifying your code, you must absolutely check the firmware version of your Murata module. On new boards, there is often a mismatch between the recent library and the pre-installed firmware, which causes the 'Firmware version mismatch' error or silent join failures. You need to run the firmware update example provided in the library before doing anything else. Once the module is up to date, the joinOTAA problem usually disappears. Also, be aware of the duty cycle imposed by the EU firmware, which prevents more than one transmission every two minutes; this can skew your loop tests.

expert-arduino · 2026-07-06

I confirm the point about the firmware; it cost me an afternoon. However, I'm encountering another more insidious issue: after about 255 successful transmissions, my board can no longer send anything, without any explicit error in the serial monitor. I've seen that this is a known bug related to the frame counter, see issue 141. It's very frustrating for long-term deployment. While waiting for a patch, I'm forced to perform a manual or scheduled reset regularly. Otherwise, the board is great for integration into standard MKR enclosures, but the dependency on Murata's proprietary firmware remains a hurdle.

gadget-hunter · 2026-07-10

Quick feedback on the MKR WiFi 1010. It's a solid board for secure IoT, thanks notably to the ECC508 crypto chip and the NINA-W102 module which handles Wi-Fi and BLE well. However, watch out for the classic pitfalls. If you have connection errors (code 255), it's almost always an obsolete NINA firmware. Remember to update it via IDE 2. Another crucial point for former Uno users: do not plug a 9V power supply into VIN. This board only accepts regulated 5V, otherwise you risk frying something. And don't forget that the ON LED turns off when running on battery, that's normal, it's wired to the 5V rail.

expert-arduino · 2026-08-23

Thanks for this info, it's exactly what I was looking for. I'm actually having an issue with Access Point mode. When I configure the board as SoftAP, my smartphone doesn't see it by name via hostByName, I have to hardcode the IP. Is this a known bug or a hardware limitation? I've read about name resolution issues in AP mode, but I'm not sure if it's fixed with the latest versions of the WiFiNINA library.

maker-debut · 2026-08-27

It is indeed a documented issue on the WiFiNINA library's GitHub tracker (issue #92). In AP mode, name resolution doesn't work like it does in station mode. For your project, I recommend keeping a static IP. Furthermore, if you use sensors on the I2C ports, note that there is a dedicated Eslov connector next to the standard headers, very handy to avoid soldering official modules. The board is small (61.5 x 25 mm), but don't be fooled by the size of the 3.3V GPIO pins: if you connect a relay directly, it won't work due to the 7 mA limit per pin. You need a transistor.

tech-hobby · 2026-08-28

Feedback on this Pi 2 Model B. It's a solid board for retro or light projects, but watch out for pitfalls if you're picking up old stock. The main strength remains the historic performance/price ratio with its 4 cores and 1 GB of RAM, more than enough for browsing or a small server. However, if you have a v1.2 revision with the BCM2837, keep an eye on the Ethernet MAC address. It changes at every boot because it isn't programmed at the factory, which breaks your DHCP reservations. You need to force a static MAC via smsc95xx.macaddr in /boot/cmdline.txt. Another common issue: without built-in Wi-Fi, you rely on a cable or a dongle. And with quad-core loads, don't underestimate the throttling algorithm at 85 degrees if the case is closed.

expert-raspberrypi · 2026-05-21

Thanks for the reminder about the MAC, I'd been struggling for two days with my NAS server changing IP every time it restarted. I added the line to cmdline.txt and it's sorted. However, I confirm the power issue. With a cheap micro-USB charger, as soon as I start a heavy compilation on all 4 cores, the board maxes out and I see the undervoltage lightning bolt on screen. If you use this board for anything other than a simple access point, invest in a proper stable 5V power supply. The polyfuse protects well but cuts everything off if you exceed the USB bus limits, and it's a pain to restart hot.

hackeur-du-vendredi · 2026-05-24

Quick question for the experts. I just picked up a Pi 2 v1.1 (so BCM2836) to set up a pi-hole. I see that ARMv7 support is disappearing from official distributions. Do you recommend sticking with an old version of Raspberry Pi OS, or are there alternatives like Alpine or Armbian that hold up on this specific 32-bit architecture? I'm worried that Wi-Fi via dongle won't be recognized correctly on recent kernels without the right firmware.

linux_nouveau · 2026-05-26

After several weeks of using the 3 Model A+, I confirm what the spec sheet implies. The 65x56 mm form factor is great for compact cases, and 5 GHz Wi-Fi is a real plus compared to older Model A boards. However, the 512 MB of RAM gets saturated quickly with a modern desktop. I had to reduce GPU memory to the bare minimum to avoid OOM crashes. Watch out for thermal management too: without a fan, throttling kicks in quickly under sustained load. The micro-USB port is fragile if you plug/unplug often. It's an interesting board for headless use, but demanding in terms of configuration.

expert-raspberrypi · 2026-05-17

Hi, thanks for this feedback. I'm hesitating to get it for a fixed home automation project. You say the single USB port is a problem, but does that mean I can't have both an external Wi-Fi dongle and a USB hard drive? Or is the internal Wi-Fi enough for most cases? I'm afraid of having to sacrifice a peripheral if the network is flaky. Plus, without Ethernet or PoE, I wonder if GPIO power is really stable over time.

maker-2024 · 2026-05-19

The single USB port is indeed the main downside. If you plug in an SSD, you can't add a Wi-Fi dongle, but luckily the internal Wi-Fi (802.11ac) is decent. However, don't expect to use a USB hub to connect multiple devices; it often causes dropouts due to the current limit on the micro-USB line. For GPIO power, it works but it's less reliable than a clean micro-USB input. I've had brown-outs with a GPIO cable that was too long. It's better to invest in a good certified 5V/2.5A power supply to avoid instabilities.

geek-du-sud · 2026-05-21

The Pi 3 Model B remains a solid reference, especially if you have the v1.2 model (BCM2837B0 with integrated heatsink) released in early 2019. The early models without a thermal heatsink heat up quickly: at 85°C, throttling is brutal and performance drops significantly, especially in a closed case. This is the major documented thermal issue. For power, don't skimp: the undervoltage detection threshold is 4.63V. With a micro-USB cable that is too thin or long, you will see the lightning bolt flash in the taskbar and SD card corruption. The recommended 2.5A is an absolute minimum if you connect peripherals. Also avoid saturating the USB 2.0 bus shared with the 100Mbit Ethernet; if you do intensive network transfers while copying files, bandwidth collapses. This is a physical limitation of the LAN9514 hub, not a software bug.

expert-raspberrypi · 2026-05-16

Thanks for the reminder about throttling. I indeed have a v1.1 (without the spreader) that becomes unusable in summer in its plastic case. I thought it was a fan issue, but it is indeed the die temperature. However, you mention Wi-Fi is only 2.4 GHz. I struggle to maintain a stable connection for audio streaming via the BCM43438 module when my neighbor uses their microwave. Is this related to Bluetooth/Wi-Fi coexistence on the same chip as indicated in the docs, or is it just the antenna power? I feel like the actual throughput is well below the theoretical 100 Mbits of the Ethernet, which forces me to stick to wired connections for heavy system updates.

maker_hobby · 2026-05-19

For your Wi-Fi issue, it is indeed the coexistence on the BCM43438 that is painful in noisy environments, not to mention that the shared USB 2.0 bus limits max throughput if you have other peripherals connected. If you want to keep the board for networking, wired remains the only reliable option, even though it caps at 100 Mbits. Another important point if you are starting out: beware of the 3.3V GPIO logic. Many Chinese 5V sensors can fry the pins if you don't use a level shifter. And don't forget there is no native ADC, so to read analog sensors, you absolutely need an external module like the MCP3008 on the SPI bus. The 1GB of RAM runs well in Lite, but if you try a full 64-bit desktop with Chromium, you will quickly hit the limits.

linux_tinker · 2026-05-20

Quick feedback on the 3B+. It's still a solid board at $35, especially thanks to the dual-band 802.11ac Wi-Fi and the 802.3af PoE header, which greatly simplify network deployments without a power outlet. The move to 64-bit is also noticeable. However, watch out for power consumption. The official documentation heavily emphasizes using a quality 2.5A power supply. I've seen unstable boards and SD card corruption with cheap micro-USB power supplies due to the undervoltage detection at 4.63V. Additionally, Ethernet is throttled to around 300 Mb/s over the USB 2.0 bus, so don't dream of true Gigabit. If you put the board in a closed case, the soft thermal limit at 60°C will quickly drop the frequency from 1.4 to 1.2 GHz. It's well thought out for safety, but it limits sustained performance.

expert-raspberrypi · 2026-07-19

Thanks for the reminder. I'm actually struggling to enable 5 GHz on my freshly installed 3B+. Despite the configured connection, I don't see any 5 GHz APs. Is this related to the country setting? I read somewhere that you had to edit a specific configuration file. Otherwise, I'll stick to 2.4 GHz, but I lose the main advantage of this board compared to the classic 3B. Is this a known bug or just a mandatory step I missed?

maker-debutant · 2026-07-22

It's not a bug, it's a regulation. Linux drivers block 5 GHz channels until the country code is correctly defined to comply with local standards. You must ensure that the country parameter is properly set in your wpa_supplicant file or via the Raspberry configuration tool. Without this, the radio module remains officially disabled on this band. Once configured, you should see speeds rise towards the advertised 100 Mb/s. Also remember to check your power supply with a multimeter if you experience dropouts, as 5 GHz draws a bit more from the available power.

linux-tinkerer · 2026-07-26

Overall review of the Pi 4 Model B. The switch to PCIe for USB 3.0 and native GbE changes everything on the network side; it's true gigabit unlike the USB bottleneck on the 3B+. However, watch out for the power supply. If you have a revision 1.0 or 1.1, USB-C cables with an e-marker chip won't work; you absolutely need a 'dumb' cable or the official PSU. Power consumption can climb to 1.2A under stress, and the total budget for USB peripherals is capped at 1.2A, which is very tight. Thermal management is also more aggressive: no soft limit like on the 3B+, it throttles directly at 85°C. Get a fan or a large heatsink, otherwise you lose performance under sustained load.

expert-raspberrypi · 2026-05-06

Thanks for the reminder about the power supply. I just struggled with my version 1.2. I was using a multi-port USB-PD charger, and as soon as I plugged my phone into another port, the Pi would reboot. Apparently, PD power supplies renegotiate the voltage when a new device is connected, which cuts power to the Pi. It's better to use a dedicated 5.1V 3A PSU. Regarding micro-HDMI, I had black screen issues with cheap adapters. You need certified 4K@60Hz cables, otherwise it doesn't work, especially in dual screen.

maker_du_42 · 2026-05-10

+1 on the heat. With the C0 stepping, I find it heats up a bit more than the B0 at equivalent frequency, although it is more stable overall. For 5GHz Wi-Fi, don't forget to configure the country code in /etc/wpa_supplicant.conf, otherwise the channels remain blocked by regulations. It's silly, but I wasted an hour looking for why 5GHz was invisible. And avoid the 1GB model for desktop use, it's really too tight; aim for at least 4GB to be comfortable.

linux_gamer · 2026-05-12

Quick feedback on the Pi 5 after a few months of use. It is undoubtedly a performance leap: we get the 2 to 3x CPU/GPU boost announced compared to the Pi 4, and the dual 4Kp60 changes everything for the desktop. The new power button and the RTC are real quality improvements. On the other hand, it runs hot. Without the Active Cooler, you will throttle at 85C on any sustained benchmark. The RP1 architecture is interesting but watch out for pitfalls: the PCIe port is disabled by default if no HAT+ is detected (remember to set dtparam=pciex1). And above all, do not count on your old Pi 4 PoE HAT, the header has changed, you have to buy a new one. Standby power consumption is also a surprise if you do not set POWER_OFF_ON_HALT=1 in the EEPROM, otherwise it still draws 1.4W.

expert-raspberrypi · 2026-08-22

Thanks for this feedback. I confirm the point about the power supply, it is the main trap. I had connected my Pi 5 to a standard 30W multiport charger and I had USB drops as soon as I plugged in an SSD. You absolutely need the official 27W (5V/5A) to have 1.6A on the USB ports, otherwise it is limited to 600mA globally. And no, PPS is not supported, which is a shame considering most modern chargers use it. It solved my peripheral issues that were desynchronizing at boot when I added another device to the hub.

maker-du-35 · 2026-08-26

Quick question for RP1 experts: I am migrating scripts from a Pi 3 and it is breaking everywhere. The old direct libraries on BCM2835 no longer work because the GPIO has moved to the RP1 chiplet. I read that you need to migrate to gpiozero or libgpiod. Are the hardware PWM pins (12/13/18/19) still just as stable via these new libs? And for the RTC, I put a CR2032 coin cell but the docs say charging is disabled by default, so no need to solder a wire to enable charging if I just want to keep the time when it is off?

gpio_zero · 2026-08-27

Review of the Model A after several months of use in an embedded project. The concept is brilliant for the $25 price, especially for applications where Ethernet isn't needed. The full USB bandwidth is a real plus compared to the Model B, but watch out for power management. With only one USB port, plugging in a Wi-Fi dongle and a keyboard requires a powered hub, otherwise the polyfuse trips and the board undervolts. The 256 MB of RAM is also very limited today, forget about heavy distros. For the USB gadget with g_ether, be aware that bugs persist regarding MAC address assignment; the host may see a random address. This is a known friction point documented on the firmware tracker. Otherwise, the reduced power consumption is ideal for closed enclosures.

expert-raspberrypi · 2026-07-20

Thanks for this review. I confirm the polyfuse issue; it's frustrating when you plug in a small unpowered hub to test a keyboard. However, regarding sound management, I got lost at first. You need to understand that the analog jack and HDMI don't work simultaneously by default; you have to force the output via vcgencmd or configure the boot. It's a classic confusion on first power-up. Has anyone managed to stabilize the network gadget mode without having this random MAC address issue?

maker-bleu · 2026-07-22

Regarding the MAC address on g_ether, it's unfortunately an old problem linked to the BCM2835. There is no miracle software solution; sometimes you have to play with the module options at startup, but it remains finicky. As for the rest, if you want to avoid hub hassles, gadget mode in storage or HID keyboard mode is more stable than network gadget on this board, as it puts less strain on the complex USB network stack. Also remember to check your micro-USB power supply; the Model A is sensitive to voltage drop if the cable is too thin, even without a hub.

linux-pi-user · 2026-07-25

Quick feedback on the Model B+ after a few months of use in a home automation project. The form factor is really the major asset here: the 40-pin connector and the 4 USB ports set the standard for all subsequent Model B versions, which greatly facilitates current hardware compatibility. However, watch out for bandwidth: the 4 USB ports and Ethernet share a single 480 Mbps LAN9514 port. In practice, if you plug in a keyboard, a USB drive, and have the network active, real throughput collapses. Don't count on this bus for fast external storage. The 512 MB of RAM is also a hard ceiling: for headless use or a lightweight interface, it works, but avoid heavy graphical environments. For those upgrading from an older model, the 26-pin era expansion cards no longer fit mechanically, and you must leave the ID_SD and ID_SC pins free to detect HATs.

expert-raspberrypi · 2026-10-01

Thanks for this feedback, it confirms my doubts about network performance. I just received my B+ for a basic media center project. You mentioned that the micro-SD port gave some trouble at first? I've read stuff about card detection issues. Is that still current or has it been fixed by recent firmwares? I don't want to spend hours debugging if it's a known but resolved bug.

maker_hobbyiste · 2026-10-04

Hi, to add regarding power supplies: watch out for undervoltage. If your power supply is marginal, the polyfuse blows or you get brown-outs that crash the system when you plug in too many peripherals. Since everything shares the bus, a power-hungry USB drive can be enough to destabilize the whole setup. Regarding SD card detection, recent firmware versions have significantly improved stability via sdhost settings, so if you have an up-to-date image, it should normally be fine. However, there is no integrated WiFi/Bluetooth, so plan for an external dongle that will eat up an already saturated USB port.

electro_nov1ce · 2026-10-04

Back on the Model B Rev 1: it's a historical piece, but you have to be aware of its electrical flaws. The strong point remains the hardware H.264 1080p decoder for $35, which was revolutionary in 2012. However, watch out for polyfuse F1: a current spike on the USB blows it and the board no longer boots correctly, with symptoms of undervoltage. Sometimes you have to desolder it or bypass it, as indicated in the eLinux docs. Furthermore, early revisions have a diode D1 that drops the voltage, making the power supply unstable with weak chargers. If you have dropouts, check this point before throwing the board away.

expert-raspberrypi · 2026-08-03

Thanks for the reminder about F1, I have exactly that issue. My board only boots if I plug in a powered hub, otherwise the red LED blinks. I read that you need to desolder the fuse, but I'm too scared to do it. Regarding D1, is it present on all Rev 1 boards or only some? The datasheet says it's 'unverified', so I suppose you have to look at the PCB. Otherwise, Ethernet is really limited due to sharing the USB 2.0 bandwidth, which is frustrating for apt updates.

maker-du-35 · 2026-08-06

For D1, look near the micro-USB power connector. If you see a diode, you can remove it to gain a few hundredths of a volt, useful with long cables. The real problem is the 256 MB of RAM and the lack of I2C pull-ups on header P1, which forces you to add external resistors if you want to connect sensors. And don't forget that MPEG-2 codecs are not enabled without buying the license keys. It's a collector's board now, support is virtually non-existent.

linux-pi-legacy · 2026-08-07

Back on the Model B Rev 2. This is the board where the design really stabilized before the move to the B+. The jump to 512 MB of RAM for still $35 is a game changer for desktop use, it changes everything. H.264 1080p decoding is still as solid as ever. However, watch out for the ECN variants. The Rev 2 lost its mounting holes, which is a nightmare for cases of that era. And don't forget that the MPEG-2 and VC-1 keys are still paid. For overclocking via config.txt, it works well if the power supply keeps up, but the 85-degree thermal limit remains in effect. A cult card but fragile.

expert-raspberrypi · 2026-08-08

I confirm the issue with the mounting holes, it's unbearable to find a suitable case without doing shaky modifications. I had to improvise standoffs. On the other hand, I have a weird issue with the F1 polyfuse. As soon as I plug in an external hard drive and the USB wifi key at the same time, the green LED blinks and it reboots. I read that you need to bypass F1, but I'm afraid of frying the board. Has anyone managed to stabilize the 480 Mbps USB bus without modifying the circuit, or is it inevitable? The D1 diode on this 2012 series also scares me regarding voltage drops with my slightly long cables.

maker_toujours_courant · 2026-08-09

The shared bus issue with the LAN9512 is real. As soon as you do file transfers over the network and read an SD card, speeds collapse well below the theoretical 100 Mbps. It's the bottleneck of this generation. Regarding F1, if you have dropouts, it's often a sign of underpowering, not necessarily the fuse itself. Try a short, thick micro-USB cable first. SD card corruption happens quickly if the process cuts out due to micro power drops. Always keep a backup on the PC. That's the price to pay for having Made in Wales at this price.

linux_papy · 2026-08-09

I'm coming back to the classic Nano to clarify some points that are often misunderstood. It's true that the form factor is unbeatable for breadboard prototyping, with its 45x18 mm allowing you to fit everything without cluttering the circuit. The full capability of the Uno is there, with the bonus of analog inputs A6 and A7 exposed via the TQFP package. However, don't count on the 3.3V pin to power an ESP8266 module or a power-hungry sensor: with only 50 mA available, you will systematically trigger a brown-out during radio transmission. For programming, the DTR behavior via the FTDI FT232RL is also a frequent source of lost first characters if you send a config string at startup, because the board resets when the serial port opens.

expert-arduino · 2026-07-06

Exactly, and if you add clones into the equation, it becomes a puzzle. I received a board sold as official that used a CH340 chip instead of the FTDI, which forced me to look for specific drivers on the WCH-IC website. The worst part is that the Mini-USB connector gave out after about fifteen insertions, a real design flaw for regular use. I should have planned for an external connector or soldered cables directly to avoid this mechanical fragility. Has anyone else managed to stabilize the serial connection with the low-cost versions without having to change the USB cable every time?

hacker_minimaliste · 2026-07-10

Thanks for the details on the 3.3V, I didn't know the current was so limited and my Wi-Fi module was restarting in a loop. For the serial port issue, I also suspect the generic Windows driver is blocking communication with clone boards. I don't have a power jack, so I'm forced to stay plugged in via USB or solder to VIN, but watch out for the 7-12V range which is more restrictive than on the Uno. If I go a bit over, what exactly do I risk regarding the internal regulator?

maker_debutant · 2026-07-14

After a few weeks of using the Nano ESP32, I confirm that it's a beast for the Nano form factor: 8 MB of PSRAM and 16 MB of flash is rare. Native USB-JTAG debugging is a real plus compared to classic boards. However, watch out for boot traps. If you see two serial ports (USB and DFU), always choose the USB port to upload; DFU often blocks uploads from the IDE. And on Linux, without the correct udev rules, you'll get libusb_open errors during debugging. It's documented, but it surprises newcomers coming from the Arduino Uno.

expert-arduino · 2026-09-09

Thanks for the reminder about the ports! I had exactly this issue at the beginning, it cost me an hour. Another thing that tripped me up was the complete absence of a 5V pin. Coming from Uno/Mega boards, I was plugging my 5V sensors directly, thinking the converter would handle it. Result: nothing works when powering via VIN (6-21V), because the 5V isn't regulated, it's just passed through from USB. You need to plan for an external power supply for 5V modules or stick to 3.3V. It's a significant mindset shift compared to older Arduinos.

hobbyiste-tinkering · 2026-09-13

I confirm the easy brick if you touch the bootloader. I made a mistake flashing with esptool to erase the entire flash and lost the factory DFU bootloader. The board stopped responding to normal commands and I had to follow the Arduino support procedure to reinstall it. Before that, I also had weird USB connect/disconnect loops when switching between tools. The double-tap reset button trick often helps regain control, but it's frustrating. Make sure to use the 'Arduino ESP32 Boards' package and not Espressif's, otherwise you won't have any drivers.

maker-codeur · 2026-09-14

Review of the Nano Every. It's clearly the logical evolution of the classic Nano: 48KB of flash and 20MHz vs 32KB and 16MHz, which changes everything for heavy sketches. The physical pinout compatibility is a real plus for existing shields. However, watch out for the pitfalls: PWM on pin 11 is gone (no more OC0B), so if your code used analogWrite(11), it silently stops working. Additionally, the default I2C is now on the dedicated SDA/SCL pins (22/23) and no longer on A4/A5. If you plug in a standard I2C shield without rewiring, you won't get any communication. The USB module is not programmable like on the 33 IoT boards, which prevents bricking the board but limits options. Overall, great size/price ratio for modern 8-bit.

expert-arduino · 2026-09-01

Thanks for the reminder about pin 11! I spent two hours trying to figure out why my motor controller wasn't responding, thinking it was a power supply issue. Reading the docs, I saw that PWM pins are limited to 3, 5, 6, 9, 10. It's annoying when recycling old Arduino code. Regarding I2C, does the Wire library automatically handle the switch to the secondary port on A4/A5 if you force the init, or do you absolutely need to solder jumpers or change the pins in the code? I don't want to end up with bus conflicts if I use both ports.

maker_bricoleur · 2026-09-03

For I2C, you need to check the megaavr lib, but generally the primary port is indeed on the dedicated pins. The most annoying thing is the servo library or certain RF drivers that use timers different from the megaavr core. I had to update several libs that were running on my old Nano. Otherwise, the headerless format is great for integrating into tight enclosures; under 5g it's unbeatable. Just make sure you have a tool to solder cleanly; the B-side is flat and component-free, but the pads are small.

hobbyiste_avr · 2026-09-06

Follow-up on the NanoPi R5S after a few months. The concept of a router with 2x 2.5GbE (RTL8125BG) and 1x GbE WAN is solid, and the M.2 NVMe slot changes everything compared to the SD card on the R4S. However, watch out for early pitfalls. 2.5G performance was mediocre at launch (CNX measured ~1.85 Gbps Tx), but recent firmwares have fixed this via interrupt optimizations. Under mainline, the WAN port was broken for a long time: you absolutely need a kernel including the gmac support and reset-pin fixes (merged April 2026). If you are using a kernel between 2023 and 2026, check that phy-supply is properly defined, otherwise there is no link. Finally, don't forget that the USB-C power supply must be PD (Power Delivery): non-PD fast chargers cause boot delays or complete failures.

expert-pi-like · 2026-08-06

Thanks for this summary. I confirm the power supply issue: I lost an afternoon trying to understand why it didn't boot consistently with an old standard 5V/2A charger. I had to switch to a 12V PD charger for it to be stable. On the other hand, I have a question about debugging. The UART header requires 1.5 Mbps, which is high. I have a classic CP2102 converter, it caps at 921600. Did you manage to access the boot console with something else? I'm afraid of getting stuck at the bootloader if I have to reflash via Maskrom, knowing that the OTG port is on the USB-A and not the USB-C, which is counter-intuitive.

hacker-du-coin · 2026-08-07

For USB-UART, the CP2102 is often sufficient if you force the speed in the terminal (putty or minicom), but it drops characters at 1.5 Mbps. A recent FT232H or CP2102N is more reliable. Otherwise, for reflashing, if you have an HDMI screen, it's simpler. The remaining real pitfall concerns the LEDs: under recent kernels (6.17+), the netdev triggers have been removed from the DT. So don't count on the LAN/WAN LEDs blinking to see traffic if you are on a very up-to-date distro, it has been removed compared to the vendor FriendlyWrt images. It's a detail, but it helps with physical diagnosis.

linux-router-01 · 2026-08-08

Hello everyone. I've spent quite a bit of time on the Nicla Sense ME (ABX00050) and I wanted to clarify a common point: it doesn't have a BMI088. The set is indeed BHI260AP, BMM150, BMP390, and BME688. Also, watch out for the documentation conflict; the site mentions BLE 4.2, but it's actually 5.0 via the ANNA-B112. It's a powerful board with its 2 MB of flash and embedded AI, but getting started is tricky. Programming via the SAMD11 is finicky; if the bridge crashes, the board becomes invisible to the IDE. I also encountered the bug where the upload fails if the path contains a space. Don't blindly trust the ADC; the reference is 1.8V, not 3.3V.

expert-arduino · 2026-07-21

Thanks for this feedback, it confirms my doubts. I just had the board become invisible via USB after a power outage. I had to reflash the bootloader following an old tutorial, but it's far from intuitive. Regarding the sensors, I'm using I2C slave mode with a Portenta, but I'm experiencing intermittent host hangs. Have you encountered the issue where the board cuts off the ESLOV power after a minute of inactivity? I had to add a regular small ping in my loop to prevent the LDO from completely disabling itself.

maker-sensor · 2026-07-22

Yes, the LDO timeout is a classic trap; you must use BHY2.setLDOTimeout if you want to keep the ESLOV active. As for me, I'm struggling with the BSX fusion calibration. The orientation sensor (ID 70) often returns 0.000 at startup and takes a while to stabilize. It's frustrating when it's intended for precise gesture tracking. Is there a specific sequence to force recalibration without having to reinitialize everything? The autonomous mode is great for the 2 MB memory, but BLE connectivity via ArduinoBLE remains unstable for me.

algo-piou · 2026-07-23

Review of the Nicla Vision after several months of use. The 22x22mm format is impressive for embedded integration, and the power of the dual-core STM32H747 (M7 480MHz + M4) allows for running fairly responsive vision tasks. However, beware of documented pitfalls. The compilation bug with the Blink_Nicla.ino file is still present: the definition of Mode in RGBled.h conflicts with mbed, which breaks compatibility if you use InterfaceCAN. Another critical point: internal RAM is limited. The camera buffer does not exceed QVGA (320x240) without external SDRAM, and the board does not have any. If you are hoping for HD, it's a dead end. The battery life is good, but make sure to check your schematics for the LiPo power supply.

expert-arduino · 2026-09-18

Hi, thanks for this very clear review. I am currently stuck on the RTC issue. I read that the calendar resets on every hard reset because the bootloader forces LSI instead of LSE. This is really annoying for logging timestamped data in standalone mode. Is there a clean workaround via Arduino code, or do you have to flash a custom bootloader? I would prefer not to touch the fuse bits if possible. And regarding the camera, are the artifacts in the capture examples fixed in the latest libraries?

maker_bob_42 · 2026-09-19

Regarding the RTC, no, there is no clean software solution in the standard IDE because the MCUBOOT bootloader is configured with lse_available=false. Your only reliable option is to flash a modified bootloader or use a feature that hard-codes the clock source correction, but that is risky. As for the camera, the frame glitches (endianness/serial) in CameraCaptureRawBytes remain an open issue on GitHub since 2022. I worked around it by increasing the serial read delays, but it's a hack. The board remains excellent for embedded ML thanks to the IMU sensor, but image handling remains limited by this internal RAM.

vision_hacker · 2026-09-21

Back on the nRF52840 Feather. It's the go-to board if you want BLE with CircuitPython, as it's the only common SoC with enough RAM and native USB. However, watch out for hardware pitfalls. If your bootloader is older than v0.6.1, recent UF2 updates like CircuitPython 8.2.0 can brick the board. Always check INFO_UF2.TXT before flashing. Another critical point: the SPIM3 bug on battery. If you power via USB, it works, but on battery, the default SPI object doesn't work correctly due to the absence of VUSB. You need to use Adafruit's workaround which ignores the first allocated object. Finally, keep in mind that the SoftDevice has priority over everything, so hard real-time is impossible with BLE enabled.

expert-microcontroleur · 2026-04-25

Thanks for these details, it saves me hours of debugging. I just struggled with SPI on battery; I thought it was a Python code issue, but it was indeed the hardware. On the other hand, I'm stuck on the Rev D schematic. I read the errata regarding the silkscreen D5 vs A6, but I'm not sure I understand the impact. If I wire according to the silkscreen, what exactly is the risk? A short circuit or just an inactive pin? And for the red LED, I saw the confusion between pin 3 and 13 in the docs; I ended up using LED_BUILTIN to avoid depending on physical numbers—is that the right approach?

maker_bricoleur · 2026-04-27

Regarding the D5/A6 errata, it's a labeling error on the PCB, not an electrical routing defect. The signal is where it should be, but if you rely on the silkscreen text to identify pin A6, you will make a mistake and solder in the wrong place. Always use the technical documentation or schematics rather than the silkscreen. Regarding the red LED, yes, LED_BUILTIN is the only reliable constant that works on both versions, as pin numbers change between the Express and the Sense. Also avoid cheap USB cables, which are often charge-only; this prevents the bootloader mode from triggering, which is very frustrating when trying to flash via UF2.

dev_embedde · 2026-04-29

Welcome back to the ODROID-C2. It's a 2016 beast but it holds up well for networking. The strengths are real: the real Gigabit Ethernet port (RTL8211F, no USB bridge) changes everything compared to the Pi 3s of that era, and H.265 4K decoding via the Mali-450 is efficient for multimedia. However, watch out for documented pitfalls. The microSD slot is limited to 100 MHz in mainline (SDR50/100 only), so forget about fast UHS-I, it lags. The eMMC module is an absolute must. Also, power consumption is demanding: you need a proper 5V/2A via the 2.5x0.8mm barrel jack. Micro-USB power supplies often cause brown-outs. Finally, the GPU is not supported in mainline without proprietary blobs, so the desktop is slow on current Armbian/DietPi. It's a network card or media center, not a modern desktop.

expert-pi-like · 2026-04-29

Thanks for this summary. I'm actually having an issue with the power supply. I was using a standard USB charger via the OTG port to save space, but it reboots randomly as soon as I plug in a Wi-Fi dongle. Do you confirm that the OTG port is too marginal for USB peripherals? I've seen that the GL852G hub consumes quite a bit. I'll switch to the barrel jack as you say, but I'm looking for a compact power supply that really delivers 2A under load.

maker-bricoleur · 2026-05-02

Yes, the OTG port puts the hub and USB ports on the same power line, which is very unstable with peripherals. For Wi-Fi, don't forget there's nothing integrated, you need a USB dongle that uses up one of the 4 ports. If you want stable networking, the GbE is perfect but check your cables carefully. Another point: the thermal sensor is not supported in mainline (U-Boot says 'No' for the thermal sensor), so there is no visible software throttling. Monitor temperatures physically if you use it in a closed case. It's a 'legacy' board now, but Armbian maintains it well.

linux-meson-fan · 2026-05-04

Review of the ODROID-C4. The value for money is real: at 50 dollars with the heatsink included, you get real GbE, 4x USB 3.0 and above all an eMMC socket, something nonexistent on the Pi 4. ARMv8 crypto extensions provide enormous gains in encryption. On the other hand, watch out for the pitfalls. No built-in Wi-Fi, you have to pay 8.90 dollars for the mSOTA+ module. The trickiest part concerns the voltages on the 40-pin header: everything is 3.3V except the ADC inputs limited to 1.8V. An analog wiring error can fry the SoC. Finally, the CPU frequency is confusing because some default images remain locked at 1.5GHz while the chip supports 2.0GHz. Check your cpufreq setting.

expert-pi-like · 2026-09-07

Thanks for the reminder about the ADCs. I confirm the frequency issue. I used an official Hardkernel image and had to use scripts to reach the 1.908GHz max allowed by the kernel. The factory-provided 4.9 kernel is legacy and causes problems with modern modules. For my 24/7 server use, I switched to Armbian. Power consumption is very low, around 1.8W at idle, which is perfect for a passive case. The only flaw is the lack of HS400 on the main kernel, so the eMMC is capped at HS200. If you are looking for raw storage performance, you have to accept this limitation or stick with the vendor.

maker-sol · 2026-09-11

Small question regarding the hardware section. You mention that USB OTG does not provide power. I tried powering it via a USB-C cable to test a portable setup without a wall outlet, and indeed, it doesn't boot. The barrel jack is absolutely mandatory. Regarding the 5BK Wi-Fi module at 8.90 dollars, is the range decent? I'm afraid the mSOTA+ format is too small for a good antenna. Otherwise, I confirm that passive cooling is more than sufficient as long as you don't run heavy tasks continuously.

hobby-tweak · 2026-09-14

A quick review of the ODROID-M1 after a few months of use. The undeniable highlight remains storage: the M.2 NVMe port on PCIe 3.0 x2 is really fast, reaching the advertised 1600 MB/s, which crushes anything you can do on a Raspberry Pi CM4. It's a real asset for a NAS or mini-server. The presence of native SATA (careful, 5V only, so no 3.5-inch drives without an external PSU) and eMMC offers rare flexibility at this price. However, beware of official images that still run on a 4.19 BSP kernel. If you want mainline for Panfrost or modern drivers, you have to compile it yourself or look for community builds. The SPI Boot Select switch is also a classic trap: if you leave Petitboot active, booting from SD/eMMC doesn't behave as expected. It cost me an evening of debugging.

expert-pi-like · 2026-09-21

Thanks for this feedback. Do you confirm that the form factor isn't Pi-like at all in reality? I've seen the dimensions (122x90mm) and the heatsink sticking out, which will be a problem for my existing case designed for a Pi 4. Furthermore, the lack of built-in WiFi/Bluetooth is a bit frustrating; you're forced to sacrifice a USB port or buy the Hardkernel dongle. Is mainline support stable today for audio, or do we still have the RK817 pincmux issues you mentioned?

makershadow · 2026-09-23

Correct regarding the dimensions, the heatsink is 123x100x19mm, it doesn't fit in any standard Pi case. For audio, the I2S1 pincmux bug that killed the RK817 codec on mainline was recently fixed (October 2025), so if you have an up-to-date kernel, audio works. But on old images or unpatched kernels, you'll get pinctrl errors and no sound. For WiFi, yes, it's USB only, no internal solution. The big advantage remains stability once the right kernel is installed: the Mali-G52 GPU runs well via Panfrost once you leave 4.19 behind. Just make sure to check your PSU voltage, they recommend 12V 2A via the DC jack, not USB-C which is absent here.

expert-pi-like · 2026-09-26

Experience report on the ODROID-N2. It's a workhorse on the CPU side with its 4x A73, but watch out for the pitfalls. The pinout conflict between the SPI NOR and the eMMC D4-D7 lines is real: if you want to boot from SPI flash, you absolutely must modify the device tree to switch to a 4-bit bus and check the position of switch SW1, otherwise nothing works. Another historical black spot: the GPU gap. For years, the Mali-G52 was limited to the framebuffer without serious X11/Wayland acceleration, until Panfrost arrived. Under Armbian, don't forget to blacklist the simpledrm module, otherwise it takes control of the display before Panfrost and you lose acceleration. Otherwise, passive cooling is excellent, especially on the N2+ Rev-C which holds 2.4GHz without thermal issues at 35°C ambient.

expert-pi-like · 2026-07-12

Thanks for the reminder about SPI, I lost an evening because of the switch being in the wrong position. I have a specific question about stability. I've read notes about random freezes after 24h+ of operation under load. Is this related to cpufreq management? I was suggested to force the governor to 'performance' to avoid OPP instabilities on the big.LITTLE, but that seems like a brutal solution. Have you noticed this on your recent N2 or N2+ boards?

hacker-du-geek · 2026-07-16

Yes, confirming regarding the governor. On my N2 with a recent image, setting the governor to 'userspace' or 'performance' stabilized long sessions. The problem often comes from the switching between the A73 and A53 cores. On the other hand, avoid storage on microSD if possible, get the eMMC, the latency difference is huge. And if you're doing media center work, 4K H.265 decoding is perfect, it's really its strong point for the price, although the lack of integrated WiFi is annoying depending on usage.

maker-serein · 2026-07-17

After several years in a cluster, I can confirm the XU4's strengths: USB 3.0 throughput and Gigabit Ethernet (880 Mbps real-world) remain unbeatable for the price of an ARMv7 board. Compatibility with Armbian 6.6 images is excellent. However, beware of the thermal trap: without active cooling, throttling on the A15 cores is immediate, losing 16% of performance compared to the cooled version. And above all, never plug a 5V UART adapter into the console header; it's 1.8V with no IO protection, and I've seen boards fry instantly. The Mali T628 GPU supports OpenCL 1.2 but declares itself as two distinct devices, which breaks some compute scripts.

expert-pi-like · 2026-05-26

Hi, quick question for those using it as a NAS. You mention the shared USB topology. I have two SSDs on the USB 3.0 ports and I get the feeling their performance drops severely when I do simultaneous network transfers. Is this related to the integrated GL352x hub or to the fact that the Ethernet controller is also on an internal USB bus? I'm worried that the bandwidth is too limited for software RAID.

maker-artisan · 2026-05-29

That is exactly the problem documented by mdel and tkaiser. The GbE monopolizes one USB 3.0 host, and the two external ports share the other host via the hub. So if you saturate the Ethernet, you already have an impact, and if your two SSDs are on the same host, they share the same line. For serious NAS use, it's better to avoid saturating both USB ports simultaneously if you want to maintain decent speeds. The HS400 eMMC is much more stable for the system, while USB for external storage can quickly become the bottleneck.

linux-tinker · 2026-05-30

Back after a few weeks with the Opta. The micro-PLC certification is real, it changes everything compared to a classic MKR. The direct 24V inputs are super handy, no more need for conditioning cards. However, be careful: USB-C doesn't power the relays, you absolutely need 12-24VDC on the terminal blocks for the power part. I also noted the I1/I4 conflict for interrupts, it's impossible to use them at the same time, it cost me an evening of debugging. Remember to add external termination resistors for RS-485 otherwise it bugs out. The OPC UA module is well present in the examples, it's a real plus for industry.

expert-arduino · 2026-08-25

Thanks for the feedback. I'm a beginner and I'm a bit lost with the core. Are you talking about the migration to Zephyr? Currently I'm using arduino:mbed_opta and I'm afraid of breaking my scripts by updating. Is the official documentation clear on future compatibility? And regarding BLE, I read that the hardware is 5.1 but the firmware is 4.2, does this cause concrete issues for simple home automation or is it transparent?

hobb-iste-77 · 2026-08-28

For BLE, if you're doing simple sensor/timer stuff, the 4.2/5.1 difference is often invisible, unless you need specific long range. The real trap is the relay lifespan: 10k cycles at 10A resistive. If you switch inductive loads (motors, valves) without external protection, you'll burn the contacts quickly. You need fuses and possibly varistors. Don't count on the internal protection, it's minimal. The datasheet is explicit about this, don't get fooled thinking it's all-terrain industrial without precautions.

maker-indus · 2026-08-30

Experience report on the Orange Pi 3B. The Pi 3B form factor with the integrated M.2 slot is really the highlight for repurposing an existing case. However, be aware that the slot is limited to PCIe 2.1 x1, so don't expect Gen4 SSD speeds; it's capped at around 500 MB/s theoretical. I also noticed that I2C on the header pins (pins 3/5) didn't work natively before the November 2025 patch. If you are running a kernel between 6.11 and 6.17, you absolutely need to create an overlay, otherwise your sensors won't respond. Handling the two hardware revisions (v1.1 and v2.1) is also a trap: if you flash the wrong device tree, Ethernet or WiFi might remain silent. Remember to check your silkscreen.

expert-pi-like · 2026-07-05

Hi expert-pi-like, thanks for this feedback. I'm actually just starting out with a v2.1 and I struggled with booting. I thought my NVMe module was dead, but while reading the Armbian tickets, I saw there was an issue with the overlay prefix and that sometimes two different U-Boot images were needed depending on whether you were booting from SATA or NVMe. Did you have this double image issue, or have recent versions of Armbian fixed it with PR #10896? It cost me an afternoon trying to understand why it booted via SATA but not via NVMe with the same config.

maker-du-93 · 2026-07-09

To add to this, if you switch to mainline (not the vendor kernel), be prepared to hunt for WiFi firmware. The AP6256 module (BCM43456) requires specific brcmfmac43456-sdio files. I had the WiFi card disappear after a kernel update because the NVRAM file corresponding to the xunlong match was missing. You need to check in /lib/firmware/brcm/. Also, a small clarification: the spec sheet says 5V/3A for the USB-C power supply. Don't try to go lower; with an NVMe SSD and a few USB peripherals, a 5V/2A power supply might be insufficient, even if no official minimum is clearly stated for light booting.

linux-ouin-ouin · 2026-07-12

On the Orange Pi 5 Plus, the classic pitfall is the power supply. There are two identical USB-C ports, but only the one near the RJ45 powers the board. The other is for data. Also, avoid generic PD chargers: the official spec requires 5V/4A. A bad adapter causes dropouts when everything is plugged in. On the other hand, the two 2.5GbE RTL8125BG ports on PCIe are excellent for routing, and the M.2 M-Key slot on PCIe 3.0 x4 is a real plus for speed. Just remember active cooling, the thermal thresholds are low.

expert-pi-like · 2026-05-28

Thanks for these details on the power supply. I received mine and I'm stuck on audio. I have no sound in the headphones with the latest Armbian Mainline image. Is it a defect in my board or a known issue? I've checked the physical connections several times, nothing changes. However, for the network part, I confirm that booting from NVMe via the M.2 adapter works well, it's smooth. But if I use the SD card for testing, be careful not to exceed 128 GB, the documentation specifies this and it can be surprising.

maker-newbie · 2026-05-30

That's normal for audio, don't look any further. Headphone detection was inverted in the Device Tree up to Linux 6.17. You need to flash an image based on a recent kernel for it to work. As long as you are on an earlier version, even if you plug in the headphones, the system doesn't see them correctly. It's a fixed bug, but if you use slightly older images, it comes back. For the rest, if you want Wi-Fi, don't forget that there is no embedded module, you absolutely need to buy an M.2 E-Key module like the AP6275P.

linux-hacker-99 · 2026-05-31

Experience report on the Orange Pi PC after several months of use. The price-performance ratio remains unbeatable for a quad-core A7, especially with the Armbian images which are well maintained. The CSI connector and integrated microphone are appreciable bonuses at this price. However, beware of the classic trap: the micro-USB OTG port is not for powering the board. I've seen beginners fry their power supplies by trying to plug in a standard cable. You must imperatively use the 5V DC jack. Furthermore, the Ethernet is limited to 100 Mbps, which is frustrating if you host heavy services. Thermal management is also tight without a fan under sustained loads, the H3 heats up quickly.

expert-pi-like · 2026-06-02

Thanks for these details on power supply, I thought I could save space by using micro-USB like on other boards. I have a question about the GPIO header: you mention Raspberry Pi compatibility. Do official HATs work out-of-the-box? I would like to connect a small SPI screen. I read that some power pins could send 5V or more if misconfigured, is that a real risk on this version or was it mainly on previous models? I don't want to fry my peripheral before even testing the code.

maker-du-44 · 2026-06-05

Regarding the header, the mechanics are compatible but the electrical implementation requires vigilance. As expert-pi-like points out, the official documentation is sometimes confusing. On my version, I had to check each pin with a multimeter. Some pins labeled VPP can provide a voltage higher than 3.3V depending on the boot configuration or the settings of the SY8106A PMIC. Don't blindly trust Raspberry Pi tutorials. For OTG, I confirm what expert-pi-like says: it is only for gadget mode or OTG peripheral, never for power. If you want to use the IR receiver, make sure the driver is properly compiled into your Armbian image, it is present but sometimes disabled by default in certain legacy builds.

linux-tinkerer · 2026-06-06

Review of the Boron BRN404X. The cloud promise is kept, the TLS handshake is smooth. But beware of documented physical pitfalls. The U.FL connector is extremely fragile, don't play around unplugging it often, you risk destroying the radio. Same for the micro-USB port which breaks off easily. Critical point: power management via the EN pin. If you power external GPIOs when the board is off, pull-ups can prevent a complete shutdown or reset. You must use an open-drain MOSFET. Finally, check your LiPo polarity before plugging it in, the datasheet insists on this, a reversal can be fatal. It's a good board for rapid prototyping thanks to FeatherWings, but demanding in terms of integration.

expert-microcontroleur · 2026-07-03

Thanks for the reminder about the EN pin, I spent two weeks trying to understand why my board never really slept, staying around 0.6 mA instead of the expected ULP values. It was exactly your scenario with an external high level. Another issue encountered: after an OTA update on Windows 11, the serial port disappeared from Device Manager. I had to change the cable and reinstall the Particle drivers. It's annoying when you're in the middle of debugging. Have you noticed any LiPo charging issues with recent versions of Device OS? I've read threads about a silent charge cutoff after version 1.5.0, I want to make sure it's fixed before validating my sealed enclosures.

maker_bidouille · 2026-07-05

Regarding charging, it seems stable on the latest releases, but keep a close eye on the TI PMIC temperature. For sealed enclosures, keep in mind that there is no castellated version for the full Boron, only for the E-Series modules. If you move to production, plan for a socket or switch to SMT modules. And don't forget the fragility of the JST connector on the battery side, reinforce it if the cable moves. Network management is great for North America, but if you're targeting Europe, know that LTE Cat M1 certification is not done, you'll need to use third-party solutions or manually check supported bands as not everything is enabled by default in the firmware.

iot_embedded_fr · 2026-07-06

Review of the Photon after a few months. The simplicity of the Particle cloud is real, the Soft AP setup works well, and the STM32F205 @120MHz architecture offers good computing power for this price. Peripherals like CAN and the 2 DACs are rare at this level. However, beware of two classic pitfalls. First, don't forget that the A5/D2 and A4/D3 pairs share PWM timers, so you only have 7 independent outputs, not 9. Second, power supply is critical: a bad USB cable causes brown-outs during Wi-Fi transmission peaks. You really need a stable source of around 1A. The 3V3 delivered by the board is very limited to 100mA, don't count on it to drive power-hungry sensors without an external LDO.

expert-microcontroleur · 2026-04-30

Thanks for the details. I'm prototyping a small connected object and I'm stuck on a standby power consumption issue. I read in the datasheet a value of ~80 microamps in deep-sleep, but on my first unit, the battery drains in 1 day, whereas on two other identical ones, it lasts 30 days. Is this a common defect or a bad setting? I tried turning off the LEDs, but the current remains high on the 'bad' board. I also read that the Bluetooth coexistence pads are unusable, so I can't rely on them to diagnose a leak there.

maker-debutant-42 · 2026-05-01

The sleep current variance issue is documented by others, as shown in the thread on the official forum where three Photons had totally different behaviors. This can come from components in the power chain or from the board itself. Also check that you haven't left the RGB LED active or floating GPIOs. Regarding the brown-outs mentioned by expert-microcontroleur, if you power via VIN with long wires, add an electrolytic capacitor and a 5.1V zener as recommended, otherwise you risk voltage spikes that damage the board. And if you deploy a fleet, watch out for the end of support for older Device OS versions, stay on the 2.x LTS branch.

tech-sauvage · 2026-05-04

Experience report on the Pico after several months of use. The strengths are real: the $4 price is unbeatable for a 133 MHz dual-core M0+ (certified at 200 MHz on later revisions) with 264 KB of SRAM. Hardware freedom is total, everything is open source. However, beware of documented pitfalls. The ADC converter is mediocre without software processing: it suffers from an inherent offset of about 30 mV related to the internal 3.3V reference and SMPS noise. You often have to force PWM mode on GPIO23 or subtract an offset via a ground channel to get correct measurements. Furthermore, the chip has no FPU, so all floating-point calculations are emulated in software, which significantly slows down complex operations. It's a fantastic board for IO via PIO, but not for heavy numerical processing.

expert-raspberrypi · 2026-08-15

Hello expert, I'm new to the Pico and I'm stuck on a power supply issue. I read that pins GP26 to GP28 are not 5V tolerant, which makes sense, but I also saw a note in the datasheet about a reverse diode to IOVDD. Does this mean that if I apply a voltage to these ADC pins while the board is off, I risk powering the 3V3 rail and damaging the rest? I want to connect a 5V sensor via a voltage divider, but I don't want to fry the board in case of hot-plugging.

maker_tinker · 2026-08-16

@maker_tinker Yes, that's exactly it. The datasheet is clear: applying a voltage to GP26-GP29 when the Pico is unpowered can back-power the 3V3 rail, which is dangerous for the MCU. For your 5V sensor, use a clean voltage divider with resistors, but make sure your external circuit cannot inject current into the board when it is off. Otherwise, a series MOSFET on the sensor's power supply is the safest solution. Regarding the ADC, also confirm the datasheet trick: set the SMPS to PWM mode via GPIO23 if you want reduced noise, otherwise the default PFM mode creates spikes that interfere with your low-level readings.

pio_wizard · 2026-08-20

After a few weeks with the Pico 2, the performance jump is real thanks to the RP2350, especially for those who want to test RISC-V (Hazard3) without breaking the bank. However, be careful if you bought a board before mid-2025: the RP2350-E9 erratum regarding GPIO Bank 0 is indeed present. I had lines stuck at 2.2V in input mode, and I had to add 8.2kΩ pull-down resistors to stabilize them. This is fixed in steppings A3/A4, but make sure to check your revision. Another classic pitfall: if you enable secure boot, you lose access to the RISC-V cores; it's all-or-nothing. And don't forget that for USB Host mode, you need to supply 5V to VBUS, otherwise it won't work.

expert-raspberrypi · 2026-04-26

Thanks for the feedback. I'm actually running into an issue with inaccurate ADC readings; the values fluctuate quite a bit with temperature. Do you confirm this is related to the internal SMPS power supply? I read there is an offset of around 30mV. Is using an LM4040 on ADC_VREF mandatory for reliable analog sensing, or is simple software filtering enough?

maker_debutant · 2026-04-28

Software filtering doesn't handle the physical offset caused by the ADC current pulling on the SMPS reference. The datasheet clearly recommends an external reference like the LM4040 if you want precision. Also, be careful: if you use a version of MicroPython earlier than 1.24.0 or Pico SDK < 2.0.0, it won't even flash, since support was only added recently. It cost me an afternoon trying to figure out why my RP2040 scripts weren't working.

codeur_embed · 2026-05-01

Experience report on the Pico 2 W. The $7 price is unbeatable for having Bluetooth Classic and BLE 5.2, but watch out for hardware pitfalls. If you have an incoming batch, check the silicon revision of the RP2350. Early versions (E9) suffer from current leakage on GPIO Bank 0 when pins are in input mode, which can clamp levels to 2.2V. External pulldown resistors under 8.2kOhm are required. This is fixed in the A3/A4 steppings announced in July 2025. Another major point: LED blinking. Forget your usual Pico code on GP25. Here, GP25 is the Chip Select for the WiFi module. If you toggle GP25, you cut off the radio. Use the cyw43_arch_gpio_put function for the LED. It's counter-intuitive but documented in the picow_blink examples.

expert-raspberrypi · 2026-08-04

Thanks for the reminder about GP25, I lost an hour trying to understand why my radio module stopped responding as soon as I touched the LED. I have a question about voltage measurement. I want to monitor my battery via the ADC, but I read that GP29 is shared with the WiFi SPI clock. Can I read the voltage at any time? I feel like I'm getting random values when the WiFi is active.

makers_bidouilleur · 2026-08-04

Exactly, it's a known hardware collision. GP29 carries both the VSYS/3 signal for the ADC and the SPI clock for the wireless module. You can only read the voltage when no SPI transaction is in progress. If you try to read while the radio is communicating, you get garbage. In the SDK, you absolutely must wrap your ADC reads within the cyw43_thread_enter and cyw43_thread_exit functions to secure access. Otherwise, the read is invalid. That's the price to pay for integrating the radio and voltage measurement on so few pins, but it requires rigor in the code.

expert-raspberrypi · 2026-08-05

I've been using the Pico W since its release in 2022. The price/features ratio is unbeatable with Wi-Fi 4 and classic Bluetooth 5.2 for $6. However, watch out for hardware pitfalls: GPIOs 23 to 25 are reserved for the radio module, so code intended for a standard Pico doesn't work directly. The most annoying point remains the VSYS voltage measurement via the ADC on GP29, which is corrupted as soon as the Wi-Fi communicates because the lines are shared. You have to read the voltage only when the SPI bus is inactive, which complicates real-time battery monitoring. The user LED is also wired to the radio chip, not the RP2040, which forces you to initialize the wireless driver just to blink a diode.

expert-raspberrypi · 2026-09-29

Thanks for the reminder about the reserved GPIOs. I actually lost an hour this morning because a MicroPython script inherited from a standard Pico wasn't responding due to the LED wired to WL_GPIO0. Regarding the ADC, I also noticed an offset of about 30 mV in my sensor measurements. The documentation mentions a 200 Ohm filter on the ADC reference that causes this, but for critical applications, have you tested adding an external reference or modifying the filter suggested in the datasheet? It seems critical for the accuracy of the data sent via Wi-Fi.

maker-bidouille · 2026-10-02

ADC accuracy is indeed limited by source impedance, as indicated in the datasheet. For Bluetooth, note that support is uneven depending on the environment: CircuitPython offers little native BLE support compared to the C SDK with BTstack. If you are doing BLE Central, make sure your MicroPython version is recent, as implementations evolve. Finally, do not neglect the 14x9 mm exclusion zone around the antenna; a metal box or a nearby plate seriously degrades signal range.

electron-libre · 2026-10-03

Back after several months on the PINE64. The spec sheet confirms what many experienced at the beginning: the Kickstarter delays and mediocre production quality documented by Hackaday. The real trap remains Ethernet. Don't let the confusing names fool you: the PINE A64 base is 10/100 Mbps (RTL8201), not gigabit. Only the A64+ has the RTL8211. I've seen people open tickets for an 11 MB/s link thinking they had the Plus version. Another critical detail: the vcc-phy rail requires a startup delay. Without the 100ms workaround in the DTS, the link is unstable. On the positive side, it's a solid brick for Armbian and mainline support is excellent. Just use the barrel jack; micro-USB drops too much voltage and causes SD corruptions.

expert-pi-like · 2026-09-22

Hi expert-pi-like. I recovered an old 512 MB card that was lying around. The docs say it's limited, but I thought I could run a small web server on it. Do you confirm that Debian and Arch are the only viable options? I tried booting a standard Android image but it doesn't work. I also suspect an issue with my SD card; I read that it's the number 1 problem. Should I invest in eMMC or stick with SD if I stay on minimal Debian?

makers_toy · 2026-09-23

Exactly regarding memory: with 512 MB, Android or Ubuntu Touch won't run properly; you need the 1 GB version or more. For storage, the SD card is the Achilles' heel of this family, as highlighted by the official documentation with its counterfeit detection tools. A slow or fake SD card will make even Debian unstable. The optional eMMC is a good idea if you want reliability, but be careful to verify the module's compatibility. If you stick with SD, get a reputable brand and use the testing tools cited in the docs. Also avoid OTG gadget mode; the mainline DTS forces the port to host, so no USB gadget without a patch.

expert-pi-like · 2026-09-27

I'm moving to the Portenta H7 for an industrial project. The dual-core setup is real: I run C++ on the M7 and MicroPython on the M4 via RPC, and it works well. However, watch out for Wi-Fi. As documented in issue #382, if the AP goes down, WiFi.begin isn't enough. You absolutely must call WiFi.end before reconnecting, otherwise it gets stuck. I also had firmware corruption after a botched update, saved at the last minute by the FlashFormat sketch. The price of 120.80 euros is justified by the SE050C2 security and the DisplayPort graphics part, but the docs are sometimes vague regarding core migration.

expert-arduino · 2026-05-03

Hi, I'm just discovering the board. When you mention Wi-Fi corruption, did that happen upon delivery or after an update? I saw that the source sheet mentions that the official docs docs.portenta.io are no longer responding (DNS error), which is annoying for migration from the other core. Regarding the graphics part, did you manage to display the LVGL interface on a screen via the USB-C port without struggling with drivers? That's my main hurdle currently.

maker-hobby-99 · 2026-05-04

@maker-hobby-99 For the display, it works but you need to read the LVGL tutorial on docs.arduino.cc, it's not plug-and-play. For Wi-Fi, expert-arduino is right about the WiFi.end hack. The issue is that if you lose the config, you also lose access to certain complex network functions once the module fails, unless you planned for FlashFormat from the start. It's a bit annoying for a finished product costing 120 bucks. Connection stability on the Murata module remains the weak point compared to dedicated solutions.

debug-user-01 · 2026-05-05

I've spent quite a bit of time on the Portenta X8 recently. The concept is impressive: 9 cores in 66x25mm, real Linux with Docker containers and the RPC bridge to the M7 for Arduino. It's powerful. However, the docs have changed drastically (docs.portenta.io is dead, everything is on docs.arduino.cc) and there are pitfalls. I had to hunt down compilation errors like QSPIFBlockDevice not found (issue #529) and ensure the m4-proxy service is running via journalctl, otherwise RPC doesn't work (issue #960). Don't count on ADB support without configuring docker permissions with newgrp. It's a card for pros, not beginners.

expert-arduino · 2026-05-14

Thanks for this very comprehensive feedback. I'm running into exactly the same serial issue via the Breakout Carrier, impossible to get the board to communicate with my GPS modules, it stays silent (see issue #584). Did you find a trick for serial port routing? Also, the CAN bridge scares me: I read there's a TX blocking bug when the SPI queue is full, does that confirm your tests? I'm still hesitating to order given the price of 223 euros and this firmware instability.

maker-iot-01 · 2026-05-15

Regarding CAN, I confirm that the SPI queue bug is present if you don't use the latest firmware, but even in 0.0.3 it remains fragile under load. For the Breakout serial, make sure you aren't using pins reserved by active carriers or USB debug. The catch is that the documentation is sparse regarding pin conflicts between the different carriers (Max, Mid, Hat). If you need strict real-time, the RPC bridge using msgpack adds non-negligible latency. I ended up bypassing RPC for certain critical tasks by using shared registers, but it's not properly documented anywhere.

dev-embedded · 2026-05-17

Experience report on the Pro Mini after several projects. Its main strength remains its minimal size for semi-permanent installations, thanks to the absence of pre-soldered connectors. However, watch out for classic pitfalls. If you get 'stk500_getsync', first check that you have selected the correct model in the IDE (5V/16MHz vs 3.3V/8MHz). The error often comes from the

expert-arduino · 2026-04-22

I confirm this synchronization issue with a CP2102 adapter. I spent an evening searching, then realized I hadn't crossed the TX and RX lines. With SparkFun's FTDI Basic, it works directly, but when soldering wires to a different USB-UART module, you need to swap RX to TX and vice versa. Another annoying point, the clone board I bought didn't have the capacitors for auto-reset. So, I have to press the reset button manually just before uploading for the bootloader to accept the data. It's doable but less convenient than with an Uno.

maker_bricoleur · 2026-04-23

Also be careful with power management if you use the RAW input. The linear regulator heats up quite a bit when stepping down from 12V to 3.3V, especially if the project draws some current. For the 3.3V/8MHz versions, I noted issues with internal oscillator drift on some older batches, which disrupted serial communications. It was necessary to recalibrate the OSCCAL register to stabilize the link. If you go with a new board, check the fuses, as a bad Brown-out Detection setting can cause invisible boot loops without a debugger.

embedd_88 · 2026-04-25

Quick feedback on the Rock 3B. The 100x75mm Pico-ITX form factor with rear ports is really convenient for cases, and the 3 M.2 slots (NVMe, Wi-Fi, 4G) are a big plus. However, watch out for networking: on non-Radxa distros, the second Ethernet port is often dead due to an old bootloader. You need to flash a recent U-Boot (mainline or Radxa SPI) for both GMAC ports to work. That's the main downside. Otherwise, power management via USB-C PD is flexible, but the accessory catalog isn't always clear about compatibility, as CNX already noted.

expert-pi-like · 2026-06-22

Thanks for the reminder about U-Boot, I spent an evening figuring out why eth1 wasn't linking up under Armbian. Regarding touchscreens, I had the same issue mentioned on the forums: the GT911 overlay doesn't work well without tinkering with the INT pins. It wasted a lot of my time. Has anyone found a stable config for dual display HDMI + DSI without having to recompile the kernel? I'm hesitant to get the industrial edition if it means dealing with this many software headaches.

hobby-maker-88 · 2026-06-24

For dual display, avoid the official overlays if you already have GPIO conflicts, as it can be unstable as indicated in the known issues. For the rest, the Pico-ITX form factor is great but be careful: not all Raspberry Pi HATs are compatible, the pinout is only "mostly" compatible. Check Radxa's color code carefully before plugging anything in, otherwise you risk frying a pin. Wi-Fi is not included, so budget for the M.2 E-Key module as well.

linux-tinkerer · 2026-06-28

Quick feedback on the Zero 3W after several weeks. The Pi Zero 2 W form factor is great for compact projects, and the RK3566 with 8GB of LPDDR4 is decent for multitasking, but watch out for thermals. The chip is throttled to 1.6GHz instead of the usual 1.8GHz to avoid overheating on this tiny PCB. This is noticeable under sustained load. The biggest pitfall for me was the header pins. If you plan to use GPIOs 3, 5, 27, or 28, forget it: they have I2C pull-up resistors that make them unusable in standard GPIO mode, see the hardware interface doc. And don't forget that power supplies not exactly at 5V can fry the board. It hurts.

expert-pi-like · 2026-05-24

Hi, thanks for the heads-up about pins 3 and 5, I hadn't seen the note in the docs. I actually have a project where I wanted to put a small LCD on those pins to save space. If I have to change pins, are there enough GPIOs available elsewhere for a simple display? On the other hand, regarding Wi-Fi, I read that board revisions change the Wi-Fi chip. Do you have a Zero 3W V1.12I? I ask because I'm struggling to get stable 5GHz; the docs say you need to confirm with real testing depending on the firmware.

maker-du-weekend · 2026-05-26

For Wi-Fi, don't assume it's brcmfmac if you have the new V1.12I board with the BL-M8800DS2 module; the docs don't confirm clear mainline support for each revision. On my setup, I had to tinker with the firmware so that 5GHz would appear correctly, otherwise I was stuck on 2.4GHz. Also, to avoid the boot issue that shuts down on its own due to UART2 (pins 8/10) serving as the U-Boot console: don't connect anything to it unless you know how to do the workaround in /etc/default/u-boot. I almost lost my data because the device wouldn't boot anymore due to simple electrical noise on that line. Be careful with rsetup overlays.

linux-tinkerer · 2026-05-29

Hello everyone. I'm revisiting the rp2040-generic board. The PIOs are indeed revolutionary for bit-banging without touching the CPU, that's the real strong point. But beware of documented pitfalls. Errata E9 prevents direct booting in cache-as-SRAM mode via UF2; a workaround from RAM is required. Also, don't trust the raw ADC specs: with a real ENOB of 8.7, you have about 9 usable bits, not 12. If you're doing audio or precise measurements, plan for serious hardware filtering due to sensitivity to power supply noise. Finally, XIP is a double-edged sword: writing to flash pauses the code. Make sure to use the SDK helpers to avoid crashes during firmware updates. The dual-core is powerful but requires rigorous spinlock management.

expert-microcontroleur · 2026-06-21

Hi expert, thanks for this clear feedback. I'm starting out with the SparkFun Pro Micro RP2040. You mentioned noise sensitivity for the ADC. I plan to read a simple potentiometer for volume control. Are 9 bits enough, or do I absolutely need to filter? Also, I've seen discussions about clock glitching when changing the frequency. Do I need to be very careful if I want to slightly overclock above the default 133 MHz, or does the system handle it on its own? I wouldn't want to fry my board by tinkering with the clock registers without understanding the risk mentioned in the datasheet.

maker-debutant-42 · 2026-06-22

@maker-debutant-42 for your pot, 9 bits is fine for volume, but if you have background noise on your 3.3V line, it will show up. The clock glitch is real: the datasheet says the auxiliary mux can create glitches if you don't follow the official sequence. If you use MicroPython, avoid touching machine.freq during a critical task without knowing what you're doing. For overclocking to 200MHz, it works well at 1.15V core but it heats up. I had instabilities with errata E7 when using ROSC counters for precise microsecond delays. Use the standard system timer. PIO saves the day for exotic protocols, but it requires carefully reading the docs on timings.

pio-hacker · 2026-06-24

Feedback on the generic RP2350 boards. The architecture selector between Cortex-M33 and Hazard3 RISC-V at 150 MHz is genuinely useful and works without a hardware reset. However, watch out for the steppings. The A2 chips suffer from erratum RP2350-E9 regarding leakage current on the Bank 0 GPIO inputs. I've seen leakage currents around 120 microamps if the line floats near 2.2 V, which ruins button readings. This is fixed on the A3 and A4 since July 2025. Check CHIP_ID.REVISION. The other issue concerns erratum RP2350-E3 on QFN-60 packages where Non-secure permissions for the PADS are incorrectly applied due to a mapping problem. This complicates the use of TrustZone. If you're buying old stock, be vigilant about these two critical points.

expert-microcontroleur · 2026-05-25

Hi, I confirm the E9 issue on my RP2350 Stamp. I spent hours diagnosing why my analog inputs were being distorted by neighboring digital ones. By adding external pull-down resistors on each sensitive line, I stabilized the readings, but it takes up space and consumes energy. It made me doubt the reliability of the inputs. Have others encountered similar issues with the A2 versions? I didn't know there was a hardware difference visible in software via CHIP_ID. Thanks for the reminder about the steppings, I'll check my next orders.

maker-bidouilleur-42 · 2026-05-26

Interesting remark about the E9. For my part, I mainly use the Hazard3 RISC-V mode for vector calculation tasks and the dynamic switching is smooth. However, I haven't encountered the E3 issue on my Pico-compatible boards, but I suppose they aren't QFN-60? If you have a Pro Micro module, double-check the package. The chip prices are attractive, but early-life errata are not trivial for production. I'm waiting for mass availability of the A4 before switching a project to series production. Do you think software support for the M33/RISC-V switch is mature?

dev-embedded-riscv · 2026-05-27

Follow-up on the Lichee RV Dock. It's impressive for the price, especially with mainline Linux support progressing well. The D1 SoC is a true RISC-V with XuanTie vector extensions, which is historically cool, but watch out for known kernel errata (cache, PMU) that require specific patches via CONFIG_ERRATA_THEAD. The main strength remains the price and M.2-B modularity for swapping carrier boards. However, the USB-C issue is real: if you use a C-to-C cable, it doesn't work due to OTG detection on the CC pin. You either have to stick with A-to-C, or do rework with 5.1k ohm resistors on the CC lines by desoldering the diodes, which breaks the automatic switch. For the RTL8723DS Wi-Fi, forget about full mainline support; you need proprietary firmwares, often manageable via Buildroot.

expert-microcontroleur · 2026-06-24

Thanks for this detailed feedback. I just received my kit for $20.90. I haven't tried the rework yet; I'll stick to USB-A to USB-C cables for power and flashing. However, I'm stuck on the documentation: the wiki page sometimes mentions 1GB of RAM in a comparison table, while everywhere else it says 512MB DDR3. Has anyone actually verified the contents of their board? And for the display, is the small 1.14-inch SPI screen usable today, or is it still unclear as indicated in the known issues?

maker-debutant-42 · 2026-06-26

Regarding the RAM, the standard version of the Lichee RV module is indeed 512MB. The mentions of 1GB likely concern other SoM variants or wiki errors, so don't count on it for the base Dock. As for the 1.14-inch screen, it is still not natively supported; the note 'not able to display' is still current. If you want graphical display, aim for HDMI (but beware, no hardware video decoding in mainline, so avoid heavy videos) or the Display Shell extension module. With 512MB, avoid heavy environments; it runs well in console and for Python or Go scripts, but it's limited for anything else.

linux-riscv-fan · 2026-06-29

I finally took the time to dig into this board. On paper, it's a monster for audio with the CS43L22 and the PDM mic, and the argument of being under $20 for an F407 at 168MHz is hard to beat. The CubeF4 BSP for playback/recording is complete. However, watch out for the classic trap: on stock boards, the ST-LINK V2-A virtual serial port is not internally wired to the MCU's USARTs. Many beginners waste hours trying to figure out why there's no output on their terminal. You absolutely need to make a small wiring bridge to pins PA9/PA10 or use USB CDC via code. Otherwise, for pure audio dev, the DAC quality is decent for hobbyist use, but don't expect a HiFi system. The integrated debugger remains a big plus to avoid buying an external JTAG.

expert-microcontroleur · 2026-07-21

Thanks for this feedback! That's exactly the problem I encountered last week. I thought the ST-LINK was magically connected to the serial port, so I spent an evening checking my GPIO config without understanding anything. As a result, I had to solder two wires to connect the adapter's TX/RX to the MCU. It's a hack, but it works. Quick technical question: is the PDM mic management via I2S2 stable when also running playback on I2S3 at the same time? I'm afraid of bus conflicts or latency if I want to do real-time audio processing.

maker_du_samedi · 2026-07-24

To answer your question about I2S simultaneity, in theory the F407 handles the two independent channels very well, but the DMA configuration must be done carefully to avoid saturating the AHB bus. Regarding the VCP issue, it's a shame ST didn't wire it by default on this revision, especially since it's sometimes present on other Discovery boards. This forces you to modify the hardware or use specific USB libraries. If you want to avoid cables, look into the USB CDC implementation, but it consumes some flash and CPU cycles for the USB stack, which can impact your time budget for heavy audio calculations.

codeur_embedde · 2026-07-28

Experience report on the Blue Pill: it's the cheapest entry point into the ARM Cortex-M3 world at 72 MHz, featuring a real full-speed USB controller and a CAN interface, which is rare for this price. However, be absolutely wary of sourcing. As noted on Wikipedia, most boards now contain counterfeit Chinese chips. These fakes cause concrete problems: programming at 921600 baud is impossible, the system bootloader doesn't start, and the DMA generates phantom interrupts that block the code. Another classic pitfall is that the pull-up resistor on the USB D+ line is often 10k or 4.7k instead of the required 1.5k, making USB enumeration extremely unstable. You often have to replace the resistor manually.

expert-microcontroleur · 2026-08-07

I confirm the USB issue, but I also struggled with the blink. No matter how much I set PC13 to HIGH, nothing lit up. Reading the stm32-base documentation, I see that the LED is in sink mode, connected between VCC and the pin. So you have to write LOW to turn it on, not HIGH. It's counter-intuitive when coming from classic Arduino. So, does having a clone chip (like GD32 or others) change anything for use with the official Arduino core? I assume it affects USB stability given the clock or DMA errors mentioned above?

maker-debutant-01 · 2026-08-09

To answer your question about clones: yes, it impacts everything. GD32F103 chips are legitimate pin-compatible alternatives, but direct counterfeits of the STM32F103C8 are often buggy. For example, some don't support modifying CR1_ACK at the same time as CR1_PE on I2C, or crash if you cut the clock to the backup domain. For USB, if your enumeration fails, check the D+ resistor first before blaming the code. And watch out for power protection: the 5V pins are directly connected to USB without any protection. Never power via USB and an external source simultaneously, or you risk frying the board or the PC port.

electronicien-forum · 2026-08-12

The critical point currently on the Nucleo F401RE is the end of life of the mbed platform. If you follow old online tutorials, you will hit a wall because the online tooling has been dead since July 2026 and Mbed OS is no longer maintained upstream. You absolutely must migrate to Mbed CE to continue using this ecosystem. Despite this issue, the board remains a solid reference for its price. We still benefit from the Cortex-M4F at 84 MHz with FPU and DSP instructions, which is rare on cheap 64-pin boards. The embedded ST-LINK/V2-1 is also a real asset: it handles SWD debugging, the virtual serial port, and USB mass storage, which greatly simplifies development when you don't want to mess around with complex drivers.

expert-microcontroleur · 2026-08-04

Thanks for the alert about mbed, I thought I could follow a 2024 tutorial without any issues. So, if I want to avoid the migration to Mbed CE which seems complicated, can I stick with the Arduino STM32 core? I see that the datasheet mentions active CI support in 2026, but I wonder if the ST-LINK debugger is really that simple to configure or if there are pitfalls with USB drivers on Windows 11.

maker_debutant · 2026-08-07

For Arduino, it is very stable currently, the F401RE is well supported in the Boards Manager. No need to touch mbed if you stay on this IDE. The ST-LINK/V2-1 is generally recognized natively, but make sure you have the latest ST drivers if the COM port appears incorrectly. The advantage of the Arduino Uno V3 connectors and the ST morpho headers is that you can stack classic shields while having access to all GPIOs via the side pins, which is very practical for more exotic peripherals without buying another board.

bidouilleur_hardware · 2026-08-08

I've spent quite a bit of time on the NUCLEO-H743 for motor control projects. On paper, it's a beast: the STM32H743 MCU runs at 480 MHz with a double-precision FPU, and the 2 MB of RAM and 1 MB of Flash offer unparalleled comfort in the classic Nucleo range. The raw performance is real, the bus is fast, and it doesn't flinch under load. However, there's a major catch to consider right now: the board is officially obsolete (EOL). ST has discontinued the product. If you're starting a new industrial or long-term project, this is a real future supply issue. For pure hobby use or rapid prototyping, it remains very usable, but don't count on stock availability in two years. The ST datasheet confirms it; it's over for new direct orders.

expert-microcontroleur · 2026-08-09

Thanks for the feedback. The EOL aspect doesn't worry me too much for my personal use; I still find boards on second-hand marketplaces. However, you say the 2 MB of RAM are comfortable. I'm struggling to see the concrete benefit compared to cheaper boards. Have you encountered issues with specific peripherals related to this H7 architecture, or does it run like an F4 once configured via CubeIDE? I'm asking because I'm hesitating to upgrade just for the speed.

dev-embarque-99 · 2026-08-10

Oh wow, I just realized my board is end-of-life. I'm using it for a small audio data acquisition project. The 480 MHz are great for real-time DSP processing; honestly, I don't see any latency. However, if the board is EOL, will software support continue? I've read that driver updates might cease. If anyone has info on the future compatibility of ST tools with this H743, I'm interested. Otherwise, I'll have to migrate to another series, and that will cost me a lot in rewriting time.

maker_bricoleur · 2026-08-11

Quick feedback on the Teensy 3.2. It's a very powerful board with its Cortex-M4 and 16 DMA channels, ideal for audio via the Teensy Audio library or for driving LEDs with OctoWS2811, where the refresh rate is impressive. However, watch out for documented pitfalls. First, you have to solder the 32.768 kHz crystal yourself for the RTC to work, which is annoying out-of-the-box. Next, the internal 3.3V regulator is limited to 250mA external. If you plug in an ESP8266 or a power-hungry peripheral, it blows. Finally, the board has been End of Life (EOL) since late 2023 due to NXP chip shortages, so don't count on future stocks. Also check that you don't exceed 3.3V on pins A10 to A14, because unlike the others, they are not 5V tolerant.

expert-microcontroleur · 2026-09-09

Thanks for this summary. I indeed encountered the WS2812B LED issue. As you say, the 3.3V signal from the Teensy is too weak for the new LED strips, causing random flickering. I had to add a logic level buffer (like the 74HCT245) as recommended in the OctoWS2811 project documentation. Another point of attention I discovered while tinkering: if you use pin 13 as an input with an internal pull-up resistor, the orange LED lights up and biases the measurement because it is connected to this pin. You absolutely must avoid INPUT_PULLUP on pin 13 if you don't want fuzzy logic states. It cost me two hours of debugging this weekend.

maker-rgb-2024 · 2026-09-10

I confirm the audio noise issues if your I2S wires to the Audio Shield are too long; I had exactly the same phenomenon of crackling in the speakers. Regarding the end of life, it's frustrating because the 64k RAM capacity is starting to be tight for complex projects like Ornament and Crime migrated to the 4.x. But for USB MIDI or analog control, it remains very good. Just be careful if you upgrade to Teensyduino 1.41 or newer: the MIDI message format has changed (pitch bend in particular), so your old code risks not sending the correct values without modification. Make sure to read the compatibility section before recompiling.

audio-hacker-v1 · 2026-09-11

I just migrated an audio project from a Teensy 3.6 to the 4.0. The power of the Cortex-M7 at 600 MHz is impressive, especially for routing the audio shield with the dedicated library. However, beware of documented pitfalls: if you have an old Rev B shield, it won't work natively. You need to add wires and, most importantly, a 100-ohm series resistor on the MCLK line, otherwise it crackles or doesn't start. Another critical point: the ADC is disappointing for high precision. Paul Stoffregen confirms that we stay around 10 effective bits due to noise, and there is no AREF pin to change the reference. If your project requires fine analog measurement, plan for an external converter; the internal one won't suffice despite the 12 bits advertised on paper.

expert-microcontroleur · 2026-04-30

Thanks for the feedback on the shield; I hadn't noticed the MCLK resistor issue on older revisions. However, I'm stuck on a power supply problem. I tried powering the board via VIN 5V while the USB cable was plugged in for debugging, and I got weird disconnects. I read in the docs that you need to cut the pads underneath to separate VIN and VUSB. Is that correct? And is the 250mA limit on the 3.3V really strict? I added a small display that draws a bit more, and it sometimes restarts.

maker_bricolage · 2026-05-04

Yes, you were right to check. The datasheet is clear: VIN and VUSB are connected from the factory. If you power via VIN with USB plugged in, you risk current backflow to your PC or voltage conflicts. You must cut the pads under the board to isolate them if you use an external power supply. For the 3.3V, the 250 mA limit is a safety recommendation because the onboard regulator heats up. If you exceed it, the voltage may drop and cause brown-outs, especially if you also have peripherals on the I2C bus or GPIO pins. Also avoid drawing more than 4 mA per digital pin; the PJRC datasheet is conservative on this point compared to other docs. For your display, try disconnecting it or see if you can keep the total draw under 250 mA on the 3.3V rail.

expert-microcontroleur · 2026-05-05

Quick experience report after quite a bit of tinkering with the Teensy 4.1. It's a beast with its Cortex-M7 at 600 MHz (overclockable to 912 MHz if you manage the heat), but watch out for the classic pitfalls. The major downside is the total lack of 5V tolerance: unlike a Teensy 3.2, if you send 5V to a pin, you kill it. You need level-shifters everywhere. Second annoyance: the lack of a DAC. People coming from the 3.5/3.6 series are disappointed; you have to use I2S or the MQS pin for audio. And don't forget that the VIN and VUSB pins are linked: never power externally without cutting the pads under the board, otherwise you'll back-power your PC. The Ethernet part is great, but the RJ45 kit is DIY soldering, which is a pain.

expert-microcontroleur · 2026-09-28

Hi, thanks for the recap. I have a recent Teensy 4.1 and I'm stuck on the ADC. I expected 12 bits based on the docs, but I'm getting very noisy values. I read somewhere that this is normal? I tried analogReference but nothing happens. Is it a bug in my code or is it hardware? Because the noise is really present even with a clean power supply.

maker_du_dimanche · 2026-10-01

It's not a bug in your code, it's a documented hardware limitation. The datasheet specifies that although the hardware is 12-bit, in practice only 10 bits are usable due to electrical noise. So don't expect surgical precision without very heavy active filtering on the power supply and inputs. Regarding analogReference, the docs are clear: the range is fixed at 0-3.3V and the function has no effect. If you need more precision, you need to see if your signal can be conditioned externally or if you need to switch boards for critical analog use. As for the rest, the speed is insane, but watch the power consumption near 100mA at 600MHz.

expert-microcontroleur · 2026-10-02

Quick update on the Tian (A000116), which is unfortunately nearing end-of-life. If you pick up a second-hand board, watch out for the model: there are no official variants, but some batches intended for non-certified markets have WiFi disabled. It's a real trap. Regarding documentation, note that the Yun's Bridge library does not work here; you must use Ciao. I've also noted inconsistencies in the official datasheet, particularly regarding the AR9342 CPU frequency (533 or 560 MHz depending on where you read it) and the analog inputs. The dual-core concept with the SAMD21 and Linux remains interesting for power consumption control via GPIO 32, but the abandonment of the GitHub repositories makes driver maintenance complicated.

expert-arduino · 2026-08-31

Thanks for the reminder about buying pitfalls. I actually have a practical question about the connectors. I'm trying to plug in a standard SPI shield that only has a standard connector and no pass-through ICSP. From what I gathered reading the notes, the Tian's SPI bus is only accessible on the original ICSP, which means my shield won't work without manually adapting the wires. Is that correct? And regarding power, if I plug in everything (WiFi, USB host, Linux processor), do I risk dropouts with a standard USB hub, or is a dedicated external power supply of more than 600 mA on Vin absolutely necessary?

maker_bricoleur · 2026-09-01

To answer your question about SPI, yes, it's confirmed by the official documentation: the SPI pins are not on the standard digital headers, you have to go through the ICSP. For power, the typical consumption announced is 470 mA at 5V, but the peak with WiFi and USB enabled can cause voltage drops if your USB hub is limited to 500 mA. I've had brownouts with an old hub. Another blocking point if you're coming from classic Arduino AVR: watch out for PWM conflicts (the 4/10 and 5/12 pairs are mutually exclusive) and above all, opening the serial monitor resets the board via 1200 baud detection on the USB CDC port. It's very confusing at first when you just want to log data without restarting Linux.

guy_du_forum · 2026-09-01

Hi everyone. I'm back on the Uno R3, still the reference board despite the arrival of the R4. The big advantage remains the ATmega328P MCU in a socket: if you fry the chip, you replace it for a few euros without changing the whole board. However, beware of two recent pitfalls. First, the serial connection via the ATmega16U2 often causes a loss of the first characters due to the automatic DTR reset when opening the port. Second, if you power via the barrel jack, avoid high voltages outside the recommended 7-12V range, otherwise the linear regulator heats up a lot. Don't forget that the VIN pin has no protection against reverse polarity, unlike the jack. It's a classic cause of irreparable failures.

expert-arduino · 2026-04-26

Thanks for this reminder about the regulator heating up. I actually have an issue with cheap clones I bought. On my official board, everything works fine, but on my three clones, I have USB driver issues that keep crashing. Is this related to the fact that they don't necessarily use the same USB chip as the official 16U2? I've read that component variations change driver behavior, but I'm not sure if I understand whether it's just a software or hardware issue. It bothers me because I want to prototype a project and I fear my components won't be reliable for the future.

maker-debutant · 2026-04-29

Exactly, maker-debutant. Clones often use a different USB-to-UART chip or a different regulator. If the drivers crash, check if your clone uses a CH340 or an FTDI instead of the 16U2, as the drivers are not the same. For the DTR reset, if you lose the first characters, add a small delay in your code after initialization or use the wait function. For power, always design for 20mA per pin, even if some older datasheets say 40mA, it's safer to avoid frying the microcontroller. Current official specs lean towards 20mA.

expert-arduino · 2026-05-01

The switch to the Uno R4 Minima is generally positive for raw power: the 48 MHz Cortex-M4 and 256 KB of flash are a game changer compared to the ATmega328P. The 12-bit DAC and 14-bit ADC are excellent for precise measurement without adding external components. However, beware of the major pitfall mentioned in the specs: the GPIO current limit has dropped to 8 mA, compared to 20-40 mA on older models. If you connect LEDs or relays directly as you would with an R3, it might not work or could damage the board. You absolutely must use transistors or drivers. The USB-C format is appreciated, but the lack of radio remains a clear strategic choice compared to the WiFi version.

expert-arduino · 2026-06-14

I confirm the 8 mA issue; I spent an afternoon figuring out why my buzzer was inaudible. It's frustrating when you're used to standard UNO shields. On the other hand, physical compatibility is there; shields plug in without any problems. I have a specific question regarding code portability: I used a motor control library that directly manipulates AVR registers (TCCR). On the R4 Minima, the core is ArduinoCore-renesas. Is there a sufficient abstraction layer, or do I need to rewrite the code using native Renesas APIs? It seems critical if we want to migrate old projects without redoing everything.

maker-99 · 2026-06-17

To your question, moteur-99, no, there is no magic bullet for AVR registers. If your library uses avr/interrupt.h or modifies TCCR registers, the code will not compile or will not work. You must imperatively migrate to the analogWrite functions and the timers exposed by the Arduino IDE for the Renesas core. To avoid surprises regarding resolution, make sure to check the analogWriteResolution call, as the default behavior has changed with the arrival of the true 12-bit DAC. Otherwise, if CAN interests you, don't forget that an external transceiver is mandatory; the board only has the controller. It's a good choice for automotive or industrial applications, but it adds a wiring step.

silicium-bleu · 2026-06-20

Quick update after a few weeks with the Uno R4 WiFi. The strengths are real: the 12x8 matrix is super handy for immediate visual feedback, and the Qwiic connector greatly simplifies sensor wiring without soldering. However, watch out for the documented pitfalls. The Qwiic I2C bus is on a secondary line (IIC0) at 3.3V, so you absolutely must use Wire1.begin instead of the usual Wire. If you're used to classic Unos, this comes as a surprise. Also, never connect a 5V device to the ESP32-S3 header; it is strictly 3.3V and you risk frying the board. This is a point often overlooked but crucial.

expert-arduino · 2026-09-11

Thanks for the warning about the ESP header voltage! I almost made a mistake trying to read a sensor powered at 5V via this connector. Luckily, I had read the docs just in time. On the other hand, I have an issue with Wi-Fi. I flashed a basic example, but the connection doesn't always work on the first try. I read that the ESP32-S3 firmware must be present and compatible. Have you had any problems reflashing the radio module? It seems like a bit of a heavy procedure just to connect to a network.

maker_debutant · 2026-09-12

Regarding Wi-Fi, it's true that managing the two chips adds a layer of complexity. Sometimes you need to reset or check that the firmware is up to date via the Serial Monitor. The other tricky point you mentioned is the 8 mA limit per GPIO. With the LED matrix on, if you connect a servo motor or a power-hungry relay to a pin, you quickly exceed the limit. On older AVR Unos, we had more headroom. Here, if you exceed 8 mA, you risk damaging the pin. I recommend using an external driver for anything motor-related, even though the board is great for rapid prototyping thanks to USB-C and the 24V VIN.

bricoleur_78 · 2026-09-13

Review of the Yun. It's a strange beast: an ATmega32U4 glued to a Linux AR9331. The concept is great but the reality is painful. The major issue remains Bridge.begin which blocks indefinitely if the sketch starts before Linux is ready. I spent hours trying to understand why my code never ran, when the problem came from the boot sequence. Add to that memory leaks on YunClient sockets after ~256 connections, sometimes making the board unusable without a physical reset. The 16 MB of flash are also too tight for anything other than the bare minimum. Before buying it, know that the Bridge repo is archived and that Arduino acknowledged the initial security weaknesses, fixed only on the Rev.2. It's over, don't count on updates.

expert-arduino · 2026-08-29

I confirm the startup blocking issue, it's very common. I tried migrating to a standard OpenWRT image to bypass the heaviness of the Arduino distribution, fatal mistake: the bridge no longer works at all and Bridge.begin remains blocked. You must restore the specific Arduino packages for the SPI/UART link with the ATmega to come back to life. For those who insist, think about the microSD via YunDiskSpaceExpander, otherwise you run out of space very quickly. But honestly, for a critical IoT project, I strongly advise against this card today, as the ecosystem has been completely abandoned.

maker-flux · 2026-08-31

Quick feedback on the Pi Zero. The concept is brilliant: for $5, you get a real Linux on a 65x30 mm board. Idle power consumption is very low, around 0.1 A, which allows for battery-powered projects or wearables without overheating like a Pi B. The USB OTG gadget mode is also very powerful for emulating serial or network. However, watch out for the pitfalls. The main documented issue is the complete lack of undervoltage detection. If your power supply is a bit weak, the board crashes without warning, unlike other models. So you need to carefully design the power supply algorithm or monitor the voltage via software. As for the rest, the single-core BCM2835 SoC is more than sufficient for I/O or scripting, but don't dream of heavy multitasking.

expert-raspberrypi · 2026-06-29

Thanks for the reminder about undervoltage. I just spent an evening figuring out why my sensor project kept crashing regularly. I thought it was a software bug. Reading the docs, it's clear that without hardware detection, it's up to you to manage it. So, I added a small voltage divider connected to a GPIO to continuously read the battery level. It's a hack, but it works better. The mini format is really great for integrating into narrow enclosures, but soldering the GPIO connectors is a nightmare if you don't have a fine-tip iron. The price remains unbeatable for beginners who just want to light up an LED via Python without breaking the bank.

bricoleur_77 · 2026-06-30

I confirm the point about power consumption. It's true that for embedded use, it's unbeatable. However, the single-core ARM1176J quickly shows its limits as soon as you launch a somewhat complex graphical interface or web browsing. I mainly use it headless via SSH or in gadget mode to send serial data. The fact that it's manufactured in Wales by Sony is an interesting detail regarding its origin. Just a small question: is the gadget mode stable in composite Ethernet + mass storage, or is it better to choose a single role to avoid USB address conflicts? I haven't dared to test the full composite mode yet.

linux_fan_simple · 2026-07-03

Experience report on the Zero 2 W with the RP3A0. It's impressive to see the SiP integrating the BCM2710A1 die and 512 MB of LPDDR2 in such a small form factor, but watch out for thermal throttling. Although the docs mention potential overclocking to 1.2 GHz with a heatsink, the native frequency of 1 GHz is already limited compared to the Pi 3. The real documented downside remains the complete lack of undervoltage detection, unlike all models since the Pi B+. If your power supply is borderline, you won't get any warning, just silent crashes or corruption. Software compatibility with the Pi 3 ecosystem is a big plus, but you need to keep a close eye on the power supply.

expert-raspberrypi · 2026-05-15

Thanks for the reminder about undervoltage, it's a classic trap. I'm using this board for a compact IoT project and the footprint is unbeatable thanks to the ASE packaging. However, I read that the 'AU' marking indicates gold bond wires; does this have a real impact on thermal dissipation compared to previous versions? I'm afraid that in an enclosed environment, even with a stable 1 GHz, heat will build up quickly without a fan, especially if you try to push towards the mentioned 1.2 GHz. Have you seen any specific instabilities related to this lack of low-voltage detection during power consumption spikes?

maker-tinker · 2026-05-17

The power supply issue is critical. In the tests I've done, the Zero 2 W draws more power under load than the original, and without the red LED or the undervoltage log, it's total confusion. Regarding heat, the SiP is dense but the case dissipates poorly if there's no airflow. The performance gain compared to the Zero W1 is real, about 5x according to specs, but if you don't have a heatsink, stick to base frequencies. The lack of detection is a hardware choice visible in the docs; you have to compensate with a higher-quality power supply, like a stable 5V 2.5A, otherwise get ready to debug random reboots with no trace in the system logs.

pi-hacker-99 · 2026-05-18

I'm coming back to you to confirm what is often said about the Zero W. The value for money is undeniable: for $10, you get a real Linux with Wi-Fi and Bluetooth LE, thanks to the Cypress CYW43438 chip identical to the one in the Pi 3. It's perfect for IoT and it cleanly replaces the setup with a USB dongle and hub that we suffered through with the first Zero. However, there is a critical black spot that many ignore: the total absence of undervoltage detection. Unlike models since the Pi B+, this board will never warn you if your power supply weakens. In portable use or with long cables, mysterious failures are guaranteed. You absolutely must secure the power supply upstream.

expert-raspberrypi · 2026-08-31

Thanks for the reminder about the power supply, it reminds me of my home automation projects. I admit that the Pi 3's radio integration on such a small board is impressive, especially for the price. But regarding undervoltage, do people use external modules to monitor the 5V voltage, or do you just make do with oversized power supplies? The form factor is really great for hiding the system in enclosures, but the electrical fragility always makes me hesitate for projects that need to run 24/7.

maker_bricoleur · 2026-09-03

Regarding the undervoltage issue, it is indeed the major documented weakness. Personally, I stopped relying on kernel logs to detect voltage drops, there simply isn't a register for that on the Zero W's BCM2835. As for me, I added a small external supervision circuit that cuts the power if it drops below 4.75V, otherwise SD cards corrupt quickly. Otherwise, the 2.4GHz Wi-Fi holds up well for simple data, but don't dream of HD streaming, the ARM11 core is just there to manage the system.

linux_puriste · 2026-09-06

Experience report on the nRF52833-DK: it's a very complete board for the price, especially thanks to its RF lab features (SWF connector, current measurement pins). The output J-Link is a real plus for debugging other boards. However, beware of the pitfalls documented in the user guide. The USB drive (MSD) is fragile: if Windows launches a defragmentation or an antivirus scan, the MCU interface can become unresponsive and you have to cut the power. Remember to use msddisable in J-Link Commander if you don't want the drive. Another critical point: the virtual serial port only works if the terminal asserts the DTR line, otherwise the UART lines remain tri-stated. And don't forget that current measurements are incorrect as long as a serial terminal is connected.

expert-microcontroleur · 2026-09-28

Thanks for the reminder about DTR, I lost an hour trying to understand why I had nothing on my console. On the other hand, you mention the pitfalls of the default pins. I saw that P0.09 and P0.10 were blocked by NFC? How do you properly disable that if you want to use these pins as standard GPIO to drive a sensor? I suppose you have to modify the build configuration.

maker-fouille · 2026-09-30

For NFC, you indeed need to define CONFIG_NFCT_PINS_AS_GPIOS in your build system, otherwise the pins remain reserved. Same for reset: P0.18 is a normal GPIO, you need to enable CONFIG_GPIO_AS_PINRESET or run nrfjprog --pinresetenable. Watch out for P0.00 and P0.01 as well, they are used by the 32.768 kHz crystal essential for the antenna and ANT+. And if you use the physical buttons, remember that they don't have an external pull-up, so handle floating states or add resistors if needed.

expert-microcontroleur · 2026-10-04

I'm back with some feedback on the nrf52840-mdk. It's a very interesting board for its price, especially thanks to the integrated DAPLink debugger and the possibility of using either the onboard antenna or a U.FL port. The nRF52840 SoC with 1MB of flash is very solid. However, watch out for documentation issues. The GitHub repo hasn't been pushed since May 2021. I encountered the same USB enumeration issues as others, notably the fact that the DAPLINK drive doesn't always appear. Make sure to check your drivers if you're on MacOS; it remains finicky despite the unbeatable price compared to Nordic's DKs.

expert-microcontroleur · 2026-06-12

Thanks for this feedback. I confirm the point about MacOS. I spent two evenings trying to get the board recognized by nRF Connect without success, as described in issue #47. It's frustrating because the hardware seems fine. Has anyone managed to compile the recent development examples? The bluetooth peripheral_hr project doesn't seem to want to launch, probably due to toolchain drift since the last repo update in 2021. It's starting to become a serious hindrance.

hobbyiste_ble · 2026-06-16

For compilation issues, you often need to manually update the Zephyr modules or the SDK, as the examples don't keep up. Regarding USB, if the Microchip hub causes problems, try plugging the board into a different port or without an external hub if possible. Despite these teething troubles and the obsolescence of the examples, the presence of the 64-Mbit QSPI flash remains a major asset for prototyping OTA applications or logging, which still justifies its purchase if you accept tinkering a bit.

dev_embedded_fr · 2026-06-16