(07/11/2021, 16:14:46)" M2D a écrit : ...
De plus je me suis penché sur le datasheet du NCN5130 et je sais pas si tu l'a remarqué mais il a besoin d'une surface, pour la diffusion optimal thermique, non négligeable : 5500 mm² pour la face opposé, ce qui pour moi le disqualifie car le projet que je souhaite développer devra s'insérer dans une boite d'encastrement standard (diamètre de 65mm).
Pour le projet que je souhaite faire je pense donc, comme je le mentionne plus haut, me diriger vers le microcontrôleur RP2040 (rpi pico), pour plusieurs raison : La première étant la compatibilité avec le stack de Thelsin sans avoir à réinventer la roue; La seconde étant la possibilité de lui intégrer de la mémoire supplémentaire en cas de besoin (jusqu'à 128 Mb); il y a aussi sa faible consommation (inférieur à 10mA en utilisation normal) ou encore son faible encombrement, .....
Par contre, le problème de consommation peut être contourné par la deuxième alim de ton Siemens (les borne jaune et blanche) qui ont justement été a cet effet par la norme. Ce n'est pas non plus une alim miracle car en général c'est la même intensité délivré que celle du bus.
....
Bonjour Condo4,
J'ai remis ma "présentation" rapide, que j'avais faite, fin de page précédente, où je répond à quelques interrogations que tu as :
- J'utilise STKNX en simple converseur BUS KNX <--> UART, il va aussi me fournir 2 alims, une pour le µC 3.3 V et une 12V pour les cartes d'extensions.
- Pour le µC c'est la puce RP2040 (le µC utilisé par le rpi Pico), car il contient 2 port UART du fait des deux calculateurs intégrés, ainsi que l'intégration d'une mémoire flash pouvant aller jusqu'à 128 Mb et sa conso électrique tournant autour le 10 mA pour une utilisation "normal".
- Pour la stack se sera celle de Thelsing, qui a été porté sur le pico par lui. Donc quelques modifications mineur pour l'adapter sur la carte. Avec la flash je ne devrai avoir aucun souci de place.
J'espère que cela t'éclaire un peu plus.
Pour la question du prix des carte d’essais, la première simulation que j'ai faite, je me retrouve à environ une centaine d'euro pour 5 cartes mais comme mon BOM n'est pas bien agencé, je pense que cela va être au alentour des 250 euros pour le tous, soit 50 euros la carte. Mais ce qui me préoccupe le plus c'est plutôt la pénurie de composant, qui pour de simple diode peut être de plus de 60 semaines et vu les stocks que Mouser a, sur les autres références, cela peut aller très vite pour devoir changer l'empreinte de PCB
.J'ai une petite remarque à te faire (c'est pour faire avancer le schmilblick) : Je n'ai pas retenu le NCN5130 car je te disais de faire attention à la diffusion thermique du composant (page 57 du Datasheet NCN5130 ), comme les cartes vont êtres à termes dans les murs, les plafonds, etc... es-ce volontairement que tu a réduit la surface de diffusion thermique ou un oubli car divisé par 7 cette surface aura, pour moi, des conséquences sur le fonctionnement de ta carte (au mieux un dysfonctionnement aléatoire de la carte, au pire l'incendie).
J'ai aussi une question sur ta gestion de tes interruptions, timers. Es-ce du fait que tu utilises un µC stm32 qui fait que tu dois gérer l'attente d'octet venant ou allant vers le Bus ou cela vient du STKNX ?
Autre question, tu parles de 5 IO qui sont nécessaire pour le STKNX pour moi 2 sont obligatoires (TX/RX), 2 autres sont optionels mais peuvent être très utile pour la gestion de l'alimentation (VCC_Ok et KNX_Ok) mais quel est la cinquième IO que tu as besoins ?
Tu vois je suis encore au début de mon projet, j'ai encore pas mal d'interrogation sur certain niveau, mais je continue mon petit chemin.
Au fait, si je me rappelle bien (je crois que c'est défini dans le "CookingBook KNX"), il existe 3 états du bus : ACK, NAK et Busy. ACK correspond bien sur que tous à bien été reçu; NAK il y eu un problème de transmission ou de réception et une demande de renvoie du télégramme si celle-ci a été défini; Et Busy il y saturation ou transmission en cours.
Donc, le module dès qu'il détecte un début de trame sur le bus doit considérer le bus en flag Busy et quand il détecte l'ACK suivant il revient en mode transmission.
Pour éviter les collisions, il me semble que les modules ne peuvent envoyer une trame qu'après un temps de repos aléatoire qui sera redéfinie à chaque libération du bus.
Si cela peut d'aider.
Cordialement
@RichardPub
Bonjour,
Tu entends quoi par processeur, si c'est sur quelle plateforme (µC) c'est un arduino que Thelsing l'a développé et moi mon développement sera sur Pico. Après je pense que cela doit être portable sur d'autre plateforme avec les bon outils de compilation.