Reprise du message précédent :
Anéfé, j'avais zappé que l'ATTiny a une plage d'alimentation large.
 
Après, je reste en faveur d'une RTC, c'est vraiment prévu pour et à mon avis, ca sera plus simple à mettre en oeuvre qu'un microcontrôleur qu'il te faudra programmer et tout.

j'ai pas mal d'xp en programmation, donc au contraire, si je peux régler mes problèmes avec quelques lignes de code, c'est parfait
 
(mais je vais étudier ta proposition ne serait-ce que pour comprendre)

Si t'alimentes directement ton Atiny sur la pile, dans ce cas la moindre surtension (branchement de la batterie par exemple), le µC se la prend directement dans la gueule.
Tu peux mettre une zener qui coupe à 5V pour protéger le µC ou faire un petit régulateur à zéner : https://www.electronics-tutorials.ws/diode/diode_7.html

Edith me dit qu'en fait un régulateur à Zener va consommer en permanence, donc c'est pas adapté. Néanmoins si t'alimente en direct l'Attiny, vaut mieux mettre une zener en direct qui coupe à 5.5V environ pour protéger le µC.

Ok, encore merci
 
Si c'est pas indiscret, c'est qui Edith ?

J'ai trouvé pourquoi je galérais avec mon wattmètre : en mettant le blindage ad-hoc en acier à ferrer les cochons autour de la carte, connecté au potentiel qui va bien, le niveau de bruit de fond retourne à quelque chose de tout à fait comparable aux autres voies    
 
Mais bon pour se retrouver avec un niveau de bruit de fond d'environ 1/3 de la pleine échelle derrière un gain de 100 c'est que le merdier est vraiment susceptible  

 
Edith c'est la personnalisation de Edit qui vient d'édition, autremnent dit c'est la personne qui te souffle à l'oreille ce que tu vas rajouter à ton message déjà posté.

ahhhhhh

Bon alors je me suis motivé à mesurer la conso d'un ESP8266.
 
Donc j'ai ce modèle:
https://www.banggood.com/ESP8266-ES [...] rehouse=CN
 
Le modèle à une LED rouge "power" qui m'emmerdait, j'ai donc viré manu-militari la résistance qui va avec pour la débrancher.
 
J'ai utilisé un bout en nodemcu qui fait en boucle:  
-Connexion à mon réseau wifi (moins de 5m de la box)
-Requète get en HTTP sur un serveur
-Passage en deep-sleep pour 10 secondes.
 
Rien d'autre de branché que l'alim et le loopback vers le reset nécessaire au bon fonctionnement du deep-sleep
 
Donc 1° test, µCurrent sur 1mV/mA branché sur l'oscillo:

 
Après j'ai étendu le délai de deep sleep à 60 secondes pour faire une mesure avec le calibre 1mV/µA, car faut avoir le temps de changer de gamme (les ~1V de burden à cause des 10 ohm de shunt durant les phases d'activité c'est un peu trop pour que le machin ne plante pas).
 
J'ai donc mesuré ~29µA remontés par le multimètre en deep sleep, on va dire que ça reste acceptable vis à vis des 20µA de la datasheet (surtout que si ça se trouve la flash bouffe les 10µA supplémentaires). Solution viable donc pour faire de la basse conso  

Intéressant Et tu avais quelle valeur connecté au wifi en mode normal ?

Je viens de me rendre compte que mon programme commence par un délai de 3 secondes (pour pouvoir reprendre le contrôle avant que ça tombe en sleep ).
 
Ça corresponds aux trois secondes en début de créneau ou on est à environ 70mA sans pics. Après il y a environ 3 secondes de communication WiFi actif (la partie hachée) avant de tomber en sommeil.
 
J'ai refait une mesure en saturant moins oscilloscope et avec un échantillonnage de bourrin et un calcul d'énergie me donne ~400mA.s pour un cycle de connexion, que l'on peut réduire à ~200 si on vire les 3 secondes de délai inutile à ~70mA, soit ~600mJ si on considère 3V de tension d'alim. Ramené en A.h ça fait ~55.6µA.h, ce qui autorise ~54000 cycles avec une batterie de 3A.h. Et la bah si tu fait un cycle par minute tu tiens ~37 jours  

Ouai enfin utiliser du Wifi toutes les minutes dans une application ultra low power...
 
Go Zigbee ou Bluetooth. Avec le Bluetooth 5, t'as une portée étendue, théoriquement jusqu'à 1000m (bon le débit chute).
 
Chez nordic y a le nRF52840 qui gère toutes les dernières nouveautés (15 mA max à puissance max) : https://www.nordicsemi.com/Products [...] s/nRF52840
Y a une dev board chez SparkFun : https://www.sparkfun.com/products/15025
 

Vais encore vous déranger.
 
 
Question RF
 
L'antenne derrière le PCB est au centre, on voit les points de soudure qui forment une croix.
Si je superpose un PCB la zone en rouge, à une hauteur de 5mm du PCB d'origine, est-ce le signal provenant de l'antenne risque d'être perturbé (effet capacitif lié à la masse du deuxième PCB superposé, ou que sais-je , j'y connais pas grand chose)??
 
J'ai comme l'impression qu'avec le modem d'origine (en bas), ils ont essayé d'éviter cette zone du milieu.
 

 
Tiens un ADC 12bit sur un oscillo secret    

 
pas possible d'envisager du lora aussi?

J'ai pas activé le 14 bits j'avais la flemme Il faut que j'utilise un peu plus l'engin pour pouvoir avoir un avis plutôt propre dessus.
 
Sinon j'ai remonté mon wattmètre. Je suis à peu près sur d'avoir remplacé la moitié des composants pour rien mais c'est pas grave, ils étaient achetés et j'allais pas remettre les anciens qui ont pris un coup de chaud au dessoudage Ah j'ai aussi acheté du fil à souder de 0.3mm, c'est bien plus facile de faire du CMS qu'avec mon 0.8    
 
Pour les curieux:
 
Carte d'acquisition pour la mesure de courant:

Carte d'acquisition pour la mesure de tension (on notera la similitude avec la carte de mesure de courant ):

La voie d’acquisition de courant réparée et prête à ré-installer. On notera la résistance de précision à 50 euro toute neuve, plus grosse que celle d'origine donc qui déborde

Vues d'ensemble:

Focus sur les alimentations isolées pour chaque voie:

Une mesure lambda de conso pour confirmer que ça marche (j'ai encore rien étalonné):

Et surtout la raison pour laquelle je maintient le truc en état, c'est qu'on peut avoir une bonne idée de la consommation en 230V de machins qui ne consomment presque rien, comme ici ce qui semble être une alimentation à chute capacitive avec redresseur simple alternance:

On dirait du home-made. J'aime

 
ok ok je comprends    
 
J'aime les appareils de mesure donc je suis curieux de savoir    
Je crois ne jamais avoir l'occasion de tester un Owon.
 
Ecran tactile 8 pouces, 8voies et toutes les option gratuites à ce prix la c'est pas mal, je suis curieux de voir ce que ça donne.
Ya un ventilateur la dedans ?
En terme de reactivité c'est comment ? ( aussi bien l'écran tactil que les boutons )
 
Sinon merci pour les photos du wattmetre c'est sympa
 

 
Du homemade propre alors !
 
 

On est bien dans l'esprit PME    Un Infratek 106A rebadgé par LEM pour avoir une corde de plus à son arc.
 
D'ailleurs les câbles de masse soudés à l'arrache sur une broche des optos sont probablement la cause de la panne qui a du laisser penser au labo où j'ai récupéré le machin qu'il était mort. A un moment il était tombé en marche quand j'investiguais j'ai pas cherché plus loin mais la un des fils s'est dessoudé à force de trifouiller dedans, en embarquant un bout de la pâte du l'opto, la pastille et une partie de piste > plus de mesure.
Et il m'ont emmerdés jusqu'au bout, car j'ai soudé le machin ailleurs avant de remonter, mais je ne sais pas pourquoi ça posait problème, il a fallu que je le vire et le ressoude pour que ça remarche  

 
Bah si, y a plein de protocoles sur le marché avec des avantages et des inconvénients.
 
Après, pour moi, LoRa ca nécessite un abonnement auprès d'opérateurs, je ne sais pas si on peut se faire son propre "master".
Mais pour faire un truc à la maison, avec des capteurs, le Bluetooth est très bien : 1.4-2Mbps, potentiellement une centaine de mètre de portée, ça convient à la plupart des applications IoT.
Après si tu veux une portée/autonomie plus longue, t'as le ZigBee potentiellement un peu plus de portée pour un peu moins de débit (250kbps), en terme de conso on est proche du bluetooth 5 néanmoins.
 
Mais bon le problème avec l'avènement du Raspberry Pi et de certains shield Arduino, bah y a plus aucune réflexion sur les technos existantes. On utilise le shield le plus populaire.
 
Comme ça été dit sur un autre topic, au niveau développement logiciel "web", il n'y a plus d'optimisation, on code avec les pieds, si ça rame, pas grave, on prendre des instances Amazon supplémentaires pour pas cher. Le problème c'est que cette mentalité commence à arriver dans le monde de l'embarqué et je le vois bien au boulot au niveau équipe soft : l'optimisation du soft n'est pas dans les tâches "quotidienne", le but c'est de développer les features en priorité, le reste on verra après.
 
Le après on le rencontre au niveau de la mémoire flash sur les cartes : on utilise de NOR, technologiquement limitée à 2Gb. La gestion des confs (pour gérer les différentes cartes/produits) c'est de mettre le même gros soft qui gère tout dans toutes les cartes. Donc aujourd'hui ils ont atteint les 2Gb. Ils veulent pas faire une image soft par produit, ok ça peut se comprendre en terme de gestion de conf. La solution c'est d'utiliser de la eMMC, moins chère que la NOR pour plus de capacité, mais faut développer le driver. Ca fait 1 an 1/2 qu'il y a des cartes avec une NOR et une eMMC, mais aucune décision de développer le driver n'a été prise.  
 
Et même globablement quand je demande au soft de me dire quelle est le ratio d'utilisation de la RAM entre écriture, lecture et idle, bah personne ne sait vraiment te répondre.
 
Les softeux qui comprennent le bas niveau, qui ont des connaissances en électronique, y en a très peu et l'avènement de l'Arduino et du Raspberry Pi n'y a rien changé.
 

ça clairement... tout à fait d'accord!
 
pour le LoRa, tu peux avoir ta gateway et soit t'as tes outils derrières ou tu peux renvoyer ça vers the thing network par exemple (gratuit).
 
et c'est valable pour le LoRa et le LoRaWan. Pour le deuxième faut juste des sondes et une gateway un peut plus balaise car faut gérer le chiffrement.
 
Je savais pas pour la portée du bluetooth 5! intéressant!

Aors déjà c'est un 4 voies
Je trouve que l'écran tactile pourrait être mieux exploité, à minima ça permet surtout de compenser un peu l'ergonomie moyenne. Le pire de ce côté c'est la FFT car on peut trouver des situation ou si on ne ruse pas à alterner entre l'échelle de fréquence et la position, il faut molleter des heures et des heures pour parcourir toute la gamme de fréquence, alors qu'avec l'écran tactile il devrait avoir à minima moyen d'afficher un pavé numérique pour aller vite    
 
Le machin a un ventilateur planqué dedans comme son frère reviewé par David, le bruit est aigu donc il irrite un peu les oreilles mais le niveau sonore est faible, mon alim. de labo velleman fait déjà plus de bruit...  
 
Pour la réactivité si on est en mode 10M / 40M points c'est pas top, mais si on sacrifie le nombre de points ça devient bien plus fluide. Cet oscillo c'est le monde du compromis.

 
Je ne comprends pas ton calcul. Pour ma part si je suppose 70ma pendant 5s (le temps que j'estime nécessaire pour se connecter, lire le capteur, et envoyer les données), j'arrive à 97 µAh en faisant une règle de trois . C'est que tu as mesuré la consommation réelle ?
 

 
Sur le papier c'est certes fabuleux mais comment je soude ça ? J'ai dû faire trois soudures dans ma vie pour changer des gros condensateurs...
 
J'ai suivi ton conseil et j'ai cherché un buck pour réguler la tension, mais j'en ai pas trouvé un qui m'aille bien. Soit le dropout était trop important, soit c'était la consommation en veille. J'ai trouvé un LDO par contre, le TPS7A05. Sauf si tu me le déconseille, je pense que je vais essayer avec ça, sans utiliser l'attiny13a. Ca permet de laisser toute la logique dans un seul contrôleur, que je peux paramétrer à distance en plus.
 
J'ai mesuré la consommation de mon capteur (3 mAh) et en utilisant les mesures de Natopsi, j'arrive à 2-3 ans sans avoir à charger la batterie. Je pense que le calcul est un peu pessimiste en plus mais même si en réalité ce n'est qu'un an, ça m'ira bien.
 
 

 
Venant du dev et n'ayant à peu près aucune connaissance en électronique, je me sens un peu concerné par ton laïus. Disons qu'on va vers ce qu'on connait à un moment. C'est plus facile de travailler avec un module wifi/IP pour commencer qu'avec des protocoles plus optimisés mais auxquels on ne s'est jamais intéressé. Avec les ESP, en quelques lignes de code, tu peux embarquer un serveur web, lire tes valeurs, les remonter en mqtt. Ce n'est qu'après que tu te rends compte que c'est pas forcément idéal sur d'autres aspects. Et puis à un moment, il faut bien progresser. C'est-à-dire s'améliorer en faisant les choses de mieux en mieux
 
Après concernant l'optimisation du code par rapport aux ressources matérielles, c'est plus une question de coût que de compétences personnelles (ou à la rigueur les deux dans la mesure où les personnes compétentes coûtent plus cher). Le hardware est souvent moins cher que le temps de travail d'un développeur C'est une tendance de fond qui est en place depuis des dizaines d'années.
 

 
Le gros avantage du software sur le hardware quand même, c'est que tu n'as pas besoin de hardware pour apprendre (je veux dire autre qu'un ordinateur)
 
Et quand tu n'es pas guidé, c'est pas forcément évident de comprendre que tu peux trouver des simulateurs en ligne. Après j'en ai pas trouvé de gratuit où tu peux simuler tout et n'importe quoi (en particulier des µc).

Pour le nRF :
Cartes de dev pas trop chères (30€)
- https://www.sparkfun.com/products/15025
- https://www.adafruit.com/product/4062  +  https://learn.adafruit.com/introduc [...] r/overview

Et pour embarquer sur une carte :un stick USB que tu peux souder (et couper le connecteur USB, cf la doc chapitre USB )
- https://www.nordicsemi.com/?sc_item [...] B6568C9%7D  (Buy Now)
- Dispo aussi chez RS : https://fr.rs-online.com/web/p/adap [...] h/1769054/
~15€

Pour les bucks :
- LTC3531, 125mA max @ 3Vout avec 2.5Vin : https://www.analog.com/en/products/ltc3531.html  pas trop complexe à mettre en oeuvre.
- LTC3532 : 500mA de courant, Vin = 2.4V-5.5V : https://www.analog.com/en/products/ltc3532.html rendement correct
Les deux ont des boitiers avec pattes pour être soudable facilement.

Le problème du LDO c'est que le rendement dépend de ta tension d'entrée et de sortie.

Voici la courbe de tension d'un module 18650 en fonction de la charge :

Faut calculer le rendement du LDO et comparer avec celui d'un buck.

D'autre part pour le LDO, même si c'est passant quand tu es en-dessous du dropout, faut voir comment il sors la tension, si elle est bruitée par exemple.
Y a quand même un risque quand tu es proche de la limite de dropout c'est que le LDO se mette à réguler, puis le Vin baisse, il régule plus, le Vin remonte légèrement, le LDO se remet à réguler, etc.

Le buck te permet d'utiliser la batterie jusqu'à une tension de 2.5V. Avec le LDO, si tu veux rester en régulation, tu devra te limiter à Vout + dropout.

Le problème c'est qu'on apprend plus à optimiser son soft, même un PC aujourd'hui c'est presque "unlimited resources" pour la plupart des softs.
Aujourd'hui tu veux faire de "l'embarqué", c'est genre Arduino + shield Ethernet ou même Wifi avec l'ESP. Genre tu utilise un µC 8 bits avec un SoC wifi qui a un µC 32 bits 10-20 fois plus puissant et qui consomme 100 fois plus. Tout ça pour envoyer la valeur du capteur de température à un serveur web pour sa centrale domotique...

Non l'optimisation c'est déjà réfléchir à son projet et à faire les choix pertinents : tu veux récupérer des valeurs de capteurs genre température, luminosité, humidité, c'est quelques bits toutes les minutes. Aucun besoin du Wifi qui sert à transmettre des centaines de Mbps. Aujourd'hui il y a plein de technos qui sont bien plus adaptées.

L'optimisation c'est un état d'esprit. En soft, perso je kiffe la demoscene et ce dont sont capables les mecs qui font des exe en 4kb ou même 16kb (ils ont droit à la DLL Direct3D). Ils comprennent ce qu'ils font : les graphismes c'est des maths mais avec un besoin de précision relatif, donc ils hésitent pas à optimiser leurs calculs en sacrifiant de la précision. Ils utilisent des algorithme de compression asymétriques : très long à la compression, très rapide à la décompression.

 
Merci
 
J'avais pas compris l'intérêt du boost dans ton message initial, j'ai regardé que les bucks stricts hier
 
Par contre j'avais vu que je risquais d'avoir des problèmes avec le LDO sur la baisse de tension. Mais à la grosse ça n'avait l'air de se produire qu'après avoir consommé 80-85% de la charge.
 
Je vais essayer les deux pour voir (en commençant par le LDO quand même ). Ca me laissera le temps d'acheter un oscillo. Je garde le bluetooth pour après. Encore merci.
 

 
Oui enfin l'arduino de ce que j'en comprends, c'est du matériel à destination des débutants pour s'initier. Les problématiques des débutants, ce n'est pas de faire l'optimisation mais de comprendre comment ça marche, pourquoi ça marche pas, arriver à faire quelque chose qui fonctionne à peu près, se débattre avec des dizaines de nouveaux concepts, arriver à les articuler et les bouffer, être capable de résoudre de plus en plus de problèmes, progresser, apprendre de nouvelles méthodes et techniques, de ses erreurs, etc. Par définition, les débutants ne font pas les choses correctement et encore moins de manière optimisée. C'est sûr que c'est grotesque tel que tu le décris mais ce n'est pas choquant, pour des débutants.
 
Pour le développement logiciel sur PC par des professionnels, c'est un vrai problème. Il est généralisé et en plus accentué par le fait que c'est compliqué de trouver de bons développeurs. Il y a peut-être aussi une part de principe de Peter => les bons développeurs sont peu à peu promus et cessent d'écrire du code. On a des problèmes importants de performance sur des fonctions de quelques logiciels au travail. C'est souvent lié à une manière complètement naïve d'utiliser les bases de données (les algos sont rarement bien compliqués dans l'informatique de gestion). Parfois aussi tu ouvres un écran, ça te bouffe 500Mo de mémoire. Quand tu fais remarquer aux développeurs qu'on faisait tourner windows XP sur des machines qui n'en n'avaient pas le quart, ils se vexent...
 

 
Oui enfin on ne peut pas comparer du travail d'orfèvre fait en assembleur avec ce qui est produit chez les éditeurs (en WinDev ). Après c'est vrai que ça a toujours été bluffant. Je me souviens de la sortie de second reality au milieu des années 90. C'était fou.
 
Dans la même veine, tu as certains virus qui sont extraordinaires à étudier et qui représentent aussi des prouesses technologiques. Lire par exemple: https://securelist.com/attacks-befo [...] tup/63725/ (et liens internes)

 
oui je voulais bien dire 4 voies    
Merci pour ce petit retour c'est sympa.
 
Il y a très peu d'info sur cet oscillo et a regarder la doc, le rapport presta/prix est très sympa donc je comprends pas trop.
 
C'est la batterie qui t'as fait choisir ce modèle plutôt qu'un Rigol ou un Siglent ?

L'Arduino ça reste un microcontrôleur 8 bits avec tout ce qu'il faut autour pour le programmer facilement en USB. Le souci c'est que tout l'aspect "électronique" est zappé. Peu de personnes ouvrent la datasheet de l'Attiny. D'ailleurs si tu demande le modèle du microncontrôleur, je pense qu'il n'y aura pas tant que ça qui te répondront "Attiny".
Beaucoup de question sur l'Arduino ont la réponse dans la datasheet, il faut néanmoins aider les débutant à déchiffrer, mais ils ne font pas l'effort de lire la datasheet. C'est la base de l'électronique pourtant.

On peut faire beaucoup de chose avec un Arduino, mais le problème c'est que certains shields ne sont pas pertinents pour un µC 8bits : Ethernet ou Wifi par exemple. Mais comme ce sont les technos des PC, osef on y va quand même.
Pendant des années j'ai essayé d'indiquer qu'il y avait d'autres technos pour remonter des infos de capteurs, mais personne n'écoute, ça n'interesse tout simplement pas les gens. Ils veulent du Wifi, de l'Ethernet, faut pas chercher plus loin que ça.

Je pense que les gens restent dans leur zone de confort, ils ont une habitude de développement, ils n'en change pas même si autour les technos ont évolué et qu'il y a des manières plus optimales. Probablement un manque d'intérêt pour le job aussi, la veille technos en souffre. (J'ai un collègue qui ne fait pas de veille techno, il reste dans sa zone de confort)

Faut arrêter avec la toute puissance de l'assembleur. Les demo sont principalement écrites en C et C++. Les compilateurs sont suffisamment bien développés pour qu'il optimise mieux que toi ton code que si tu écrivais en assembleur.
Il reste un peu d'assembleur dans les codes mais bon c'est plus quelques petites techniques et des habitudes qui restent qu'autre chose.

Les demos ce sont principalement des maths et un peu d'optimisation de code. Certains développeurs ont même créé des logiciels pour se simplifier le développement.
Tu as quelques articles ici : https://www.iquilezles.org/www/index.htm

Là où j'ai fait de l'assembleur dans un programme en C c'est quand je travaillais sur un DSP à l'école. Du fait de la présence de certaines opérations en hardware pour réaliser une multiplication et une addition en un seul coup d'horloge, il fallait mieux utiliser le code de l'opération en assembleur, le compilateur C était pas forcément capable d'optimiser ça. Bon c'était en 2010, je pense que ça a évolué depuis.

Encore faut-il regarder les bonnes datasheets .
Il me semble que c'est surtout des ATmega sur les Arduino. (Mais peut-être que l'IDE a été porté sur les ATtiny aussi, comme pour les MSP430, les ESPmachin et les STM32F103).

Perso, je ne sais pas bien coder, alors je fais tout ce que je peux en HW .

Du coup j'utilise souvent de l'arduino qui a l'avantage d'avoir une carte prête à utiliser sans debugger et pas chère (du coup on peut en avoir plein d'avance et osef si on en abime un peu une).

Eh oui. Et beaucoup de "Maker" se content d'embriquer des biblios toutes faites et se vantent après de maîtriser le C++ et d'avoir fait je ne sais quel bidule internet-3D-blockchain-IoT-lessive. (sans vouloir vexer qui que ce soit bien sûr. J'ai une image assez mauvaise du mot "maker", au contraire du mot "hacker" )

Après le soucis c'est pas de faire du mauvais code sur Arduino n'y d'utiliser des trucs pas adaptés quand on bricole chez soi, le soucis c'est quand les gens font ça à un niveau pro. J'ose dire qu'au niveau PC on a tellement de bloatware parce que aujourd'hui la plupart des gens sont incapables de te sortir un truc propre sans 1000 bibliothèques et autres frameworks. Programmer (pisser du code) c'est facile, bien programmer c'est autre chose.

C'est issite le topoc des aigris ?    

Pour faire les choses bien il faut prendre le temps de chercher des solutions, les comparer entre elles, en tester certaines, et le temps c'est de l'argent.  
Au niveau pro c'est pas mauvais de faire du prototypage rapide, le problème c'est qu'une fois que tu présente le proto aux décideurs pour eux t'as déjà un produit fini, même si tu émet toutes les réserves du monde hors de question de sortir du pognon pour carrosser tout ça sauf si c'est nécessaire de réaliser des économies d'échelle
 
Pis bon en système lourd, les outils de simulation sur lesquels je travaille, vu qu'on est pas sur un déploiement à grande échelle, c'est objectivement bien moins coûteux d'acheter de la mémoire vive que d'essayer d'éviter de l'utiliser.

 
Hum, pour le dev pas optimisé je doute quand même que ce soit ça. Si je reste sur les sgbd, tu as pléthore de programmeurs qui exécutent pleins de petites requêtes parce qu'ils ne savent pas comment fonctionne un sgbd et en particulier qu'ils ne connaissent pas la notion d'overhead ou n'ont pas idée de son importance C'est pourtant relativement intuitif que c'est beaucoup moins long de demander une fois à quelqu'un de faire 1000 fois quelque chose, plutôt que de lui demander 1000 fois de faire une fois cette même chose
 

 
J'ai pas commencé C'est juste que de mon temps (:o) les démos étaient faites en assembleur.
 

 
Non. Enfin pas dans le détail. Il optimise mieux que moi parce que je n'ai ni le temps ni l'envie d'écrire de l'asm optimisé pour une architecture bien précise. C'est une demi LU ça

Je vérifie l'assembleur généré par gcc pour les avr, et encore, juste les vecteurs d'interruption et les quelques fonctions les plus critiques.
Mais c'est plus pour vérifier si mon C est assez clair pour le compilateur que pour faire mieux que lui.
Pour un exécutable pc de 500k linké avec des dizaines de mégas de libs, je m'arrête à sysprof/valgrind ...  

Bondoir  

J'ai un soucis USB Type-C :-/

C'est chiant à câbler.
Du coup je me base sur les layout de routage que proposent les fabricants de multiplexeur dédiés à ce type de connecteur.

Sauf que ce que propose TI avec son HD3SS3220, est bizarre

Regardez la partie USB 2 (jaune/orange). Si je comprends bien, il fait comme pour les pistes de l'USB 3, il utilise des vias pour faire passer les pistes de derrières, de l'autre côté du connecteur. Sauf que celles de l'USB 2, sont croisées. Comment arrive-t-il de l'autre côté???

(Déjà le stub je trouve ca très moyen)

C'est un exemple, probablement simplifié, donc probablement faux en partie...

 
http://www.ti.com/tool/tida-00891?jktype=design
 
Download Design files :
 

 
TOP / Layer 3
 
 

Han, merci

Pas moyen de mettre des via entre les 2 rangés de pad/pin (design rules, avec les spec du fabricant) :-/

Bah fait un stub, avec les vitesses de l'usb 2.0 les électrons ne vont pas dérailler

Ca va pas faire de l'EMI qui va m'irradier?
 
 
Mais bon vais trouver une autre solution.
C'est courent que les fabricants de PCB chinois ne proposent pas de micro-vias???

C'est de l'USB 2.0 quoi... T'as le droit à 6 cm de skew entre D+ et D-, si tu prends en compte le cable, ça te laisse encore 4 cm, à l'échelle d'un routage c'est tout sauf une contrainte.
Ensuite avec ton connecteur full CMS, t'auras forcément un stub puisque t'as qu'un seul pad connecté.
 
Prends un connecteur CMS + TH et fais comme ça :

 
( https://electronics.stackexchange.c [...] hole-usb-c )
 
Les vrais fabricants chinois proposent les micro-vias. En revanche les PCB low-cost, non ça ne propose pas de µvia.
Faut savoir ce qu'on veut : du pas cher ou de la qualité.