> Pour l'interface entre l'ATMEGA et le KNX : 2 transistors et une poignée de résistances et le tour est joué.
C'est un peu plus compliqué que ça si on souhaite respecter la norme KNX.
Il y a des règles assez contraignante sur la consommation de courant, les fronts, les timings... c'est pas juste, on a le droit de consomer 10mA, le protocole est loin d'être simple, on ne peut pas passer de 0mA a 10mA d'un coup, il y a plein de règles, par exemple, au branchement, tu ne peux pas charger directement une capa sur le DC du bus, tu dois limiter le courant de charge pour éviter de passer pour un 0 logique. Le STKNX résout les problèmes hardware, et en plus, contient un DC/DC bien pratique pour généré par exemple du 12V, bref, c'est une approche plus simple, et qui permet de respecter les règles de branchement au bus, mais ça ne gère ni les collisions, ni les timing précis a respecter, ça décode même pas totalement les bits comme un UART.
Concernant le Code; sans TP-UART (qui finalement, fait un gros travail, mais qui malheureusement est introuvable chez les fournisseurs "standard" comme mouser, ce qui est nécessaire pour faire router une carte sur seedstudio), même avec STKNX c'est pas simple. J'avance, mais je suis obligé d'utiliser des timer hardware et une gestion sur interruption car les règle sur les timings sont très serré, et la gestion de l'émission / réception des bits en gérant les collisions est compliqué. Une boucle simple a la arduino ne permettrait pas je pense de faire fonctionner le protocole en parallèle de l'application. C'est pour ça que souvent, un micro 8bit est en charge du protocole (le TP-UART en est un), et l'application est sur un autre micro.
Mon but est de tout faire avec un seul micro + STKNX... donc, utiliser les IT et les timers est indispensable.
Pour le moment, sur mon projet STKNX, j'ai la lecture qui fonctionne, jusqu’à la couche transport (réception des trames); je suis en train de recoder tout le protocole en C en me basant sur la spec officiel.
En bas niveau, il me faut encore géré les collisions et les ACK (d'ailleurs, j'ai du mal a voir quand et a quel layer les ACK doivent être géré).
En parallèle, j'ai un projet qui utilise un TP-UART et la stack thelsing C++, je suis en train de la transformer en pure C, pour au finale fusionner le code avec le bas de ma stack dans le but d'avoir une stack en C complète ( la couche application est assez complexe (en taille) et reprendre une partie du travail de Thelsing me gagne du temps, surtout sur la gestion des objets et de la mémoire).
Bref, je n'avance pas a la vitesse que j’espèrais (j'ai pas trop de temps a y consacrer), mais il manque vraiment une stack open source en C pas "typé Arduino"... Le code de thelsing est très bien, mais il est très gros (a cause du C++ je pense), très orienté Arduino uniquement, et ne permet pas facilement de le coupler a un STKNX (il manque aussi la gestion des ACK et collision, puisque le TP-UART le gère directement)...
De plus, pour ce genre de projet, utiliser des héritage C++ au lieu de #ifdef rend le code binaire encre plus gros, alors que finalement, sur un micro, dans un projet, une fois compilé, le code n'a pas besoin de gérer RF et TP par exemple, et une configuration précise par #ifdef permettrait de limiter la taille de la stack. D'ailleurs, en poussant un peu, on peut même imaginer choisir aussi les type de DPT supporté, aucun projet n'a besoin de décoder tout les types existant, et les fonctions de codage/décodage prennent une grosse place.
Bref, j'ai pas encore fini, je prévois une rev2 de ma carte, plus petite encore (pour le moment elle fait 40mmx35mm, je pense descendre a 35mmx30mm), en utilisant un oscillateur a la place du quartz (j'ai du me planter un peu dans mes calcules, et mon quartz n'a pas la précision attendu, ce qui me fait des erreur de décodage de 1% des trames pour le moment, et finalement, un oscillateur prendra moins de place que quartz + capa + résistances et imitera le nombre de composant nécessaire (pour limité le coût avec seeedstudio)).
C'est un peu plus compliqué que ça si on souhaite respecter la norme KNX.
Il y a des règles assez contraignante sur la consommation de courant, les fronts, les timings... c'est pas juste, on a le droit de consomer 10mA, le protocole est loin d'être simple, on ne peut pas passer de 0mA a 10mA d'un coup, il y a plein de règles, par exemple, au branchement, tu ne peux pas charger directement une capa sur le DC du bus, tu dois limiter le courant de charge pour éviter de passer pour un 0 logique. Le STKNX résout les problèmes hardware, et en plus, contient un DC/DC bien pratique pour généré par exemple du 12V, bref, c'est une approche plus simple, et qui permet de respecter les règles de branchement au bus, mais ça ne gère ni les collisions, ni les timing précis a respecter, ça décode même pas totalement les bits comme un UART.
Concernant le Code; sans TP-UART (qui finalement, fait un gros travail, mais qui malheureusement est introuvable chez les fournisseurs "standard" comme mouser, ce qui est nécessaire pour faire router une carte sur seedstudio), même avec STKNX c'est pas simple. J'avance, mais je suis obligé d'utiliser des timer hardware et une gestion sur interruption car les règle sur les timings sont très serré, et la gestion de l'émission / réception des bits en gérant les collisions est compliqué. Une boucle simple a la arduino ne permettrait pas je pense de faire fonctionner le protocole en parallèle de l'application. C'est pour ça que souvent, un micro 8bit est en charge du protocole (le TP-UART en est un), et l'application est sur un autre micro.
Mon but est de tout faire avec un seul micro + STKNX... donc, utiliser les IT et les timers est indispensable.
Pour le moment, sur mon projet STKNX, j'ai la lecture qui fonctionne, jusqu’à la couche transport (réception des trames); je suis en train de recoder tout le protocole en C en me basant sur la spec officiel.
En bas niveau, il me faut encore géré les collisions et les ACK (d'ailleurs, j'ai du mal a voir quand et a quel layer les ACK doivent être géré).
En parallèle, j'ai un projet qui utilise un TP-UART et la stack thelsing C++, je suis en train de la transformer en pure C, pour au finale fusionner le code avec le bas de ma stack dans le but d'avoir une stack en C complète ( la couche application est assez complexe (en taille) et reprendre une partie du travail de Thelsing me gagne du temps, surtout sur la gestion des objets et de la mémoire).
Bref, je n'avance pas a la vitesse que j’espèrais (j'ai pas trop de temps a y consacrer), mais il manque vraiment une stack open source en C pas "typé Arduino"... Le code de thelsing est très bien, mais il est très gros (a cause du C++ je pense), très orienté Arduino uniquement, et ne permet pas facilement de le coupler a un STKNX (il manque aussi la gestion des ACK et collision, puisque le TP-UART le gère directement)...
De plus, pour ce genre de projet, utiliser des héritage C++ au lieu de #ifdef rend le code binaire encre plus gros, alors que finalement, sur un micro, dans un projet, une fois compilé, le code n'a pas besoin de gérer RF et TP par exemple, et une configuration précise par #ifdef permettrait de limiter la taille de la stack. D'ailleurs, en poussant un peu, on peut même imaginer choisir aussi les type de DPT supporté, aucun projet n'a besoin de décoder tout les types existant, et les fonctions de codage/décodage prennent une grosse place.
Bref, j'ai pas encore fini, je prévois une rev2 de ma carte, plus petite encore (pour le moment elle fait 40mmx35mm, je pense descendre a 35mmx30mm), en utilisant un oscillateur a la place du quartz (j'ai du me planter un peu dans mes calcules, et mon quartz n'a pas la précision attendu, ce qui me fait des erreur de décodage de 1% des trames pour le moment, et finalement, un oscillateur prendra moins de place que quartz + capa + résistances et imitera le nombre de composant nécessaire (pour limité le coût avec seeedstudio)).