Archives par mot-clé : ARM

[Projet] Module NFC

Le NFC, c’est une technique de communication sans contact, qui est utilisée pour les cartes de transport et autres cartes CB sans contact. Le signal est modulé à une fréquence de 13,56 MHz, ce qui est une bande “ISM” comme le 2.4 GHz ou le 433.92 MHz. En dehors du NFC, cette bande sert aux machines à plasma en physique, semiconducteurs, etc.

J’ai remarqué qu’il existait peu de lecteurs NFC hackables et abordables.

Le seul que je connaisse est le OpenPCD, basé sur un chip lecteur NFC de NXP. Ce projet implémente un lecteur de cartes sans contact dont le micrologiciel est fait pour expérimenter.

Je suis récemment tombé sur le circuit de Texas Instruments TRF7970A, qui, non seulement, est capable de fonctionner comme le circuit de NXP (lecteur de carte, ou “initiator” en langage NFC), mais également en mode “peer to peer” et “target” (émulation de carte). C’est un composant ridiculement petit (QFN) mais facilement disponible. Malgré sa petite taille pénible à souder, il mérite qu’on s’y intéresse. Un kit d’évaluation est disponible auprès de TI, mais 1) j’aime pas les kits d’évaluation et 2) c’est cher (49 ou 99 dollars). Donc je vais faire ma propre carte.

En suivant toutes les docs de référence fournies par TI, j’ai été capable de développer ma propre carte d’évaluation, au format 5×5 cm.

La première carte est une antenne adaptée munie de son circuit d’adaptation d’impédance: Les valeurs des composants seront à calculer selon des formules (magiques pour les débutants) après avoir caractérisé l’inductance de l’antenne. Je reviendrai sur ces calculs plus tard.

Schéma antenne
Schéma antenne

Le dessin de l’antenne est basé sur un design NXP à plusieurs tours qui permet d’avoir les deux fils de sortie de l’antenne du même côté.

Circuit de l'antenne
Circuit de l’antenne

La deuxième carte est le “lecteur” proprement dit, qui porte un autre circuit d’adaptation d’impédance, le circuit TRF, et une connexion SPI vers un microcontroleur Tiva C, le successeur du Stellaris qui se trouve sur la carte Stellaris Launchpad. Voici quelques caractéristiques techniques:

  • Front-end NFC Texas Instruments TRF7970A
  • Connecteur coaxial UFL pour l’antenne
  • Microcontroleur ARM Cortex M4 Tiva C Series TM4F123
  • 256k de flash
  • 32k de RAM
  • Port USB (OTG non câblé, donc seulement device)
  • Port I2C
  • UART
  • Port JTAG sur header 10 points (pinout ARM standard)
  • 20 GPIO disponibles sur header au pas de 2.54mm
  • Alimentation 5V, par USB ou externe
Schéma frontend NFC
Schéma frontend NFC

Et le circuit:

PCB Frontend NFC
PCB Frontend NFC

J’ai réussi à me débrouiller pour avoir très peu de pistes coté cuivre, du coup le plan recouvre tout le dessous du circuit. La majorité des pistes vertes que vous voyez relient tous les points de masse, pour m’assurer que je n’en oublie aucun. En réalité, toutes ces pistes seront noyées dans le plan de masse. J’utilise cette technique pour m’assurer que mon plan de masse est en un seul morceau.

Dans la semaine qui vient, je vais envoyer ces deux circuits chez SeeedStudio, je pense en faire au moins dix, peut être plus. Si avoir ces circuits vous intéresse, signalez vous, je n’utiliserai pas les 10 donc contre une petite obole, je pourrai vous envoyer un jeu de circuits. Mais je ne les donnerai pas, je connais trop de projets qui finissent par prendre la poussière sur l’étagère…

Niveau réalisation, il y a un TQFP (pas trop dur) et un QFN. Il vaut mieux souder ça à l’air chaud, mais ça doit aussi être possible au fer très fin.

Niveau logiciel, c’est complexe. Avant d’avoir un lecteur de cartes fonctionnel, il faudra du temps. Mais c’est possible, je n’ai aucun doute, surtout si je suis pas tout seul. On peut imaginer de la communication avec les téléphones NFC du moment. Les possibilités sont infinies, Internet est vaste, et plein de docs.

Pour les libs bas niveau, je pense partir de ce que j’ai déja développé pour la carte Stellaris Launchpad, ma librairie FreeStella, qui permet d’initialiser le CPU et de faire fonctionner l’uart. Cette lib n’a aucune dépendance, elle permet le développement “bare metal” à partir du vecteur de boot de l’ARM. Elle ne se base pas sur le TivaWare / StellarisWare, et elle est publiée avec une licence très permissive.

Je vous tiens au courant, et en attendant, parlez moi de vos idées. Qu’est ce qu’on va bien pouvoir faire de cool avec ce projet?

Les GPIO de la Stellaris Launchpad

J’ai enfin réussi à faire tourner et à débugger mon premier programme pour la Stellaris Launchpad. Oh, ce n’est pas grand chose, j’ai fait clignoter une LED. Mais qu’est ce que j’ai appris de choses!

En particulier, j’ai découvert pas mal de choses sur les fonctions GPIO (general purpose input/output) de ce microcontrôleur.

Accès GPIO par les bus APB et AHB

Le CPU ARM Cortex contient plusieurs bus de donnée à l’extérieur du coeur du processeur.

  • le bus APB, Advanced Peripheral Bus
  • le bus AHB, Advanced High-Performance Bus

Les périphériques internes du Stellaris sont connectés à l’un ou à l’autre de ces bus:

Archi interne Stellaris
Archi interne Stellaris

Pour les périphériques GPIO (= lignes de sorties qu’on peut piloter et lire), on a le choix du bus utilisé. Prenons l’exemple du port F, utilisé pour piloter les LEDs de la carte Stellaris Launchpad. Ce port est accessible depuis deux adresses:

  • Pour sa connexion à l’APB, les registres sont disponibles à partir de l’adresse 0x40025000
  • Pour sa connexion à l’AHB, les registres sont disponibles à partir de l’adresse 0x4005D000

Les registres accessibles sont les mêmes, mais le bus AHB possède une plus faible latence, et ses adresses sont plus pratiques à utiliser dans des calculs.

Mais attention : Au reset, seul l’accès par le bus APB est possible. Toute tentative d’accès aux ports AHB provoquera une exception de type “Bus Fault”, et comme dans un code basique, cette exception n’est pas activée, on obtiendra une “Hard Fault”.

Après quelques heures passées sur le sujet, j’ai bien relu la datasheet, et j’ai compris que les bons bits devaient être définis dans le registre GPIOHBCTL, documenté au paragraphe 5.5, page 247.

Recette 1: Accès GPIO qui produit une hardfault (ou une busfault) -> Vérifier GPIOHBCTL

 

Ecriture de données sur les ports GPIO

Après cette découverte, je n’ai plus eu de Hard Fault. En revanche, toute écriture dans le registre GPIODATA n’avait aucun effet.

De la même manière, seule une lecture attentive de la datasheet m’a donné l’explication. GPIODATA n’est pas un registre, mais une PLAGE de 256 registres.

En effet, tout accès à la zone [GPIODATA..GPIODATA+256*4] s’accompagne d’une écriture sur le port, mais les bits de poids faible de l’adresse sont utilisés comme un masque définissant quels bits seront écrits. Le but de cette fonctionnalité, documentée page 608, est de permettre les modifications de bits individuels du port sans utiliser la technique du read-modify-write:

WRITE(address, READ(address) OP mask)

En effet, les seuls bits modifiés du port sont ceux dont les bits d’adresse 9..2 sont à 1.

Supposons que j’écrive 0xEB à l’adresse GPIODATA+0x98, voici ce qui se passe:

gpiodata access

u signifie que le bit n’est pas modifié, 0 ou 1 montre la valeur réellement écrite.

Donc en général, pour la modification du bit N, vous devez écrire 1<<bit à l’adresse GPIODATA+(1<<bit)

Eh non! Vous avez encore mal lu! Les bits significatifs sont 9..2 et non 7..0 !

Pour la modification du bit N, vous devez écrire 1<<(bit+2) à l’adresse GPIODATA+(1<<(bit+2))

Recette 2: Si les GPIO ne changent pas, vérifiez votre adresse GPIODATA

 

Tout ceci m’inspire une 3e recette, car ce circuit est manifestement plus complexe et moins évident qu’un PIC:

Recette 3: Pour le Stellaris LM4F, le RTFM est vraiment important!

 

Quelle est la meilleure toolchain pour ARM embarqué?

Sur le web, on trouve plusieurs toolchains ARM, qui peuvent être toutes utilisées pour programmer des cartes embarquées. Voici les principales:

  • YAGARTO (yet another arm toolchain)
  • buildroot
  • CodeSourcery (Sourcery CodeBench)
  • linaro (toolchain “officielle”)
  • GNUARM
  • WinARM

Toutes ces toolchains sont subtilement différentes:

  • CodeSourcery ne supporte pas les FPU (floating point unit) des Cortex-M4, et n’offre aucun support pour les utilisateurs de la version gratuite depuis le rachat de cette société par Mentor Graphics
  • WinARM et GNUARM sont préhistoriques, peu maintenues, etc
  • buildroot est prévue pour être utilisée dans l’environnement du même nom, et n’est pas toujours facile à obtenir séparément
  • C’est très pénible de compiler soi même une toolchain GCC complète

linaro est produite principalement pour les plate formes Android et Linux, et elle supporte les Cortex M4 (STM32, Stellaris etc). Son grand avantage est d’être supportée directement par la société ARM elle même, mais elle met 3 ou 4 fois plus de temps que les autres à compiler un programme. Pour un petit programme, cela peut sembler peu important, mais dès qu’on touche un projet plus volumineux, cela peut devenir pénible. De plus, elle inclut par défaut le support des exceptions C++, ce qui est totalement inutile sur les plate formes embarquées à mémoire réduite.

Pour regrouper le meilleur de ces mondes, Freddie Chopin, un expert en logiciel embarqué ARM très actif dans le monde open source /logiciel libre , a décidé de compiler et de distribuer sa propre toolchain, basée sur les paquets de la toolchain “officielle” linaro, mais en utilisant les options de constructions de CodeSourcery. Le résultat est doté de ces caractéristiques:

  • Plus rapide que Linaro,
  • Elle est compilée avec le compilateur le plus récent pour windows, mingw-w64 (et avec gcc sous linux)
  • Les paquets de base (le compilateur, newlib, gdb et binutils) proviennent directement des projets officiels, et utilisent les révisions les plus récentes,
  • Les autres composants (librairies requises pour la compilation de la toolchain, comme gmp, mpfr, mpc) sont les plus récentes versions stables (sauf si la documentation recommandait une version spécifique),
  • Les exceptions C++ ne sont pas activées (bien qu’une version avec les exceptions soit en préparation),
  • Toutes les librairies cibles sont fournies non strippées, donc avec toutes leurs infos de débogage (ce qui est pratique pour approfondir le débogage de ses propres programmes),
  • la librairie newlib est compilée avec l’option reent-small pour économiser de l’espace de pile.

Ces options sont très intéressantes pour l’efficacité des programmes ARM embarqués.

Cette toolchain est appellée “bleeding edge toolchain”, et elle est téléchargeable pour windows 32 et 64 bits, et pour linux 64 bits, sur le site sourceforge.

Je recommande son utilisation pour tous les projets ARM embarqués.

Des parties de cet article sont basées sur la traduction de cet article original (en anglais).

Vite fait: Apprenons à développer sur ARM avec Texas Instruments

Texas instruments propose depuis quelques semaines une promotion très intéressante sur sa carte de développement Stellaris LM4F120. C’est une carte de développement avec un microcontroleur ARM et les composants indispensables, sur une carte électronique utilisable pour bricoler, le tout pour 5 dollars.

Cela me semble parfait pour aborder le développement embarqué sur une plate forme 32 bits moderne. La carte a les fonctionnalités suivantes (description complète, description du kit):

  • CPU ARM Cortex M4 à 80 MHz, avec 256Ko de flash et 32Ko de RAM
  • Interface USB 2 (micro-B, le cable est fourni) avec un PC
  • Interface de débogage intégrée sur un autre port USB
  • Interface “Booster pack” similaire à l’Arduino pour pouvoir connecter ses propres montages additionnels
  • Des LEDs et des boutons pour les tests
  • de l’I2C, UART, CAN, ADC,  interruptions…
Carte Stellaris Launchpad de Texas Instruments
Carte Stellaris Launchpad de Texas Instruments

Je m’en suis procuré une, nous verrons comment nous en servir quand je l’aurai reçue, courant novembre apparemment.

Un des défis sera de la programmer avec la chaine d’outils libres GCC, au lieu de compter sur les outils payants de Texas Instruments.

Il vous faudra comprendre l’anglais un minimum pour passer commande, le paiement se fait par carte ou paypal, et il n’y a pas de frais de port!

 

C’est ici que ça se passe pour commander votre launchpad stellaris LM4F120!