mercredi 24 décembre 2014

ATmega168pb, le 8 bits à la fête! Aperçu du kit Atmel ATmega168 X PLAINED.

And now for something completely different…

Après avoir posté quelques billets sur différents micro-contrôleurs, notamment ceux de la famille Z8F de Zilog, les circuits 32 bits de chez Microchip dans une application bien pensée que sont les produits Maximite et Micromite, ou encore les circuits compatibles ARM0 de NXP, aujourd'hui je propose un très petit aperçu des composants 8 bits de chez Atmel. En l’occurrence le processeur ATmega168pb, nouvellement présenté et dont la découverte est facilitée par un kit d'évaluation nommé 'ATmega168 X PLAINED Mini'.


Ce qui est intéressant avec ce nouveau micro-contrôleur, bien que ce soit un processeur 8 bits, c'est qu'il propose une architecture RISC rapide, un prix très réduit malgré la présence d'un nombre assez important de périphériques embarqués, et la mise à disposition de la part d'Atmel d'un logiciel de développement/programmation intégré de bonne facture. En un mot, Ce circuit se présente un peu de la même façon que les Z8F de Zilog.

En résumé, voici ce que nous propose un ATmega168pb (extrait de la documentation Atmel):

  • Up to 20 MIPS Throughput at 20MHz
  • On-chip 2-cycle Multiplier
  • 16KBytes of In-System Self-Programmable Flash program memory
  • 512Bytes EEPROM
  • 1KBytes Internal SRAM
  • Two 8-bit Timer/Counters with Separate Prescaler and Compare Mode
  • 16-bit Timer/Counter with Separate Prescaler, Compare Mode, and Capture Mode
  • Real Time Counter with Separate Oscillator
  • Six PWM Channels
  • 8-channel 10-bit ADC with Temperature Measurement
  • Programmable Serial USART with Start of Frame Detection
  • Master/Slave SPI Serial Interface
  • Byte-oriented 2-wire Serial Interface (Phillips I 2 C compatible)
  • Programmable Watchdog Timer with Separate On-chip Oscillator
  • On-chip Analog Comparator
  • Interrupt and Wake-up on Pin Change
  • Six Sleep Modes: Idle, ADC Noise Reduction, Power-save, Power-down, Standby, and Extended Standby
  • 27 Programmable I/O Lines

...pour les caractéristiques essentielles, ce qui présente tout de même un certain potentiel de flexibilité dans un très petit circuit. Il pourrait se placer entre les micros de chez Zilog avec plus de rapidité d'exécution et plus de périphériques embarqués, et les 32 bits de chez Microchip en présentant certes moins de puissance de calcul, mais aussi une bien plus grande facilité dans la gestion du placement des périphériques sur les pattes de sorties.

La page du site d'Atmel ou il est possible de commander le kit d'évaluation :

http://store.atmel.com/PartDetail.aspx?q=p:10500404#tc:description
Avant toute tentative d'utilisation de ce kit, il convient de télécharger le logiciel de développement Atmel Studio 6. Et de constater que le package d'installation constitue un joli pavé de près de 700Moctets de données, auxquelles il conviendra de rajouter 200Moctets de mises à jours diverses et variées à la date de ce billet. Bien plus que ce que Propose Zilog avec son logiciel de développement. Point intéressant : l'application de programmation en Flash du micro-contrôleur fait parti du logiciel de développement. Inutile donc de chercher sur la toile, une solution tierce 'gratuite' susceptible de ne pas fonctionner correctement, comme ce qui aurait pu être mon cas avec le logiciel FlashMagic si les développeurs de cet utilitaire n'avaient pas réagi très rapidement à ma demande de correction pour son bon fonctionnement avec le processeur NXP LPC810.

Une fois Studio 6 installé et la carte d'évaluation connectée dans un port USB libre de la machine de développement, le premier lancement de Studio 6 fait apparaître l'environnement de développement ainsi qu'un onglet affichant le matériel compatible Studio découvert :

http://synthelectro-fr.blogspot.com
Rapidement, l'envie d'en savoir un peu plus sur le fonctionnement de l'environnement de développement et sur le micro-contrôleur pousse à tenter une première programmation. Sur le site d'Atmel, se trouve un programme d'exemple appelé 'Morse' censé présenter par le clignotement de la LED utilisateur présente sur la carte d'évaluation, le code Morse correspondant à ce que l'on aura fournit au processeur par l'intermédiaire de son port Série. C'est d'ailleurs cette application qui est programmée dans le kit d'évaluation permettant, à défaut de savoir dans un premier temps de quoi il s'agit, de constater qu'il y a de la vie lorsque l'on connecte la carte au PC. C'est déjà ça.

Une constatation intéressante concernant le mode de programmation de la Flash du micro-contrôleur, concerne le fait que celui-ci s'effectue par le port SPI du circuit. Laissant ainsi libre le port série pour tout type d'expérimentations. Cela peut peut-être paraître anodin, mais il m'est arrivé quelques mésaventures avec un circuit LPC1114 répondant 'synchronized' à une suite d'octets envoyés sur son port série, alors qu'il n'était nullement en mode programmation, le système de détection automatique de 'baud rate' du LPC1114 se déclenchant à 'l’insu de mon plein gré' !!!

Plutôt que de compiler de nouveau cette application et de la re-programmer dans le processeur, j'ai préféré partir de zéro et écrire un programme simple envoyant quelques caractères par le port série.

Et voici le 'programme du siècle', ou plus simplement un 'Hello World' un peu plus évolué que l'habituel clignotement d'une LED :
/*
 * TestCom.c
 *
 * Created: 23/12/2014 10:34:39
 *  Author: eric
 */ 

#include <avr/io.h>

#define F_CPU                   16000000UL  // Oscillateur interne à 16MHz
#define LED_ON                  PORTB |=  (1<<PORTB5)
#define LED_OFF                 PORTB &= ~(1<<PORTB5)
#define USART_BAUDRATE          9600
#define BAUD_PRESCALE           (((F_CPU / (USART_BAUDRATE * 16UL))) - 1)

void InitSystem(void);

int main(void)
{
unsigned long Temp;
 
 InitSystem();
 
    while(1)
    {
     //TODO:: Please write your application code 
        while (!(UCSR0A & (1<<UDRE0)));
        UDR0 = 'D';
        for (Temp = 10000000; Temp; Temp--);
        while (!(UCSR0A & (1<<UDRE0)));
        UDR0 = 'F';
    }
}

void InitSystem(void)
{
 DDRB |= (1<<PORTB5);                   // PB5 en sortie (LED0)
 PORTB |= (1<<PORTB5);                  // PB5 pullUp
 LED_OFF;                               // start with the LED off

 UCSR0B = (1 << RXEN0)  | (1 << TXEN0); // Autorisation RX/TX
 UCSR0C = (1 << UCSZ00) | (1 << UCSZ01);// Mode 8 bits

 UBRR0H = (BAUD_PRESCALE >> 8);         // Baud rate LSB du registre UBRR
 UBRR0L = BAUD_PRESCALE;                // Baud rate MSB du registre UBRR
}
Rien de bien compliqué en somme si ce n'est qu'en guise de clignotement de LED, le caractère 'D' est envoyé par le port série puis, après une boucle vide comptant jusqu'à 10.000.000, le caractère 'F' est envoyé à la console, le tout, dans une boucle sans fin. Ce simple programme m'a permis de constater que la boucle de comptage s'effectue en 6 secondes.

Une fois ce programme compilé, un simple démarrage de session de débogage permet de lancer la programmation de la flash du composant puis de démarrer le programme interne. Il est tout à fait plaisant de constater que dès lors, toutes les opérations permettant l'évolution en pas à pas du programme ainsi que la visualisation des variables et des mémoires internes au processeur sont accessibles simplement, et en temps réel, ainsi que la gestion des points d'arrêts. Je retrouve ici tout ce qui fait l'efficacité de la solution Zilog.

Session typique de débogage sous Studio 6. 
Un petit mot sur le processeur lui-même : il s'agit, donc, d'un processeur 8 bits. De ce fait, il ne présente pas la complexité d'un circuit même 'simple' de type ARM comme le LPC1114FN28 de NXP. Les mnémoniques assembleur utilisées sont très simples ainsi que l'architecture des registres. Lors de l'élaboration du programme ci-dessus, je n'ai absolument pas utilisé quelque librairie Atmel que ce soit. J'ai programmé directement les registres concernés par mon 'application', tout simplement. Je retrouve avec ce système, comme je l'ai rappelé précédemment, toute la facilité et la rapidité de développement que propose les circuits Zilog, tout en offrant un peu plus de puissance et de périphériques embarqués, notamment l'EEPROM, totalement absente des circuits Z8F.

Et puisque j'évoque la 'puissance' de ce processeur, j'ai comparé le résultat de ce programme avec ceux obtenus lors d'un test précédent sur des machines fonctionnant sous interpréteur Basic. En 'force brute', l'ATmega168pb exécute un simple comptage à une vitesse supérieure à 350 fois le même type de test effectué sur un processeur PIC32 à 50MHz sous interpréteur Basic, le Micromite. Le Micromite étant lui-même 130 fois plus rapide que le bon vieux Tandy PC-2. L'ATmega168pb est donc près de 50 000 fois plus rapide que le PC-2. Évidement, cette comparaison est 'tendancieuse', les environnements de ces trois processeurs étant très différents les uns des autres.

Cependant, si l'on considère les outils disponibles aujourd'hui pour une personne désireuse de se lancer dans la réalisation de matériels embarqués, force est de constater qu'il y a vraiment de quoi faire petit, économe en énergie, tout en étant vraiment très performant. Le tout pour un budget minimal puisqu'à considérer que la phase la plus lente dans tout le processus d'élaboration est celle du chargement du logiciel Studio 6, il est tout à fait possible d'imaginer utiliser cette chaîne de développement sur un portable équipé d'un simple processeur Core 2 Duo. C'est mon cas, avec un Core 2 à 2.10 MHz. Ce type de Portable se trouve aujourd'hui en occasion à moins de 200€, à comparer aux 3500 Francs nécessaires pour acquérir un Sharp PC 1500 (TRS80-PC2) à l'époque de sa sortie. Les outils de développement sont fournis gracieusement par Atmel.

Le tout pour moins de 200€ ?....
Conclusion : je me suis laissé tenter par une publicité Atmel,vantant tous les avantages du circuit ATmega168pb, proposé sur une carte de développement minimale mais pratique au prix de de 8,88$ hors frais de port (24/12/2014). Je pensais être en présence d'un circuit minimaliste, il n'en est rien. Bien qu'en version 8 bits, et sous réserve que le besoin en calculs intensifs ne soit pas l'objectif, ce circuit est très flexible, puissant et pratique à programmer/debugger avec les outils Atmel. Au delà de la découverte, il serait dommage de ne pas l'utiliser dans une application concrète…


mardi 9 décembre 2014

ZigBee ou la chronique d'une mort annoncée?...

Ah, ZigBee !... Et la révolution révolutionnaire qui allait tout révolutionner dans la façon de contrôler l'habitat. Enfin, tout allait devenir simple et efficace, c'était le début de l'Internet Of Things, l'IoT d'aujourd'hui !

Un des premiers modèles de modules type ZigBee disponibles pour le grand public.

Puisque je m'intéresse entre autres sujets, à l’automatisation des bâtiments, je viens de découvrir un article sur le site de Batirama intitulé : "ZigBee 3.0 : fin de la cacophonie en 2015". Je serais tenté de traduire ce titre d'article en 'ZigBee : fin du sketch' !

Mais reprenons depuis le début... Je ne sais plus exactement en quelle année fût annoncée la 'révolution' ZigBee, mais il me semble que c'était vers 2007, Peu importe. Intéressé par les possibilités présentées, j'acquis un kit de démonstration chez Radiocrafts à un prix pas spécialement donné. Les deux cartes contenues dans la boîte semblaient tout droit sorties d'un atelier de bricolage, avec 'bouts de fils' soudés à même le circuit imprimé, destinés à configurer les quelques 'bornes' de configuration des modules ZigBee. Les deux cartes étaient équipées d'une antenne extérieur et non pas d'une antenne intégrée, soit par un composant, soit directement gravé sur le circuit imprimé.

Origine : Radiocrafts.
A noter que j'ai récupéré l'image ci-dessus le 09 décembre 2014 et que je ne sais pas si elle correspond toujours au kit que j'ai reçu à l'époque. Je ne possède plus ce kit, l'ayant fait passé depuis longtemps par la case déchèterie rubrique 'produits électroniques'!

Très rapidement, la déception : J'effectue les premiers tests de liaison, point à point. Inutile de préciser que la configuration des modules par commande de type 'AT' n'était pas spécialement des plus conviviale, le module renvoyant juste un 'OK' laconique en guide de confirmation. En configurant les deux modules en puissance maximale, j'obtins une distance de communication d' à peine 10 mètres en vis à vis, seulement 'obturé' par la fenêtre double vitrage de mon bureau.

Après d'énormes recherches sur Internet, je ne parvins jamais à être en mesure de me faire une idée précise sur les distances atteignables avec le protocol ZigBee. Je me souviens avoir vu quelques réalisations ou les exemples de distances de liaison obtenues étaient toujours réalisées en extérieur, par exemple une vidéo présenté par Texas Instruments montrant une 'certaine distance' obtenue avec ce type de circuit, dans un espace vert. Je ne sais plus si l'exemple Texas était présenté avec des modules ZigBee ou avec leur solution maison, mais peu importe, il s'agissait de la même bande de fréquence et de la même puissance de transmission. Quelle plaisanteries toutes ces démonstrations.

Parce qu'il faut être clair : ça ne fonctionne absolument pas en intérieur. Les raisons principales sont très simples et sont au nombre de trois : 

1- La puissance d'émission est RIDICULE. 
2- La bande de fréquence utilisée traverse très difficilement les obstacles. 
3- La bande de fréquence utilisée étant la même que celle du WiFi, le spectre radio est tellement bruité que même la haute sensibilité des récepteurs ZigBee ne parvient pas à palier le faible ratio S/B de la liaison.

Exemple de module ZigBee.

Vous pourriez me dire que c'est facile de critiquer, suite à un simple essai de modules peut-être pas optimaux et que etc etc etc...

Sauf que, suite à ces essais très peu convaincants, j'ai décidé d'attaquer le problème à la base et de créer des appareils de meilleur qualité. Je ne rentre pas dans les détails, mais un module ZigBee est constitué d'un frontal radio fréquence (RF) et d'un processeur faisant le lien avec l'extérieur et gérant la pile ZigBee. Inutile de préciser que chaque constructeur de module ZigBee incorpore le type de processeur qui l'intéresse dans sa solution. Se faisant, un programme développé pour un type de module d'un constructeur ne pourra certainement pas être implémenté dans un module d'un autre constructeur. Il convient donc de faire attention à la solution matérielle adoptée. Je passerai aussi sur la compatibilité des piles ZigBee implémentées ainsi que sur le choix de la chaîne de développement plus ou moins complète, plus ou moins finie, plus ou moins installable avec laquelle il m'a fallu me battre pour réussir à programmer les modules choisis : des modules Jennic, qui me semblaient à l'époque les moins pires ! 
 
Un module Jennic.
J'ai donc réalisé trois prototypes de capteurs de température et d'hygrométrie. Dans l'ordre de l'image ci-dessous, deux prototypes équipés de modules avec antenne extérieur, et un avec une antenne directement gravée sur le module.

Réalisation personnelle...

Après de longues heures de découverte, et de programmation, je réussis à configurer un prototype équipé d'une antenne extérieur en module maître, et les deux autres en modules esclaves. Ce qui m'a permis d'effectuer des tests de distances. Et je n'ai pas été déçus !!! Avec le prototype équipé d'une antenne gravée sur le module Zigbee, j'ai obtenu 1,5m et une paroi BA13 traversée. Sinon, c'était 2m. Oui, vous avez bien lu : 2m max en vis à vis. Les tests ont été effectués dans un appartement situé dans un immeuble, noyé dans les transmissions WiFi. Il y avait plus de 10 réseaux visibles à différentes puissances. Avec deux prototypes équipés d'antennes extérieur, la situation s'améliorait quelque peu puisque j'ai pu obtenir 12m (mesurés au mètre à ruban), toujours en traversant une paroi de BA13 plus un voile extérieur de 15cm, j'étais en fait sur le balcon. En un mot, dans un appartement de 75m² ayant une topologie carrée, et même en intérieur, le simple fait de devoir passer plus de deux cloisons BA13 ne me permettait pas de ponter la diagonale !!!

Je n'ai pas poussé plus avant les expérimentations sur le sujet. A titre d'exemple, des tests effectués avec de simples émetteurs récepteurs travaillant dans la bande des 433Mhz sous 10mW d'émission m'ont permis le transfert de fichiers à 2400 bauds jusque dans le sous-sol du bâtiment, l'appartement se situant au 2ième étage. J'ai même du arrêter rapidement les tests puisque je perturbais l'ouverture du portail d'entrée de la résidence.

Modules 433MHz APC220 utilisés pour les expérimentations.
Que dire de plus ?
Il est possible aujourd'hui que l’interopérabilité des modules ZigBee s'améliore. Je doute que la raison en soit uniquement la version 3.0 du protocole. Mais plutôt au fait que durant ces sept dernières années, le nombre de constructeurs ayant jeté l'éponge sur ce sujet fait que les derniers restant sur la place semblent arriver à proposer des solutions compatibles avec... eux-même !

A titre d'exemple : 
- Les modules MaxStream ont été repris par Digi.
- Les modules MeshMetics ne sont plus disponibles.
- Les modules Jennic ont été repris par NXP.
Et tant d'autres....

Mais les fondamentaux restent présents :

- Le partage du spectre de fréquence avec le WiFi ne permet pas de bonnes liaisons.
- Le spectre utilisé est très vite arrêté par les obstacles, même fins.
- Pour ponter des distances 'utilisables', il faut impérativement installer des 'répéteurs' de réseau, avec toute la complexité de configuration de ce type de réseau tant au niveau logiciel, que logistique.
- Que dire de l'autonomie électrique des appareils dans le cas d'un réseau de ce type puisqu'à minima ils doivent être constamment en réception : quelques mois ?
- Miser sur le bon fournisseur de modules parce qu'il n'y a aucune garantie sur la pérennité de l'approvisionnement. Mais heureusement, le marché semble s'être assaini, il reste de moins en moins de constructeurs de modules ZigBee, voire bientôt... plus du tout !!! 
- Considérer la difficulté de développement autour des modules choisis...

Quoi faire alors ?

Hum, je dirais que la vraie vie est ailleurs. Il existe aujourd'hui des constructeurs capables de proposer des solutions de type WiFi, très bon marché et compatibles avec le protocole de commande série de type 'AT'. 

Photo provenant du site HACKADAY, du module ESP8266 .
Je n'ai pas encore effectué de tests de distance avec ces modules Wifi mais au moins cela reste du réseau 'standard' accessible depuis n'importe quel portable équipé d'une carte de réception WiFi, c'est à dire tous maintenant, et cela ne coûte que deux à trois Euros sur eBay ! 
De plus, le processeur embarqué 'semble' programmable, bien qu'il 'semblerait' que la chaîne de compilation ne soit pas triviale à installer et que la documentation disponible soit plus que légère pour l'instant. Mais une importante communauté de développeurs se fédère autour de cette solution, permettant d'envisager une meilleur intégration de ce type de solutions dans les mois à venir. Un bon point de départ sur ce module pourrait être celui-ci : Limpkin's.

Alors plutôt que tenter une aventure professionnelle autour du ZigBee, mieux vaut passer quelques heures de loisir à expérimenter autour de ce type de solution WiFi !

Moi, ce que j'en dis....