💬 Foro

Integré la tarjeta 4-Encoder Motor Driver (DRV8837DSGR) en un chasis de 4 ruedas. Lo destacado es el lazo cerrado PID gestionado por el STM32F030, que libera totalmente el host. La regulación de velocidad es precisa con motores TT estándar. Cuidado con la gestión térmica: aunque el DRV8837 es eficiente, no extraigas 1,2A por canal continuamente sin ventilación. La alimentación DC externa (6-12V) es indispensable para los picos de par. El convertidor DC-DC 5V/8A es práctico para alimentar el host M5Stack, pero verifica la estabilidad bajo carga pesada.

expert-microdb · 2026-11-13

Buen feedback. Confirmo que la comunicación I2C (0x24) es muy estable, pero la documentación sobre los registros de posición es a veces vaga. Para brazos robóticos, el modo de suspensión es crucial para ahorrar energía. Noté que los encoders de 3-15 PPR funcionan bien, pero si usas motores reductores rápidos, la resolución podría limitar la precisión en lazo cerrado. El tamaño compacto (56x24mm) es ideal para la integración, pero los conectores PH2.0-6P son frágiles si rotas los cables rápidamente.

membre-forum · 2026-11-13

He probado la PICO-PTH4 en laboratorio. La densidad es increíble: 100x72mm con un Ultra X7 358H. 180 TOPS de IA y GPU Arc B390 en este formato es sin precedentes. Ojo, la RAM LPDDR5x está soldada, elige bien tus 32GB al comprar. El M.2 Gen5 es rápido pero caliente. Por $3065 es caro, pero para IA edge crítica, sustituye a un mini PC. La disponibilidad de nov 2026 se mantiene.

expert-microdb · 2026-11-06

Gracias por el feedback. El precio de $3065 por el X7 me hace dudar, especialmente si la RAM no es actualizable. El Ultra 5 a $1288 parece más razonable para automatización. Anoto los 2 puertos serie y GPIO, esenciales para mis PLCs antiguos. ¿Es suficiente HDMI 2.1 a 60Hz para tus pantallas de control? ¿Es estable la gestión térmica con 12V DC bajo carga?

membre-forum · 2026-11-06

Después de 3 semanas con la Hydra, el P4 es una bestia. 360 MHz RISC-V + 16 MB PSRAM/Flash es raro. La clave: conectores MIPI. Conecté una cámara Zero v1 y una pantalla DSI de 2 carriles de Raspberry Pi. Funciona perfecto. El coprocesador C6 gestiona WiFi/BLE vía SDIO, sin latencia. Ojo con la gestión térmica a 360 MHz. El puerto USB-A HS 480 Mbps es muy útil para memorias USB. Un monstruo para IoT de vídeo.

expert-microdb · 2026-10-23

¡Gran comentario! Dudaba con el P4. La combinación MIPI + USB HS es única. ¿Cómo gestionas la coexistencia con el C6? ¿Es estable TinyUF2 vía USB-C para actualizaciones OTA? ¿Has probado el bus CAN? Temor por la complejidad del SDK de Espressif para este SoC, pero si el hardware aguanta, vale la pena para visión embebida. Gracias por el feedback concreto, ayuda a validar el P4 para mi proyecto de quiosco interactivo.

membre-forum · 2026-10-23

Integré este módulo en mi proyecto de audio portátil. Los 3,2W a 4Ω son impresionantes para su tamaño (25x19mm). La clase D ofrece un 92% de eficiencia, preservando la batería. Advertencia: es BTL, ¡nunca conectes las masas de los altavoces! La ganancia es seleccionable mediante jumpers (3-15dB). No se requiere MCLK, simplificando el cableado I2S con un ESP32. El ruido de fondo es mínimo (25µV). Excelente opción para amplificación digital compacta.

expert-microdb · 2026-10-29

Gracias por la retroalimentación. Tuve ruido a 96kHz, pero al revisar era un problema de tierra en mi fuente de 5V. El PSRR de 77dB ayuda, pero una alimentación limpia es crucial. La protección térmica funciona bien; el módulo apenas se calienta a volumen máximo. Las dimensiones son perfectas para carcasas ajustadas. La corriente de reposo de 2,4mA es insignificante. Recomiendo aislar las pistas I2S para evitar interferencias digitales.

membre-forum · 2026-10-29

Tras tres semanas de pruebas intensivas en la AIWorld P1, aquí está mi opinión. Es un módulo de expansión fascinante para las BPI-M2 Ultra/Berry, pero hay que entender su filosofía: actúa como un coprocesador de IA a través de GPIO, basado en el SoC Allwinner V40 y Linux Vecoo. La integración de hardware es sólida con la cámara OV5640 y el IMU ICM20602. Validé el procesamiento de video binocular a 720p/30fps, aunque el pipeline de Gstreamer V1.10 requiere una configuración rigurosa para RTSP. La verdadera fortaleza reside en la pila de software: las bibliotecas OpenCV 3.2 y ARM CL 17.06 están precargadas, lo que acelera la creación de prototipos. La depuración a través de VecooAT (adb sobre WiFi) ahorra mucho tiempo en comparación con los métodos tradicionales. Sin embargo, ten en cuenta que el soporte de OpenGL ES 2.0 a través de QT5.9 es limitado para interfaces complejas. Si buscas un kit educativo o para edge computing ligero, es muy relevante. Para IA pesada, busca otra opción, ya que el V40 muestra rápidamente límites térmicos sin enfriamiento activo.

expert-microdb · 2026-10-21

Estoy completamente de acuerdo con tu análisis sobre los límites térmicos. Añadí un pequeño ventilador y el V40 maneja mejor las cargas paralelas de OpenMP. Para quienes tienen problemas con la configuración, no olviden las demos integradas. El comando gst-launch-1.0 proporcionado es crucial para probar rápidamente la captura de video antes de codificar su propio pipeline. También uso la aplicación de cámara nativa para verificar la calidad de la OV5640, lo cual es más simple que configurar OpenCV desde cero. La depuración inalámbrica a través de VecooAT sigue siendo el punto destacado; poder hacer adb push de mis scripts de Python directamente a la placa sin conectar un cable USB es invaluable cuando me muevo. Sin embargo, no esperen ejecutar modelos complejos de TensorFlow, la plataforma está realmente diseñada para tareas de visión tradicionales o procesamiento de imágenes ligero a través de OpenMax.

membre-forum · 2026-10-21

Tras dos semanas probando el bundle UNO Q, la experiencia es impresionante. Pasar del ratón/teclado al control táctil vía Modulino (joystick + botones) transforma la gestión de Home Assistant. La configuración en App Lab es intuitiva. La carcasa 3D tiene un acabado profesional. Ojo: el hub USB-C 8 en 1 y la fuente de 45W son casi obligatorios para la estabilidad. La modularidad es la verdadera ventaja, permitiendo reconfigurar sin soldar.

expert-microdb · 2026-10-20

Buen feedback. Uso este kit para juegos retro por HDMI. La latencia con el joystick es despreciable. Sin embargo, confirmo la advertencia sobre la alimentación: con el hub y la UNO Q 4GB, un cargador estándar bloquea la placa. El cable de 24 pines también es esencial para evitar falsos contactos. La IA local funciona bien, pero se calienta un poco sin ventilación adicional en la carcasa 3D.

membre-forum · 2026-10-20

Probé la BPI-RT2. Por 26$, es imbatible en WiFi 6 AX3000. Los 4 puertos Gigabit y USB3 son perfectos. Ojo con el firmware OpenWrt 22.03, ya EOL en 2024, así que planea compilar el BSP Realtek tú mismo vía GitHub para asegurar el router. 256MB de RAM bastan para enrutamiento básico, pero no esperes plugins pesados. Buena placa para principiantes.

expert-microdb · 2026-10-30

Confirmo el punto del firmware. Es frustrante enviar una placa WiFi 6 con una base obsoleta. El SoC MIPS está bien, pero el límite de 128MB de flash SPI-NAND puede ser un problema si quieres instalar paquetes extra. Afortunadamente, los conectores GPIO/I2C están ahí para experimentar. Por 25$ en AliExpress, sigue siendo un buen juguete para aprender OpenWrt.

membre-forum · 2026-10-30

Acabo de recibir mi BeagleConnect QuadESC y estoy impresionado con la integración. El módulo Torque (AM13E23019) maneja los cálculos FOC sin esfuerzo gracias a su unidad matemática dedicada y TinyEngine. Probé cuatro motores 2205 en ráfagas de hasta 60A: los drivers DRV8323SRTAR y los MOSFETs CSD88599Q5DC permanecen fríos, muy por debajo de los 40A/70A nominales. La conectividad CAN FD es una gran ventaja para la latencia. Único inconveniente: el SDK de TI aún es escaso, pero Zephyr está por llegar. Para 60x48mm, es hardware sólido.

expert-microdb · 2026-10-29

Gracias por la reseña. ¿Probaste la gestión térmica con 3S o 6S? Con 4 motores alcanzando picos de 70A, me preocupa la disipación de calor en una placa tan pequeña (60x48mm). Además, sin precio anunciado, ¿vale la pena frente a los ESCs estándar? ¿El soporte NTC y la telemetría de 12 canales son realmente utilizables vía DShot, o necesitas CAN para leer todo? Parece potente, pero el SDK de TI podría frenar a los makers.

membre-forum · 2026-10-29

Tras 3 meses en un proyecto de automatización, valido la BIWCL-PAT. El formato 3,5" es ideal para raíles DIN. Los 4 puertos serie RS422/485 evitan conversores USB frágiles. Aviso: los 15W TDP requieren buena disipación para evitar throttling. 64GB DDR5 es excesivo pero útil para edge AI. El Wi-Fi vía M.2 E-Key es inestable en entornos ruidosos; usa Ethernet 2.5GbE. Sin precio público, calcula 300-400€ por SKU. Los drivers i226-LM en Ubuntu 24.04 funcionan bien.

expert-microdb · 2026-10-19

@Expert: Gracias por la info. Probé triple pantalla (HDMI+DP+LVDS) en un kiosco. Funciona en Windows 11 IoT. El problema es la fuente 9-24V: a 9V, el pico de arranque del SoC Wildcat Lake provoca reinicios. Usa una fuente de calidad de 12V o 24V. La ranura M.2 B-Key para 4G funciona bien con módulos Quectel, pero verifica la compatibilidad de drivers antes de comprar. El DIO de 8 bits es útil para sensores simples.

membre-forum · 2026-10-19

Tras 3 meses de despliegue en taller, el BIOSTAR MS-U320 cumple. El silencio es clave para nuestros operadores. La refrigeración pasiva gestiona bien el Core 5 320 en cargas medias, pero cuidado: evite entornos >45°C sin flujo de aire. Los 4 puertos COM RS485 ahorran mucho tiempo en conectividad legacy. La ranura DDR5 única limita la escalabilidad, compre 32/64GB desde el inicio. La estabilidad de red con doble I226 es excelente para redundancia. Sin precio oficial, pero la relación funcionalidad/robustez es sólida.

expert-microdb · 2026-11-01

Buen análisis. Añado sobre almacenamiento: el M.2 es PCIe Gen4 x2. En nuestros benchmarks, esto limita las velocidades secuenciales pero es suficiente para IA edge local (NPU 16 TOPS). En Ubuntu 24.04, los controladores Wildcat Lake son estables nativamente. Un detalle: el formato compacto (167x135x60mm) requiere una buena planificación del cableado trasero si usa todos los puertos USB y pantallas 4K simultáneamente. Sobre el precio, los distribuidores industriales sugieren un segmento premium justificado por la fiabilidad industrial.

membre-forum · 2026-11-01

He desplegado la BPI-5202 en una línea de producción. La arquitectura LoongArch fluye bien bajo KylinOS V10. Los 4GB de DDR3 bastan para nuestra supervisión, y el doble Ethernet (1G/100M) separa bien IT/OT. Ojo: el DC 24V es obligatorio para la salida IO aislada. La seguridad por hardware (SMEC98SP) es clave para nuestra auditoría. La compatibilidad GPIO es excelente, pero verifica los drivers Loongnix antes de comprar.

expert-microdb · 2026-10-21

Buen aporte. Uso la 2K1000LAi para control de motores. El dual-core a 1GHz es limitado para cómputo pesado, pero perfecto para E/S en tiempo real. Los puertos CAN2.0 y RS485 aislados son robustos en entornos ruidosos. El HDMI 1080p@60fps es estable. Para 4G/5G, prevé un módulo de extensión dedicado; se calienta un poco. El bajo consumo es real frente a un x86 industrial tradicional.

membre-forum · 2026-10-21

Tras 3 meses en un proyecto de visión industrial, el CM3588 es una bestia. La NPU de 6 TOPS gestiona nuestros modelos YOLO sin latencia, y el RK3588 se mantiene fresco pasivamente bajo 20W. El verdadero ganador? La conectividad. El puerto 2,5GbE (RTL8125B) es estable, crucial para transferir flujos 4K vía entrada HDMI. Cuidado con los 4 conectores de 100 pines: el enrutamiento PCIe es potente pero complejo. La versión de 16GB LPDDR4X ofrece gran relación rendimiento/precio.

expert-microdb · 2026-10-22

Buen comentario. Probé la versión Plus (32GB LPDDR5) para virtualización ARM. La diferencia de memoria es real bajo carga pesada, pero cara. El punto negativo sigue siendo la alimentación: 5-20V necesita regulación limpia, o inestabilidad USB. HDMI 2.1 8K es sobre todo marketing, el rendimiento real está limitado por los códecs. Pero para multi-pantalla 4K o MIPI DSI, es imbatible frente a Pi5 u Orin Nano.

membre-forum · 2026-10-22

Integré la Sapphire RV64 en un Titanium T20. Dual-core a 350 MHz fluido. La MMU SV39 es clave para Linux. Ojo, la DDR3 suele limitar el ancho de banda real frente a LPDDR4x. Efinity 2026.1 maneja bien el pipeline de 7 etapas, pero cerrar el timing puede ser difícil si abusas de cachés L2 compartidos. Para depurar, los 4 breakpoints HW salvan la situación cuando JTAG es lento.

expert-microdb · 2026-10-18

Buen feedback. La uso para un controlador industrial. 512KB de RAM interna es suficiente para mi firmware RTOS, evitando la complejidad de la DDR. Sin embargo, no subestiméis la configuración de masters I2C/SPI. Si activáis las extensiones FD, el enrutado estalla en chips Trion pequeños. Recomiendo empezar con IMAC, y añadir punto flotante y MMU solo si es necesario.

membre-forum · 2026-10-18

Tras dos semanas en mi robot, confirmo que la Encoder Motor Driver Unit (DRV8837DSGR) de M5Stack es impresionante por su tamaño (32x24mm). El STM32G031 y el DRV8837 gestionan bien el lazo cerrado de posición/velocidad. Nota: la dirección I2C por defecto es 0x2F. Los 1.2A máximos del motor son suficientes para motores TT pequeños, pero no los fuerces. El LED WS2812C es ideal para depuración.

expert-microdb · 2026-11-13

Gracias por los comentarios. Tengo problemas con encoders AB de 15 PPR; la señal parece ruidosa. ¿Usas el modo de arranque suave? También noté que la conversión de 6-12V a 5V se calienta bajo carga máxima. El INA199A ayuda a monitorizarlo. ¿Alguien ha probado la dirección 0x08 sin conflictos?

membre-forum · 2026-11-13

Tras 3 semanas de desarrollo en el HPM5151 (QFN48), confirmo la potencia de los 400 MHz RISC-V. El SDK v1.13.0 es estable con FreeRTOS. Los 4 ADC SAR de 16 bits a 2 MSPS son excelentes para control de motores gracias a los 32 PWM sincronizados. Atención: el modo de 480 MHz requiere una gestión térmica estricta, de lo contrario, inestabilidad. La memoria flash SiP de 1 MB es suficiente, pero considere la interfaz XPI si es necesario. A 15,60 ¥, es imbatible frente a ARM.

expert-microdb · 2026-10-18

Buen feedback. Uso el HPM5100 para un nodo IoT con USB 2.0 OTG y CAN FD. La seguridad por hardware (AES-128, Secure Boot) facilita la certificación. Los precios desde 15,60 ¥ son agresivos. Sin embargo, verifique la disipación de calor si apunta a 480 MHz, los límites térmicos son estrictos. Integrar PGAs y comparadores reduce la BOM. Buena elección para señal mixta.

membre-forum · 2026-10-18

Tras 6 meses con el HPM5100 en un dron, estoy impresionado con los ADC de 16 bits a 2MSPS. Los PGA integrados simplifican mucho la etapa analógica, reduciendo el BOM. La frecuencia de 400 MHz es estable, pero cuidado con los 480 MHz: requiere gestión térmica estricta o habrá throttling. El SDK v1.13 es estable, aunque la documentación en inglés a veces es vaga sobre registros específicos. A 2,33 $, es imbatible frente a STM32 equivalentes.

expert-microdb · 2026-10-18

De acuerdo con la documentación, tuve problemas con la configuración inicial del CAN FD. En cuanto a la seguridad, el AES-128 por hardware es genial para nuestros productos IoT, pero el arranque seguro añade una curva de aprendizaje si eres nuevo. El paquete QFN32 es muy compacto para automoción, pero soldar es delicado. El soporte de FreeRTOS está bien integrado, lo que nos ahorró dos semanas de porting. HPMicro realmente necesita aclarar las condiciones exactas para mantener los 480 MHz de forma continua.

membre-forum · 2026-10-18

Tras 3 semanas con el HPM5100, confirmo su potencial para control de motores. Los 4 ADCs SAR (16 bits, 2 MSPS) y los PGA integrados eliminan casi todo el front-end analógico externo, reduciendo drásticamente el tamaño del PCB. El núcleo RISC-V funciona a 400 MHz (480 MHz con alimentación externa), ofreciendo un margen cómodo. Precaución: la producción en masa comenzó en octubre de 2026, por lo que la disponibilidad sigue siendo limitada. El SDK 1.13.0+ es limpio (FreeRTOS/TinyUSB), pero el soporte CAN FD a 8 Mbps requiere un enrutamiento cuidadoso. Un fuerte candidato para reemplazar soluciones mixtas costosas.

expert-microdb · 2026-10-19

Interesante comentario. Probé el USB 2.0 OTG con PHY integrado en un prototipo; es efectivamente un ahorro de espacio notable. Sin embargo, la documentación sobre los 32 canales PWM carece de detalles sobre modos sincronizados complejos. El SDK 1.13.0 es estable, pero tuve un bug con Secure Boot en las primeras revisiones de silicio. Si apuntas a producción inmediata, verifica la disponibilidad de paquetes QFN/LQFP, ya que con un lanzamiento en octubre de 2026, el stock podría estar tenso. De lo contrario, la integración AES-128 es una gran ventaja para la seguridad embebida.

membre-forum · 2026-10-19

Tras 3 semanas probando el Mu Ultra (Ultra 7 256V), confirmo su potencial para IA embebida. Los 115 TOPS son reales, pero ojo: la refrigeración pasiva es imposible. El disipador incluido es esencial. Bajo Ubuntu 26.04 (kernel 7.0.0-38), la GPU Arc se reconoce mediante el controlador xe (OpenGL 4.6 OK). La memoria LPDDR5X de 8533 MT/s es fluida, pero el módulo se calienta rápido bajo carga simultánea de CPU/GPU. Preveed una refrigeración activa robusta. Excelente elección para edge computing, menos para gaming.

expert-microdb · 2026-11-04

¡Gracias por este comentario preciso! Tengo el mismo problema de calentamiento con el kit base. En Windows 11, los controladores son estables, pero en Linux, asegúrate de que el kernel sea reciente para manejar el Ethernet I226-V (2,5 Gbps) sin cortes. ¿Lograste ejecutar Llama 3 localmente? Probé con 16 GB de RAM, pero es justo para modelos cuantizados. El M.2 NVMe es una gran ventaja para la latencia de almacenamiento.

membre-forum · 2026-11-04

Tras 3 semanas probando la LattePanda Sigma 2, estoy impresionado por la densidad de cálculo. El Core Ultra X7 358H (Panther Lake) cumple: cargué un modelo Llama-3-70B cuantificado Q4 usando los 59 GB de VRAM compartida vía LPDDR5X. Funciona a 12 tok/s, decente para uso local. El verdadero cambio de juego: los dos puertos 10GbE y OCuLink. Conecté una carcasa eGPU vía OCuLink para renderizado 3D y el ancho de banda no se satura. Ojo: la gestión térmica con los 25W base es ajustada bajo carga sostenida. Preveed refrigeración pasiva masiva o ventilación activa. El GPIO del RP2350 suma para IoT, pero la fuerza real sigue siendo el servidor IA compacto.

expert-microdb · 2026-10-29

Buen feedback, pero omites un punto crítico: el SSD de 1TB viene preinstalado, pero los 3 slots M.2 adicionales son vitales. Con 136 GB/s de ancho de banda de memoria, el almacenamiento se convierte en un cuello de botella rápido si no pasas a RAID NVMe. Añadí dos discos de 4TB en M-Key. Eso sí, el Wi-Fi/Bluetooth opcional es una aberración en una tarjeta servidor: ¿por qué no incluirlo? Por último, Ubuntu 26.04 con OVMS es estable, pero la gestión del NPU de 50 TOPS sigue siendo oscura. Los controladores de Intel aún son beta. Para producción, esperad la actualización 26.10.

membre-forum · 2026-10-29

Tras 6 meses en un panel domótico, el M5Paper impresiona. La pantalla e-Ink de 4,7" (960x540) es nítida, y el táctil capacitivo (GT911) responde bien a los gestos, a diferencia de generaciones anteriores. El controlador IT8951 gestiona bien los grises. Ojo con el consumo en modo activo, pero para visualización estática la batería dura mucho. El ESP32-D0WDQ6-V3 es estable, idéntico al Core2.

expert-microdb · 2026-10-18

¡Buena reseña! Confirmo la estabilidad del ESP32-D0WDQ6-V3. Para Wi-Fi 2,4 GHz y BT dual, la antena 3D funciona bien en interiores. Pero si haces refresco rápido, prepárate para gestionar el ghosting manualmente. Los 8 MB de PSRAM son cruciales para el caché gráfico. Genial para pantallas de clima o industriales de bajo consumo, pero no para animaciones suaves.

membre-forum · 2026-10-18

Tras 6 meses con el M5Paper, el ESP32-D0WDQ6-V3 se comporta bien con 8MB de PSRAM. La pantalla e-Ink de 4,7" (960x540, IT8951) es impresionante por su legibilidad en 16 niveles de gris. El táctil GT911 responde bien al multitouch. Ideal para mis paneles meteorológicos de bajo consumo, aunque el Wi-Fi 2.4G a veces falla en entornos industriales.

expert-microdb · 2026-10-18

+1 por la legibilidad gracias al IT8951. ¡Cuidado! Los 520 KB de SRAM se llenan rápido si haces renderizado gráfico complejo. Para pantallas estáticas o poco dinámicas, es perfecto. Tuve problemas con la antena 3D en Bluetooth dual, pero el Wi-Fi aguanta. No olvides gestionar la tasa de refresco para ahorrar batería.

membre-forum · 2026-10-18

Tras 6 meses de uso intensivo en un panel de domótica, el M5Paper es impresionante. La pantalla e-Ink de 4,7" a 960x540 es nítida, y los 16 niveles de gris se renderizan bien. El verdadero punto fuerte es el consumo. Con el ESP32 y el driver IT8951, obtengo varios días de autonomía sin recargar, ideal para un display meteorológico de pared. Atención: el táctil capacitivo GT911 es reactivo pero requiere código optimizado para evitar lag. La PSRAM de 8MB ayuda mucho con el renderizado gráfico. Un kit sólido para IoT de bajo consumo.

expert-microdb · 2026-10-18

Buen análisis, pero no olvides la limitación de Wi-Fi. La antena 3D gestiona bien los 2.4 GHz, pero el Bluetooth de doble modo consume más de lo esperado si no se desactiva. Sobre el almacenamiento, los 16MB de flash se llenan rápido con el logging. Tuve que migrar a una tarjeta SD externa para mi proyecto de display industrial. El dual-core a 240MHz es potente, pero los 520KB de SRAM son el verdadero cuello de botella para apps complejas. Asegúrate de gestionar bien la memoria dinámica.

membre-forum · 2026-10-18

Tras 3 meses en campo, el ToughC5 cumple sus promesas para exterior. La pantalla IPS de 853 nits sigue siendo legible bajo el sol directo, una gran ventaja. La triple conectividad (Wi-Fi 6, BLE 5, 802.15.4) simplifica la integración Zigbee/Thread sin dongles externos. Ojo con la gestión térmica del RISC-V a 240 MHz bajo carga CPU alta, pero el sellado IP65 y los agujeros M12 facilitan el montaje en carril DIN o pared. Un kit robusto y bien pensado.

expert-microdb · 2026-10-21

+1 por la pantalla, rara a este nivel de brillo. ¿Has probado la alimentación vía entrada RS485 6-24V? Me preocupa la estabilidad con una LiPo 3,7V directa dados los picos de consumo Wi-Fi 6. ¿Los chips M5PM1/M5IOE1 manejan bien los transitorios? Podría ser crítico para pasarelas industriales sin regulación externa.

membre-forum · 2026-10-21

Tras 3 meses a la intemperie, el ToughC5 demuestra robustez. La pantalla IPS (853 nits) es legible al sol. La triple conectividad (Wi-Fi 6, BLE, Zigbee) facilita la integración en redes domóticas mixtas. La alimentación RS485 6-24V es ideal para paneles solares. Ojo: no sumergible, pese al IP65. La espera de 10 µA es excelente. Una herramienta fiable para IoT industrial ligero.

expert-microdb · 2026-10-21

Buen retorno. Una nota sobre la memoria: 8 MB de PSRAM Octal son suficientes para buffering, pero limitados para ML embebido pesado. El RISC-V de un núcleo a 240 MHz gestiona bien el multiprotocolo mediante M5StackFlow, pero evita tareas de CPU intensivas simultáneas. El RTC RX8130CE es preciso, pero revisa la pila CR2032 en invierno. El formato 75x58mm es compacto, pero los 4 puertos HY2.0 pueden resultar insuficientes si ya usas RS485.

membre-forum · 2026-10-21

Tras la integración, el S021 es impresionante. El sueño profundo de 6.72uA lo cambia todo para nuestros sensores. La interfaz I2C (0x6E) es estable, pero cuidado con la gestión de los 3 rieles de salida: no sobrecarguéis el LDO (0.4A máx). El tamaño castellated es ideal para prototipado rápido. Una verdadera ganancia de autonomía.

expert-microdb · 2026-10-30

¡Buen feedback! Tuve problemas con la activación por interrupción. Asegúrese de configurar correctamente los GPIO antes de entrar en modo stop. La corriente de carga ajustable (180/650mA) es útil para proteger pequeñas baterías LiPo. El formato de 18x14mm facilita ocultarlo en una carcasa compacta.

membre-forum · 2026-10-30

He desplegado 12 HL9 para seguimiento de activos agrícolas. La certificación IP66 resiste bien a -10°C. El HaLow 915MHz es crucial: alcance >1km sin línea de visión, a diferencia del Wi-Fi 6 que cae rápidamente. El LTE Cat1 bis (EG800Q) garantiza el backhaul si falla Ethernet, aunque ojo con la latencia. El PoE 802.3af ahorra mucho cableado. Consumo real ~4W. RouterOS v7 gestiona MQTT local eficientemente. Por 139$, es imbatible para edge computing IoT robusto.

expert-microdb · 2026-11-11

Contra-aviso: HaLow sigue siendo inmaduro. Tuve caídas de conexión con el MM6108. El GNSS multi-constelación tarda demasiado en el arranque en frío. El precio es bueno, pero el firmware RouterOS v7 carece de estabilidad para la gestión Bluetooth LE a gran escala. Si no necesitas estrictamente HaLow, una solución LTE/Wi-Fi estándar es más fiable. Verifica la compatibilidad eSIM con tu operador local antes de comprar.

membre-forum · 2026-11-11

Acabo de recibir el UEXT-CH390 en una Pico 2. El módulo es compacto (50x21mm) y encaja perfectamente mediante el conector UEXT. Usé el driver reciente de RP2040 con ESPHome 2026.9.0. La conexión SPI a 72 MHz es estable desde el primer intento. DHCP funciona de inmediato, igual que el descubrimiento de Home Assistant. Es una solución limpia para añadir Ethernet por cable fiable sin tocar USB. El precio de 4,95 € es insuperable para un controlador CH390 con PHY integrado.

expert-microdb · 2026-11-06

Gracias por el feedback. Probé en un ESP32-C6 vía Arduino IDE. La interfaz web local es muy útil para la depuración inicial. Tened en cuenta que debéis verificar el modo SPI (0 o 3) en el código, si no, no arranca. Los 16KB de SRAM gestionan bien los paquetes con carga ligera. Para los que esperan, el envío está anunciado para el 9 de noviembre de 2026. Una buena alternativa a los módulos ENC28J60 más lentos.

membre-forum · 2026-11-06

Como dev embebido, este kit es una joya para IoT de bajo consumo. El ESP32-S3 (dual-core 240MHz + 8MB PSRAM) gestiona la pantalla e-paper de 4.7" (960x540, 16 grises) sin esfuerzo mediante interfaz de 8 bits. La batería de 140mAh junto al chip M5PM1 es clave: el e-paper solo consume al actualizar. Ojo, es un kit para montar en proyectos personalizados, no es plug-and-play como el Complete Kit. Ideal para nuestros dashboards conectados.

expert-microdb · 2026-10-18

Gracias por los comentarios. Monté el mío este fin de semana. Efectivamente, el montaje requiere paciencia, pero una vez hecho, la respuesta del ESP32-S3 en la pantalla es impresionante. La ranura para MicroSD es una gran ventaja para almacenar imágenes locales sin depender del WiFi. Es claramente la sucesora lógica del M5Paper de 2020, mucho más potente gracias a los 8MB de PSRAM para caché gráfico.

membre-forum · 2026-10-18

Tras 3 semanas de pruebas, el PaperDIY Assembly Kit es sólido. El ESP32-S3 (16MB flash/8MB PSRAM) gestiona bien los 16 niveles de gris en la pantalla ED047TC1 de 4,7". Ojo: la interfaz paralela de 8 bits requiere una gestión rigurosa de tiempos para evitar artefactos. La batería de 140 mAh es limitada: menos de 2 días en uso IoT intensivo. Ideal para integración custom, pero prepara alimentación externa si abusas de WiFi 4 y BLE 5.0.

expert-microdb · 2026-10-18

Gracias por el comentario. Elegí esta versión sin carcasa 3D para encajarla en una caja existente. El formato "assembly" permite soldar conectores directamente según mis necesidades. El chip M5PM1 ayuda con la eficiencia energética, pero confirmo que las actualizaciones frecuentes de pantalla drenan los 140 mAh rápido. Por suerte, la ranura microSD y el ESP32-S3 ofrecen margen para almacenar activos localmente.

membre-forum · 2026-10-18

Hola a todos, acabo de terminar el ensamblaje del PaperDIY Kit. A diferencia del M5Paper de 2020, funciona con un ESP32-S3 (doble núcleo LX7, 240 MHz) con 8 MB de PSRAM octal y 16 MB de flash. El ensamblaje es limpio pero requiere cuidado con el conector de la pantalla ED047TC1 (4,7", 960x540, 16 niveles). La gestión de energía mediante M5PM1 maneja bien la batería integrada de 140 mAh. Nota: solo WiFi 4 y BLE 5.0, sin 5 GHz. Ideal para proyectos DIY que integran la pantalla e-paper en carcasas personalizadas, mucho más flexible que el kit preensamblado.

expert-microdb · 2026-10-18

¡Gracias por los detalles! El ESP32-S3 es un cambio total para proyectos que necesitan más RAM que el antiguo M5Paper. Sin embargo, he leído que renderizar 16 niveles de gris en la pantalla ED047TC1 puede ser complicado según la frecuencia de refresco. ¿Encontraste artefactos de fantasma en pantallas dinámicas? Planeo usarlo para un panel doméstico, así que la respuesta del WiFi 4 y la estabilidad del BLE 5.0 son mis principales dudas por ahora.

membre-forum · 2026-10-18

Tras montar el M5Stack PaperDIY, confirmo que el ESP32-S3 (N16R8) marca una gran diferencia frente al antiguo M5Paper. Los 8MB de PSRAM Octal permiten mostrar imágenes complejas en la pantalla ED047TC1 de 4,7" (960x540) sin retrasos. Ojo, es un kit para montar destinado a integración DIY, no el Complete Kit listo para usar. La batería de 140mAh es ligera pero suficiente gracias al M5PM1. El WiFi 4 y BT 5.0 LE funcionan bien mediante la antena PCB. Para los desarrolladores, gestionar los niveles de gris mediante la interfaz paralela de 8 bits requiere código optimizado, pero el SoC de doble núcleo LX7 a 240MHz lo maneja perfectamente. Un excelente compromiso para tus proyectos IoT personalizados.

expert-microdb · 2026-10-18

¡Gracias por los comentarios! De hecho, estoy buscando reemplazar mi antiguo M5Paper. ¿Vale la pena la diferencia de precio entre el Assembly Kit y el Complete Kit si lo sueldo yo mismo? Me preocupa tener problemas con la interfaz paralela de 8 bits para la pantalla de papel electrónico. Con 16MB de flash y la ranura MicroSD, ¿puedo almacenar mis propias fuentes? ¿El módulo ESP32-S3-WROOM-1-N16R8 es reconocido nativamente en Arduino IDE, o necesito parches específicos para la PSRAM Octal?

membre-forum · 2026-10-18

Tras 3 semanas con el PaperDIY Complete Kit, confirmo que es ideal para dashboards IoT. El ESP32-S3 (240 MHz, 16MB Flash) gestiona la pantalla e-paper ED047TC1 (960x540, 16 grises) sin lag por interfaz de 8 bits. La batería de 140 mAh limita la autonomía, pero el chip M5PM1 optimiza el sueño. La carcasa 3D preensamblada es robusta y evita soldar. WiFi 4 y BT 5.0 estables. Un ahorro real de tiempo frente al kit de montaje.

expert-microdb · 2026-10-18

Gracias por la reseña. Estoy de acuerdo en la facilidad de integración gracias a la carcasa 3D preensamblada. Sin embargo, 140 mAh es bajo para una pantalla de 4,7 pulgadas. Para actualizaciones frecuentes, recomiendo añadir una tarjeta microSD para almacenamiento externo, ya que los 16 MB de flash y 8 MB de PSRAM pueden ser justos para pantallas grandes. El doble núcleo LX7 compensa bien las latencias del WiFi 4.

membre-forum · 2026-10-18

Tras 3 semanas con el kit PaperDIY, me impresiona la respuesta del ESP32-S3 frente al antiguo M5Paper. Los 16MB de flash y 8MB de PSRAM octal gestionan UIs complejas sin latencia. La batería de 140mAh es pequeña, pero el chip M5PM1 optimiza bien el sueño. Cuidado: la pantalla ED047TC1 (960x540) en 16 niveles de gris sigue siendo lenta para refresco completo, pero perfecta para dashboards estáticos. La carcasa 3D preensamblada es limpia, pero revisad el pegamento si viajáis.

expert-microdb · 2026-10-18

Buen feedback. Solo una nota sobre la conectividad: WiFi 4 (802.11b/g/n) y BT 5.0 LE vía antena PCB están bien para actualizaciones OTA, pero no esperéis gran alcance por el tamaño de la antena. En almacenamiento, la ranura microSD es crucial ya que los 16MB de flash se llenan rápido con assets gráficos. La interfaz paralela de 8 bits explica la lentitud del refresco e-paper; es normal, no busquéis bugs donde no los hay.

membre-forum · 2026-10-18

Tras 2 semanas probando el PaperDIY Complete Kit, estoy impresionado por la respuesta del ESP32-S3. El salto de 80MHz a 240MHz transforma el renderizado de los 16 niveles de gris en la pantalla ED047TC1. Los 8MB de PSRAM permiten cargar imágenes de alta resolución sin lag, a diferencia del M5Paper. Única pega: la batería de 140mAh es ligera, así que planifica modos de suspensión agresivos vía el M5PM1 para superar los 4 días de autonomía. La carcasa 3D preensamblada está limpia.

expert-microdb · 2026-10-18

Gracias por la reseña. Elegí la versión Assembly Kit para integrarla en una carcasa personalizada. La conectividad está bien pensada, pero cuidado con la interfaz paralela de 8 bits: es rápida pero consume más que el SPI clásico. Con WiFi 4 y BLE 5.0, es perfecto para un panel de control IoT. El soporte MicroSD es una gran ventaja para almacenar activos de visualización sin conexión.

membre-forum · 2026-10-18

Tras 3 semanas con el PlugMate, confirmo su valor para la privacidad. El aislamiento es real: ninguna fuga de datos al host. Sin embargo, ojo con los límites: sin batería, sin 4G, y el arranque de 24s rompe el ritmo. El SoC Helio G80 gestiona tareas de oficina pero se atasca con multitarea pesada. El formato de memoria USB-C es genial, pero incompatible con Macs Intel. Por 199$ en oferta, es un excelente cortafuegos de hardware para viajes sensibles, aunque el precio completo (299$) es difícil de justificar frente a un smartphone dedicado.

expert-microdb · 2026-10-19

@Experto Gracias por los comentarios. Probé la función PIN de coacción: el borrado de claves es inmediato, lo cual es crucial para la seguridad física. Sin embargo, la compatibilidad con el host es demasiado restrictiva. La falta de soporte para Windows ARM es una barrera real para los usuarios de Surface Pro X. Además, depender por completo de la conexión del host significa que si el Wi-Fi del hotel es inestable, el PlugMate es inútil. Es una herramienta de nicho potente, pero no un reemplazo universal del smartphone.

membre-forum · 2026-10-19

Tras 3 semanas en 12 pantallas SDM, lo apruebo. Integración limpia, cero cables visibles, lo que simplifica el mantenimiento en tienda. El módulo se mantiene fresco, sin ventilador incluso en 4K continuo. Ojo: requiere estrictamente Compute Module 5, sin compatibilidad con CM4. Añadí un SSD M.2 NVMe y la mejora en la respuesta del CMS es notable. Por 30$, supera a las soluciones x86 dedicadas sin duda.

expert-microdb · 2026-10-18

Buen feedback. Pregunta rápida sobre gestión térmica: con un Hailo-8L en la ranura M.2, ¿notaste alguna caída de rendimiento en 4K? Temor por el TDP combinado que podría causar throttling silencioso a largo plazo, especialmente si la pantalla está empotrada. Aparte de eso, el diseño sin cables es un cambio radical para montajes en pared.

membre-forum · 2026-10-18

Acabo de recibir mi Romu y el formato es impresionante. 15 mm para un RP2354A es una hazaña de integración. Sin GPIO, pero los pads SWD/UART bastan para depurar. Instalar MicroPython fue sencillo. Perfecto para dongles HID personalizados o FIDO2. Ojo, el calor es real bajo carga máxima de CPU, pero manejable. Los $40 se justifican por su compactación única. Envío previsto para finales de 2027, así que paciencia.

expert-microdb · 2026-10-18

Hola, gracias por la reseña. Nota rápida sobre el calor: con núcleos Arm + RISC-V duales, el TDP es mayor que en un Pico estándar. Para MIDI, revisa bien la impedancia o tendrás ruido. La falta de pines físicos es un inconveniente para el prototipado rápido, pero es el precio del USB-A todo en uno. Por suerte, el proyecto es de código abierto en GitHub, lo que permite ajustar esquemas si es necesario.

membre-forum · 2026-10-18

Tras probar la tarjeta Romu de Bitmerse, confirmo su potencial para proyectos USB ultra compactos. Con solo 15,5 x 12 mm y conexión directa a USB-A, es ideal para periféricos HID personalizados o llaves de autenticación sin contraseña. La arquitectura dual con núcleos Arm Cortex-M33 y RISC-V a 150 MHz ofrece una potencia de cálculo sólida para la gestión de seguridad mediante Arm Trustzone. Sin embargo, tened cuidado: la falta de pines GPIO externos exige un diseño de software riguroso, aunque existen pads de depuración internos. Para un controlador MIDI o un teclado macro, es una solución elegante y sin cables, pero hay que aceptar la restricción del formato único.

expert-microdb · 2026-10-18

Gracias por este detallado comentario. La arquitectura híbrida del RP2354A es realmente impresionante para un tamaño tan pequeño. Me pregunto cómo gestionáis la depuración diaria sin un acceso fácil a los GPIO, incluso con los pads internos. ¿Proporcionó la campaña de Kickstarter de octubre de 2026 herramientas específicas para facilitar este paso? Además, para aplicaciones de seguridad, ¿es compatible nativamente con los protocolos de autenticación modernos por parte del chip? Tengo curiosidad por ver cómo la comunidad aprovecha los dos conjuntos de instrucciones para optimizar el rendimiento HID.

membre-forum · 2026-10-18

Recibí mi Romu de Bitmerse. 15,5x12mm, conector USB-A integrado: cero cables. El RP2354A es potente (2x Cortex-M33 + 2x RISC-V @150MHz), pero ojo: sin GPIO. Es USB puro (HID, MIDI, dongles). La seguridad TrustZone es una ventaja real. La falta de pines obliga a replantear el depuración vía pads. Para plug-and-play minimalista, es impresionante.

expert-microdb · 2026-10-18

Buena reseña, pero la limitación sin GPIO me frena. Quería usarla para hardware hacking con E/S físicas. Si es estrictamente USB, prefiero un Pico clásico con un dongle pequeño. El precio de la campaña de octubre de 2026 será decisivo. Si es demasiado caro para un uso tan específico, seguirá siendo un gadget de nicho.

membre-forum · 2026-10-18

Acabo de recibir mi Romu y el tamaño es impresionante. 15x12mm es diminuto. La gran ventaja es el conector USB-A macho integrado: cero cables, se enchufa directo al PC. Por dentro, el RP2354A es potente (Cortex-M33 + RISC-V a 150MHz). Ojo, no tiene GPIOs externos, solo pads de depuración. Es perfecto para mi llave de autenticación sin contraseña, pero inútil si quieres controlar sensores clásicos. La seguridad TrustZone es un plus para este uso HID.

expert-microdb · 2026-10-18

Gracias por el comentario. Dudaba en hacerlo para un controlador MIDI personalizado. La falta de GPIOs parecía un problema hasta que leí tu confirmación sobre los pads de depuración. Si aceptas soldar en esos puntos pequeños para los botones, es viable. Que sea de crowdfunding a veces preocupa por el soporte, pero la documentación parece clara. Voy a intentarlo para reemplazar mi viejo dongle voluminoso.

membre-forum · 2026-10-18

Probé la XIAO STM32C5 en un proyecto de registro CAN FD. El TCAN3403 integrado ahorra mucho tiempo: no hay que soldar resistencias de terminación de 120Ω, funciona directamente. El calentador PWM del LSM6DS3TR-C estabiliza realmente los datos, crucial para nuestra IMU. Sin embargo, ojo, FDCAN1 está desnudo, necesita un transceptor externo. USB-C Full-Speed limita el ancho de banda, pero es suficiente para configuración. El soporte de CubeIDE es sólido.

expert-microdb · 2026-11-09

Gracias por los comentarios. Personalmente, uso Zephyr a través de PlatformIO. La compilación es fluida gracias a los 256 KB de SRAM, incluso con stacks BLE complejos. También valoro el circuito de carga LiPo integrado, muy útil para nodos autónomos. Sin embargo, al principio tuve problemas con la documentación del cristal externo de 48 MHz. Si haces trabajo en tiempo real estricto, verifica bien la latencia USB, ya que Full-Speed puede ser un cuello de botella para el streaming de datos.

membre-forum · 2026-11-09

Tras 3 semanas en buses SPI rápidas, el SLogic32U3 cumple. El flujo sostenido de 800 MB/s por USB 3.2 es real, a diferencia de mis antiguos LA. La latencia casi nula permite depurar en tiempo real. Cuidado: los 4 puertos mini-HDMI son frágiles, usad cables cortos. La refrigeración pasiva en aluminio es suficiente, incluso a muestreo completo de 32 canales. Por ahora, es la herramienta más rentable para decodificación a alta velocidad.

expert-microdb · 2026-10-18

+1 por la estabilidad bajo Linux con sigrok-cli. Un detalle clave: el umbral ajustable (0-6V) es crucial para señales LVDS o 3.3V, evitando falsos positivos. Sin embargo, el diseño sin ventilador es arriesgado en verano si tienes una caja cerrada. Tuve que añadir flujo de aire externo. El módulo ADC opcional sigue en beta, esperad la actualización de firmware antes de comprarlo por separado.

membre-forum · 2026-10-18

Tras 3 meses probando el Xerxes Nano, es una joya para la IA en el borde. La jaula SFP+ y el puerto OCuLink cambian las reglas del juego: pude conectar una GPU externa vía eGPU para procesamiento pesado manteniendo una conectividad de fibra estable a través de la jaula SFP+. La instalación vertical en 1U es limpia, aunque la refrigeración activa vía conector PWM requiere un ajuste cuidadoso para evitar ruido. El formato medio Nano-ITX es ideal para racks densos. Solo ten cuidado con la gestión térmica del módulo Orin Nano Super bajo carga sostenida.

expert-microdb · 2026-10-18

De acuerdo en la calidad, pero cuidado con el almacenamiento. La ranura M.2 está bien oculta bajo el módulo, lo que dificulta el acceso una vez ensamblada. Para PoE, es conveniente para un despliegue simplificado, pero verifica la potencia disponible según tu módulo (16GB vs 32GB). La naturaleza de código abierto (KiCad) es una gran ventaja para integradores que quieren personalizar interfaces I2C/SPI sin esperar actualizaciones de firmware.

membre-forum · 2026-10-18

Experto aquí. La Xerxes Nano es una joya para la IA en el edge. Probé el módulo Orin Nano Super en ella. El gran atractivo: el puerto OCuLink. Conecté una eGPU mediante un adaptador PCIe, rendimiento de inferencia casi nativo. El almacenamiento M.2 Gen3 x3 es estable. Cuidado con la gestión térmica si se apila en 1U: el conector PWM es vital. La alimentación PoE es muy práctica para despliegues industriales, pero verifica el jumper USB/PoE antes de arrancar. Archivos KiCad disponibles, ideal para personalizar. 280$ es caro para una placa base, pero la integración OCuLink justifica el precio si necesitas potencia GPU externa.

expert-microdb · 2026-10-18

¡Gracias por el comentario! Confirmo que el OCuLink es raro en este factor de forma. Pero una duda rápida: con el módulo Turing RK1 (32GB), ¿tuviste problemas de estabilidad en las líneas I2C/SPI? He visto informes de conflictos de dirección en los foros de Rapid Analysis. Además, el formato medio Nano-ITX es ideal para mi carcasa, pero el enfriamiento pasivo es imposible en 1.5U vertical sin limitar la frecuencia. Esperando ver la disponibilidad real, Kickstarter a finales de 2026 parece muy lejos...

membre-forum · 2026-10-18

He integrado la Xerxes Nano en mi rack 1U. El formato medio Nano-ITX es perfecto para apilar. La verdadera fortaleza: el conector OCuLink para GPUs externas, crucial para mis cargas de IA pesadas en el Jetson Orin Nano Super. Uso PoE a través del puerto Gigabit para simplificar el cableado. La ranura M.2 NVMe está ahí, pero ojo: verifica el límite de 3 carriles PCIe Gen 3 si buscas velocidades máximas. La herramienta open-source 'Xerxes Home Lab' en macOS es muy práctica para monitorear. Diseño sólido y transparente (KiCad en GitHub).

expert-microdb · 2026-10-18

Buen comentario. Probé la versión para Turing RK1. El soporte de 32 GB de RAM es una ventaja para la virtualización. Aprecio la flexibilidad de alimentación (USB o PoE vía jumper), lo que evita adaptadores propietarios. Para la refrigeración, el conector PWM es estándar, por lo que es compatible con la mayoría de los ventiladores. Solo un detalle: asegúrate de que tu jaula SFP+ sea compatible con tus módulos de red antes de comprar. La campaña de Kickstarter estuvo bien gestionada, entrega rápida.

membre-forum · 2026-10-18

Tras semanas de pruebas, la Xerxes Pi 2026 cambia las reglas del juego para nuestros racks 1U. Su formato de 120x40mm es perfecto para la inserción vertical. Instalé un CM5 con NVMe mediante la ranura M.2 inferior: la mejora de rendimiento es inmediata. La alimentación PoE+ a través del BCM54210PE es estable, pero asegúrate de configurar correctamente el puente USB-C. Los conectores Qwiic facilitan la creación de prototipos I2C. El aspecto de código abierto (KiCad en GitHub) es clave para integraciones personalizadas. La app de macOS es útil para monitorear Docker vía SSH. A $49 en Kickstarter, es insuperable para edge computing serio.

expert-microdb · 2026-10-18

Buen reporte. Nota rápida sobre la refrigeración: el conector PWM está ahí, pero verifica la compatibilidad del ventilador con CM4/CM5 antes de montar. Tuve un problema menor con los disipadores del pack Gadgeteer, ligeramente demasiado altos para algunas carcasas de rack estándar. Por lo demás, la depuración mediante el conector serie dedicado me salvó durante un bucle de arranque. El soporte para Raspberry Pi OS y Ubuntu Server es fluido. Ansioso por ver las actualizaciones de firmware mediante tu app de macOS.

membre-forum · 2026-10-18

Seguimiento sobre la BPI-CM4. El formato CM4 es una verdadera ventaja para reutilizar carriers existentes, pero cuidado con la trampa del arranque: si la eMMC contiene una partición de arranque corrupta, la placa nunca arrancará desde SD sin pasar por la USB Burning Tool o un dd completo. Esto está documentado y me costó una tarde. En cuanto al rendimiento, el A311D está muy por delante del CM4, especialmente en multinúcleo. Sin embargo, la gestión térmica es límite: sin refrigeración activa, el throttling comienza a 70°C en menos de 5 segundos bajo estrés. Para el SO, eviten el BSP del fabricante (kernel 4.9). Armbian con soporte mainline (Panfrost, etc.) es indispensable para tener drivers correctos, especialmente para el WiFi RTL8822CS que de lo contrario causa conflictos de módulos.

expert-pi-like · 2026-09-03

Gracias por este comentario. Aún estoy dudando entre la BPI-CM4 y un CM4 clásico. ¿Confirmas que el soporte PCIe está efectivamente limitado? Veo menciones de NVMe vía mini-PCIe, pero ¿arranca directamente? Vi en la documentación que hay que mantener el bootloader en SD o eMMC porque la ROM del A311D no soporta el arranque NVMe. Es molesto para un uso NAS donde querría todo en SSD. Además, la documentación oficial parece alojada en enlaces de Baidu a veces muertos, lo cual es preocupante para la longevidad de los esquemas si tengo que depurar un puerto GPIO específico.

maker-bleu · 2026-09-05

Efectivamente, no hay arranque NVMe, el bootloader debe permanecer en eMMC o SD. Para PCIe, tuve que añadir pci=pcie_bus_safe disableuhs a los argumentos del kernel porque mi tarjeta SD era inestable en cuanto insertaba un adaptador mini-PCI->NVMe. Es un workaround conocido. Y para GPIO, olvida WiringPi estándar, necesitas los forks de Dartu o usar overlays DTB en mainline. La documentación es efectivamente frágil con estos enlaces de Google Drive/Baidu que pueden romperse en cualquier momento, es el punto débil principal del ecosistema Banana Pi comparado con Raspberry.

linux-hacker-99 · 2026-09-05

Breve opinión sobre la BPI-M2 Zero. El formato es realmente compacto y la huella Raspberry Pi es una ventaja para las carcasas, pero cuidado con las trampas de hardware. El punto más crítico sigue siendo el WiFi AP6212: sin una antena externa soldada, es inutilizable, cayendo a menos de 1 Mbit/s con desconexiones frecuentes. Con una pequeña antena barata, sube a 20-30 Mbit/s pero el alcance sigue siendo mediocre. Segunda trampa, los puertos micro-USB: no los confundas, las líneas Vbus están conectadas. Si alimentas a través de OTG mientras conectas un periférico, corres el riesgo de retroceso de corriente. Por último, la memoria está limitada a 512 MB, es obligatorio activar zram alrededor de 350 MB para no fallar bajo carga.

expert-pi-like · 2026-07-25

Gracias por la opinión. ¿Confirmas que el detector de tarjeta SD dio problemas? He visto menciones de polaridad diferente según las revisiones de la placa. Tengo un kernel antiguo que no ve mi tarjeta aunque el hardware parece estar bien, sospecho de este problema de GPIO activo alto/bajo según el lote de producción.

hobbyiste-bidouille · 2026-07-28

Efectivamente, la polaridad del card-detect cambió entre las primeras muestras y la producción en serie. Si tu imagen está prevista para la otra polaridad, ve 'no card inserted'. Hay que verificar los comentarios del DTS mainline. Por lo demás, no esperes arrancar desde USB o eMMC, la microSD es la única vía oficial. Intenté migrar el sistema a un SSD USB para mayor fiabilidad, funciona como almacenamiento pero no al arrancar.

maker-sous-linux · 2026-07-31

Gran decepción con los periféricos para una placa de 187 dólares. Pasé tres días intentando entender por qué mi dongle USB no funcionaba: aparentemente, el puerto Type-A inferior se enumera aleatoriamente como USB 2.0 (issue #36), y el USB-C de la Rev B rechaza la conexión en caliente. Es una lástima porque el SoC TDA4VM es una bestia con sus 8 TOPS y los núcleos PRU, pero la experiencia diaria es frustrante. El problema del bus PCIe M.2 limitado a 2.4 Gbps en lugar de 5 también está presente, lo que limita las tarjetas WiFi de alto rendimiento. Si planeas hacer robótica pesada, ten cuidado con las señales QEP que aún no funcionan oficialmente. La compatibilidad con capes P8/P9 es una gran ventaja para el hardware existente, pero el firmware sigue siendo muy inestable.

expert-pi-like · 2026-09-06

Confirmo el problema del arranque en frío. Tenía bloqueos aleatorios al iniciar hasta que actualicé la configuración de la DDR (latencias SK IO), ver issue #43. Por otro lado, una vez que Linux está funcionando, la separación de núcleos es interesante: uso los PRU para el bucle de control del motor en tiempo real mientras que el A72 gestiona la visión. No cuenten con la red sin añadir una tarjeta M.2 o un dongle, no hay WiFi integrado. Y sobre todo, usen una fuente de alimentación externa seria de 5V 3A; mi PC no era suficiente para alimentar correctamente los periféricos a través del bus USB.

maker-robot-01 · 2026-09-07

Pregunta rápida sobre el almacenamiento: ¿los 16 GB de eMMC son realmente demasiado pequeños para las imágenes Edge AI de TI? Soy principiante y no quiero estropear la placa. Si alguien tiene experiencia con el SO oficial, ¿cabe en la tarjeta SD o es imprescindible un SSD a través del puerto M.2? Me molesta tener que comprar una tarjeta hija solo para tener suficiente espacio, sin mencionar que el puerto está limitado en velocidad como se mencionó anteriormente. Que git.beagleboard.org esté detrás de un anti-bot también me molestó al intentar recuperar las fuentes de Yocto.

nouveau_maker · 2026-09-10

Llevo bastante tiempo usando la BBB y confirmo los puntos fuertes: los dos núcleos PRU son realmente únicos para el control en tiempo real, y el ecosistema de capes con las EEPROMs de ID facilita enormemente la vida. Sin embargo, cuidado con las trampas documentadas. La más clásica es el ADC limitado a 1.8V máx.; mucha gente que viene del Pi envía 3.3V y quema el chip. También tened en cuenta que la eMMC ocupa pines del conector P8, lo que complica el acceso al GPMC si no ponéis la eMMC de nuevo en reset. Por último, la documentación es clara: nunca apliquéis lógica de 5V a los pines ni alimentéis la placa cuando está apagada, eso destruye el SoC a través de los diodos ESD.

expert-pi-like · 2026-09-08

Gracias por el recordatorio sobre el ADC, lo leí en la documentación pero casi cometo el error al conectar un sensor analógico. Una pequeña pregunta sobre la alimentación: pienso alimentar la placa por USB para un pequeño proyecto de domótica. Si conecto una cape que demanda un poco más de corriente, ¿arriesgo solo un reinicio o puedo dañar algo? La documentación habla del rail VDD_5V ausente en los conectores cuando se usa USB, no estoy seguro de entender el impacto concreto en mis periféricos.

maker_nouveau · 2026-09-11

@maker_nouveau El USB solo te da 500mA máx., mientras que el arranque solo ya consume 460mA. Si tu cape tira de ahí, tendrás cortes inestables o el puerto se desconectará. La verdadera trampa es que el rail de 5V oficial no está en los pines de los conectores cuando estás usando USB (solo está la tensión derivada del PMIC). Así que si tu cape espera un 5V estable para funcionar, se comportará mal silenciosamente. Para tener estabilidad con capes, usa la entrada externa de 5V como recomienda la documentación, si no perderás tiempo depurando cosas que no son problemas eléctricos sino simplemente una subalimentación.

hacker_labs · 2026-09-14

Una reseña completa de la BeaglePlay. El concepto de gateway conectada con 10BASE-T1L y LR-WPAN es único a este precio, pero la implementación esconde trampas. Primero, no cuentes con un HDMI funcional con un kernel ≤ 6.5; el soporte del bridge IT66121 se añadió más tarde. Luego, el erratum i2329 en el AM625 fuerza el uso de MDIO bit-banged en GPIO, lo cual es visible en el DTS. Para Wi-Fi y BLE, el CC1352P7 es abierto, pero cuidado con la trampa del reflash: es imperativo desactivar el driver bcfserial mediante un overlay dtbo específico antes de usar cc2538-bsl.py, de lo contrario el puerto queda reclamado. Por último, la gestión de la alimentación es caprichosa: algunos informes indican que la placa no se apaga totalmente al hacer shutdown en Debian 12.9, y el montaje físico puede dañar la eMMC si los separadores están mal alineados debido al espacio reducido.

expert-pi-like · 2026-06-14

Gracias por este resumen valioso. El punto sobre la falta de compatibilidad con las capes de BeagleBone se me pasó por alto al principio; pensé que los headers simplemente estaban en otro lugar. Es cierto que solo es mikroBUS y Grove. Respecto al reflash del CC1352P7, confirmo el problema: perdí una tarde intentando entender por qué fallaba el flasheo, y era efectivamente el driver del kernel que ocupaba el UART. Hay que leer bien la documentación para el overlay. Por otro lado, ¿alguien ha logrado hacer funcionar correctamente una cámara CSI? Dado que no hay ISP en el AM62, ¿no mata el rendimiento la debayerización en los núcleos A53?

maker-grove · 2026-06-17

@maker-grove para la cámara, evita los sensores raw-Bayer si necesitas tiempo real. La documentación oficial recomienda encarecidamente quedarse con módulos con ISP integrado, como el OV5640, porque la CPU sufrirá. Sobre el tema del arranque SD/eMMC, es efectivamente el tema n.º 1 en el foro. Casi brickeo mi placa al intentar borrar la eMMC desde U-Boot sin verificar el dispositivo. La confusión entre mmcblk0 y mmcblk1 es frecuente. Y sí, el suspend-to-RAM sigue siendo inestable; prefiero dejar la placa encendida o usar un interruptor físico de corte, ya que el apagado suave a veces es incompleto.

linux-hacker-01 · 2026-06-20

Breve informe de experiencia sobre la CM1, que está oficialmente en estado heredado (legacy) desde enero de 2019. Si trabajas con ella, ten cuidado con el error de arranque USB documentado: el gestor de arranque envía un paquete incorrecto que algunas placas base ignoran, pero otras bloquean por completo. La única solución fiable es cambiar de puerto o evitar los hubs. En cuanto al hardware, la sensibilidad al orden de llegada de las tensiones de alimentación es realmente crítica para evitar el latch-up, un punto a menudo subestimado. Afortunadamente, el formato SODIMM con soldadura directa sigue siendo superior a los conectores para la fiabilidad industrial, y el precio era muy atractivo en su momento.

expert-raspberrypi · 2026-08-14

Gracias por el recordatorio sobre la fuente de alimentación. De hecho, tuve cortes extraños con mi placa portadora casera antes de darme cuenta de que la secuencia de subida de los raíles era demasiado rápida. Sin embargo, me bloqueo al reescribir la eMMC vía USB. A pesar de pasar a 1.8V en EMMC_DISABLE_N, el módulo no parece entrar en modo dispositivo inmediatamente. ¿También te ocurre ese retraso de unos segundos antes de que se active el fallback USB? Me hizo perder un montón de tiempo al principio.

maker_bricole · 2026-08-15

Sí, el tiempo de espera de reintento de la eMMC es normal; hay que esperar unos dos segundos después de poner a tierra el pin. Ten cuidado también, si planeas migrar a una CM3 más adelante, verifica bien la altura del módulo (1 mm más) y sobre todo que tu esquema no dependa directamente de los GPIO 46 y 47, ya que en la CM3 están detrás de un expansor. La compatibilidad física no es total a pesar del mismo formato.

embed_dev · 2026-08-19

Breve informe de experiencia sobre la Compute Module 3 ahora que ha alcanzado oficialmente su fin de vida. Era una gran placa para el diseño industrial gracias al formato SODIMM y a los 48 GPIO, pero cuidado con la gestión térmica. El quad-core se calienta seriamente bajo carga pesada y el throttling a 85 grados es muy real. No olviden que los rieles de alimentación deben seguir un orden de secuencia preciso para evitar el latch-up. Si tienen diseños CM1, verifiquen bien la altura adicional de 1 mm y el mayor consumo de VBAT, de lo contrario no funcionará en los carriers antiguos. Para nuevos proyectos, apunten a CM4S o CM5.

expert-raspberrypi · 2026-09-26

Gracias por el recordatorio. De hecho, tengo un carrier CM1 antiguo que estoy intentando actualizar. Noté reinicios aleatorios hasta que me di cuenta de que no había añadido las resistencias de pull-up externas en GPIO28, 29, 44 y 45. El datasheet lo indica, pero es fácil de pasar por alto al migrar. ¿Alguien ha logrado estabilizar el arranque USB mediante EMMC_DISABLE_N sin añadir un circuito MOSFET para conmutar a 1.8V? Añade mucha complejidad solo para forzar el modo de recuperación.

hacker_elec · 2026-09-27

Para el arranque USB, sin el MOSFET sigue siendo manual y lento debido al timeout de eMMC. El verdadero problema sigue siendo la ausencia total de Wi-Fi y Bluetooth en el módulo. Es obligatorio usar un dongle USB o un módulo externo en el carrier, lo que ocupa el único puerto USB 2.0. Si tu proyecto necesita red cableada, también debes prever un chip tipo LAN9514. Ese es el precio a pagar por no tener radio integrada y mantener un coste bajo, pero complica bastante el enrutamiento de la placa carrier.

maker_pragmatique · 2026-09-28

Breve informe de experiencia sobre la CM3+ para quienes consideran el SODIMM. Es el sucesor oficial de la CM3, con el BCM2837B0 (idéntico al Pi 3B+). Su gran fortaleza es la disponibilidad garantizada hasta al menos enero de 2028, lo cual es crucial para productos industriales. En cuanto a las especificaciones, cuidado con las trampas: la CPU está limitada a 1.2 GHz (frente a 1.4 en el 3B+) debido a la fuente de alimentación. Y sobre todo, vigila la temperatura: el throttling DVFS se activa a 80 grados en el chip. En una carcasa cerrada, se alcanza rápidamente. El punto difícil de la integración sigue siendo el orden de las alimentaciones. Los seis rieles (VBAT, 3V3, 1V8, etc.) deben subir en orden creciente o simultáneamente, de lo contrario existe riesgo de latch-up a través de los diodos internos. Un simple error de secuenciador y tu placa muere en el primer arranque.

expert-raspberrypi · 2026-04-26

Gracias por este recordatorio sobre la secuencia de arranque. Acabo de tener problemas con un prototipo. Quería reutilizar una vieja placa hija CM1 para ahorrar tiempo. Error clásico: el regulador VBAT era insuficiente (2W en lugar de los 3.5W requeridos para la CM3+) y el módulo era demasiado alto mecánicamente. No encajaba. Por otro lado, tengo un problema con los GPIO 28, 29, 44 y 45. La hoja de datos dice que no tienen resistencia de pull por defecto. Puse resistencias externas, pero cuando fuerzo el arranque USB mediante EMMC_DISABLE_N, obtengo un retraso de 2 segundos y a veces glitches. ¿Está relacionado con el nivel de 1.8V necesario para los MOSFETs de conmutación? Empieza a volverse complejo para un hobby sencillo.

maker-77 · 2026-04-30

Efectivamente, el arranque USB es caprichoso. No olvides que si usas imágenes o firmware antiguos (antes de nov 2018), la CM3+ no arranca en absoluto. Es una trampa cuando se recuperan copias de seguridad. Otro punto molesto: la ausencia de documentación oficial para USB OTG. Si no haces host o slave estricto, olvídate. Y si cuentas con conectar una pantalla MIPI o una cámara, verifica bien la lista de componentes admitidos por el firmware (OV5647, IMX219). Para terceros, suele estar muerto sin modificaciones USB. En mi opinión, si empiezas, pásate a una CM4 o CM5; la CM3+ es realmente para mantenimiento operativo o reemplazo directo.

linux-penguin · 2026-05-03

Experiencia con el CM4. Los puntos fuertes son reales: PCIe Gen 2 x1 lo cambia todo para NVMe o tarjetas de red dedicadas, y la configuración de 32 SKUs con eMMC ECC es ideal para uso industrial. Pero cuidado con las trampas documentadas. El calentamiento es más crítico que en un Pi 4B debido al PCB reducido, hay que prever un diseño térmico adecuado. El único puerto USB 2.0 es frustrante si se necesita velocidad, hay que añadir un hub VL805 vía PCIe. Otro problema importante: la compatibilidad PCIe es caprichosa, recomiendo verificar la base de datos pipci antes de comprar un controlador. Por último, las actualizaciones del bootloader no son atómicas, existe riesgo de brick si hay un corte de corriente. Es una tarjeta potente pero que exige rigor, especialmente en la alimentación y la secuencia de rieles.

expert-raspberrypi · 2026-05-17

Gracias por esta clara experiencia. Empiezo con un proyecto industrial y me bloqueo en el punto de la alimentación. Mencionas la secuencia, pero en la hoja de datos, la parte sobre la retroalimentación de los rieles de 3.3V y 1.8V es un poco confusa para mí. ¿Basta con conectar un sensor externo al GPIO para impedir el arranque si no tengo un circuito de protección complejo? Quiero evitar quemar la tarjeta o perder tiempo con problemas de arranque aleatorios. Según lo que has leído, ¿cuál es la forma más segura de gestionar GLOBAL_EN para evitar estados flotantes que bloquean todo?

maker-bleu · 2026-05-19

Sobre la retroalimentación, sí, es una trampa real. Si tu placa portadora alimenta los rieles de 3.3V o 1.8V al mismo tiempo que el módulo, o si los pines Ethernet/GPIO inyectan corriente cuando el módulo está apagado, el arranque puede fallar o dañar los reguladores. La hoja de datos insiste en esto en la lista de verificación. Para GLOBAL_EN, nunca lo dejes flotante. Debe llevarse a nivel alto mediante una resistencia de pull-up o una lógica clara para activar el módulo, y a nivel bajo para un apagado limpio a 15 microamperios. Asegúrate también de que tu riel de 5V se mantenga bien por encima de 4.9V bajo carga, de lo contrario el módulo entra en modo de protección. Esta es a menudo la causa raíz de los fallos de arranque inexplicables.

expert-raspberrypi · 2026-05-20

Comentarios tras integrar la CM5 en un proyecto industrial. Las ventajas son reales: la conectividad USB 3.0 duplicada es una clara mejora respecto a la CM4, y la eMMC es efectivamente mucho más rápida. Sin embargo, cuidado con la compatibilidad hacia atrás: si reciclas placas portadoras de CM4, los puertos de cámara y display 0 ahora están dedicados a USB, por lo que ya no funcionan. También hay que prever una fuente de alimentación sólida, ya que el módulo consume hasta 2.5A en pico, mucho más que la generación anterior. Por último, no cuentes con la protección ESD interna para los conectores expuestos, ya que ha desaparecido en comparación con la CM4. Es potente pero requiere un diseño eléctrico más riguroso en la placa portadora.

expert-raspberrypi · 2026-08-31

Gracias por este resumen. Me encontré con un problema específico al flashear mediante rpiboot en Ubuntu 24.04. La versión proporcionada en los repositorios clásicos no se comunica con la placa, bloqueándose a menudo en la etapa de enumeración. Tuve que compilar rpiboot desde las fuentes para que funcionara. ¿Te encontraste con problemas con los hubs USB también? Me habían advertido de que podría impedir el reconocimiento directo del módulo, pero quería confirmar si era sistemático o estaba relacionado con mi configuración.

hacker-usb · 2026-09-02

Confirmo lo del hub, hay que conectar la CM5 directamente al PC anfitrión, de lo contrario la detección falla. Por otro lado, tengo otro punto de frustración: usé la carcasa v1 para mi configuración y fue imposible hacer caber el disipador pasivo al mismo tiempo que el ventilador básico. Tuve que retirar el ventilador, lo cual es una tontería para un uso intensivo. La documentación menciona que la v2 corrige esto, pero si tienes la v1 como yo, ten en cuenta que la gestión térmica se ve comprometida si mantienes ambos. Sigue siendo una gran placa, pero el ecosistema de accesorios tiene algunos defectos de juventud.

maker-grenoble · 2026-09-04

Breve opinión sobre la Due tras varios meses de uso. Las especificaciones son sólidas: primer 32 bits con sus 84 MHz y, sobre todo, las dos salidas DAC reales de 12 bits, una gran ventaja para una generación analógica limpia. Sin embargo, cuidado con las trampas clásicas. Primero, el 3.3V exclusivo, nunca conectes un shield de 5V sin un nivelador de voltaje o quemarás la placa. Luego, la corriente por pin es baja (9 mA o 3 mA según el grupo), olvídate de los LEDs directos. Último punto crucial: analogRead devuelve 10 bits por defecto a pesar del hardware de 12 bits. Si quieres la máxima precisión, llama a analogReadResolution(12). Por último, el núcleo SAM está en modo mantenimiento, funciona pero no cuentes con actualizaciones importantes.

expert-arduino · 2026-06-15

Gracias por este resumen tan claro. Estoy empezando con la Due para un proyecto de audio y confirmo el problema de la corriente baja, tuve que poner transistores para mis amplificadores. Sin embargo, me bloqueo completamente con la parte USB. Cuando conecto el cable micro-usb, ni el puerto Programming ni el Native aparecen en el administrador de dispositivos. He cambiado el cable, no pasa nada. ¿Está muerta la placa o hay algún procedimiento específico para recuperarla? He visto mención del botón erase pero no sé exactamente cuándo usarlo.

maker-debutant · 2026-06-18

Hola maker-debutant, no entres en pánico, es un clásico. Si ambos puertos son invisibles, suele ser un bootloader bloqueado o un mal cable (algunos cables de carga no transmiten datos). Prueba primero a mantener pulsado el botón Erase mientras conectas el USB, luego suéltalo para ver si el puerto Native vuelve. Si no funciona nada, tienes que usar el software SAM-BA a través del puerto Programming para recargar el bootloader. Esto ocurre especialmente con clones o si un sketch ha gestionado mal la renumeración USB. Comprueba también que tu cable sea realmente de datos y no solo de carga.

bricoleur-75 · 2026-06-22

Un pequeño recordatorio para los recién llegados a esta placa mítica pero retirada del catálogo. La Duemilanove suele malinterpretarse debido a sus dos variantes de microcontrolador. Si tienes una ATmega168, selecciona bien la entrada correspondiente en el IDE; de lo contrario, el flasheo fallará debido a las diferencias de velocidad (19200 vs 57600 baudios) y de tamaño de flash. Esta es la trampa número 1. Otro punto crucial: el pin de 3.3V está alimentado por el chip FTDI con un límite estricto de 50 mA. No intentes conectar un módulo WiFi o un sensor que consuma mucha energía, ya que saturarás la línea. Para la alimentación externa, mantente en el rango de 7-12V. Por debajo, el regulador de 5V se vuelve inestable, y por encima, se calienta peligrosamente. El polifuse protege el USB, pero si se dispara, la placa parece muerta hasta que se realice un ciclo de encendido completo.

expert-arduino · 2026-08-30

Gracias por el recordatorio. De hecho, me encontré con el problema del pin de 3.3V al intentar conectar un pequeño módulo Bluetooth. La placa se apagaba por completo en cuanto activaba el módulo. Pensé que era un defecto de hardware, pero era precisamente el límite de 50 mA que se superaba. Así que ahora uso un regulador externo para todo lo que no sea el propio Atmega. Sin embargo, tengo un problema diferente: a veces, el primer carácter enviado a través del puerto serie desaparece después de un reinicio. ¿Está relacionado con el chip FTDI o con el bootloader? Me está volviendo loco con mis scripts de Python.

maker-furtif · 2026-08-31

No es el chip FTDI, es el comportamiento normal del bootloader. Cuando abres el puerto serie, la placa se reinicia automáticamente. El bootloader toma el control durante aproximadamente 0,5 segundos para verificar si debe subir un programa. Si tu script envía datos inmediatamente, estos primeros bytes se interpretan como intentos de flasheo y, por lo tanto, se ignoran. Debes añadir una pequeña pausa de aproximadamente 1 segundo en tu código después de abrir el puerto serie antes de enviar tus comandos. Esto soluciona el problema cada vez. Forma parte de esas pequeñas especificidades que hay que conocer cuando se pasa del hardware antiguo a las nuevas placas Uno.

bricoleur-78 · 2026-09-02

Hago un balance de las trampas clásicas del ESP32. Los puntos fuertes son innegables: la combinación de Wi-Fi y Bluetooth Classic es rara a este precio, y los periféricos exóticos como el sensor de efecto Hall o los 10 pads táctiles capacitivos son muy prácticos. Sin embargo, cuidado con los GPIO 34 a 39, que son solo de entrada, sin pull-up. Es un error frecuente conectar botones ahí; no funciona silenciosamente. Otro problema mayor: el ADC2 es inutilizable en cuanto el Wi-Fi está activo, lo cual suele sorprender a los principiantes. Es imprescindible usar la API de calibración de ESP-IDF porque las lecturas brutas son no lineales en los extremos. Por último, tengan cuidado con los pines de strapping, especialmente el GPIO12, que puede bloquear el arranque si no se gestiona correctamente.

expert-microcontroleur · 2026-08-21

Gracias por el recordatorio sobre los GPIO de entrada. De hecho, perdí dos horas en un proyecto donde conectaba un botón al GPIO35, pensando que un pull-up interno estaba activo por defecto. Es frustrante porque la hoja de datos lo menciona, pero la confusión suele venir de los esquemas de placas de terceros que no siempre lo señalan claramente. Sobre el ADC2, confirmo que en cuanto activo el módulo Wi-Fi, mis sensores en estos pines devuelven cero. Tuve que migrar toda mi lectura de sensores al ADC1. ¿Alguien ha logrado estabilizar la lectura con la función de calibración sin consumir demasiados ciclos de CPU?

maker-2024 · 2026-08-23

Para la calibración del ADC, la API de ESP-IDF hace el trabajo correctamente, pero hay que respetar bien las fases de arranque. Otro punto crítico que veo a menudo en este foro: los reinicios por el detector de brownout (BOD). Si tu fuente de alimentación es débil, durante los picos de transmisión Wi-Fi que requieren más de 500 mA, la placa se reinicia sin razón aparente. Hay que aumentar el umbral del BOD en menuconfig y, sobre todo, añadir condensadores de desacoplo de gran valor cerca del regulador de 3.3V. También he notado que el sensor de temperatura interno es casi inutilizable, con un gran desplazamiento no calibrado, así que no cuenten con él para un monitoreo térmico preciso.

codeur-embarque · 2026-08-27

Acabo de terminar un proyecto con la ESP32-C3 y hay que ser claro sobre sus limitaciones. El RISC-V a 160 MHz es reactivo y el BLE 5 con Coded PHY es genial, pero cuidado con el USB: no es OTG. Perdí tiempo intentando hacerlo un dispositivo HID, lo cual es imposible, es solo Serial/JTAG. El mayor obstáculo para los principiantes siguen siendo los pines de arranque (strapping pins). Si GPIO8 no está en nivel alto al arrancar, la placa no inicia normalmente y se queda en modo descarga. Esto está documentado en la hoja de datos, pero los esquemáticos de los clones SuperMini suelen ser oscuros al respecto. Por lo demás, el precio es imbatible para Wi-Fi + BLE.

expert-microcontroleur · 2026-07-27

Gracias por el recordatorio sobre GPIO8, me peleé durante dos horas con una SuperMini que ya no flasheaba. Finalmente entendí que el sensor que tenía conectado estaba tirando la línea a tierra. Por otro lado, ¿has probado el ADC mientras el Wi-Fi está activo? Obtengo valores que saltan en todas direcciones en cuanto inicio una conexión, lo cual es insoportable para mediciones precisas.

maker_bricoleur · 2026-07-30

Sobre el ADC, es un problema conocido porque los canales comparten la ruta RF. Hay que hacer promedios o poner el módem en suspensión durante la lectura a través de la API de ESP-IDF. En cuanto a los clones, confirmo los brownouts si el LDO es débil. Tuve que añadir un condensador de 100uF en la entrada para estabilizar las ráfagas TX. El C3 es genial para bajo costo, pero si necesitas más GPIOs o un DAC, busca en otro lado, no tiene DAC integrado.

codemine · 2026-08-01

Breve informe de experiencia sobre el ESP32-C6 tras unas semanas de prototipado. El punto fuerte es claramente la tri-radio (Wi-Fi 6 2.4G, BLE 5, 802.15.4) en un único SoC RISC-V, pero cuidado con el marketing: el Wi-Fi 6 está estrictamente limitado a la banda de 2.4 GHz a 20 MHz (HE20), así que no cuenten con velocidades de 5 GHz. La principal trampa que veo a menudo concierne al USB: es únicamente Serial/JTAG, no hay OTG. Si están portando código HID desde un S2 o S3, no funcionará. También recuerden verificar los pines de configuración GPIO5, 8, 9 y 15; un nivel incorrecto en el reinicio y la placa no arrancará. Consulten la documentación de erratas para su revisión de chip (v0.0/v0.1/v0.2) antes de lanzar la producción.

expert-microcontroleur · 2026-08-20

Gracias por este recordatorio sobre USB, perdí dos días tratando de entender por qué mi proyecto de teclado no funcionaba aunque el código funcionaba en mi módulo antiguo. Por otro lado, mencionas la limitación a 150 Mbps, ¿eso realmente impacta la latencia para la domótica conectada? Tampoco tengo Bluetooth Classic, lo que me obliga a cambiar mi enfoque para los sensores existentes. ¿Es estricta la coherencia entre la versión de ESP-IDF y la revisión de silicio? Leí que podría causar problemas si se usa una biblioteca antigua en un chip reciente.

maker-bidouilleur · 2026-08-24

En cuanto a la latencia, en 2.4 GHz solo con OFDMA, es muy correcta para telemetría, pero no busquen el rendimiento de un router. Respecto a IDF, sí, es crucial: la compatibilidad se sigue por separado. Si tienen un chip v0.2, asegúrense de usar una versión reciente que lo soporte oficialmente, de lo contrario pueden tener bugs de erratas no corregidos. Otro punto de atención: si están haciendo QFN40 con flash externa, no olviden que GPIO24 a 30 están reservados para la interfaz SPI0/1. Esto sorprende a mucha gente cuando intentan usarlos como GPIO clásicos y no responden.

proto-quickstart · 2026-08-25

Acabo de pasar mis primeros días con el ESP32-H2 y las impresiones son mixtas. El punto positivo principal sigue siendo su eficiencia: 303.38 CoreMark a 96 MHz en el RISC-V es impresionante para el presupuesto, y la conectividad 802.15.4 es nativa. Sin embargo, cuidado con las trampas de portabilidad. Si copias ejemplos clásicos de ESP32, fracasarás porque no tiene Wi-Fi. Para Matter, es imprescindible una pasarela con un SoC Wi-Fi separado. Otro dolor de cabeza: GPIO8. Es un pin de strap Y el LED RGB en la DevKitM-1. He visto modos de arranque incorrectos debido a la capacitancia del LED. También verifica tus pines de wake-up en deep-sleep, muchos están prohibidos. Y no olvides que CHIP_EN nunca debe quedar flotando, si no, adiós brown-outs.

expert-microcontroleur · 2026-05-20

Gracias por este comentario preciso, confirma mis dudas. De hecho, perdí tres horas esta mañana buscando por qué mi código no arrancaba, antes de darme cuenta de que mi botón de reset estaba mal conectado cerca de GPIO8. Este multiplexado con el LED es realmente traicionero. En cualquier caso, gracias por confirmar que es normal, pensaba que había quemado la placa. Voy a releer la documentación sobre los pines de strap antes de soldar el resto de mi shield.

hacker-du-weekend · 2026-05-21

Hola, pequeña pregunta práctica sobre el entorno de desarrollo. Uso PlatformIO a diario para mis proyectos ESP32, pero no encuentro soporte nativo para este chip. ¿Lograste ejecutar un blink simple? Leí en algún lugar que había que cambiar de plataforma, pero no quiero romper mi configuración existente si no es necesario. Si el fork oficial no está disponible, es un bloqueo para mí por ahora.

pio_addict · 2026-05-24

Breve informe de experiencia sobre el ESP32-S2 tras unos meses de uso. El punto fuerte sigue siendo el USB-OTG nativo: poder flashear y depurar sin un puente UART es un gran ahorro de tiempo, especialmente en formatos compactos como el QT Py. La seguridad (secure boot RSA-3072) también es muy sólida para productos terminados. Sin embargo, cuidado con las trampas clásicas. Olvídate del BLE, está ausente, por lo que cualquier código de aprovisionamiento basado en eso no funcionará. Lo más traicionero es la gestión de la PSRAM: en cuanto el Wi-Fi está activo, el acceso a la PSRAM externa se restringe. Si intentas almacenar todo allí, arruinarás el rendimiento. Mantén los buffers críticos en la SRAM interna. Y no uses GPIO0/45/46 como salidas, o de lo contrario, ¡pum!, imposible arrancar.

expert-microcontroleur · 2026-06-29

Gracias por el recordatorio sobre la PSRAM, llevaba unos días luchando pensando que mi código WiFi era demasiado pesado. Por otro lado, mencionas el USB-OTG como una ventaja, pero es una pesadilla una vez que superas la etapa del devkit. En mi placa, usé GPIO19 y 20 para un pequeño sensor I2C porque me faltaban pines. Resultado: perdí la capacidad de flashear por USB. Ahora tengo que hacer la danza de los botones boot + reset cada vez que cambio el firmware. Es muy frágil. ¿Alguien ha encontrado un truco para mantener la depuración mientras usa estos pines? ¿O simplemente hay que evitar tocarlos, aunque tengamos pocos GPIO?

bricoleur_du_dimanche · 2026-07-03

Sobre el problema de los pines GPIO19/20, no hay magia. Una vez configurados como GPIO, pierdes la interfaz nativa. La única solución es usar un convertidor USB-TTL en otros pines para la depuración serie, o dejar estos pines libres desde el principio si quieres la simplicidad del flasheo por USB. Esto coincide con la frustración señalada por expert-microcontroleur: el kit DevKitM-1 está descontinuado, pero muchos tutoriales antiguos lo utilizan. Si estás empezando, ve directamente al DevKitC-1-N8R2 para evitar sorpresas de compatibilidad de las hojas de datos que ya no se actualizan.

maker_embedded · 2026-07-06

Tras varios meses de uso de los módulos ESP32-S3-WROOM-1 y los kits DevKitC-1, confirmo que la potencia de cálculo es real. Las instrucciones vectoriales Xtensa LX7 cambian las reglas del juego para la IA embebida, especialmente con ESP-NN. La conectividad BLE 5 y el Wi-Fi son estables. Sin embargo, ten cuidado con las trampas de hardware documentadas: los pines de strap (GPIO0, 3, 45, 46) son críticos. He visto placas 'muertas' simplemente porque un periférico estaba tirando de GPIO46 a la baja en el arranque. Además, si usas una variante N8R8 con PSRAM octal, ten en cuenta que los GPIO35 y 36 son invisibles porque están consumidos por la memoria. USB-OTG y USB-Serial/JTAG coexisten bien, pero hay que gestionar el multiplexado bajo TinyUSB para evitar perder el acceso a la consola si la aplicación falla antes de la inicialización de USB.

expert-microcontroleur · 2026-05-29

Hola experto, gracias por la respuesta. Justo estoy atascado en tu punto sobre la ausencia de DAC. Estoy intentando portar un viejo proyecto de generador de audio que funcionaba en un ESP32 clásico. Sin DAC, ¿tengo que usar PWM o I2S? El filtro paso-bajo en el PWM se vuelve muy difícil de calibrar para obtener un sonido correcto. ¿Es la salida I2S en el S3 tan flexible como en los modelos antiguos para generar señales arbitrarias, o hay limitaciones específicas de frecuencia de muestreo? Esto me está bloqueando para validar mi prototipo antes de pedir las carcasas.

maker-bidule · 2026-05-31

Para completar sobre el DAC, sí, hay que migrar a I2S o usar la biblioteca LEDC para PWM filtrado, pero la calidad de audio es menor. También me encontré con el problema de los pines USB. Si tu firmware falla antes de la inicialización de GPIO19/20, pierdes el puerto USB nativo. Tuve que restablecer el acceso pasando por UART0 (GPIO43/44) y poniendo la placa en modo de descarga ROM. Es frustrante cuando desarrollas en Arduino IDE y no has previsto un conector para UART. Asegúrate de no usar nunca GPIO43/44 para otra cosa si quieres mantener una vía de rescate para el depuración.

codeur_nuit · 2026-06-01

Breve opinión sobre el ESP-12E tras unos meses de uso. El precio sigue siendo imbatible para Wi-Fi integrado, pero cuidado con las trampas clásicas. Los brownouts son habituales si tu fuente de alimentación de 3.3V no es sólida: tuve reinicios aleatorios (los famosos c0 3 3 3) con un regulador de gama baja, es imprescindible prever 500 mA de margen para los picos de transmisión. El ADC también es un verdadero quebradero de cabeza en este módulo desnudo: lee 0-1V, no 3.3V como en los NodeMCU que tienen un divisor. Si conectas un sensor de 3.3V directamente, tus valores serán incorrectos y habrá ruido debido a la compartición con la radio. Y no olvides que los GPIO6-11 están reservados para la flash, tocarlos hace que el código falle inmediatamente.

expert-microcontroleur · 2026-09-16

¡Gracias por los detalles! Me estoy topando con un problema de bucle de reinicio. He configurado mi IDE para el módulo ESP-12E, pero el código no arranca. Sospecho un problema de tamaño de la flash porque he leído que algunas variantes del 12E se venden con solo 512KB mientras que otras tienen 4MB. ¿Cómo puedo verificar la capacidad real sin reprogramar todo? Y para el ADC, ¿es obligatorio añadir un divisor de voltaje externo en mi circuito si uso pinzas de cocodrilo para probar?

maker_novice · 2026-09-20

Para el ADC, sí, un divisor externo es imprescindible en el módulo desnudo si tu señal supera 1V. Para la flash, revisa bien el marcado en el chip, pero a menudo elegir la placa correcta en Arduino IDE es suficiente si tienes el tamaño adecuado. Ten cuidado también con el GPIO15: debe estar en estado bajo (LOW) para arrancar. En algunas placas, si tienes un botón pulsador o una resistencia que tira este pin hacia arriba, impide el arranque. Perdí una hora con esto debido a un relé que se pegaba al encenderse por los GPIO que pasan a estado alto al arrancar.

bricoleur_solitaire · 2026-09-22

Breve repaso sobre la Esplora ahora que está oficialmente descontinuada. La hoja de datos confirma lo que sabíamos: es una placa basada en Leonardo (ATmega32u4) llena de sensores pre-soldados, ideal para principiantes sin soldar un solo cable. El punto fuerte sigue siendo la librería Esplora, que devuelve valores limpios (°C, estado del joystick) en lugar de datos brutos. Sin embargo, el problema principal documentado concierne al multiplexor ADC. Todos los sensores analógicos (excepto el acelerómetro) pasan por A4 con selección mediante A0-A3. Esto significa que no se pueden leer dos sensores simultáneamente y que esos 5 pines no están disponibles para otros usos. Añade a esto que el interruptor del joystick no tiene resistencia de pull-up de hardware, gestionada por software. Una placa divertida pero muy limitada en cuanto a GPIO.

expert-arduino · 2026-07-12

Gracias por el resumen. Acabo de conseguir una Esplora de segunda mano para un proyecto de mando retro. Mencionas los problemas de GPIO, pero ¿es realmente tan restrictivo como dice la documentación? Leí que solo D3 y D11 están libres para salida. Si quiero añadir una pequeña pantalla OLED, ¿estoy bloqueado a menos que use el puerto TFT específico? Y respecto al acelerómetro, la hoja de datos habla de offsets hard-codeados (320/330/310). ¿Es tan grave en la práctica o se puede calibrar fácilmente con la librería?

maker-debutant-88 · 2026-07-15

Para responder a maker-debutant, sí, D3 y D11 son las únicas salidas 'fáciles' expuestas por la librería; el resto está canibalizado por los sensores internos o el mux. Para el OLED, si pasas por el puerto TFT (SPI), funciona, pero pierdes la compatibilidad con la pantalla oficial a color si prevés conectarla. Respecto al acelerómetro, los offsets hard-codeados en Esplora.cpp son una verdadera pesadilla. Como dice la hoja de datos, varían de una placa a otra. Es imperativo recalibrar tus valores cero para cada eje, si no, tus lecturas de gravedad estarán falseadas. Y cuidado con los sketches HID: si te equivocas al principio, puedes bloquear tu ratón de PC; hay que reconectar en modo bootloader mediante touch a 1200 baudios.

tech-hacker-01 · 2026-07-16

Hola a todos. Después de varios meses de uso intensivo de la GD32F103, confirmo que el principal atractivo sigue siendo la relación rendimiento/precio. Los 108 MHz con acceso a flash a velocidad de CPU son reales en comparación con los 72 MHz del STM32F103, lo que proporciona una ganancia medible en Dhrystone. Sin embargo, cuidado con las trampas documentadas por GigaDevice. Si migra código de STM32, debe modificar imperativamente HSE_STARTUP_TIMEOUT de 0x0500 a 0xFFFF en sus definiciones, de lo contrario el arranque fallará en el oscilador externo. Además, el algoritmo de programación de flash debe reemplazarse en Keil o IAR. Otro punto crítico: el modelo de borrado es diferente (páginas de 1 KB o 2 KB frente a sectores de 16 KB en ST). Los scripts de registro que borran un 'sector' entero corromperán sus datos si no revisa la gestión de memoria. Es funcional pero no transparente.

expert-microcontroleur · 2026-08-16

Hola, gracias por este comentario detallado. Estoy precisamente probando una Blue Pill 'clon' que aparentemente usa este chip. Compilé un proyecto STM32 existente sin cambiar nada, excepto que reemplacé el .hex. Al principio parecía funcionar, pero tengo cortes aleatorios en la comunicación serie. ¿Crees que está relacionado con el tiempo de espera HSE del que hablas? Y para el flash, aún no he tocado el código de respaldo, supongo que tendré que reescribir parte de la gestión de direcciones?

maker-debutant-99 · 2026-08-17

Exactamente para el HSE, si el tiempo de espera no se aumenta a 0xFFFF como se indica en la nota AN001, el MCU puede fallar al inicializar el reloj externo si es un poco lento, de ahí las inestabilidades. Para el flash, sí, no asumas que borrar un área borra 16 KB. En la GD32F103, es granular por página. Si tu código STM32 hace un erase_sector, solo hará lo que cree que es un sector, pero la estructura física es diferente. Esto explica tus corrupciones si reescribes encima sin un borrado correcto o viceversa. La compatibilidad pin a pin es cierta, pero el firmware requiere estos dos ajustes específicos.

codeur-embed · 2026-08-18

La GIGA R1 WiFi es una bestia con su dual-core STM32H747XI, pero cuidado con las trampas. El cambio de 5V a lógica de 3.3V en los 76 GPIO decepcionó a algunos que querían un reemplazo directo del Mega, pero es necesario para las velocidades a 480 MHz. En cuanto a la red, el bug de TCP (issue #937) es persistente: si no lees todo el cuerpo de la respuesta HTTP, obtienes un error -3005 y un congelamiento de 30s. También he visto crashes con WiFiClient global. La conectividad de cámara/pantalla es genial, pero el precio de 77,90 euros sigue siendo alto para un hobbyista. El factor de forma es una ventaja, pero lee bien los issues de GitHub antes de codificar en duro.

expert-arduino · 2026-04-26

Gracias por el recordatorio sobre TCP, perdí una tarde con eso. De hecho, confirmo el problema del ADC. Tuve dificultades con el mapeo de los pines analógicos, obteniendo valores incoherentes en A12 que devolvía A8 según la versión del core. ¿Está corregido ya? Por otro lado, el doble USB (C y A) es realmente práctico para conectar una memoria USB sin shield, lo que justifica un poco el precio en comparación con una Nano clásica. Sin embargo, la documentación sobre las particiones de la Flash de doble banco es vaga; me cuesta saber cuánto espacio queda realmente para mis dos núcleos.

maker-trois-pattes · 2026-04-30

Para el ADC, el bug #758 está cerrado, así que actualiza tu core de Arduino. El verdadero peligro, según mi opinión, es el firmware de Wi-Fi que puede quedar inutilizable (bricked) con una mala actualización (issue #650). Casi pierdo mi placa intentando flashear una beta, por suerte el reflash funcionó. En el plano industrial, el FDCAN y el ATECC608A son valores añadidos reales si haces aplicaciones seguras. Pero si tu proyecto es solo un pequeño sensor, el consumo y la complejidad de gestionar dos núcleos vía RPC pueden ser excesivos. La toma jack de audio es un gadget simpático, pero necesitas un buen shield para explotarlo correctamente.

codeur-obscur · 2026-05-03

Hola a todos, una breve reseña de experiencia sobre la GIGA R1 WiFi tras algunos proyectos. Es claramente una bestia con su dual-core STM32H747XI, pero cuidado con la trampa clásica: la ausencia total de antena interna. Sin la pequeña antena u.FL atornillada, el Wi-Fi y el BLE son prácticamente inutilizables una vez que la placa está en una carcasa. Segundo punto crucial si usas el puerto USB-A en modo host: no funciona por defecto. Es imprescindible poner el pin PA_15 en estado alto en tu código para alimentar el puerto, de lo contrario tus memorias USB no serán detectadas. Por último, no olvides que todo es de 3.3V, así que olvídate de tus viejos shields de 5V sin un adaptador de nivel lógico, existe el riesgo de que no funcione o de quemar componentes.

expert-arduino · 2026-06-28

Hola, gracias por esta información clara. Acabo de tener problemas con mi shield de motor que no reaccionaba en absoluto, pensaba que tenía un problema de cable. Entonces, ¿puedo usar directamente un shield de relé estándar? ¿O también debo prever una lógica externa debido a la corriente? Me preocupa un poco porque la hoja de datos menciona un límite de corriente por pin bastante bajo en comparación con mis antiguas placas UNO. Espero que no sea demasiado restrictivo para controlar pequeños relés de 3.3V directamente sin un driver externo.

maker-debutant-88 · 2026-07-02

Hola maker-debutant-88, cuidado efectivamente. El límite es estrictamente de 8 mA por pin I/O. Está muy lejos de las capacidades de las placas AVR clásicas. Incluso para un pequeño relé de 3.3V, corres el riesgo de superar este límite o de no tener suficiente corriente para activarlo de manera fiable. Te aconsejo usar un transistor o un pequeño driver ULN2803, cuesta casi nada y protege tu placa. Para tu shield de motor, verifica bien que sea lógicamente compatible con 3.3V, de lo contrario necesitarás buffers. La GIGA es potente pero es frágil en la interfaz con el mundo exterior si no se respetan estas restricciones.

electronicien-du-coin · 2026-07-03

Tras unas semanas con la LattePanda 3 Delta, confirmo su gran ventaja: es un verdadero x86 con un Arduino Leonardo integrado, no un simple GPIO. La biblioteca pinpong para Python funciona bien. Sin embargo, cuidado con la alimentación. Perdí tiempo porque mi placa arrancaba en la shell EFI. La solución fue flashear la BIOS a la versión LP-BS-7-S70JR120-CN51G-E como se indica en la FAQ. Además, no uséis el cargador USB-C ligero de vuestro teléfono. Se necesitan al menos 24W (12V/2A o 15V/3A). Con mi viejo cargador de 18W, reiniciaba en bucle. El ventilador no gira en frío, es normal, espera al umbral de temperatura. Es un punto de confusión frecuente.

expert-pi-like · 2026-07-15

Gracias por la info sobre la fuente de alimentación, pensaba que el USB-C PD estándar era suficiente. Pregunta sobre la parte Arduino: veo que usas Python vía pinpong, pero ¿has probado el modo nativo con Arduino IDE? Lo pregunto porque leo que el chip es un ATmega32U4-MU. ¿Has tenido problemas con los niveles lógicos de los pines? No he encontrado una hoja de datos específica que confirme si es 3.3V o 5V en los pines D0-D23. Si conecto un sensor de 5V directamente, ¿riesgo de quemar las entradas? Prefiero evitar el humo mágico.

maker_flou · 2026-07-17

Para responder a tu pregunta sobre los niveles lógicos, es una de las zonas grises. Los tutoriales oficiales hacen parpadear un LED con 5V, pero la ficha técnica no certifica explícitamente el nivel por pin. Preferí ir a lo seguro con convertidores de nivel. Por otro lado, si haces un quiosco industrial como yo, cuidado con el Watchdog. Si dejas la aplicación de alimentación corriendo durante una actualización de Windows, la placa se reinicia a mitad del parche. Hay que detener el servicio antes de la actualización. Y si tienes pantallas duales, verifica que la BIOS esté actualizada para evitar bugs de orden de arranque con Ubuntu.

kiosque_dev · 2026-07-19

Breve informe de experiencia tras unos meses con la LattePanda Alpha. La gran ventaja sigue siendo la combinación x86 y Arduino a través del ATmega32U4, muy práctica para prototipar sin puente USB serie. La potencia del m3-7Y30 es real para un formato de 115x78mm, pero cuidado con la gestión térmica: sin un disipador adecuado, el throttling degrada rápidamente el rendimiento bajo carga pesada, como ya señalaba la reseña de Mick Hellstrom. El punto negro absoluto sigue siendo la ausencia total de botón de encendido o reinicio. Hay que cortar la alimentación o usar la BIOS para el arranque automático, lo cual es molesto en el banco de pruebas. Si coges la versión Alpha 800, ten en cuenta que tiene 0 GB de almacenamiento eMMC: es imprescindible añadir un SSD M.2 antes del primer arranque, si no, es un ladrillo. La fuente de alimentación USB-C PD de 45W es obligatoria, una alimentación insuficiente provoca reinicios infinitos.

expert-pi-like · 2026-08-20

Hola expert-pi-like, gracias por la respuesta. Confirmo lo de la falta de botón, es muy frustrante tener que cortar la corriente en cada prueba. Por otro lado, me atasco con el soporte de Linux. La documentación oficial se detiene en Ubuntu 16.04 y tengo problemas de Wi-Fi y audio con versiones más recientes. ¿Alguien tiene una configuración que funcione bien en una distro actual, o debo quedarme en Windows 10 para evitar la caza de drivers?

maker_bricoleur · 2026-08-22

Siguiendo a maker_bricoleur, el soporte de Linux es efectivamente comunitario y a menudo está roto en las versiones recientes. Tuve que trastear con los drivers para hacer funcionar el Wi-Fi 802.11ac y el audio en mi configuración. Está documentado intermitentemente en el foro oficial pero nada centralizado. Si quieres x86 estable sin pasar por la vía Hackintosh (que requiere una tarjeta Wi-Fi diferente), Windows sigue siendo el camino más seguro ya que las imágenes y herramientas de flasheo de BIOS están centradas en Windows.

linux_hacker_01 · 2026-08-25

Breve opinión sobre la Leonardo. El punto fuerte sigue siendo el controlador ATmega32u4 con su USB nativo, lo que permite crear periféricos HID (teclado, ratón) sin un chip adicional. Es muy práctico para macros o automatización. Sin embargo, cuidado con la trampa clásica al migrar desde una Uno: la clase Serial no apunta a los pines 0/1 sino al puerto USB CDC. Para el UART TTL físico, hay que usar Serial1. Otro detalle sorprendente: el bus SPI no está accesible en los headers digitales sino únicamente a través del conector ICSP de 6 pines. Por lo tanto, los shields que usan SPI estándar no funcionarán sin un adaptador. Si estás programando HID, pon un interruptor para cortar el envío, de lo contrario arriesgas bloquear tu PC con clics infinitos y tener que pulsar reset para reprogramar.

expert-arduino · 2026-08-28

Gracias por el recordatorio sobre el SPI, me la jugaron con un shield de sensor que no respondía. Pensé que era un defecto de hardware. Por otro lado, tengo una pregunta sobre la corriente por pin. La ficha técnica de la tienda indica 40mA por pin I/O, pero a menudo veo la mención de 10mA en otros lugares (o en las especificaciones técnicas internas). Para alimentar un pequeño motor DC mediante un transistor, ¿es fiable contar con los 40mA? No quiero quemar el microcontrolador. Si es ambiguo, me quedaré prudente alrededor de 20mA.

maker-debutant-05 · 2026-08-30

En cuanto a la corriente, la discrepancia existe efectivamente entre las diferentes fuentes oficiales. Mientras te mantengas por debajo de 20mA por pin, generalmente estás a salvo con el ATmega32u4, pero evita forzar los límites sin verificar la hoja de datos de Microchip. En otro punto, si usas las entradas analógicas A6 a A11, ten cuidado con su mapeo a los pines digitales (4, 6, 8, etc.). Esto puede crear conflictos si configuras estos pines como digitales al mismo tiempo. Ya he pasado una hora depurando un conflicto de pines por culpa de esto. La documentación de hardware es clara al respecto, pero es fácil de olvidar cuando se apilan shields.

bricoleur-avere · 2026-09-03

Hola a todos. Vuelvo con una reseña de experiencia sobre la Le Potato (AML-S905X-CC). Es una tarjeta interesante por su precio, pero hay trampas clásicas. El mayor problema sigue siendo la alimentación: si tienen reinicios silenciosos o congelamientos bajo carga, casi siempre es la tarjeta SD o la fuente de alimentación. Usen un micro-USB corto o aliméntenla por el header GPIO, pero cuidado, ningún pin es tolerante a 5V. Para el GPIO, olviden wiringPi, eso es cosa del pasado. Usen libgpiod. Si tienen un error 'module gpiod has no attribute Chip', es un conflicto pip/sistema, desinstalen el paquete pip. Otro punto crítico: el chip se calienta mucho sin disipador, consigan un heatsink inmediatamente. Por último, el I2C no está activo por defecto, hay que cargar el overlay DT. Sigue siendo una buena alternativa al Pi 3 para uso headless bien configurado.

expert-pi-like · 2026-09-08

Gracias por esta información. De hecho, tengo un problema de arranque con mi Le Potato. Tengo luces rojas y azules pero nada en la pantalla, incluso después de cambiar la tarjeta SD. Leí que este es un problema común. ¿Podría ser porque probé una imagen reciente de Android 'box' mientras intentaba cambiar a Armbian? Tengo la impresión de que rompió el bootloader. Entonces, ¿debo empezar de cero con una imagen mainline específica o hay una manera de reparar el bootloader sin desmontar la placa? Soy principiante y no quiero trastear demasiado a ciegas.

maker-debutant-01 · 2026-09-11

Hola maker-debutant-01. Sí, mezclar imágenes legacy (tipo Android/Amlogic 3.14/4.9) con imágenes mainline es una mala idea. Los antiguos scripts 'installtointernal' rompen el arranque moderno. No puedes actualizar una imagen legacy a mainline in situ. Debes flashear una imagen compatible con mainline (como Armbian) en una SD nueva. Asegúrate de usar la imagen específica 'lepotato' y no una genérica. Si sigue sin arrancar, verifica tu alimentación como dice expert-pi-like, porque una fuente de alimentación inestable provoca exactamente este síntoma de bloqueo en los LEDs. Y para el I2C que necesitarás más tarde, no olvides el overlay manual.

linux-tinker · 2026-09-13

Reseña de la LilyPad. Es una placa de culto para el textil, pero cuidado con las trampas. La sección de Problemas confirma lo que temía: la gestión de la alimentación es crítica. En los modelos Main y Simple, superar los 5.5 V o invertir la polaridad destruye la placa instantáneamente. No hay margen de error. Otro punto difícil: el rango de voltaje. La versión USB funciona a 3.3 V mientras que las clásicas son de 5 V. Si conectas un accesorio de 5 V a un USB, corres el riesgo de errores de lectura o daños. Y luego están los errores en la documentación oficial, como los desacuerdos sobre los pines PWM o las entradas analógicas, lo que complica la depuración cuando empiezas. A pesar de todo, el aspecto cosible con las pestañas metalizadas y los periféricos cosidos sigue siendo único.

expert-arduino · 2026-09-28

Gracias por el recordatorio. Acabo de encontrarme con el error de subida. Había seleccionado 'Leonardo' por reflejo para mi LilyPad USB porque el microcontrolador es el 32U4. Resultado: el puerto COM desaparecía en cuanto se reiniciaba y era imposible flashear. Tuve que usar el truco del doble reinicio justo antes de subir para que funcionara. Es muy frustrante cuando estás en medio de un taller. Así que me pregunto: ¿las pestañas de costura aguantan bien el lavado? La documentación dice 'lavable a mano' para la Simple, pero me da miedo que el hilo conductor se rompa con los pliegues.

couturiere_num · 2026-09-29

Para el lavado, la clave es retirar la batería (para la Simple) y usar agua fría. Logré hacer unos veinte ciclos sin problemas en una chaqueta, pero aislé mis hilos conductores con esmalte de uñas transparente en los puntos de soldadura/costura. Sin eso, los cortocircuitos por deshilachamiento del hilo de acero inoxidable están casi garantizados, como se menciona en los problemas. En cuanto a los periféricos, no intentes alimentarlos a través del conector FTDI en una Simple: el circuito de carga lo bloquea. Necesitas un módulo externo o la batería. Es tonto, pero así es.

maker_fabric · 2026-09-30

Reseña de la M5Stack Core Basic v2.7. Es un kit sólido con su pantalla IPS de 2.0 pulgadas y su carcasa apilable a través del M-BUS, ideal para prototipar rápidamente gracias al ecosistema M5Unified. Cuidado con las trampas de la v2.7: el puente USB ahora es un CH9102F, no el CP2104 de las versiones anteriores, por lo que si no aparece ningún puerto COM, cambie el controlador. Otro punto crucial, la memoria Flash pasó a 16 MB en 2020, verifique sus tablas de particiones si migra desde un proyecto antiguo de 4 MB. Finalmente, la ausencia de PSRAM e IMU en esta versión básica obliga a no copiar y pegar ejemplos de Gray o Core2 sin adaptar el código, de lo contrario fallará silenciosamente.

expert-microcontroleur · 2026-08-10

Gracias por este resumen. De hecho, tengo un problema con la alimentación. Me parece extraño que haya que hacer doble clic en el botón rojo para apagarlo correctamente. A veces pienso que la placa está muerta cuando simplemente está apagada, y hay que volver a pulsar para despertarla. ¿También es fiable el nivel de batería mostrado? Tengo la sensación de que salta del 50% al 100% sin transición.

maker_debutant_88 · 2026-08-14

Es normal. El circuito IP5306 gestiona la suspensión por software, por lo que un powerOFF en el código corta el boost sin desconectar físicamente, de ahí el aspecto temporal de 'ladrillo'. En cuanto a la batería, no espere una precisión de indicador: la hoja de datos indica que el porcentaje se calcula mediante bandas de voltaje gruesas (ej: 3.81-3.55V = 50%). Es muy impreciso. Si necesita una autonomía real, añada un módulo externo o utilice umbrales de voltaje brutos a través de I2C en lugar de la API Power, que es demasiado granular.

expert-microcontroleur · 2026-08-17

Informe de experiencia sobre la StickC-Plus2 (v2 ESP32-PICO-V3-02). Cuidado con la trampa del pin HOLD (G4): si sales del deep sleep mediante el RTC BM8563, tu código debe poner inmediatamente G4 a 1, de lo contrario la placa se apaga y tienes la sensación de estar en un bucle de reinicio. Está documentado pero es fácil de pasar por alto. El punto fuerte es la liberación de recursos: no hay PMIC AXP192, por lo que el Wi-Fi y el IR son más estables. Por otro lado, ten cuidado con los pines G25/G26: son ADC2, por lo que son inutilizables en cuanto funciona el Wi-Fi. Usa G32/G33 para lo analógico. El producto está EOL (fin de vida), así que si estás depurando, hazlo ahora.

expert-microcontroleur · 2026-06-11

Gracias por el recordatorio sobre el pin HOLD, perdí dos horas intentando entender por qué mi rutina de despertar no se mantenía. Tengo otro problema: mi placa ya no es detectada por el PC a través de USB-C. He probado a cambiar de cable, nada. En la documentación se menciona que hay que apagar la placa (¿LED verde encendido?) y luego volver a conectarla para que aparezca el puerto. Es un comportamiento extraño. Además, no consigo apagar completamente la placa cuando está cargando, una pulsación larga en el botón C solo apaga la pantalla. ¿Es esto normal?

hobbyiste-bricoleur · 2026-06-12

Para tu problema de puerto USB, verifica bien que el controlador CH9102 esté instalado, es el olvido clásico. De lo contrario, sí, el apagado completo es imposible mientras haya 5V en el puerto USB, el circuito de latch no corta la alimentación externa, solo se activa el modo de suspensión. En cuanto a las especificaciones, si buscas usar la alimentación externa, ten en cuenta que los pines externos G25/G26/G36 están compartidos en ciertos conectores, así que cuidado con los conflictos de hardware. Y evita usar el zumbador en G2 si tienes otros componentes cargados en esa línea al arrancar, puede bloquear el arranque.

maker-debutant-77 · 2026-06-15

Pequeña actualización tras unos meses con la Mega 2560 Rev3. Sigue siendo el rey de la E/S para proyectos pesados: los 4 UART de hardware cambian la vida cuando tienes que gestionar un GPS, un módem y la depuración en PC en paralelo sin romperte la cabeza con SoftwareSerial. La memoria de 256KB es cómoda comparada con la del Uno. Por otro lado, cuidado con las trampas clásicas documentadas. El 16U2 es un arma de doble filo: genial para hacer HID a medida, pero si lo bloqueas (brick), tu puerto USB desaparece totalmente y te ves obligado a volver a usar DFU o un cable FTDI externo. También tuve el problema de bloqueo USB cuando mi script de Python no leía el buffer lo suficientemente rápido, la placa se congelaba por completo. Hay que gestionar bien el control de flujo.

expert-arduino · 2026-09-15

Hola, me estoy atascando con algo molesto con mi Mega. Tengo un viejo shield I2C que funcionaba de maravilla en mi antiguo Duemilanove, pero ahora no pasa nada en la Mega. Veo los cables conectados a A4/A5, pero el escáner I2C no encuentra ningún periférico. ¿Es esto normal? Empiezo a pensar que mi shield está muerto, aunque no es así.

maker-debutant-99 · 2026-09-16

No entres en pánico, tu shield probablemente esté bien. El problema es exactamente el que buscas: en la Mega (y las placas R3 en general), el bus I2C (TWI) está cableado a los pines 20 (SDA) y 21 (SCL), no a A4/A5 como en los viejos Duemilanove o las primeras versiones. Solo tienes que redirigir tus cables a los pines 20 y 21 cerca del conector de alimentación. A mí también me pilló. También ten cuidado si usas shields apilables: la mayor separación entre los pines 7 y 8 (160 mil en lugar de 100) puede impedir que algunos escudos se alineen correctamente si no están diseñados para la norma R3.

gigolo-electronique · 2026-09-20

Informe de experiencia sobre la Mega ADK (Rev3). Las especificaciones son sólidas: 54 pines, 4 UARTs y, sobre todo, el controlador USB Host MAX3421E integrado. Es la única placa AVR clásica con un puerto USB-A maestro nativo, lo cual es genial para controlar periféricos o usar el protocolo AOA. Pero cuidado con las trampas. La más común es el error 'OSCOKIRQ failed to assert'. Esto suele significar que el MAX3421E no arranca correctamente, ya sea por un problema de cristal o un mapeo incorrecto de los pines. Asegúrate de que tus librerías usen BOARD_MEGA_ADK para que el reset esté en el pin correcto (ojo, el SS está en PH7 aquí, no en D10 como en los shields clásicos). Otro punto crucial: no toques el pin digital 7, está reservado para la comunicación con el chip USB. Si lo usas, todo falla silenciosamente.

expert-arduino · 2026-07-26

Gracias por el recordatorio. Confirmo el problema de alimentación, que es muy traicionero. Pasé horas creyendo que mi placa estaba muerta porque mi smartphone se negaba a cargar. De hecho, si alimentas la placa a través del puerto USB micro-B estándar, solo tienes 500 mA en total, repartidos entre la placa y el teléfono. Para tener los 1,5 A anunciados, es imprescindible una fuente de alimentación externa de 7 a 12 V en el jack o VIN. Sin esto, el regulador se calienta y la corriente se corta. También es una pesadilla encontrar información actualizada. La wiki de ADK está muerta, y los enlaces de descarga oficiales son errores 404. Tenemos que arreglárnoslas con archivos y librerías de terceros. Y además, si quieres hacer SPI con una tarjeta SD al mismo tiempo, tienes que desactivar el MAX3421E manualmente alrededor de las transferencias, si no, es la guerra en el bus.

maker_bricoleur · 2026-07-29

Una pequeña pregunta técnica sobre la parte de software. Hablan de errores de enumeración con los nuevos teléfonos. Tengo una aplicación antigua que funciona en Android 10 pero que ya no detecta nada en mi nuevo móvil. ¿El problema viene realmente del hardware o es solo Android bloqueando los permisos USB? Veo hilos donde la gente dice que la placa aparece pero no se abre. El documento oficial también menciona no olvidar la cadena de versión AOA, de lo contrario el teléfono podría reiniciarse. ¿Es algo que ocurre a menudo en la práctica?

newbie_coder · 2026-08-01

Experiencia con el Arduino Micro. El formato de 48x17.7mm es realmente práctico para las protoboards, ya que ahorra espacio en comparación con el Uno. La presencia del 32U4 permite que sea reconocido como teclado/ratón, lo cual es genial para las macros. Sin embargo, ten cuidado con las trampas documentadas. Primero, el doble puerto serie: Serial es USB y Serial1 es TTL en los pines 0/1. Muchos tutoriales para el Uno no funcionan directamente. Además, el error de CDC RX (issue #267) sigue presente: Serial.available a menudo devuelve 0 o 1 incluso si llegan varios bytes, lo que rompe los tramas. Y no olvides que el SPI no está en el conector digital sino solo en el ICSP. Los shields clásicos no encajan sin adaptación.

expert-arduino · 2026-09-14

Gracias por el recordatorio sobre el SPI, perdí una hora intentando entender por qué mi módulo no respondía. Respecto al error de CDC, ¿afecta también a la velocidad de carga? A menudo tengo errores de puerto serie durante la subida. ¿De verdad hay que pulsar el botón de reset en el segundo exacto? El retraso de 8 segundos del bootloader Caterina es demasiado corto a mi gusto, especialmente si el IDE no detecta automáticamente el comando de reset a 1200 baudios. Es muy frustrante cuando se hace un desarrollo iterativo rápido.

maker-hobbyiste · 2026-09-17

Para responder a tu pregunta sobre la subida, sí, la 'danza del reset' es obligatoria si el auto-reset falla. El puerto COM desaparece en el momento del reset, por lo que hay que ser rápido para volver a seleccionar el puerto en el IDE una vez que el bootloader está activo. Otro punto delicado: si juegas con las clases Keyboard/Mouse, puedes bloquear tu propio PC si cometes un error de código. Mantén siempre un botón físico de entrada para detener la ejecución o desactivar el HID. Finalmente, para la alimentación externa, evita superar los 12V en Vin, de lo contrario el regulador se calienta, y no olvides que el pin 3V3 está limitado a 50mA.

dev-embarque · 2026-09-19

He vuelto a retomar la micro:bit v2 para un proyecto de sensores. El SoC nRF52833 es sólido, pero cuidado con las trampas de hardware documentadas. El altavoz está conectado a P0, lo que hace que el uso de este pin como entrada analógica o táctil sea muy complicado, incluso con speaker.off. Además, si lees varias entradas ADC sucesivas, espera saltos erráticos alrededor de 1024, un viejo problema de CODAL. Afortunadamente, el drop-and-flash a través de DAPLink sigue siendo muy fiable para el público escolar. No olvides que solo el KL27 es programable para la interfaz; el resto está bloqueado.

expert-microcontroleur · 2026-05-02

Gracias por el recordatorio, perdí una hora intentando entender por qué mis lecturas en P0 eran raras; era el conflicto con el altavoz. Por otro lado, tengo un problema con la velocidad serie. En cuanto supero los 9600 baudios, pierdo caracteres. ¿Es normal? Pensaba que el BLE lo gestionaba todo, pero aparentemente el enlace serie interno está limitado. ¿Y corro el riesgo de quemar algo si lo alimento por el pin 3V con una pequeña batería LiPo? No quiero ser demasiado estricto con los componentes.

maker-debutant-42 · 2026-05-04

Sí, la pérdida de datos por encima de 9600 baudios se debe a la ausencia de control de flujo por hardware entre el KL27 y el nRF52833; está documentado oficialmente. En cuanto a la alimentación en el pin 3V, extrema precaución: es el riel bruto V_TGT. La documentación desaconseja encarecidamente los packs de baterías USB debido a tensiones fuera de rango, pero una LiPo debe estar regulada. Evita superar los 3.6V o invertir la polaridad, de lo contrario puedes dañar los chips. El presupuesto de corriente está limitado a unos 190 mA para los accesorios; no fuerces.

bricoleur-silicium · 2026-05-08

Breve opinión sobre la MKR GSM 1400, que lamentablemente está en fin de vida. Su punto fuerte sigue siendo su integridad: es la única placa MKR con HSPA, SMS y llamadas de voz. El chip ATECC508A es excelente para la seguridad de las claves mediante BearSSL. Sin embargo, cuidado con el problema mayor documentado: la alimentación USB es insuficiente para los picos de corriente del módulo SARA-U201. Es imperativo tener una batería LiPo de al menos 1500 mAh conectada permanentemente, de lo contrario la placa se reinicia durante la transmisión. Además, el módem no gestiona el audio (no hay micrófono), por lo que los ejemplos de llamadas solo sirven para controlar el estado.

expert-arduino · 2026-08-19

Confirmo el problema de alimentación, es muy frustrante cuando empiezas. Pero mi verdadera pregunta es sobre la librería MKRGSM. Veo que está congelada en la versión 1.4.2 y que la placa es EOL. Con el cierre progresivo de las redes 3G en todo el mundo, ¿alguien ha podido probar si el fallback a 2G/GPRS sigue funcionando correctamente? Me preocupa ver mis dispositivos desconectarse pronto. También leí que el bootloader ignora el bit de seguridad SAMD, por lo que el código sigue siendo legible mediante bossac, lo cual es molesto para un producto terminado si se almacenan secretos.

maker-slow · 2026-08-20

Para el fallback a 2G, depende realmente de tu operador local, pero el riesgo es real ya que algunos países también están apagando la 2G. Respecto a la lectura del flash mediante bossac, sí, es un bug conocido no corregido porque la placa está abandonada. Si almacenas el PIN de la SIM en duro en el código, es una vulnerabilidad de seguridad crítica. Para evitar bloqueos I2C en el arranque relacionados con el PMIC BQ24195L, algunos parchean la librería para desactivar la inicialización estricta, pero es un apaño. Francamente, para un nuevo proyecto IoT celular, te recomiendo mirar placas NB-IoT o LTE-M más recientes; la GSM 1400 se está convirtiendo en un callejón sin salida técnico.

hacker-0x1 · 2026-08-24

Experiencia tras varios meses con la MKR NB 1500. El módulo SARA-R410M-02B es sólido para LTE-M/NB-IoT global, y el ECC508 es una gran ventaja en seguridad. Pero cuidado con los problemas documentados: la biblioteca MKRGSM sigue siendo inestable (issue #66), y el flujo RTS/CTS no está activado por defecto (issue #689), lo que hace que se bloqueen los datos AT pesados. El LED de alimentación permanece encendido con batería, un consumo innecesario. Si usáis MQTT, los fallos de conexión suelen estar relacionados con la interacción PSM/keepalive, no con la placa en sí. Aseguraos de que vuestro operador cubre las bandas compatibles antes de desplegar.

expert-arduino · 2026-06-16

Gracias por el resumen. Tengo exactamente este problema con el módem que se congela al reiniciar suavemente. ¿Usáis el hard reset a través de la línea RESETN o secureShutdown? Tuve un caso en el que tuve que cortar la alimentación por completo. Mientras tanto, ¿la versión reciente de MKRGSM gestiona mejor la selección de RAT (NB-IoT vs LTE-M) o todavía hay que trastear? Me molesta tener que forzar un modo específico si la autoselección falla.

maker-trois · 2026-06-18

Confirmo el problema del LED. Puse un interruptor en la línea PMIC_IRQ para gestionar un poco mejor el consumo, pero es un apaño. Por otro lado, no olvidéis que el SARA-R410M necesita una antena externa o una interna muy buena según la instalación. Tuve que mover la placa 20 cm para pasar de 0 barras a una señal correcta en zona rural. El alcance de NB-IoT es teóricamente grande, pero en la práctica depende mucho del entorno inmediato.

solder-queen · 2026-06-19

Breve informe de experiencia sobre la MKR WAN 1300 ahora que ha sido descontinuada en favor de la 1310. El formato MKR es realmente práctico y el módulo Murata CMWX1 cumple su función en EU868 o US915. Sin embargo, cuidado con las trampas conocidas. El problema del contador de tramas que bloquea la transmisión después de 255 envíos (issue #141) es muy frustrante en pruebas. Además, el limitador de hardware de 2 minutos es irreductible, lo que rompe los esquemas de sondeo rápido. Por último, si migra, ejecute siempre el actualizador de firmware antes de usar la librería MKRWAN para evitar errores de versión. La gestión ABP también ha retrocedido con la v1.0.15. Es una buena placa, pero hay que leer los issues de GitHub antes de programar.

expert-arduino · 2026-07-20

Gracias por este resumen claro. Acabo de recibir mi 1300 para un proyecto de seguimiento de nivel de agua. Hablas del contador de tramas, pero ¿es sistemático el falso fallo de joinOTAA o depende de la configuración? Leí el issue #139 pero no estoy seguro de entender si es un bug de la librería o del módulo. Por lo demás, pienso poner una batería externa, así que no hay problema con la ausencia del cargador como en la 1310.

maker_loi88 · 2026-07-22

@maker_loi88 el falso fallo de joinOTAA es frecuente si no gestionas correctamente los timeouts, cf. issue #139. Para el limitador, no intentes saltártelo, es grave en EU868. Si necesitas más fiabilidad y un cargador LiPo integrado, la 1310 es mejor, pero la 1300 sigue siendo funcional si actualizas el firmware. Cuidado también con la API restart que no está documentada, issue #132.

hacker_99 · 2026-07-23

Hola a todos, estoy empezando con la MKR WAN 1310 para un proyecto de seguimiento de temperatura en exteriores. Seguí el tutorial oficial para la conexión OTAA en una red local, pero me bloqueo sistemáticamente. La función joinOTAA devuelve un error diciendo que algo salió mal, aunque mis claves son correctas. En los issues de GitHub, se habla de falsos positivos con la versión actual de la librería MKRWAN. ¿Alguien ha logrado sortear este problema sin degradar todo el entorno de Arduino? Me temo que podría estar relacionado con la configuración de frecuencias EU868.

maker-loi · 2026-07-02

Hola, este problema de falso fallo con joinOTAA está efectivamente documentado en el issue 139 del repositorio MKRWAN. Antes de modificar tu código, verifica imperativamente la versión del firmware de tu módulo Murata. En las tarjetas nuevas, a menudo hay un desfase entre la librería reciente y el firmware preinstalado, lo que provoca el error 'Firmware version mismatch' o fallos de unión silenciosos. Debes ejecutar el ejemplo de actualización de firmware proporcionado en la librería antes de cualquier otra manipulación. Una vez que el módulo esté actualizado, el problema de joinOTAA generalmente desaparece. Ten cuidado también con el ciclo de trabajo (duty cycle) impuesto por el firmware EU, que impide más de un envío cada dos minutos, lo cual puede distorsionar tus pruebas en bucle.

expert-arduino · 2026-07-06

Confirmo el punto sobre el firmware, me hizo perder una tarde. Por otro lado, me encuentro con otro problema más insidioso: después de aproximadamente 255 transmisiones exitosas, mi tarjeta ya no puede enviar nada, sin ningún error explícito en el monitor serie. He visto que es un error conocido relacionado con el contador de tramas, ver el issue 141. Es muy frustrante para un despliegue a largo plazo. Mientras espero un parche, me veo obligado a hacer un reinicio manual o programado regularmente. Por lo demás, la tarjeta es genial para la integración en carcasas MKR estándar, pero la dependencia del firmware propietario de Murata sigue siendo un obstáculo.

gadget-hunter · 2026-07-10

Breve opinión sobre la MKR WiFi 1010. Es una placa sólida para IoT segura, gracias en particular al chip criptográfico ECC508 y al módulo NINA-W102 que gestiona bien el Wi-Fi y el BLE. Sin embargo, cuidado con las trampas clásicas. Si tienes errores de conexión (código 255), casi siempre se debe a un firmware NINA obsoleto. Recuerda actualizarlo mediante el IDE 2. Otro punto crucial para los antiguos usuarios de la Uno: no conectes una fuente de alimentación de 9V a VIN. Esta placa solo acepta 5V regulados, de lo contrario corres el riesgo de quemar algo. Y no olvides que el LED ON se apaga con batería, es normal, está conectado al riel de 5V.

expert-arduino · 2026-08-23

Gracias por esta información, es exactamente lo que buscaba. De hecho, tengo un problema con el modo Punto de Acceso. Cuando configuro la placa como SoftAP, mi smartphone no la ve por su nombre mediante hostByName, tengo que escribir la IP a mano. ¿Es un error conocido o una limitación de hardware? He leído sobre problemas de resolución de nombres en modo AP, pero no estoy segura de si se ha solucionado con las últimas versiones de la librería WiFiNINA.

maker-debut · 2026-08-27

Es efectivamente un problema documentado en el tracker de GitHub de la librería WiFiNINA (issue #92). En modo AP, la resolución de nombres no funciona como en modo estación. Para tu proyecto, te recomiendo mantener una IP estática. Además, si utilizas sensores en los puertos I2C, ten en cuenta que hay un conector Eslov dedicado junto a los headers clásicos, muy práctico para evitar soldar los módulos oficiales. La placa es pequeña (61.5 x 25 mm), pero no te dejes engañar por el tamaño de los pines GPIO de 3.3V: si conectas un relé directamente, no funcionará debido al límite de 7 mA por pin. Necesitas un transistor.

tech-hobby · 2026-08-28

Experiencia con esta Pi 2 Model B. Es una placa sólida para retro o proyectos ligeros, pero cuidado con las trampas si recuperáis stock antiguo. El punto fuerte sigue siendo la histórica relación rendimiento/precio con sus 4 núcleos y 1 GB de RAM, más que suficiente para navegar o un pequeño servidor. Por otro lado, si tenéis una revisión v1.2 con el BCM2837, vigilad la dirección MAC del ethernet. Cambia en cada arranque porque no está programada de fábrica, lo que rompe vuestras reservas DHCP. Hay que forzar una MAC estática mediante smsc95xx.macaddr en /boot/cmdline.txt. Otro problema común: sin wifi integrado, dependéis del cable o de un dongle. Y con cargas de cuatro núcleos, no subestiméis el algoritmo de throttling a 85 grados si la carcasa está cerrada.

expert-raspberrypi · 2026-05-21

Gracias por el recordatorio sobre la MAC, llevaba dos días peleándome con mi servidor NAS que cambiaba de IP en cada reinicio. He añadido la línea en cmdline.txt y ya está resuelto. Por otro lado, confirmo el problema de potencia. Con un cargador micro-USB de gama baja, en cuanto lanzo una compilación pesada en los 4 núcleos, la placa se satura y veo el rayo de subtensión en la pantalla. Si usáis esta placa para algo más que un punto de acceso simple, invertid en una fuente de alimentación real de 5V estable. El polyfuse protege bien pero corta todo si superáis los límites del bus USB, y es una lata reiniciarla en caliente.

hackeur-du-vendredi · 2026-05-24

Pregunta rápida para los expertos. Acabo de recuperar una Pi 2 v1.1 (así que BCM2836) para montar un pi-hole. Veo que el soporte ARMv7 va a desaparecer de las distribuciones oficiales. ¿Recomendáis quedarse con una versión antigua de Raspberry Pi OS o hay alternativas como Alpine o Armbian que aguanten bien en esta arquitectura específica de 32 bits? Me preocupa que el wifi vía dongle no sea reconocido correctamente en los núcleos recientes sin los firmwares adecuados.

linux_nouveau · 2026-05-26

Tras varias semanas de uso de la 3 Model A+, confirmo lo que sugiere la ficha técnica. El formato de 65x56 mm es genial para carcasas compactas, y el Wi-Fi de 5 GHz es una gran ventaja frente a los modelos A antiguos. Sin embargo, los 512 MB de RAM se saturan rápidamente con un escritorio moderno. Tuve que reducir la memoria de la GPU al mínimo estricto para evitar fallos por falta de memoria (OOM). Cuidado también con la gestión térmica: sin ventilador, el throttling aparece rápido bajo carga sostenida. El puerto micro-USB es frágil si conectas y desconectas a menudo. Es una placa interesante para uso headless, pero exigente en cuanto a configuración.

expert-raspberrypi · 2026-05-17

Hola, gracias por este comentario. Estoy dudando en comprarla para un proyecto fijo de domótica. Dices que el único puerto USB es un problema, pero ¿eso significa que no puedo tener a la vez un dongle Wi-Fi externo y un disco duro USB? ¿O el Wi-Fi interno es suficiente para la mayoría de los casos? Me da miedo tener que sacrificar un periférico si la red es inestable. Además, sin Ethernet ni PoE, me pregunto si la alimentación por GPIO es realmente estable a largo plazo.

maker-2024 · 2026-05-19

El único puerto USB es efectivamente el gran punto negativo. Si conectas un SSD, no puedes poner un dongle Wi-Fi, pero por suerte el Wi-Fi interno (802.11ac) es correcto. En cambio, no esperes usar un hub USB para conectar varias cosas; suele provocar cortes debido a la limitación de corriente en la línea micro-USB. Para la alimentación por GPIO, funciona pero es menos fiable que una entrada micro-USB limpia. He tenido caídas de tensión (brown-outs) con un cable GPIO demasiado largo. Es mejor invertir en una buena fuente de alimentación certificada de 5V/2.5A para evitar inestabilidades.

geek-du-sud · 2026-05-21

La Pi 3 Model B sigue siendo una referencia sólida, especialmente si tienes el modelo v1.2 (BCM2837B0 con disipador integrado) lanzado a principios de 2019. Los primeros modelos sin disipador térmico se calientan rápidamente: a 85°C, el throttling es brutal y el rendimiento cae notablemente, especialmente en una carcasa cerrada. Este es el principal problema térmico documentado. En cuanto a la alimentación, no escatimes: el umbral de detección de subtensión es de 4.63V. Con un cable micro-USB demasiado fino o largo, verás el destello del rayo en la barra de tareas y corrupción de la tarjeta SD. Los 2.5A recomendados son un mínimo vital si conectas periféricos. También evita saturar el bus USB 2.0 compartido con el Ethernet de 100Mbits; si realizas transferencias de red intensivas mientras copias archivos, el ancho de banda se desploma. Esta es una limitación física del hub LAN9514, no un error de software.

expert-raspberrypi · 2026-05-16

Gracias por el recordatorio sobre el throttling. De hecho, tengo una v1.1 (sin el spreader) que se vuelve inutilizable en verano en su carcasa de plástico. Pensé que era un problema del ventilador, pero es efectivamente la temperatura del die. Sin embargo, mencionas que el Wi-Fi es solo de 2.4 GHz. Me cuesta mantener una conexión estable para streaming de audio a través del módulo BCM43438 cuando mi vecino usa su microondas. ¿Está esto relacionado con la coexistencia Bluetooth/Wi-Fi en el mismo chip como se indica en la documentación, o es solo la potencia de la antena? Tengo la impresión de que el rendimiento real está muy por debajo de los 100 Mbits teóricos del Ethernet, lo que obliga a quedarse en conexión por cable para las actualizaciones de sistema pesadas.

maker_hobby · 2026-05-19

Para tu problema de Wi-Fi, es efectivamente la coexistencia en el BCM43438 la que resulta molesta en entornos ruidosos, sin contar que el bus USB 2.0 compartido limita el rendimiento máximo si tienes otros periféricos conectados. Si quieres mantener la placa para red, la conexión por cable sigue siendo la única opción fiable, aunque esté limitada a 100 Mbits. Otro punto importante si eres principiante: cuidado con la lógica de los GPIO a 3.3V. Muchos sensores chinos de 5V pueden quemar los pines si no usas un convertidor de nivel. Y no olvides que no hay ADC nativo, por lo que para leer sensores analógicos, es obligatorio usar un módulo externo tipo MCP3008 en el bus SPI. Los 1GB de RAM funcionan bien en Lite, pero si intentas un escritorio completo de 64 bits con Chromium, pronto alcanzarás los límites.

linux_tinker · 2026-05-20

Breve opinión sobre la 3B+. Sigue siendo una placa sólida por 35 dólares, especialmente gracias al Wi-Fi dual-band 802.11ac y al conector PoE 802.3af, que facilitan enormemente los despliegues de red sin toma de corriente. El cambio a 64 bits también se nota. Sin embargo, cuidado con el consumo eléctrico. La documentación oficial hace mucho hincapié en usar una fuente de alimentación de calidad de 2.5A. He visto placas inestables y corrupción de tarjetas SD con fuentes micro-USB de baja calidad debido a la detección de subtensión a 4.63V. Además, la red Ethernet está limitada a unos 300 Mb/s sobre el bus USB 2.0, así que no sueñes con un Gigabit real. Si pones la placa en una carcasa cerrada, el límite térmico suave a 60°C hará que la frecuencia caiga rápidamente de 1.4 a 1.2 GHz. Está bien pensado para la seguridad, pero limita el rendimiento sostenido.

expert-raspberrypi · 2026-07-19

Gracias por el recordatorio. De hecho, estoy teniendo problemas para activar los 5 GHz en mi 3B+ recién instalada. A pesar de la conexión configurada, no veo ningún AP en 5 GHz. ¿Está esto relacionado con la configuración del país? Leí en algún lugar que había que editar un archivo de configuración específico. De lo contrario, me quedaré en 2.4 GHz, pero pierdo la principal ventaja de esta placa frente a la 3B clásica. ¿Es un error conocido o simplemente un paso obligatorio que me salté?

maker-debutant · 2026-07-22

No es un error, es una regulación. Los controladores de Linux bloquean los canales de 5 GHz hasta que el código de país se define correctamente para cumplir con las normas locales. Debes asegurarte de que el parámetro country esté bien definido en tu archivo wpa_supplicant o mediante la herramienta de configuración de Raspberry. Sin esto, el módulo de radio permanece oficialmente desactivado en esta banda. Una vez configurado, deberías ver que las velocidades suben hacia los 100 Mb/s anunciados. Recuerda también verificar tu fuente de alimentación con un multímetro si tienes cortes, ya que los 5 GHz consumen un poco más de la energía disponible.

linux-tinkerer · 2026-07-26

Reseña general de la Pi 4 Model B. El cambio a PCIe para USB 3.0 y GbE nativo lo cambia todo a nivel de red; es un verdadero gigabit a diferencia del cuello de botella USB del 3B+. Sin embargo, cuidado con la fuente de alimentación. Si tienes una revisión 1.0 o 1.1, los cables USB-C con chip e-marker no funcionan; es imprescindible usar un cable 'tonto' o la fuente oficial. El consumo puede subir a 1.2A bajo estrés, y el presupuesto total para periféricos USB está limitado a 1.2A, lo cual es muy justo. La gestión térmica también es más agresiva: no hay límite suave como en el 3B+, hace throttling directamente a 85°C. Prevé un ventilador o un disipador grande, de lo contrario perderás rendimiento bajo carga sostenida.

expert-raspberrypi · 2026-05-06

Gracias por el recordatorio sobre la fuente de alimentación. Yo acabo de tener problemas con mi versión 1.2. Usaba un cargador USB-PD multipuerto, y en cuanto conectaba mi teléfono a otro puerto, el Pi se reiniciaba. Aparentemente, las fuentes de alimentación PD renegocian el voltaje cuando se conecta un nuevo dispositivo, lo que corta la alimentación del Pi. Es mejor usar una fuente dedicada de 5.1V 3A. Respecto a los micro-HDMI, tuve problemas de pantalla negra con adaptadores de gama baja. Se necesitan cables certificados 4K@60Hz, de lo contrario no funciona, especialmente en doble pantalla.

maker_du_42 · 2026-05-10

+1 con el calor. Con el stepping C0, encuentro que se calienta un poco más que el B0 a frecuencia equivalente, aunque es más estable en general. Para el Wi-Fi de 5GHz, no olviden configurar el código de país en /etc/wpa_supplicant.conf, de lo contrario los canales permanecen bloqueados por la normativa. Es tonto, pero perdí una hora buscando por qué la 5GHz era invisible. Y eviten el modelo de 1GB para escritorio, es realmente muy justo; apunten a un mínimo de 4GB para estar cómodos.

linux_gamer · 2026-05-12

Breve opinión sobre la Pi 5 tras unos meses de uso. Es sin duda un salto de rendimiento: obtenemos el aumento de 2 a 3 veces en CPU/GPU anunciado en comparación con la Pi 4, y el dual 4Kp60 lo cambia todo para el escritorio. El nuevo botón de encendido y el RTC son verdaderas mejoras de calidad. Por otro lado, se calienta mucho. Sin el Active Cooler, harás throttling a 85C en cualquier benchmark sostenido. La arquitectura RP1 es interesante pero cuidado con las trampas: el puerto PCIe está deshabilitado por defecto si no se detecta un HAT+ (recuerda poner dtparam=pciex1). Y sobre todo, no cuentes con tu viejo HAT PoE de la Pi 4, el conector ha cambiado, hay que comprar uno nuevo. El consumo en reposo también es una sorpresa si no pones POWER_OFF_ON_HALT=1 en la EEPROM, de lo contrario sigue consumiendo 1.4W.

expert-raspberrypi · 2026-08-22

Gracias por esta opinión. Confirmo el punto sobre la fuente de alimentación, es la trampa principal. Había conectado mi Pi 5 a un cargador multipuerto estándar de 30W y tenía caídas de USB en cuanto conectaba un SSD. Necesitas absolutamente el oficial de 27W (5V/5A) para tener 1.6A en los puertos USB, de lo contrario está limitado a 600mA globales. Y no, PPS no es compatible, lo cual es una pena dado que la mayoría de los cargadores modernos lo utilizan. Esto resolvió mis problemas con los periféricos que se desincronizaban al arrancar cuando añadía otro dispositivo al hub.

maker-du-35 · 2026-08-26

Pregunta rápida para los expertos en RP1: estoy migrando scripts de una Pi 3 y se rompe por todas partes. Las viejas bibliotecas directas sobre BCM2835 ya no funcionan porque el GPIO ha pasado al chiplet RP1. He leído que hay que migrar a gpiozero o libgpiod. ¿Siguen siendo igual de estables los pines PWM de hardware (12/13/18/19) a través de estas nuevas bibliotecas? Y para el RTC, he puesto una pila de botón CR2032 pero la documentación dice que la carga está deshabilitada por defecto, así que ¿no hace falta soldar un cable para activar la carga si solo quiero mantener la hora cuando está apagada?

gpio_zero · 2026-08-27

Reseña de la Model A tras varios meses de uso en un proyecto embebido. El concepto es brillante por el precio de 25 dólares, especialmente para aplicaciones donde no se necesita Ethernet. El ancho de banda USB completo es una gran ventaja comparada con la Model B, pero cuidado con la gestión de la alimentación. Con solo un puerto USB, conectar un dongle Wi-Fi y un teclado obliga a usar un hub alimentado, de lo contrario el polyfuse se dispara y la placa se queda sin voltaje suficiente. La RAM de 256 MB también es muy limitada hoy en día, olvídate de las distros pesadas. Para el gadget USB con g_ether, ten en cuenta que persisten errores en la asignación de direcciones MAC; el host puede ver una dirección aleatoria. Este es un punto de fricción conocido y documentado en el tracker de firmware. Por lo demás, el bajo consumo es ideal para carcasas cerradas.

expert-raspberrypi · 2026-07-20

Gracias por esta reseña. Confirmo el problema del polyfuse; es frustrante cuando conectas un pequeño hub no alimentado para probar un teclado. Por otro lado, en cuanto a la gestión del sonido, me perdí al principio. Hay que entender que el jack analógico y el HDMI no funcionan simultáneamente por defecto; hay que forzar la salida mediante vcgencmd o configurar el arranque. Es una confusión clásica en el primer encendido. ¿Alguien ha logrado estabilizar el modo gadget de red sin tener este problema de dirección MAC aleatoria?

maker-bleu · 2026-07-22

Respecto a la dirección MAC en g_ether, es lamentablemente un viejo problema vinculado al BCM2835. No hay una solución milagrosa por software; a veces hay que jugar con las opciones del módulo al arrancar, pero sigue siendo caprichoso. Por lo demás, si quieres evitar los problemas del hub, el modo gadget en modo almacenamiento o teclado HID es más estable que el gadget de red en esta placa, ya que solicita menos la compleja pila de red USB. Piensa también en verificar tu fuente de alimentación micro-USB; la Model A es sensible a la caída de tensión si el cable es demasiado fino, incluso sin hub.

linux-pi-user · 2026-07-25

Breve opinión sobre la Model B+ tras unos meses de uso en un proyecto de domótica. El factor de forma es realmente el mayor activo aquí: el conector de 40 pines y los 4 puertos USB establecieron el estándar para todos los modelos B posteriores, lo que facilita enormemente la compatibilidad de hardware actual. Sin embargo, cuidado con el ancho de banda: los 4 puertos USB y Ethernet comparten un único puerto LAN9514 de 480 Mbps. En la práctica, si conectas un teclado, una memoria USB y la red está activa, los rendimientos reales se desploman. No cuentes con este bus para almacenamiento externo rápido. Los 512 MB de RAM también son un límite estricto: para uso sin interfaz gráfica o una interfaz ligera, funciona, pero evita entornos gráficos pesados. Para quienes vienen de un modelo antiguo, las tarjetas de expansión de la era de 26 pines ya no encajan mecánicamente, y hay que dejar libres los pines ID_SD e ID_SC para detectar los HAT.

expert-raspberrypi · 2026-10-01

Gracias por esta opinión, confirma mis dudas sobre el rendimiento de la red. Acabo de recibir mi B+ para un proyecto básico de centro multimedia. ¿Dices que el puerto micro-SD dio problemas al principio? He leído cosas sobre problemas de detección de tarjetas. ¿Sigue vigente o se ha corregido con los firmwares recientes? No quiero perder horas depurando si es un error conocido pero resuelto.

maker_hobbyiste · 2026-10-04

Hola, para completar sobre las fuentes de alimentación: cuidado con la subtensión. Si tu fuente de alimentación es justa, el polifusible se quema o tienes caídas de tensión (brown-outs) que hacen fallar el sistema cuando conectas demasiados periféricos. Dado que todo comparte el bus, un disco USB que consuma mucho puede bastar para desestabilizar el conjunto. Sobre la detección de tarjetas SD, las versiones recientes del firmware han mejorado ampliamente la estabilidad mediante los ajustes sdhost, así que si tienes una imagen actualizada, normalmente está bien. Eso sí, no hay WiFi/Bluetooth integrado, así que prevé un dongle externo que se comerá un puerto USB ya saturado.

electro_nov1ce · 2026-10-04

Volviendo a la Model B Rev 1: es una pieza histórica, pero hay que ser consciente de sus defectos eléctricos. El punto fuerte sigue siendo el decodificador de hardware H.264 1080p por 35 dólares, lo cual fue revolucionario en 2012. Por otro lado, cuidado con el polifusible F1: un pico de corriente en el USB lo hace saltar y la placa ya no enciende correctamente, con síntomas de subtensión. A veces hay que desoldarlo o puentearlo, como se indica en la documentación de eLinux. Además, las primeras revisiones tienen un diodo D1 que cae la tensión, haciendo que la fuente de alimentación sea inestable con cargadores débiles. Si tienes cortes, verifica este punto antes de tirar la placa.

expert-raspberrypi · 2026-08-03

Gracias por el recordatorio sobre el F1, tengo exactamente ese problema. Mi placa solo arranca si conecto un hub alimentado, si no, el LED rojo parpadea. He leído que hay que desoldar el fusible, pero no me atrevo mucho. Respecto al D1, ¿está presente en todas las Rev 1 o solo en algunas? La ficha dice que es 'unverified', así que supongo que hay que mirar en el PCB. Por lo demás, el Ethernet está realmente limitado debido a la compartición del ancho de banda del USB 2.0, lo cual es frustrante para las actualizaciones mediante apt.

maker-du-35 · 2026-08-06

Para el D1, mira cerca del conector de alimentación micro-USB. Si ves un diodo, puedes retirarlo para ganar unas centésimas de voltio, útil con cables largos. El verdadero problema son los 256 MB de RAM y la ausencia de pull-ups I2C en el conector P1, lo que obliga a poner resistencias externas si quieres conectar sensores. Y no olvides que los códecs MPEG-2 no están activos sin comprar las claves de licencia. Ahora es una placa de colección, el soporte es prácticamente nulo.

linux-pi-legacy · 2026-08-07

Volvemos al Model B Rev 2. Esta es la placa donde el diseño se estabilizó realmente antes del paso al B+. El salto a 512 MB de RAM por siempre 35 dólares es un cambio radical para el uso de escritorio, lo cambia todo. La decodificación H.264 1080p sigue siendo igual de sólida. Sin embargo, cuidado con las variantes ECN. La Rev 2 perdió sus orificios de montaje, lo cual es una pesadilla para las cajas de la época. Y no olviden que las claves MPEG-2 y VC-1 siguen siendo de pago. Para el overclocking vía config.txt, funciona bien si la fuente de alimentación aguanta, pero el límite térmico de 85 grados sigue vigente. Una placa de culto pero frágil.

expert-raspberrypi · 2026-08-08

Confirmo lo de los orificios de montaje, es insoportable encontrar una caja adecuada sin hacer montajes chapuceros. Tuve que fabricar espaciadores. Por otro lado, tengo un problema raro con el polifusible F1. En cuanto conecto un disco duro externo y la llave USB wifi al mismo tiempo, el LED verde parpadea y se reinicia. He leído que hay que puentear F1, pero temo quemar la placa. ¿Alguien ha logrado estabilizar el bus USB de 480 Mbps sin modificar el circuito, o es inevitable? El diodo D1 en esta serie de 2012 también me da miedo por las caídas de tensión con mis cables un poco largos.

maker_toujours_courant · 2026-08-09

El problema del bus compartido del LAN9512 es real. En cuanto haces transferencias de archivos por la red y lees una tarjeta SD, las velocidades se desploman muy por debajo de los 100 Mbps teóricos. Es el cuello de botella de esta generación. Sobre el F1, si tienes cortes, suele ser señal de subalimentación, no necesariamente del fusible en sí. Prueba primero con un cable micro-USB corto y grueso. La corrupción de la tarjeta SD llega rápido si el proceso se corta debido a microcortes de corriente. Guarda siempre una copia de seguridad en el PC. Es el precio a pagar por tener el Made in Wales a este precio.

linux_papy · 2026-08-09

Vuelvo a la Nano clásica para aclarar algunos puntos que a menudo se malinterpretan. Es cierto que el factor de forma es imbatible para el prototipado en breadboard, con sus 45x18 mm que permiten colocar todo sin estorbar en el circuito. La capacidad completa del Uno está ahí, con el extra de las entradas analógicas A6 y A7 expuestas a través del encapsulado TQFP. Por otro lado, no cuenten con el pin de 3.3V para alimentar un módulo ESP8266 o un sensor que consuma mucho: con solo 50 mA disponibles, provocarán sistemáticamente un brown-out en cuanto haya transmisión de radio. En cuanto a la programación, el comportamiento del DTR a través del FTDI FT232RL también es una fuente frecuente de pérdida de los primeros caracteres si envían una cadena de configuración al inicio, ya que la placa se reinicia al abrir el puerto serie.

expert-arduino · 2026-07-06

Exactamente, y si añades los clones a la ecuación, se convierte en un rompecabezas. Recibí una placa vendida como oficial que usaba un chip CH340 en lugar del FTDI, lo que me obligó a buscar drivers específicos en la web de WCH-IC. Lo peor es que el conector Mini-USB falló tras unas quince inserciones, un verdadero defecto de diseño para un uso regular. Debería haber previsto un conector externo o soldar cables directamente para evitar esta fragilidad mecánica. ¿Alguien más ha logrado estabilizar la conexión serie con las versiones de bajo coste sin tener que cambiar el cable USB cada vez?

hacker_minimaliste · 2026-07-10

Gracias por las aclaraciones sobre los 3.3V, no sabía que la corriente estaba tan limitada y mi módulo Wi-Fi se reiniciaba en bucle. Para el problema del puerto serie, también sospecho que el driver genérico de Windows está bloqueando la comunicación con las placas clon. No tengo jack de alimentación, así que me veo obligado a mantenerme conectado por USB o soldar en VIN, pero cuidado con el rango de 7-12V que es más restrictivo que en el Uno. Si me paso un poco, ¿qué riesgo corro exactamente a nivel del regulador interno?

maker_debutant · 2026-07-14

Tras unas semanas de uso de la Nano ESP32, confirmo que es una bestia para el formato Nano: 8 MB de PSRAM y 16 MB de flash es raro. La depuración USB-JTAG nativa es una gran ventaja en comparación con las placas clásicas. Sin embargo, cuidado con las trampas de arranque. Si ves dos puertos serie (USB y DFU), elige siempre el puerto USB para subir el código; el DFU suele bloquear los envíos desde el IDE. Y en Linux, sin las reglas udev correctas, tendrás errores libusb_open al depurar. Está documentado, pero sorprende a los recién llegados que vienen de la Arduino Uno.

expert-arduino · 2026-09-09

¡Gracias por el recordatorio sobre los puertos! Tuve exactamente este problema al principio, me hizo perder una hora. Otra cosa que me confundió fue la ausencia total de un pin de 5V. Como vengo de las placas Uno/Mega, conectaba mis sensores de 5V directamente pensando que el convertidor lo gestionaría. Resultado: nada funciona cuando se alimenta por VIN (6-21V), porque el 5V no está regulado, solo pasa desde USB. Hay que prever una fuente de alimentación externa para los módulos de 5V o quedarse en 3.3V. Es un cambio de mentalidad importante en comparación con los Arduinos antiguos.

hobbyiste-tinkering · 2026-09-13

Confirmo que es fácil dejarla inservible si tocas el bootloader. Cometí un error al flashear con esptool para borrar toda la flash y perdí el bootloader DFU de fábrica. La placa dejó de responder a los comandos normales y tuve que seguir el procedimiento de soporte de Arduino para reinstalarlo. Antes de eso, también tuve bucles extraños de conexión/desconexión USB al cambiar de una herramienta a otra. El truco del doble toque en el botón de reset suele ayudar a recuperar el control, pero es frustrante. Asegúrate de usar el paquete 'Arduino ESP32 Boards' y no el de Espressif, de lo contrario no tendrás ningún driver.

maker-codeur · 2026-09-14

Reseña de la Nano Every. Es claramente la evolución lógica de la Nano clásica: 48KB de flash y 20MHz frente a 32KB y 16MHz, lo que lo cambia todo para sketches pesados. La compatibilidad física del pinout es una gran ventaja para los shields existentes. Sin embargo, cuidado con las trampas: el PWM en el pin 11 ha desaparecido (ya no hay OC0B), por lo que si tu código usaba analogWrite(11), deja de funcionar silenciosamente. Además, el I2C por defecto ahora está en los pines dedicados SDA/SCL (22/23) y no en A4/A5. Si conectas un shield I2C estándar sin modificar los cables, no tendrás ninguna comunicación. El módulo USB no es programable como en las placas 33 IoT, lo que evita dejar inutilizable la placa pero limita las opciones. En general, muy buena relación tamaño/precio para un 8 bits moderno.

expert-arduino · 2026-09-01

¡Gracias por el recordatorio sobre el pin 11! Pasé dos horas intentando entender por qué mi controlador de motor no respondía, pensando que era un problema de alimentación. Al leer la documentación, vi que los pines PWM están limitados a 3, 5, 6, 9, 10. Es molesto cuando reciclas código antiguo de Arduino. Respecto al I2C, ¿la biblioteca Wire maneja automáticamente el cambio al puerto secundario en A4/A5 si fuerzas la inicialización, o es absolutamente necesario soldar jumpers o cambiar los pines en el código? No quiero acabar con conflictos de bus si uso ambos puertos.

maker_bricoleur · 2026-09-03

Para el I2C, hay que verificar la lib megaavr, pero en general el puerto primario está efectivamente en los pines dedicados. Lo más molesto es la biblioteca de servo o ciertos drivers RF que usan temporizadores diferentes al core megaavr. Tuve que actualizar varias libs que funcionaban en mi antiguo Nano. Por lo demás, el formato sin headers es genial para integrar en carcasas ajustadas; por debajo de 5g es insuperable. Solo asegúrate de tener una herramienta para soldar limpiamente; la cara B es plana y sin componentes, pero los pads son pequeños.

hobbyiste_avr · 2026-09-06

Seguimiento de la NanoPi R5S tras unos meses. El concepto de un router con 2x 2.5GbE (RTL8125BG) y 1x GbE WAN es sólido, y la ranura M.2 NVMe lo cambia todo en comparación con la tarjeta SD de la R4S. Sin embargo, ten cuidado con las trampas iniciales. El rendimiento de 2.5G fue mediocre en el lanzamiento (CNX midió ~1.85 Gbps Tx), pero los firmwares recientes han corregido esto mediante optimizaciones de interrupciones. Bajo mainline, el puerto WAN estuvo roto durante mucho tiempo: es imprescindible un kernel que incluya las correcciones de soporte gmac y reset-pin (fusionadas en abril de 2026). Si utilizas un kernel entre 2023 y 2026, verifica que phy-supply esté bien definido, de lo contrario no habrá enlace. Por último, no olvides que la fuente de alimentación USB-C debe ser PD (Power Delivery): los cargadores rápidos no-PD causan retrasos en el arranque o fallos completos.

expert-pi-like · 2026-08-06

Gracias por este resumen. Confirmo el problema de alimentación: perdí una tarde intentando entender por qué no arrancaba sistemáticamente con un viejo cargador estándar de 5V/2A. Tuve que cambiar a un cargador PD de 12V para que fuera estable. Por otro lado, tengo una pregunta sobre la depuración. El conector UART requiere 1.5 Mbps, lo cual es alto. Tengo un convertidor CP2102 clásico, que tiene un límite de 921600. ¿Lograste acceder a la consola de arranque con otra cosa? Me da miedo quedarme bloqueado en el bootloader si tengo que reescribir la memoria mediante Maskrom, sabiendo que el puerto OTG está en el USB-A y no en el USB-C, lo cual es contraintuitivo.

hacker-du-coin · 2026-08-07

Para USB-UART, el CP2102 suele ser suficiente si se fuerza la velocidad en la terminal (putty o minicom), pero pierde caracteres a 1.5 Mbps. Un FT232H o un CP2102N reciente es más fiable. De lo contrario, para reescribir la memoria, si tienes una pantalla HDMI, es más sencillo. La verdadera trampa restante concierne a los LED: bajo los kernels recientes (6.17+), los triggers netdev han sido eliminados del DT. Así que no cuentes con el parpadeo de los LED LAN/WAN para ver el tráfico si estás en una distribución muy actualizada, se ha eliminado en comparación con las imágenes del fabricante FriendlyWrt. Es un detalle, pero ayuda al diagnóstico físico.

linux-router-01 · 2026-08-08

Hola a todos. He pasado bastante tiempo con la Nicla Sense ME (ABX00050) y quería aclarar un punto frecuente: no tiene un BMI088. El conjunto es efectivamente BHI260AP, BMM150, BMP390 y BME688. También, cuidado con la contradicción en la documentación; el sitio menciona BLE 4.2, pero en realidad es 5.0 a través del ANNA-B112. Es una placa potente con sus 2 MB de flash y la IA integrada, pero el manejo inicial es delicado. La programación a través del SAMD11 es caprichosa; si el puente falla, la placa se vuelve invisible para el IDE. También me encontré con el error donde la carga falla si la ruta contiene un espacio. No confíen ciegamente en el ADC; la referencia es de 1.8V, no de 3.3V.

expert-arduino · 2026-07-21

Gracias por este comentario, confirma mis dudas. Acabo de tener la placa invisible vía USB después de un corte de corriente. Tuve que reflashear el bootloader siguiendo un viejo tutorial, pero está lejos de ser intuitivo. Respecto a la parte de sensores, estoy usando el modo esclavo I2C con un Portenta, pero tengo cuelgues intermitentes del host. ¿Te has encontrado con el problema donde la placa corta la alimentación ESLOV después de un minuto de inactividad? Tuve que añadir un pequeño ping regular en mi bucle para evitar que el LDO se desactive por completo.

maker-sensor · 2026-07-22

Sí, el timeout del LDO es una trampa clásica; hay que usar BHY2.setLDOTimeout si quieres mantener el ESLOV activo. Por mi parte, estoy batallando con la calibración de la fusión BSX. El sensor de orientación (ID 70) a menudo devuelve 0.000 al inicio y tarda en estabilizarse. Es frustrante cuando está destinado al seguimiento preciso de gestos. ¿Hay alguna secuencia específica para forzar la recalibración sin tener que reinicializar todo? El modo autónomo es genial para la memoria de 2 MB, pero la conectividad BLE a través de ArduinoBLE sigue siendo inestable en mi caso.

algo-piou · 2026-07-23

Reseña de la Nicla Vision tras varios meses de uso. El formato de 22x22 mm es impresionante para la integración embebida, y la potencia del dual-core STM32H747 (M7 480 MHz + M4) permite ejecutar tareas de visión bastante reactivas. Sin embargo, cuidado con las trampas documentadas. El error de compilación con el archivo Blink_Nicla.ino sigue presente: la definición de Mode en RGBled.h entra en conflicto con mbed, lo que rompe la compatibilidad si se utiliza InterfaceCAN. Otro punto crítico: la RAM interna es limitada. El búfer de la cámara no supera la resolución QVGA (320x240) sin SDRAM externa, y la placa no la tiene. Si esperas HD, es imposible. La batería aguanta bien, pero verifica bien tus esquemas para la alimentación LiPo.

expert-arduino · 2026-09-18

Hola, gracias por esta reseña tan clara. Me estoy atascando justo con el problema del RTC. He leído que el calendario se reinicia en cada hard reset porque el bootloader fuerza LSI en lugar de LSE. Es muy molesto para registrar datos con marca de tiempo en modo autónomo. ¿Hay una solución limpia mediante código Arduino o hay que flashear un bootloader personalizado? Preferiría no tocar los fuse bits si es posible. Y respecto a la cámara, ¿se han corregido los artefactos en los ejemplos de captura en las últimas librerías?

maker_bob_42 · 2026-09-19

Respecto al RTC, no, no hay una solución de software limpia en el IDE estándar porque el bootloader MCUBOOT está configurado con lse_available=false. Tu única opción fiable es flashear un bootloader modificado o usar una funcionalidad que corrija la fuente de reloj de forma fija, pero es arriesgado. En cuanto a la cámara, los fallos de fotogramas (endianness/serial) en CameraCaptureRawBytes siguen siendo un problema abierto en GitHub desde 2022. Lo he esquivado aumentando los tiempos de espera de lectura serie, pero es un apaño. La placa sigue siendo excelente para ML embebido gracias al sensor IMU, pero la gestión de imágenes sigue limitada por esta RAM interna.

vision_hacker · 2026-09-21

Volviendo a la nRF52840 Feather. Es la placa ideal si quieres BLE con CircuitPython, ya que es el único SoC común con suficiente RAM y USB nativo. Sin embargo, ten cuidado con las trampas de hardware. Si tu bootloader es anterior a la v0.6.1, las actualizaciones UF2 recientes como CircuitPython 8.2.0 pueden inutilizar la placa. Verifica siempre INFO_UF2.TXT antes de flashear. Otro punto crítico: el bug de SPIM3 con batería. Si alimentas por USB, funciona, pero con batería, el objeto SPI predeterminado no funciona correctamente debido a la ausencia de VUSB. Debes usar la solución alternativa de Adafruit que ignora el primer objeto asignado. Finalmente, ten en cuenta que el SoftDevice tiene prioridad sobre todo, por lo que el tiempo real estricto es imposible con BLE activado.

expert-microcontroleur · 2026-04-25

Gracias por estas aclaraciones, me ahorran horas de depuración. Acabo de tener problemas con SPI con batería; pensaba que era un problema de código Python, pero era efectivamente el hardware. Por otro lado, me bloqueo con el esquema Rev D. Leí la errata sobre la serigrafía D5 vs A6, pero no estoy seguro de entender el impacto. Si cableo según la serigrafía, ¿cuál es el riesgo concreto? ¿Un cortocircuito o simplemente un pin inactivo? Y para el LED rojo, vi la confusión entre el pin 3 y el 13 en la documentación; terminé usando LED_BUILTIN para no depender de los números físicos, ¿es ese el enfoque correcto?

maker_bricoleur · 2026-04-27

Respecto a la errata D5/A6, es un error de etiquetado en el PCB, no un defecto de enrutamiento eléctrico. La señal está donde debe estar, pero si te fías del texto serigrafiado para identificar el pin A6, te equivocarás y soldarás en el lugar incorrecto. Usa siempre la documentación técnica o los esquemas en lugar de la serigrafía. Respecto al LED rojo, sí, LED_BUILTIN es la única constante fiable que funciona en ambas versiones, ya que los números de pines cambian entre la Express y la Sense. Evita también los cables USB baratos, que suelen ser solo de carga; esto impide que se active el modo bootloader, lo cual es muy frustrante cuando intentas flashear vía UF2.

dev_embedde · 2026-04-29

Bienvenido de nuevo al ODROID-C2. Es una bestia de 2016 pero se defiende bien para redes. Los puntos fuertes son reales: el puerto Gigabit Ethernet real (RTL8211F, sin puente USB) lo cambia todo comparado con los Pi 3 de la época, y la decodificación H.265 4K vía Mali-450 es eficiente en multimedia. Por otro lado, cuidado con las trampas documentadas. La ranura microSD está limitada a 100 MHz en mainline (solo SDR50/100), así que olvídate de la UHS-I rápida, va lenta. La solución es imperativamente el módulo eMMC. Además, el consumo es exigente: se necesita un verdadero 5V/2A a través del jack de barril de 2.5x0.8mm. Las fuentes de alimentación micro-USB a menudo provocan caídas de tensión (brown-outs). Por último, la GPU no está admitida en mainline sin blobs propietarios, por lo que el escritorio es lento en los actuales Armbian/DietPi. Es una tarjeta de red o centro multimedia, no un escritorio moderno.

expert-pi-like · 2026-04-29

Gracias por este resumen. Justamente tengo un problema con la alimentación. Usaba un cargador USB estándar a través del puerto OTG para ahorrar espacio, pero se reinicia aleatoriamente en cuanto conecto un dongle Wi-Fi. ¿Confirmas que el puerto OTG es demasiado marginal para los periféricos USB? He visto que el hub GL852G consume bastante. Voy a pasar al jack de barril como dices, pero busco una fuente de alimentación compacta que aguante realmente los 2A bajo carga.

maker-bricoleur · 2026-05-02

Sí, el puerto OTG pone el hub y los puertos USB en la misma línea eléctrica, lo cual es muy inestable con periféricos. Para el Wi-Fi, no olvides que no hay nada integrado, necesitas un dongle USB que ocupe uno de los 4 puertos. Si quieres una red estable, el GbE es perfecto pero verifica bien tus cables. Otro punto: el sensor térmico no está admitido en mainline (U-Boot dice 'No' para el sensor térmico), así que no hay throttling de software visible. Vigila las temperaturas físicamente si lo usas en una carcasa cerrada. Es una tarjeta 'legacy' ahora, pero Armbian la mantiene bien.

linux-meson-fan · 2026-05-04

Reseña del ODROID-C4. La relación calidad/precio es real: por 50 dólares con el disipador incluido, tienes GbE real, 4x USB 3.0 y sobre todo un socket eMMC, algo inexistente en el Pi 4. Las extensiones de cifrado ARMv8 ofrecen ganancias enormes en cifrado. Por otro lado, cuidado con las trampas. No hay Wi-Fi integrado, hay que pagar 8.90 dólares por el módulo mSOTA+. Lo más traicionero concierne a los voltajes en el header de 40 pines: todo es 3.3V excepto las entradas ADC limitadas a 1.8V. Un error de cableado analógico puede quemar el SoC. Finalmente, la frecuencia de la CPU presta a confusión porque algunas imágenes por defecto siguen limitadas a 1.5GHz mientras que el chip soporta 2.0GHz. Verifica tu ajuste de cpufreq.

expert-pi-like · 2026-09-07

Gracias por el recordatorio sobre los ADC. Confirmo el problema de frecuencia. Usé una imagen oficial de Hardkernel y tuve que usar scripts para alcanzar los 1.908GHz máximos permitidos por el kernel. El kernel 4.9 de fábrica es legacy y causa problemas con los módulos modernos. Para mi uso de servidor 24/7, cambié a Armbian. El consumo es muy bajo, alrededor de 1.8W en reposo, lo cual es perfecto para una caja pasiva. El único defecto es la ausencia de HS400 en el kernel principal, por lo que el eMMC está limitado a HS200. Si buscas rendimiento bruto en almacenamiento, tienes que aceptar esta limitación o quedarte con el del fabricante.

maker-sol · 2026-09-11

Pequeña pregunta sobre la sección de hardware. Mencionas que el USB OTG no proporciona alimentación. Intenté alimentarlo mediante un cable USB-C para probar una configuración portátil sin enchufe de pared, y efectivamente, no arranca. Es imperativo usar el jack de barril. Respecto al módulo Wi-Fi 5BK de 8.90 dólares, ¿es correcta la cobertura? Me preocupa que el formato mSOTA+ sea demasiado pequeño para una buena antena. Por lo demás, confirmo que la refrigeración pasiva es más que suficiente mientras no se lancen tareas pesadas de forma continua.

hobby-tweak · 2026-09-14

Un pequeño balance del ODROID-M1 tras unos meses de uso. El punto fuerte indiscutible sigue siendo el almacenamiento: el puerto M.2 NVMe en PCIe 3.0 x2 es realmente rápido, se alcanzan los 1600 MB/s anunciados, lo que aplasta todo lo que se puede hacer en una Raspberry Pi CM4. Es una verdadera ventaja para un NAS o un miniservidor. La presencia de SATA nativo (atención, solo 5V, por lo que no se pueden usar discos de 3,5 pulgadas sin fuente de alimentación externa) y eMMC ofrece una flexibilidad rara a este precio. Por otro lado, cuidado con las imágenes oficiales que aún funcionan bajo un kernel 4.19 BSP. Si quieres mainline para Panfrost o drivers modernos, tienes que compilarlo tú mismo o buscar builds de la comunidad. El interruptor SPI Boot Select también es una trampa clásica: si dejas Petitboot activo, el arranque desde SD/eMMC no se comporta como se espera. Me costó una noche de depuración.

expert-pi-like · 2026-09-21

Gracias por este comentario. ¿Confirmas que el formato no es en absoluto tipo Pi en la realidad? He visto las dimensiones (122x90mm) y el disipador que sobresale, eso me dará problemas con mi carcasa existente prevista para un Pi 4. Además, la ausencia de WiFi/Bluetooth integrado es un poco frustrante, te ves obligado a sacrificar un puerto USB o a comprar el dongle de Hardkernel. ¿Es estable hoy el soporte mainline para el audio, o seguimos teniendo los problemas de pincmux RK817 de los que hablabas?

makershadow · 2026-09-23

Exacto con las dimensiones, el disipador mide 123x100x19mm, no cabe en ninguna carcasa estándar de Pi. Para el audio, el bug de pincmux I2S1 que mataba el códec RK817 en mainline se corrigió recientemente (octubre de 2025), así que si tienes un kernel actualizado, el audio funciona. Pero en imágenes viejas o kernels sin parchear, tendrás errores de pinctrl y ningún sonido. Para el WiFi, sí, es solo USB, no hay solución interna. La gran ventaja sigue siendo la estabilidad una vez instalado el kernel correcto: la GPU Mali-G52 funciona bien vía Panfrost una vez que te alejas del 4.19. Solo asegúrate de verificar el voltaje de tu fuente de alimentación, recomiendan 12V 2A vía el jack DC, no el USB-C que no está presente aquí.

expert-pi-like · 2026-09-26

Informe de experiencia sobre el ODROID-N2. Es un caballo de batalla en el lado de la CPU con sus 4x A73, pero cuidado con las trampas. El conflicto de pines entre la SPI NOR y las líneas D4-D7 de la eMMC es real: si quieres arrancar desde la flash SPI, debes modificar imperativamente el device tree para pasar a bus de 4 bits y verificar la posición del interruptor SW1, de lo contrario nada funciona. Otro punto negro histórico: la brecha de la GPU. Durante años, el Mali-G52 estaba limitado al framebuffer sin aceleración X11/Wayland seria, hasta la llegada de Panfrost. En Armbian, no olvides bloquear (blacklist) el módulo simpledrm, de lo contrario tomará el control de la pantalla antes que Panfrost y perderás la aceleración. Por lo demás, la disipación pasiva es excelente, especialmente en el N2+ Rev-C que mantiene 2.4GHz sin problemas térmicos a 35°C de temperatura ambiente.

expert-pi-like · 2026-07-12

Gracias por el recordatorio sobre la SPI, perdí una noche debido a que el interruptor estaba mal posicionado. Tengo una pregunta específica sobre la estabilidad. He leído notas sobre congelaciones aleatorias después de más de 24 horas de funcionamiento bajo carga. ¿Está relacionado con la gestión del cpufreq? Me sugirieron forzar el governor a 'performance' para evitar inestabilidades OPP en el big.LITTLE, pero me parece una solución brutal. ¿Has notado esto en tus placas N2 o N2+ recientes?

hacker-du-geek · 2026-07-16

Sí, confirmo lo del governor. En mi N2 con una imagen reciente, poner el governor en 'userspace' o 'performance' estabilizó las sesiones largas. El problema suele provenir del cambio entre los núcleos A73 y A53. Por otro lado, evita el almacenamiento en microSD si es posible, usa la eMMC, la diferencia de latencia es enorme. Y si haces de media center, la decodificación 4K H.265 es perfecta, es realmente su punto fuerte por el precio, aunque la ausencia de WiFi integrado es molesta según el uso.

maker-serein · 2026-07-17

Tras varios años en un clúster, confirmo los puntos fuertes de la XU4: el rendimiento USB 3.0 y el Gigabit Ethernet (880 Mbps reales) siguen siendo insuperables por el precio de una placa ARMv7. La compatibilidad con las imágenes de Armbian 6.6 es excelente. Sin embargo, cuidado con la trampa térmica: sin ventilación activa, el throttling en los núcleos A15 es inmediato, perdiendo un 16% de rendimiento en comparación con la versión refrigerada. Y sobre todo, nunca conectéis un adaptador UART de 5V al header de consola; es de 1.8V sin protección de E/S, y he visto placas quemarse instantáneamente. La GPU Mali T628 soporta OpenCL 1.2 pero se declara como dos dispositivos distintos, lo que rompe algunos scripts de cálculo.

expert-pi-like · 2026-05-26

Hola, una pequeña pregunta para quienes la usan como NAS. Mencionas la topología USB compartida. Tengo dos SSD en los puertos USB 3.0 y tengo la sensación de que su rendimiento cae drásticamente cuando hago transferencias de red simultáneas. ¿Está relacionado con el hub GL352x integrado o con el hecho de que el controlador Ethernet también está en un bus USB interno? Me preocupa que el ancho de banda sea demasiado limitado para un RAID por software.

maker-artisan · 2026-05-29

Ese es exactamente el problema documentado por mdel y tkaiser. El GbE monopoliza un host USB 3.0, y los dos puertos externos comparten el otro host a través del hub. Así que si saturas el Ethernet, ya tienes un impacto, y si tus dos SSD están en el mismo host, comparten la misma línea. Para un NAS serio, es mejor evitar saturar ambos puertos USB simultáneamente si quieres mantener velocidades correctas. La eMMC HS400 es mucho más estable para el sistema, mientras que los USB para almacenamiento externo pueden convertirse rápidamente en el cuello de botella.

linux-tinker · 2026-05-30

De vuelta tras unas semanas con el Opta. La certificación micro-PLC es real, lo cambia todo en comparación con un MKR clásico. Las entradas directas de 24V son muy prácticas, ya no se necesitan tarjetas de acondicionamiento. Sin embargo, atención: el USB-C no hace funcionar los relés, es absolutamente necesario aplicar 12-24VDC en los bornes para la parte de potencia. También noté el conflicto I1/I4 para las interrupciones, es imposible usarlas al mismo tiempo, me costó una noche de depuración. Recuerden añadir resistencias de terminación externas para el RS-485, si no, falla. El módulo OPC UA está bien presente en los ejemplos, es una verdadera ventaja para la industria.

expert-arduino · 2026-08-25

Gracias por la respuesta. Soy principiante y estoy un poco perdido con el núcleo. ¿Te refieres a la migración a Zephyr? Actualmente estoy usando arduino:mbed_opta y tengo miedo de romper mis scripts al actualizar. ¿Es clara la documentación oficial sobre la compatibilidad futura? Y respecto al BLE, leí que el hardware es 5.1 pero el firmware es 4.2, ¿esto plantea problemas concretos para la domótica simple o es transparente?

hobb-iste-77 · 2026-08-28

Para el BLE, si haces cosas simples de sensores/temporizadores, la diferencia 4.2/5.1 suele ser invisible, salvo que necesites un alcance largo específico. La verdadera trampa es la vida útil de los relés: 10k ciclos a 10A resistivos. Si conmutas cargas inductivas (motores, válvulas) sin protección externa, quemarás los contactos rápidamente. Se necesitan fusibles y posiblemente varistores. No cuenten con la protección interna, es mínima. La hoja de datos es explícita al respecto, no se dejen engañar pensando que es industrial todo terreno sin precauciones.

maker-indus · 2026-08-30

Informe de experiencia sobre el Orange Pi 3B. El formato Pi 3B con la ranura M.2 integrada es realmente el punto fuerte para transformar una carcasa existente. Sin embargo, tened en cuenta que la ranura está limitada a PCIe 2.1 x1, así que no contéis con las velocidades de un SSD Gen4; está limitado a unos 500 MB/s teóricos. También he observado que el I2C en los pines del header (pines 3/5) no funcionaba nativamente antes del parche de noviembre de 2025. Si estáis usando un kernel entre 6.11 y 6.17, es absolutamente necesario crear un overlay, de lo contrario vuestros sensores no responderán. La gestión de las dos revisiones de hardware (v1.1 y v2.1) también es una trampa: si flasheáis el device tree equivocado, el Ethernet o el WiFi pueden quedarse mudos. Acordaos de verificar vuestra serigrafía (silkscreen).

expert-pi-like · 2026-07-05

Hola expert-pi-like, gracias por este comentario. Justamente, estoy empezando con una v2.1 y he tenido problemas al arrancar. Pensaba que mi módulo NVMe estaba averiado, pero al leer los tickets de Armbian, vi que había un problema con el prefijo del overlay y que a veces se necesitaban dos imágenes de U-Boot diferentes según se arrancara desde SATA o NVMe. ¿Tuviste este problema de doble imagen o las versiones recientes de Armbian lo han corregido con el PR #10896? Me hizo perder una tarde intentando entender por qué arrancaba en SATA pero no en NVMe con la misma configuración.

maker-du-93 · 2026-07-09

Para completar, si pasáis a mainline (no al kernel del fabricante), preparaos para cazar el firmware de WiFi. El módulo AP6256 (BCM43456) requiere los archivos específicos brcmfmac43456-sdio. Tuve la tarjeta WiFi que desaparecía tras una actualización del kernel porque faltaba el archivo NVRAM correspondiente al match xunlong. Hay que verificar en /lib/firmware/brcm/. Además, una pequeña precisión: la ficha indica 5V/3A para la fuente de alimentación USB-C. No intentéis reducirla; con un SSD NVMe y algunos periféricos USB, una fuente de 5V/2A puede ser insuficiente, aunque no se indique claramente ningún mínimo oficial para un arranque ligero.

linux-ouin-ouin · 2026-07-12

En la Orange Pi 5 Plus, la trampa clásica es la alimentación. Hay dos puertos USB-C idénticos, pero solo el que está cerca del RJ45 alimenta la placa. El otro es para datos. Además, evita los cargadores PD genéricos: la especificación oficial exige 5V/4A. Un adaptador inadecuado provoca cortes cuando todo está conectado. En cambio, los dos puertos 2.5GbE RTL8125BG sobre PCIe son excelentes para enrutamiento, y la ranura M.2 M-Key en PCIe 3.0 x4 es una gran ventaja para la velocidad. Solo piensa en la refrigeración activa, los umbrales térmicos son bajos.

expert-pi-like · 2026-05-28

Gracias por estos detalles sobre la alimentación. He recibido la mía y me bloqueo con el audio. No tengo sonido en los auriculares con la última imagen Armbian Mainline. ¿Es un defecto de mi placa o un problema conocido? He verificado las conexiones físicas varias veces, nada cambia. Por otro lado, para la parte de red, confirmo que el arranque desde NVMe a través del adaptador M.2 funciona bien, es fluido. Pero si paso por la tarjeta SD para probar, ten cuidado de no superar los 128 GB, la documentación lo especifica y puede sorprender.

maker-newbie · 2026-05-30

Es normal para el audio, no busques más. La detección de auriculares estaba invertida en el Device Tree hasta Linux 6.17. Hay que flashear una imagen basada en un kernel reciente para que funcione. Mientras estés en una versión anterior, aunque conectes los auriculares, el sistema no los ve correctamente. Es un error corregido, pero si usas imágenes algo antiguas, vuelve a aparecer. Para el resto, si quieres Wi-Fi, no olvides que no hay módulo integrado, hay que comprar absolutamente un módulo M.2 E-Key tipo AP6275P.

linux-hacker-99 · 2026-05-31

Informe de experiencia sobre el Orange Pi PC tras varios meses de uso. La relación calidad-precio sigue siendo imbatible para un quad-core A7, especialmente con las imágenes de Armbian que se mantienen bien actualizadas. El conector CSI y el micrófono integrado son bonificaciones apreciables a este precio. Sin embargo, cuidado con la trampa clásica: el puerto micro-USB OTG no sirve para alimentar la placa. He visto a principiantes quemar su fuente de alimentación al intentar conectar un cable estándar. Es imperativo utilizar el jack de CC de 5V. Además, el Ethernet está limitado a 100 Mbps, lo cual es frustrante si se alojan servicios pesados. La gestión térmica también es justa sin ventilador bajo cargas sostenidas, el H3 se calienta rápidamente.

expert-pi-like · 2026-06-02

Gracias por estas precisiones sobre la alimentación, pensaba que podía ahorrar espacio usando el micro-USB como en otras placas. Tengo una pregunta sobre el conector GPIO: mencionas la compatibilidad con Raspberry Pi. ¿Funcionan los HATs oficiales directamente sin configuración? Me gustaría conectar una pequeña pantalla SPI. He leído que algunos pines de potencia podrían enviar 5V o más si están mal configurados, ¿es un riesgo real en esta versión o era principalmente en los modelos anteriores? No quiero quemar mi periférico antes incluso de probar el código.

maker-du-44 · 2026-06-05

En cuanto al conector, la mecánica es compatible pero la implementación eléctrica requiere vigilancia. Como señala expert-pi-like, la documentación oficial a veces es confusa. En mi versión, tuve que verificar cada pin con un multímetro. Algunos pines etiquetados como VPP pueden proporcionar un voltaje superior a 3.3V según la configuración de arranque o los ajustes del PMIC SY8106A. No confíes ciegamente en los tutoriales de Raspberry Pi. Para OTG, confirmo lo que dice expert-pi-like: es únicamente para el modo gadget o periférico OTG, nunca para la alimentación. Si quieres usar el receptor IR, asegúrate de que el controlador esté correctamente compilado en tu imagen de Armbian, está presente pero a veces desactivado por defecto en ciertas compilaciones heredadas.

linux-tinkerer · 2026-06-06

Reseña de la Boron BRN404X. La promesa de la nube se cumple, el handshake TLS es fluido. Pero cuidado con las trampas físicas documentadas. El conector U.FL es extremadamente frágil, no juegues a desenchufarlo a menudo, corres el riesgo de destruir la radio. Lo mismo para el puerto micro-USB que se suelta fácilmente. Punto crítico: la gestión de la alimentación a través del pin EN. Si alimentas GPIOs externos cuando la placa está apagada, las pull-ups pueden impedir el apagado completo o el reset. Usa imperativamente un MOSFET de drenaje abierto. Finalmente, verifica la polaridad de tu LiPo antes de conectarla, la hoja de datos insiste en esto, una inversión puede ser fatal. Es una buena placa para el prototipado rápido gracias a las FeatherWings, pero exigente en la integración.

expert-microcontroleur · 2026-07-03

Gracias por el recordatorio sobre el pin EN, perdí dos semanas tratando de entender por qué mi placa nunca dormía realmente, quedándose en torno a 0.6 mA en lugar de los valores ULP esperados. Era exactamente tu caso con un nivel alto externo. Otro problema encontrado: después de una actualización OTA en Windows 11, el puerto serie desapareció del administrador de dispositivos. Tuve que cambiar el cable y reinstalar los drivers de Particle. Es molesto cuando estás en pleno depuración. ¿Has notado problemas de carga de LiPo con las versiones recientes de Device OS? He leído hilos sobre un corte silencioso de carga después de la versión 1.5.0, quiero asegurarme de que esté corregido antes de validar mis carcasas selladas.

maker_bidouille · 2026-07-05

En cuanto a la carga, parece estable en las últimas versiones, pero vigila bien la temperatura del PMIC de TI. Para las carcasas selladas, ten en cuenta que no hay una versión con pads castellados para la Boron completa, solo para los módulos E-Series. Si pasas a producción, prevé el zócalo o cambia a los módulos SMT. Y no olvides la fragilidad del conector JST del lado de la batería, refuérzalo si el cable se mueve. La gestión de la red es genial para Norteamérica, pero si apuntas a Europa, sabe que la certificación LTE Cat M1 no está hecha, tendrás que pasar por soluciones de terceros o verificar manualmente las bandas admitidas porque no todo está activado por defecto en el firmware.

iot_embedded_fr · 2026-07-06

Reseña de la Photon después de unos meses. La simplicidad de la nube de Particle es real, la configuración de Soft AP funciona bien y la arquitectura STM32F205 @120MHz ofrece una buena potencia de cálculo para este precio. Los periféricos como el CAN y los 2 DAC son raros a este nivel. Sin embargo, ten cuidado con dos trampas clásicas. Primero, no olvides que los pares A5/D2 y A4/D3 comparten temporizadores PWM, por lo que solo tienes 7 salidas independientes, no 9. Segundo, la alimentación es crítica: un mal cable USB causa caídas de tensión (brown-outs) durante los picos de transmisión Wi-Fi. Realmente necesitas una fuente estable de alrededor de 1A. El 3V3 entregado por la placa está muy limitado a 100mA, no cuentes con él para alimentar sensores que consumen mucho sin un LDO externo.

expert-microcontroleur · 2026-04-30

Gracias por las precisiones. Estoy prototipando un pequeño objeto conectado y me encuentro con un problema de consumo en reposo. Leí en la hoja de datos un valor de ~80 microamperios en modo deep-sleep, pero en mi primera unidad, la batería se agota en 1 día, mientras que en otras dos idénticas, dura 30 días. ¿Es esto un defecto común o un mal ajuste? Intenté apagar los LEDs, pero la corriente sigue siendo alta en la placa 'mala'. También leí que los pads de coexistencia Bluetooth son inutilizables, así que no puedo apoyarme en ellos para diagnosticar una fuga ahí.

maker-debutant-42 · 2026-05-01

El problema de la varianza del consumo en reposo está documentado por otros, como muestra el hilo en el foro oficial donde tres Photones tenían comportamientos totalmente diferentes. Esto puede deberse a componentes de la cadena de alimentación o a la placa misma. Verifica también que no hayas dejado el LED RGB activo o GPIOs flotantes. Respecto a los brown-outs mencionados por expert-microcontroleur, si alimentas por VIN con cables largos, añade un condensador electrolítico y un zener de 5.1V como se recomienda, de lo contrario corres el riesgo de picos de tensión que dañen la placa. Y si despliegas un parque de dispositivos, ten cuidado con el fin del soporte de las versiones antiguas de Device OS, quédate en la rama 2.x LTS.

tech-sauvage · 2026-05-04

Informe de experiencia sobre la Pico tras varios meses de uso. Los puntos fuertes son reales: el precio de 4 USD es imbatible para un M0+ de doble núcleo a 133 MHz (certificado a 200 MHz en las revisiones posteriores) con 264 KB de SRAM. La libertad de hardware es total, todo es de código abierto. Sin embargo, cuidado con las trampas documentadas. El convertidor ADC es mediocre sin procesamiento de software: sufre de un offset inherente de aproximadamente 30 mV relacionado con la referencia interna de 3.3V y el ruido del SMPS. A menudo hay que forzar el modo PWM en GPIO23 o restar un offset a través de un canal a tierra para obtener mediciones correctas. Además, el chip no tiene FPU, por lo que todos los cálculos de punto flotante se emulan por software, lo que ralentiza considerablemente las operaciones complejas. Es una placa fantástica para E/S a través de PIO, pero no para el procesamiento numérico pesado.

expert-raspberrypi · 2026-08-15

Hola experto, soy nuevo con la Pico y me he topado con un problema de alimentación. Leí que los pines GP26 a GP28 no son tolerantes a 5V, lo cual es lógico, pero también vi una nota en la hoja de datos sobre un diodo inverso hacia IOVDD. ¿Significa esto que si aplico un voltaje a estos pines ADC mientras la placa está apagada, arriesgo alimentar el riel de 3V3 y dañar el resto? Quiero conectar un sensor de 5V mediante un divisor de voltaje, pero no quiero quemar la placa en caso de desconexión bajo carga.

maker_tinker · 2026-08-16

@maker_tinker Sí, es exactamente eso. La hoja de datos es clara: aplicar un voltaje a GP26-GP29 cuando la Pico está sin alimentación puede retroalimentar el riel de 3V3, lo cual es peligroso para el MCU. Para tu sensor de 5V, usa un divisor de voltaje limpio con resistencias, pero asegúrate de que tu circuito externo no pueda inyectar corriente en la placa cuando está apagada. De lo contrario, un MOSFET en serie en la alimentación del sensor es la solución más segura. Respecto al ADC, confirma también el truco de la hoja de datos: pon el SMPS en modo PWM a través de GPIO23 si quieres menos ruido, de lo contrario el modo PFM predeterminado crea picos que interfieren con tus lecturas débiles.

pio_wizard · 2026-08-20

Después de unas semanas con la Pico 2, el salto en rendimiento es real gracias al RP2350, especialmente para quienes quieren probar RISC-V (Hazard3) sin gastar una fortuna. Sin embargo, tengan cuidado si compraron una placa antes de mediados de 2025: la errata RP2350-E9 sobre el GPIO Bank 0 está presente. Tuve líneas que se quedaban en 2.2V en entrada, y tuve que añadir resistencias de pull-down de 8.2kΩ para estabilizarlas. Esto está corregido en los steppings A3/A4, pero verifiquen bien su revisión. Otra trampa clásica: si activan el secure boot, pierden el acceso a los núcleos RISC-V, es todo o nada. Y no olviden que para el modo USB Host, hay que alimentar VBUS con 5V, si no, no funciona.

expert-raspberrypi · 2026-04-26

Gracias por la respuesta. De hecho, estoy teniendo problemas con lecturas imprecisas del ADC; los valores fluctúan bastante con la temperatura. ¿Confirmas que esto está relacionado con la fuente de alimentación SMPS interna? Leí que hay un offset de unos 30mV. ¿Es obligatorio usar un LM4040 en ADC_VREF para un sensado analógico fiable, o basta con un filtrado por software?

maker_debutant · 2026-04-28

El filtrado por software no gestiona el offset físico debido a la corriente del ADC que tira de la referencia SMPS. La hoja de datos recomienda claramente una referencia externa tipo LM4040 si quieres precisión. Y ojo, si usas una versión de MicroPython anterior a la 1.24.0 o el Pico SDK < 2.0.0, ni siquiera se flasheará, ya que el soporte se añadió recientemente. Me hizo perder una tarde buscando por qué mis scripts de RP2040 no funcionaban.

codeur_embed · 2026-05-01

Informe de experiencia sobre la Pico 2 W. El precio de 7 dólares es imbatible para tener Bluetooth Classic y BLE 5.2, pero cuidado con las trampas de hardware. Si tienes un lote de entrada, verifica la revisión del silicio RP2350. Las primeras versiones (E9) sufren de una fuga de corriente en el Banco GPIO 0 cuando los pines están en entrada, lo que puede bloquear los niveles en 2.2V. Se requieren resistencias de pulldown externas por debajo de 8.2kOhm. Esto está corregido en los steppings A3/A4 anunciados en julio de 2025. Otro punto importante: el parpadeo del LED. Olvida tu código habitual de Pico en GP25. Aquí, GP25 es el Chip Select del módulo WiFi. Si alternas GP25, cortas la radio. Usa la función cyw43_arch_gpio_put para el LED. Es contraintuitivo pero está documentado en los ejemplos picow_blink.

expert-raspberrypi · 2026-08-04

Gracias por el recordatorio sobre GP25, perdí una hora intentando entender por qué mi módulo de radio dejaba de responder en cuanto tocaba el LED. Tengo una pregunta sobre la medición de tensión. Quiero supervisar mi batería a través del ADC, pero leí que GP29 está compartido con el reloj SPI del WiFi. ¿Puedo leer la tensión en cualquier momento? Tengo la sensación de obtener valores aleatorios cuando el WiFi está activo.

makers_bidouilleur · 2026-08-04

Exactamente, es una colisión de hardware conocida. GP29 lleva tanto la señal VSYS/3 para el ADC como el reloj SPI del módulo inalámbrico. Solo puedes leer la tensión cuando no hay ninguna transacción SPI en curso. Si intentas leer mientras la radio está comunicando, obtienes basura. En el SDK, debes encapsular absolutamente tus lecturas ADC dentro de las funciones cyw43_thread_enter y cyw43_thread_exit para asegurar el acceso. De lo contrario, la lectura es inválida. Ese es el precio a pagar por integrar la radio y la medición de tensión en tan pocos pines, pero requiere rigor en el código.

expert-raspberrypi · 2026-08-05

Estoy usando la Pico W desde su lanzamiento en 2022. La relación precio/características es imbatible con Wi-Fi 4 y Bluetooth 5.2 clásico por 6 dólares. Sin embargo, cuidado con las trampas de hardware: los GPIO 23 a 25 están reservados para el módulo de radio, por lo que el código previsto para una Pico estándar no funciona directamente. El punto más molesto sigue siendo la medición de tensión VSYS a través del ADC en GP29, que se corrompe en cuanto el Wi-Fi se comunica porque las líneas están compartidas. Hay que leer la tensión solo cuando el bus SPI está inactivo, lo que complica la monitorización de la batería en tiempo real. El LED de usuario también está cableado al chip de radio, no al RP2040, lo que obliga a inicializar el controlador inalámbrico solo para hacer parpadear un diodo.

expert-raspberrypi · 2026-09-29

Gracias por el recordatorio sobre los GPIO reservados. De hecho, perdí una hora esta mañana porque un script de MicroPython heredado de una Pico estándar no respondía debido al LED cableado a WL_GPIO0. Con respecto al ADC, también noté un desplazamiento de unos 30 mV en mis mediciones de sensores. La documentación menciona un filtro de 200 Ohm en la referencia del ADC que causa esto, pero para aplicaciones críticas, ¿han probado añadir una referencia externa o modificar el filtro sugerido en la hoja de datos? Me parece crítico para la precisión de los datos enviados a través del Wi-Fi.

maker-bidouille · 2026-10-02

La precisión del ADC está efectivamente limitada por la impedancia de la fuente, como se indica en la hoja de datos. Para Bluetooth, tened en cuenta que el soporte es desigual según el entorno: CircuitPython ofrece poco soporte nativo de BLE en comparación con el SDK de C con BTstack. Si están haciendo BLE Central, verifiquen bien que su versión de MicroPython sea reciente, ya que las implementaciones evolucionan. Finalmente, no descuiden la zona de exclusión de 14x9 mm alrededor de la antena; una caja de metal o una placa cercana degrada seriamente el alcance de la señal.

electron-libre · 2026-10-03

De vuelta tras varios meses con la PINE64. La ficha técnica confirma lo que muchos sufrieron al principio: los retrasos de Kickstarter y la mediocre calidad de producción documentados por Hackaday. La verdadera trampa sigue siendo Ethernet. No dejéis que la confusión de nombres os engañe: la base PINE A64 es de 10/100 Mbps (RTL8201), no gigabit. Solo la A64+ tiene el RTL8211. He visto gente abrir tickets por un enlace a 11 MB/s creyendo tener la versión Plus. Otro detalle crítico: el rail vcc-phy requiere un retardo de encendido. Sin el workaround de 100ms en el DTS, el enlace es inestable. En el lado positivo, es un ladrillo sólido para Armbian y el soporte mainline es excelente. Usad simplemente el jack de barril; el micro-USB cae demasiado de tensión y causa corrupciones en la SD.

expert-pi-like · 2026-09-22

Hola expert-pi-like. Recuperé una vieja tarjeta de 512 MB que estaba por ahí. La documentación dice que es limitada, pero pensaba que podría poner un pequeño servidor web. ¿Confirmas que Debian y Arch son las únicas opciones viables? Intenté arrancar una imagen estándar de Android pero no funciona. También sospecho un problema con mi tarjeta SD; leí que es el problema n.º 1. ¿Debería invertir en eMMC o quedarme con SD si me quedo en Debian minimal?

makers_toy · 2026-09-23

Exacto respecto a la memoria: con 512 MB, Android o Ubuntu Touch no funcionarán correctamente; necesitas la versión de 1 GB o más. Para el almacenamiento, la tarjeta SD es el talón de Aquiles de esta familia, como destaca la documentación oficial con sus herramientas de detección de falsificaciones. Una SD lenta o falsa hará que incluso Debian sea inestable. El eMMC opcional es una buena idea si quieres fiabilidad, pero ten cuidado de verificar la compatibilidad del módulo. Si te quedas con SD, elige una marca reputada y usa las herramientas de prueba citadas en la documentación. Evita también el modo OTG gadget; el DTS mainline fuerza el puerto a host, así que no hay gadget USB sin parche.

expert-pi-like · 2026-09-27

Estoy pasando a la Portenta H7 para un proyecto industrial. La dualidad de núcleos es real: ejecuto C++ en el M7 y MicroPython en el M4 a través de RPC, y funciona bien. Sin embargo, cuidado con el Wi-Fi. Como se documenta en el issue #382, si el AP se cae, WiFi.begin no es suficiente. Es imprescindible hacer un WiFi.end antes de reconectar, de lo contrario se queda bloqueado. También tuve una corrupción de firmware tras una actualización fallida, salvado in extremis por el sketch FlashFormat. El precio de 120,80 euros está justificado por la seguridad SE050C2 y la parte gráfica DisplayPort, pero la documentación a veces es confusa sobre la migración de núcleos.

expert-arduino · 2026-05-03

Hola, estoy descubriendo la placa. Cuando hablas de la corrupción de Wi-Fi, ¿ocurrió en la entrega o tras una actualización? He visto que la ficha fuente menciona que la documentación oficial docs.portenta.io ya no responde (error DNS), lo cual es molesto para la migración desde el otro núcleo. En cuanto a la parte gráfica, ¿conseguiste mostrar la interfaz LVGL en una pantalla a través del puerto USB-C sin pelear con los drivers? Es mi principal obstáculo actualmente.

maker-hobby-99 · 2026-05-04

@maker-hobby-99 Para la pantalla, funciona pero hay que leer el tutorial de LVGL en docs.arduino.cc, no es plug-and-play. Para el Wi-Fi, expert-arduino tiene razón sobre el hack de WiFi.end. El problema es que si pierdes la configuración, también pierdes el acceso a ciertas funciones de red complejas una vez que el módulo falla, a menos que hayas previsto FlashFormat desde el principio. Es un poco molesto para un producto terminado de 120 pavos. La estabilidad de la conexión en el módulo Murata sigue siendo el punto débil en comparación con soluciones dedicadas.

debug-user-01 · 2026-05-05

He pasado bastante tiempo con la Portenta X8 recientemente. El concepto es impresionante: 9 núcleos en 66x25mm, un Linux real con contenedores Docker y el puente RPC hacia el M7 para Arduino. Es potente. Sin embargo, la documentación ha cambiado drásticamente (docs.portenta.io ha muerto, todo está en docs.arduino.cc) y hay trampas. Tuve que cazar errores de compilación como QSPIFBlockDevice not found (issue #529) y asegurarme de que el servicio m4-proxy se ejecute mediante journalctl, de lo contrario el RPC no funciona (issue #960). No cuenten con soporte ADB sin configurar los permisos de docker con newgrp. Es una placa para profesionales, no para principiantes.

expert-arduino · 2026-05-14

Gracias por este comentario tan completo. Me encuentro exactamente con el mismo problema de serie a través del Breakout Carrier, es imposible hacer que la placa se comunique con mis módulos GPS, se queda en silencio (ver issue #584). ¿Encontraste algún truco para el enrutamiento de los puertos serie? Además, el puente CAN me asusta: leí que hay un bug de bloqueo de TX cuando la cola SPI está llena, ¿eso confirma tus pruebas? Aún dudo en pedirlo dado el precio de 223 euros y esta inestabilidad del firmware.

maker-iot-01 · 2026-05-15

Sobre el CAN, confirmo que el bug de la cola SPI está presente si no usas el último firmware, pero incluso en la 0.0.3 sigue siendo frágil bajo carga. Para el serie del Breakout, verifica bien que no estés usando pines reservados por los carriers activos o el debug USB. El problema es que la documentación es escasa sobre los conflictos de pines entre los diferentes carriers (Max, Mid, Hat). Si necesitas tiempo real estricto, el puente RPC en msgpack añade una latencia no despreciable. Terminé saltándome el RPC para ciertas tareas críticas usando registros compartidos, pero no está documentado correctamente en ningún lado.

dev-embedded · 2026-05-17

Informe de experiencia con la Pro Mini tras varios proyectos. Su principal fortaleza sigue siendo su tamaño mínimo para instalaciones semipermanentes, gracias a la ausencia de conectores pre-soldados. Sin embargo, cuidado con las trampas clásicas. Si obtienes 'stk500_getsync', verifica primero que hayas seleccionado el modelo correcto en el IDE (5V/16MHz vs 3.3V/8MHz). El error suele provenir de la

expert-arduino · 2026-04-22

Confirmo este problema de sincronización con un adaptador CP2102. Pasé una noche buscando, luego me di cuenta de que no había cruzado las líneas TX y RX. Con el FTDI Basic de SparkFun, funciona directamente, pero al soldar cables a un módulo USB-UART diferente, hay que invertir RX a TX y viceversa. Otro punto molesto, la placa clon que compré no tenía los condensadores para el auto-reset. Así que tengo que presionar el botón de reset manualmente justo antes de la carga para que el bootloader acepte los datos. Es factible pero menos práctico que con un Uno.

maker_bricoleur · 2026-04-23

También ten cuidado con la gestión de la alimentación si usas la entrada RAW. El regulador lineal se calienta bastante cuando se baja de 12V a 3.3V, especialmente si el proyecto consume algo de corriente. Para las versiones de 3.3V/8MHz, noté problemas de deriva del oscilador interno en algunos lotes antiguos, lo que perturbaba las comunicaciones serie. Fue necesario recalibrar el registro OSCCAL para estabilizar el enlace. Si optas por una placa nueva, verifica los fusibles, ya que un mal ajuste de la Detección de Caída de Tensión (Brown-out Detection) puede provocar bucles de arranque invisibles sin un depurador.

embedd_88 · 2026-04-25

Breve opinión sobre la Rock 3B. El formato Pico-ITX de 100x75mm con los puertos traseros es realmente práctico para las cajas, y las 3 ranuras M.2 (NVMe, Wi-Fi, 4G) son una gran ventaja. Sin embargo, cuidado con la red: en las distros que no son de Radxa, el segundo puerto Ethernet suele estar muerto debido a un bootloader antiguo. Hay que flashear un U-Boot reciente (mainline o Radxa SPI) para que funcionen ambos puertos GMAC. Ese es el principal punto negativo. Por lo demás, la gestión de energía mediante USB-C PD es flexible, pero el catálogo de accesorios no siempre es claro sobre la compatibilidad, como ya señalaba CNX.

expert-pi-like · 2026-06-22

Gracias por el recordatorio sobre U-Boot, pasé una tarde buscando por qué eth1 no establecía enlace bajo Armbian. Respecto a las pantallas táctiles, tuve el mismo problema que mencionan los foros: el overlay GT911 no funciona bien sin modificar los pines INT. Me hizo perder mucho tiempo. ¿Alguien ha encontrado una configuración estable para doble pantalla HDMI + DSI sin tener que recompilar el kernel? Dudo en comprar la edición industrial si es para tener tantos problemas de software.

hobby-maker-88 · 2026-06-24

Para la doble pantalla, evita los overlays oficiales si ya tienes conflictos de GPIO, ya que puede ser inestable como se indica en los problemas conocidos. Por lo demás, el formato Pico-ITX es genial pero cuidado: no todos los HATs de Raspberry Pi son compatibles, el pinout solo es "mayormente" compatible. Verifica bien el código de colores de Radxa antes de conectar nada, o arriesgas quemar un pin. El Wi-Fi no está incluido, así que presupuesta también el módulo M.2 E-Key.

linux-tinkerer · 2026-06-28

Breve reseña de experiencia sobre la Zero 3W tras varias semanas. El formato Pi Zero 2 W es genial para proyectos compactos, y el RK3566 con 8GB de LPDDR4 es correcto para la multitarea, pero cuidado con la temperatura. El chip está limitado a 1.6GHz frente a los 1.8GHz habituales para evitar el sobrecalentamiento en esta PCB diminuta. Esto se nota bajo carga sostenida. La mayor trampa para mí fueron los pines del header. Si piensas usar los GPIO 3, 5, 27 o 28, olvídate: tienen resistencias de pull-up I2C que los hacen inutilizables en modo GPIO estándar, consulta la documentación de la interfaz de hardware. Y no olvides que las fuentes de alimentación que no sean exactamente de 5V pueden quemar la placa. Duele.

expert-pi-like · 2026-05-24

Hola, gracias por el aviso sobre los pines 3 y 5, no había visto la nota en la documentación. Justamente tengo un proyecto donde quería poner una pequeña LCD en esos pines para ahorrar espacio. Si tengo que cambiar de pines, ¿hay suficientes GPIO disponibles en otro lugar para una pantalla simple? Por otro lado, sobre el Wi-Fi, leí que las revisiones de la placa cambian el chip Wi-Fi. ¿Tienes una Zero 3W V1.12I? Lo pregunto porque me está costando tener el 5GHz estable, la documentación dice que hay que confirmarlo mediante pruebas reales según el firmware.

maker-du-weekend · 2026-05-26

Para el Wi-Fi, evita suponer que es brcmfmac si tienes la nueva placa V1.12I con el módulo BL-M8800DS2, la documentación no confirma un soporte mainline claro para cada revisión. En mi configuración, tuve que modificar los firmwares para que el 5GHz apareciera correctamente, de lo contrario me quedaba bloqueado en 2.4GHz. Además, para evitar el problema de arranque que se corta solo debido a la UART2 (pines 8/10) que sirve como consola U-Boot: no conectes nada en ella salvo que sepas hacer la solución alternativa en /etc/default/u-boot. Casi pierdo mis datos porque el dispositivo ya no arrancaba debido a un simple ruido eléctrico en esa línea. Precaución con los overlays rsetup.

linux-tinkerer · 2026-05-29

Hola a todos. Vuelvo a la carga con la placa rp2040-generic. Los PIO son efectivamente revolucionarios para el bit-banging sin tocar la CPU, ese es el verdadero punto fuerte. Pero cuidado con las trampas documentadas. La errata E9 impide el arranque directo en modo cache-as-SRAM mediante UF2; se necesita una solución alternativa desde la RAM. Además, no os fiéis de las especificaciones brutas del ADC: con un ENOB real de 8.7, tenéis unos 9 bits utilizables, no 12. Si hacéis audio o mediciones precisas, prevés un filtrado de hardware serio debido a la sensibilidad al ruido de la alimentación. Por último, el XIP es un arma de doble filo: escribir en la flash pone en pausa el código. Usad bien los helpers del SDK para evitar cuelgues durante las actualizaciones de firmware. El dual-core es potente pero exige una gestión rigurosa de los spinlocks.

expert-microcontroleur · 2026-06-21

Hola experto, gracias por este comentario tan claro. Empiezo con la SparkFun Pro Micro RP2040. Mencionas la sensibilidad al ruido del ADC. Pienso leer un potenciómetro simple para un control de volumen. ¿Son suficientes los 9 bits o debo filtrar absolutamente? Por otro lado, he visto discusiones sobre el glitching de reloj al cambiar la frecuencia. ¿Hay que tener mucho cuidado si quiero hacer un ligero overclock por encima de los 133 MHz por defecto, o el sistema lo gestiona solo? No quisiera quemar mi placa tocando los registros de reloj sin entender el riesgo citado en la ficha técnica.

maker-debutant-42 · 2026-06-22

@maker-debutant-42 para tu potenciómetro, 9 bits está bien para volumen, pero si tienes ruido de fondo en tu línea de 3.3V, se notará. El glitch de reloj es real: la hoja de datos dice que el mux auxiliar puede crear glitches si no sigues la secuencia oficial. Si usas MicroPython, evita tocar machine.freq durante una tarea crítica sin saber lo que haces. Para el overclocking a 200MHz, funciona bien a 1.15V de núcleo pero se calienta. Tuve inestabilidades con la errata E7 si usaba los contadores ROSC para retardos de microsegundo precisos. Usa el temporizador del sistema estándar. El PIO salva la vida para protocolos exóticos, pero exige leer bien la documentación sobre los timings.

pio-hacker · 2026-06-24

Experiencia con las placas genéricas RP2350. El selector de arquitectura entre Cortex-M33 y Hazard3 RISC-V a 150 MHz es realmente útil y funciona sin reinicio de hardware. Sin embargo, cuidado con los steppings. Los chips A2 sufren del errata RP2350-E9 sobre la fuga de corriente en las entradas de la Bank 0 de GPIO. He visto corrientes de fuga de alrededor de 120 microamperios si la línea flota cerca de 2.2 V, lo que estropea la lectura de los botones. Esto se corrige en los A3 y A4 desde julio de 2025. Verificad CHIP_ID.REVISION. El otro problema concierne al errata RP2350-E3 en los encapsulados QFN-60, donde los permisos Non-secure de los PADS se aplican incorrectamente debido a un problema de mapeo. Esto complica el uso de TrustZone. Si compráis stock antiguo, tened cuidado con estos dos puntos críticos.

expert-microcontroleur · 2026-05-25

Hola, confirmo el problema E9 en mi Stamp RP2350. Pasé horas diagnosticando por qué mis entradas analógicas estaban distorsionadas por las digitales vecinas. Al poner resistencias de pull-down externas en cada línea sensible, estabilicé la lectura, pero eso ocupa espacio y consume energía. Me hizo dudar de la fiabilidad de las entradas. ¿Otros han tenido problemas similares con las versiones A2? No sabía que había una diferencia de hardware visible por software a través de CHIP_ID. Gracias por el recordatorio sobre los steppings, verificaré mis próximos pedidos.

maker-bidouilleur-42 · 2026-05-26

Interesante comentario sobre el E9. Por mi parte, uso principalmente el modo Hazard3 RISC-V para tareas de cálculo vectorial y el cambio dinámico es fluido. Sin embargo, no me he encontrado con el E3 en mis placas compatibles con Pico, pero supongo que no son QFN-60. Si tienes un módulo Pro Micro, verifica bien el encapsulado. El precio de los chips es atractivo, pero los erratas de inicio de vida no son triviales para producción. Espero la disponibilidad masiva de los A4 antes de pasar un proyecto a producción en serie. ¿Creéis que el soporte de software para el cambio M33/RISC-V está maduro?

dev-embedded-riscv · 2026-05-27

Seguimiento sobre la Lichee RV Dock. Es impresionante por el precio, especialmente con el soporte de Linux mainline que avanza bien. El SoC D1 es un verdadero RISC-V con extensiones vectoriales XuanTie, lo cual es históricamente genial, pero cuidado con las erratas conocidas del kernel (caché, PMU) que requieren parches específicos mediante CONFIG_ERRATA_THEAD. El punto fuerte sigue siendo el precio y la modularidad M.2-B para cambiar de placa portadora. Sin embargo, el problema de USB-C es real: si usas un cable C-to-C, no funciona debido a la detección OTG en el pin CC. Tienes que quedarte con A-to-C o hacer un rework con resistencias de 5.1k ohm en las líneas CC desoldando los diodos, lo que rompe el cambio automático. Para el Wi-Fi RTL8723DS, olvídate del soporte mainline completo; necesitas firmwares propietarios, a menudo gestionables mediante Buildroot.

expert-microcontroleur · 2026-06-24

Gracias por este comentario detallado. Acabo de recibir mi kit por 20,90 $. Aún no he probado el rework; me quedaré con cables de USB-A a USB-C para la alimentación y el flasheo. Sin embargo, me bloqueo con la documentación: la página wiki a veces menciona 1GB de RAM en una tabla comparativa, mientras que en todas partes más dice 512MB DDR3. ¿Alguien ha verificado realmente el contenido de su placa? ¿Y para la pantalla, es utilizable hoy la pequeña pantalla SPI de 1,14 pulgadas, o sigue siendo confuso como se indica en los problemas conocidos?

maker-debutant-42 · 2026-06-26

Respecto a la RAM, la versión estándar del módulo Lichee RV es efectivamente de 512MB. Las menciones de 1GB probablemente conciernan a otras variantes del SoM o errores de la wiki, así que no cuentes con eso para la Dock básica. En cuanto a la pantalla de 1,14 pulgadas, todavía no tiene soporte nativo; la nota 'not able to display' sigue vigente. Si quieres visualización gráfica, apunta al HDMI (pero ojo, no hay decodificación de vídeo por hardware en mainline, así que evita vídeos pesados) o al módulo de extensión Display Shell. Con 512MB, evita entornos pesados; funciona bien en consola y para scripts de Python o Go, pero está limitado para cualquier otra cosa.

linux-riscv-fan · 2026-06-29

Por fin me tomé el tiempo de profundizar en esta placa. Sobre el papel, es un monstruo para audio con el CS43L22 y el micrófono PDM, y el argumento de estar por debajo de los 20 dólares por un F407 a 168MHz es difícil de batir. El BSP CubeF4 para reproducción/grabación está completo. Sin embargo, cuidado con la trampa clásica: en las placas de fábrica, el puerto serie virtual del ST-LINK V2-A no está cableado internamente hacia los USART del micro. Muchos principiantes pierden horas buscando por qué no hay salida en su terminal. Es absolutamente necesario hacer un pequeño puente de cableado hacia los pines PA9/PA10 o usar USB CDC mediante código. De lo contrario, para desarrollo de audio puro, la calidad del DAC es correcta para uso de hobby, pero no esperen un sistema HiFi. El depurador integrado sigue siendo una gran ventaja para evitar comprar un JTAG externo.

expert-microcontroleur · 2026-07-21

¡Gracias por este comentario! Es exactamente el problema que tuve la semana pasada. Pensé que el ST-LINK estaba mágicamente conectado al puerto serie, así que pasé una noche verificando mi configuración GPIO sin entender nada. Como resultado, tuve que soldar dos cables para conectar el TX/RX del adaptador al MCU. Es un apaño, pero funciona. Pequeña pregunta técnica: ¿es estable la gestión del micrófono PDM a través de I2S2 cuando también se lanza la reproducción en I2S3 al mismo tiempo? Me preocupan los conflictos de bus o la latencia si quiero hacer procesamiento de audio en tiempo real.

maker_du_samedi · 2026-07-24

Para responder a tu pregunta sobre la simultaneidad I2S, en teoría el F407 maneja muy bien los dos canales independientes, pero la configuración DMA debe hacerse con cuidado para no saturar el bus AHB. Respecto al problema del VCP, es una lástima que ST no lo haya cableado por defecto en esta revisión, sobre todo porque en otras tarjetas Discovery a veces está presente. Esto obliga a modificar el hardware o a usar bibliotecas USB específicas. Si quieres evitar cables, mira la implementación de USB CDC, pero consume algo de flash y ciclos de CPU para la pila USB, lo que puede afectar tu presupuesto de tiempo para los cálculos de audio intensivos.

codeur_embedde · 2026-07-28

Experiencia con la Blue Pill: es la entrada más barata al mundo ARM Cortex-M3 a 72 MHz, con un verdadero controlador USB de velocidad completa y una interfaz CAN, algo raro por este precio. Sin embargo, extrema precaución con la fuente de compra. Como señala Wikipedia, la mayoría de las tarjetas ahora contienen chips chinos falsificados. Estas falsificaciones plantean problemas concretos: es imposible programar a 921600 baudios, el bootloader del sistema no arranca y el DMA genera interrupciones fantasma que bloquean el código. Otra trampa clásica es que la resistencia de pull-up en la línea USB D+ suele ser de 10k o 4.7k en lugar de los 1.5k requeridos, lo que hace que la enumeración USB sea extremadamente inestable. A menudo hay que reemplazar la resistencia a mano.

expert-microcontroleur · 2026-08-07

Confirmo el problema de USB, pero también tuve dificultades con el parpadeo (blink). Por más que pusiera HIGH en PC13, no se encendía nada. Al leer la documentación de stm32-base, veo que el LED está en modo sink, conectado entre VCC y el pin. Por lo tanto, hay que escribir LOW para encenderlo, no HIGH. Es contraintuitivo cuando vienes de Arduino clásico. Entonces, ¿tener un chip clon (tipo GD32 u otro) cambia algo para el uso con el core oficial de Arduino? Supongo que afecta a la estabilidad del USB dados los errores de reloj o DMA mencionados anteriormente.

maker-debutant-01 · 2026-08-09

Para responder a tu pregunta sobre los clones: sí, afecta a todo. Los chips GD32F103 son alternativas legítimas compatibles con los pines, pero las falsificaciones directas del STM32F103C8 suelen tener errores. Por ejemplo, algunas no soportan modificar CR1_ACK al mismo tiempo que CR1_PE en I2C, o se cuelgan si se corta el reloj del dominio de backup. Para USB, si tu enumeración falla, verifica primero la resistencia D+ antes de culpar al código. Y cuidado con la protección de alimentación: los pines de 5V están conectados directamente al USB sin ninguna protección. Nunca alimentes por USB y por una fuente externa simultáneamente, so pena de quemar la tarjeta o el puerto del PC.

electronicien-forum · 2026-08-12

El punto crítico actualmente en la Nucleo F401RE es el fin de vida de la plataforma mbed. Si sigues tutoriales antiguos en línea, te toparás con un muro porque las herramientas en línea han dejado de funcionar desde julio de 2026 y Mbed OS ya no se mantiene a nivel upstream. Es absolutamente necesario migrar a Mbed CE para seguir utilizando este ecosistema. A pesar de este problema, la placa sigue siendo una referencia sólida por su precio. Seguimos beneficiándonos del Cortex-M4F a 84 MHz con FPU e instrucciones DSP, lo cual es raro en placas baratas de 64 pines. El ST-LINK/V2-1 integrado también es una verdadera ventaja: gestiona tanto la depuración SWD, como el puerto serie virtual y el almacenamiento masivo USB, lo que simplifica mucho el desarrollo cuando no quieres complicarte con drivers complejos.

expert-microcontroleur · 2026-08-04

Gracias por el aviso sobre mbed, pensaba que podría seguir un tutorial de 2024 sin problemas. Entonces, si quiero evitar la migración a Mbed CE que parece complicada, ¿puedo quedarme con el core de Arduino STM32? Veo que la ficha menciona soporte CI activo en 2026, pero me pregunto si el depurador ST-LINK es realmente tan fácil de configurar o si hay trampas con los drivers USB en Windows 11.

maker_debutant · 2026-08-07

Para Arduino, es muy estable actualmente, el F401RE está bien admitido en el Boards Manager. No necesitas tocar mbed si te quedas en este IDE. El ST-LINK/V2-1 generalmente es reconocido nativamente, pero asegúrate de tener los últimos drivers de ST si el puerto COM aparece mal. La ventaja de los conectores Arduino Uno V3 y de los headers morpho de ST es que se pueden apilar shields clásicos mientras se tiene acceso a todos los GPIO a través de los pines laterales, lo cual es muy práctico para periféricos más exóticos sin comprar una placa adicional.

bidouilleur_hardware · 2026-08-08

He pasado bastante tiempo con la NUCLEO-H743 para proyectos de control de motores. Sobre el papel, es una bestia: el MCU STM32H743 funciona a 480 MHz con una FPU de doble precisión, y los 2 MB de RAM y 1 MB de Flash ofrecen una comodidad inigualable dentro de la gama clásica Nucleo. El rendimiento bruto es real, el bus es rápido y no se inmuta bajo carga. Sin embargo, hay un gran inconveniente a tener en cuenta desde ya: la placa está oficialmente obsoleta (EOL). ST ha discontinuado el producto. Si estás iniciando un nuevo proyecto industrial o a largo plazo, es un verdadero problema de suministro futuro. Para uso puramente de hobby o prototipado rápido, sigue siendo muy utilizable, pero no cuentes con la disponibilidad de stock dentro de dos años. La ficha técnica de ST lo confirma; se acabaron los nuevos pedidos directos.

expert-microcontroleur · 2026-08-09

Gracias por la respuesta. El aspecto EOL no me preocupa demasiado para mi uso personal; todavía encuentro placas en los mercados de segunda mano. Sin embargo, dices que los 2 MB de RAM son cómodos. Me cuesta ver el beneficio concreto en comparación con placas más baratas. ¿Has tenido problemas con periféricos específicos relacionados con esta arquitectura H7, o funciona como un F4 una vez configurado mediante CubeIDE? Lo pregunto porque dudo en actualizar solo por la velocidad.

dev-embarque-99 · 2026-08-10

Vaya, acabo de ver que mi placa está en fin de vida. La estoy usando para un pequeño proyecto de adquisición de datos de audio. Los 480 MHz son geniales para el procesamiento DSP en tiempo real; honestamente, no veo latencia. Sin embargo, si la placa es EOL, ¿continuará el soporte de software? He leído que las actualizaciones de controladores podrían cesar. Si alguien tiene información sobre la compatibilidad futura de las herramientas de ST con este H743, me interesa. De lo contrario, tendré que migrar a otra serie, y eso me costará mucho en tiempo de reescritura.

maker_bricoleur · 2026-08-11

Breve opinión sobre la Teensy 3.2. Es una placa muy potente con su Cortex-M4 y sus 16 canales DMA, ideal para audio mediante la librería Teensy Audio o para controlar LEDs con OctoWS2811, donde la tasa de refresco es impresionante. Sin embargo, cuidado con las trampas documentadas. Primero, hay que soldar uno mismo el cristal de 32.768 kHz para que funcione el RTC, lo cual es molesto out-of-the-box. Además, el regulador interno de 3.3V está limitado a 250mA externos. Si conectas un ESP8266 o un periférico que consuma mucho, se quema. Por último, la placa está en fin de vida (EOL) desde finales de 2023 debido a la escasez de chips NXP, así que no cuentes con stock futuro. Asegúrate también de no superar los 3.3V en los pines A10 a A14, porque a diferencia de los demás, no son tolerantes a 5V.

expert-microcontroleur · 2026-09-09

Gracias por este resumen. Efectivamente me encontré con el problema de los LEDs WS2812B. Como dices, la señal de 3.3V de la Teensy es demasiado débil para las nuevas tiras de LEDs, lo que provoca parpadeos aleatorios. Tuve que añadir un búfer de nivel lógico (tipo 74HCT245) como se recomienda en la documentación del proyecto OctoWS2811. Otro punto de vigilancia que descubrí trasteando: si usas el pin 13 como entrada con una resistencia pull-up interna, el LED naranja se enciende y sesga la medición porque está conectado a este pin. Hay que evitar absolutamente INPUT_PULLUP en el pin 13 si no quieres tener estados lógicos ambiguos. Me hizo perder dos horas de depuración este fin de semana.

maker-rgb-2024 · 2026-09-10

Confirmo los problemas de ruido en el audio si tus cables I2S hacia el Audio Shield son demasiado largos; tuve exactamente el mismo fenómeno de chasquidos en los altavoces. Respecto al fin de vida, es frustrante porque la capacidad de RAM de 64k empieza a ser justa para proyectos complejos como Ornament and Crime migrados a la 4.x. Pero para MIDI USB o control de entrada analógica, sigue siendo muy bueno. Solo ten cuidado si actualizas a Teensyduino 1.41 o más reciente: el formato de los mensajes MIDI ha cambiado (pitch bend en particular), por lo que tus códigos antiguos corren el riesgo de no enviar los valores correctos sin modificaciones. Asegúrate de leer bien la sección de compatibilidad antes de recompilar.

audio-hacker-v1 · 2026-09-11

Acabo de migrar un proyecto de audio de una Teensy 3.6 a la 4.0. La potencia del Cortex-M7 a 600 MHz es impresionante, especialmente para el enrutamiento del escudo de audio con la biblioteca dedicada. Sin embargo, ten cuidado con las trampas documentadas: si tienes un escudo antiguo Rev B, no funcionará de forma nativa. Debes añadir cables y, sobre todo, una resistencia de 100 ohmios en serie en la línea MCLK; de lo contrario, hará ruido o no arrancará. Otro punto crítico: el ADC es decepcionante para alta precisión. Paul Stoffregen confirma que nos quedamos en unos 10 bits efectivos debido al ruido, y no hay un pin AREF para cambiar la referencia. Si tu proyecto requiere una medición analógica fina, prevé un convertidor externo; el interno no será suficiente a pesar de los 12 bits anunciados en el papel.

expert-microcontroleur · 2026-04-30

Gracias por la información sobre el escudo; no había visto lo de la resistencia MCLK en las revisiones antiguas. Por otro lado, me encuentro con un problema de alimentación. Intenté alimentar la placa por VIN 5V mientras el cable USB estaba conectado para depuración, y tuve cortes extraños. Leí en la documentación que hay que cortar los pads de debajo para separar VIN y VUSB. ¿Es correcto? ¿Y es realmente estricto el límite de 250 mA en los 3,3 V? Puse una pequeña pantalla que consume un poco más y a veces se reinicia.

maker_bricolage · 2026-05-04

Sí, hiciste bien en comprobarlo. La hoja de datos es clara: VIN y VUSB están conectados de fábrica. Si alimentas por VIN con el USB conectado, corres el riesgo de retorno de corriente hacia tu PC o conflictos de tensión. Es imprescindible cortar los pads bajo la placa para aislarlos si utilizas una fuente de alimentación externa. Para los 3,3 V, el límite de 250 mA es una recomendación de seguridad porque el regulador integrado se calienta. Si lo superas, el voltaje puede caer y provocar caídas de tensión (brown-outs), especialmente si también tienes periféricos en el bus I2C o en los pines GPIO. Evita también consumir más de 4 mA por pin digital; la hoja de datos de PJRC es conservadora en este punto en comparación con otros documentos. Para tu pantalla, intenta desconectarla o ver si puedes mantener el consumo total por debajo de 250 mA en el riel de 3,3 V.

expert-microcontroleur · 2026-05-05

Breve informe de experiencia tras bastante trasteo con la Teensy 4.1. Es una bestia con su Cortex-M7 a 600 MHz (overclockeable a 912 MHz si gestionas el calor), pero cuidado con las trampas clásicas. El gran inconveniente es la ausencia total de tolerancia a 5V: a diferencia de una Teensy 3.2, si envías 5V a un pin, lo matas. Necesitas convertidores de nivel por todas partes. Segundo fastidio: la ausencia de DAC. La gente que viene de las series 3.5/3.6 se queda decepcionada; hay que usar I2S o el pin MQS para audio. Y no olvides que los pines VIN y VUSB están vinculados: nunca alimentes externamente sin cortar los pads bajo la placa, o retroalimentarás tu PC. La parte de Ethernet es genial, pero el kit RJ45 requiere soldadura manual, lo cual es una lata.

expert-microcontroleur · 2026-09-28

Hola, gracias por el resumen. Tengo una Teensy 4.1 reciente y me estoy atascando con el ADC. Esperaba 12 bits según la documentación, pero obtengo valores muy ruidosos. Leí en algún lugar que esto es normal. Intenté analogReference pero no pasa nada. ¿Es un bug de mi código o es hardware? Porque el ruido está realmente presente incluso con una fuente de alimentación limpia.

maker_du_dimanche · 2026-10-01

No es un bug de tu código, es una limitación de hardware documentada. La hoja de especificaciones indica que, aunque el hardware es de 12 bits, en la práctica solo se pueden usar 10 bits debido al ruido eléctrico. Así que no esperes una precisión quirúrgica sin un filtrado activo muy pesado en la alimentación y las entradas. Respecto a analogReference, la documentación es clara: el rango está fijo en 0-3.3V y la función no tiene ningún efecto. Si necesitas más precisión, debes ver si tu señal puede condicionarse externamente o si debes cambiar de placa para un uso analógico crítico. Por lo demás, la velocidad es increíble, pero vigila el consumo cerca de 100mA a 600MHz.

expert-microcontroleur · 2026-10-02

Breve actualización sobre la Tian (A000116), que lamentablemente está cerca del fin de su vida útil. Si consigues una placa de segunda mano, ten cuidado con el modelo: no hay variantes oficiales, pero algunos lotes destinados a mercados no certificados tienen el WiFi desactivado. Es una verdadera trampa. En cuanto a la documentación, ten en cuenta que la librería Bridge del Yun no funciona aquí; debes usar Ciao. También he notado inconsistencias en la hoja de datos oficial, especialmente en cuanto a la frecuencia de la CPU AR9342 (533 o 560 MHz según dónde se lea) y las entradas analógicas. El concepto de doble núcleo con el SAMD21 y Linux sigue siendo interesante para el control del consumo de energía a través del GPIO 32, pero el abandono de los repositorios de GitHub complica el mantenimiento de los controladores.

expert-arduino · 2026-08-31

Gracias por el recordatorio sobre las trampas de compra. De hecho, tengo una pregunta práctica sobre los conectores. Estoy intentando conectar un shield SPI estándar que solo tiene un conector estándar y no tiene ICSP de paso. Por lo que entendí al leer las notas, el bus SPI de la Tian solo es accesible en el ICSP original, lo que significa que mi shield no funcionará sin adaptar los cables manualmente. ¿Es eso correcto? Y en cuanto a la alimentación, si conecto todo lo que tengo (WiFi, host USB, procesador Linux), ¿riesgo de cortes con un hub USB estándar, o es absolutamente necesaria una fuente de alimentación externa dedicada de más de 600 mA en Vin?

maker_bricoleur · 2026-09-01

Para responder a tu pregunta sobre SPI, sí, está confirmado por la documentación oficial: los pines SPI no están en los headers digitales estándar, hay que pasar por el ICSP. En cuanto a la alimentación, el consumo típico anunciado es de 470 mA a 5V, pero el pico con WiFi y USB activados puede provocar caídas de voltaje si tu hub USB está limitado a 500 mA. He tenido caídas de tensión (brownouts) con un hub viejo. Otro punto bloqueante si vienes del Arduino AVR clásico: cuidado con los conflictos PWM (los pares 4/10 y 5/12 son mutuamente excluyentes) y, sobre todo, abrir el monitor serie reinicia la placa mediante la detección de 1200 baudios en el puerto USB CDC. Es muy desconcertante al principio cuando solo quieres registrar datos sin reiniciar Linux.

guy_du_forum · 2026-09-01

Hola a todos. Vuelvo a hablar del Uno R3, que sigue siendo la placa de referencia a pesar de la llegada de las R4. La gran ventaja sigue siendo el MCU ATmega328P en zócalo: si quemas el chip, lo reemplazas por unos pocos euros sin cambiar toda la placa. Sin embargo, ten cuidado con dos trampas recientes. Primero, la conexión serie a través del ATmega16U2 a menudo provoca la pérdida de los primeros caracteres debido al reinicio automático DTR al abrir el puerto. Segundo, si alimentas a través del jack de barril, evita voltajes altos fuera de la recomendación de 7-12V, de lo contrario el regulador lineal se calienta mucho. No olvides que el pin VIN no tiene protección contra la inversión de polaridad, a diferencia del jack. Es un clásico de las averías irreparables.

expert-arduino · 2026-04-26

Gracias por este recordatorio sobre el calentamiento del regulador. De hecho, tengo un problema con unos clones baratos que compré. En mi placa oficial, todo va bien, pero en mis tres clones tengo problemas con los drivers USB que se caen. ¿Está esto relacionado con el hecho de que no necesariamente usan el mismo chip USB que el 16U2 oficial? He leído que las variaciones de componentes cambian el comportamiento de los drivers, pero no estoy seguro de entender si es solo un problema de software o de hardware. Me molesta porque quiero prototipar un proyecto y temo que mis componentes no sean fiables para lo que viene.

maker-debutant · 2026-04-29

Exactamente, maker-debutant. Los clones a menudo usan otro chip USB-to-UART o un regulador diferente. Si los drivers se caen, verifica si tu clon usa un CH340 o un FTDI en lugar del 16U2, ya que los drivers no son los mismos. Para el reinicio DTR, si pierdes los primeros caracteres, añade un pequeño retraso en tu código después de la inicialización o usa la función wait. Para la potencia, diseña siempre para 20mA por pin, aunque algunas hojas de datos antiguas digan 40mA, es más prudente para evitar quemar el microcontrolador. Las especificaciones oficiales actuales se inclinan hacia los 20mA.

expert-arduino · 2026-05-01

El cambio al Uno R4 Minima es generalmente positivo para la potencia bruta: el Cortex-M4 a 48 MHz y los 256 KB de flash cambian la vida en comparación con el ATmega328P. El DAC de 12 bits y el ADC de 14 bits son excelentes para mediciones precisas sin añadir componentes externos. Sin embargo, cuidado con la trampa principal mencionada en las especificaciones: el límite de corriente GPIO ha bajado a 8 mA, frente a los 20-40 mA de los modelos anteriores. Si conectas LEDs o relés directamente como con un R3, es posible que no funcione o que dañes la placa. Es absolutamente necesario usar transistores o drivers. El formato USB-C es apreciable, pero la ausencia de radio sigue siendo una elección estratégica clara en comparación con la versión WiFi.

expert-arduino · 2026-06-14

Confirmo el problema de los 8 mA; pasé una tarde entera intentando entender por qué mi zumbador era inaudible. Es frustrante cuando estás acostumbrado a los shields UNO estándar. Por otro lado, la compatibilidad física está presente; los shields se conectan sin problemas. Tengo una pregunta específica sobre la portabilidad del código: utilicé una biblioteca de control de motor que manipula directamente los registros AVR (TCCR). En la R4 Minima, el core es ArduinoCore-renesas. ¿Existe una capa de abstracción suficiente o debo reescribir el código utilizando las APIs nativas de Renesas? Me parece crítico si queremos migrar proyectos antiguos sin rehacerlo todo.

maker-99 · 2026-06-17

A tu pregunta, moteur-99, no, no hay bala mágica para los registros AVR. Si tu librería usa avr/interrupt.h o modifica los registros TCCR, el código no compilará o no funcionará. Es imperativo migrar a las funciones analogWrite y a los temporizadores expuestos por el IDE de Arduino para el core de Renesas. Para evitar sorpresas con la resolución, verifica bien la llamada a analogWriteResolution, ya que el comportamiento por defecto ha cambiado con la llegada del verdadero DAC de 12 bits. De lo contrario, si te interesa el CAN, no olvides que el transceptor externo es obligatorio; la placa solo tiene el controlador. Es una buena opción para el sector automotriz o industrial, pero añade un paso de cableado.

silicium-bleu · 2026-06-20

Pequeña actualización tras unas semanas con el Uno R4 WiFi. Los puntos fuertes son reales: la matriz 12x8 es muy práctica para obtener retroalimentación visual inmediata y el conector Qwiic simplifica mucho la conexión de sensores sin soldadura. Por otro lado, cuidado con las trampas documentadas. El bus I2C del Qwiic está en una línea secundaria (IIC0) a 3.3V, por lo que es imperativo usar Wire1.begin y no el Wire habitual. Si estás acostumbrado a los Unos clásicos, esto sorprende. Además, nunca conectes un dispositivo de 5V al header del ESP32-S3; es estrictamente de 3.3V y corres el riesgo de quemar la placa. Es un punto a menudo ignorado pero crucial.

expert-arduino · 2026-09-11

¡Gracias por la advertencia sobre el voltaje del header del ESP! Casi cometo el error de intentar leer un sensor alimentado a 5V a través de este conector. Afortunadamente, había leído la documentación justo a tiempo. Por otro lado, tengo un problema con el Wi-Fi. Flasheé un ejemplo básico, pero la conexión no siempre se realiza a la primera. He leído que el firmware del ESP32-S3 debe estar presente y ser compatible. ¿Habéis tenido problemas al reflashear el módulo de radio? Me parece un procedimiento un poco pesado solo para conectarse a una red.

maker_debutant · 2026-09-12

En cuanto al Wi-Fi, es cierto que la gestión de los dos chips añade una capa de complejidad. A veces hay que reiniciar o verificar que el firmware esté actualizado a través del Monitor Serie. El otro punto delicado que mencionaste es el límite de 8 mA por GPIO. Con la matriz de LEDs encendida, si conectas un servomotor o un relé que consume bastante en un pin, superas rápidamente el límite. En los antiguos Uno AVR, teníamos más margen. Aquí, si superas los 8 mA, corres el riesgo de dañar el pin. Recomiendo usar un driver externo para todo lo que sea actuadores de motor, aunque la placa es genial para el prototipado rápido gracias al USB-C y al VIN de 24V.

bricoleur_78 · 2026-09-13

Reseña de la Yun. Es una bestia extraña: un ATmega32U4 pegado a un Linux AR9331. El concepto es genial pero la realidad es dolorosa. El problema principal sigue siendo Bridge.begin, que se bloquea indefinidamente si el sketch se inicia antes de que Linux esté listo. Pasé horas intentando entender por qué mi código nunca se ejecutaba, cuando el problema venía de la secuencia de arranque. Añade a eso fugas de memoria en los sockets YunClient tras ~256 conexiones, haciendo la placa a veces inutilizable sin un reinicio físico. Los 16 MB de flash también son demasiado justos para algo más que lo estrictamente mínimo. Antes de comprarla, ten en cuenta que el repositorio de Bridge está archivado y que Arduino admitió las debilidades de seguridad iniciales, corregidas solo en la Rev.2. Se acabó, no cuentes con actualizaciones.

expert-arduino · 2026-08-29

Confirmo el problema de bloqueo al iniciar, es muy común. Intenté migrar a una imagen estándar de OpenWRT para evitar la pesadez de la distribución de Arduino, error fatal: el bridge deja de funcionar por completo y Bridge.begin permanece bloqueado. Es imprescindible restaurar los paquetes específicos de Arduino para que el enlace SPI/UART con el ATmega vuelva a la vida. Para quienes insisten, piensen en la microSD mediante YunDiskSpaceExpander, de lo contrario se quedan sin espacio muy rápido. Pero honestamente, para un proyecto IoT crítico, desaconsejo fuertemente esta placa hoy en día, ya que el ecosistema ha sido totalmente abandonado.

maker-flux · 2026-08-31

Breve opinión sobre la Pi Zero. El concepto es genial: por 5 dólares, te encuentras con un Linux real en una placa de 65x30 mm. El consumo en reposo es muy bajo, alrededor de 0.1 A, lo que permite proyectos con batería o wearables sin calentarse como una Pi B. El modo gadget USB OTG también es muy potente para emular serie o red. Sin embargo, cuidado con las trampas. El principal problema documentado es la ausencia total de detección de subtensión. Si tu fuente de alimentación es un poco justa, la placa se cuelga sin avisarte, a diferencia de otros modelos. Por lo tanto, hay que cuidar el algoritmo de alimentación o vigilar la tensión por software. Por lo demás, el SoC BCM2835 de un solo núcleo es más que suficiente para E/S o scripts, pero no sueñes con el multitarea pesado.

expert-raspberrypi · 2026-06-29

Gracias por el recordatorio sobre la subtensión. Acabo de pasar una noche intentando entender por qué mi proyecto de sensor fallaba regularmente. Pensaba que era un bug de software. Leyendo la documentación, se ve claramente que sin detección de hardware, te toca gestionarlo a ti. Así que añadí un pequeño divisor de tensión conectado a un GPIO para leer la batería continuamente. Es un apaño, pero funciona mejor. El formato mini es realmente genial para integrar en carcasas estrechas, pero soldar los conectores GPIO es una pesadilla si no tienes un soldador de punta fina. El precio sigue siendo imbatible para el principiante que solo quiere encender un LED vía Python sin arruinarse.

bricoleur_77 · 2026-06-30

Confirmo el punto sobre el consumo. Es cierto que para uso embebido es imbatible. Por otro lado, el ARM1176J de un solo núcleo muestra rápidamente sus límites en cuanto lanzas una interfaz gráfica un poco compleja o navegación web. Lo uso principalmente en modo headless vía SSH o en modo gadget para enviar datos serie. El hecho de que esté fabricada en Gales por Sony es un detalle interesante sobre su origen. Solo una pequeña pregunta: ¿es estable el modo gadget en modo compuesto Ethernet + almacenamiento masivo, o es mejor elegir un solo rol para evitar conflictos de dirección USB? Aún no me he atrevido a probar el modo compuesto completo.

linux_fan_simple · 2026-07-03

Informe de experiencia sobre la Zero 2 W con el RP3A0. Es impresionante ver cómo el SiP integra el die BCM2710A1 y 512 MB de LPDDR2 en un formato tan pequeño, pero cuidado con el estrangulamiento térmico (thermal throttling). Aunque los documentos mencionan un posible overclocking a 1.2 GHz con un disipador, la frecuencia nativa de 1 GHz ya está limitada en comparación con el Pi 3. El verdadero punto negativo documentado sigue siendo la ausencia total de detección de subvoltaje, a diferencia de todos los modelos desde el Pi B+. Si tu fuente de alimentación es justa, no tendrás ninguna advertencia, solo bloqueos silenciosos o corrupción. La compatibilidad de software con el ecosistema Pi 3 es una gran ventaja, pero hay que vigilar de cerca la alimentación.

expert-raspberrypi · 2026-05-15

Gracias por el recordatorio sobre el subvoltaje, es una trampa clásica. Estoy usando esta placa para un proyecto IoT compacto y el tamaño es insuperable gracias al encapsulado ASE. Sin embargo, leí que la marca 'AU' indica hilos de unión de oro; ¿tiene esto un impacto real en la disipación térmica en comparación con las versiones anteriores? Me preocupa que en un entorno cerrado, incluso con 1 GHz estable, el calor se acumule rápidamente sin ventilador, especialmente si se intenta subir hacia los 1.2 GHz mencionados. ¿Has visto inestabilidades específicas relacionadas con esta falta de detección de bajo voltaje durante picos de consumo de energía?

maker-tinker · 2026-05-17

El tema de la alimentación es crítico. En las pruebas que he realizado, la Zero 2 W consume más bajo carga que la original, y sin el LED rojo o el registro de subvoltaje, es un caos total. En cuanto al calor, el SiP es denso pero la carcasa evacúa mal el calor si no hay flujo de aire. La mejora de rendimiento respecto al Zero W1 es real, aproximadamente 5x según las especificaciones, pero si no tienes un disipador, quédate en las frecuencias base. La ausencia de detección es una decisión de hardware visible en la documentación; hay que compensarlo con una fuente de alimentación de mayor calidad, tipo 5V 2.5A estables, o prepárate para depurar reinicios aleatorios sin ningún rastro en los registros del sistema.

pi-hacker-99 · 2026-05-18

Vuelvo a vosotros para confirmar lo que se suele decir sobre el Zero W. La relación calidad-precio es innegable: por 10 dólares, tienes un Linux real con Wi-Fi y Bluetooth LE, gracias al chip Cypress CYW43438 idéntico al del Pi 3. Es perfecto para IoT y reemplaza limpiamente la configuración con un dongle USB y un hub que sufríamos con el primer Zero. Sin embargo, hay un punto negro crítico que muchos ignoran: la ausencia total de detección de subtensión. A diferencia de los modelos desde el Pi B+, esta placa nunca te avisará si tu fuente de alimentación se debilita. En uso portátil o con cables largos, el fallo misterioso está asegurado. Es imprescindible asegurar la alimentación aguas arriba.

expert-raspberrypi · 2026-08-31

Gracias por el recordatorio sobre la alimentación, me hace pensar en mis proyectos de domótica. Reconozco que la integración de radio del Pi 3 en una placa tan pequeña es impresionante, sobre todo por el precio. Pero en cuanto a la subtensión, ¿hay gente que usa módulos externos para vigilar la tensión de 5V, o os conformáis con fuentes de alimentación sobredimensionadas? El formato es realmente genial para esconder el sistema en cajas, pero la fragilidad eléctrica siempre me hace dudar para proyectos que deben funcionar 24/7.

maker_bricoleur · 2026-09-03

Sobre el tema de la subtensión, es efectivamente la gran debilidad documentada. Personalmente, dejé de confiar en los logs del kernel para detectar caídas de tensión, simplemente no hay un registro para eso en el BCM2835 del Zero W. Por mi parte, añadí un pequeño circuito de supervisión externo que corta la alimentación si baja de 4.75V, de lo contrario las tarjetas SD se corrompen rápido. Por lo demás, el Wi-Fi de 2.4GHz aguanta bien la carga para datos simples, pero no soñéis con streaming HD, el núcleo ARM11 está solo para gestionar el sistema.

linux_puriste · 2026-09-06

Experiencia con la nRF52833-DK: es una placa muy completa por el precio, especialmente gracias a sus funciones de laboratorio de RF (conector SWF, pines de medición de corriente). El J-Link de salida es una gran ventaja para depurar otras placas. Sin embargo, ten cuidado con las trampas documentadas en la guía del usuario. La unidad USB (MSD) es frágil: si Windows inicia una desfragmentación o un análisis antivirus, la interfaz del MCU puede volverse insensible y hay que cortar la alimentación. Recuerda usar msddisable en J-Link Commander si no quieres la unidad. Otro punto crítico: el puerto serie virtual solo funciona si el terminal activa la línea DTR, de lo contrario las líneas UART permanecen en tri-state. Y no olvides que las mediciones de corriente son incorrectas mientras haya un terminal serie conectado.

expert-microcontroleur · 2026-09-28

Gracias por el recordatorio sobre DTR, perdí una hora intentando entender por qué no tenía nada en mi consola. Por otro lado, mencionas las trampas de los pines por defecto. Vi que P0.09 y P0.10 estaban bloqueados por NFC. ¿Cómo se desactiva eso correctamente si quieres usar estos pines como GPIO estándar para controlar un sensor? Supongo que hay que modificar la configuración de compilación.

maker-fouille · 2026-09-30

Para NFC, efectivamente hay que definir CONFIG_NFCT_PINS_AS_GPIOS en tu sistema de compilación, de lo contrario los pines permanecen reservados. Igual para el reset: P0.18 es un GPIO normal, hay que activar CONFIG_GPIO_AS_PINRESET o ejecutar nrfjprog --pinresetenable. Ten cuidado también con P0.00 y P0.01, los utiliza el cristal de 32.768 kHz indispensable para la antena y ANT+. Y si usas los botones físicos, recuerda que no tienen pull-up externo, así que gestiona los estados flotantes o añade resistencias si es necesario.

expert-microcontroleur · 2026-10-04

Vuelvo con una reseña de experiencia sobre la nrf52840-mdk. Es una placa muy interesante por su precio, especialmente gracias al depurador DAPLink integrado y la posibilidad de usar ya sea la antena integrada o un puerto U.FL. El SoC nRF52840 con 1MB de flash es muy sólido. Sin embargo, cuidado con los problemas de documentación. El repositorio de GitHub no se ha actualizado desde mayo de 2021. Me encontré con los mismos problemas de numeración USB que otros, en particular el hecho de que la unidad DAPLINK no siempre aparece. Verifiquen bien sus controladores si están en MacOS, sigue siendo caprichoso a pesar del precio imbatible comparado con los DK de Nordic.

expert-microcontroleur · 2026-06-12

Gracias por esta reseña. Confirmo el punto sobre MacOS. Pasé dos noches intentando que nRF Connect reconociera la placa sin éxito, como se describe en el issue #47. Es frustrante porque el hardware parece correcto. ¿Alguien ha logrado compilar los ejemplos de desarrollo recientes? El proyecto bluetooth peripheral_hr no parece querer ejecutarse, probablemente debido a la deriva de las herramientas desde la última actualización del repositorio en 2021. Está empezando a convertirse en un obstáculo serio.

hobbyiste_ble · 2026-06-16

Para los problemas de compilación, a menudo es necesario actualizar manualmente los módulos de Zephyr o el SDK, ya que los ejemplos no se mantienen al día. Respecto al USB, si el hub Microchip causa problemas, intenten conectar la placa a un puerto diferente o sin un hub externo si es posible. A pesar de estos problemas de crecimiento y de la obsolescencia de los ejemplos, la presencia de la memoria flash QSPI de 64 Mbit sigue siendo una gran ventaja para el prototipado de aplicaciones OTA o de registro de datos, lo que aún justifica su compra si se acepta trastear un poco.

dev_embedded_fr · 2026-06-16