Projet communautaire Arduino ATMEGA KNX

[condo4]

- 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 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.

C'est un peu la question que je me pose, ça stack est prévu pour être utiliser avec un TP-UART, donc, ne gère pas du tout les problème de timing... par exemple, pour émettre une trame, tu lui envoie la trame a 28KBaud (chiffre pas sur, a vérifier, mais bien plus vite que 9600) et le TP-UART gère le reste: Gestion des bits, des collisions, des ACK, des répétitions... bref, ton UC n'a que besoin d'un UART, le composant fait tout....
STKNX, c'est pas du tout ça... déjà, c'est pas un UART qu'il faut, mais des GPIO... dans l'idéal, 2 pour la com (TX et RX) mais en pratique, j'ai du mettre le RX sur 2 pattes, car une pour initialisé le timer, et l'autre pour déclancher une interruption...
Par exemple, pour écrire un 0 sur le bus, tu va devoir mettre 1 la GPIO TX 35µs, et 69µs a 0.
Une lecture, tu reçois 35µs a 1, et 69µs a zéro, et ce timing dois être plus que précis...
Pour la collision, pendant l’émission d'un 1 logique (donc pas d'écriture sur le bus), tu dois vérifier que RX ne change pas d'état...
Bref, c'est très complexe a gérer... D’où l'usage de timer / interruption comme je n'en avais jamais codé !!!
J'ai fait un push sur github, même si tout n'est pas fini:
https://github.com/condo4/LightKnxStack/tree/master --> STKNX/stknx_iface.c

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 du changer quelques composant de la BOM, mais je pouvais la faire en 25 jours...
Mais ce qui était cher, c'était ni le PCB (~70$/5 pc) ni la BOM (154$ / 5pc) mais tout les frais (Setup+Assembly+Operation: 232$)) --> 457$ pour 5 cartes, à cela on doit ajouter les frais de douane soit 600$ environ les 5 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).

Déjà, je pense que le besoin thermique dépend beaucoup de combien tu tire sur les alim DC/DC... Ensuite, je me suis rapproché de leur design (avec via thermique, et différents plan de masse sur les différents layer). D’ailleurs, sur leurs dessin de références page 57, je ne vois pas ou ils calcule 5500 mm² !! je pense qu'il y a erreur dans la datasheet.
Le composant prévoit de fonctionner jusqu’à 105°C avec le design de réference, même derrière un mure en ne consommant moins de 5W (10mA), je ne vois pas pourquoi ça chaufferait autant...
De plus, si ça chauffe un peu (Jonction supportant  quand même 150°C, y'a beaucoup de marge pour un composant consommant si peu), rien n’empêcherait de lui collé un mini radiateur (type Chipset pour rasberry), voir un pad thermique avec le boîtier...

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 ?

Justement, le STM32L432KC (comme ton µC je pense) ne sais pas gérer le protocole KNX sortie du STKNX (voir plus haut) car ce n'est pas une UART qu'il faut (contrairement au TP-UART ou NCN5130).
J'ai donc 2 GPIO pour RX (IRQ et Trigger Timer) et 1 pour TX (Cablé sur une sortie comparateur Timer), les deux autre sont des GPIO simple pour KNX_OK et VCC_OK effectivement.

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.

En faite, c'est un peu plus compliqué que ça... le ACK déjà doit être émit a un timing hyper précis après la fin de trame pour que TOUT les participants qui l'émettent le font au même instant pour que les signaux sur le bus se superposent...
Ensuite, le bus n'est libre qu'après 50 bit_times, ou 53 en fonction de la priorité de ta trame a émettre...
Bref, c'est assez casse tête, surtout qu'a c'est vitesse, impossible de l'écrire "traditionnellement" avec des boucles d'attente dans du code... seul un timers 32bits avec une horloge précise peut faire le boulot...
Pour bien comprendre tout ça, si tu a un compte KNX, tu peux lire "The KNX Standard v2.1/The KNX Standard v2.1/03 Volume 3 System Specifications/03_02_02 Communication Medium TP1 v01.02.02 AS.pdf" dans les specifications accessible avec ton compte gratuitement.

Bref, le STKNX est bien complexe a utilisé par rapport au TP-UART ou NCN5130, et la stack de Thelsing est très loin de pouvoir supporter ce genre de composant... d’où m'a ré-écriture from scratch (je m'inspire quand même de l'excellent travail qu'il a fait, mais certain choix comme le C++ pour ce genre de stack rende le code difficilement portable et relativement gros pour du micro-controleur.

Bon Week end