Se connecter

richardpub · 10/12/2021, 00:30:57

(08/11/2021, 19:00:30)M2D a écrit : Bonjour,

La je ne sais pas quoi te dire , si tu es sous Windows pour renommer un fichier dans l’exploreur de dossier c'est la touche F2, ou click droit renommer, pour le dos c'est la commande "ren", sous Linux c'est "mv". C'est une des bases quand on fait de la programmation ....
Sinon oui j'utilise le CreateKnxProd que j'ai compilé du stack de Thelsing, j'ai pri son fichier xml d'exemple que j'ai chargé dans l'application compilé, je l'ai exporté, ce qui m'a créé un fichier knxProd que j'ai renommé pour que tu puisse le récupérer. Voilà je ne sais pas quoi tu dire de plus, à part utiliser Visual express 2017 pour utiliser la stack.

J'espère que tu vas pouvoir essayer le fichier demo car pour moi j'ai du mal à voir comment tu vas pour faire communiquer le bus KNX avec le module non KNX sans faire une interface de communication.

Peux-tu me dire sur quel processeur tu as installé knx-demo.ino???

M2D · (Modification du message : 10/12/2021, 15:09:21 par M2D.)

(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 Dodgy

.

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.

condo4 · 10/12/2021, 18:30:52

Citation :- 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

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

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

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

Citation :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

richardpub · (Modification du message : 11/12/2021, 11:02:50 par richardpub.)

(10/12/2021, 14:56:08)M2D a écrit : @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.

J'utilise un Mode MCU esp 8266

Tu parles d'Arduino comme plateforme, mais un contact avec Thelsing sur son Github, me disait qu'il na pas développé pour l'Arduino, bien qu'il utilises l' IDE Arduino pout les téléchargement.
C'est pour cela que je suis parti vers les ESP8266.

M2D · 11/12/2021, 10:53:47

(10/12/2021, 19:14:02)richardpub a écrit :
(10/12/2021, 14:56:08)M2D a écrit : @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.

J'utilise un Mode MCU esp 8266

Bonjour,
La carte que tu as se programme via l'IDE Arduino, donc il ne devrait pas avoir de problème.

Condo4 a écrit : a écrit :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

.........

Merci de cette remarque car je pensai que que le datasheet réexpliqué succinctement la norme et donc le l'avais survolé.
En fait, je pense que Thelsing a vu que le bus pouvait être échantillonner de façon plus fine ( Attention je ne me suis toujours pas penché sur la relecture de son code), je pense qu'il a vu que le bus pouvez être lu sur 28800 Baud/s, ce qui donne un cycle de 34.66 µs par cycle et que 3 cycles donne bien les 104 µs. Après il est fort possible que que la norme pris les arrondis pour simplifier les textes et discours de formation ( mais la c'est ma supposition).
En part de ce fait, je m'attend à en fait de devoir gérer les parités, ACK, ect..... mais ce sera traité dans ma partie software.
Pour la connexion des pins du RP2040, je me suis mal exprimé car les 30 GPIO peuvent être autant des GPIOx, que PIOx, que UARTx, ect... Donc oui c'est bien 2 GPIO qui serviront à TX et RX

Condo4 a écrit : a écrit :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...

Les pénuries et aussi les frais de douanes (j'avais aussi çà dans la tête), m'ont fait plutôt rechercher des entreprises locales pour mes cartes tests. Je préfère payer 50 € de plus que d'avoir des colis bloqué ou perdu on ne sais où.

Pour le standard KNX, il est vrai que cela fait plus trois an que je n'ai pas ouvert les pdf, donc je me rend compte que j'ai beaucoup de "trou" sur le norme.

Bon week end à toi aussi.
Au plaisir.

condo4 · 11/12/2021, 11:26:40

Citation :En fait, je pense que Thelsing a vu que le bus pouvait être échantillonner de façon plus fine ( Attention je ne me suis toujours pas penché sur la relecture de son code), je pense qu'il a vu que le bus pouvez être lu sur 28800 Baud/s, ce qui donne un cycle de 34.66 µs par cycle et que 3 cycles donne bien les 104 µs. Après il est fort possible que que la norme pris les arrondis pour simplifier les textes et discours de formation ( mais la c'est ma supposition

En faite j'ai peur que ce soit plus complexe que ça... et que l'uart ne puisse pas etre utilisé...
Déjà a chaque bit il faut gérer la collision, le ack doit être géré a la micro seconde prêt, ce qui est totalement impossible en soft pure, de plus les bytes font 13 bits, si on utilise le sur echantillon x3 sans parité il faudrait un uart 39 bit, et souvant c'est pas vraiment possible...
Pour gérer le ack, j'ai du gérer couche data link des les handler d'it, c'est seulement a partir de la couche réseau qu'il est possible de gérer dans du soft "asynchrone"...
Concernant la fabrication de la carte par des boite française, tu as trouver des boîtes qui te font des serie de 5 cartes a moins de 1000€ ?
Je peux souder la face bottom moi-même, du coup je veux ressayer une cotation avec que les composant delicat a faire souder, et garder les diode, capa et resistance pour moi...
Surtout que je me suis limité aux 0603... sur mon 1er proto, j'ai du souder des 0402 et meme si j'y suis arrivé, c'est la limite de mes competances...
Bonne chance :-)

richardpub · 11/12/2021, 11:49:01

(11/12/2021, 10:53:47)M2D a écrit :
(10/12/2021, 19:14:02)richardpub a écrit :
(10/12/2021, 14:56:08)M2D a écrit : @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.

J'utilise un Mode MCU esp 8266

Bonjour,
La carte que tu as se programme via l'IDE Arduino, donc il ne devrait pas avoir de problème.

Je n'ai pas de problème pour programmer le Node MCU esp 8266 avec l'IDE Arduino, mais le problème que je ne sais pas résoudre c'est qu'une fois le participant créé avec le fichier knx-demo.knxprod importé dans le catalogue, lorsqu'il me demande d'appuyer sur le bouton de programmation lors du téléchargement complet (théoriquement le bouton flash de l'ESP8266) la Led de programmation se met en bleu fixe, et rien ne se passe, et je finit donc en erreur dans ETS5.
Je pense qu'il faut que je rentre dans le code de Thelsing, pour comprendre comment cela devrait fonctionner.
Je suis vraiment bloqué à ce niveau, et je ne comprend pas pourquoi. Pourtant avant de nager dans la création des fichiers .knxprod, j'avais réussi à être fonctionnel au téléchargement avec le Node MCU esp 8266.

abnaxus · 11/12/2021, 13:41:01

J'avais aussi pas mal galéré pour utiliser la stack, mais après quelques tweaks, ca marche pas trop mal. Je l'utilise avec des ESP32 et stm32. mais il faut mettre la main à la pate, et avoir son débuggeur sous la main aide beaucoup. Il y a des bugs!!! N'hésite pas à faire des PR, Thelsing a pris de la distance sur le projet mais accepte les PR Wink

Sinon question bête, car j'avais eu le même problème que toi sur un de mes projets (je n'ai jamais joué avec les exemples):
Ton participant est bien visible en mode prog dans ETS?
Si ce n'est pas le cas, en dehors d'une erreur d'elec (cablage, tensions...), la valeur par defaut du participant (0) est une valeur invalide et pose des problèmes avec ETS. Je te conseille de la changer dans le code par exemple avec 1 (knx.bau().deviceObject().individualAddress(1) Wink

abnaxus · 11/12/2021, 13:50:29

Juste un ajout concernant les préoccupations de footprint de la stack, hormis le c++, il y a des define à utiliser pour réduire l'usage des printf mais surtout des conversions string->float ou l'intialisation de plusieurs buffer d'uart par arduino!
C'est documenté dans le config.h

richardpub · 11/12/2021, 18:12:50

(11/12/2021, 13:41:01)abnaxus a écrit : J'avais aussi pas mal galéré pour utiliser la stack, mais après quelques tweaks, ca marche pas trop mal. Je l'utilise avec des ESP32 et stm32. mais il faut mettre la main à la pate, et avoir son débuggeur sous la main aide beaucoup. Il y a des bugs!!! N'hésite pas à faire des PR, Thelsing a pris de la distance sur le projet mais accepte les PR
Sinon question bête, car j'avais eu le même problème que toi sur un de mes projets (je n'ai jamais joué avec les exemples):
Ton participant est bien visible en mode prog dans ETS?
Si ce n'est pas le cas, en dehors d'une erreur d'elec (cablage, tensions...), la valeur par defaut du participant (0) est une valeur invalide et pose des problèmes avec ETS. Je te conseille de la changer dans le code par exemple avec 1 (knx.bau().deviceObject().individualAddress(1)

Ton participant est bien visible en mode prog dans ETS?
Ai-je bien compris ta réponse?? Comment peut-il être visible???
ci-joint une copie de mon ETS, le participant est Temperatursensor: [Image: 21121106311925602917709033.gif]

Tu veux dire que je vois bien mon participant dans ETS et que je peux y associer des groupe adresses. C'est le cas... Par contre le participant knx-demo est en 1.0.xx alors que mes participants classiques de mon installation, sont en 1.1.xxx cela pourrait-il être la raison de mes soucis??? le participant knx-demo fonctionne lui en IP multicast.

Merci pour votre aide.

abnaxus · 11/12/2021, 18:40:50

Non, dans le Tab "Bus", tu as:
Diagnostics/Addresses Individuelles/Mode de Programmation.
Ici tu mets ton participant en mode programmation, et tu cliques sur démarrer.
Il devrait apparaître avec son adresse préconfigurée.
S'il n'apparait pas, soit il y a un problème dans le code/montage, ou il y a un problème de communication.
Par défaut, avec l'adresse individuelle à 0, j'ai eu des soucis (confirmés par d'autres). Il faut la changer par n'importe quoi d'autre de licite (perso, j'utilise 1).

Si rien de tout ca ne fonctionne, l faut passer par du debug Sad

...
(je n'ai fait que du TPUART, je n'ai jamais utilisé les autres modes ni utilisé les exemples, mais comme je l'ai dit, la stack n'est pas bullet proof, et il a fallu se retrousser les manches pour la chasse aux bugs et avec l'esp en debug par printf sur la liaison serie c'est pas la gloire Sad

...)

richardpub · 12/12/2021, 10:53:02

Merci pour ta réponse je regarde de ce pas...
Heureusement je ne compte pas mon temps, pour arriver à un résultat correct.

richardpub · 12/12/2021, 11:06:39

Je ne connaissais pas cette partie du diagnostic.

Et effectivement je n'ai rien de présent en mode programmation.

Je te cite : "Par défaut, avec l'adresse individuelle à 0, j'ai eu des soucis (confirmés par d'autres). Il faut la changer par n'importe quoi d'autre de licite (perso, j'utilise 1)."

A quel niveau, renseignes-tu l'adresse individuelle???

Quand je cherche à modifier le participant de 1.0.x en 1.1.xx, j'ai cette erreur.

[Image: 21121211242225602917709616.gif]

abnaxus · 12/12/2021, 11:29:30

Pour le moment le problème ne vient pas d'ETS, on va juste se focaliser sur l'adresse individuelle et s'assurer que ca communique.
Pour changer l'adresse individuelle par défaut de (0) à (1).
Il faut modifier le fichier .ino et ajouter avant le knx.readMemory() la ligne suivante:
knx.bau().deviceObject().individualAddress(1);
Recompiler et uploader dans ton esp.

Normalement, ton device devrait être vu par ETS avec la manip précédente. Si c'est le cas, tu devrais pouvoir programmer ton participant.
Sinon, il faut voir ou ca coince.
Comme ça, comme tu es en IP, j'utiliserais un sniffer (wireshark par ex) et regarder si tu vois des trames passer.

M2D · (Modification du message : 12/12/2021, 23:30:45 par M2D.)

(11/12/2021, 11:26:40)condo4 a écrit : En faite j'ai peur que ce soit plus complexe que ça... et que l'uart ne puisse pas etre utilisé...
Déjà a chaque bit il faut gérer la collision, le ack doit être géré a la micro seconde prêt, ce qui est totalement impossible en soft pure, de plus les bytes font 13 bits, si on utilise le sur echantillon x3 sans parité il faudrait un uart 39 bit, et souvant c'est pas vraiment possible...
Pour gérer le ack, j'ai du gérer couche data link des les handler d'it, c'est seulement a partir de la couche réseau qu'il est possible de gérer dans du soft "asynchrone"...
Concernant la fabrication de la carte par des boite française, tu as trouver des boîtes qui te font des serie de 5 cartes a moins de 1000€ ?
Je peux souder la face bottom moi-même, du coup je veux ressayer une cotation avec que les composant delicat a faire souder, et garder les diode, capa et resistance pour moi...
Surtout que je me suis limité aux 0603... sur mon 1er proto, j'ai du souder des 0402 et meme si j'y suis arrivé, c'est la limite de mes competances...
Bonne chance :-)

Cela fait plus de trois an que je n'avais pas remis le nez dans la document du standard KNX, elle n'a pas changé elle est toujours de 2013 Big Grin

, donc je vais vous abandonnez quelques temps pour m'y replonger. Il y a quand même une tolérance sur les 35µs tant pour l’émission (min : 34 µs et max : 36 µs) que pour la réception (min : n bit - 2 µs et max : n bit + 2 µs), donc le fait de multiplier par trois la vitesse de transmission doit être possible après les parités et le stop devra être gérer à la main. Mais ce sera plus tard, car je souhaite faire une carte d'essai pour le STKNX, pour valider cela.

En parlant dans standard knx, je cherche le volume 1 : Primer du knx spécification, donc si quelqu'un l'a je serai heureux de l'avoir, merci.

Pour le fabricant français la centaines d'euro que j'annonçais c'est justement une boite française où j'ai fais le devis. Là je pense, que beaucoup de personnes ont des aprioris, mais comme pour se type de montage quasiment tout est automatisé, la différence n'est fait (et ce n'est que mon avis) sur la disponibilité des composants. Après certaines sociétés ne veulent pas travailler avec des particuliers ou ne souhaite pas remettre en cause leur grille tarifaire. C'est un autre débat.

Sinon bravo pour l'envie de souder si petit, je n'ai pas cette équipement (pâte à braser, fer , etc...), après je ne sais pas si la douane changera, des composants y seront monté.

@RichardPub
Il faudra que tu change en effet l'adresse individuel car tu as un seul coupler de ligne qui doit être une extension au nombre de participants (>63) pour le mettre à la suite. Il me semble aussi que l'adresse individuel "sortie d'usine" d'un participant est 255.255.255 ou 0.0.0 (il me semble que c'est le premier), cela peut expliquer ton problème, mais je pense que abnaxus est beaucoup plus calé sur les subtilité de la stack de Thelsing.

Bonne soirée

richardpub · 13/12/2021, 09:58:15

(12/12/2021, 11:29:30)abnaxus a écrit : Pour le moment le problème ne vient pas d'ETS, on va juste se focaliser sur l'adresse individuelle et s'assurer que ca communique.
Pour changer l'adresse individuelle par défaut de (0) à (1).
Il faut modifier le fichier .ino et ajouter avant le knx.readMemory() la ligne suivante:
knx.bau().deviceObject().individualAddress(1);
Recompiler et uploader dans ton esp.

Normalement, ton device devrait être vu par ETS avec la manip précédente. Si c'est le cas, tu devrais pouvoir programmer ton participant.
Sinon, il faut voir ou ca coince.
Comme ça, comme tu es en IP, j'utiliserais un sniffer (wireshark par ex) et regarder si tu vois des trames passer.

Je suis absent pendant 2 jours J'ai commencé à tester.
Merci pour ton aide précise.

abnaxus · 13/12/2021, 09:58:31

@RichardPub
Par curiosité, j'ai fait un test avec un esp8266 que j'avais sous la main pour un bricolage pour ma chérie ;p.
Bon c'est pas gagné...
J'ai constaté un problème d'envoi de trame sur le réseau...
La stack recoit bien les messages, répond, mais les envois de trames sont aléatoires (il a fallu attendre un peu pour voir mon participant envoyer quelque chose et qu'ETS le voit au passage).
Pour info, il faut également, bien setter le MASK_VERSION=0x57B0
Apparemment concernant le problème de trame, je ne suis pas le seul à l'avoir, certains conseils un delay/yield après le write, mais sans succès de mon côté. Je n'ai pas investigué davantage.
Tu peux tester de ton coté, en décommentant les printHex dans EspPlatform: Confused

endBytesMultiCast et EspPlatform::readBytesMultiCast

richardpub · 13/12/2021, 10:08:22

Je n'arrive pas à copier directement le moniteur série de l'IDE Arduino
[Image: 21121310282225602917710966.gif]

abnaxus · 13/12/2021, 10:13:44

Ce log est normal, si tu décommentes les printHex, tu devrais voir ce que ton participant reçoit et répond.
Avec Wireshark tu pourras également voir ces mêmes trames transiter (mon problème est que les envois ne passent pas toujours). Je soupçonne une spécificité du framework de l'esp mais je n'ai pas regardé plus que ça, si ça se trouve ça passera chez toi.

richardpub · 13/12/2021, 16:56:10

Je regarde des mon retour
Cela expliquerait que j’ai déjà réussi sans trop savoir pourquoi, et que je n’y arrive plus
À plus

richardpub · 14/12/2021, 19:52:40

Je ne suis pas un champion de wireshark, mais les seules choses que je vois passer ce sont les demandes d'ETS5 en demande de téléchargement vers la passerelle 224.0.23.12 ,
et de ma passerelle IP/KNX vers la passerelle 224.0.23.12 .
Je ne vois rien venant de l'ESP8266;

Je te joins le code de L'ESP8266/

Code :
#include <Arduino.h>

#include <knx.h>

#if MASK_VERSION != 0x07B0 && (defined ARDUINO_ARCH_ESP8266 || defined ARDUINO_ARCH_ESP32)

#include <WiFiManager.h>

#endif

// create named references for easy access to group objects

#define goCurrent knx.getGroupObject(1)

#define goMax knx.getGroupObject(2)

#define goMin knx.getGroupObject(3)

#define goReset knx.getGroupObject(4)

float currentValue = 0;

float maxValue = 0;

float minValue = RAND_MAX;

long lastsend = 0;

void measureTemp()

{

    long now = millis();

    if ((now - lastsend) < 2000)

        return;

    lastsend = now;

    int r = rand();

    currentValue = (r * 1.0) / (RAND_MAX * 1.0);

    currentValue *= 100 * 100;

    // write new value to groupobject

    goCurrent.value(currentValue);

    if (currentValue > maxValue)

    {

        maxValue = currentValue;

        goMax.value(maxValue);

    }

    if (currentValue < minValue)

    {

        minValue = currentValue;

        goMin.value(minValue);

    }

}

// callback from reset-GO

void resetCallback(GroupObject& go)

{

    if (go.value())

    {

        maxValue = 0;

        minValue = 10000;

    }

}

void setup()

{

    Serial.begin(115200);

    ArduinoPlatform::SerialDebug = &Serial;

    randomSeed(millis());

#if MASK_VERSION != 0x07B0 && (defined ARDUINO_ARCH_ESP8266 || defined ARDUINO_ARCH_ESP32)

    WiFiManager wifiManager;

    wifiManager.autoConnect("knx-demo");

#endif

    // read adress table, association table, groupobject table and parameters from eeprom

    knx.bau().deviceObject().individualAddress(1);

    knx.readMemory();

    // print values of parameters if device is already configured

    if (knx.configured())

    {

        // register callback for reset GO

        goReset.callback(resetCallback);

        goReset.dataPointType(DPT_Trigger);

        goCurrent.dataPointType(DPT_Value_Temp);

        goMin.dataPointType(DPT_Value_Temp);

        goMax.dataPointType(DPT_Value_Temp);

        Serial.print("Timeout: ");

        Serial.println(knx.paramByte(0));

        Serial.print("Zykl. senden: ");

        Serial.println(knx.paramByte(1));

        Serial.print("Min/Max senden: ");

        Serial.println(knx.paramByte(2));

        Serial.print("Aenderung senden: ");

        Serial.println(knx.paramByte(3));

        Serial.print("Abgleich: ");

        Serial.println(knx.paramByte(4));

    }

    // pin or GPIO the programming led is connected to. Default is LED_BUILTIN

    // knx.ledPin(LED_BUILTIN);

    // is the led active on HIGH or low? Default is LOW

    // knx.ledPinActiveOn(HIGH);

    // pin or GPIO programming button is connected to. Default is 0

    // knx.buttonPin(0);

    // start the framework.

    knx.start();

}

void loop()

{

    // don't delay here to much. Otherwise you might lose packages or mess up the timing with ETS

    knx.loop();

    // only run the application code if the device was configured with ETS

    if (!knx.configured())

        return;

    measureTemp();

}

C'est un peu comme si le wifi n'arrivait pas jusqu'à mon réseau. Pourtant je vois bien mes autres appareils en WIFI sur le réseau.????

richardpub · 15/12/2021, 00:11:04

le temps d'envoyer le message et l'idée m'est venue de rallonger à 20 secondes le code:

Code :
void measureTemp()

{

   long now = millis();

   if ((now - lastsend) < 2000)

et du coup je vois passer l'IP de mon ESP8266 vers le multicast. mais ca ne fonctionne pas

richardpub · 16/12/2021, 17:56:30

C'est visiblement au niveau du "if (knx.configured())'=" que ca coince. Sauriez vous me dire dans quelle partie des sources cela est-il programmé.

abnaxus · 16/12/2021, 18:18:55

Je ne comprends pas ce que tu veux dire?
Si ton device n'est pas configuré, il attend de l'être et ne fait pas de mesure, c'est le comportement normal. Une fois programmé, il redémarre et prend les mesures pour les envoyer sur le bus.

Je ferais un test quand j'aurais un peu plus de temps avec un esp32 voir si j'ai le même phénomène.

abnaxus · 16/12/2021, 18:25:28

Tout se passe dans le knx.loop()
knx.configured() est juste un getter.

Se connecter
Utilisateur :
Mot de passe :	Mot de passe oublié ?
	Se rappeler