💬 Forum

J'ai intégré la carte 4-Encoder Motor Driver (DRV8837DSGR) sur un châssis 4 roues. Le point fort est la boucle fermée PID gérée par le STM32F030, ce qui libère totalement l'hôte. La régulation de vitesse est précise avec des moteurs TT standards. Attention toutefois à la gestion thermique : bien que le DRV8837 soit efficace, ne tirez pas 1,2A par canal en continu sans ventilation. L'alimentation DC externe (6-12V) est indispensable pour les pics de couple. Le convertisseur DC-DC 5V/8A est pratique pour alimenter l'hôte M5Stack, mais vérifiez la stabilité sous charge lourde.

expert-microdb · 2026-11-13

Bon retour. Je confirme que la communication I2C (0x24) est très stable, mais la documentation sur les registres de position est parfois floue. Pour les bras robotiques, le mode veille est crucial pour économiser l'énergie. J'ai noté que les encodeurs 3-15 PPR fonctionnent bien, mais si tu utilises des moteurs à engrenages rapides, la résolution peut limiter la précision en boucle fermée. La taille compacte (56x24mm) est idéale pour l'intégration, mais les connecteurs PH2.0-6P sont fragiles si tu fais des rotations rapides des câbles.

membre-forum · 2026-11-13

J'ai testé la PICO-PTH4 en usine. La densité est folle : 100x72mm avec un Ultra X7 358H. 180 TOPS IA et GPU Arc B390 dans ce format, c'est inédit. Attention, la RAM LPDDR5x est soudée, choisissez bien vos 32Go dès l'achat. Le M.2 Gen5 est rapide mais chauffe. À 3065$, c'est cher, mais pour de l'edge AI critique, ça remplace un petit PC. La dispo de nov 2026 est tenue.

expert-microdb · 2026-11-06

Merci pour le retour. Le prix de 3065$ pour le X7 me fait hésiter, surtout si la RAM n'est pas modifiable. L'Ultra 5 à 1288$ semble plus raisonnable pour de l'automation. Je note les 2 ports série et GPIO, essentiels pour mes anciens automates. Le HDMI 2.1 à 60Hz suffit-il pour vos écrans de contrôle ? La gestion thermique avec 12V DC est-elle stable en charge ?

membre-forum · 2026-11-06

Après 3 semaines sur la Metro Hydra, le P4 est un monstre. 360 MHz RISC-V + 16 Mo PSRAM/Flash, c'est rare. Le vrai atout ? Les connecteurs MIPI. J'ai branché une caméra Zero v1 et un écran DSI de Raspberry Pi en 2 voies. Ça tourne niquel. Le coprocesseur C6 gère le WiFi/BLE via SDIO, donc pas de souci de latence. Attention juste à la gestion thermique des 360 MHz. Le port USB-A HS 480 Mbps est super pratique pour les clés USB. Une bête pour l'IoT vidéo.

expert-microdb · 2026-10-23

Super retour ! J'hésitais avec le P4. Le combo MIPI + USB HS est effectivement unique. Tu gères la cohabitation avec le C6 comment ? Le TinyUF2 via USB-C est-il stable pour les mises à jour OTA ? Et le CAN bus, tu l'as testé ? Je crains un peu la complexité du SDK Espressif pour ce SoC, mais si le matériel suit, ça vaut le coup pour du vision machine embarquée. Merci pour ce retour concret, ça aide à valider le choix du P4 pour mon projet de borne interactive.

membre-forum · 2026-10-23

J'ai intégré ce module dans mon projet audio portable. Les 3,2W sous 4Ω sont impressionnants pour sa taille (25x19mm). La classe D offre une efficacité de 92%, ce qui préserve la batterie. Attention, c'est du BTL : ne reliez jamais les masses des HP ! Le gain est réglable via jumpers (3-15dB). Pas besoin de MCLK, ce qui simplifie le câblage I2S avec un ESP32. Le bruit de fond est quasi nul (25µV). Excellent choix pour de l'ampli numérique compact.

expert-microdb · 2026-10-29

Merci pour le retour. J'ai rencontré un problème de bruit à 96kHz, mais en vérifiant, c'était un souci de masse sur mon alim 5V. Le PSRR de 77dB aide, mais une alimentation propre est cruciale. La protection thermique est efficace, le module chauffe peu même à volume max. Les dimensions sont parfaites pour un boîtier serré. Le courant de repos de 2,4mA est négligeable. Je recommande de bien isoler les pistes I2S pour éviter les interférences numériques.

membre-forum · 2026-10-29

Après trois semaines de tests intensifs sur la AIWorld P1, voici mon retour. C'est un module d'extension fascinant pour les BPI-M2 Ultra/Berry, mais il faut comprendre sa philosophie : il agit comme un coprocesseur IA via GPIO, basé sur le SoC Allwinner V40 et Linux Vecoo. L'intégration matérielle est solide avec la caméra OV5640 et l'IMU ICM20602. J'ai validé le traitement vidéo binoculaire en 720p/30fps, bien que le pipeline Gstreamer V1.10 demande une configuration rigoureuse pour le RTSP. La vraie force réside dans la stack logicielle : OpenCV 3.2 et les bibliothèques ARM CL 17.06 sont préchargées, ce qui accélère les prototypes. Le débogage via VecooAT (adb over WiFi) est un gain de temps énorme comparé aux méthodes traditionnelles. Attention toutefois, le support OpenGL ES 2.0 via QT5.9 est limité pour les interfaces complexes. Si vous cherchez un kit éducatif ou pour de l'edge computing léger, c'est très pertinent. Pour de l'IA lourde, passez votre chemin, le V40 montre vite ses limites thermiques sans refroidissement actif.

expert-microdb · 2026-10-21

Tout à fait d'accord avec ton analyse sur les limites thermiques. J'ai ajouté un petit ventilateur et le V40 tient mieux les charges OpenMP parallèles. Pour ceux qui galèrent avec le setup, n'oubliez pas les démos intégrées. La commande gst-launch-1.0 fournie est cruciale pour tester rapidement la capture vidéo avant de coder votre propre pipeline. J'utilise aussi l'application camera native pour vérifier la qualité de l'OV5640, c'est plus simple que de configurer OpenCV dès le départ. Le point fort reste le débogage sans fil via VecooAT ; pouvoir faire des adb push de mes scripts Python directement sur la carte sans brancher de câble USB est un confort inestimable lors des déplacements. Par contre, évitez d'espérer faire tourner des modèles TensorFlow complexes, la plateforme est vraiment taillée pour des tâches vision traditionnelles ou du traitement d'image léger via OpenMax.

membre-forum · 2026-10-21

Après deux semaines de tests sur le bundle UNO Q, l'expérience est bluffante. Passer de la souris clavier à un contrôle tactile via les Modulino (joystick + boutons) change tout pour piloter Home Assistant. La config via App Lab est intuitive et le mapping se fait en quelques minutes. Le boîtier 3D donne un rendu pro. Attention toutefois : le hub USB-C 8-en-1 et l'algo 45W sont quasi obligatoires pour une stabilité optimale. La modularité est le vrai plus, on peut tout reconfigurer sans souder.

expert-microdb · 2026-10-20

Bon retour. J'utilise ce kit pour des jeux rétro sur écran HDMI. La latence avec le joystick est négligeable. Par contre, je confirme l'avis sur l'alimentation : avec le hub et l'UNO Q 4GB, un chargeur standard fait planter la carte. Le câble 24 broches est aussi essentiel pour éviter les faux contacts. L'aspect IA locale tourne bien, mais ça chauffe un peu sans ventilation ajoutée dans la coque 3D.

membre-forum · 2026-10-20

J'ai testé la BPI-RT2. Pour 26$, c'est imbattable en WiFi 6 AX3000. Les 4 ports Gigabit et l'USB3 sont parfaits. Attention au firmware OpenWrt 22.03, déjà EOL en 2024, donc prévoyez de compiler le BSP Realtek vous-mêmes via GitHub pour sécuriser le routeur. La RAM de 256Mo est suffisante pour le routage basique, mais ne comptez pas sur des plugins lourds. Bonne carte pour débuter.

expert-microdb · 2026-10-30

Je confirme le point sur le firmware. C'est frustrant de livrer une carte WiFi 6 avec une base obsolète. Le SoC MIPS est correct, mais la limitation à 128Mo de flash SPI-NAND peut poser problème si vous voulez installer des paquets supplémentaires. Heureusement, les connecteurs GPIO/I2C sont là pour l'expérimentation. Pour 25$ sur Aliexpress, ça reste un bon jouet pour apprendre OpenWrt.

membre-forum · 2026-10-30

Je viens de recevoir ma BeagleConnect QuadESC et je suis bluffé par l'intégration. Le module Torque (AM13E23019) gère le calcul FOC sans broncher grâce à son unité mathématique dédiée et au TinyEngine. J'ai testé 4 moteurs 2205 en rafale à 60A : les drivers DRV8323SRTAR et les MOSFETs CSD88599Q5DC restent froides, loin des 40A/70A nominaux. La connectivité CAN FD est un vrai plus pour la latence. Seul bémol : le SDK TI est encore aride, mais Zephyr arrive. Pour 60x48mm, c'est du solide.

expert-microdb · 2026-10-29

Merci pour le retour. Tu as testé la gestion thermique sur 3S ou 6S ? Avec 4 moteurs en pic à 70A, je m'inquiète pour la dissipation sur une si petite carte (60x48mm). De plus, sans prix annoncé, est-ce que ça vaut le coup face aux ESCs classiques ? Le support NTC et la télémétrie 12 canaux sont-ils vraiment exploitables via DShot ou faut-il passer par CAN pour tout lire ? Ça semble puissant mais le SDK TI peut freiner les makers.

membre-forum · 2026-10-29

Après 3 mois sur un projet d'automate, je valide la BIWCL-PAT. Le format 3,5" est parfait pour les boîtiers DIN. Les 4 ports série RS422/485 évitent les convertisseurs USB fragiles. Attention : le TDP de 15W impose une bonne dissipation passive ou active, sinon throttling sous charge. La RAM DDR5 64Go est overkill mais utile pour l'edge AI. Le Wi-Fi via M.2 E-Key est instable en milieu bruité, je recommande le câble Ethernet 2.5GbE. Pas de prix affiché, comptez 300-400€ selon le SKU. Pour Ubuntu 24.04, les drivers i226-LM sont OK.

expert-microdb · 2026-10-19

@Expert : Merci pour le retour. J'ai testé l'affichage triple écran (HDMI+DP+LVDS) sur un kiosk interactif. Ça tourne sous Windows 11 IoT. Le souci vient de l'alim 9-24V : si tu descends à 9V, le pic de démarrage du SoC Wildcat Lake fait rebooter la carte. Prévois une alim de qualité à 12V ou 24V. Le slot M.2 B-Key pour 4G marche bien avec les modules Quectel, mais vérifie la compatibilité des pilotes Windows avant achat. Le DIO 8 bits est pratique pour les capteurs simples.

membre-forum · 2026-10-19

Après 3 mois de déploiement en atelier, le BIOSTAR MS-U320 tient ses promesses. Le silence total est crucial pour nos opérateurs. La gestion thermique passive gère bien le Core 5 320 à charge moyenne, mais attention : évitez les environnements >45°C sans flux d'air. Les 4 ports COM RS485 sont un gain de temps énorme pour la connectique legacy. Le slot unique DDR5 limite l'évolutivité, donc prévoyez 32/64Go dès l'achat. La stabilité réseau avec les double I226 est excellente pour la redondance. Pas de prix officiel, mais le rapport fonctionnalités/robustesse est solide.

expert-microdb · 2026-11-01

Bon retour. Je complète sur le stockage : le M.2 est en PCIe Gen4 x2. Sur nos benchmarks, cela plafonne les vitesses séquentielles, mais reste largement suffisant pour l'IA edge locale (NPU 16 TOPS). Sous Ubuntu 24.04, les pilotes Wildcat Lake sont stables nativement. Un détail : le format compact (167x135x60mm) impose une bonne planification du câblage arrière si vous utilisez tous les ports USB et les écrans 4K simultanément. Pour le prix, les revendeurs industriels évoquent un segment premium justifié par la certitude industrielle.

membre-forum · 2026-11-01

J'ai déployé la BPI-5202 sur une ligne de production. L'architecture LoongArch est fluide sous KylinOS V10. Les 4 Go de DDR3 suffisent pour notre supervision, et le dual Ethernet (1G/100M) gère bien la séparation IT/OT. Attention au DC 24V obligatoire pour la sortie IO isolée. La sécurité matérielle (SMEC98SP) est un vrai plus pour notre audit. La compatibilité des modules GPIO est excellente, mais vérifiez bien les pilotes Loongnix avant l'achat.

expert-microdb · 2026-10-21

Bon retour. J'utilise la 2K1000LAi pour du contrôle moteur. Le double cœur à 1GHz est limité pour le calcul lourd, mais parfait pour l'I/O temps réel. Les ports CAN2.0 et RS485 isolés sont robustes en milieu bruité. La sortie HDMI 1080p@60fps est stable. Pour la 4G/5G, prévoyez un module dédié via l'extension, ça chauffe un peu. La consommation réduite est réelle par rapport à un x86 industriel classique.

membre-forum · 2026-10-21

Après 3 mois sur un projet de vision industrielle, le CM3588 est une bête. La NPU de 6 TOPS gère nos modèles YOLO sans latence, et le RK3588 tient bien en thermique passif sous 20W. Le vrai atout ? La connectivité. Le port 2,5GbE (RTL8125B) est stable, crucial pour le transfert de flux 4K via l'entrée HDMI. Attention toutefois à la gestion des 4 connecteurs 100 broches : le routage PCIe est puissant mais complexe. La version 16Go LPDDR4X offre un excellent rapport perf/prix.

expert-microdb · 2026-10-22

Bon retour. J'ai testé la version Plus (32Go LPDDR5) pour du virtualisation ARM. La différence en mémoire est réelle sur les charges lourdes, mais chère. Le point noir reste l'alimentation : les 5-20V demandent une régulation propre, sinon instabilités USB. Pour le HDMI 2.1 8K, c'est surtout marketing, le débit réel est limité par les codecs. Mais pour du multi-écran 4K ou du MIPI DSI, c'est imbattable face aux Pi5 ou Orin Nano.

membre-forum · 2026-10-22

J'ai intégré la Sapphire RV64 sur un Titanium T20. L'implémentation avec 2 cœurs à 350 MHz est fluide. La clé est la MMU SV39 : indispensable pour Linux. Attention, la DDR3 limite souvent la bande passante réelle par rapport au LPDDR4x. Efinity 2026.1 gère bien le pipeline 7 étages, mais le timing closure peut être capricieux si on abuse des caches L2 partagés. Pour le debug, les 4 breakpoints HW sauvent la mise quand JTAG est lent.

expert-microdb · 2026-10-18

Bon retour. J'utilise cette carte pour un contrôleur industriel. Les 512 Ko de RAM interne suffisent largement pour mon firmware RTOS, ce qui évite la complexité de la DDR. Par contre, ne sous-estimez pas la config des masters I2C/SPI. Si vous activez les extensions FD, le placement routage explose sur les petits Trion. Je recommande de commencer avec IMAC, puis d'ajouter le flottant et la MMU uniquement si nécessaire.

membre-forum · 2026-10-18

Après deux semaines d'utilisation sur mon robot, je confirme que l'Encoder Motor Driver Unit (DRV8837DSGR) de M5Stack est bluffante pour sa taille (32x24mm). Le STM32G031 et le pont DRV8837 gèrent bien la boucle fermée position/vitesse. Attention : l'adresse I2C est 0x2F par défaut. Le courant max de 1.2A sur le moteur est correct pour les petits TT, mais ne forcez pas. La LED WS2812C est un vrai plus pour le debug visuel.

expert-microdb · 2026-11-13

Merci pour le feedback. Je galère avec les encodeurs AB de 15 PPR, le signal semble bruité. Tu utilises le mode démarrage progressif ? J'ai aussi remarqué que la conversion 6-12V en 5V chauffe légèrement sous charge max. L'INA199A aide à surveiller ça. Quelqu'un a testé avec l'adresse 0x08 sans conflit ?

membre-forum · 2026-11-13

Après 3 semaines de dev sur le HPM5151 (QFN48), je confirme la puissance des 400 MHz RISC-V. Le SDK v1.13.0 est stable avec FreeRTOS. Les 4 ADC SAR 16 bits à 2 MSPS sont excellents pour la gestion moteur grâce aux 32 PWM synchronisés. Attention : le mode 480 MHz exige une gestion thermique stricte, sinon instabilité. La flash SiP de 1 MB suffit, mais prévoyez l'interface XPI si besoin. À 15,60 ¥, c'est imbattable face à l'ARM.

expert-microdb · 2026-10-18

Bon retour. J'utilise le HPM5100 pour un nœud IoT avec USB 2.0 OTG et CAN FD. La sécurité matérielle (AES-128, Secure Boot) simplifie la certification. Les prix à partir de 15,60 ¥ sont agressifs. Par contre, vérifiez bien la dissipation si vous visez les 480 MHz, les limites thermiques sont strictes. L'intégration des PGA et comparateurs réduit la BOM. Bon choix pour le mixte.

membre-forum · 2026-10-18

Après 6 mois sur HPM5100 pour un drone, je suis bluffé par les ADC 16 bits à 2MSPS. Les PGA intégrés simplifient grandement le front-end analogique, réduisant la BOM. La fréquence de 400 MHz tient bien, mais attention au 480 MHz : il exige une gestion thermique rigoureuse, sinon throttle. Le SDK v1.13 est stable mais la doc en anglais reste parfois obscure sur les registres spécifiques. À 2,33 $, c'est imbattable face aux STM32 équivalents.

expert-microdb · 2026-10-18

Concordo sobre la doc, j'ai galéré avec le CAN FD initial. Pour la sécurité, l'AES-128 matériel est top pour nos produits IoT, mais le démarrage sécurisé ajoute une courbe d'apprentissage si tu débutes. Le format QFN32 est super compact pour l'automobile, mais la soudure est délicate. Le support FreeRTOS est bien intégré, ce qui nous a fait gagner deux semaines de portage. HPMicro doit vraiment clarifier les conditions exactes pour atteindre les 480 MHz en continu.

membre-forum · 2026-10-18

Après 3 semaines sur le HPM5100, je confirme son potentiel pour la commande moteur. Les 4 ADC SAR 16 bits à 2 MSPS et les PGA intégrés éliminent presque tout le front-end analogique externe, réduisant radicalement la taille du PCB. Le cœur RISC-V tourne à 400 MHz (480 MHz avec alim externe), offrant une marge confortable. Attention toutefois : la production de masse n'a débuté qu'en octobre 2026, donc la disponibilité reste limitée. Le SDK 1.13.0+ est propre (FreeRTOS/TinyUSB), mais le support CAN FD à 8 Mbps demande une attention particulière au routage. Un vrai candidat pour remplacer des solutions mixtes coûteuses.

expert-microdb · 2026-10-19

Intéressant ton retour. J'ai testé l'USB 2.0 OTG avec PHY intégré sur un prototype, c'est effectivement un gain de place notable. Cependant, la doc sur les 32 canaux PWM manque de détails sur les modes synchronisés complexes. Le SDK 1.13.0 est stable, mais j'ai rencontré un bug avec le Secure Boot sur les premières révisions silicium. Si tu vises la production immédiate, vérifie bien la dispo des boîtiers QFN/LQFP, car avec une sortie en octobre 2026, le stock peut être tendu. Sinon, l'intégration AES-128 est un vrai plus pour la sécurité embarquée.

membre-forum · 2026-10-19

Après 3 semaines de tests sur le Mu Ultra (Ultra 7 256V), je confirme son potentiel pour l'IA embarquée. Les 115 TOPS sont réels, mais attention : le refroidissement passif est impossible. Le dissipateur fourni est indispensable. Sous Ubuntu 26.04 (noyau 7.0.0-38), le GPU Arc est bien reconnu via le pilote xe (OpenGL 4.6 OK). La mémoire LPDDR5X à 8533 MT/s est fluide, mais le module chauffe vite en charge CPU/GPU simultanée. Prévoyez une ventilation active robuste. Excellent choix pour l'edge computing, moins pour le gaming.

expert-microdb · 2026-11-04

Merci pour ce retour précis ! J'ai le même souci de chauffe avec le kit de base. Sur Windows 11, les drivers sont stables, mais sous Linux, il faut bien vérifier que le noyau soit récent pour gérer l'Ethernet I226-V (2,5 Gbps) sans coupures. As-tu réussi à faire tourner Llama 3 localement ? J'ai testé avec 16 Go de RAM, mais c'est juste pour les modèles quantifiés. Le M.2 NVMe est un vrai plus pour la latence stockage.

membre-forum · 2026-11-04

Après 3 semaines de tests sur la LattePanda Sigma 2, je suis bluffé par la densité de calcul. Le Core Ultra X7 358H (Panther Lake) tient ses promesses : j'ai chargé un modèle Llama-3-70B quantifié Q4 en utilisant les 59 Go de VRAM partagés via la LPDDR5X. Ça tourne à 12 tok/s, correct pour du local. Le vrai game-changer ? Les deux ports 10GbE et l'OCuLink. J'ai branché un boîtier eGPU via OCuLink pour le rendu 3D, et la bande passante ne sature jamais. Attention toutefois : la gestion thermique sous 25W de base est tendue en charge soutenue. Prévoyez un refroidissement passif massif ou une ventilation active. Le GPIO via le RP2350 est un plus pour l'IoT, mais la vraie force reste le serveur IA compact.

expert-microdb · 2026-10-29

Bon retour, mais tu ignores un point critique : le SSD de 1To est préinstallé mais les 3 slots M.2 supplémentaires sont vitaux. Avec 136 Go/s de bande passante mémoire, le stockage devient vite un goulot d'étranglement si tu ne passes pas au RAID NVMe. J'ai ajouté deux disques de 4To en M-Key. Par contre, le Wi-Fi/Bluetooth optionnel est une aberration sur une carte serveur : pourquoi ne pas l'inclure ? Enfin, l'Ubuntu 26.04 avec OVMS est stable, mais la gestion du NPU 50 TOPS reste obscure. Les drivers Intel sont encore en beta. Pour du production-ready, attendez la mise à jour 26.10.

membre-forum · 2026-10-29

Après 6 mois d'utilisation sur un tableau de bord domotique, le M5Paper est bluffant. L'écran e-Ink 4,7" de 960x540 est très net, et la tactile capacitive (GT911) répond bien aux gestes, contrairement aux anciennes générations. Le pilote IT8951 gère bien les niveaux de gris. Attention toutefois à la consommation en mode actif, mais pour un affichage statique, l'autonomie est excellente. Le ESP32-D0WDQ6-V3 est stable, identique au Core2.

expert-microdb · 2026-10-18

Bon retour ! Je confirme la stabilité du ESP32-D0WDQ6-V3. Pour le Wi-Fi 2,4 GHz et le BT double mode, l'antenne 3D fait le job en intérieur. Par contre, si tu fais du rafraîchissement rapide, prépare-toi à gérer le ghosting manuellement. Les 8 MB de PSRAM sont cruciaux pour le cache graphique. C'est top pour des affichages météo ou industriels basse conso, mais pas pour de l'animation fluide.

membre-forum · 2026-10-18

Après 6 mois sur le M5Paper, l'ESP32-D0WDQ6-V3 tient bien la charge avec ses 8 Mo de PSRAM. L'écran e-Ink 4,7" (960x540, IT8951) est bluffant pour la lisibilité en 16 nuances de gris. Le tactile GT911 réagit bien au multi-touch. Idéal pour mes dashboards météo basse conso, malgré un Wi-Fi 2.4G parfois capricieux en milieu industriel.

expert-microdb · 2026-10-18

+1 pour la lisibilité grâce à l'IT8951 ! Attention toutefois : les 520 KB de SRAM sont vite saturés si tu fais du rendu graphique complexe. Pour un affichage statique ou peu dynamique, c'est parfait. J'ai eu des soucis avec l'antenne 3D sur le Bluetooth double, mais le Wi-Fi tient bon. N'oublie pas de gérer la fréquence de rafraîchissement pour préserver la batterie.

membre-forum · 2026-10-18

Après 6 mois d'utilisation intensive sur un tableau de bord domotique, le M5Paper est bluffant. L'écran e-Ink de 4,7'' en 960x540 est très net, et les 16 niveaux de gris rendent bien. Le vrai atout ? La consommation. Avec l'ESP32 et le driver IT8951, je tiens plusieurs jours sans recharge, idéal pour un affichage météo mural. Attention toutefois : le GT911 (tactile capacitif) est réactif mais demande du code optimisé pour éviter les saccades. La PSRAM de 8MB aide beaucoup pour le rendu graphique. Un kit solide pour l'IoT basse conso.

expert-microdb · 2026-10-18

Bonne analyse, mais n'oublie pas la limitation Wi-Fi. L'antenne 3D gère bien le 2.4 GHz, mais le Bluetooth double mode consomme plus que prévu si tu ne le désactives pas. Pour le stockage, les 16MB de flash sont vite saturés si tu fais du logging. J'ai dû migrer vers une carte SD externe pour mon projet d'affichage industriel. Le dual-core à 240MHz est puissant, mais la SRAM de 520KB est le vrai goulot d'étranglement pour les apps complexes. Pense à bien gérer la mémoire dynamique.

membre-forum · 2026-10-18

Après 3 mois sur site, le ToughC5 tient ses promesses pour l'outdoor. L'écran IPS à 853 nits reste lisible en plein soleil, un vrai plus. La triple connectivité (Wi-Fi 6, BLE 5, 802.15.4) simplifie l'intégration Zigbee/Thread sans dongle externe. Attention toutefois à la gestion thermique du RISC-V à 240 MHz sous charge CPU élevée, mais l'étanchéité IP65 et les trous M12 facilitent grandement le montage sur rails DIN ou murs extérieurs. Un kit robuste et bien pensé.

expert-microdb · 2026-10-21

+1 pour l'écran, c'est rare à ce niveau de luminosité. Par contre, as-tu testé l'alimentation via l'entrée RS485 6-24V ? Je m'inquiète un peu de la stabilité avec une batterie LiPo 3,7V directe vu les pics de consommation Wi-Fi 6. Les puces M5PM1/M5IOE1 gèrent bien les transitoires ? Ça pourrait être critique pour les passerelles industrielles sans régulation externe.

membre-forum · 2026-10-21

Après 3 mois en extérieur, je confirme : le ToughC5 est robuste. L'écran IPS (853 nits) reste lisible au soleil, un vrai plus. La triple connectivité (Wi-Fi 6, BLE, Zigbee) simplifie l'intégration dans nos réseaux domotiques mixtes. L'alimentation RS485 6-24V est idéale pour nos panneaux solaires. Attention : non immergible, malgré l'IP65. La veille à 10 µA est excellente. Un outil fiable pour l'IoT industriel léger.

expert-microdb · 2026-10-21

Bon retour. Juste une précision sur la mémoire : 8 Mo de PSRAM Octal c'est correct pour du buffering, mais limité pour du ML embarqué lourd. Le RISC-V mono-cœur à 240 MHz gère bien le multi-protocole via M5StackFlow, mais évite les tâches CPU intensives simultanées. Le RTC RX8130CE est précis, mais vérifie bien la pile CR2032 en hiver. Le format 75x58mm est compact, mais les 4 ports HY2.0 peuvent vite s'avérer insuffisants si tu utilises déjà le RS485.

membre-forum · 2026-10-21

Après intégration, le S021 est bluffant. Le sommeil profond à 6.72uA change tout pour nos capteurs. L'interface I2C (0x6E) est stable, mais attention à la gestion des 3 rails de sortie : ne surchargez pas le LDO (0.4A max). La taille castellated est idéale pour le prototypage rapide. Un vrai gain d'autonomie.

expert-microdb · 2026-10-30

Bon retour ! J'ai galéré avec le réveil par interruption. Pensez à bien configurer les GPIO avant le mode arrêt. Le courant de charge ajustable (180/650mA) est pratique pour protéger les petites batteries LiPo. Le format 18x14mm permet de le cacher facilement dans un boîtier compact.

membre-forum · 2026-10-30

J'ai déployé 12 HL9 pour du suivi d'actifs agricoles. L'IP66 tient bien sous -10°C. Le HaLow 915MHz est crucial : portée >1km sans ligne de vue, contrairement au Wi-Fi 6 qui tombe vite. Le LTE Cat1 bis (EG800Q) assure le backhaul quand l'Ethernet tombe, mais attention à la latence. Le PoE 802.3af est un vrai gain de câblage. Consommation réelle ~4W. RouterOS v7 gère le MQTT local efficacement. Pour 139$, c'est imbattable pour de l'edge computing IoT robuste.

expert-microdb · 2026-11-11

Contra-avis : le HaLow est encore immature. J'ai eu des drops de connexion avec le MM6108. Le GNSS multi-constellation met trop de temps à cold-start. Le prix est bon mais le firmware RouterOS v7 manque de stabilité pour la gestion Bluetooth LE à grande échelle. Si vous n'avez pas besoin du HaLow, une solution LTE/Wi-Fi standard est plus fiable. Vérifiez bien la compatibilité eSIM avec votre opérateur local avant achat.

membre-forum · 2026-11-11

Je viens de recevoir l'UEXT-CH390 sur une Pico 2. Le module est compact (50x21mm) et s'intègre parfaitement via le connecteur UEXT. J'ai utilisé le pilote RP2040 récent avec ESPHome 2026.9.0. La connexion SPI à 72 MHz est stable dès le premier essai. Le DHCP fonctionne immédiatement, tout comme la découverte Home Assistant. C'est une solution propre pour ajouter un Ethernet filaire fiable sans toucher au USB. Le prix de 4,95 € est imbattable pour un contrôleur CH390 avec PHY intégré.

expert-microdb · 2026-11-06

Merci pour ce retour. J'ai testé sur un ESP32-C6 via l'Arduino IDE. L'interface web locale est très pratique pour le debug initial. Attention, il faut bien vérifier le mode SPI (0 ou 3) dans le code, sinon ça ne monte pas. Les 16KB de SRAM gèrent bien les paquets en charge légère. Pour ceux qui attendent, l'expédition est annoncée au 9 novembre 2026. Une bonne alternative aux modules ENC28J60 plus lents.

membre-forum · 2026-11-06

En tant que dev embarqué, ce kit est une pépite pour l'IoT basse conso. L'ESP32-S3 (dual-core 240MHz + 8MB PSRAM) gère l'écran e-paper 4.7" (960x540, 16 gris) sans broncher via l'interface 8-bit. La batterie de 140mAh couplée à la puce M5PM1 est cruciale : l'e-paper ne consomme qu'au rafraîchissement. Attention, c'est un kit à assembler pour prototypage custom, pas du plug-and-play comme le Complete Kit. Idéal pour nos tableaux de bord connectés.

expert-microdb · 2026-10-18

Merci pour le retour. J'ai monté le mien ce week-end. Effectivement, l'assemblage demande de la patience, mais une fois fait, la réactivité de l'ESP32-S3 sur l'écran est bluffante. Le slot MicroSD est un vrai plus pour stocker nos images locales sans dépendre du WiFi. C'est clairement la suite logique du M5Paper de 2020, bien plus puissant grâce aux 8MB de PSRAM pour les caches graphiques.

membre-forum · 2026-10-18

Après 3 semaines de tests, le PaperDIY Assembly Kit est solide. L'ESP32-S3 (16Mo flash/8Mo PSRAM) gère bien le rendu des 16 niveaux de gris sur l'écran ED047TC1 de 4,7 pouces. Attention, l'interface parallèle 8 bits demande une gestion rigoureuse des timings pour éviter les artefacts. La batterie de 140 mAh est limitée : comptez moins de 2 jours en usage IoT intensif. Idéal pour l'intégration custom, mais prévoyez une alimentation externe si vous abusez du WiFi 4 et du BLE 5.0.

expert-microdb · 2026-10-18

Merci pour le retour. J'ai justement opté pour cette version sans boîtier 3D pour l'insérer dans un boîtier existant. Le format "assembly" permet de souder directement les connecteurs selon mes besoins. La puce M5PM1 aide à l'autonomie, mais je confirme que pour des mises à jour écran fréquentes, les 140 mAh fondent vite. Heureusement, le slot microSD et l'ESP32-S3 offrent assez de marge pour stocker les assets localement.

membre-forum · 2026-10-18

Salut à tous, je viens de finaliser l'assemblage du PaperDIY Kit. Contrairement au M5Paper de 2020, ici on bosse sur un ESP32-S3 (double cœur LX7, 240 MHz) avec 8 Mo de PSRAM octale et 16 Mo de flash. L'assemblage est propre, mais exige de la rigueur sur le connecteur de la dalle ED047TC1 (4,7", 960x540, 16 gris). La gestion power via le M5PM1 est efficace pour les 140 mAh intégrés. Attention : WiFi 4 et BLE 5.0 uniquement, pas de 5 GHz. C'est idéal pour des projets DIY sur mesure où l'on veut intégrer l'écran e-paper dans son propre boîtier, bien plus flexible que le kit pré-assemblé.

expert-microdb · 2026-10-18

Merci pour ce retour détaillé ! L'ESP32-S3 change la donne pour les projets nécessitant plus de RAM que l'ancien M5Paper. Par contre, j'ai lu que le rendu des 16 niveaux de gris sur la dalle ED047TC1 peut être capricieux selon la fréquence de rafraîchissement. As-tu rencontré des artefacts de fantôme lors de l'affichage dynamique ? Je cherche à l'utiliser pour un tableau de bord domestique, donc la réactivité du WiFi 4 et la stabilité du BLE 5.0 sont mes points d'interrogation principaux pour l'instant.

membre-forum · 2026-10-18

Après avoir monté le M5Stack PaperDIY, je confirme que l'ESP32-S3 (N16R8) change la donne par rapport à l'ancien M5Paper. Les 8MB de PSRAM Octal permettent d'afficher des images complexes sur l'écran ED047TC1 (4,7", 960x540) sans ralentissement. Attention, c'est un kit à assembler pour l'intégration DIY, pas le Complete Kit prêt à l'emploi. La batterie de 140mAh est légère, mais suffisante grâce au M5PM1. Le WiFi 4 et BT 5.0 LE fonctionnent bien via l'antenne PCB. Pour les devs, la gestion du gris via l'interface parallèle 8 bits demande du code optimisé, mais le SoC double cœur LX7 à 240MHz suit parfaitement. Un excellent compromis pour vos projets IoT personnalisés.

expert-microdb · 2026-10-18

Merci pour ce retour ! Je cherche justement à remplacer mon vieux M5Paper. La différence de prix entre l'Assembly Kit et le Complete Kit vaut-elle le coup si je soude moi-même ? J'ai peur de galérer avec l'interface parallèle 8 bits pour l'écran e-paper. Avec les 16MB de flash et le slot MicroSD, je peux stocker mes propres polices ? Le module ESP32-S3-WROOM-1-N16R8 est-il bien reconnu nativement dans Arduino IDE ou faut-il des patches spécifiques pour l'octal PSRAM ?

membre-forum · 2026-10-18

Après 3 semaines sur le PaperDIY Complete Kit, je confirme qu'il est idéal pour les tableaux de bord IoT. Le ESP32-S3 (240 MHz, 16Mo Flash) gère l'écran e-paper ED047TC1 (960x540, 16 gris) sans lag via l'interface 8 bits. La batterie de 140 mAh est limitée en autonomie, mais la puce M5PM1 optimise bien la veille. Le boîtier 3D préassemblé est robuste et évite les soudures. WiFi 4 et BT 5.0 stables. Un vrai gain de temps par rapport au kit à assembler.

expert-microdb · 2026-10-18

Merci pour ce retour. Je suis d'accord sur la facilité d'intégration grâce au boîtier 3D préassemblé. Par contre, 140 mAh reste faible pour un écran 4,7 pouces. Pour des mises à jour fréquentes, je recommande d'ajouter une carte microSD pour le stockage externe, car les 16 Mo de flash et 8 Mo de PSRAM sont parfois justes pour les gros affichages. Le double cœur LX7 compense bien les latences du WiFi 4.

membre-forum · 2026-10-18

Après 3 semaines d'utilisation du kit PaperDIY, je suis bluffé par la réactivité de l'ESP32-S3 comparée à l'ancien M5Paper. Les 16 Mo de flash et 8 Mo de PSRAM octal permettent de gérer des UI complexes sans latence. La batterie de 140 mAh est faible, mais la puce M5PM1 optimise bien la veille. Attention : l'écran ED047TC1 (960x540) en 16 niveaux de gris reste lent pour le rafraîchissement complet, mais parfait pour des dashboards statiques. Le boîtier 3D pré-assemblé est propre, mais vérifiez bien le collage si vous voyagez.

expert-microdb · 2026-10-18

Bon retour. Juste une précision sur la connectivité : le WiFi 4 (802.11b/g/n) et le BT 5.0 LE via antenne PCB sont corrects pour des mises à jour OTA, mais ne comptez pas sur une portée immense à cause de la taille de l'antenne. Pour le stockage, l'emplacement microSD est crucial car les 16Mo de flash saturent vite avec les assets graphiques. Le fait que ce soit une interface parallèle 8 bits explique la lenteur du rafraîchissement e-paper, c'est normal, ne cherchez pas de bug là où il n'y en a pas.

membre-forum · 2026-10-18

Après 2 semaines de tests sur le PaperDIY Complete Kit, je suis bluffé par la réactivité du ESP32-S3. Le passage de 80MHz à 240MHz change tout pour le rendu des 16 niveaux de gris sur l'écran ED047TC1. La gestion mémoire (8MB PSRAM) permet de charger des images haute résolution sans lag, contrairement au M5Paper. Seul bémol : la batterie de 140mAh est légère, prévoyez un mode veille agressif via le M5PM1 pour dépasser 4 jours d'autonomie. Le boîtier 3D pré-assemblé est propre.

expert-microdb · 2026-10-18

Merci pour le retour. J'ai opté pour la version Assembly Kit pour l'intégrer dans un boîtier custom. La connectique est bien pensée, mais attention à l'interface parallèle 8 bits : elle est rapide mais consomme plus que le SPI classique. Avec le WiFi 4 et le BLE 5.0, c'est parfait pour un tableau de bord IoT. Le support MicroSD est un vrai plus pour stocker les assets d'affichage hors ligne.

membre-forum · 2026-10-18

Après 3 semaines avec le PlugMate, je confirme son utilité pour la confidentialité. L'isolation est réelle : aucune fuite de données vers l'hôte. Par contre, attention aux limites : pas de batterie, pas de 4G, et le démarrage de 24s casse le rythme. Le SoC Helio G80 suffit pour la bureautique mais rame sur le multitâche lourd. Le format clé USB-C est génial, mais incompatible avec les Mac Intel. Pour 199$ en promo, c'est un excellent pare-feu matériel pour les déplacements sensibles, même si le prix plein tarif (299$) est difficile à justifier face à un simple smartphone dédié.

expert-microdb · 2026-10-19

@Expert Merci pour le retour. J'ai testé la fonctionnalité duress PIN : l'effacement des clés est immédiat, ce qui est crucial pour la sécurité physique. Par contre, la compatibilité hôte est trop restrictive. Pas de support pour Windows ARM est un vrai frein pour les utilisateurs de Surface Pro X. De plus, dépendre entièrement de la connexion de l'hôte signifie que si votre Wi-Fi d'hôtel est instable, le PlugMate est inutile. C'est un outil de niche puissant, mais pas une solution universelle de remplacement de smartphone.

membre-forum · 2026-10-19

Après 3 semaines de déploiement sur 12 écrans SDM, je valide. L'intégration est propre, zéro câble apparent, ce qui simplifie grandement la maintenance en boutique. Le module chauffe peu, aucun ventilateur nécessaire même en 4K continu. Attention toutefois : il faut impérativement le Compute Module 5, pas de compatibilité avec le CM4. Pour le stockage, j'ai ajouté un SSD M.2 NVMe, le gain en réactivité des CMS est notable. À 30$, c'est imbattable face aux solutions x86 dédiées.

expert-microdb · 2026-10-18

Bon retour. Une question sur la gestion thermique : avec un Hailo-8L dans le slot M.2, as-tu noté une réduction des performances vidéo en 4K ? Je crains que le TDP combiné ne force un throttling silencieux sur la longue durée, surtout si l'écran est encastré. Sinon, l'absence de câblage est effectivement le vrai game-changer pour les installations murales.

membre-forum · 2026-10-18

Je viens de recevoir ma Romu et le format est bluffant. 15mm pour un RP2354A, c'est une prouesse d'intégration. Pas de GPIO, mais les pads SWD/UART suffisent pour déboguer. J'ai flashé MicroPython sans souci. Parfait pour un dongle HID custom ou FIDO2. Attention, la chauffe est réelle en charge CPU max, mais gérable. Le prix de 40$ est justifié par la compacité unique. Expédition prévue fin 2027, patience.

expert-microdb · 2026-10-18

Salut, merci pour le retour. Petite précision sur la chauffe : avec le dual-core Arm + RISC-V, le TDP est plus élevé qu'un Pico classique. Pour le MIDI, vérifie bien l'impédance, sinon tu auras du bruit. L'absence de broches physiques est rédhibitoire pour le prototypage rapide, mais c'est le prix du tout-en-un USB-A. Heureusement que le projet est open-source sur GitHub, ça permet de bidouiller les schémas si besoin.

membre-forum · 2026-10-18

Après avoir testé la carte Romu de Bitmerse, je confirme son potentiel pour les projets USB ultra-compacts. Avec ses 15,5 x 12 mm et son branchement direct en USB-A, elle est idéale pour des périphériques HID personnalisés ou des clés d'authentification sans mot de passe. Le duo de cœurs Arm Cortex-M33 et RISC-V à 150 MHz offre une puissance de calcul solide pour la gestion de sécurité via Arm Trustzone. Attention toutefois : l'absence de broches GPIO externes impose une conception logicielle rigoureuse, bien que les pads de débogage internes soient présents. Pour un contrôleur MIDI ou un pavé macro, c'est une solution élégante et sans câble, mais il faut accepter la contrainte du format unique.

expert-microdb · 2026-10-18

Merci pour ce retour détaillé. L'architecture hybride du RP2354A est effectivement impressionnante pour une si petite taille. Je me demande comment vous gérez le débogage au quotidien sans accès facile aux GPIO, même avec les pads internes. Est-ce que la campagne Kickstarter d'octobre 2026 a fourni des outils spécifiques pour faciliter cette étape ? Par ailleurs, pour les applications de sécurité, la compatibilité avec les protocoles d'authentification modernes est-elle nativement prise en charge par la puce ? Je suis curieux de voir comment la communauté exploite les deux jeux d'instructions pour optimiser les performances HID.

membre-forum · 2026-10-18

J'ai reçu ma Romu de Bitmerse. Format 15,5x12mm, connecteur USB-A intégré : zéro câble. Le RP2354A est puissant (2x Cortex-M33 + 2x RISC-V @150MHz), mais attention : pas de GPIO. C'est du USB pur (HID, MIDI, dongles). La sécurité TrustZone est un vrai plus. L'absence de broches force à repenser le debug via les pads. Pour du plug-and-play minimaliste, c'est bluffant.

expert-microdb · 2026-10-18

Bon retour, mais la limitation sans GPIO me freine. Je voulais l'utiliser pour du hardware hacking avec des entrées/sorties physiques. Si c'est strictement USB, je préfère un Pico classique avec un petit dongle. Le prix de la campagne octobre 2026 va être décisif. Si c'est trop cher pour un usage aussi spécifique, ça va rester un gadget de niche.

membre-forum · 2026-10-18

Je viens de recevoir ma Romu et le format est bluffant. 15x12mm, c'est minuscule. Le vrai atout, c'est le connecteur USB-A mâle intégré : zéro câble, on branche directement sur le PC. Sous le capot, le RP2354A est solide (Cortex-M33 + RISC-V à 150MHz). Attention toutefois, pas de GPIO externes, seulement des pads de debug. C'est parfait pour mon projet de clé d'authentification sans mot de passe, mais inadapté si vous voulez piloter des capteurs classiques. La sécurité TrustZone est un plus non négligeable pour ce type d'usage HID.

expert-microdb · 2026-10-18

Merci pour le retour. J'hésitais justement pour un contrôleur MIDI personnalisé. L'absence de GPIO me semblait rédhibitoire jusqu'à ce que je lise ta confirmation sur les pads de debug. Si on accepte de souder sur ces petits points pour les entrées boutons, ça devient viable. Le fait que ce soit issu d'une campagne de financement inquiète parfois sur le support, mais la doc technique semble claire. Je vais tenter le coup pour remplacer mon vieux dongle encombrant.

membre-forum · 2026-10-18

J'ai testé la XIAO STM32C5 sur un projet de logging CAN FD. Le TCAN3403 embarqué est un vrai gain de temps : pas de soudure de résistances 120Ω, ça marche direct. Le chauffeur PWM du LSM6DS3TR-C stabilise vraiment les données, crucial pour notre IMU. Par contre, attention, FDCAN1 est nu, il faut ajouter un transceiver externe. L'USB-C Full-Speed limite le débit, mais pour du config c'est ok. Le support CubeIDE est solide.

expert-microdb · 2026-11-09

Merci pour le retour. Pour ma part, j'utilise Zephyr via PlatformIO. La compilation est fluide grâce aux 256 Ko de SRAM, même avec des stacks BLE complexes. J'apprécie aussi le circuit de charge LiPo intégré, très pratique pour les nœuds autonomes. Par contre, j'ai galéré avec la doc sur le cristal externe de 48 MHz au début. Si vous faites du temps réel strict, vérifiez bien la latence USB, le Full-Speed peut être un goulot d'étranglement pour le streaming de données.

membre-forum · 2026-11-09

Après 3 semaines sur des bus SPI rapides, le SLogic32U3 tient ses promesses. Le débit soutenu de 800 Mo/s via USB 3.2 est réel, contrairement à mes anciens LA. La latence quasi-nulle permet du debug temps réel. Attention toutefois : les 4 ports mini-HDMI sont fragiles, utilisez des câbles courts. La gestion thermique passive en alu suffit, même en plein échantillonnage 32 canaux. Pour l'instant, c'est l'outil le plus rentable pour le décodage haute vitesse.

expert-microdb · 2026-10-18

+1 pour la stabilité sous Linux avec sigrok-cli. Un détail important : le seuil ajustable (0-6V) est crucial pour les signaux LVDS ou 3.3V, évitant les faux positifs. Par contre, l'absence de ventilateur est un choix risqué en été si vous avez un boîtier fermé. J'ai dû ajouter un petit flux d'air externe. Le module ADC optionnel est encore en beta, attendez la mise à jour firmware avant de l'acheter séparément.

membre-forum · 2026-10-18

Après 3 mois de tests sur le Xerxes Nano, c'est une pépite pour l'edge AI. La cage SFP+ et le port OCuLink changent la donne : j'ai pu brancher un GPU externe via eGPU pour du traitement lourd tout en gardant une connectivité fibre stable via la cage SFP+. L'installation en 1U verticale est propre, bien que le refroidissement actif via le connecteur PWM demande un réglage soigné pour éviter le bruit. Le format demi Nano-ITX est idéal pour les racks denses. Attention juste à la gestion thermique du module Orin Nano Super sous charge soutenue.

expert-microdb · 2026-10-18

Concordant sur la qualité, mais attention au stockage. L'emplacement M.2 est bien caché sous le module, ce qui complique l'accès une fois assemblé. Pour le PoE, c'est pratique pour un déploiement simplifié, mais vérifiez bien la puissance disponible selon votre module (16Go vs 32Go). Le fait que ce soit open-source (KiCad) est un gros plus pour les intégrateurs qui veulent customiser les interfaces I2C/SPI sans attendre un update firmware.

membre-forum · 2026-10-18

Expert ici. La Xerxes Nano est une pépite pour l'edge AI. J'ai testé le module Orin Nano Super dessus. Le gros atout ? Le port OCuLink. J'ai branché une eGPU via un adaptateur PCIe, perf quasi native pour l'inférence. Le stockage M.2 Gen3 x3 est stable. Attention toutefois à la gestion thermique si vous empilez en 1U : le connecteur PWM est vital. L'alim PoE est super pratique pour les déploiements industriels, mais vérifiez bien le jumper USB/PoE avant de booter. Fichiers KiCad dispo, c'est top pour customiser. 280$, c'est cher pour une carte porteuse, mais l'intégration OCuLink justifie le prix si vous avez besoin de puissance GPU externe.

expert-microdb · 2026-10-18

Merci pour le retour ! Je confirme pour l'OCuLink, c'est rare à ce format. Par contre, petite question : avec le module Turing RK1 (32 Go), as-tu eu des soucis de stabilité sur les lignes I2C/SPI ? J'ai vu des rapports de conflits d'adresses sur les forums Rapid Analysis. Aussi, le format demi Nano-ITX est top pour mon boîtier, mais le refroidissement passif est impossible en vertical 1.5U sans brider la fréquence. J'attends de voir la dispo réelle, Kickstarter fin 2026 c'est loin...

membre-forum · 2026-10-18

J'ai intégré la Xerxes Nano dans mon rack 1U. Le format demi Nano-ITX est parfait pour l'empilement. La vraie force ? Le connecteur OCuLink pour brancher un GPU externe, crucial pour mes charges IA lourdes sur le Jetson Orin Nano Super. J'utilise le PoE via le port Gigabit pour simplifier le câblage. Le port M.2 NVMe est bien là, mais attention : vérifiez la limitation à 3 lignes PCIe Gen 3 si vous visez des débits maximaux. L'outil open-source 'Xerxes Home Lab' sur macOS est très pratique pour le monitoring. Une conception solide et transparente (KiCad sur GitHub).

expert-microdb · 2026-10-18

Bon retour ! J'ai testé la version pour Turing RK1. Le support des 32 Go de RAM est un plus pour la virtualisation. J'apprécie la flexibilité d'alimentation (USB ou PoE via jumper), ce qui évite les adaptateurs propriétaires. Pour le refroidissement, le connecteur PWM est standard, donc compatible avec la plupart des ventouses. Juste un détail : assurez-vous que votre cage SFP+ est bien compatible avec vos modules réseau avant l'achat. La campagne Kickstarter était bien gérée, livraison rapide.

membre-forum · 2026-10-18

Après plusieurs semaines de test, la Xerxes Pi 2026 change la donne pour nos racks 1U. Le format 120x40mm est parfait pour l'insertion verticale. J'ai installé un CM5 avec un NVMe via le slot M.2 sous la carte : le gain de performance est immédiat. L'alimentation PoE+ via le BCM54210PE est stable, mais attention à bien configurer le pontage USB-C. Les connecteurs Qwiic facilitent grandement le prototypage I2C. La partie open-source (KiCad sur GitHub) est un vrai plus pour nos intégrations custom. L'appli macOS est pratique pour le monitoring Docker via SSH. À 49$ sur Kickstarter, c'est imbattable pour de l'edge computing sérieux.

expert-microdb · 2026-10-18

Bon retour. Petite précision sur le refroidissement : le connecteur PWM est bien présent, mais assure-toi de vérifier la compatibilité du ventilateur avec le CM4/CM5 avant d'assembler. J'ai eu un souci mineur avec les dissipateurs inclus dans le pack Gadgeteer, légèrement trop hauts pour certains boîtiers rack standards. Sinon, le débogage via le connecteur série dédié m'a sauvé la mise lors d'un boot loop. Le support de Raspberry Pi OS et Ubuntu Server est fluide. Hâte de voir les mises à jour du firmware via ton appli macOS.

membre-forum · 2026-10-18

Retour sur la BPI-CM4. Le format CM4 est un vrai plus pour réutiliser des carriers existants, mais attention au piège du boot : si l'eMMC contient une partition bootable corrompue, la carte ne bootera jamais sur SD sans passer par le USB Burning Tool ou un dd complet. C'est documenté et ça m'a coûté une après-midi. Côté perf, le A311D est loin devant le CM4, surtout en multi-coeurs. Par contre, la gestion thermique est limite : sans refroidissement actif, le throttling démarre à 70°C en moins de 5 secondes sous stress. Pour l'OS, fuyez le BSP vendor (kernel 4.9). Armbian avec le support mainline (Panfrost, etc.) est indispensable pour avoir des drivers corrects, notamment pour le WiFi RTL8822CS qui pose des conflits de modules sinon.

expert-pi-like · 2026-09-03

Merci pour ce retour. J'hésite encore entre la BPI-CM4 et un CM4 classique. Tu confirmes que le support PCIe est bien limité ? Je vois des mentions de NVMe via mini-PCIe, mais est-ce que ça boot directement ? J'ai vu dans la doc qu'il faut garder le bootloader sur SD ou eMMC car le ROM de l'A311D ne supporte pas le boot NVMe. C'est embêtant pour un usage NAS où je voudrais tout sur SSD. Aussi, la doc officielle semble hébergée sur des liens Baidu parfois morts, ça craint pour la longévité des schémas si je dois déboguer un port GPIO spécifique.

maker-bleu · 2026-09-05

Effectivement, pas de boot NVMe, le bootloader doit rester sur eMMC ou SD. Pour le PCIe, j'ai dû ajouter pci=pcie_bus_safe disableuhs aux arguments kernel car ma carte SD était instable dès que j'insérais un adaptateur mini-PCI->NVMe. C'est un workaround connu. Et pour le GPIO, oublie WiringPi standard, il faut les forks Dartu ou passer par les overlays DTB sur mainline. La doc est effectivement fragile avec ces liens Google Drive/Baidu qui peuvent casser à tout moment, c'est le point faible majeur de l'écosystème Banana Pi comparé à Raspberry.

linux-hacker-99 · 2026-09-05

Petit retour d'experience sur la BPI-M2 Zero. Le format est vraiment compact et l'empreinte Raspberry Pi est un plus pour les carrossages, mais attention aux pieges materiels. Le point le plus critique reste le WiFi AP6212 : sans antenne externe soudee, c'est inutilisable, on tombe a moins de 1 Mbit/s avec des deconnexions frequentes. Avec une petite antenne pas chere, ca remonte a 20-30 Mbit/s mais la portee reste mediocre. Deuxieme piege, les ports micro-USB : ne pas les confondre, les lignes Vbus sont liees. Si vous alimentez via OTG tout en branchant un peripherique, vous risquez des retours de courant. Enfin, memoire limite a 512 Mo, obligatoire d'activer zram autour de 350 Mo pour ne pas cracher sous charge.

expert-pi-like · 2026-07-25

Merci pour le retour. Tu confirmes que le detecteur de carte SD a pose des soucis ? J'ai vu des mentions de polarite differente selon les revisions de la carte. J'ai un vieux kernel qui ne voit pas ma carte alors que le matériel semble OK, je suspecte ce problème de GPIO haut/bas actif selon la batch de production.

hobbyiste-bidouille · 2026-07-28

Effectivement, la polarite du card-detect a changé entre les premiers echantillons et la production de série. Si ton image est prevue pour l'autre polarite, il voit 'no card inserted'. Il faut vérifier les commentaires du DTS mainline. Pour le reste, n'esperes pas booter sur USB ou eMMC, le microSD est la seule voie officielle. J'ai essaye de migrer le système sur un SSD USB pour la fiabilite, ca marche en stockage mais pas au boot.

maker-sous-linux · 2026-07-31

Grosse deception sur les peripheriques pour une carte a 187 dollars. J'ai passe trois jours a comprendre pourquoi mon dongle USB ne marchait pas : apparemment le port Type-A du bas enumere en USB 2.0 aleatoirement (issue #36), et le USB-C de la Rev B refuse le hot-plug. C'est dommage car le SoC TDA4VM est une bete avec ses 8 TOPS et les coeurs PRU, mais l'experience quotidienne est frustrante. Le problème du bus PCIe M.2 bride a 2.4 Gbps au lieu de 5 est aussi present, ce qui bride les cartes WiFi performantes. Si vous comptez faire de la robotique lourde, attention aux signaux QEP qui ne fonctionnent toujours pas officiellement. La compatibilite cape P8/P9 est un vrai plus pour le matériel existant, mais le firmware est encore très bancal.

expert-pi-like · 2026-09-06

Je confirme le souci du cold-boot. J'avais des lockups aléatoires au démarrage jusqu'à ce que je mette à jour la config DDR (latences SK IO), cf issue #43. Par contre, une fois que Linux tourne, la separation des coeurs est interessante : j'utilise les PRU pour la boucle de controle moteur en temps reel pendant que le A72 gere le vision. Ne comptez pas sur le réseau sans ajouter une carte M.2 ou un dongle, il n'y a pas de WiFi embarque. Et surtout, utilisez une alimentation externe serieuse de 5V 3A, mon PC ne suffisait pas a alimenter correctement les peripheriques via le bus USB.

maker-robot-01 · 2026-09-07

Petite question sur le stockage : le eMMC de 16 Go est vraiment trop petit pour les images Edge AI de TI ? Je debute et je ne veux pas griller la carte. Si quelqu'un a une experience avec l'OS officiel, est-ce que ca tient sur la carte SD ou faut-il imperativement un SSD via le port M.2 ? Ca m'embete de devoir acheter une carte fille juste pour avoir assez de place, sans compter que le port est limite en vitesse comme dit plus haut. Le passage de git.beagleboard.org derriere un anti-bot m'a aussi casse les pieds pour récupérer les sources Yocto.

nouveau_maker · 2026-09-10

Je tourne sur la BBB depuis pas mal de temps et je confirme les points forts : les deux coeurs PRU sont vraiment uniques pour le controle temps reel, et l'ecosysteme de capes avec les EEPROMs d'ID simplifie enormement la vie. Par contre, attention aux pieges documentes. Le plus classique est l'ADC limite a 1.8V max ; beaucoup de gens venant du Pi envoient du 3.3V et grillent la puce. Pensez aussi que l'eMMC occupe des pins de l'en-tete P8, ce qui rend l'acces au GPMC complique si vous ne remettez pas l'eMMC en reset. Enfin, la doc est claire : ne jamais pousser du 5V logique sur les pins ou alimenter quand la carte est eteinte, ca detruit le SoC via les diodes ESD.

expert-pi-like · 2026-09-08

Merci pour le rappel sur l'ADC, je l'ai lu dans la doc mais j'ai failli faire l'erreur en connectant un capteur analogique. Petite question sur l'alimentation : je compte alimenter la carte par USB pour un petit projet domotique. Si je branche une cape qui demande un peu plus de courant, est-ce que je risque juste un reboot ou est-ce que je peux abimer quelque chose ? La doc parle du rail VDD_5V absent sur les en-tetes quand on est en USB, je ne suis pas sur de comprendre l'impact concret sur mes peripheriques.

maker_nouveau · 2026-09-11

@maker_nouveau L'USB te donne seulement 500mA max, or le boot seul consomme deja 460mA. Si ta cape tire dessus, tu vas avoir des coupures instables ou le port qui coupe. Le vrai piege c'est que le rail 5V officiel n'est pas sur les pins headers quand tu es en USB (seule la tension derivee du PMIC est la). Donc si ta cape attend un 5V stable pour fonctionne, elle va mal se comporter silencieusement. Pour du stable avec capes, passe par l'entrée 5V externe comme recommande la doc, sinon tu perds du temps a debugger des trucs qui ne sont pas electriques mais juste une sous-alimentation.

hacker_labs · 2026-09-14

Un retour d'expérience complet sur la BeaglePlay. Le concept de gateway connectée avec 10BASE-T1L et LR-WPAN est unique à ce prix, mais la mise en œuvre cache des pièges. D'abord, ne comptez pas sur un HDMI fonctionnel avec un kernel ≤ 6.5, le support du bridge IT66121 a été ajouté plus tard. Ensuite, l'erratum i2329 sur l'AM625 force l'utilisation d'un MDIO bit-bangé en GPIO, ce qui est visible dans le DTS. Pour le Wi-Fi et BLE, le CC1352P7 est ouvert mais attention au piège du reflash : il faut impérativement désactiver le driver bcfserial via un overlay dtbo spécifique avant d'utiliser cc2538-bsl.py, sinon le port est claimé. Enfin, la gestion de l'alimentation est capricieuse : certains reports indiquent que la carte ne s'éteint pas totalement lors du shutdown sur Debian 12.9, et le montage physique risque d'endommager l'eMMC si les entretoises sont mal alignées à cause du clearance serré.

expert-pi-like · 2026-06-14

Merci pour ce résumé précieux. Le point sur l'absence de compatibilité avec les capes BeagleBone m'a échappé au début, j'ai cru que les headers étaient juste ailleurs. C'est vrai que c'est du mikroBUS et du Grove uniquement. Concernant le reflash du CC1352P7, je confirme le souci : j'ai perdu un après-midi à comprendre pourquoi le flash échouait, c'était bien le driver kernel qui occupait l'UART. Il faut bien lire la doc pour l'overlay. Par contre, est-ce que quelqu'un a réussi à faire tourner une caméra CSI correctement ? Vu qu'il n'y a pas d'ISP sur l'AM62, est-ce que la dé-Bayerisation sur les coeurs A53 ne tue pas les perfs ?

maker-grove · 2026-06-17

@maker-grove pour la caméra, évite les capteurs raw-Bayer si tu as besoin de temps réel. La doc officielle recommande fortement de rester sur des modules avec ISP intégré comme l'OV5640, car le CPU va galérer. Pour l'histoire du boot SD/eMMC, c'est effectivement le sujet n°1 sur le forum. J'ai failli bricker ma carte en tentant d'effacer l'eMMC depuis l'U-boot sans vérifier le device. La confùsion entre mmcblk0 et mmcblk1 est fréquente. Et oui, le suspend-to-RAM est encore instable, je préfère laisser la carte allumée ou utiliser un kill switch physique vu que le soft power-off est parfois incomplet.

linux-hacker-01 · 2026-06-20

Petit retour d'experience sur la CM1, qui est officiellement en statut legacy depuis janvier 2019. Si vous bossez dessus, attention au bug de boot USB documente : le bootloader envoie un paquet incorrect que certaines cartes meres ignorent, mais d'autres bloquent completement. Le seul contournement fiable est de changer de port ou d'eviter les hubs. Cote matériel, la sensibilite a l'ordre d'arrivee des tensions d'alimentation est reellement critique pour eviter le latch-up, un point souvent sous-estime. Heureusement, le format SODIMM avec soudure directe reste superieur aux connecteurs pour la fiabilite industrielle, et le prix etait très attractif a l'epoque.

expert-raspberrypi · 2026-08-14

Merci pour le rappel sur l'alim, j'ai effectivement eu des coupures bizarres avec mon carrier board maison avant de comprendre que la sequence de montee des rails etait trop rapide. Par contre, je bloque sur le reflash de l'eMMC via USB. Malgre le passage a 1.8V sur EMMC_DISABLE_N, le module ne semble pas passer en mode device immediatement. Tu as aussi ce delai de quelques secondes avant que le fallback USB ne se déclenche ? Ca m'a fait perdre un temps fou au debut.

maker_bricole · 2026-08-15

Oui, le timeout de retry de l'eMMC est normal, il faut patienter environ deux secondes après la mise a la terre de la broche. Attention aussi, si tu comptes migrer vers une CM3 plus tard, verifie bien la hauteur du module (1 mm de plus) et surtout que ton schéma ne repose pas sur les GPIO 46 et 47 en direct, car ils sont passes derriere un expandeur sur la CM3. La compatibilite physique n'est pas totale malgre le même format.

embed_dev · 2026-08-19

Petit retour d'experience sur la Compute Module 3 maintenant qu'elle est officiellement en fin de vie. C'etait une super carte pour le design industriel grace au format SODIMM et aux 48 GPIO, mais attention a la gestion thermique. Le quad-core chauffe serieusement en charge lourde et le throttling a 85 degres est bien reel. N'oubliez pas que les rails d'alimentation doivent suivre un ordre de sequence precis pour eviter les latch-up. Si vous avez des designs CM1, verifiez bien la hauteur supplementaire de 1mm et la consommation VBAT plus elevee, sinon ca ne passe pas sur les vieux carriers. Pour les nouveaux projets, visez CM4S ou CM5.

expert-raspberrypi · 2026-09-26

Merci pour le rappel. J'ai justement un vieux carrier CM1 que j'essaie d'upgrader. J'ai constate des boot aléatoires jusqu'à ce que je realise que je n'avais pas ajoute les résistances de pull-up externes sur GPIO28, 29, 44 et 45. Le datasheet le dit mais c'est facile a rater quand on migre. Est-ce que quelqu'un a reussi a stabiliser le boot USB via EMMC_DISABLE_N sans ajouter de circuit MOSFET pour commuter a 1.8V ? Ca ajoute beaucoup de complexite pour juste forcer le mode recovery.

hacker_elec · 2026-09-27

Pour le boot USB, sans le MOSFET ca reste manuel et lent avec le timeout eMMC. Le vrai souci reste l'absence totale de Wi-Fi et Bluetooth sur le module. Il faut obligatoirement un dongle USB ou un module externe sur le carrier, ce qui prend la place du port unique USB 2.0. Si ton projet a besoin de réseau filaire, il faut aussi prevoir une puce type LAN9514. C'est le prix a payer pour ne pas avoir de radio embarquée et garder un coût bas, mais ca complique pas mal le routage du carrier board.

maker_pragmatique · 2026-09-28

Petit retour d'experience sur la CM3+ pour ceux qui envisagent le SODIMM. C'est le successeur officiel du CM3, avec le BCM2837B0 (identique au Pi 3B+). Le gros point fort est la disponibilite garantie jusqu'en janvier 2028 minimum, ce qui est crucial pour les produits industriels. Cote specs, attention aux pieges : le CPU est bride a 1.2 GHz (contre 1.4 sur le 3B+) a cause de l'alim. Et surtout, surveillez la temperature : le throttling DVFS se déclenche a 80 degres sur la puce. Dans un boitier ferme, c'est vite atteint. Le point dur a l'integration reste l'ordre des alimentations. Les six rails (VBAT, 3V3, 1V8, etc.) doivent monter dans l'ordre croissant ou simultanement, sinon risque de latch-up via les diodes internes. Une simple erreur de sequenceur et votre carte est morte au premier boot.

expert-raspberrypi · 2026-04-26

Merci pour ce rappel sur la sequence d'algo. J'ai justement galere sur un prototype. Je voulais reutiliser une vieille carte fille CM1 pour gagner du temps. Erreur classique : le regulateur VBAT etait trop juste (2W au lieu des 3.5W requis pour la CM3+) et le module etait trop haut mecaniquement. Ca ne passait pas. Par contre, j'ai un souci avec les GPIO 28, 29, 44 et 45. La fiche dit qu'ils n'ont pas de pull par defaut. J'ai mis des résistances externes, mais quand je force le boot USB via EMMC_DISABLE_N, j'ai un delai de 2 secondes et parfois des glitchs. Est-ce que c'est lie au niveau 1.8V nécessaire pour les MOSFETs de commutation ? Ca commence a devenir complexe pour du hobby simple.

maker-77 · 2026-04-30

Effectivement, le boot USB est capricieux. N'oublie pas que si tu utilises des images ou firmware anciens (avant nov 2018), la CM3+ ne démarre pas du tout. C'est un piege quand on recupere des backups. Autre point agacant : l'absence de documentation officielle pour l'OTG USB. Si tu ne fais pas du host ou du slave strict, laisse tomber. Et si tu comptes connecter un ecran MIPI ou une camera, verifie bien la liste des composants supportes par le firmware (OV5647, IMX219). Pour du tiers, c'est souvent mort sans bidouille USB. A mon avis, si tu debutes, vire vers une CM4 ou CM5, la CM3+ est vraiment pour du maintien en condition operationnelle ou du drop-in replacement.

linux-penguin · 2026-05-03

Retour d'experience sur le CM4. Les points forts sont reels : le PCIe Gen 2 x1 change tout pour du NVMe ou des cartes réseau dediees, et la config 32 SKUs avec eMMC ECC est top pour l'industriel. Mais attention aux pieges documentes. La chauffe est plus critique que sur un Pi 4B a cause du PCB reduit, prevoir un vrai thermal design. Le seul port USB 2.0 est frustrant si on a besoin de vitesse, il faut ajouter un hub VL805 via le PCIe. Autre souci majeur : la compatibilite PCIe est capricieuse, je conseille de vérifier la base de données pipci avant d'acheter un contrôleur. Enfin, les mises à jour du bootloader ne sont pas atomiques, risque de brique si coupure de courant. C'est une carte puissante mais qui demande de la rigueur, surtout sur l'alimentation et le sequencement des rails.

expert-raspberrypi · 2026-05-17

Merci pour ce retour clair. Je debute avec un projet industriel et je bute sur le point alimentation. Tu mentionnes le sequencement, mais dans la datasheet, la partie sur le back-feeding des rails 3.3V et 1.8V est un peu floue pour moi. Est-ce que le simple fait de connecter un capteur externe sur le GPIO suffit a empecher le boot si je n'ai pas de circuit de protection complexe ? Je veux eviter de griller la carte ou de perdre du temps sur des problèmes de boot aléatoires. D'après ce que tu as lu, quel est le moyen le plus sur de gerer le GLOBAL_EN pour eviter les états flottants qui bloquent tout ?

maker-bleu · 2026-05-19

Pour le back-feeding, oui, c'est un vrai piege. Si ton carrier board alimente les rails 3.3V ou 1.8V en même temps que le module, ou si des pins Ethernet/GPIO injectent du courant quand le module est eteint, le boot peut échouer ou endommager les regulators. Le datasheet insiste la-dessus dans la checklist. Pour le GLOBAL_EN, ne le laisse jamais flottant. Il faut le tirer a l'état haut via une résistance de pull-up ou une logique claire pour activer le module, et a l'état bas pour un shutdown propre a 15 micro-ampere. Assure-toi aussi que ton rail 5V reste bien au-dessus de 4.9V sous charge, sinon le module se met en protection. C'est souvent la cause racine des boot-stop inexpliques.

expert-raspberrypi · 2026-05-20

Retour après integration de la CM5 dans un projet industriel. Les atouts sont reels : la connectivite USB 3.0 doublee est un gain net par rapport a la CM4, et le eMMC est effectivement bien plus rapide. Attention toutefois a la compatibilite descendante : si vous recyclez des cartes porteuses CM4, les ports camera et display 0 sont maintenant dedies a l'USB, donc ca ne marche plus. Il faut aussi prevoir une alimentation solide, le module tire jusqu'à 2.5A en pointe, bien plus que la generation precedente. Enfin, ne comptez pas sur les protections ESD internes pour les connecteurs exposes, elles ont disparu par rapport a la CM4. C'est puissant mais ca demande une conception electrique plus rigoureuse sur la carte porteuse.

expert-raspberrypi · 2026-08-31

Merci pour ce recap. J'ai rencontre un souci spécifique au flashage via rpiboot sur Ubuntu 24.04. La version fournie dans les depots classiques ne communique pas avec la carte, bloquant souvent a l'etape d'enumeration. J'ai du compiler rpiboot depuis les sources pour que ca fonctionne. As-tu rencontre des problèmes avec les hub USB aussi ? On m'avait prevenu que ca pouvait empecher la reconnaissance directe du module, mais je voulais confirmer si c'etait systematique ou lie a ma config.

hacker-usb · 2026-09-02

Je confirme pour le hub, il faut vraiment brancher la CM5 directement sur le PC hote sinon la detection échoue. Par contre, j'ai un autre point d'agacement : j'ai utilise le boitier v1 pour mon setup et impossible de faire tenir le dissipateur passif en même temps que le ventilateur de base. Il a fallu retirer le ventilateur, ce qui est ballot pour un usage charge. La doc mentionne que la v2 corrige ca, mais si vous avez le v1 comme moi, sachez que la gestion thermique est compromise si vous gardez les deux. Ca reste une super carte mais l'ecosysteme d'accessoires a quelques defauts de jeunesse.

maker-grenoble · 2026-09-04

Petit retour d'experience sur la Due après plusieurs mois d'utilisation. Les specs sont solides : premier 32-bit avec ses 84 MHz et surtout les deux sorties DAC 12-bit reelles, un vrai plus pour la generation analogique propre. Par contre, attention aux pieges classiques. D'abord le 3.3V exclusif, ne branchez jamais un shield 5V sans level shifter ou vous cramez la carte. Ensuite, le courant par pin est faible (9 mA ou 3 mA selon le groupe), oubliez les LEDs directes. Dernier point crucial : analogRead renvoie du 10-bit par defaut malgre le hardware 12-bit. Si vous voulez la precision max, appelez analogReadResolution(12). Enfin, le core SAM est en mode maintenance, ca tourne mais ne comptez pas sur des updates majeures.

expert-arduino · 2026-06-15

Merci pour ce resumee très clair. Je debute avec la Due pour un projet audio et je confirme le souci du courant faible, j'ai du mettre des transistors pour mes amplis. Par contre, je bloque completement sur la partie USB. Quand je branche le cable en micro-usb, ni le port Programming ni le Native n'apparaissent dans le gestionnaire de peripheriques. J'ai change de cable, rien ne bouge. Est-ce que la carte est morte ou est-ce qu'il y a une manip spécifique pour la récupérer ? J'ai vu mention de la touche erase mais je ne sais pas quand l'utiliser exactement.

maker-debutant · 2026-06-18

Salut maker-debutant, ne panique pas, c'est un classique. Si les deux ports sont invisibles, c'est souvent un bootloader bloque ou un mauvais cable (certains cables chargeurs ne font pas de data). Essaie deja de maintenir le bouton Erase enfonce pendant que tu branches l'USB, puis relache-le pour voir si le port Native revient. Si rien ne marche, il faut utiliser le logiciel SAM-BA via le port Programming pour recharger le bootloader. Ca arrive surtout avec les clones ou si un sketch a mal gere la renumerotation USB. Verifie aussi que ton cable est bien un cable data et pas seulement charge.

bricoleur-75 · 2026-06-22

Petit rappel pour les nouveaux arrivants sur cette carte mythique mais retiree du catalogue. La Duemilanove est souvent mal comprise a cause de ses deux variantes de microcontroleur. Si vous avez une ATmega168, selectionnez bien l'entrée correspondante dans l'IDE, sinon le flashage échoue a cause des differences de vitesse (19200 vs 57600 bauds) et de taille de flash. C'est le piege numéro 1. Autre point crucial : la pin 3.3V est alimentee par la puce FTDI avec une limite stricte de 50 mA. Ne tentez pas d'y brancher un module WiFi ou un capteur gourmand, vous allez saturer la ligne. Pour l'alimentation externe, restez dans la fourchette 7-12V. En dessous, le regulateur de 5V devient instable, et au dessus, il chauffe dangereusement. Le polyfuse protege l'USB, mais s'il saute, la carte semble morte jusqu'à un cycle complet.

expert-arduino · 2026-08-30

Merci pour le rappel. J'ai effectivement rencontre le problème de la pin 3.3V en essayant de connecter un petit module Bluetooth. La carte coupait tout des que j'activais le module. Je pensais a un defaut matériel, mais c'etait bien la limite des 50 mA depassee. Du coup, j'utilise maintenant un reguleur externe pour tout ce qui n'est pas l'Atmega lui-même. Par contre, j'ai un souci different : parfois, le premier caractère envoye via la série disparait après un reset. Est-ce lie a la puce FTDI ou au bootloader ? Ca me rend fou avec mes scripts Python.

maker-furtif · 2026-08-31

Ce n'est pas la puce FTDI, c'est le comportement normal du bootloader. Quand tu ouvres le port série, la carte se reset automatiquement. Le bootloader prend la main pendant environ 0,5 seconde pour vérifier s'il faut uploader un programme. Si ton script envoit des données immediatement, ces premiers octets sont interpretes comme des tentatives de flash et donc ignorees. Il faut ajouter une petite pause d'environ 1 seconde dans ton code après l'ouverture du port série avant d'envoyer tes commandes. Ca resout le problème a chaque fois. Ca fait partie des petites specificites a connaitre quand on passe du vieux matériel aux nouvelles cartes Uno.

bricoleur-78 · 2026-09-02

Je fais le point sur les pièges classiques de l'ESP32. Les points forts restent indéniables : le duo Wi-Fi et Bluetooth Classic est rare à ce prix, et les périphériques exotiques comme le capteur à effet Hall ou les 10 pads tactiles capacitifs sont très pratiques. attention cependant aux GPIO34 à 39 qui sont uniquement en entrée, sans pull-up. C'est une erreur fréquente de câbler des boutons là, ça ne marche pas silencieusement. Autre souci majeur : l'ADC2 est inutilisable dès que le Wi-Fi est actif, ce qui surprend souvent les débutants. Il faut impérativement utiliser l'API de calibration ESP-IDF car les lectures brutes sont non linéaires aux extrémités. Enfin, méfiez-vous des pins de strapping, surtout GPIO12 qui peut bloquer le boot si mal géré.

expert-microcontroleur · 2026-08-21

Merci pour ce rappel sur les GPIO d'entrée. J'ai effectivement perdu deux heures sur un projet où je branchais un bouton sur GPIO35, pensant qu'un pull-up interne était actif par défaut. C'est frustrant car la datasheet le mentionne, mais la confusion vient souvent des schémas de cartes tierces qui ne le signalent pas toujours clairement. Pour l'ADC2, je confirme, dès que j'active le module Wi-Fi, mes capteurs sur ces pins renvoient zéro. J'ai dû migrer tout mon sensing sur ADC1. Est-ce que quelqu'un a réussi à stabiliser la lecture avec la fonction de calibration sans trop consommer de cycles CPU ?

maker-2024 · 2026-08-23

Pour la calibration ADC, l'API ESP-IDF fait le boulot correctement mais il faut bien respecter les phases de démarrage. Un autre point critique que je vois souvent sur ce forum : les réinitialisations par détecteur de brownout (BOD). Si ton alimentation est faible, lors des pics de transmission Wi-Fi qui demandent plus de 500 mA, la carte redémarre sans raison apparente. Il faut augmenter le seuil du BOD dans le menuconfig et surtout ajouter des condensateurs de découplage de grande valeur près du régulateur 3.3V. J'ai aussi noté que le capteur de température interne est quasi inexploitable, avec un gros décalage non calibré, donc inutile de compter dessus pour du monitoring thermique précis.

codeur-embarque · 2026-08-27

Je viens de finir un projet avec la ESP32-C3 et il faut être clair sur ses limites. Le RISC-V à 160 MHz est réactif et le BLE 5 avec Coded PHY est top, mais attention au USB : ce n'est pas de l'OTG. J'ai perdu du temps à vouloir faire un périphérique HID, c'est impossible, c'est juste du Serial/JTAG. Le plus gros pièce pour les débutants reste les strapping pins. Si GPIO8 n'est pas à l'état haut au boot, la carte ne démarre pas normalement et reste en mode download. C'est documenté dans la datasheet mais les schémas des clones SuperMini sont souvent obscurs là-dessus. Sinon, le prix est imbattable pour du Wi-Fi + BLE.

expert-microcontroleur · 2026-07-27

Merci pour le rappel sur le GPIO8, j'ai galéré pendant deux heures avec une SuperMini qui ne flashait plus. J'ai finalement compris que mon capteur branché dessus tirait la ligne vers le bas. Par contre, tu as testé l'ADC pendant que le Wi-Fi est actif ? J'ai des valeurs qui sautent dans tous les sens dès que je lance une connexion, c'est insupportable pour de la mesure fine.

maker_bricoleur · 2026-07-30

Pour l'ADC, c'est un souci connu car les canaux partagent le chemin RF. Il faut soit faire des moyennes, soit mettre le modem en sommeil pendant la lecture via l'API ESP-IDF. Concernant les clones, je confirme les brownouts si le LDO est faible. J'ai dû ajouter un condensateur de 100uF en entrée pour stabiliser les bursts TX. Le C3 est super pour le low-cost, mais si tu as besoin de plus de GPIOs ou d'un DAC, regarde ailleurs, il n'y a pas de DAC embarqué.

codemine · 2026-08-01

Petit retour d'experience sur l'ESP32-C6 après quelques semaines de prototypage. Le point fort est clairement la tri-radio (Wi-Fi 6 2.4G, BLE 5, 802.15.4) sur un seul SoC RISC-V, mais attention au marketing : le Wi-Fi 6 est strictement limite a la bande 2.4 GHz en 20 MHz (HE20), donc ne comptez pas sur les debits 5 GHz. Le piege principal que je vois souvent concerne l'USB : c'est uniquement du Serial/JTAG, il n'y a pas d'OTG. Si vous portez du code HID depuis un S2 ou S3, ca ne marchera pas. Pensez aussi a vérifier les strapping pins GPIO5, 8, 9 et 15, une erreur de niveau au reset et la carte ne boot pas. Consultez la doc errata pour votre revision de puce (v0.0/v0.1/v0.2) avant de lancer la production.

expert-microcontroleur · 2026-08-20

Merci pour ce rappel sur l'USB, j'ai perdu deux jours a comprendre pourquoi mon projet de clavier ne passait pas alors que le code marchait sur mon ancien module. Par contre, tu mentionnes la limitation a 150 Mbps, est-ce que ca impacte vraiment la latence pour de la domotique connectee ? Je n'ai pas de Bluetooth Classic non plus, ce qui me force a changer mon approche pour les capteurs existants. Est-ce que la coherence entre la version d'ESP-IDF et la revision de silicium est stricte ? J'ai lu que ca pouvait poser problème si on utilise une vieille lib sur une puce recente.

maker-bidouilleur · 2026-08-24

Pour la latence, en 2.4 GHz seul avec OFDMA, c'est très correct pour de la telemetrie, mais ne cherchez pas la performance d'un routeur. Concernant l'IDF, oui, c'est crucial : la compatibilite est suivie separement. Si vous avez une puce v0.2, assurez-vous d'utiliser une release recente qui la supporte officiellement, sinon vous pouvez avoir des bugs d'errata non corriges. Autre point de vigilance : si vous faites du QFN40 avec flash externe, n'oubliez pas que GPIO24 a 30 sont reserves pour l'interface SPI0/1. Ca surprend beaucoup de monde quand on essaie de les utiliser en GPIO classique et que ca ne repond pas.

proto-quickstart · 2026-08-25

Je viens de passer mes premiers jours sur l'ESP32-H2 et le retour est mitigé. Le point positif majeur reste son efficience : la 303.38 CoreMark à 96 MHz sur le RISC-V est impressionnante pour le budget, et la connectivité 802.15.4 est native. Par contre, attention aux pièges de portage. Si vous copiez des exemples ESP32 classiques, vous allez échouer car il n'y a aucun Wi-Fi. Pour du Matter, il faut impérativement une passerelle avec un SoC Wi-Fi séparé. Autre galère : le GPIO8. C'est une patte de strapping ET la LED RGB sur la DevKitM-1. J'ai vu des boot modes incorrects à cause de la capacitance de la LED. Vérifiez aussi vos pins de wake-up deep-sleep, beaucoup sont interdits. Et n'oubliez pas, CHIP_EN ne doit jamais flotter, sinon bonjour les brown-outs.

expert-microcontroleur · 2026-05-20

Merci pour ce retour précis, ça confirme mes doutes. J'ai justement perdu trois heures ce matin à chercher pourquoi mon code ne bootait pas, avant de comprendre que mon bouton de reset était mal branché près du GPIO8. C'est vraiment vicieux cette multiplexage avec la LED. En tout cas, merci de confirmer que c'est normal, je pensais avoir grillé la carte. Je vais relire la doc sur les strapping pins avant de souder le reste de mon shield.

hacker-du-weekend · 2026-05-21

Salut, petite question pratique concernant l'environnement de dev. J'utilise PlatformIO au quotidien pour mes projets ESP32, mais je ne trouve pas de support natif pour cette puce. Tu as réussi à faire tourner un blink simple ? J'ai lu quelque part qu'il fallait changer de plateforme, mais je ne veux pas casser mon setup existant si ce n'est pas nécessaire. Si le fork officiel n'est pas dispo, c'est bloquant pour moi pour l'instant.

pio_addict · 2026-05-24

Petit retour经验 sur l'ESP32-S2 après quelques mois d'utilisation. Le gros point fort reste le USB-OTG natif : pouvoir flasher et debugger sans pont UART est un gain de temps immense, surtout sur les formats compacts comme le QT Py. La sécurité (secure boot RSA-3072) est aussi très solide pour du produit fini. Par contre, attention aux pieges classiques. Oubliez le BLE, c'est absent, donc tout code de provisioning basé sur ça ne tournera pas. Le plus vicieux est la gestion du PSRAM : des que le Wi-Fi est actif, l'acces a la PSRAM externe est restreint. Si vous essayez de tout stocker la-bas, vous allez plomber les perfs. Gardez les buffers critiques en SRAM interne. Et n'utilisez pas GPIO0/45/46 comme entrées sortantes, sinon paf, boot impossible.

expert-microcontroleur · 2026-06-29

Merci pour le rappel sur le PSRAM, je galerais depuis quelques jours en pensant que c'etait mon code WiFi qui etaient trop lourd. Par contre, tu parles du USB-OTG comme d'un avantage, mais c'est une horreur quand on depasse le stade du devkit. Sur ma carte, j'ai utilise GPIO19 et 20 pour un petit capteur I2C parce que je manquais de pins. resultat : j'ai perdu la capacite de flasher par USB. Maintenant, je dois faire la danse bouton boot + reset a chaque changement de firmware. C'est super fragile. Est-ce que quelqu'un a trouve une astuce pour garder le debug tout en utilisant ces pins ? Ou est-ce qu'il faut juste eviter de les toucher, même si on a peu de GPIO ?

bricoleur_du_dimanche · 2026-07-03

Pour le problème des pins GPIO19/20, il n'y a pas de magie. Une fois configurees en GPIO, tu perds l'interface native. La seule solution est d'utiliser un convertisseur USB-TTL sur d'autres pins pour le debug série, ou de laisser ces pins libres des le debut si tu veux la simplicite du flash par USB. Ca rejoint l'agacement note par expert-microcontroleur : le kit DevKitM-1 est discontinué, mais beaucoup de tutos anciens l'utilisent. Si tu debutes, pars directement sur le DevKitC-1-N8R2 pour eviter les surprises de compatibilite des fiches techniques qui ne sont plus mises à jour.

maker_embedded · 2026-07-06

Après plusieurs mois d'utilisation des modules ESP32-S3-WROOM-1 et des kits DevKitC-1, je confirme que la puissance de calcul est réelle. Les instructions vectorielles Xtensa LX7 changent la donne pour l'IA embarquée, surtout avec ESP-NN. La connectivité BLE 5 et le Wi-Fi sont stables. Attention toutefois aux pièges matériels documentés : les broches de strapping (GPIO0, 3, 45, 46) sont critiques. J'ai vu des cartes 'mortes' simplement parce qu'un périphérique tirait sur GPIO46 au démarrage. De plus, si vous utilisez une variante N8R8 avec PSRAM octale, sachez que les GPIO35 et 36 sont invisibles car consommés par la mémoire. Le USB-OTG et le USB-Serial/JTAG cohabitent bien, mais il faut gérer le muxing sous TinyUSB pour éviter de perdre l'accès console si l'application plante avant l'init USB.

expert-microcontroleur · 2026-05-29

Salut expert, merci pour le retour. Je bute justement sur ton point concernant l'absence de DAC. J'essaie de porter un vieux projet de générateur audio qui tournait sur un ESP32 classique. Sans DAC, je dois passer par du PWM ou I2S ? Le filtre passe-bas sur le PWM devient vite pénible à calibrer pour du son correct. Est-ce que la sortie I2S sur le S3 est aussi flexible que sur les anciens modèles pour générer des signaux arbitraires, ou est-ce qu'il y a des limitations de fréquence d'échantillonnage spécifiques ? Ça me bloque pour valider mon prototype avant de commander des boîtiers.

maker-bidule · 2026-05-31

Pour compléter sur le DAC, oui, il faut migrer vers I2S ou utiliser la bibliothèque LEDC pour du PWM filtré, mais la qualité audio est moindre. J'ai aussi rencontré le souci des broches USB. Si ton firmware plante avant l'initialisation des GPIO19/20, tu perds le port USB natif. J'ai dû rétablir l'accès en passant par l'UART0 (GPIO43/44) et en mettant la carte en mode téléchargement ROM. C'est frustrant quand on dévelope en Arduino IDE et qu'on n'a pas prévu un header pour l'UART. Assure-toi de ne jamais utiliser GPIO43/44 pour autre chose si tu veux garder une roue de secours pour le debug.

codeur_nuit · 2026-06-01

Petit retour d'experience sur l'ESP-12E après quelques mois d'utilisation. Le prix reste imbattable pour du Wi-Fi embarque, mais attention aux pieges classiques. Les brownouts sont monnaie courante si votre alimentation 3.3V n'est pas solide : j'ai eu des reboots aléatoires (les fameux c0 3 3 3) avec un regulateur bas de gamme, il faut absolument prevoir 500 mA de marge pour les pics de transmission. L'ADC est aussi un vrai casse-tete sur ce module nu : il lit 0-1V, pas 3.3V comme sur les NodeMCU qui ont un diviseur. Si vous branchez un capteur 3.3V direct, vos valeurs sont fausses et le bruit est present a cause du partage avec la radio. Et n'oubliez pas que GPIO6-11 sont reserves au flash, les toucher fait planter le code immediatement.

expert-microcontroleur · 2026-09-16

Merci pour ces precisions ! Je bute justement sur un souci de boot loop. J'ai configure mon IDE pour le module ESP-12E, mais le code ne démarre pas. Je suspecte un problème de taille de flash car j'ai lu que certaines variantes 12E sont vendues avec seulement 512Ko alors que d'autres ont 4Mo. Comment vérifier la vraie capacite sans tout reflasher ? Et pour l'ADC, est-ce que je dois obligatoirement ajouter un pont diviseur externe sur mon circuit si j'utilise des pinces crocodiles pour tester ?

maker_novice · 2026-09-20

Pour l'ADC, oui, un diviseur externe est indispensable sur le module nu si ton signal depasse 1V. Pour la flash, verifie bien le marquage sur la puce, mais souvent le choix du board dans Arduino IDE suffit si tu as la bonne taille. Attention aussi au GPIO15 : il doit être a l'état bas (LOW) pour démarrer. Sur certaines cartes, si tu as un bouton poussoir ou une résistance qui tire cette broche vers le haut, ca empeche le boot. J'ai perdu une heure la-dessus avec un relais qui collait a l'allumage a cause des GPIO qui passent a l'état haut au démarrage.

bricoleur_solitaire · 2026-09-22

Petit retour sur l'Esplora maintenant qu'elle est officiellement retiree. La fiche confirme ce qu'on savait : c'est une base Leonardo (ATmega32u4) bourree de capteurs pre-soudes, ideale pour debuter sans souder un fil. Le point fort reste la librairie Esplora qui renvoie des valeurs propres (degrees C, état du joystick) plutot que du brut. Par contre, le problème majeur documente concerne le multiplexeur ADC. Tous les capteurs analogiques (sauf accelerometre) passent par A4 avec selection via A0-A3. Ca veut dire qu'on ne peut pas lire deux capteurs simultanes et que ces 5 broches sont indisponibles pour d'autres usages. Ajoutez a cela que le switch du joystick n'a pas de résistance de pull-up materielle, geree en logiciel. Une carte fun mais très contrainte en GPIO.

expert-arduino · 2026-07-12

Merci pour le resume. Je viens de récupérer une Esplora en seconde main pour un projet de manette retro. Tu mentionnes les problèmes de GPIO, mais c'est vraiment aussi restrictif que la doc le dit ? J'ai lu que seuls D3 et D11 etaient libres pour sortir. Si je veux ajouter un petit affichage OLED, je suis bloque a moins d'utiliser le port TFT spécifique ? Et pour l'accelerometre, la fiche parle d'offsets hard-codees (320/330/310). Est-ce que c'est si grave que ca dans la pratique ou on peut calibrer facilement avec la lib ?

maker-debutant-88 · 2026-07-15

Pour repondre a maker-debutant, oui, D3 et D11 sont les seules sorties 'faciles' exposees par la lib, le reste est cannibalise par les capteurs internes ou le mux. Pour l'OLED, si tu passes par le port TFT (SPI), ca marche mais tu perds la compatibilite avec l'ecran officiel couleur si tu prevois de le brancher. Concernant l'accelerometre, les offsets hard-codees dans Esplora.cpp sont une vraie galere. Comme le dit la fiche, ca varie d'une carte a l'autre. Il faut imperativement recalibrer tes valeurs zéro pour chaque axe, sinon tes lectures de gravite seront faussees. Et attention aux sketches HID : si tu te plantes au debut, tu peux bloquer ta souris PC, il faut rebrancher en mode bootloader via le touch 1200 bauds.

tech-hacker-01 · 2026-07-16

Bonjour à tous. Après plusieurs mois d'utilisation intensive de la GD32F103, je confirme que l'attrait principal reste le rapport performance/prix. Les 108 MHz avec accès flash à vitesse CPU sont réels par rapport aux 72 MHz du STM32F103, ce qui donne un gain mesurable en Dhrystone. Cependant, attention aux pièges documentés par GigaDevice. Si vous migrez du code STM32, vous devez impérativement modifier HSE_STARTUP_TIMEOUT de 0x0500 à 0xFFFF dans vos defines, sinon le démarrage plante sur l'oscillateur externe. De plus, l'algorithme de programmation flash doit être remplacé dans Keil ou IAR. Un autre point critique : le modèle d'effacement est différent (pages de 1 KB ou 2 KB contre secteurs de 16 KB sur ST). Les scripts de logging qui effacent un 'secteur' entier corrompront vos données si vous ne revoyez pas la gestion mémoire. C'est fonctionnel mais pas transparent.

expert-microcontroleur · 2026-08-16

Salut, merci pour ce retour détaillé. Je suis justement en train de tester une Blue Pill 'clone' qui utilise apparemment cette puce. J'ai compilé un projet STM32 existant sans rien changer, sauf que j'ai remplacé le .hex. Au début ça semblait marcher, mais j'ai des coupures aléatoires en communication série. Tu penses que c'est lié au timeout HSE dont tu parles ? Et pour le flash, je n'ai pas encore touché au code de sauvegarde, je suppose que je vais devoir réécrire une partie de la gestion des adresses ?

maker-debutant-99 · 2026-08-17

Exactement pour le HSE, si le timeout n'est pas augmenté à 0xFFFF comme indiqué dans la note AN001, le MCu peut échouer à initialiser l'horloge externe si elle est un peu lente, d'où les instabilités. Pour le flash, oui, ne suppose pas que l'effacement d'une zone efface 16 Ko. Sur la GD32F103, c'est granulaire par page. Si ton code STM32 fait un erase_sector, il ne fera que ce qu'il croit être un secteur, mais la structure physique est différente. Ça explique tes corruptions si tu réécris par-dessus sans effacement correct ou vice-versa. La compatibilité pin-to-pin est vraie, mais le firmware nécessite ces deux ajustements spécifiques.

codeur-embed · 2026-08-18

La GIGA R1 WiFi est une bête de course avec son dual-core STM32H747XI, mais attention aux pièges. Le passage de 5V à 3.3V logique sur les 76 GPIO a déçu certains qui voulaient du drop-in Mega, mais c'est nécessaire pour les vitesses à 480 MHz. Côté réseau, le bug TCP (issue #937) est coriace : si vous ne lisez pas tout le corps de la réponse HTTP, vous prenez une erreur -3005 et 30s de freeze. J'ai aussi vu des crashs avec WiFiClient en global. La connectique caméra/display est top, mais le prix de 77,90 euros reste salé pour du hobbyiste. Le form factor est un atout, mais lisez bien les issues GitHub avant de coder en dur.

expert-arduino · 2026-04-26

Merci pour le rappel sur le TCP, j'ai perdu une après-midi dessus. En fait, je confirme le souci de l'ADC. J'ai galéré avec le mapping des broches analogiques, j'ai eu des valeurs incohérentes sur A12 qui renvoyait du A8 selon les versions du core. C'est corrigé depuis ? Sinon, le double USB (C et A) est vraiment pratique pour brancher une clé USB sans shield, ça justifie un peu le prix par rapport à une Nano classique. Par contre, la doc sur les partitions de la Flash double bank est floue, j'ai du mal à savoir combien de place il reste vraiment pour mes deux coeurs.

maker-trois-pattes · 2026-04-30

Pour l'ADC, le bug #758 est fermé, donc mets à jour ton core Arduino. Le vrai danger selon moi c'est le firmware Wi-Fi qui peut se bricker avec une mauvaise mise à jour (issue #650). J'ai failli perdre ma carte en tentant de flasher une beta, heureusement le reflash a marché. Sur le plan industriel, le FDCAN et l'ATECC608A sont des plus-values réelles si tu fais du sécurisé. Mais si ton projet est juste un petit capteur, la consommation et la complexité de gestion des deux coeurs via RPC peuvent être overkill. La prise jack audio est un gadget sympa, mais il faut un bon shield pour l'exploiter correctement.

codeur-obscur · 2026-05-03

Bonjour a tous, petit retour d'experience sur la GIGA R1 WiFi après quelques projets. C'est clairement une bête de course avec son dual-core STM32H747XI, mais attention au piège classique : l'absence totale d'antenne interne. Sans la petite antenne u.FL vissée, le Wi-Fi et le BLE sont quasi inutilisables une fois la carte dans un boîtier. Deuxième point crucial si vous utilisez le port USB-A en mode host : il ne marche pas par défaut. Il faut impérativement mettre la broche PA_15 en état haut dans votre code pour alimenter le port, sinon vos clés USB ne sont pas détectées. Enfin, n'oubliez pas que tout est en 3.3V, donc oubliez vos vieux shields 5V sans adaptateur de niveau logique, ça risque de ne pas fonctionner ou de griller des composants.

expert-arduino · 2026-06-28

Salut, merci pour ces infos claires. J'ai justement galéré avec mon shield moteur qui ne réagissait pas du tout, je pensais avoir un problème de câble. Du coup, est-ce que je peux utiliser directement un shield relais standard ? Ou est-ce que je dois aussi prévoir une logique externe à cause du courant ? Je m'inquiète un peu parce que la fiche technique mentionne une limite de courant par broche assez basse comparé à mes anciennes cartes UNO. J'espère que ce n'est pas trop restrictif pour piloter de petits relais 3.3V directement sans driver externe.

maker-debutant-88 · 2026-07-02

Salut maker-debutant-88, attention effectivement. La limite est stricte à 8 mA par broche I/O. C'est très loin des capacités des cartes AVR classiques. Même pour un petit relais 3.3V, tu risques de dépasser cette limite ou de ne pas avoir assez de courant pour l'enclencher de manière fiable. Je te conseille d'utiliser un transistor ou un petit driver ULN2803, ça coûte trois fois rien et ça protège ta carte. Pour ton shield moteur, vérifie bien qu'il est compatible 3.3V logiquement, sinon il faudra des buffers. La GIGA est puissante mais elle est fragile sur l'interface avec le monde extérieur si on ne respecte pas ces contraintes.

electronicien-du-coin · 2026-07-03

Après quelques semaines sur la LattePanda 3 Delta, je confirme l'atout majeur : c'est un vrai x86 avec un Arduino Leonardo integre, pas un simple GPIO. La bibliotheque pinpong pour Python marche bien. Par contre, attention a l'énergie. J'ai perdu du temps car ma carte bootait en EFI shell. La solution etait de flasher le BIOS vers la version LP-BS-7-S70JR120-CN51G-E comme indique dans la FAQ. Aussi, ne prenez pas le chargeur USB-C legere de votre telephone. Il faut au moins 24W (12V/2A ou 15V/3A). Avec mon vieux chargeur 18W, elle redemarrait en boucle. Le ventilateur ne tourne pas a froid, c'est normal, il attend le seuil de temperature. C'est un point de confusion frequent.

expert-pi-like · 2026-07-15

Merci pour le retour sur l'alim, je pensais que l'USB-C PD standard suffisait. Question sur la partie Arduino : je vois que tu utilises Python via pinpong, mais est-ce que tu as essaye le mode natif avec Arduino IDE ? Je demande car je lis que le chip est un ATmega32U4-MU. Est-ce que tu as rencontre des soucis avec le niveau logique des broches ? Je n'ai pas trouve de datasheet spécifique confirmant si c'est du 3.3V ou 5V sur les pins D0-D23. Si je branche un capteur 5V directement, risque je de griller les entrées ? Je prefere eviter les magic-smoke.

maker_flou · 2026-07-17

Pour repondre a ta question niveau logique, c'est l'une des zones d'ombre. Les tutos officiels font clignoter une LED via 5V, mais la fiche technique ne certifie pas explicitement le niveau par pin. J'ai prefere jouer la sécurité avec des convertisseurs de niveau. Sinon, si tu fais du kiosk industriel comme moi, attention au Watchdog. Si tu laisses l'application de feeding tourner pendant une mise à jour Windows, la carte redemarre en plein patch. Il faut stopper le service avant l'update. Et si tu as des ecrans doubles, verifie bien que le BIOS est à jour pour eviter les bugs de boot order avec Ubuntu.

kiosque_dev · 2026-07-19

Petit retour d'experience après quelques mois avec la LattePanda Alpha. L'atout majeur reste le combo x86 et Arduino via l'ATmega32U4, très pratique pour prototyper sans pont USB série. La puissance du m3-7Y30 est reelle pour un format 115x78mm, mais attention a la gestion thermique : sans heatsink adequat, le throttling degrade vite les performances sous charge lourde, comme le notait deja la revue de Mick Hellstrom. Le point noir absolu reste l'absence totale de bouton power ou reset. Il faut couper l'alim ou utiliser le BIOS pour le démarrage auto, ce qui est penible au banc. Si vous prenez la version Alpha 800, sachez qu'elle a 0 Go de stockage eMMC : il faut absolument ajouter un SSD M.2 avant le premier boot, sinon c'est une brique. L'alim USB-C PD de 45W est obligatoire, une sous-alimentation provoque des reboot infinis.

expert-pi-like · 2026-08-20

Salut expert-pi-like, merci pour le retour. Je confirme pour l'absence de bouton, c'est très frustrant quand on doit couper le courant a chaque test. Par contre, je bute sur le support Linux. Les docs officielles s'arretent a Ubuntu 16.04 et j'ai des soucis de Wi-Fi et d'audio avec des versions plus recentes. Quelqu'un a une config qui tourne bien sur une distro actuelle, ou est-ce que je dois rester sur Windows 10 pour eviter la chasse aux drivers ?

maker_bricoleur · 2026-08-22

Pour faire suite a maker_bricoleur, le support Linux est effectivement communautaire et souvent casse sur les versions recentes. J'ai du bidouiller les drivers pour faire fonctionner le Wi-Fi 802.11ac et l'audio sur ma config. C'est documente par intermittence sur le forum officiel mais rien de centralise. Si tu veux du x86 stable sans passer par la case Hackintosh (qui demande une carte Wi-Fi differente), Windows reste la voie la plus sure vu que les images et outils de flash BIOS sont centres sur Windows.

linux_hacker_01 · 2026-08-25

Petit retour d'experience sur la Leonardo. Le point fort reste le contrôleur ATmega32u4 avec son USB natif, ce qui permet de creer des peripheriques HID (clavier, souris) sans puce supplementaire. C'est très pratique pour les macros ou l'automatisation. En revanche, attention au piege classique lors de la migration depuis une Uno : la classe Serial ne pointe pas sur les broches 0/1 mais sur le port USB CDC. Pour l'UART TTL physique, il faut utiliser Serial1. Autre detail qui surprend : le bus SPI n'est pas accessible sur les headers numériques mais uniquement via le connecteur ICSP a 6 broches. Les shields utilisant le SPI standard ne fonctionneront donc pas sans adaptateur. Si vous codez du HID, mettez un switch pour couper l'envoi, sinon vous risquez de bloquer votre PC avec des clics infinis et de devoir appuyer sur reset pour reprogrammer.

expert-arduino · 2026-08-28

Merci pour ce rappel sur le SPI, je me suis fait avoir avec un shield capteur qui ne repondait pas. J'ai cru a un defaut matériel. Par contre, j'ai une question sur le courant par broche. La fiche technique du store indique 40mA par pin I/O, mais je vois souvent la mention 10mA ailleurs (ou dans les specs techniques internes). Pour alimenter un petit moteur DC via un transistor, est-ce fiable de compter sur les 40mA ? Je ne veux pas griller le microcontroleur. Si c'est ambigu, je vais rester prudent autour de 20mA.

maker-debutant-05 · 2026-08-30

Pour le courant, la discrepance existe bel et bien entre les differentes sources officielles. Tant que tu restes en dessous de 20mA par broche, tu es generalement dans le sur avec l'ATmega32u4, mais evite de tirer sur les limites sans vérifier la datasheet du Microchip. Sur un autre point, si tu utilises des entrées analogiques A6 a A11, attention a leur mapping sur les broches numériques (4, 6, 8, etc.). Cela peut creer des conflits si tu configures ces broches en digital en même temps. J'ai deja passe une heure a debugger un conflit de pin a cause de ca. La doc hardware est claire la-dessus, mais c'est facile a oublier quand on empile les shield.

bricoleur-avere · 2026-09-03

Bonjour à tous. Je reviens vers vous avec un retour d'expérience sur la Le Potato (AML-S905X-CC). C'est une carte intéressante pour son prix, mais il y a des pièges classiques. Le plus gros souci reste l'alimentation : si vous avez des redémarrages silencieux ou des freezes sous charge, c'est presque toujours la carte SD ou l'alim. Utilisez du micro-USB court ou alimentez par le header GPIO, mais attention, aucun pin n'est 5V tolerant. Pour le GPIO, oubliez wiringPi, c'est du passé. Utilisez libgpiod. Si vous avez une erreur 'module gpiod has no attribute Chip', c'est un conflit pip/système, désinstallez le package pip. Autre point chaud : la puce chauffe beaucoup sans dissipateur, prévoyez un heatsink immédiatement. Enfin, l'I2C n'est pas actif par défaut, il faut charger l'overlay DT. Ça reste une bonne alternative au Pi 3 pour du headless bien configuré.

expert-pi-like · 2026-09-08

Merci pour ces infos. J'ai justement un problème de boot avec ma Le Potato. J'ai les lumières rouges et bleues mais rien à l'écran, même après avoir changé de carte SD. J'ai lu que c'était un souci courant. Est-ce que ça peut venir du fait que j'ai essayé une image 'box' Android récente alors que j'essaie de passer sous Armbian ? J'ai l'impression que ça a cassé le bootloader. Du coup, est-ce que je dois repartir de zéro avec une image mainline spécifique ou est-ce qu'il y a un moyen de réparer le bootloader sans démonter la carte ? Je débute et je ne veux pas bricoter trop aveuglément.

maker-debutant-01 · 2026-09-11

Salut maker-debutant-01. Oui, mélanger les images legacy (type Android/Amlogic 3.14/4.9) avec les images mainline est une mauvaise idée. Les anciens scripts 'installtointernal' cassent le boot modern. Tu ne peux pas mettre à jour une image legacy vers mainline en place. Tu dois flasher une image compatible mainline (comme Armbian) sur une SD neuve. Assure-toi d'utiliser l'image spécifique 'lepotato' et non une image générique. Si ça ne boot toujours pas, vérifie ton alimentation comme le dit expert-pi-like, car une alim instable provoque exactement ce symptôme de blocage aux LEDs. Et pour l'I2C dont tu auras besoin plus tard, n'oublie pas l'overlay manuel.

linux-tinker · 2026-09-13

Retour d'experience sur la LilyPad. C'est une carte culte pour le textile, mais attention aux pieges. La section Problemes confirme ce que je craignais : la gestion de l'alimentation est critique. Sur les modèles Main et Simple, dépasser 5.5 V ou inverser la polarite detruit la carte instantanement. Pas de droit a l'erreur. Autre point dur : le domaine de tension. La version USB tourne a 3.3 V alors que les classiques sont en 5 V. Si vous branchez un accessoire 5 V sur une USB, vous risquez des erreurs de lecture ou des dommages. Et puis il y a les bugs de doc officiels, comme les desaccords sur les broches PWM ou les entrées analogiques, ce qui complique le debug quand on debute. Malgre tout, l'aspect cousable avec les languettes metallisees et les peripheriques coudus reste unique.

expert-arduino · 2026-09-28

Merci pour ce rappel. J'ai justement rencontre le bug de l'upload. J'avais selectionne 'Leonardo' par reflexe pour ma LilyPad USB car le microcontroleur est le 32U4. Resultat : le port COM disparaissait des la réinitialisation et impossible de flasher. J'ai du utiliser l'astuce du double-reset juste avant l'upload pour que ca passe. C'est super frustrant quand on est en cours d'atelier. Du coup, je me demande : est-ce que les languettes de couture tiennent bien le coup au lavage ? La doc dit 'lavable a la main' pour la Simple, mais j'ai peur que le fil conducteur ne casse avec les pliages.

couturiere_num · 2026-09-29

Pour le lavage, la cle est de retirer la batterie (pour la Simple) et d'utiliser de l'eau froide. J'ai reussi a faire une vingtaine de cycles sans souci sur une veste, mais j'ai isole mes fils conducteurs avec du vernis a ongles transparent aux points de soudure/couture. Sans ca, les courts-circuits par effilochage du fil stainless sont quasi garantis, comme mentionne dans les problèmes. Concernant les peripheriques, n'essaie pas de les alimenter via le connecteur FTDI sur une Simple : le circuit de charge le bloque. Il faut un module externe ou la batterie. C'est bete mais c'est comme ca.

maker_fabric · 2026-09-30

Retour sur la M5Stack Core Basic v2.7. C'est un kit solide avec son écran IPS 2.0 pouces et son boîtier empilable via le M-BUS, idéal pour prototyper vite grâce à l'écosystème M5Unified. Attention aux pièges de la v2.7 : le pont USB est désormais un CH9102F, pas le CP2104 des anciennes versions, donc si aucun port COM n'apparait, changez de driver. Autre point crucial, la mémoire Flash est passée à 16 MB en 2020, vérifiez vos tables de partitions si vous migrez d'un vieux projet 4 MB. Enfin, l'absence de PSRAM et d'IMU sur cette version de base impose de ne pas copier-coller des exemples Gray ou Core2 sans adapter le code, sinon ça plante silencieusement.

expert-microcontroleur · 2026-08-10

Merci pour ce résumé. J'ai justement un souci avec l'alimentation. Je trouve ça bizarre qu'il faille double-cliquer sur le bouton rouge pour éteindre proprement. Parfois je pense que la carte est morte alors qu'elle est juste éteinte, et il faut appuyer à nouveau pour la réveiller. Est-ce que le niveau de batterie affiché est fiable aussi ? J'ai l'impression que ça saute de 50% à 100% sans transition.

maker_debutant_88 · 2026-08-14

C'est normal. Le circuit IP5306 gère la mise en veille logicielle, donc un powerOFF dans le code coupe le boost sans débrancher physiquement, d'où l'aspect 'brique' temporaire. Pour la batterie, ne t'attend pas à une précision de jauge : la datasheet indique que le pourcentage est calculé par bandes de tension grossières (ex: 3.81-3.55V = 50%). C'est très imprécis. Si tu as besoin d'une vraie autonomie, ajoute un module externe ou utilise des seuils de tension bruts via l'I2C plutôt que l'API Power qui est trop granulaire.

expert-microcontroleur · 2026-08-17

Retour d'expérience sur la StickC-Plus2 (v2 ESP32-PICO-V3-02). Attention au piège du HOLD pin (G4) : si vous sortez de deep sleep via le RTC BM8563, votre code doit immédiatement mettre G4 à 1, sinon la carte s'éteint et vous avez l'impression d'être dans une boucle de reboot. C'est documenté mais facile à rater. Le point fort est la libération des ressources : pas de PMIC AXP192, donc Wi-Fi et IR plus stables. Par contre, méfiez-vous des pins G25/G26 : ce sont des ADC2, donc inutilisables dès que le Wi-Fi tourne. Utilisez G32/G33 pour l'analogique. Le produit est EOL, donc si vous débuggez, faites-le maintenant.

expert-microcontroleur · 2026-06-11

Merci pour le rappel sur le HOLD pin, j'ai perdu deux heures à comprendre pourquoi ma routine de réveil ne tenait pas. J'ai un autre souci : ma carte n'est plus détectée par le PC via USB-C. J'ai beau changer de câble, rien. Dans la doc, il est mentionné qu'il faut éteindre la carte (LED verte allumée ?) puis rebrancher pour que le port apparaisse. C'est bizarre comme comportement. De plus, je n'arrive pas à éteindre complètement la carte quand elle est en charge, le long press sur le bouton C ne fait que couper l'écran. C'est normal ?

hobbyiste-bricoleur · 2026-06-12

Pour ton problème de port USB, vérifie bien que le driver CH9102 est installé, c'est souvent l'oubli classique. Sinon, oui, l'extinction complète est impossible tant que le 5V est présent sur le port USB, le circuit de latch ne coupe pas l'alim externe, seul le mode veille s'active. Concernant les specs, si tu cherches à utiliser l'alimentation externe, sache que les pins externes G25/G26/G36 sont partagés sur certains connecteurs, donc attention aux conflits matériels. Et évite d'utiliser le buzzer sur G2 si tu as d'autres composants chargés sur cette ligne au démarrage, ça peut bloquer le boot.

maker-debutant-77 · 2026-06-15

Petit retour après quelques mois sur la Mega 2560 Rev3. C'est toujours le roi de l'I/O pour les projets lourds : les 4 UART materiels changent la vie quand on doit gerer un GPS, un modem et le debug PC en parallele sans se casser la tete avec SoftwareSerial. La mmoire de 256Ko est confortable compar au Uno. Par contre, attention aux pieges classiques documentes. Le 16U2 est une arme double tranchant : super pour faire du HID sur mesure, mais si tu le bricks, ton port USB disparait totalement et tu es obliger de repasser par du DFU ou un cable FTDI externe. Et j'ai eu le souci de blocage USB quand mon script python ne lisait pas assez vite le buffer, la carte freeze completement. Il faut bien grer le flow control.

expert-arduino · 2026-09-15

Salut, je bute sur un truc chiant avec ma Mega. J'ai un vieux shield I2C qui marchait niquel sur mon ancien Duemilanove, mais la il ne se passe rien sur la Mega. Je vois bien les cables connectes sur A4/A5 mais le scanner I2C ne trouve aucun priphrique. C'est normal ? Je commence a penser que mon shield est mort alors que non.

maker-debutant-99 · 2026-09-16

Pas de panique, ton shield va probablement très bien. Le trou est exactement celui que tu cherches : sur la Mega (et les cartes R3 en general), le bus I2C (TWI) est cbl sur les pins 20 (SDA) et 21 (SCL), pas sur A4/A5 comme sur les vieux Duemilanove ou les premières versions. Il faut juste que tu reroutes tes cables vers les pins 20 et 21 près du connecteur de puissance. Ca m'a aussi piege. Attention aussi si tu utilises des shields a empiler : l'ecart plus large entre les pins 7 et 8 (160 mil au lieu de 100) peut empecher certains boucliers de s'aligner correctement si ils ne sont pas prvus pour la norme R3.

gigolo-electronique · 2026-09-20

Retour d'experience sur la Mega ADK (Rev3). Les specs sont solides : 54 pins, 4 UARTs, et surtout le contrôleur USB Host MAX3421E integre. C'est la seule carte AVR classique avec un port USB-A maitre natif, ce qui est top pour piloter des peripheriques ou utiliser le protocole AOA. Mais attention aux pieges. Le plus courant est l'erreur OSCOKIRQ failed to assert. Cela signifie souvent que le MAX3421E ne démarre pas correctement, soit a cause d'un problème de cristal, soit d'un mauvais mapping des broches. Assurez-vous que vos libraries utilisent bien BOARD_MEGA_ADK pour que le reset soit sur la bonne pin (attention, le SS est sur PH7 ici, pas D10 comme sur les shields classiques). Autre point crucial : ne touchez pas a la pin digitale 7, elle est reservee a la communication avec le chip USB. Si vous l'utilisez, tout plante silencieusement.

expert-arduino · 2026-07-26

Merci pour ce rappel. Je confirme le souci d'alimentation qui est très sournois. J'ai passe des heures a croire que ma carte etait morte car mon smartphone refusait de charger. En fait, si tu alimentes la carte via le port USB micro-B standard, tu as droit a seulement 500 mA au total, repartis entre la carte et le telephone. Pour avoir les 1,5 A annonces, il faut imperativement une alimentation externe de 7 a 12 V sur le jack ou VIN. Sans ca, le regulateur chauffe et le courant saute. C'est aussi un vrai cauchemar de trouver des infos à jour. Le wiki ADK est mort, les liens de téléchargement officiels sont des 404. On doit se debrouiller avec des archives et des librairies tierces. Et puis, si tu veux faire du SPI avec une carte SD en même temps, il faut desactiver le MAX3421E manuellement autour des transferts, sinon c'est la guerre sur le bus.

maker_bricoleur · 2026-07-29

Une petite question technique sur la partie logicielle. Vous parlez des erreurs d'enumeration avec les nouveaux telephones. J'ai une vieille app qui marche sur Android 10 mais qui ne detecte plus rien sur mon nouveau mobile. Est-ce que le problème vient vraiment du hardware ou c'est juste Android qui bloque les permissions USB ? Je vois des threads ou les gens disent que la carte apparait mais ne s'ouvre pas. Le document officiel parle aussi de ne pas oublier la chaîne de version AOA, sinon le telephone peut rebooter. C'est un truc qui arrive souvent en pratique ?

newbie_coder · 2026-08-01

Retour d'experience sur l'Arduino Micro. Le format 48x17.7mm est vraiment pratique pour les breadboards, on gagne de la place par rapport a l'Uno. La presence du 32U4 permet d'être reconnu comme clavier/souris, c'est top pour les macros. Par contre, attention aux pieges documentes. D'abord, le dual serial : Serial est l'USB et Serial1 est le TTL sur les pins 0/1. Beaucoup de tutos Uno ne marchent pas directement. Ensuite, le bug CDC RX (issue #267) est toujours la : Serial.available renvoie souvent 0 ou 1 même si plusieurs octets arrivent, ca casse les trames. Et n'oubliez pas que le SPI n'est pas sur le header digital mais uniquement sur l'ICSP. Les shields classiques ne passent pas sans adaptation.

expert-arduino · 2026-09-14

Merci pour le rappel sur le SPI, j'ai perdu une heure a comprendre pourquoi mon module ne repondait pas. Concernant le bug CDC, est-ce que ca affecte aussi la vitesse de chargement ? J'ai souvent des erreurs de port série au moment du upload. Il faut vraiment appuyer sur le bouton reset a la seconde près ? Le delai de 8 secondes du bootloader Caterina est trop court a mon gout, surtout si l'IDE ne detecte pas automatiquement la commande de reset a 1200 bauds. C'est très frustrant quand on fait du developpement iteratif rapide.

maker-hobbyiste · 2026-09-17

Pour repondre a ta question sur le upload, oui, la dance du reset est obligatoire si l'auto-reset échoue. Le port COM disparait au moment du reset, donc il faut être rapide pour reselectionner le port dans l'IDE une fois le bootloader actif. Un autre point delicat : si tu joues avec les classes Keyboard/Mouse, tu peux bloquer ton propre PC si tu fais une erreur de code. Garde toujours un bouton physique en entrée pour couper l'exécution ou desactiver le HID. Enfin, pour l'alimentation externe, evite de dépasser 12V sur Vin sinon le regulateur chauffe, et n'oublie pas que le pin 3V3 est limite a 50mA.

dev-embarque · 2026-09-19

J'ai repris la micro:bit v2 pour un projet de capteurs. Le SoC nRF52833 est solide, mais attention aux pièges matériels documentés. Le speaker est câblé sur P0, ce qui rend l'usage de cette broche en entrée analogique ou tactile très compliqué, même avec speaker.off. De plus, si vous lisez plusieurs entrées ADC successives, attendez-vous à des sauts erratiques autour de 1024, un vieux problème de CODAL. Heureusement, le drop-and-flash via DAPLink reste super fiable pour le public scolaire. N'oubliez pas que seul KL27 est programmable pour l'interface, le reste est verrouillé.

expert-microcontroleur · 2026-05-02

Merci pour ce rappel, j'ai perdu une heure à comprendre pourquoi mes lectures sur P0 étaient bizarres, c'était le conflit avec le haut-parleur. Par contre, j'ai un souci avec la vitesse série. Dès que je dépasse les 9600 bauds, je perds des caractères. C'est normal ? Je pensais que le BLE gérait tout, mais apparemment le lien série interne est limité. Et est-ce que je risque de griller quelque chose si j'alimente par le pin 3V avec une petite batterie LiPo ? Je ne veux pas être trop strict avec les composants.

maker-debutant-42 · 2026-05-04

Oui, la perte de données au-dessus de 9600 bauds est due à l'absence de contrôle de flux matériel entre le KL27 et le nRF52833, c'est documenté officiellement. Pour l'alimentation sur le pin 3V, prudence absolue : c'est le rail brut V_TGT. La doc déconseille fortement les packs de batteries USB à cause des tensions hors plage, mais une LiPo doit être régulée. Évite le dépassement de 3.6V ou l'inversion de polarité, sinon tu peux endommager les puces. Le budget courant est limité à environ 190 mA pour les accessoires, ne force pas.

bricoleur-silicium · 2026-05-08

Petit retour d'experience sur la MKR GSM 1400, qui est malheureusement en fin de vie. Le point fort reste son integrite : c'est la seule carte MKR avec HSPA, SMS et appels vocaux. La puce ATECC508A est top pour la sécurité des cles via BearSSL. Par contre, attention au problème majeur documente : l'alimentation USB est insuffisante pour les pics de courant du module SARA-U201. Il est imperative d'avoir une batterie LiPo de 1500 mAh minimum branchee en permanence, sinon la carte resete en pleine transmission. De plus, le modem ne gere pas l'audio (pas de micro), donc les exemples d'appels ne servent qu'a piloter l'état.

expert-arduino · 2026-08-19

Je confirme le souci d'alimentation, c'est très frustrant quand on debute. Mais ma vraie question porte sur la librarie MKRGSM. Je vois qu'elle est figee a la version 1.4.2 et que la carte est EOL. Avec la fermeture progressive des réseaux 3G partout dans le monde, est-ce que quelqu'un a pu tester si le fallback 2G/GPRS fonctionne toujours correctement ? Je craque de voir mes devices hors ligne bientot. J'ai aussi lu que le bootloader ignore le bit de sécurité SAMD, donc le code reste lisible via bossac, ce qui est embetant pour un produit fini si on stocke des secrets.

maker-slow · 2026-08-20

Pour le fallback 2G, ca depend vraiment de ton operateur local, mais le risque est reel vu que certains pays coupent aussi le 2G. Concernant la lecture du flash via bossac, oui c'est un bug connu non corrige car la carte est abandonnee. Si tu stockes le PIN SIM en dur dans le code, c'est une faille de sécurité critique. Pour eviter les blocages I2C au boot lies au PMIC BQ24195L, certains patchent la librarie pour desactiver l'init stricte, mais c'est du bricolage. Franchement, pour un nouveau projet IoT cellulaire, je te conseille de regarder des cartes NB-IoT ou LTE-M plus recentes, la GSM 1400 devient un trou noir technique.

hacker-0x1 · 2026-08-24

Retour d'experience après plusieurs mois sur la MKR NB 1500. Le module SARA-R410M-02B est solide pour du LTE-M/NB-IoT global, et l'ECC508 est un vrai plus sécurité. Mais attention aux soucis documentes : la biblio MKRGSM reste instable (issue #66), et le flux RTS/CTS n'est pas active par defaut (issue #689), ce qui fait cracher les données AT lourdes. Le LED d'alim reste allume sur batterie, une conso inutile. Si vous faites du MQTT, les échecs de connexion sont souvent lies a l'interaction PSM/keepalive, pas a la carte elle-même. Verifiez bien que votre operateur couvre les bandes supportees avant de deployer.

expert-arduino · 2026-06-16

Merci pour le resume. J'ai exactement ce souci de modem qui se fige au redemarrage doux. Tu utilises le hard reset via la ligne RESETN ou le secureShutdown ? J'ai eu le cas ou il fallait couper l'alim completement. En attendant, est-ce que la version recente de MKRGSM gere mieux la selection RAT (NB-IoT vs LTE-M) ou il faut encore bidouiller ? Ca m'enerve de devoir forcer un mode spécifique si l'auto-selection foire.

maker-trois · 2026-06-18

Je confirme le problème du LED. J'ai mis un switch sur la ligne PMIC_IRQ pour gerer un peu mieux la conso, mais c'est bricolage. Par contre, n'oubliez pas que le SARA-R410M a besoin d'antenne externe ou une très bonne interne selon l'installation. J'ai du deplacer la carte de 20cm pour passer de 0 bars a un signal correct en zone rurale. La portee NB-IoT est theoriquement grande, mais en pratique ca depend beaucoup de l'environnement immediat.

solder-queen · 2026-06-19

Petit retour d'experience sur la MKR WAN 1300 maintenant qu'elle est delistee au profit de la 1310. Le format MKR est vraiment pratique et le module Murata CMWX1 fait le job en EU868 ou US915. Par contre, attention aux pieges connus. Le problème du compteur de trames qui bloque l'emission après 255 envois (issue #141) est très frustrant en test. Aussi, le throttle matériel de 2 minutes est irreductible, ce qui casse les schémas de poll rapide. Enfin, si vous migrez, lancez toujours l'updater de firmware avant d'utiliser la lib MKRWAN pour eviter les erreurs de version. La gestion ABP a aussi recule avec la v1.0.15. C'est une bonne carte, mais faut lire les issues GitHub avant de coder.

expert-arduino · 2026-07-20

Merci pour ce resume clair. Je viens de recevoir ma 1300 pour un projet de suivi de niveau d'eau. Tu parles du compteur de trames, mais est-ce que le faux échec de joinOTAA est systematique ou ca depend de la config ? J'ai lu l'issue #139 mais je ne suis pas sur de comprendre si c'est un bug de la lib ou du module. Sinon, je compte mettre une batterie externe, donc pas de souci pour le chargeur absent comme sur la 1310.

maker_loi88 · 2026-07-22

@maker_loi88 le faux échec de joinOTAA est frequent si tu ne geres pas les timeouts correctement, cf issue #139. Pour le throttle, ne cherche pas a le contourner, c'est grave en EU868. Si tu as besoin de plus de fiabilite et d'un chargeur LiPo integre, la 1310 est mieux, mais la 1300 reste fonctionnelle si tu mets à jour le firmware. Attention aussi a l'API restart qui n'est pas documentee, issue #132.

hacker_99 · 2026-07-23

Bonjour à tous, je débute avec la MKR WAN 1310 pour un projet de suivi de température en extérieur. J'ai suivi le tuto officiel pour la connexion OTAA sur un réseau local, mais je bloque systématiquement. La fonction joinOTAA renvoie une erreur quelque chose a mal tourne, alors que mes clés sont correctes. Dans les issues GitHub, on parle de faux positifs avec la version actuelle de la librairie MKRWAN. Est-ce que quelqu'un a réussi à contourner ce problème sans downgrader tout l'environnement Arduino ? J'ai peur que ce soit lié à la configuration des fréquences EU868.

maker-loi · 2026-07-02

Salut, ce souci de faux échec avec joinOTAA est effectivement documenté dans l'issue 139 du dépôt MKRWAN. Avant de modifier ton code, vérifie impérativement la version du firmware de ton module Murata. Sur les cartes neuves, il y a souvent un décalage entre la librairie récente et le firmware préinstallé, ce qui provoque l'erreur Firmware version mismatch ou des échecs de jointure silencieux. Il faut lancer l'exemple de mise à jour du firmware fourni dans la librairie avant toute autre manipulation. Une fois le module à jour, le problème de joinOTAA disparaît généralement. Attention aussi au régulateur de débit imposé par le firmware EU qui empêche plus d'un envoi toutes les deux minutes, ce qui peut fausser tes tests en boucle.

expert-arduino · 2026-07-06

Je confirme le point sur le firmware, ça m'a fait perdre une après-midi. Par contre, je rencontre un autre souci plus insidieux : après environ 255 transmissions réussies, ma carte ne peut plus rien envoyer, sans aucune erreur explicite dans le moniteur série. J'ai vu que c'est un bug connu lié au compteur de trames, voir l'issue 141. C'est très frustrant pour un déploiement long terme. En attendant un patch, je suis obligé de faire un reset manuel ou programmé régulièrement. Sinon, la carte est super pour l'intégration dans des boîtiers MKR standards, mais la dépendance au firmware propriétaire de Murata reste un frein.

gadget-hunter · 2026-07-10

Petit retour d'experience sur la MKR WiFi 1010. C'est une carte solide pour l'IoT securisee, notamment grâce à la puce crypto ECC508 et au module NINA-W102 qui gere bien le Wi-Fi et le BLE. Par contre, attention aux pieges classiques. Si vous avez des erreurs de connexion (code 255), c'est presque toujours un firmware NINA obsolete. Pensez a le mettre à jour via l'IDE 2. Autre point crucial pour les anciens utilisateurs d'Uno : ne branchez pas une alim 9V sur VIN. Cette carte accepte uniquement du 5V regule, sinon vous risquez de griller quelque chose. Et n'oubliez pas que le LED ON s'eteint sur batterie, c'est normal, il est cable sur le rail 5V.

expert-arduino · 2026-08-23

Merci pour ces infos, c'est exactement ce que je cherchais. J'ai justement un souci avec le mode Access Point. Quand je configure la carte en SoftAP, mon smartphone ne la voit pas par son nom via hostByName, je suis oblige de taper l'IP en dur. Est-ce un bug connu ou une limitation materielle ? J'ai lu qu'il y avait des histoires de resolution de nom en AP mode, mais je ne suis pas sure que ce soit regle avec les dernieres versions de la librairie WiFiNINA.

maker-debut · 2026-08-27

C'est bien un souci documente sur le tracker GitHub de la lib WiFiNINA (issue #92). En mode AP, la resolution de nom ne fonctionne pas comme en station. Pour ton projet, je te conseille de garder l'IP statique. Par ailleurs, si tu utilises des capteurs sur les ports I2C, sache qu'il y a un connecteur Eslov dedie a cote des headers classiques, très pratique pour eviter le soudage des modules officiels. La carte est petite (61.5 x 25 mm), mais ne te laisse pas avoir par la taille des pins GPIO a 3.3V : si tu branches un relais directement, ca ne marchera pas a cause de la limite des 7 mA par pin. Il te faut un transistor.

tech-hobby · 2026-08-28

Retour d'experience sur cette Pi 2 Model B. C'est une carte solide pour le retro ou les projets legers, mais attention aux pieges si vous recuperez du stock. Le point fort reste le rapport perf/prix historique avec ses 4 coeurs et 1 GB de RAM, largement suffisant pour de la navigation ou un petit serveur. Par contre, si vous avez une revision v1.2 avec le BCM2837, surveillez l'adresse MAC de l'ethernet. Elle change a chaque boot parce qu'elle n'est pas programmee en usine, ce qui casse vos reservations DHCP. Il faut forcer une MAC statique via smsc95xx.macaddr dans /boot/cmdline.txt. Autre souci courant : sans wifi integre, on depend du cable ou d'un dongle. Et avec les charges quad-core, ne sous-estimez pas l'algo de throttling a 85 degres si le boitier est ferme.

expert-raspberrypi · 2026-05-21

Merci pour le rappel sur la MAC, je me battais depuis deux jours avec mon serveur NAS qui changeait d'IP a chaque redemarrage. J'ai mis la ligne dans cmdline.txt et c'est regle. Par contre, je confirme le problème de puissance. Avec un chargeur micro-USB bas de gamme, des que je lance une compilation lourde sur les 4 coeurs, la carte sature et je vois l'eclair de sous-tension a l'ecran. Si vous utilisisez cette carte pour autre chose qu'un point d'acces simple, investissez dans une vraie alimentation 5V stable. Le polyfuse protege bien mais il coupe tout si on depasse les limites du bus USB, et c'est chiant a relancer a chaud.

hackeur-du-vendredi · 2026-05-24

Petite question pour les experts. Je viens de récupérer une Pi 2 v1.1 (donc BCM2836) pour monter un pi-hole. Je vois que le support ARMv7 va disparaitre des distributions officielles. Est-ce que vous recommandez de rester sur une vieille version de Raspberry Pi OS ou est-ce qu'il y a des alternatives comme Alpine ou Armbian qui tiennent la route sur cette architecture 32-bit spécifique ? J'ai peur que le wifi via dongle ne soit pas reconnu correctement sur les noyaux recents sans les bons firmwares.

linux_nouveau · 2026-05-26

Après plusieurs semaines d'utilisation de la 3 Model A+, je confirme ce que la fiche technique laisse entendre. Le format 65x56 mm est super pour les boîtiers compacts, et le Wi-Fi 5 GHz est un vrai plus par rapport aux anciens modèles A. Par contre, les 512 MB de RAM sont vite saturés avec le bureau moderne. J'ai dû réduire la mémoire GPU au strict minimum pour éviter les plantages OOM. Attention aussi à la gestion thermique : sans ventilateur, le throttling arrive vite sous charge soutenue. Le port micro-USB est fragile si vous branchez/débranchez souvent. C'est une carte intéressante pour du headless, mais exigeante en configuration.

expert-raspberrypi · 2026-05-17

Salut, merci pour ce retour. Je hésite à la prendre pour un projet domotique fixe. Tu dis que le port USB unique est un problème, mais est-ce que ça veut dire que je ne peux pas avoir à la fois un dongle Wi-Fi externe et un disque dur USB ? Ou est-ce que le Wi-Fi interne suffit pour la plupart des cas ? J'ai peur de devoir sacrifier un périphérique si le réseau est capricieux. En plus, sans Ethernet ni PoE, je me demande si l'alimentation par GPIO est vraiment stable sur la durée.

maker-2024 · 2026-05-19

Le port USB unique est effectivement le gros point noir. Si tu branches un SSD, tu ne peux pas mettre un dongle Wi-Fi, mais heureusement le Wi-Fi interne (802.11ac) est correct. Par contre, n'espère pas utiliser un hub USB pour connecter plusieurs choses, ça fait souvent des coupures à cause de la limitation de courant sur la ligne micro-USB. Pour l'alim par GPIO, ça marche mais c'est moins fiable qu'une entrée micro-USB propre. J'ai eu des brown-outs avec un câble GPIO trop long. Vaut mieux investir dans un bon alimentateur 5V/2.5A certifié pour éviter les instabilités.

geek-du-sud · 2026-05-21

La Pi 3 Model B reste une référence solide, surtout si vous avez le modèle v1.2 (BCM2837B0 avec dissipateur intégré) sorti début 2019. Les premiers modèles sans radiateur thermique chauffent vite : à 85°C, le throttling est brutal et les performances chutent nettement, surtout en caisson fermé. C'est le problème thermique majeur documenté. Pour l'alimentation, ne lésinez pas : le seuil de détection de sous-tension est à 4.63V. Avec un câble micro-USB trop fin ou long, vous allez voir le flash de l'éclair dans la barre des tâches et des corruptions de SD card. Les 2.5A recommandés sont un minimum vital si vous branchez des périphériques. Évitez aussi de saturer le bus USB 2.0 partagé avec l'Ethernet 100Mbits ; si vous faites du transfert réseau intensif pendant une copie de fichiers, la bande passante s'effondre. C'est une limitation physique du hub LAN9514, pas un bug logiciel.

expert-raspberrypi · 2026-05-16

Merci pour ce rappel sur le throttling. J'ai effectivement une v1.1 (sans le spreader) qui devient inutilisable en été dans son boîtier plastique. Je pensais que c'était un problème de ventilo, mais c'est bien la température du die. Par contre, tu mentionnes le Wi-Fi uniquement 2.4 GHz. J'ai du mal à tenir une connexion stable pour du streaming audio via le module BCM43438 quand mon voisin utilise son micro-ondes. Est-ce que c'est lié à la coexistence Bluetooth/Wi-Fi sur la même puce comme indiqué dans la doc, ou est-ce juste la puissance de l'antenne ? J'ai l'impression que le débit réel est bien en dessous des 100 Mbits théoriques de l'Ethernet, ce qui force à rester en filaire pour les mises à jour système lourdes.

maker_hobby · 2026-05-19

Pour ton problème Wi-Fi, c'est effectivement la coexistence sur le BCM43438 qui est pénible en environnement bruité, sans compter que le bus USB 2.0 partagé limite le débit max si tu as d'autres périphériques branchés. Si tu veux garder la carte pour du réseau, le filaire reste la seule option fiable, même s'il plafonne à 100 Mbits. Autre point important si tu débutes : attention à la logique des GPIO à 3.3V. Beaucoup de capteurs chinois en 5V peuvent griller les pins si tu n'utilises pas de niveau shifter. Et n'oublie pas qu'il n'y a pas d'ADC natif, donc pour lire des capteurs analogiques, il faut obligatoirement un module externe type MCP3008 sur le bus SPI. La 1GB de RAM tourne bien en Lite, mais si tu tentes un bureau 64-bit complet avec Chromium, tu vas vite toucher les limites.

linux_tinker · 2026-05-20

Petit retour d'experience sur la 3B+. C'est toujours une carte solide a 35 dollars, surtout grace au Wi-Fi dual-band 802.11ac et au header PoE 802.3af qui facilitent grandement les deploiements en réseau sans prise secteur. Le passage au 64-bit est aussi appreciable. Par contre, attention a la consommation electrique. La documentation officielle insiste lourdement sur l'usage d'une alimentation 2.5A de qualite. J'ai vu des cartes instables et des corruptions de carte SD avec des alimentations micro-USB bas de gamme a cause de la detection de sous-tension a 4.63V. De plus, le réseau Ethernet est bridé a environ 300 Mb/s sur le bus USB 2.0, donc ne revez pas de vrai Gigabit. Si vous mettez la carte dans un boitier ferme, le plafond thermique souple a 60 degres C va vite faire chuter la fréquence de 1.4 a 1.2 GHz. C'est bien pense pour la sécurité, mais ca limite les perfs soutenues.

expert-raspberrypi · 2026-07-19

Merci pour ce rappel. Je galere justement pour activer le 5 GHz sur ma 3B+ fraichement installee. Malgre la connexion configurer, je ne vois aucune AP en 5 GHz. Est-ce que c'est lie a la configuration du pays ? J'ai lu quelque part qu'il fallait editer un fichier de configuration spécifique. Sinon, je vais rester sur le 2.4 GHz, mais je perd l'interet principal de cette carte par rapport a la 3B classique. Est-ce que c'est un bug connu ou juste une etape obligatoire que j'ai rate ?

maker-debutant · 2026-07-22

Ce n'est pas un bug, c'est une reglementation. Les pilotes Linux bloquent les canaux 5 GHz tant que le code pays n'est pas defini correctement pour respecter les normes locales. Il faut bien vérifier que le paramètre country est bien defini dans ton fichier wpa_supplicant ou via l'outil de configuration Raspberry. Sans ca, le module radio reste officiellement desactive sur cette bande. Une fois configure, tu devrais voir les debits monter vers les 100 Mb/s annonces. Pense aussi a vérifier ta puissance d'alimentation avec un multimeter si tu as des coupures, car le 5 GHz tire un peu plus sur l'énergie disponible.

linux-tinkerer · 2026-07-26

Retour global sur la Pi 4 Model B. Le passage au PCIe pour l'USB 3.0 et le GbE natif change tout au niveau réseau, c'est du vrai gigabit contrairement au bridage USB du 3B+. Par contre, gare à l'alimentation. Si vous avez une révision 1.0 ou 1.1, les câbles USB-C avec puce e-marker ne passent pas, il faut impérativement un câble 'dumb' ou l'alim officielle. La consommation peut grimper à 1.2A en stress, et le budget total pour les périphériques USB est plafonné à 1.2A, ce qui est très juste. La gestion thermique est aussi plus agressive : pas de soft limit comme sur la 3B+, ça throttle directement à 85°C. Prévoyez un ventilo ou un gros dissipateur sinon vous perdez en perfs en sustained load.

expert-raspberrypi · 2026-05-06

Merci pour le rappel sur l'alim. J'ai justement galéré avec ma version 1.2. J'utilisais un chargeur multi-ports USB-PD, et dès que je branchais mon téléphone sur un autre port, le Pi redémarrait. Apparemment les alimentations PD renégocient la tension quand un nouveau device est connecté, ce qui coupe l'alim du Pi. Il vaut mieux un secteur dédié de 5.1V 3A. Concernant les micro-HDMI, j'ai eu des soucis d'affichage noir avec des adaptateurs bas de gamme. Il faut des câbles certifiés 4K@60Hz, sinon ça ne passe pas, surtout en dual screen.

maker_du_42 · 2026-05-10

+1 sur la chaleur. Avec le stepping C0, je trouve que ça chauffe un peu plus que le B0 à fréquence équivalente, bien que ce soit plus stable globalement. Pour le Wi-Fi 5GHz, n'oubliez pas de configurer le code pays dans /etc/wpa_supplicant.conf, sinon les canaux restent bloqués par la réglementation. C'est bête mais j'ai perdu une heure à chercher pourquoi la 5GHz était invisible. Et évitez le modèle 1GB pour le desktop, c'est vraiment trop juste, visez minimum 4GB pour être à l'aise.

linux_gamer · 2026-05-12

Petit retour d'experience sur la Pi 5 après quelques mois d'utilisation. C'est indeniablement un saut de performance : on retrouve les 2 a 3x en CPU/GPU annonces par rapport a la Pi 4, et le dual 4Kp60 change tout pour le desktop. Le nouveau bouton power et l'RTC sont des vrais plus qualitatifs. Par contre, c'est chaud. Sans le Active Cooler, vous allez throttler a 85C sur n'importe quel bench soutenu. L'architecture RP1 est interessante mais attention aux pitfalls : le port PCIe est desactive par defaut si pas de HAT+ detecte (penser a dtparam=pciex1). Et surtout, ne comptez pas sur votre vieux HAT PoE de Pi 4, le header a bouge, il faut racheter. La conso en veille reste aussi une surprise si on ne met pas POWER_OFF_ON_HALT=1 dans l'EEPROM, sinon ca tire encore 1.4W.

expert-raspberrypi · 2026-08-22

Merci pour ce retour. Je confirmer le point sur l'alim, c'est le piege principal. J'avais branche ma Pi 5 sur un chargeur multiport 30W standard et j'avais des drops USB des que je branchais un SSD. Il faut absolument le 27W officiel (5V/5A) pour avoir les 1.6A sur les ports USB, sinon c'est limite a 600mA global. Et non, le PPS n'est pas supporte, ce qui est dommage vu que la plupart des chargeurs modernes l'utilisent. Ca a resolu mes problèmes de peripheriques qui se desynchronisaient au boot quand j'ai ajoute un autre device sur le hub.

maker-du-35 · 2026-08-26

Petite question pour les experts RP1 : je migre des scripts de Pi 3 et ca casse partout. Les vieilles bibliotheques directes sur BCM2835 ne passent plus car le GPIO est passe par le chiplet RP1. J'ai lu qu'il fallait migrer vers gpiozero ou libgpiod. Est-ce que les pins hardware PWM (12/13/18/19) sont toujours aussi stables via ces nouvelles libs ? Et pour l'RTC, j'ai mis une pile boutons CR2032 mais la doc dit que la charge est desactivee par defaut, donc pas besoin de souder un fil pour activer le chargement si je veux juste garder l'heure quand c'est eteint ?

gpio_zero · 2026-08-27

Retour sur la Model A après plusieurs mois d'utilisation en projet embarqué. Le concept est brillant pour le prix de 25 dollars, surtout pour les applications où l'on n'a pas besoin d'Ethernet. La bande passante USB complète est un vrai plus comparé à la Model B, mais attention à la gestion de l'alimentation. Avec seulement un port USB, brancher un dongle Wi-Fi et un clavier oblige à utiliser un hub alimenté, sinon le polyfuse saute et la carte sous-alimente. La RAM de 256 Mo est aussi très limitée aujourd'hui, oubliez les distros lourdes. Pour le gadget USB avec g_ether, sachez que des bugs persistent sur l'attribution des adresses MAC, le hôte peut voir une adresse aléatoire. C'est un point de friction connu documenté sur le tracker firmware. Sinon, la consommation réduite est idéale pour les boitiers fermés.

expert-raspberrypi · 2026-07-20

Merci pour ce retour. Je confirme le souci du polyfuse, c'est frustrant quand on branche un petit hub non alimenté pour tester un clavier. Par contre, pour la gestion du son, je me suis perdu au début. Il faut bien comprendre que le jack analogique et le HDMI ne fonctionnent pas en même temps par défaut, il faut forcer la sortie via vcgencmd ou configurer le boot. C'est une confusion classique à la première mise sous tension. Est-ce que quelqu'un a réussi à stabiliser le mode gadget réseau sans avoir ce problème d'adresse MAC aléatoire ?

maker-bleu · 2026-07-22

Pour l'adresse MAC sur g_ether, c'est malheureusement un vieux problème lié au BCM2835. Il n'y a pas de solution miracle côté soft, il faut parfois jouer avec les options du module au démarrage, mais ça reste capricieux. Pour le reste, si tu veux éviter les tracas du hub, le mode gadget en mode stockage ou clavier HID est plus stable que le gadget réseau sur cette carte, car il sollicite moins la pile USB réseau complexe. Pense aussi à vérifier ta alimentation micro-USB, la Model A est sensible à la chute de tension si le câble est trop fin, même sans hub.

linux-pi-user · 2026-07-25

Petit retour d'experience sur la Model B+ après quelques mois d'utilisation en projet domotique. Le facteur forme est vraiment l'atout majeur ici : le connecteur 40 pin et les 4 ports USB ont defini la norme pour tous les Modele B subsequent, ce qui facilite grandement la compatibilite materielle actuelle. Par contre, attention a la bande passante : les 4 USB et l'Ethernet partagent un seul port LAN9514 a 480 Mbps. En pratique, si vous branchez un clavier, une cle USB et que le réseau est actif, les debits reels s'effondrent. Ne comptez pas sur ce bus pour du stockage externe rapide. La RAM de 512 Mo est aussi un plafond dur : pour du headless ou une interface legere, ca passe, mais evitez les environnements graphiques lourds. Pour ceux qui passent d'un ancien modèle, les cartes d'extension de l'ere 26 pin ne rentrent plus mecaniquement, et il faut laisser les broches ID_SD et ID_SC libres pour detecter les HAT.

expert-raspberrypi · 2026-10-01

Merci pour ce retour, ca confirme mes doutes sur les perfs réseau. Je viens de recevoir ma B+ pour un projet media center basique. Tu dis que le port micro-SD a donne du fil a retordre au debut ? J'ai lu des trucs sur des problèmes de detection de carte. C'est toujours d'actu ou c'est corrige par les firmwares recents ? Je ne veux pas perdre des heures a debuger si c'est un bug connu mais resolu.

maker_hobbyiste · 2026-10-04

Salut, pour completer sur les alimentations : fais gaffe a la sous-tension. Si ton alim est juste, le polyfuse saute ou tu as des brown-outs qui font planter le système quand tu branches trop de peripheriques. Vu que tout partage le bus, un disque USB gourmand peut suffire a destabiliser l'ensemble. Pour la detection de carte SD, les versions recentes du firmware ont largement ameliore la stabilite via les reglages sdhost, donc si tu as une image à jour, c'est normalement bon. Par contre, pas de WiFi/Bluetooth integre, prevu un dongle externe qui va bouffer un port USB deja sature.

electro_nov1ce · 2026-10-04

Retour sur la Model B Rev 1 : c'est une piece historique, mais il faut être conscient de ses defauts electriques. Le point fort reste le decodeur H.264 1080p matériel pour 35 dollars, ce qui etait revolutionnaire en 2012. Par contre, attention au polyfuse F1 : un pic de courant sur l'USB le fait sauter et la carte ne s'allume plus correctement, avec des symptomes de sous-tension. Il faut parfois le desouder ou le bypasser, comme indique dans la doc eLinux. De plus, les premières revisions ont une diode D1 qui chute la tension, rendant l'alim instable avec des chargeurs faibles. Si vous avez des coupures, verifiez ce point avant de jeter la carte.

expert-raspberrypi · 2026-08-03

Merci pour le rappel sur le F1, j'ai exactement ce souci. Ma carte ne démarre que si je branche un hub alimente, sinon la LED rouge clignote. J'ai lu qu'il fallait dessouder le fusible, mais je n'ose pas trop. Concernant la D1, est-ce qu'elle est presente sur toutes les Rev 1 ou seulement certaines ? La fiche dit que c'est 'unverified', donc je suppose qu'il faut regarder sur le PCB. Sinon, l'ethernet est vraiment limite a cause du partage de la bande passante USB 2.0, c'est frustrant pour les mises à jour via apt.

maker-du-35 · 2026-08-06

Pour la D1, regarde près du connecteur d'alimentation micro-USB. Si tu vois une diode, tu peux la retirer pour gagner quelques centiemes de volts, utile avec des cables longs. Le vrai problème c'est les 256 Mo de RAM et l'absence de pull-ups I2C sur le header P1, ca oblige a mettre des résistances externes si tu veux brancher des capteurs. Et n'oublie pas que les codecs MPEG-2 ne sont pas actifs sans acheter les cles de licence. C'est une carte de collection maintenant, le support est quasi nul.

linux-pi-legacy · 2026-08-07

Retour sur le Model B Rev 2. C'est la carte ou le design s'est vraiment stabilise avant le passage en B+. Le passage a 512 Mo de RAM pour toujours 35 dollars est un game changer pour l'usage bureau, ca change tout. Le decodage H.264 1080p est toujours aussi solide. Par contre, attention aux variantes ECN. La Rev 2 a perdu ses trous de fixation, ce qui est une horreur pour les boitiers de l'epoque. Et n'oubliez pas que les cles MPEG-2 et VC-1 sont toujours payantes. Pour l'overclocking via config.txt, ca tourne bien si l'alim suit, mais la limitation thermique a 85 degres reste effective. Une carte culte mais fragile.

expert-raspberrypi · 2026-08-08

Je confirme pour les trous de fixation, c'est insupportable de trouver un boitier adapte sans faire des montages bancals. J'ai du bricoler des entretoises. Par contre, j'ai un souci bizarre avec le polyfuse F1. Des que je branche un disque dur externe et la cle USB wifi en même temps, la LED verte clignote et ca reboot. J'ai lu qu'il fallait bypasser F1, mais je crains de griller la carte. Quelqu'un a reussi a stabiliser le bus USB 480 Mbps sans modifier le circuit, ou est-ce inevitable ? La diode D1 sur cette série 2012 me fait aussi peur pour les pertes de tension avec mes cables un peu longs.

maker_toujours_courant · 2026-08-09

Le problème du bus partage LAN9512 est reel. Des que tu fais du transfert de fichiers via le réseau et que tu lis une carte SD, les debits s'effondrent bien en dessous des 100 Mbps theoriques. C'est le goulot d'etranglement de cette generation. Pour le F1, si tu as des coupures, c'est souvent un signe de sous-alimentation, pas forcement le fusible lui-même. Essaie deja un cable micro-USB court et epais. La corruption de la carte SD arrive vite si l'algo se coupe a cause des micros coupures de courant. Garde toujours une sauvegarde sur le PC. C'est le prix a payer pour avoir le Made in Wales a ce prix.

linux_papy · 2026-08-09

Je reviens sur la Nano classique pour clarifier certains points souvent mal compris. C'est vrai que le facteur de forme est imbattable pour le prototypage sur breadboard, avec ses 45x18 mm qui permettent de tout caser sans encombrer le circuit. La capacité complète de l'Uno est là, avec en bonus les entrées analogiques A6 et A7 exposées via le boîtier TQFP. Par contre, ne comptez pas sur le pin 3.3V pour alimenter un module ESP8266 ou un capteur gourmand : avec seulement 50 mA disponibles, vous allez systématiquement déclencher un brown-out dès l'émission radio. Pour la programmation, le comportement du DTR via le FTDI FT232RL est aussi une source fréquente de perte des premiers caractères si vous envoyez une chaîne de config dès le démarrage, car la carte se réinitialise à l'ouverture du port série.

expert-arduino · 2026-07-06

Exactement, et si tu ajoutes les clones à l'équation, ça devient un casse-tête. J'ai reçu une carte vendue comme officielle qui utilisait un chip CH340 au lieu du FTDI, ce qui m'a obligé à chercher des drivers spécifiques sur le site de WCH-IC. Le pire, c'est que le connecteur Mini-USB a lâché au bout d'une quinzaine d'insertions, un vrai défaut de conception pour un usage régulier. J'aurais dû prévoir un connecteur externe ou souder directement des câbles pour éviter cette fragilité mécanique. Est-ce que d'autres ont réussi à stabiliser la connexion série avec les versions à bas coût sans devoir changer le cable USB à chaque fois ?

hacker_minimaliste · 2026-07-10

Merci pour ces précisions sur le 3.3V, je ne savais pas que le courant était si limité et mon module Wi-Fi redemarrait en boucle. Pour le problème de port série, je soupçonne aussi le driver générique Windows de bloquer la communication avec les cartes clones. Je n'ai pas de jack d'alimentation, donc je suis obligé de rester branché en USB ou de souder sur VIN, mais attention à la plage 7-12V qui est plus restrictive que sur l'Uno. Si je dépasse un peu, je risque quoi exactement au niveau du régulateur interne ?

maker_debutant · 2026-07-14

Après quelques semaines d'utilisation de la Nano ESP32, je confirme que c'est une bête de course pour le format Nano : 8 Mo de PSRAM et 16 Mo de flash, c'est rare. Le debug USB-JTAG natif est un vrai plus comparé aux cartes classiques. Par contre, attention aux pièges de démarrage. Si vous voyez deux ports série (USB et DFU), choisissez toujours le port USB pour uploader ; le DFU bloque souvent les envois depuis l'IDE. Et sur Linux, sans les règles udev correctes, vous aurez des erreurs libusb_open en debug. C'est documenté, mais ça surprend les nouveaux arrivants qui viennent de l'Arduino Uno.

expert-arduino · 2026-09-09

Merci pour le rappel sur les ports ! J'ai eu exactement ce souci au début, ça m'a fait perdre une heure. Un truc qui m'a aussi piégé, c'est l'absence totale de pin 5V. Comme je viens des cartes Uno/Mega, je branchais mes capteurs 5V directement en me disant que le convertisseur allait gérer. Résultat : rien ne marche quand on alimente par VIN (6-21V), car le 5V n'est pas régulé, juste passé en USB. Il faut prévoir une alimentation externe pour les modules 5V ou rester en 3.3V. C'est un changement de mentalité important par rapport aux anciens Arduinos.

hobbyiste-tinkering · 2026-09-13

Je confirme le coup du brick facile si on touche au bootloader. J'ai fait une erreur en flashant avec esptool pour effacer la flash entière et j'ai perdu le bootloader DFU d'usine. La carte ne répondait plus aux commandes normales et il a fallu suivre la procédure de support Arduino pour le réinstaller. Avant ça, j'avais aussi des boucles de connexion/déconnexion USB bizarres quand je passais d'un outil à l'autre. L'astuce du double-tap reset sur le bouton aide souvent à récupérer la main, mais c'est frustrant. Assurez-vous de bien utiliser le package 'Arduino ESP32 Boards' et pas celui d'Espressif, sinon vous n'aurez aucun driver.

maker-codeur · 2026-09-14

Retour d'experience sur la Nano Every. C'est clairement l'evolution logique du Nano classique : 48KB de flash et 20MHz contre 32KB et 16MHz, ca change tout pour les sketches lourds. La compatibilite physique du pinout est un vrai plus pour les shields existants. Par contre, attention aux pieges : le PWM sur la pin 11 a disparu (plus de OC0B), donc si votre code utilisait analogWrite(11), ca ne marche plus silencieusement. De plus, l'I2C par defaut est maintenant sur les pins dediees SDA/SCL (22/23) et non plus sur A4/A5. Si vous branchez un shield I2C standard sans bidouiller les fils, vous n'aurez aucune communication. Le module USB n'est pas programmable comme sur les boards 33 IoT, ce qui evite de bricker la carte mais limite les options. Au global, très bon rapport taille/prix pour du 8-bit moderne.

expert-arduino · 2026-09-01

Merci pour le rappel sur la pin 11 ! J'ai passe deux heures a comprendre pourquoi mon contrôleur de moteur ne repondait pas, pensant a un problème d'alim. En lisant la doc, j'ai vu que les pins PWM sont limitees a 3, 5, 6, 9, 10. C'est embetant quand on recycle des vieux codes Arduino. Pour l'I2C, est-ce que la bibliotheque Wire gere automatiquement le switch vers le port secondaire sur A4/A5 si on force l'init, ou faut-il absolument souder des jumpers ou changer les pins dans le code ? Je ne veux pas me retrouver avec des conflits de bus si j'utilise les deux ports.

maker_bricoleur · 2026-09-03

Pour l'I2C, il faut vérifier la lib megaavr, mais en general le port primaire est bien sur les pins dediees. Le plus chiant c'est la bibliotheque de servo ou certains drivers RF qui utilisent les timers differents du core megaavr. J'ai du mettre à jour plusieurs libs qui tournaient sur mon ancien Nano. Sinon, le format sans headers est genial pour integrer dans des boitiers serres, sous 5g c'est imbattable. Juste assurez-vous d'avoir un outil pour souder proprement, la face B est plate et sans composants, mais les pads sont petits.

hobbyiste_avr · 2026-09-06

Retour sur la NanoPi R5S après quelques mois. Le concept de routeur avec 2x 2.5GbE (RTL8125BG) et 1x GbE WAN est solide, et le slot M.2 NVMe change tout par rapport au SD card des R4S. Cependant, attention aux pièges du début. La performance du 2.5G a été médiocre au lancement (CNX mesurait ~1.85 Gbps Tx), mais les firmwares récents ont corrigé cela via des optimisations d'interrupts. Sous mainline, le port WAN a été cassé longtemps : il faut impérativement un kernel incluant les fixes gmac support et reset-pin (merged avril 2026). Si vous utilisez un noyau entre 2023 et 2026, vérifiez que le phy-supply est bien défini, sinon pas de lien. Enfin, n'oubliez pas que l'alim USB-C doit être PD (Power Delivery) : les chargeurs rapides non-PD causent des délais de boot ou des échecs complets.

expert-pi-like · 2026-08-06

Merci pour ce résumé. Je confirme le souci d'alimentation : j'ai perdu une après-midi à comprendre pourquoi elle ne démarrait pas systématiquement avec un vieux chargeur 5V/2A standard. Il a fallu passer à un chargeur PD 12V pour que ce soit stable. Par contre, j'ai une question sur le débogage. Le header UART demande du 1.5 Mbps, ce qui est élevé. J'ai un convertisseur CP2102 classique, il plafonne à 921600. As-tu réussi à accéder à la console de démarrage avec autre chose ? J'ai peur de rester bloqué au bootloader si je dois reflasher via Maskrom, sachant que le port OTG est sur l'USB-A et non le USB-C, ce qui est contre-intuitif.

hacker-du-coin · 2026-08-07

Pour le USB-UART, le CP2102 suffit souvent si on force la vitesse dans le terminal (putty ou minicom), mais il perd des caractères à 1.5 Mbps. Un FT232H ou un CP2102N récent est plus fiable. Sinon, pour le reflash, si tu as un écran HDMI, c'est plus simple. Le vrai piège restant concerne les LEDs : sous les kernels récents (6.17+), les triggers netdev ont été retirés du DT. Donc ne compte pas sur le clignotement des LEDs LAN/WAN pour voir le trafic si tu es sur une distro très à jour, ça a été retiré par rapport aux images vendor FriendlyWrt. C'est du détail, mais ça aide au diagnostic physique.

linux-router-01 · 2026-08-08

Bonjour a tous. J'ai passe pas mal de temps sur la Nicla Sense ME (ABX00050) et je voulais clarifier un point frequent : elle n'a pas de BMI088. Le set est bien BHI260AP, BMM150, BMP390 et BME688. Attention aussi au conflit de doc, le site parle de BLE 4.2 mais c'est bien du 5.0 via l'ANNA-B112. C'est une carte puissante avec ses 2 Mo de flash et l'IA embarquée, mais la prise en main est delicate. La programmation via le SAMD11 est capricieuse, si le pont plante, la carte devient invisible pour l'IDE. J'ai aussi rencontre le bug ou l'upload échoue si le chemin contient un espace. Ne vous fiez pas aveuglement a l'ADC, la reference est 1.8V, pas 3.3V.

expert-arduino · 2026-07-21

Merci pour ce retour, ca confirme mes doutes. J'ai justement eu la carte invisible via USB après une coupure de courant. J'ai du reflasher le bootloader en suivant un vieux tuto, mais c'est loin d'être intuitif. Concernant la partie capteurs, j'utilise le mode I2C esclave avec un Portenta, mais j'ai des hang intermittents de l'hote. As-tu rencontre le problème ou la carte coupe l'alim ESLOV après une minute d'inactivite ? J'ai du ajouter un petit ping regulier dans ma boucle pour eviter que le LDO ne se desactive completement.

maker-sensor · 2026-07-22

Oui, le timeout du LDO est un piege classique, il faut bien utiliser BHY2.setLDOTimeout si tu veux garder l'ESLOV actif. Pour ma part, je galere avec la calibration de la fusion BSX. Le capteur d'orientation (ID 70) renvoie souvent 0.000 au démarrage et met du temps a se stabiliser. C'est frustrant quand c'est destine a du suivi de geste precis. Y a-t-il une sequence spécifique pour forcer la recalibration sans devoir tout réinitialiser ? Le mode autonome est top pour la memoire de 2 Mo, mais la connectivite BLE via ArduinoBLE reste instable chez moi.

algo-piou · 2026-07-23

Retour sur la Nicla Vision après plusieurs mois d'utilisation. Le format 22x22mm est bluffant pour une intégration embarquée, et la puissance du dual-core STM32H747 (M7 480MHz + M4) permet de faire tourner du vision assez réactif. Par contre, attention aux pièges documentés. Le bug de compilation avec le fichier Blink_Nicla.ino est toujours présent : la définition de Mode dans RGBled.h entre en conflit avec mbed, ce qui casse la compatibilité si on utilise InterfaceCAN. Autre point critique : la RAM interne est limitée. Le buffer caméra ne dépasse pas le QVGA (320x240) sans SDRAM externe, or la carte n'en a pas. Si vous espérez du HD, c'est mort. La batterie tient bien, mais vérifiez bien vos schémas pour l'alim LiPo.

expert-arduino · 2026-09-18

Salut, merci pour ce retour très clair. Je bute justement sur le problème de l'RTC. J'ai lu que le calendrier se réinitialise à chaque hard reset à cause du bootloader qui force le LSI au lieu du LSE. C'est super gênant pour logguer des données horodatées en mode autonome. Est-ce qu'il y a un workaround propre via le code Arduino ou il faut flasher un bootloader custom ? Je ne veux pas toucher au fuse bits si possible. Et pour la caméra, les artefacts dans les exemples de capture sont-ils fixés dans les dernières libs ?

maker_bob_42 · 2026-09-19

Pour l'RTC, non, il n'y a pas de solution logicielle propre dans l'IDE standard car le bootloader MCUBOOT est configuré avec lse_available=false. Ta seule option fiable est de flasher un bootloader modifié ou d'utiliser une fonctionnalité qui corrige la source d'horloge en dur, mais c'est risqué. Pour la caméra, les glitches de frames (endianness/serial) dans CameraCaptureRawBytes restent un problème ouvert sur GitHub depuis 2022. J'ai contourné en augmentant les délais de lecture série, mais c'est du bricolage. La carte reste excellente pour le ML embarqué grâce au capteur IMU, mais la gestion des images reste limitée par cette RAM interne.

vision_hacker · 2026-09-21

Retour sur la nRF52840 Feather. C'est la carte de choix si vous voulez du BLE avec CircuitPython, car c'est le seul SoC courant avec assez de RAM et USB natif. Attention toutefois aux pièges matériels. Si votre bootloader est antérieur à la v0.6.1, les mises à jour UF2 récentes comme CircuitPython 8.2.0 peuvent bricker la carte. Vérifiez toujours INFO_UF2.TXT avant de flasher. Autre point critique : le bug SPIM3 sur batterie. Si vous alimentez par USB, ça passe, mais en batterie, l'objet SPI par défaut ne marche pas correctement à cause de l'absence de VUSB. Il faut utiliser le workaround d'Adafruit qui ignore le premier objet alloué. Enfin, gardez en tête que le SoftDevice a la priorité sur tout, donc le temps réel dur est impossible avec le BLE activé.

expert-microcontroleur · 2026-04-25

Merci pour ces précisions, ça m'évite des heures de debug. J'ai justement galéré avec le SPI sur batterie, je pensais à un problème de code Python mais c'était bien le hardware. Par contre, je bute sur le schéma Rev D. J'ai lu l'errata concernant le silkscreen D5 vs A6, mais je ne suis pas sûr de comprendre l'impact. Si je câble selon l'impression sérigraphie, je risque quoi concrètement ? Un court-circuit ou juste un pin inactif ? Et pour le red LED, j'ai vu la confusion entre pin 3 et 13 dans la doc, j'ai fini par utiliser LED_BUILTIN pour ne pas dépendre des numéros physiques, c'est la bonne approche ?

maker_bricoleur · 2026-04-27

Pour l'errata D5/A6, c'est une erreur d'étiquetage sur le PCB, pas un défaut de routage électrique. Le signal est bien là où il doit être, mais si tu te fies au texte sérigraphié pour identifier le pin A6, tu vas te tromper et souder sur le mauvais endroit. Utilise Always la doc technique ou les schémas plutôt que le silkscreen. Concernant le red LED, oui, LED_BUILTIN est la seule constante fiable qui marche sur les deux versions, car les numéros de pins changent entre la Express et la Sense. Évite aussi les câbles USB bon marché qui sont souvent en charge seule, ça empêche le mode bootloader de se déclencher, ce qui est très frustrant quand on essaie de flasher via UF2.

dev_embedde · 2026-04-29

Bon retour sur l'ODROID-C2. C'est une bête de 2016 mais elle tient bien la route pour du réseau. Les points forts sont réels : le port Gigabit Ethernet réel (RTL8211F, pas d'USB bridge) change tout comparé aux Pi 3 de l'époque, et le décodage H.265 4K via le Mali-450 est efficace en multimédia. Par contre, attention aux pièges documentés. Le slot microSD est bridé en mainline à 100 MHz (SDR50/100 seulement), donc Oubliez la UHS-I rapide, ça rame. La solution est impérativement le module eMMC. Aussi, la consommation est exigeante : il faut un vrai 5V/2A via le jack barrel 2.5x0.8mm. Les alimentations micro-USB font souvent des brown-outs. Enfin, le GPU n'est pas supporté en mainline sans blobs propriétaires, donc le bureau est lent sur Armbian/DietPi actuels. C'est une carte réseau ou média center, pas un desktop moderne.

expert-pi-like · 2026-04-29

Merci pour ce résumé. J'ai justement un souci avec l'alimentation. J'utilisais un chargeur USB standard via le port OTG pour gagner de la place, mais ça reboote aléatoirement dès que je branche un dongle Wi-Fi. Tu confirmes que le port OTG est trop marginal pour les périphériques USB ? J'ai vu que le hub GL852G consomme pas mal. Je vais passer au jack barrel comme tu dis, mais je cherche une alim compacte qui tienne vraiment les 2A sous charge.

maker-bricoleur · 2026-05-02

Oui, le port OTG met le hub et les ports USB sur la même ligne électrique, c'est très instable avec des périphériques. Pour le Wi-Fi, n'oublie pas qu'il n'y a rien d'intégré, il faut un dongle USB qui bouffe un des 4 ports. Si tu veux du réseau stable, le GbE est parfait mais vérifie bien tes câbles. Autre point : le capteur thermique n'est pas supporté en mainline (U-Boot dit 'No' pour le thermal sensor), donc pas de throttling logiciel visible. Surveille les températures physiquement si tu l'utilises en boîtier fermé. C'est une carte 'legacy' maintenant, mais Armbian la maintient bien.

linux-meson-fan · 2026-05-04

Retour d'experience sur l'ODROID-C4. Le rapport qualite/prix est reel : a 50 dollars avec le dissipateur inclus, on a un vrai GbE, 4x USB 3.0 et surtout un socket eMMC, chose inexistante sur le Pi 4. Les extensions crypto ARMv8 donnent des gains enorms sur le chiffrement. Par contre, attention aux pieges. Pas de Wi-Fi embarque, il faut payer les 8.90 dollars pour le module mSOTA+. Le plus vicieux concerne les tensions sur le header 40 pins : tout est en 3.3V sauf les entrées ADC limitees a 1.8V. Une erreur de cablage analogique peut griller le SoC. Enfin, le fréquence CPU prete a confusion car certaines images par defaut restent bridees a 1.5GHz alors que la puce supporte 2.0GHz. Verifiez votre reglage cpufreq.

expert-pi-like · 2026-09-07

Merci pour le rappel sur les ADC. Je confirme le souci de fréquence. J'ai utilise une image Hardkernel officielle et j'ai du passer par des scripts pour atteindre les 1.908GHz max autorises par le noyau. Le kernel 4.9 fourni en usine est legacy et pose des problèmes avec les modules modernes. Pour mon usage serveur 24/7, j'ai bascule sur Armbian. La consommation est très basse, environ 1.8W au repos, ce qui est parfait pour un boitier passif. Le seul blem est l'absence de HS400 sur le noyau principal, l'eMMC plafonne donc a HS200. Si tu cherches de la performance brute en stockage, il faut accepter cette limitation ou rester sur le vendor.

maker-sol · 2026-09-11

Petite question sur la section materielle. Tu mentionnes que l'OTG USB ne fournit pas d'alimentation. J'ai voulu alimenter via un cable USB-C pour tester une config portable sans prise secteur, et effectivement, ca ne démarre pas. Faut imperativement le jack barrel. Concernant le module Wi-Fi 5BK a 8.90 dollars, est-ce que la portee est correcte ? J'ai peur que le format mSOTA+ soit trop petit pour une bonne antenne. Sinon, je confirme que le refroidissement passif suffit largement tant qu'on ne lance pas de taches lourdes en continu.

hobby-tweak · 2026-09-14

Petit bilan sur l'ODROID-M1 après quelques mois d'utilisation. Le point fort incontestable reste le stockage : le port M.2 NVMe en PCIe 3.0 x2 est vraiment rapide, on atteint les 1600 Mo/s annoncés, ce qui écrase tout ce qu'on peut faire sur un Raspberry Pi CM4. C'est un vrai atout pour un NAS ou un mini-serveur. La présence du SATA natif (attention, 5V seulement, donc pas de 3.5 pouces sans alim externe) et de l'eMMC offre une flexibilité rare à ce prix. Par contre, méfiez-vous des images officielles qui tournent encore sous un noyau 4.19 BSP. Si vous voulez du mainline pour du Panfrost ou des drivers modernes, il faut compiler soi-même ou chercher des builds communautaires. Le switch SPI Boot Select est aussi un piège classique : si vous laissez Petitboot actif, le boot sur SD/eMMC ne se comporte pas comme attendu. Ça m'a coûté une soirée de débogage.

expert-pi-like · 2026-09-21

Merci pour ce retour. Tu confirmes bien que le format n'est pas du tout Pi-like en réalité ? J'ai vu les dimensions (122x90mm) et le radiateur qui dépasse, ça va me poser problème pour mon boîtier existant prévu pour un Pi 4. De plus, l'absence de WiFi/Bluetooth embarqué est un peu frustrante, on est obligé de sacrifier un port USB ou d'acheter le dongle Hardkernel. Est-ce que le support mainline est stable aujourd'hui pour l'audio, ou on a toujours les soucis de pincmux RK817 dont tu parlais ?

makershadow · 2026-09-23

Exact pour les dimensions, le radiateur fait 123x100x19mm, ça ne rentre dans aucun boîtier standard Pi. Pour l'audio, le bug de pincmux I2S1 qui tuait le codec RK817 sur mainline a été corrigé récemment (octobre 2025), donc si tu as un noyau à jour, l'audio fonctionne. Mais sur les vieilles images ou les noyaux non patchés, tu auras des erreurs pinctrl et pas de son. Pour le WiFi, oui, c'est USB uniquement, pas de solution interne. Le gros avantage reste la stabilité une fois le bon noyau installé : le GPU Mali-G52 tourne bien via Panfrost une fois qu'on quitte le 4.19. Juste assure-toi de vérifier la tension de ton alim, ils recommandent du 12V 2A via le jack DC, pas le USB-C qui est absent ici.

expert-pi-like · 2026-09-26

Retour d'expérience sur l'ODROID-N2. C'est une bête de somme côté CPU avec ses 4x A73, mais attention aux pièges. Le conflit de brochage entre le SPI NOR et les lignes D4-D7 de l'eMMC est réel : si vous voulez booter depuis la flash SPI, il faut impérativement modifier le device tree pour passer en bus 4 bits et vérifier la position du switch SW1, sinon rien ne marche. Autre point noir historique : le gap GPU. Pendant des années, le Mali-G52 était limité au framebuffer sans accélération X11/Wayland sérieuse, jusqu'à l'arrivée de Panfrost. Sous Armbian, n'oubliez pas de blacklister le module simpledrm, sinon il prend la main sur l'affichage avant Panfrost et vous perdez l'accélération. Sinon, la dissipation passive est excellente, surtout sur le N2+ Rev-C qui tient 2.4GHz sans thermique problématique à 35°C ambiants.

expert-pi-like · 2026-07-12

Merci pour le rappel sur le SPI, j'ai perdu une soirée à cause du switch mal positionné. J'ai une question précise sur la stabilité. J'ai lu des notes sur des freezes aléatoires après 24h+ de fonctionnement sous charge. Est-ce que c'est lié à la gestion du cpufreq ? On m'a suggéré de forcer le governor en 'performance' pour éviter les instabilités OPP sur le big.LITTLE, mais ça me parait brutal comme solution. Tu as constaté ça sur tes boards N2 ou N2+ récente ?

hacker-du-geek · 2026-07-16

Oui, confirmer pour le governor. Sur ma N2 avec une image récente, mettre le governor en 'userspace' ou 'performance' a stabilisé les longues sessions. Le problème vient souvent de la bascule entre les coeurs A73 et A53. Par contre, évite le stockage sur microSD si possible, prends l'eMMC, la différence de latence est énorme. Et si tu fais du media center, le décodage 4K H.265 est nickel, c'est vraiment son point fort pour le prix, bien que l'absence de WiFi intégré soit pénible selon l'usage.

maker-serein · 2026-07-17

Après plusieurs années en cluster, je confirme les points forts de la XU4 : le débit USB 3.0 et le Gigabit Ethernet (880 Mbps réels) restent imbattables pour le prix d'une carte ARMv7. La compatibilité avec les images Armbian 6.6 est excellente. Par contre, attention au piège thermique : sans le ventilateur actif, le throttling est immédiat sur les coeurs A15, perdant 16% de perfs par rapport à la version refroidie. Et surtout, ne branchez jamais un adaptateur UART 5V sur le header console, c'est du 1.8V sans protection IO, j'ai vu des cartes griller instantanément. Le GPU Mali T628 gère l'OpenCL 1.2 mais se déclare comme deux devices distincts, ce qui casse certains scripts de calcul.

expert-pi-like · 2026-05-26

Salut, petite question pour ceux qui l'utilisent en NAS. Tu mentionnes la topologie USB partagée. J'ai deux SSD sur les ports USB 3.0 et j'ai l'impression que leurs perfs chutent sévèrement quand je fais des transferts réseau simultanés. Est-ce que c'est lié au hub GL352x intégré ou au fait que le contrôleur Ethernet soit aussi sur un bus USB interne ? J'ai peur que la bande passante soit trop limitée pour du RAID logiciel.

maker-artisan · 2026-05-29

C'est exactement le problème documenté par mdel et tkaiser. Le GbE monopolise un hôte USB 3.0, et les deux ports externes partagent l'autre hôte via le hub. Donc si tu satures l'Ethernet, tu as déjà un impact, et si tes deux SSD sont sur le même hôte, ils se partagent la même ligne. Pour du NAS sérieux, il vaut mieux éviter de saturer les deux ports USB simultanément si tu veux garder des débits corrects. L'eMMC HS400 est bien plus stable pour le système, les USB pour le stockage externe peuvent vite devenir le goulot.

linux-tinker · 2026-05-30

Retour après quelques semaines sur l'Opta. La certification micro-PLC est reelle, ca change tout par rapport a un MKR classique. Les entrées 24V directes sont super pratiques, plus besoin de cartes conditionneuses. Par contre attention : le USB-C ne fait pas tourner les relais, il faut absolument le 12-24VDC sur les borniers pour la partie puissance. J'ai aussi note le conflit I1/I4 pour les interruptions, impossible de les utiliser en même temps, ca m'a coute une soiree de debug. Pensez a ajouter des résistances de terminaison externes pour le RS-485 sinon ca bugue. Le module OPC UA est bien present dans les exemples, c'est un vrai plus pour l'industrie.

expert-arduino · 2026-08-25

Merci pour le retour. Je debute et je suis un peu perdu avec le noyau. Tu parles de la migration vers Zephyr ? Actuellement je suis sous arduino:mbed_opta et j'ai peur de casser mes scripts en mettant à jour. Est-ce que la doc officielle est claire sur la compatibilite future ? Et pour le BLE, j'ai lu que le matériel est 5.1 mais le firmware 4.2, est-ce que ca pose des souci concretement pour de la domotique simple ou c'est transparent ?

hobb-iste-77 · 2026-08-28

Pour le BLE, si tu fais du simple capteur/tempo, la difference 4.2/5.1 est souvent invisible, sauf si tu as besoin de longue portee spécifique. Le vrai piege c'est la duree de vie des relais : 10k cycles a 10A resistif. Si tu commutes des charges inductives (moteurs, vannes) sans protection externe, tu vas griller les contacts vite. Il faut des fusibles et eventuellement des varistances. Ne comptez pas sur la protection interne, elle est minimale. La fiche technique est explicite la-dessus, ne vous faites pas avoir en pensant que c'est du tout-terrain industriel sans precautions.

maker-indus · 2026-08-30

Retour d'expérience sur l'Orange Pi 3B. Le format Pi 3B avec le slot M.2 intégré est vraiment le point fort pour transformer un boîtier existant. Attention toutefois, le slot est limité au PCIe 2.1 x1, donc ne comptez pas sur les débits d'un SSD Gen4, c'est plafonné autour de 500 MB/s théoriques. J'ai aussi constaté que l'I2C sur les broches du header (pins 3/5) ne fonctionnait pas nativement avant le patch de novembre 2025. Si vous êtes sous un noyau entre 6.11 et 6.17, il faut absolument créer un overlay sinon vos capteurs ne répondront pas. La gestion des deux révisions matérielles (v1.1 et v2.1) est aussi un piège : si vous flashez le mauvais device tree, l'Ethernet ou le WiFi peuvent rester muets. Pensez à vérifier votre silkscreen.

expert-pi-like · 2026-07-05

Salut expert-pi-like, merci pour ce retour. Justement, je débute avec une v2.1 et j'ai galéré au démarrage. Je pensais que mon module NVMe était HS mais en lisant les tickets Armbian, j'ai vu qu'il y avait un souci de prefixe d'overlay et qu'il fallait parfois deux images U-Boot différentes selon qu'on bootait sur SATA ou NVMe. As-tu eu ce problème de double image ou est-ce que les versions récentes d'Armbian ont corrigé ça avec le PR #10896 ? Ça m'a fait perdre une après-midi à comprendre pourquoi ça bootait en SATA mais pas en NVMe avec la même config.

maker-du-93 · 2026-07-09

Pour compléter, si vous passez sous mainline (pas le kernel vendor), préparez-vous à chasser les firmware WiFi. Le module AP6256 (BCM43456) nécessite les fichiers brcmfmac43456-sdio spécifiques. J'ai eu la carte wifi qui disparaissait après une mise à jour du noyau car le fichier NVRAM correspondant au match xunlong manquait. Il faut vérifier dans /lib/firmware/brcm/. Aussi, petite précision : la fiche dit 5V/3A pour l'alim USB-C. N'essayez pas de réduire, avec un SSD NVMe et quelques périphériques USB, une alimentation 5V/2A peut être insuffisante, même si aucun minimum officiel n'est clairement affiché pour le boot léger.

linux-ouin-ouin · 2026-07-12

Sur l'Orange Pi 5 Plus, le piège classique est l'alimentation. Il y a deux ports USB-C identiques, mais seul celui près des RJ45 alimente la carte. L'autre est pour les données. De plus, évitez les chargeurs PD génériques : la spec officielle exige du 5V/4A. Un mauvais adaptateur provoque des coupures quand tout est branché. En revanche, les deux ports 2.5GbE RTL8125BG sur PCIe sont excellents pour du routage, et le slot M.2 M-Key en PCIe 3.0 x4 est un vrai plus pour la rapidité. Pensez juste au refroidissement actif, les seuils thermiques sont bas.

expert-pi-like · 2026-05-28

Merci pour ces détails sur l'alim. J'ai reçu la mienne et je bute sur l'audio. Je n'ai aucun son dans le casque avec la dernière image Armbian Mainline. Est-ce un défaut de ma carte ou un problème connu ? J'ai vérifié les branchements physiques plusieurs fois, rien ne change. Par contre, pour la partie réseau, je confirme que le boot sur NVMe via l'adaptateur M.2 fonctionne bien, c'est fluide. Mais si je passe par la carte SD pour tester, attention à ne pas dépasser 128 Go, la doc le précise et ça peut surprendre.

maker-newbie · 2026-05-30

C'est normal pour l'audio, ne cherche pas plus loin. La détection de casque était inversée dans le Device Tree jusqu'à Linux 6.17. Il faut flasher une image basée sur un noyau récent pour que ça marche. Tant que tu es sur une version antérieure, même si tu branches le casque, le système ne le voit pas correctement. C'est un bug corrigé, mais si tu utilises des images un peu anciennes, ça revient. Pour le reste, si tu veux du Wi-Fi, n'oublie pas qu'il n'y a pas de module embarqué, il faut absolument acheter un module M.2 E-Key type AP6275P.

linux-hacker-99 · 2026-05-31

Retour d'experience sur l'Orange Pi PC après plusieurs mois d'utilisation. Le rapport qualite-prix reste imbattable pour un quad-core A7, surtout avec les images Armbian qui sont bien maintenues. Le connecteur CSI et le micro integre sont des bonus appreciables a ce prix. Par contre, attention au piege classique : le port micro-USB OTG ne sert pas a alimenter la carte. J'ai vu des debutants griller leur alimentation en essayant de brancher un cable standard. Il faut imperativement utiliser le jack DC 5V. De plus, l'ethernet est limite a 100 Mbps, ce qui est frustrant si on heberge des services lourds. La gestion thermique est aussi juste sans ventilateur sur les charges soutenues, le H3 chauffe vite.

expert-pi-like · 2026-06-02

Merci pour ces precisions sur l'alimentation, je pensais pouvoir gagner de la place en utilisant le micro-usb comme sur d'autres boards. J'ai une question sur le header GPIO : tu mentionnes la compatibilite Raspberry Pi. Est-ce que les HATs officiels fonctionnent out-of-the-box ? Je voudrais brancher un petit ecran SPI. J'ai lu que certains pins de puissance pouvaient envoyer du 5V ou plus si mal configure, est-ce que c'est un risque reel sur cette version ou c'etait surtout sur les modèles précédents ? Je ne veux pas cramer mon peripherique avant même de tester le code.

maker-du-44 · 2026-06-05

Pour le header, la mecanique est compatible mais la mise en oeuvre electrique demande de la vigilance. Comme le souligne expert-pi-like, la documentation officielle est parfois confuse. Sur ma version, j'ai du vérifier chaque pin au multimetre. Certains pins etiquetes VPP peuvent fournir une tension superieure a 3.3V selon la configuration du boot ou les reglages du PMIC SY8106A. Ne te fie pas aveuglement aux tutos Raspberry Pi. Pour l'OTG, confirme ce que dit expert-pi-like : c'est uniquement pour le mode gadget ou l'OTG peripherique, jamais pour l'alim. Si tu veux utiliser l'IR receiver, assure-toi que le driver est bien compile dans ton image Armbian, il est present mais parfois desactive par defaut dans certain builds legacy.

linux-tinkerer · 2026-06-06

Retex sur la Boron BRN404X. La promesse cloud est tenue, le handshake TLS est fluide. Mais attention aux pièges physiques documentés. Le connecteur U.FL est extrêmement fragile, ne jouez pas à le débrancher souvent, vous risquez de détruire la radio. Idem pour le port micro-USB qui se dérobe facilement. Point critique : la gestion de l'alimentation via la broche EN. Si vous alimentez des GPIOs externes quand la carte est éteinte, des pull-ups peuvent empêcher l'arrêt complet ou le reset. Utilisez impérativement un MOSFET open-drain. Enfin, vérifiez la polarité de votre LiPo avant branchement, la datasheet insiste là-dessus, une inversion peut être fatale. C'est une bonne carte pour le prototypage rapide grâce aux FeatherWings, mais exigeante en intégration.

expert-microcontroleur · 2026-07-03

Merci pour le rappel sur l'EN pin, j'ai perdu deux semaines à comprendre pourquoi ma carte ne dormait jamais vraiment, restant autour de 0.6 mA au lieu des valeurs ULP attendues. C'était exactement ton cas de figure avec un niveau haut externe. Autre souci rencontré : après une mise à jour OTA sous Windows 11, le port série a disparu du gestionnaire de périphériques. Il a fallu changer de câble et reinstallé les drivers Particle. C'est pénible quand on est en plein debug. As-tu constaté des soucis de recharge LiPo avec les versions récentes de Device OS ? J'ai lu des threads sur une coupure de charge silencieuse après la version 1.5.0, je veux m'assurer que ce soit corrigé avant de valider mes boîtiers scellés.

maker_bidouille · 2026-07-05

Concernant la recharge, ça semble stable sur les dernières releases, mais surveille bien la température du PMIC TI. Pour les boîtiers scellés, garde en tête qu'il n'y a pas de version castellée pour la Boron complète, seulement les modules E-Series. Si tu passes en production, prévoir le socket ou basculer vers les modules SMT. Et n'oublie pas la fragilité du connecteur JST côté batterie, renforce-le si le câble bouge. La gestion du réseau est top pour le Nord-Amérique, mais si tu vises l'Europe, sache que la certification LTE Cat M1 n'est pas faite, il faudra passer par des solutions tierces ou vérifier les bandes supportées manuellement car tout n'est pas activé par défaut dans le firmware.

iot_embedded_fr · 2026-07-06

Retour d'experience sur la Photon après quelques mois. La simplicite du cloud Particle est reelle, le setup Soft AP fonctionne bien et l'architecture STM32F205 @120MHz offre une bonne puissance de calcul pour ce prix. Les peripheriques comme le CAN et les 2 DAC sont rares a ce niveau. Attention toutefois a deux pieges classiques. D'abord, n'oubliez pas que les paires A5/D2 et A4/D3 partagent des timers PWM, vous n'avez donc que 7 sorties independantes et non 9. Ensuite, l'alimentation est critique : une mauvaise cable USB cause des brown-outs lors des pics de transmission Wi-Fi. Il faut vraiment une source stable d'environ 1A. Le 3V3 delivre par la carte est très limite a 100mA, ne comptez pas dessus pour piloter des capteurs gourmands sans un LDO externe.

expert-microcontroleur · 2026-04-30

Merci pour ces precisions. Je suis en train de prototyper un petit objet connecté et je bute sur un problème de consommation en veille. J'ai lu dans la datasheet une valeur de ~80 microampere en deep-sleep, mais sur mon premier exemplaire, la batterie se vide en 1 jour alors que sur deux autres identiques, cela tient 30 jours. Est-ce que c'est un defaut courant ou un mauvais reglage ? J'ai essaye de couper les LEDs mais le courant reste eleve sur la carte 'mauvaise'. J'ai aussi lu que les pads de coexistence Bluetooth sont inutilisables, donc je ne peux pas m'appuyer dessus pour diagnostiquer une fuite la.

maker-debutant-42 · 2026-05-01

Le problème de variance de consommation de sommeil est documente par d'autres, comme le montre le thread sur le forum officiel ou trois Photons avaient des comportements totalement differents. Cela peut venir de composants de la chaîne d'alimentation ou de la carte elle-même. Verifie aussi que tu n'as pas laisse la LED RGB active ou des GPIO flottants. Pour les brown-outs dont parle expert-microcontroleur, si tu alimentes par VIN avec des fils longs, ajoute une capa electrolytique et un zener 5.1V comme recommande, sinon tu risques des pics de tension qui abiment la carte. Et si tu deploies un parc, attention a la fin de support des anciennes versions de Device OS, reste sur la branche 2.x LTS.

tech-sauvage · 2026-05-04

Retour d'experience sur la Pico après plusieurs mois d'utilisation. Les points forts sont reels : le prix de 4 USD est imbattable pour un dual-core M0+ a 133 MHz (certifie 200 MHz sur les rev laterales) avec 264 KB de SRAM. La liberte materielle est totale, tout est open source. Cependant, attention aux pieges documentes. Le convertisseur ADC est mediocre sans traitement logiciel : il souffre d'un offset inherent d'environ 30 mV lie a la reference 3.3V interne et au bruit du SMPS. Il faut souvent forcer le mode PWM sur GPIO23 ou soustraire un offset via un canal a la masse pour obtenir des mesures correctes. De plus, la puce n'a pas de FPU, donc tout calcul flottant est emule en logiciel, ce qui ralentit considerablement les operations complexes. C'est une carte fantastique pour l'IO via les PIO, mais pas pour le traitement numérique lourd.

expert-raspberrypi · 2026-08-15

Bonjour expert, je debute avec la Pico et je bute sur un souci d'alimentation. J'ai lu que les broches GP26 a GP28 ne sont pas 5V tolerantes, ce qui est logique, mais j'ai aussi vu dans la datasheet une note sur une diode inverse vers l'IOVDD. Est-ce que cela signifie que si j'applique une tension sur ces broches ADC alors que la carte est eteinte, je risque d'alimenter le rail 3V3 et d'endommager le reste ? Je veux connecter un capteur 5V via un pont diviseur, mais je ne veux pas griller la carte en cas de debranchement en charge.

maker_tinker · 2026-08-16

@maker_tinker Oui, c'est exactement ca. La datasheet est claire : appliquer une tension sur GP26-GP29 quand la Pico est hors tension peut back-powerrer le rail 3V3, ce qui est dangereux pour le MCU. Pour ton capteur 5V, utilise un diviseur de tension propre passe par des resis, mais assure-toi que ton circuit externe ne peut pas injecter du courant dans la carte quand elle est off. Sinon, un MOSFET en série sur l'alim du capteur est la solution la plus sure. Concernant l'ADC, confirme aussi l'astuce de la datasheet : met le SMPS en mode PWM via GPIO23 si tu veux un bruit reduit, sinon le mode PFM par defaut cree des pics qui brouillent tes lectures faibles.

pio_wizard · 2026-08-20

Après quelques semaines avec la Pico 2, le saut en performances est réel grâce au RP2350, surtout pour ceux qui veulent tester le RISC-V (Hazard3) sans exploser le budget. Attention tout de même si vous avez acheté une carte avant mi-2025 : l'erratum RP2350-E9 sur les GPIO Bank 0 est bien présent. J'ai eu des lignes qui restaient à 2.2V en entrée, il a fallu ajouter des résistances de pull-down de 8.2kΩ pour stabiliser. C'est corrigé sur les steppings A3/A4, mais vérifiez bien votre révision. Autre piège classique : si vous activez le secure boot, vous perdez l'accès aux cœurs RISC-V, c'est binaire. Et n'oubliez pas que pour le mode USB Host, il faut alimenter VBUS en 5V, sinon ça ne marche pas.

expert-raspberrypi · 2026-04-26

Merci pour le retour. Je bute justement sur un souci d'ADC imprécis, les valeurs bougent pas mal avec la température. Tu confirmes que c'est lié à l'alim SMPS interne ? J'ai lu qu'il y avait un offset d'environ 30mV. Est-ce que la solution du LM4040 sur ADC_VREF est obligatoire pour du capteur analogique fiable, ou un simple filtrage logiciel suffit ?

maker_debutant · 2026-04-28

Le filtrage logiciel ne gère pas l'offset physique dû au courant de l'ADC qui tire sur la référence SMPS. Le datasheet recommande clairement une référence externe type LM4040 si tu veux de la précision. Et attention, si tu utilises une version de MicroPython antérieure à la 1.24.0 ou le Pico SDK < 2.0.0, ça ne flashera même pas, vu que le support n'a été ajouté que récemment. Ça m'a fait perdre une après-midi à chercher pourquoi mes scripts RP2040 ne passaient pas.

codeur_embed · 2026-05-01

Retour d'experience sur la Pico 2 W. Le prix de 7 dollars est imbattable pour avoir du Bluetooth Classic et du BLE 5.2, mais attention aux pieges materiels. Si vous avez un lot d'arrivee, verifiez la revision du silicon RP2350. Les premières versions (E9) souffrent d'une fuite de courant sur les GPIO Bank 0 quand les pins sont en entrée, pouvant bloquer les niveaux a 2.2V. Il faut des résistances de pulldown externes sous 8.2kOhm. C'est corrige sur les steppings A3/A4 announces en juillet 2025. Autre point lourd : le clignotement LED. Oubliez votre code Pico habituel sur GP25. Ici, GP25 est le Chip Select du module WiFi. Si vous togglez GP25, vous coupez la radio. Utilisez la fonction cyw43_arch_gpio_put pour la LED. C'est contre-intuitif mais documente dans les exemples picow_blink.

expert-raspberrypi · 2026-08-04

Merci pour le rappel sur GP25, j'ai perdu une heure a comprendre pourquoi mon module radio ne repondait plus des que je touchais a la LED. J'ai une question sur la mesure de tension. Je veux surveiller ma batterie via l'ADC, mais j'ai lu que GP29 est partage avec l'horloge SPI du WiFi. Est-ce que je peux lire la tension n'importe quand ? J'ai l'impression d'avoir des valeurs aléatoires quand le WiFi est actif.

makers_bidouilleur · 2026-08-04

Exactement, c'est une collision materielle connue. GP29 porte a la fois le signal VSYS/3 pour l'ADC et l'horloge SPI du module无线. Vous ne pouvez lire la tension que lorsqu'aucune transaction SPI n'est en cours. Si vous essayez de lire pendant que la radio communique, vous obtenez des ordures. Dans le SDK, il faut absolument encapsuler vos lectures ADC dans les fonctions cyw43_thread_enter et cyw43_thread_exit pour securiser l'acces. Sinon, la lecture est invalide. C'est le prix a payer pour integrer la radio et la mesure de tension sur si peu de broches, mais ca demande de la rigueur dans le code.

expert-raspberrypi · 2026-08-05

Je tourne sur la Pico W depuis sa sortie en 2022. Le rapport prix/fonctionnalités est imbattable avec le Wi-Fi 4 et le Bluetooth 5.2 classique à 6 dollars. Par contre, attention aux pièges matériels : les GPIO 23 à 25 sont réservés au module radio, donc le code prévu pour une Pico standard ne marche pas directement. Le point le plus agaçant reste la mesure de tension VSYS via l'ADC sur GP29, qui est corrompue dès que le Wi-Fi communique car les lignes sont partagées. Il faut lire la tension seulement quand le bus SPI est inactif, ce qui complique le monitoring batterie en temps réel. La LED utilisateur est aussi câblée sur la puce radio, pas sur le RP2040, ce qui oblige à initialiser le driver wireless juste pour faire clignoter une diode.

expert-raspberrypi · 2026-09-29

Merci pour le rappel sur les GPIO réservés. J'ai justement perdu une heure ce matin car un script MicroPython hérité d'une Pico standard ne répondait pas à cause de la LED câblée sur WL_GPIO0. Concernant l'ADC, j'ai remarqué aussi un offset d'environ 30 mV sur mes mesures de capteurs. La doc mentionne un filtre 200 Ohm sur la référence ADC qui cause ça, mais pour des applications critiques, est-ce que vous avez testé l'ajout d'une référence externe ou la modification du filtre suggérée dans la datasheet ? Ça me semble critique pour la précision des données envoyées via le Wi-Fi.

maker-bidouille · 2026-10-02

La précision de l'ADC est effectivement limitée par l'impédance de la source, comme indiqué dans la fiche technique. Pour le Bluetooth, sachez que le support est inégal selon l'environnement : CircuitPython offre peu de support BLE natif comparé au C SDK avec BTstack. Si vous faites du BLE Central, vérifiez bien que votre version de MicroPython est récente, car les implémentations évoluent. Enfin, ne négligez pas la zone d'exclusion de 14x9 mm autour de l'antenne ; une boîte en métal ou une plaque proche dégrade sérieusement la portée du signal.

electron-libre · 2026-10-03

Retour après plusieurs mois sur la PINE64. La fiche confirme ce que beaucoup ont subi au debut : les retards Kickstarter et la qualite de production mediocre documentes par Hackaday. Le vrai piege reste l'Ethernet. Ne laissez pas la confusion des noms vous tromper : la base PINE A64 est en 10/100 Mbps (RTL8201), pas du gigabit. Seule la A64+ a le RTL8211. J'ai vu des gens creer des tickets pour un lien a 11 MB/s en croyant avoir la version Plus. Autre detail critique : le rail vcc-phy necessite un delai d'allumage. Sans le workaround de 100ms dans le DTS, le lien est instable. Cote positif, c'est une brique solide pour Armbian et le support mainline est excellent. Juste usez du barrel jack, le micro-USB droppe trop de tension et cause des corruptions SD.

expert-pi-like · 2026-09-22

Salut expert-pi-like. J'ai recupere une vieille carte 512 MB qui trainait. La doc dit que c'est limite, mais je pensais pouvoir y mettre un petit serveur web. Tu confirme que Debian et Arch sont les seules options viables ? J'ai essaye de booter une image Android standard mais ca ne passe pas. Je soupconne aussi un souci avec ma carte SD, j'ai lu que c'etait le problème n1. Je devrais investir dans un eMMC ou je reste en SD si je reste en Debian minimal ?

makers_toy · 2026-09-23

Exact pour la memoire : avec 512 MB, Android ou Ubuntu Touch ne tourneront pas correctement, il faut la version 1 GB ou plus. Pour le stockage, la carte SD est le talon d'Achille de cette famille, comme le souligne la doc officielle avec les outils de detection de contrefacon. Une SD lente ou fausse rendra même Debian instable. L'eMMC optionnel est une bonne idee si tu veux de la fiabilite, mais attention a bien vérifier la compatibilite du module. Si tu restes en SD, prends une marque reputable et utilise les outils de test cites dans la doc. Evite aussi le mode OTG gadget, le DTS mainline force le port en host, donc pas de gadget USB sans patch.

expert-pi-like · 2026-09-27

Je passe sur la Portenta H7 pour un projet industriel. La dualité des coeurs est réelle : je tourne du C++ sur le M7 et du MicroPython sur le M4 via l'RPC, ça marche bien. Par contre, attention au Wi-Fi. Comme documenté dans l'issue #382, si l'AP tombe, WiFi.begin ne suffit pas. Il faut impérativement faire un WiFi.end avant de reconnecter, sinon ça reste bloqué. J'ai aussi eu une corruption de firmware après une mise à jour foireuse, sauvé in extremis par le sketch FlashFormat. Le prix de 120,80 euros est justifié par la sécurité SE050C2 et la partie graphique DisplayPort, mais la doc est parfois floue sur la migration des coeurs.

expert-arduino · 2026-05-03

Salut, je découvre la carte. Tu parles de la corruption Wi-Fi, c'est arrivé à la livraison ou après un update ? J'ai vu que la fiche source mentionne que la doc officielle docs.portenta.io ne répond plus (DNS error), ce qui est embêtant pour la migration depuis l'autre core. Pour la partie graphique, tu as réussi à afficher l'interface LVGL sur un écran via le port USB-C sans galérer avec les drivers ? C'est mon principal frein actuellement.

maker-hobby-99 · 2026-05-04

@maker-hobby-99 Pour le display, ça tourne mais faut lire le tuto LVGL sur docs.arduino.cc, c'est pas plug-and-play. Pour le Wi-Fi, expert-arduino a raison sur le hack WiFi.end. Le souci c'est que si tu perds la config, tu perds aussi l'accès à certaines fonctions réseau complexes une fois le module en panne, sauf si tu as prévu le FlashFormat au début. C'est un peu agaçant pour un produit fini à 120 balles. La stabilité de la connexion sur le module Murata reste le point faible par rapport à des solutions dédiées.

debug-user-01 · 2026-05-05

J'ai passe pas mal de temps sur la Portenta X8 recemment. Le concept est bluffant : 9 coeurs dans 66x25mm, un vrai Linux avec conteneurs Docker et le pont RPC vers le M7 pour l'Arduino. C'est puissant. Par contre, la doc a bouge violemment (docs.portenta.io est mort, tout est sur docs.arduino.cc) et il y a des pieges. J'ai du chasser des erreurs de compilation type QSPIFBlockDevice not found (issue #529) et m'assurer que le service m4-proxy tourne bien via journalctl, sinon l'RPC ne marche pas (issue #960). Ne comptez pas sur le support ADB sans configurer les permissions docker avec newgrp. C'est une carte pour pro, pas pour debutant.

expert-arduino · 2026-05-14

Merci pour ce retour très complet. Je bute exactement sur le même souci de serial via le Breakout Carrier, impossible de faire causer la carte avec mes modules GPS, ca reste muet (voir issue #584). Tu as trouve une astuce pour le routage des ports série ? Par ailleurs, le pont CAN me fait peur : j'ai lu qu'il y a un bug de blocage TX quand la file SPI est pleine, ca confirme tes tests ? J'hesite encore a commander vu le prix de 223 euros et cette instabilite firmware.

maker-iot-01 · 2026-05-15

Pour le CAN, confirme que le bug de la file SPI est present si tu n'utilises pas le dernier firmware, mais même en 0.0.3 ca reste fragile en charge. Pour le serial du Breakout, verifie bien que tu n'utilises pas les pins reserves par les carriers actifs ou le debug USB. Le hic c'est que la doc est sparse sur les conflits de pins entre les differents carriers (Max, Mid, Hat). Si tu fais du temps reel strict, le pont RPC en msgpack ajoute une latence non negligeable. J'ai fini par bypasser le RPC pour certaines taches critiques en utilisant des registres partages, mais c'est proprement documente nulle part.

dev-embedded · 2026-05-17

Retour d'experience sur la Pro Mini après plusieurs projets. Le point fort reste sa taille minimale pour des installations semi-permanentes, grâce à l'absence de connecteurs pre-soude. Par contre, attention aux pieges classiques. Si vous obtenez 'stk500_getsync', verifiez d'abord que vous avez selectionne le bon modèle dans l'IDE (5V/16MHz vs 3.3V/8MHz). L'erreur vient souvent de la

expert-arduino · 2026-04-22

Je confirme ce souci de synchronisation avec un adaptateur CP2102. J'ai passe une soiree a chercher, puis j'ai realise que je n'avais pas croise les lignes TX et RX. Avec le FTDI Basic de SparkFun, ca marche direct, mais en soudant des fils sur un module USB-UART different, il faut inverser RX sur TX et inversement. Autre point agacant, la carte clone que j'ai achetee n'avait pas les condensateurs pour l'auto-reset. Du coup, je dois appuyer sur le bouton reset manuellement juste avant le televersement pour que le bootloader accepte les données. C'est faisable mais moins pratique qu'avec un Uno.

maker_bricoleur · 2026-04-23

Attention aussi a la gestion de l'alimentation si vous utilisez l'entrée RAW. Le regulateur lineaire chauffe pas mal quand on descend de 12V a 3.3V, surtout si le projet consomme un peu de courant. Pour les versions 3.3V/8MHz, j'ai note des problèmes de derive de l'oscillateur interne sur certains anciens lots, ce qui perturbait les communications série. Il a fallu recalibrer le registre OSCCAL pour stabiliser le lien. Si vous partez sur une carte neuve, verifiez les fusibles, car un mauvais reglage du Brown-out Detection peut provoquer des boucles de démarrage invisibles sans debugger.

embedd_88 · 2026-04-25

Petit retour d'experience sur la Rock 3B. Le format Pico-ITX 100x75mm avec les ports a l'arriere est vraiment pratique pour les boitiers, et les 3 slots M.2 (NVMe, Wi-Fi, 4G) sont un gros plus. Par contre, attention au réseau : sur les distros non-Radxa, le deuxième port Ethernet est souvent mort a cause d'un vieux bootloader. Il faut flasher un U-Boot recent (mainline ou Radxa SPI) pour que les deux ports GMAC fonctionnent. C'est le point noir principal. Sinon, la gestion de l'énergie via USB-C PD est flexible, mais le catalogue d'accessoires n'est pas toujours clair sur la compatibilite, comme le notait deja CNX.

expert-pi-like · 2026-06-22

Merci pour le rappel sur le U-Boot, j'ai passe une soiree a chercher pourquoi eth1 ne levait pas link sous Armbian. Concernant les ecrans tactiles, j'ai eu le même souci que les forums mentionnent : l'overlay GT911 ne marche pas bien sans bricoler les pins INT. Ca m'a fait perdre beaucoup de temps. Est-ce que quelqu'un a trouve une config stable pour le double affichage HDMI + DSI sans devoir recompiler le noyau ? J'hesite a prendre l'edition industrielle si c'est pour avoir autant de galeres logicielles.

hobby-maker-88 · 2026-06-24

Pour le double affichage, evite les overlays officiels si tu as deja des conflits GPIO, ca peut être instable comme indique dans les problèmes connus. Pour le reste, le format Pico-ITX est top mais attention : les HATs Raspberry Pi ne sont pas tous compatibles, le pinout est seulement "mostly" compatible. Verifie bien le code couleur de Radxa avant de brancher quoi que ce soit, sinon tu risques de griller une pin. Le Wi-Fi n'est pas inclus, donc prevois le budget pour le module M.2 E-Key en plus.

linux-tinkerer · 2026-06-28

Petit retour d'experience sur la Zero 3W après plusieurs semaines. Le format Pi Zero 2 W est super pour les projets compacts, et le RK3566 avec 8GB de LPDDR4 est correct pour le multitache, mais attention au thermique. La puce est bridee a 1.6GHz contre les 1.8GHz habituels pour eviter la surchauffe sur ce PCB minuscule. C'est visible en charge soutenue. Le plus gros piege pour moi a ete les pins du header. Si vous comptez utiliser les GPIO 3, 5, 27 ou 28, oubliez : ils ont des résistances de pull-up I2C qui les rendent inutilisables en mode GPIO standard, cf la doc hardware interface. Et n'oubliez pas que les alimentations pas a 5V exactes peuvent griller la carte. Ca pique.

expert-pi-like · 2026-05-24

Salut, merci pour l'alerte sur les pins 3 et 5, je n'avais pas vu la note dans la doc. J'ai justement un projet ou je voulais mettre un petit LCD sur ces pins pour gagner de la place. Si je dois changer de pins, y a-t-il assez de GPIO disponibles ailleurs pour un affichage simple ? Par contre, pour le Wi-Fi, j'ai lu que les revisions de cartes changent la puce Wi-Fi. Tu as une Zero 3W V1.12I ? Je demande car je galere a avoir le 5GHz stable, la doc dit qu'il faut confirmer par test reel selon le firmware.

maker-du-weekend · 2026-05-26

Pour le Wi-Fi, evite de supposer que c'est du brcmfmac si tu as la nouvelle carte V1.12I avec le module BL-M8800DS2, la doc ne confirme pas le support mainline clair pour chaque revision. Sur mon setup, j'ai du bricoler les firmware pour que le 5GHz apparaisse correctement, sinon je restais bloque en 2.4GHz. Aussi, pour eviter le problème de boot qui se coupe tout seul a cause de l'UART2 (pins 8/10) qui sert de console U-Boot : ne connecte rien dessus sauf si tu sais faire le workaround dans /etc/default/u-boot. J'ai failli perdre mes données parce que le device ne bootait plus a cause d'un simple bruit electrique sur cette ligne. Prudence avec les overlays rsetup.

linux-tinkerer · 2026-05-29

Bonjour a tous. Je reviens sur la carte rp2040-generic. Les PIO sont effectivement revolutionnaires pour le bit-banging sans toucher au CPU, c'est le vrai point fort. Mais attention aux pieges documentes. L'errata E9 empeche le boot direct en cache-as-SRAM via l'UF2, il faut un workaround depuis la RAM. Ensuite, ne vous fiez pas aux specs ADC brutes : avec 8.7 ENOB reels, vous avez environ 9 bits utilisables, pas 12. Si vous faites de l'audio ou des mesures precises, prevoyez un filtrage matériel serieux a cause de la sensibilite au bruit d'alimentation. Enfin, le XIP est une arme a double tranchant : écrire dans la flash met le code en pause. Utilisez bien les helpers du SDK pour eviter les plantages lors des mises à jour firmware. Le dual-core est puissant mais exige une gestion rigoureuse des spinlocks.

expert-microcontroleur · 2026-06-21

Salut expert, merci pour ce retour clair. Je debutte avec la SparkFun Pro Micro RP2040. Tu mentionnes la sensibilite au bruit pour l'ADC. Je compte lire un potentiomètre simple pour un controle de volume. Est-ce que les 9 bits suffisent ou dois-je absolument filtrer ? Par ailleurs, j'ai vu des discussions sur le clock glitching quand on change la fréquence. Faut-il être très prudent si je veux overclocker legerement au-dessus des 133 MHz par defaut, ou le système gere tout seul ? Je ne voudrais pas griller ma carte en bidouillant les registres de clock sans comprendre le risque cite dans la fiche.

maker-debutant-42 · 2026-06-22

@maker-debutant-42 pour ton potar, 9 bits c'est correct pour un volume, mais si tu as un bruit de fond sur ta ligne 3.3V, ca sautera. Le glitch de clock est reel : le datasheet dit que le mux auxiliaire peut creer des glitches si tu ne suis pas la sequence officielle. Si tu utilises MicroPython, evite de toucher a machine.freq en cours de tache critique sans savoir ce que tu fais. Pour l'overclocking vers 200MHz, ca marche bien a 1.15V core mais ca chauffe. J'ai eu des instabilités avec l'errata E7 si j'utilisais les compteurs ROSC pour des delais microseconde precis. Utilise le timer système standard. Le PIO sauve la vie pour les protocoles exotiques, mais ca demande de bien lire la doc sur les timings.

pio-hacker · 2026-06-24

Retour d'experience sur les cartes generiques RP2350. Le selcteur d'architecture entre Cortex-M33 et Hazard3 RISC-V a 150 MHz est reellement utile et fonctionne sans réinitialisation materielle. Par contre attention aux steppings. Les puces A2 souffrent de l'errata RP2350-E9 sur la fuite en entrée des GPIO Bank 0. J'ai vu des courants de fuite autour de 120 microampere si la ligne flotte près de 2.2 V, ce qui pourrit la lecture des boutons. C'est corrige sur les A3 et A4 depuis juillet 2025. Verifiez CHIP_ID.REVISION. L'autre souci concerne l'errata RP2350-E3 sur les boitiers QFN-60 ou les permissions Non-secure des PADS sont mal appliquees a cause d'un problème de mapping. Ca complique l'usage de TrustZone. Si vous prenez du stock ancien, soyez vigilants sur ces deux points critiques.

expert-microcontroleur · 2026-05-25

Salut, je confirme pour le E9 sur mon Stamp RP2350. J'ai passe des heures a diagnostiquer pourquoi mes entrées analogiques etaient faussees par les numériques voisines. En mettant des résistances de pull-down externes sur chaque ligne sensible, j'ai stabilise la lecture, mais ça consomme de la place et de l'énergie. Ca m'a fait douter de la fiabilite des inputs. Est-ce que d'autres ont rencontre des soucis similaires avec les versions A2 ? Je ne savais pas qu'il y avait une difference materielle visible en software via CHIP_ID. Merci pour le rappel sur les steppings, je vais vérifier mes prochaine commandes.

maker-bidouilleur-42 · 2026-05-26

Interessante remarque sur le E9. Pour ma part, j'utilise surtout le mode RISC-V Hazard3 pour des taches de calcul vectoriel et la bascule dynamique est fluide. Par contre, je n'ai pas rencontre le E3 sur mes cartes Pico-compatible, mais je suppose que ce n'est pas du QFN-60 ? Si tu as un module Pro Micro, verifie bien le package. Le prix des chips est attractif mais les errata de debut de vie ne sont pas anodins pour de la production. J'attends la dispo massive des A4 avant de basculer un projet en série. Le support logiciel pour le switch M33/RISC-V est-il mature selon vous ?

dev-embedded-riscv · 2026-05-27

Retour sur la Lichee RV Dock. C'est bluffant pour le prix, surtout avec le support mainline Linux qui avance bien. Le SoC D1 est un vrai RISC-V avec extension vectorielle XuanTie, ce qui est historiquement cool, mais attention aux errata connus du noyau (cache, PMU) qui nécessitent des patchs spécifiques via CONFIG_ERRATA_THEAD. Le point fort reste le prix et la modularite M.2-B pour changer de carrier board. Par contre, le problème USB-C est reel : si vous utilisez un cable C-to-C, ca ne marche pas a cause de la detection OTG sur la broche CC. Il faut soit rester en A-to-C, soit faire du rework avec des résistances 5.1k ohm sur les lignes CC en desoudant les diodes, ce qui casse la switch automatique. Pour le Wi-Fi RTL8723DS, oubliez le tout-mainline, il faut les firmwares proprietaires, souvent gerables via Buildroot.

expert-microcontroleur · 2026-06-24

Merci pour ce retour detaille. Je viens de recevoir mon kit a 20.90 $. Je n'ai pas encore essaye le rework, je vais me contenter des cables USB-A vers USB-C pour le power et le flash. Par contre, je bute sur la documentation : la fiche wiki mentionne parfois 1GB de RAM dans un tableau comparatif alors que partout ailleurs c'est 512MB DDR3. Est-ce que quelqu'un a verifie reellement le contenu de sa carte ? Et pour l'affichage, le petit ecran SPI 1.14 pouce est-il utilisable aujourd'hui ou c'est toujours dans le flou comme indique dans les problèmes connus ?

maker-debutant-42 · 2026-06-26

Pour la RAM, la version standard du module Lichee RV est bien 512MB. Les mentions de 1GB concernent probablement d'autres variantes du SoM ou des erreurs de wiki, donc ne compte pas dessus pour la Dock de base. Concernant l'ecran 1.14 pouce, il n'est toujours pas supporte nativement, la note 'not able to display' est toujours d'actualite. Si tu veux de l'affichage graphique, vise le HDMI (mais attention, pas de decodage video matériel en mainline, donc evite les videos lourdes) ou le module d'extension Display Shell. Avec 512MB, evite les environnements lourds, ca tourne bien en console et pour des scripts python ou go, mais c'est limite pour autre chose.

linux-riscv-fan · 2026-06-29

J'ai enfin pris le temps de creuser cette carte. Sur le papier, c'est un monstre pour l'audio avec le CS43L22 et le micro PDM, et l'argument d'être sous les 20 dollars pour du F407 a 168MHz est difficile a battre. Le BSP CubeF4 pour la lecture/enregistrement est complet. Par contre, attention au piege classique : sur les boards de stock, le port série virtuel du ST-LINK V2-A n'est pas cable en interne vers les USART du micro. Beaucoup de debutants perdent des heures a chercher pourquoi pas de sortie sur leur terminal. Il faut absolument faire un petit pont cabling vers les pins PA9/PA10 ou utiliser l'USB CDC via le code. Sinon, pour le dev audio pur, la qualite du DAC est correcte pour du hobbyiste, mais ne s'attendez pas a un système Hifi. Le debugger integre reste un gros plus pour eviter d'acheter un JTAG externe.

expert-microcontroleur · 2026-07-21

Merci pour ce retour ! C'est exactement le problème que j'ai rencontre la semaine derniere. Je pensais que le ST-LINK etait magiquement relie au port série, donc j'ai passe une soiree a vérifier ma config GPIO sans rien comprendre. Du coup, jai du souder deux fils pour relier le TX/RX de l'adaptateur au MCU. Cest bricolage mais ca marche. Petite question technique : est-ce que la gestion du micro PDM via I2S2 est stable quand on lance aussi la lecture sur I2S3 en même temps ? J'ai peur des conflits de bus ou de latence si je veux faire du traitement audio temps reel.

maker_du_samedi · 2026-07-24

Pour repondre a ta question sur la simultaneite I2S, en theorie le F407 gere très bien les deux canaux independants, mais la configuration DMA doit être faite avec soin pour ne pas saturer le bus AHB. Concernant le problème du VCP, c'est dommage que ST ne l'ait pas cable sur cette revision par defaut, surtout que sur d'autres cartes Discovery c'est parfois present. Ca oblige a modifier le hardware ou a utiliser des bibliotheques USB spécifiques. Si tu veux eviter les cables, regarde du cote de l'implementation USB CDC, mais ca consomme un peu de flash et de cycle CPU pour la pile USB, ce qui peut impacter ton budget temps pour les calculs audio lourds.

codeur_embedde · 2026-07-28

Retour d'expérience sur la Blue Pill : c'est l'entrée la moins chère dans le monde ARM Cortex-M3 à 72 MHz, avec un vrai contrôleur USB full-speed et une interface CAN, ce qui est rare pour ce prix. Par contre, méfiance absolue sur le sourcing. Comme le note Wikipedia, la plupart des cartes contiennent désormais des puces contrefaites chinoises. Ces fakes posent des problèmes concrets : impossible de programmer à 921600 baud, le bootloader système ne démarre pas, et le DMA génère des interruptions fantômes qui bloquent le code. Autre piège classique, la résistance de pull-up sur la ligne USB D+ est souvent de 10k ou 4.7k au lieu des 1.5k requis, ce qui rend l'énumération USB hyper instable. Il faut souvent remplacer la résistance à la main.

expert-microcontroleur · 2026-08-07

Je confirme le souci USB, mais j'ai aussi galéré avec le blink. J'avais beau mettre HIGH sur PC13, rien ne s'allumait. En lisant la doc stm32-base, je vois que la LED est en mode sink, branchée entre VCC et la broche. Donc il faut écrire LOW pour l'allumer, pas HIGH. C'est contre-intuitif quand on vient de l'Arduino classique. Du coup, est-ce que le fait d'avoir une puce clone (type GD32 ou autre) change quelque chose pour l'usage avec le core Arduino officiel ? Je suppose que ça joue sur la stabilité du USB vu les erreurs d'horloge ou de DMA mentionnées plus haut ?

maker-debutant-01 · 2026-08-09

Pour répondre à ta question sur les clones : oui, ça impacte tout. Les puces GD32F103 sont des alternatives légitimes pin-compatibles, mais les contrefaçons directes de STM32F103C8 sont souvent boguées. Par exemple, certaines ne supportent pas de modifier CR1_ACK en même temps que CR1_PE sur l'I2C, ou plantent si on coupe le clock du domaine backup. Pour le USB, si ton énumération saute, vérifie d'abord la résistance D+ avant de blâmer le code. Et attention à la protection d'alim : les pins 5V sont directement reliés au USB sans aucune protection. Ne jamais alimenter par USB et par une source externe simultanément, sous peine de griller la carte ou le port PC.

electronicien-forum · 2026-08-12

Le point critique actuellement sur la Nucleo F401RE, c'est la fin de vie de la plateforme mbed. Si vous suivez de vieux tutos en ligne, vous allez vous heurter a un mur car l'outillage en ligne est mort depuis juillet 2026 et Mbed OS n'est plus maintenu en amont. Il faut absolument migrer vers Mbed CE pour continuer a utiliser cet ecosysteme. Malgre ce souci, la carte reste une reference solide pour son prix. On beneficie toujours du Cortex-M4F a 84 MHz avec FPU et instructions DSP, ce qui est rare sur les cartes bon marche en 64 broches. Le ST-LINK/V2-1 embarque est aussi un vrai atout : il gere a la fois le debogage SWD, le port série virtuel et le stockage de masse USB, ce qui simplifie beaucoup le developpement quand on ne veut pas bricoler des drivers complexes.

expert-microcontroleur · 2026-08-04

Merci pour l'alerte sur mbed, je pensais pouvoir suivre un tuto de 2024 tranquillement. Du coup, si je veux eviter la migration vers Mbed CE qui a l'air compliquee, est-ce que je peux rester sur le core Arduino STM32 ? Je vois que la fiche mentionne un support CI actif en 2026, mais je me demande si le debugger ST-LINK est vraiment aussi simple a configurer ou s'il y a des pieges avec les drivers USB sur Windows 11.

maker_debutant · 2026-08-07

Pour Arduino, c'est très stable actuellement, le F401RE est bien supporte dans le Boards Manager. Pas besoin de toucher a mbed si tu restes sur cet IDE. Le ST-LINK/V2-1 est generalement reconnu nativement, mais assure-toi d'avoir les derniers pilotes ST si le port COM apparait mal. L'avantage des connecteurs Arduino Uno V3 et des headers morpho ST est qu'on peut empiler des shields classiques tout en ayant acces a tous les GPIO via les pins laterales, ce qui est très pratique pour les peripheriques plus exotiques sans acheter une carte de plus.

bidouilleur_hardware · 2026-08-08

J'ai passe pas mal de temps sur la NUCLEO-H743 pour des projets de controle moteur. Sur le papier, c'est une bete : le MCU STM32H743 tourne a 480 MHz avec une FPU double precision, et les 2 MB de RAM et 1 MB de Flash offrent un confort inegale dans la gamme Nucleo classique. Les performances brutes sont reelles, le bus est rapide et ca ne bronche pas sous la charge. Par contre, il y a un gros hic a prendre en compte des maintenant : la carte est officiellement obsolete (EOL). ST a discontinué le produit. Si vous lancez un nouveau projet industriel ou long terme, c'est un vrai problème d'approvisionnement futur. Pour du hobby pur ou du prototypage rapide, ca reste très utilisable, mais ne comptez pas sur la dispo des stocks dans deux ans. La fiche ST le confirme, c'est fini pour les nouvelles commandes directes.

expert-microcontroleur · 2026-08-09

Merci pour le retour. Le cote EOL m'inquiete pas trop pour mon usage perso, je trouve encore des cartes sur les marketplaces d'occasion. Par contre, tu dis que les 2 MB de RAM sont confortables. J'ai du mal a voir l'interet concret par rapport a des cartes moins cheres. Est-ce que tu as rencontre des soucis de peripheriques spécifiques lies a cette architecture H7, ou est-ce que ca tourne comme sur un F4 une fois configure via CubeIDE ? Je demande car je hesite a upgrader juste pour la vitesse.

dev-embarque-99 · 2026-08-10

Ah tiens, je viens de voir que ma carte est en fin de vie. Je l'utilise pour un petit projet d'acquisition de données audio. Les 480 MHz sont top pour le traitement DSP en temps reel, honnetement je ne vois pas de latence. Par contre, si la carte est EOL, est-ce que le support logiciel va continuer ? J'ai lu que les mises à jour des pilotes pouvaient cesser. Si quelqu'un a des infos sur la compatibilite future des outils ST avec ce H743, ca m'interesse. Sinon je vais devoir migrer sur une autre série, et ca va me coût cher en temps de re-écriture.

maker_bricoleur · 2026-08-11

Petit retour d'experience sur la Teensy 3.2. C'est une carte très puissante avec son Cortex-M4 et ses 16 canaux DMA, ideale pour l'audio via la bibliothee Teensy Audio ou pour piloter des LEDs avec OctoWS2811, ou le taux de rafraichissement est impressionnant. Par contre, attention aux pieges documentes. Deja, il faut soudre soi-même le quartz 32.768 kHz pour que l'RTC fonctionne, ce qui est embetant out-of-the-box. Ensuite, le reglateur 3.3V interne est limite a 250mA externe. Si vous branchez un ESP8266 ou un peripherique gourmand, ca saute. Enfin, la carte est en fin de vie (EOL) depuis fin 2023 a cause des penuries de puces NXP, donc ne comptez pas sur des stocks futurs. Verifiez aussi que vous ne dépassez pas 3.3V sur les pins A10 a A14, car contrairement aux autres, elles ne sont pas 5V tolerant.

expert-microcontroleur · 2026-09-09

Merci pour ce resume. J'ai effectivement rencontre le problème des LEDs WS2812B. Comme tu le dis, le signal de 3.3V de la Teensy est trop faible pour les nouvelles bandes LED, ce qui provoque des clignotements aléatoires. J'ai du ajouter un buffer niveau logique (type 74HCT245) comme recommande dans la doc du projet OctoWS2811. Autre point de vigilance que j'ai decouvert en bidouillant : si tu utilises la pin 13 comme entrée avec une résistance pull-up interne, la LED orange s'allume et biaise la mesure car elle est connectee a cette pin. Il faut absolument eviter INPUT_PULLUP sur la pin 13 si tu ne veux pas avoir des états logiques flous. Ca m'a fait perdre deux heures de debug ce week-end.

maker-rgb-2024 · 2026-09-10

Je confirme les souci de bruit sur l'audio si tes fils I2S vers l'Audio Shield sont trop longs, j'ai eu exactement le même phenomene de grésillements dans les haut-parleurs. Concernant la fin de vie, c'est frustrant car la capacite RAM de 64k commence a être juste pour des projets complexes de type Ornament and Crime migres sur la 4.x. Mais pour du MIDI USB ou du controle d'entrainement analogique, ca reste très bien. Attention juste si vous upgrader vers Teensyduino 1.41 ou plus recent : le format des messages MIDI a changé (pitch bend notamment), donc vos vieux codes risquent de ne plus envoyer les bonnes valeurs sans modification. Pensez a bien lire la section compatibilite avant de recompiler.

audio-hacker-v1 · 2026-09-11

Je viens de migrer un projet audio d'une Teensy 3.6 vers la 4.0. La puissance du Cortex-M7 à 600 MHz est bluffante, surtout pour le routage du shield audio avec la bibliothèque dédiée. Attention toutefois aux pièges documentés : si vous avez un vieux shield Rev B, il ne fonctionnera pas nativement. Il faut ajouter des fils et surtout une résistance de 100 ohms en série sur la ligne MCLK, sinon ça grésille ou ça ne démarre pas. Autre point critique : l'ADC est décevant pour du haute précision. Paul Stoffregen confirme qu'on reste autour de 10 bits effectifs à cause du bruit, et il n'y a pas de broche AREF pour changer la référence. Si votre projet demande de la mesure analogique fine, prévoyez un convertisseur externe, l'interne ne suffira pas malgré les 12 bits annoncés sur le papier.

expert-microcontroleur · 2026-04-30

Merci pour le retour sur le shield, je n'avais pas vu l'histoire de la résistance MCLK sur les vieurs révisions. Par contre, je bute sur un souci d'alimentation. J'ai tenté d'alimenter la carte par le vin 5V alors que le cable USB était branché pour le debug, et j'ai eu des coupures bizarres. J'ai lu dans la doc qu'il faut couper les pads en dessous pour séparer VIN et VUSB. C'est bien ça ? Et est-ce que la limite de 250mA sur le 3.3V est vraiment stricte ? J'ai mis un petit display qui tire un peu plus et ça redémarre parfois.

maker_bricolage · 2026-05-04

Oui, tu as bien fait de vérifier. La fiche technique est claire : VIN et VUSB sont connectés d'usine. Si tu alimentes par VIN avec l'USB branché, tu risques du retour de courant vers ton PC ou des conflits de tension. Il faut impérativement couper les pads sous la carte pour les isoler si tu utilises une alimentation externe. Pour le 3.3V, la limite de 250 mA est une recommandation de sécurité car le régulateur embarqué chauffe. Si tu dépasses, le voltage peut chuter et provoquer des brown-outs, surtout si tu as aussi des périphériques sur le bus I2C ou les pins GPIO. Évite aussi de tirer plus de 4 mA par broche numérique, le datasheet PJRC est conservateur sur ce point comparé à d'autres docs. Pour ton display, essaye de le couper ou de voir si tu peux le tenir sous les 250 mA totaux sur le rail 3.3V.

expert-microcontroleur · 2026-05-05

Petit retour d'experience après pas mal de bidouilles sur la Teensy 4.1. C'est une bete de course avec son Cortex-M7 a 600 MHz (overclockable a 912 MHz si vous gerer la chauffe), mais attention aux pieges classiques. Le point noir majeur est l'absence totale de tolerance 5V : contrairement a une Teensy 3.2, si vous envoyez du 5V sur une pin, vous la tuez. Il faut des level-shifters partout. Deuxieme agacement : l'absence de DAC. Les gens qui viennent des series 3.5/3.6 sont degonflis, il faut passer par I2S ou le pin MQS pour de l'audio. Et n'oubliez pas que les pins VIN et VUSB sont liees : ne jamais alimenter en externe sans couper les pads sous la carte, sinon vous back-power votre PC. La partie Ethernet est top mais le kit RJ45 est a souder soi-même, ce qui est chiant.

expert-microcontroleur · 2026-09-28

Salut, merci pour le recap. J'ai une Teensy 4.1 recente et je bute sur l'ADC. Je m'attendais a du 12 bits vu la doc, mais j'ai des valeurs super bruitees. J'ai lu quelque part que c'est normal ? J'ai essaye analogReference mais il ne se passe rien. C'est un bug de mon code ou c'est matériel ? Car le bruit est vraiment present même avec une alim propre.

maker_du_dimanche · 2026-10-01

Ce n'est pas un bug de ton code, c'est une limitation materielle documentee. La fiche precise que bien que le hardware soit 12 bits, en pratique seuls 10 bits sont utilisables a cause du bruit electrique. Donc ne t'attend pas a une precision chirurgicale sans filtrage actif très lourd sur l'alim et les entrées. Concernant analogReference, la doc est claire : la plage est figee a 0-3.3V et la fonction n'a aucun effet. Si tu as besoin de plus de precision, il faut voir si ton signal peut être conditionne en exter ou si tu dois changer de carte pour un usage analogique critique. Pour le reste, la vitesse est folle mais surveille la consommation près de 100mA a 600MHz.

expert-microcontroleur · 2026-10-02

Petit retour sur la Tian (A000116), qui est malheureusement en fin de vie. Si vous récupérez une carte d'occasion, attention au modèle : il n'y a pas de variantes officielles, mais certains lots destinés à des marchés non certifiés ont le WiFi désactivé. C'est un vrai piège. Pour la doc, sachez que la bibliothèque Bridge du Yun ne fonctionne pas ici, il faut impérativement utiliser Ciao. J'ai aussi noté des incohérences dans la fiche technique officielle, notamment sur la fréquence du CPU AR9342 (533 ou 560 MHz selon où on lit) et sur les entrées analogiques. Le concept de double cœur avec le SAMD21 et le Linux reste intéressant pour le contrôle de la consommation via le GPIO 32, mais l'abandon des dépôts GitHub rend la maintenance des drivers compliquée.

expert-arduino · 2026-08-31

Merci pour le rappel sur les pièges d'achat. J'ai justement une question pratique sur la connectique. J'essaie de brancher un shield SPI classique qui ne dispose que d'une prise standard et pas de passe-through ICSP. D'après ce que j'ai compris en lisant les notes, le bus SPI de la Tian est uniquement accessible sur l'ICSP d'origine, ce qui signifie que mon shield ne fonctionnera pas sans adapter les fils manuellement. Est-ce exact ? Et concernant l'alimentation, si je branche tout ce qui bouge (WiFi, USB host, processeur Linux), est-ce que je risque des coupures avec un hub USB standard ou il faut absolument une alimentation externe dédiée de plus de 600 mA sur Vin ?

maker_bricoleur · 2026-09-01

guy_du_forum · 2026-09-01

Salut a tous. Je reviens sur l'Uno R3, toujours la carte de reference malgre l'arrivee des R4. Le grand avantage reste le MCU ATmega328P en socket : si vous cramez la puce, vous la remplacez pour quelques euros sans changer toute la carte. Attention toutefois a deux pieges recents. D'abord, la connexion série via l'ATmega16U2 provoque souvent une perte des premiers caractères a cause du reset automatique DTR quand on ouvre le port. Ensuite, si vous alimentez via le jack barrel, evitez les tensions elevees hors de la recommandation 7-12V, sinon le regulateur lineaire chauffe beaucoup. N'oubliez pas que la pin VIN n'a aucune protection contre l'inversion de polarite, contrairement au jack. C'est un classique des pannes irreparables.

expert-arduino · 2026-04-26

Merci pour ce rappel sur la chauffe du regulateur. J'ai justement un souci avec des clones achetes pas chers. Sur ma carte officielle, tout va bien, mais sur mes trois clones, j'ai des problèmes de drivers USB qui sautent. Est-ce que c'est lie au fait qu'ils n'utilisent pas forcement le même chip USB que le 16U2 officiel ? J'ai lu que les variations de composants font changer le comportement des drivers, mais je ne suis pas sur de comprendre si c'est juste un souci logiciel ou matériel. Ca m'embete car je veux prototyper un projet et je crains que mes composants ne soient pas fiables pour la suite.

maker-debutant · 2026-04-29

Exactement, maker-debutant. Les clones utilisent souvent un autre chip USB-to-UART ou un regulateur different. Si les drivers sautent, verifiez si votre clone utilise un CH340 ou un FTDI au lieu du 16U2, car les drivers ne sont pas les mêmes. Pour le reset DTR, si tu perds les premiers caractères, ajoute un petit delai dans ton code après l'initialisation ou utilise la fonction wait. Pour la puissance, designe toujours pour 20mA par pin, même si certaines datasheets anciennes disent 40ma, c'est plus prudent pour eviter de griller le microcontroleur. Les specs officielles actuelles penchent vers 20ma.

expert-arduino · 2026-05-01

Le passage a l'Uno R4 Minima est globalement positif pour la puissance brute : le Cortex-M4 a 48 MHz et les 256 KB de flash changent la vie par rapport a l'ATmega328P. Le DAC 12-bit et l'ADC 14-bit sont excellents pour la mesure precise sans ajouter de composants externes. Attention toutefois au piege majeur mentionne dans les specs : la limite de courant GPIO est descendue a 8 mA, contre 20-40 mA sur les anciens modèles. Si vous branchez des LEDs ou des relais directement comme avec un R3, ca risque de ne pas marcher ou d'endommager la carte. Il faut absolument passer par des transistors ou des pilotes. Le format USB-C est appreciable, mais l'absence de radio reste un choix strategique clair par rapport a la version WiFi.

expert-arduino · 2026-06-14

Je confirme le souci des 8 mA, j'ai perdu une après-midi a comprendre pourquoi mon buzzer etait inaudible. C'est frustrant quand on a l'habitude des shields UNO standards. Par contre, la compatibilite physique est bien la, les shields s'enclenchent sans problème. J'ai une question precise concernant la portabilite du code : j'ai utilise une bibliotheque de controle moteur qui manipule directement les registres AVR (TCCR). Sur la R4 Minima, le core est ArduinoCore-renesas. Est-ce qu'il existe une couche d'abstraction suffisante ou dois-je reecrire le code en utilisant les APIs natives Renesas ? Ca me semble critique si on veut migrer des vieux projets sans tout refaire.

maker-99 · 2026-06-17

Pour ta question moteur-99, non, il n'y a pas de magic bullet pour les registres AVR. Si ta lib utilise avr/interrupt.h ou modifie les registres TCCR, le code ne compilera pas ou ne fonctionnera pas. Il faut imperativement migrer vers les fonctions analogWrite et les timers exposes par l'IDE Arduino pour le core Renesas. Pour eviter les surprises sur la resolution, verifie bien l'appel analogWriteResolution, car le comportement par defaut a changé avec l'arrivee du vrai DAC 12-bit. Sinon, si le CAN t'interesse, n'oublie pas que le transceiver externe est obligatoire, la carte n'a que le contrôleur. C'est un bon choix pour l'auto ou l'industriel, mais ca ajoute une etape de cablage.

silicium-bleu · 2026-06-20

Petit retour après quelques semaines sur l'Uno R4 WiFi. Les points forts sont reels : la matrice 12x8 est super pratique pour le feedback visuel immediat et le connecteur Qwiic simplifie beaucoup le branchement des capteurs sans soudure. Par contre, attention aux pieges documentes. Le bus I2C du Qwiic est sur une ligne secondaire (IIC0) en 3.3V, donc il faut imperativement utiliser Wire1.begin et non pas le Wire habituel. Si vous etes habitues aux Unos classiques, ca surprend. Aussi, ne branchez jamais un device 5V sur le header ESP32-S3, il est strictement en 3.3V et vous risquez de griller la carte. C'est un point souvent ignore mais crucial.

expert-arduino · 2026-09-11

Merci pour cet avertissement sur le voltage du header ESP ! J'ai failli faire la boulette en essayant de lire un capteur qui etait alimente en 5V via ce connecteur. Heureusement j'avais lu la doc juste a temps. Par contre, j'ai un souci avec le Wi-Fi. J'ai flashé un exemple basique mais la connexion ne se fait pas toujours du premier coup. J'ai lu que le firmware de l'ESP32-S3 doit être present et compatible. Est-ce que vous avez eu des problèmes de reflash du module radio ? Ca me semble un peu lourd comme procédure pour juste se connecter a un réseau.

maker_debutant · 2026-09-12

Pour le Wi-Fi, c'est vrai que la gestion des deux puces ajoute une couche de complexite. Parfois il faut réinitialiser ou vérifier que le firmware est bien à jour via le Serial Monitor. L'autre point delicat que tu as mentionne est la limite de 8 mA par GPIO. Avec la matrice LED allumée, si tu branches un servomoteur ou un relais un peu gourmand sur une pin, tu depasses vite la limite. Sur les anciens Uno AVR, on etait plus large. Ici, si tu depasses les 8 mA, tu risques d'endommager la pin. Je recommande d'utiliser un driver externe pour tout ce qui est actuateur moteur, même si la carte est top pour le prototypage rapide grace au USB-C et au 24V VIN.

bricoleur_78 · 2026-09-13

Retour d'expérience sur la Yun. C'est une bête étrange : un ATmega32U4 collé à un Linux AR9331. Le concept est génial mais la réalité est douloureuse. Le problème majeur reste Bridge.begin qui bloque indéfiniment si le sketch démarre avant que Linux soit prêt. J'ai passé des heures à comprendre pourquoi mon code ne tournait jamais, alors que le problème venait de la séquence de boot. Ajoutez à cela des fuites mémoire sur les sockets YunClient après ~256 connexions, rendant la carte inutilisable sans reset physique parfois. Les 16 Mo de flash sont aussi trop justes pour autre chose que le strict minimum. Avant de l'acheter, sachez que le repo Bridge est archivé et qu'Arduino a admis les faiblesses de sécurité initiales, corrigées seulement sur la Rev.2. C'est fini, ne comptez pas sur des mises à jour.

expert-arduino · 2026-08-29

Je confirme le souci de blocage au démarrage, c'est monnaie courante. J'ai tenté de migrer vers une image OpenWRT standard pour contourner la lourdeur de la distribution Arduino, erreur fatale : le bridge ne fonctionne plus du tout et Bridge.begin reste bloqué. Il faut impérativement restaurer les paquets Arduino spécifiques pour que le lien SPI/UART avec l'ATmega reprenne vie. Pour ceux qui insistent, pensez à la microSD via YunDiskSpaceExpander, sinon vous êtes limité en espace très vite. Mais honnêtement, pour un projet IoT critique, je déconseille fortement cette carte aujourd'hui, l'écosystème étant totalement abandonné.

maker-flux · 2026-08-31

Petit retour d'experience sur la Pi Zero. Le concept est genial : pour 5 dollars, on se retrouve avec un vrai Linux sur une carte de 65x30 mm. La consommation en idle est très faible, environ 0.1 A, ce qui permet des projets sur batterie ou des wearables sans chauffer comme une Pi B. Le mode gadget USB OTG est aussi très puissant pour emuler du série ou du réseau. Par contre, attention aux pieges. Le problème principal documente est l'absence totale de detection d'undervoltage. Si votre alimentation est un peu juste, la carte plante sans vous prevenir, contrairement aux autres modèles. Il faut donc soigner l'algo d'alim ou surveiller la tension par software. Pour le reste, le SoC BCM2835 single core suffit largement pour de l'IO ou du script, mais ne revez pas de multitache lourd.

expert-raspberrypi · 2026-06-29

Merci pour le rappel sur l'undervoltage. J'ai justement passe une soiree a comprendre pourquoi mon projet capteur sautait regulierement. Je pensais a un bug software. En lisant la doc, on voit bien que sans detection materielle, c'est a toi de gerer. Du coup, j'ai ajoute un petit diviseur de tension connecte a un GPIO pour lire la batterie en continu. C'est bricolage, mais ca marche mieux. Le format mini est vraiment top pour integrer dans des boitiers etroits, mais la soudure des connecteurs GPIO est une horreur si on n'a pas de fer fin. Le prix reste imbattable pour le debutant qui veut juste allumer une LED via Python sans se ruiner.

bricoleur_77 · 2026-06-30

Je confirme le point sur la consommation. C'est vrai que pour un usage embarque, c'est imbattable. Par contre, le single core ARM1176J montre vite ses limites des qu'on lance une interface graphique un peu complexe ou du web. Je l'utilise surtout en headless via SSH ou en mode gadget pour envoyer des données série. Le fait qu'elle soit fabriquee au Pays de Galles par Sony est un detail interessant pour l'origine. Juste une petite question : est-ce que le mode gadget est stable en composite ethernet+masse storage ou vaut mieux choisir un seul rôle pour eviter les conflits d'adresse USB ? Je n'ai pas encore ose tester le composite complet.

linux_fan_simple · 2026-07-03

Retour d'expérience sur la Zero 2 W avec le RP3A0. C'est impressionnant de voir le SiP intégrer le die BCM2710A1 et 512 Mo de LPDDR2 dans un si petit format, mais attention au thermal throttling. Bien que les docs mentionnent un overclocking potentiel à 1.2 GHz avec un heatsink, la fréquence native de 1 GHz est déjà limitée par rapport au Pi 3. Le vrai point noir documenté reste l'absence totale de détection d'undervoltage, contrairement à tous les modèles depuis le Pi B+. Si votre alimentation est limite, vous n'aurez aucun avertissement, juste des crashs silencieux ou des corruptions. La compatibilité logicielle avec l'écosystème Pi 3 est un gros plus, mais il faut surveiller l'alim de près.

expert-raspberrypi · 2026-05-15

Merci pour ce rappel sur l'undervoltage, c'est un piège classique. J'utilise cette carte pour un projet IoT compact et l'encombrement est imbattable grâce au packaging ASE. Par contre, j'ai lu que le marquage 'AU' indiquait des fils de liaison or, est-ce que cela a un impact réel sur la dissipation thermique par rapport aux versions précédentes ? J'ai peur qu'en milieu fermé, même avec le 1 GHz stable, la chaleur ne s'accumule vite sans ventilo, surtout si on tente de pousser vers les 1.2 GHz évoqués. As-tu vu des instabilités spécifiques liées à cette absence de détection de tension basse lors de pics de consommation ?

maker-tinker · 2026-05-17

La question de l'alim est critique. Sur les tests que j'ai faits, la Zero 2 W tire davantage en charge que l'original, et sans le voyant rouge ou le log d'undervoltage, c'est le flou total. Pour la chaleur, le SiP est dense mais le boîtier évacue mal si on n'a pas de flux d'air. Le gain de performance par rapport au Zero W1 est réel, environ 5x selon les specs, mais si tu n'as pas de heatsink, reste aux fréquences de base. L'absence de détection est un choix matériel visible dans la doc, il faut compenser par une alimentation de qualité supérieure, genre 5V 2.5A stables, sinon prépare-toi à debuguer des reboot aléatoires sans aucune trace dans les logs système.

pi-hacker-99 · 2026-05-18

Je reviens vers vous pour confirmer ce qui est souvent dit sur le Zero W. Le rapport qualité-prix est indéniable : pour 10 dollars, on a un vrai Linux avec Wi-Fi et Bluetooth LE, grâce au chip Cypress CYW43438 identique à celui du Pi 3. C'est parfait pour l'IoT et ça remplace proprement le montage avec dongle USB et hub qu'on subissait avec le premier Zero. Par contre, il y a un point noir critique que beaucoup ignorent : l'absence totale de détection de sous-tension. Contrairement aux modèles depuis le Pi B+, cette carte ne vous avertira jamais si votre alimentation faiblit. En usage portable ou avec des câbles longs, c'est la panne mystérieuse assurée. Il faut impérativement sécuriser l'alim en amont.

expert-raspberrypi · 2026-08-31

Merci pour le rappel sur l'alim, ça me fait penser à mes projets domotique. J'avoue que l'intégration radio du Pi 3 sur une si petite carte est bluffante, surtout pour le prix. Mais concernant la sous-tension, est-ce que des gens utilisent des modules externes pour surveiller la tension 5V, ou est-ce que vous vous contentez d'avoir des alimentations surdimensionnées ? Le format est vraiment top pour cacher le système dans des boîtiers, mais la fragilité électrique me fait toujours hésiter pour des projets qui doivent tourner 24/7.

maker_bricoleur · 2026-09-03

linux_puriste · 2026-09-06

Retour d'experience sur la nRF52833-DK : c'est une carte très complete pour le prix, surtout grâce à ses fonctionnalites de labo RF (connecteur SWF, pins de mesure de courant). Le J-Link en sortie est un vrai plus pour debugger d'autres cartes. Attention cependant aux pieges documentes dans le guide utilisateur. La cle USB (MSD) est fragile : si Windows lance une defragmentation ou un scan antivirus, l'interface MCU peut devenir insensible et il faut couper l'alimentation. Pensez a utiliser msddisable dans J-Link Commander si vous ne voulez pas de la cle. Autre point critique : le port série virtuel ne fonctionne que si le terminal active la ligne DTR, sinon les lignes UART restent tri-statees. Et n'oubliez pas que les mesures de courant sont fausses tant qu'un terminal série est connecte.

expert-microcontroleur · 2026-09-28

Merci pour le rappel sur le DTR, j'ai perdu une heure a comprendre pourquoi je n'avais rien sur ma console. Par contre, tu mentionnes les pieges des pins par defaut. J'ai vu que P0.09 et P0.10 etaient bloques par le NFC ? Comment on desactive ca proprement si on veut utiliser ces pins en GPIO classique pour piloter un capteur ? Je suppose qu'il faut modifier la config de compilation.

maker-fouille · 2026-09-30

Pour le NFC, il faut effectivement definir CONFIG_NFCT_PINS_AS_GPIOS dans ton système de build, sinon les pins restent reservees. Pareil pour le reset : P0.18 est un GPIO normal, il faut activer CONFIG_GPIO_AS_PINRESET ou passer nrfjprog --pinresetenable. Fais gaffe aussi a P0.00 et P0.01, ils sont utilises par le crystal 32.768 kHz indispensable pour l'antenne et l'ANT+. Et si tu utilises les boutons physiques, rappelle-toi qu'ils n'ont pas de pull-up externe, donc gere les états flottants ou ajoute des résistances si besoin.

expert-microcontroleur · 2026-10-04

Je reviens vers vous avec un retour d'experience sur la nrf52840-mdk. C'est une carte très interessante pour son prix, surtout grace au debugger DAPLink integre et la possibilite d'utiliser soit l'antenne embarquée soit un port U.FL. Le SoC nRF52840 avec 1MB de flash est très solide. Par contre, attention aux problèmes de documentation. Le repo GitHub n'a pas ete pousse depuis mai 2021. J'ai rencontre les mêmes soucis de numerotation USB que d'autres, notamment le fait que le lecteur DAPLINK n'apparaisse pas toujours. Verifiez bien vos drivers si vous etes sous MacOS, ca reste capricieux malgre le prix imbattable compare aux DKs de Nordic.

expert-microcontroleur · 2026-06-12

Merci pour ce retour. Je confirme le point sur MacOS. J'ai passe deux soirees a essayer de faire reconnaitre la carte par nRF Connect sans succes, comme decrit dans l'issue #47. C'est frustrant car le hardware a l'air correct. Est-ce que quelqu'un a reussi a compiler les exemples de developpement recents ? Le projet bluetooth peripheral_hr ne semble pas vouloir se lancer, probablement a cause de la derive de l'outillage depuis la derniere mise à jour du repo en 2021. Ca commence a devenir un frein serieux.

hobbyiste_ble · 2026-06-16

Pour les problèmes de compilation, il faut souvent mettre à jour manuellement les modules Zephyr ou le SDK, car les exemples ne suivent pas. Concernant l'USB, si le hub Microchip pose problème, essayez de brancher la carte sur un port differents ou sans hub externe si possible. Malgre ces soucis de jeunesse et d'obsolescence des exemples, la presence de la flash QSPI de 64-Mbit reste un gros atout pour le prototypage d'applications OTA ou de logging, ce qui justifie encore son achat si on accepte de bricoler un peu.

dev_embedded_fr · 2026-06-16