L’usine à gaz USB
L’Universal Serial Bus est une norme de transfert de données en série (c’est à dire que les données sont transmises les unes à la suite des autres ; à opposer au mode parallèle où les données sont transmises via plusieurs canaux). Créé en 1994 par un consortium de constructeurs, l’USB est maintenant incontournable depuis le début des années 2000. Tout fonctionne maintenant par USB : claviers, souris, stockages de données, caméras, imprimantes, protocoles sans fil,.. L’idée de pouvoir rejoindre cette communauté doit vous sembler excitante !
Il est important de saisir certains concepts avant de se jeter à l’eau. Par ailleurs, je ne traiterai ici que des périphériques de version USB 1.1. Cette limitation est due aux caractéristiques techniques des micro-contrôleurs.
Les caractéristiques du bus
L’USB 1 et 2, se déploit sur quatre fils :
- L’alimentation +5V VCC en rouge (parfois orange)
- Le câble « données » D- en blanc (parfois jaune)
- Le câble « données » D+ en vert
- et la masse GND en noir (parfois bleu)
Communément, un périphérique USB 1.x peut être alimenté par un courant de 150mA (500mA pour l’USB 2.0). Si vous avez besoin de plus de puissance, il sera nécessaire de prévoir votre propre source de courant (batteries, alimentation, …).
Les connecteurs à chaque bout peuvent avoir différentes formes, les plus courants étant les suivantes :
Broches | Type A | Type B | Mini-A | Mini-B | Micro-A | Micro-B |
---|---|---|---|---|---|---|
VCC | 1 | 1 | 1 | 1 | 1 | 1 |
D- | 2 | 2 | 2 | 2 | 2 | 2 |
D+ | 3 | 3 | 3 | 3 | 3 | 3 |
GND | 4 | 4 | 5 | 5 | 5 | 5 |
La topologie
Le bus se dessine suivant une topologie en arbre, l’hôte étant la racine. Il est possible de connecter jusqu’à 127 périphériques, sur 5 niveaux (derrière des hubs).
L’USB peut fonctionner jusqu’à 3 mètres et même au-delà en utilisant des répétiteurs alimentés (ceci est néanmoins déconseillé).
Les identifiants
Chaque périphérique s’identifie grâce à deux codes :
- le code fournisseur (vendor ID) sur 2 octets (soit 65536 possibilités). Ce code est distribué par l’USB Implementers Forum. Il est nécessaire de payer entre 2500 et 5000 US$ pour disposer du sien de façon officielle. Heureusement, il existe des codes pour les « bricoleurs » comme nous.
- le code produit (product ID) sur 2 octets (soit 65536 possibilités). Ce code est défini par le fournisseur à sa guise. Généralement, tous les produits d’une même génération partagent le même code produit.
On les représente communément sous forme hexadécimale, sur 4 chiffres, en les séparant par un deux-points. Voici quelques exemples :
- Appareil photo Sony NEX-5R : 054c:066e
- Téléphone Nexus 4 : 18d1:4ee1
Ce couple ne permettent pas d’identifier de manière unique un individu, seulement sa nature. Pour l’identifier précisément, il sera nécessaire de le prévoir de manière logicielle, ou en utilisant son chemin de connexion dans le réseau (par exemple, hub 2 > hub 2.1> hub 2.1.4 > port 2.1.4.5).
Par ailleurs, il existe une identification textuelle représentée par une chaîne de caractères.
Les classes USB
Vue la myriade de possibilités qu’offre la norme USB, il est nécessaire de regrouper les périphériques par classes, afin de factoriser l’effort à fournir pour le support de nouveaux matériels.
Ainsi, les souris, claviers, joysticks, etc. sont syndiqués sous la classe « Human interface device » (HID): 0x03. Les périphériques de stockage sont sous la classe « Mass storage » : 0x08. Cette page (en anglais) résume les classes officiellement déclarées.
Suivant la classe, les systèmes d’exploitation ont bâti des pilotes (drivers) afin de rendre plus ou moins transparente l’intégration des périphériques USB. Ainsi, la plupart des périphériques de classe HID sont supportés sans la nécessité de fournir des pilotes. C’est cette classe qui va nous intéresser, car il s’agit de la plus simple à mettre en œuvre.
Le « Report Descriptor »
Dans le cas de la classe HID, il est nécessaire de fournir un « report descriptor ». Il s’agit d’une chaîne d’entiers qui décrit le format de données que le périphérique va retourner à l’hôte.
Prenons l’exemple d’une souris ; celle-ci doit retourner les informations suivantes :
- l’état de ses boutons (gauche, droite, milieu, molette vers le haut et molette vers le bas)
- un mouvement sur l’axe X
- un mouvement sur l’axe Y
La classe HID « mouse »
Voici une façon de représenter ces données, sur 3 octets :
octet | bit 7 | bit 6 | bit 5 | bit 4 | bit 3 | bit 2 | bit 1 | bit 0 |
---|---|---|---|---|---|---|---|---|
Boutons | - | - | - | molette bas | molette haut | clic droit | clic milieu | clic gauche |
Axe X | entier relatif entre -128 et 127 | |||||||
Axe Y | entier relatif entre -128 et 127 |
Voici à quoi correspond le rapport :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
char ReportDescriptor[48] = { 0x05, 0x01, // USAGE_PAGE (Generic Desktop) 0x09, 0x02, // USAGE (Mouse) 0xa1, 0x01, // COLLECTION (Application) 0x09, 0x01, // USAGE (Pointer) 0xa1, 0x00, // COLLECTION (Physical) 0x05, 0x09, // USAGE_PAGE (Button) 0x19, 0x01, // USAGE_MINIMUM (Button 1) 0x29, 0x05, // USAGE_MAXIMUM (Button 5) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x25, 0x01, // LOGICAL_MAXIMUM (1) 0x95, 0x03, // REPORT_COUNT (3) 0x75, 0x01, // REPORT_SIZE (1) 0x81, 0x02, // INPUT (Data,Var,Abs) 0x95, 0x01, // REPORT_COUNT (1) 0x75, 0x03, // REPORT_SIZE (3) 0x81, 0x03, // INPUT (Cnst,Var,Abs) 0x05, 0x01, // USAGE_PAGE (Generic Desktop) 0x09, 0x30, // USAGE (X) 0x09, 0x31, // USAGE (Y) 0x15, 0x80, // LOGICAL_MINIMUM (-128) 0x25, 0x7f, // LOGICAL_MAXIMUM (127) 0x75, 0x08, // REPORT_SIZE (8) 0x95, 0x02, // REPORT_COUNT (2) 0xc0, // END_COLLECTION 0xc0 // END_COLLECTION }; |
Pour aider à la rédaction de ce rapport, il est possible d’utiliser HID Descriptor Tool disponible ici. Voici à quoi cela ressemble :
Je ne vais pas vous faire un cours sur le contenu détaillé de ces rapports. Il suffit simplement de savoir qu’ils existent et à quoi ils servent. Pour plus de détails, voici une bonne introduction (en anglais).
La classe HID « Custom »
Dans mon tutoriel, je vais utiliser une version allégée qui n’utilise pas de donnée formatée :
1 2 3 4 5 6 7 8 9 10 11 12 |
char ReportDescriptor[22] = { 0x06, 0x00, 0xff, // USAGE_PAGE (Generic Desktop) 0x09, 0x01, // USAGE (Vendor Usage 1) 0xa1, 0x01, // COLLECTION (Application) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255) 0x75, 0x08, // REPORT_SIZE (8) 0x95, 0x01, // REPORT_COUNT (1) 0x09, 0x00, // USAGE (Undefined) 0xb2, 0x02, 0x01, // FEATURE (Data,Var,Abs,Buf) 0xc0 // END_COLLECTION }; |
L’utilisation d’un tel rapport permet de s’affranchir des limitations du format HID, tout en étant facile à « installer » sur l’hôte. Cependant, il devient nécessaire d’utiliser un logiciel sur l’hôte pour se servir du périphérique.
La bibliothèque V-USB
AVR-GCC ne fournit pas de méthode pour utiliser l’USB, et ce n’est pas son but.
Il est donc nécessaire de charger une bibliothèque (library) tierce. V-USB est une bibliothèque qui propose une implémentation logicielle de la norme USB 1.1 pour les micro-contrôleurs AVR.
Celle-ci est proposée sous double licence : GPL version 2 ou commerciale. Cela implique que vos projets qui incluent cette bibliothèque doivent être publiés en accord avec la GPL (et donc avec distribution des sources), ou nécessite l’achat d’une licence commerciale (9.90€ pour une licence « Hobbyiste », 500€ pour une licence professionnelle).
Il existe des alternatives, mais la plupart nécessitent des micro-contrôleurs « puissants » ou des contrôleurs USB matériel. V-USB est utilisable sur des micro-contrôleurs modestes, dont l’ATTiny85.
Que contient-elle ?
La version actuelle (20121206) contient le répertoire usbdrv, dans lequel vous trouverez (entre autres) :
usbdrv.h | les définitions nécessaires |
usbdrv.c | le cœur du pilote |
usbdrvasm.S | code assembleur utilisé par le pilote |
usbdrvasm*.inc | fichier appelé depuis usbdrvasm.S |
asmcommon.inc | fichier appelé depuis usbdrvasm.S |
oddebug.c | fournit plusieurs fonction de débogage |
oddebug.h | Les définitions requises par oddebug.c |
usbportability.h | Des définitions utilisés par le compilateur |
usbconfig-prototype.h | un exemple de fichier de configuration |
Pour le bon fonctionnement du projet, il est important de copier l’intégralité du répertoire dans vos sources.
Comment fonctionne la bibliothèque ?
La configuration
Toute la configuration se trouve dans le fichier usbconfig.h, que vous devez ajouter à vos sources. Pour cela, vous pouvez copier le fichier usbconfig-prototype.h. Voici les points importants à adapter à votre projet :
Macro | Description | Exemple |
---|---|---|
USB_CFG_IOPORTNAME | Port du microcontrôleur utilisé pour la communication en USB | B |
USB_CFG_DMINUS_BIT | Numéro de broche utilisé par D- | 0 |
USB_CFG_DPLUS_BIT | Numéro de broche utilisé par D+ | 2 |
USB_CFG_IS_SELF_POWERED | Indique si votre périphérique dispose de sa propre source (0 : Non/ 1 : Oui) | 0 |
USB_CFG_MAX_BUS_POWER | Courant maximum que consomme votre périphérique (en mA) | 50 |
USB_CFG_IMPLEMENT_FN_WRITE | Indique si vous souhaitez utiliser la fonction usbFunctionWrite() ou non | 0 |
USB_CFG_IMPLEMENT_FN_READ | Indique si vous souhaitez utiliser la fonction usbFunctionRead() ou non | 0 |
USB_CFG_LONG_TRANSFERS | Indique si vous souhaitez faire des transferts de plus de 254 octets | 0 |
USB_CFG_VENDOR_ID | Octet faible et octet fort qui définissent l’identifiant fournisseur | 0xc0, 0x16 |
USB_CFG_PRODUCT_ID | Octet faible et octet fort qui définissent l’identifiant produit | 0xdc, 0x05 |
USB_CFG_VENDOR_NAME | Nom du fournisseur (il est demandé d’y mettre un nom de domaine) | ‘c’,’i’,’c’,’a’,’t’,’r’,’i’,’c’,’e’,’.’,’e’,’u’ |
USB_CFG_VENDOR_NAME_LEN | Taille de la macro fournisseur | 12 |
USB_CFG_DEVICE_NAME | Nom du produit | ’I’,’R’,’-‘,’L’,’e’,’d’ |
USB_CFG_DEVICE_NAME_LEN | Taille de la macro produit | 6 |
Bien entendu, il reste beaucoup de macros, je vous laisse découvrir leur utilité dans les commentaires du code.
Les callbacks
V-USB implémente plusieurs « callbacks » (fonctions de retour), qui sont appelées à la suite d’événements précis. Cela ressemble à des interruptions, sauf que celles-ci sont purement logicielles :
- usbFunctionSetup : appelée à l’arrivée d’une requête ; c’est ici que vous définirez ce qu’il doit se passer au niveau du micro-contrôleur.
- usbFunctionWrite (nécessite USB_CFG_IMPLEMENT_FN_WRITE à 1) Cette fonction est appelée quand la fonction usbFunctionSetup retourne USB_NO_MSG et si la requête est de type USBRQ_HID_SET_REPORT (0x09).
- usbFunctionRead (nécessite USB_CFG_IMPLEMENT_FN_READ à 1) Cette fonction est appelée quand la fonction usbFunctionSetup retourne USB_NO_MSG et si la requête est de type USBRQ_HID_GET_REPORT (0x01).
Il y en a d’autres mais ce sont les principales. Ce diagramme résume l’utilisation que vous pouvez faire de ces méthodes.
La bibliothèque LibUSB
Comme je l’ai indiqué lors du chapitre sur les « report descriptors », nous allons avoir besoin d’un programme sur la machine hôte qui se chargera de dialoguer avec le micro-contrôleur branché en USB. Je vais utiliser ici libusb.
Ne voulant pas m’embêter avec la signature des pilotes sous Windows (obligatoire depuis la version 8) j’ai décidé de tout faire sous Linux (j’utilise une Fedora 20).
LibUSB est une bibliothèque dont le but est de fournir des méthodes de gestion et d’accès aux périphériques branchés en USB.
Le programme se découpe en deux parties :
- une partie d’initialisation, où l’on cherche le périphérique USB qui nous intéresse
- une partie d’exécution, où l’on effectue les actions nécessaires, notamment grâce à la méthode libusb_control_transfer() que vous avez pu apercevoir dans mon diagramme plus haut.
La structure du projet
Pour mon exemple, je vais utiliser un petit projet qui permet à mon PC de servir de télécommande pour une bande de LED RGB.
Aperçu
Voici comment doit se présenter votre projet :
Vous verrez dans beaucoup d’exemples que les fichiers remote.c , requests.h , usbconfig.h et Makefile (celui du micro-contrôleur) se trouvent dans un répertoire firmware. Vous pouvez ranger ces fichiers comme bon vous semble, l’important est que cette structure soit claire pour vous.
Le schéma
Avant de parler du code, voici un exemple de branchements :Il n’y a pas grand chose à dire sur ce schéma. Les deux diodes Zener doivent limiter la tension à 3.3V.
Les définitions
usbconfig.h
Comme décrit plus tôt, il s’agit de la configuration pilote V-USB. Celui est chargé automatiquement, à partir du moment où votre projet inclus le fichier usbdrv.h . Il sera également inclus lors de la compilation du programme hôte.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 |
/* Name: usbconfig.h * Project: V-USB, virtual USB port for Atmel's(r) AVR(r) microcontrollers * Author: Christian Starkjohann * Creation Date: 2005-04-01 * Tabsize: 4 * Copyright: (c) 2005 by OBJECTIVE DEVELOPMENT Software GmbH * License: GNU GPL v2 (see License.txt), GNU GPL v3 or proprietary (CommercialLicense.txt) */ #ifndef __usbconfig_h_included__ #define __usbconfig_h_included__ /* General Description: This file is an example configuration (with inline documentation) for the USB driver. It configures V-USB for USB D+ connected to Port D bit 2 (which is also hardware interrupt 0 on many devices) and USB D- to Port D bit 4. You may wire the lines to any other port, as long as D+ is also wired to INT0 (or any other hardware interrupt, as long as it is the highest level interrupt, see section at the end of this file). */ /* ---------------------------- Hardware Config ---------------------------- */ #define USB_CFG_IOPORTNAME B /* This is the port where the USB bus is connected. When you configure it to * "B", the registers PORTB, PINB and DDRB will be used. */ #define USB_CFG_DMINUS_BIT 0 /* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected. * This may be any bit in the port. */ #define USB_CFG_DPLUS_BIT 2 /* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected. * This may be any bit in the port. Please note that D+ must also be connected * to interrupt pin INT0! [You can also use other interrupts, see section * "Optional MCU Description" below, or you can connect D- to the interrupt, as * it is required if you use the USB_COUNT_SOF feature. If you use D- for the * interrupt, the USB interrupt will also be triggered at Start-Of-Frame * markers every millisecond.] */ #define USB_CFG_CLOCK_KHZ (F_CPU/1000) /* Clock rate of the AVR in kHz. Legal values are 12000, 12800, 15000, 16000, * 16500, 18000 and 20000. The 12.8 MHz and 16.5 MHz versions of the code * require no crystal, they tolerate +/- 1% deviation from the nominal * frequency. All other rates require a precision of 2000 ppm and thus a * crystal! * Since F_CPU should be defined to your actual clock rate anyway, you should * not need to modify this setting. */ #define USB_CFG_CHECK_CRC 0 /* Define this to 1 if you want that the driver checks integrity of incoming * data packets (CRC checks). CRC checks cost quite a bit of code size and are * currently only available for 18 MHz crystal clock. You must choose * USB_CFG_CLOCK_KHZ = 18000 if you enable this option. */ /* ----------------------- Optional Hardware Config ------------------------ */ /* #define USB_CFG_PULLUP_IOPORTNAME D */ /* If you connect the 1.5k pullup resistor from D- to a port pin instead of * V+, you can connect and disconnect the device from firmware by calling * the macros usbDeviceConnect() and usbDeviceDisconnect() (see usbdrv.h). * This constant defines the port on which the pullup resistor is connected. */ /* #define USB_CFG_PULLUP_BIT 4 */ /* This constant defines the bit number in USB_CFG_PULLUP_IOPORT (defined * above) where the 1.5k pullup resistor is connected. See description * above for details. */ /* --------------------------- Functional Range ---------------------------- */ #define USB_CFG_HAVE_INTRIN_ENDPOINT 1 /* Define this to 1 if you want to compile a version with two endpoints: The * default control endpoint 0 and an interrupt-in endpoint (any other endpoint * number). */ #define USB_CFG_HAVE_INTRIN_ENDPOINT3 0 /* Define this to 1 if you want to compile a version with three endpoints: The * default control endpoint 0, an interrupt-in endpoint 3 (or the number * configured below) and a catch-all default interrupt-in endpoint as above. * You must also define USB_CFG_HAVE_INTRIN_ENDPOINT to 1 for this feature. */ #define USB_CFG_EP3_NUMBER 3 /* If the so-called endpoint 3 is used, it can now be configured to any other * endpoint number (except 0) with this macro. Default if undefined is 3. */ /* #define USB_INITIAL_DATATOKEN USBPID_DATA1 */ /* The above macro defines the startup condition for data toggling on the * interrupt/bulk endpoints 1 and 3. Defaults to USBPID_DATA1. * Since the token is toggled BEFORE sending any data, the first packet is * sent with the oposite value of this configuration! */ #define USB_CFG_IMPLEMENT_HALT 0 /* Define this to 1 if you also want to implement the ENDPOINT_HALT feature * for endpoint 1 (interrupt endpoint). Although you may not need this feature, * it is required by the standard. We have made it a config option because it * bloats the code considerably. */ #define USB_CFG_SUPPRESS_INTR_CODE 0 /* Define this to 1 if you want to declare interrupt-in endpoints, but don't * want to send any data over them. If this macro is defined to 1, functions * usbSetInterrupt() and usbSetInterrupt3() are omitted. This is useful if * you need the interrupt-in endpoints in order to comply to an interface * (e.g. HID), but never want to send any data. This option saves a couple * of bytes in flash memory and the transmit buffers in RAM. */ #define USB_CFG_INTR_POLL_INTERVAL 10 /* If you compile a version with endpoint 1 (interrupt-in), this is the poll * interval. The value is in milliseconds and must not be less than 10 ms for * low speed devices. */ #define USB_CFG_IS_SELF_POWERED 0 /* Define this to 1 if the device has its own power supply. Set it to 0 if the * device is powered from the USB bus. */ #define USB_CFG_MAX_BUS_POWER 50 /* Set this variable to the maximum USB bus power consumption of your device. * The value is in milliamperes. [It will be divided by two since USB * communicates power requirements in units of 2 mA.] */ #define USB_CFG_IMPLEMENT_FN_WRITE 0 /* Set this to 1 if you want usbFunctionWrite() to be called for control-out * transfers. Set it to 0 if you don't need it and want to save a couple of * bytes. */ #define USB_CFG_IMPLEMENT_FN_READ 0 /* Set this to 1 if you need to send control replies which are generated * "on the fly" when usbFunctionRead() is called. If you only want to send * data from a static buffer, set it to 0 and return the data from * usbFunctionSetup(). This saves a couple of bytes. */ #define USB_CFG_IMPLEMENT_FN_WRITEOUT 0 /* Define this to 1 if you want to use interrupt-out (or bulk out) endpoints. * You must implement the function usbFunctionWriteOut() which receives all * interrupt/bulk data sent to any endpoint other than 0. The endpoint number * can be found in 'usbRxToken'. */ #define USB_CFG_HAVE_FLOWCONTROL 0 /* Define this to 1 if you want flowcontrol over USB data. See the definition * of the macros usbDisableAllRequests() and usbEnableAllRequests() in * usbdrv.h. */ #define USB_CFG_DRIVER_FLASH_PAGE 0 /* If the device has more than 64 kBytes of flash, define this to the 64 k page * where the driver's constants (descriptors) are located. Or in other words: * Define this to 1 for boot loaders on the ATMega128. */ #define USB_CFG_LONG_TRANSFERS 0 /* Define this to 1 if you want to send/receive blocks of more than 254 bytes * in a single control-in or control-out transfer. Note that the capability * for long transfers increases the driver size. */ /* #define USB_RX_USER_HOOK(data, len) if(usbRxToken == (uchar)USBPID_SETUP) blinkLED(); */ /* This macro is a hook if you want to do unconventional things. If it is * defined, it's inserted at the beginning of received message processing. * If you eat the received message and don't want default processing to * proceed, do a return after doing your things. One possible application * (besides debugging) is to flash a status LED on each packet. */ #define USB_RESET_HOOK(resetStarts) if(!resetStarts){hadUsbReset();} #ifndef __ASSEMBLER__ extern void hadUsbReset(void); // define the function for usbdrv.c #endif /* This macro is a hook if you need to know when an USB RESET occurs. It has * one parameter which distinguishes between the start of RESET state and its * end. */ /* #define USB_SET_ADDRESS_HOOK() hadAddressAssigned(); */ /* This macro (if defined) is executed when a USB SET_ADDRESS request was * received. */ #define USB_COUNT_SOF 0 /* define this macro to 1 if you need the global variable "usbSofCount" which * counts SOF packets. This feature requires that the hardware interrupt is * connected to D- instead of D+. */ /* #ifdef __ASSEMBLER__ * macro myAssemblerMacro * in YL, TCNT0 * sts timer0Snapshot, YL * endm * #endif * #define USB_SOF_HOOK myAssemblerMacro * This macro (if defined) is executed in the assembler module when a * Start Of Frame condition is detected. It is recommended to define it to * the name of an assembler macro which is defined here as well so that more * than one assembler instruction can be used. The macro may use the register * YL and modify SREG. If it lasts longer than a couple of cycles, USB messages * immediately after an SOF pulse may be lost and must be retried by the host. * What can you do with this hook? Since the SOF signal occurs exactly every * 1 ms (unless the host is in sleep mode), you can use it to tune OSCCAL in * designs running on the internal RC oscillator. * Please note that Start Of Frame detection works only if D- is wired to the * interrupt, not D+. THIS IS DIFFERENT THAN MOST EXAMPLES! */ #define USB_CFG_CHECK_DATA_TOGGLING 0 /* define this macro to 1 if you want to filter out duplicate data packets * sent by the host. Duplicates occur only as a consequence of communication * errors, when the host does not receive an ACK. Please note that you need to * implement the filtering yourself in usbFunctionWriteOut() and * usbFunctionWrite(). Use the global usbCurrentDataToken and a static variable * for each control- and out-endpoint to check for duplicate packets. */ #define USB_CFG_HAVE_MEASURE_FRAME_LENGTH 1 /* define this macro to 1 if you want the function usbMeasureFrameLength() * compiled in. This function can be used to calibrate the AVR's RC oscillator. */ #define USB_USE_FAST_CRC 0 /* The assembler module has two implementations for the CRC algorithm. One is * faster, the other is smaller. This CRC routine is only used for transmitted * messages where timing is not critical. The faster routine needs 31 cycles * per byte while the smaller one needs 61 to 69 cycles. The faster routine * may be worth the 32 bytes bigger code size if you transmit lots of data and * run the AVR close to its limit. */ /* -------------------------- Device Description --------------------------- */ #define USB_CFG_VENDOR_ID 0xc0, 0x16 /* = 0x16c0 = 5824 = voti.nl */ /* USB vendor ID for the device, low byte first. If you have registered your * own Vendor ID, define it here. Otherwise you may use one of obdev's free * shared VID/PID pairs. Be sure to read USB-IDs-for-free.txt for rules! * *** IMPORTANT NOTE *** * This template uses obdev's shared VID/PID pair for Vendor Class devices * with libusb: 0x16c0/0x5dc. Use this VID/PID pair ONLY if you understand * the implications! */ #define USB_CFG_DEVICE_ID 0xdc, 0x05 /* VOTI's lab use PID */ /* This is the ID of the product, low byte first. It is interpreted in the * scope of the vendor ID. If you have registered your own VID with usb.org * or if you have licensed a PID from somebody else, define it here. Otherwise * you may use one of obdev's free shared VID/PID pairs. See the file * USB-IDs-for-free.txt for details! * *** IMPORTANT NOTE *** * This template uses obdev's shared VID/PID pair for Vendor Class devices * with libusb: 0x16c0/0x5dc. Use this VID/PID pair ONLY if you understand * the implications! */ #define USB_CFG_DEVICE_VERSION 0x00, 0x01 /* Version number of the device: Minor number first, then major number. */ #define USB_CFG_VENDOR_NAME 'c','i','c','a','t','r','i','c','e','.','e','u' #define USB_CFG_VENDOR_NAME_LEN 12 /* These two values define the vendor name returned by the USB device. The name * must be given as a list of characters under single quotes. The characters * are interpreted as Unicode (UTF-16) entities. * If you don't want a vendor name string, undefine these macros. * ALWAYS define a vendor name containing your Internet domain name if you use * obdev's free shared VID/PID pair. See the file USB-IDs-for-free.txt for * details. */ #define USB_CFG_DEVICE_NAME 'I','R','-','L','e','d' #define USB_CFG_DEVICE_NAME_LEN 6 /* Same as above for the device name. If you don't want a device name, undefine * the macros. See the file USB-IDs-for-free.txt before you assign a name if * you use a shared VID/PID. */ /*#define USB_CFG_SERIAL_NUMBER 'N', 'o', 'n', 'e' */ /*#define USB_CFG_SERIAL_NUMBER_LEN 0 */ /* Same as above for the serial number. If you don't want a serial number, * undefine the macros. * It may be useful to provide the serial number through other means than at * compile time. See the section about descriptor properties below for how * to fine tune control over USB descriptors such as the string descriptor * for the serial number. */ #define USB_CFG_DEVICE_CLASS 0 #define USB_CFG_DEVICE_SUBCLASS 0 /* See USB specification if you want to conform to an existing device class. * Class 0xff is "vendor specific". */ #define USB_CFG_INTERFACE_CLASS 3 #define USB_CFG_INTERFACE_SUBCLASS 0 #define USB_CFG_INTERFACE_PROTOCOL 0 /* See USB specification if you want to conform to an existing device class or * protocol. The following classes must be set at interface level: * HID class is 3, no subclass and protocol required (but may be useful!) * CDC class is 2, use subclass 2 and protocol 1 for ACM */ #define USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH 52 /* Define this to the length of the HID report descriptor, if you implement * an HID device. Otherwise don't define it or define it to 0. * If you use this define, you must add a PROGMEM character array named * "usbHidReportDescriptor" to your code which contains the report descriptor. * Don't forget to keep the array and this define in sync! */ /* #define USB_PUBLIC static */ /* Use the define above if you #include usbdrv.c instead of linking against it. * This technique saves a couple of bytes in flash memory. */ /* ------------------- Fine Control over USB Descriptors ------------------- */ /* If you don't want to use the driver's default USB descriptors, you can * provide our own. These can be provided as (1) fixed length static data in * flash memory, (2) fixed length static data in RAM or (3) dynamically at * runtime in the function usbFunctionDescriptor(). See usbdrv.h for more * information about this function. * Descriptor handling is configured through the descriptor's properties. If * no properties are defined or if they are 0, the default descriptor is used. * Possible properties are: * + USB_PROP_IS_DYNAMIC: The data for the descriptor should be fetched * at runtime via usbFunctionDescriptor(). If the usbMsgPtr mechanism is * used, the data is in FLASH by default. Add property USB_PROP_IS_RAM if * you want RAM pointers. * + USB_PROP_IS_RAM: The data returned by usbFunctionDescriptor() or found * in static memory is in RAM, not in flash memory. * + USB_PROP_LENGTH(len): If the data is in static memory (RAM or flash), * the driver must know the descriptor's length. The descriptor itself is * found at the address of a well known identifier (see below). * List of static descriptor names (must be declared PROGMEM if in flash): * char usbDescriptorDevice[]; * char usbDescriptorConfiguration[]; * char usbDescriptorHidReport[]; * char usbDescriptorString0[]; * int usbDescriptorStringVendor[]; * int usbDescriptorStringDevice[]; * int usbDescriptorStringSerialNumber[]; * Other descriptors can't be provided statically, they must be provided * dynamically at runtime. * * Descriptor properties are or-ed or added together, e.g.: * #define USB_CFG_DESCR_PROPS_DEVICE (USB_PROP_IS_RAM | USB_PROP_LENGTH(18)) * * The following descriptors are defined: * USB_CFG_DESCR_PROPS_DEVICE * USB_CFG_DESCR_PROPS_CONFIGURATION * USB_CFG_DESCR_PROPS_STRINGS * USB_CFG_DESCR_PROPS_STRING_0 * USB_CFG_DESCR_PROPS_STRING_VENDOR * USB_CFG_DESCR_PROPS_STRING_PRODUCT * USB_CFG_DESCR_PROPS_STRING_SERIAL_NUMBER * USB_CFG_DESCR_PROPS_HID * USB_CFG_DESCR_PROPS_HID_REPORT * USB_CFG_DESCR_PROPS_UNKNOWN (for all descriptors not handled by the driver) * * Note about string descriptors: String descriptors are not just strings, they * are Unicode strings prefixed with a 2 byte header. Example: * int serialNumberDescriptor[] = { * USB_STRING_DESCRIPTOR_HEADER(6), * 'S', 'e', 'r', 'i', 'a', 'l' * }; */ #define USB_CFG_DESCR_PROPS_DEVICE 0 #define USB_CFG_DESCR_PROPS_CONFIGURATION 0 #define USB_CFG_DESCR_PROPS_STRINGS 0 #define USB_CFG_DESCR_PROPS_STRING_0 0 #define USB_CFG_DESCR_PROPS_STRING_VENDOR 0 #define USB_CFG_DESCR_PROPS_STRING_PRODUCT 0 #define USB_CFG_DESCR_PROPS_STRING_SERIAL_NUMBER 0 #define USB_CFG_DESCR_PROPS_HID 0 #define USB_CFG_DESCR_PROPS_HID_REPORT 0 #define USB_CFG_DESCR_PROPS_UNKNOWN 0 #define usbMsgPtr_t unsigned short /* If usbMsgPtr_t is not defined, it defaults to 'uchar *'. We define it to * a scalar type here because gcc generates slightly shorter code for scalar * arithmetics than for pointer arithmetics. Remove this define for backward * type compatibility or define it to an 8 bit type if you use data in RAM only * and all RAM is below 256 bytes (tiny memory model in IAR CC). */ /* ----------------------- Optional MCU Description ------------------------ */ /* The following configurations have working defaults in usbdrv.h. You * usually don't need to set them explicitly. Only if you want to run * the driver on a device which is not yet supported or with a compiler * which is not fully supported (such as IAR C) or if you use a differnt * interrupt than INT0, you may have to define some of these. */ /* #define USB_INTR_CFG MCUCR */ /* #define USB_INTR_CFG_SET ((1 << ISC00) | (1 << ISC01)) */ /* #define USB_INTR_CFG_CLR 0 */ /* #define USB_INTR_ENABLE GIMSK */ /* #define USB_INTR_ENABLE_BIT INT0 */ /* #define USB_INTR_PENDING GIFR */ /* #define USB_INTR_PENDING_BIT INTF0 */ /* #define USB_INTR_VECTOR INT0_vect */ #endif /* __usbconfig_h_included__ */ |
requests.h
Ce fichier contient les requêtes USB personnalisées. Comme pour le fichier précédent, il sera inclus lors de la compilation.
1 2 |
#define CUSTOM_RQ_SEND_COMMAND 0x10 #define CUSTOM_RQ_REPEAT_COMMAND 0x11 |
Le programme du micro-contrôleur
remote.c
Il s’agit du code principal, qui sera envoyé sur le micro-contrôleur.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 |
#include <avr/io.h> #include <util/delay.h> #include <avr/sleep.h> #include <avr/wdt.h> #include <avr/interrupt.h> /* for sei() */ #include <avr/pgmspace.h> /* required by usbdrv.h */ #include "usbdrv.h" #include "requests.h" #define IR_PORT PORTB #define IR_DDR DDRB #define IR_PIN PB4 #define SIGNAL_BOTTOM() IR_PORT |= (1<<IR_PIN) #define SIGNAL_TOP() IR_PORT &= ~(1<<IR_PIN) // Delay in us #define IR_PULSE_MOD 13.2 #define IR_INIT_DELAY 4500 #define IR_1_DELAY 1690 #define IR_0_DELAY 560 // Delay in ms #define IR_REPEAT_DELAY 99 //38kHz pulse #define PULSE() {SIGNAL_TOP();_delay_us(IR_PULSE_MOD);SIGNAL_BOTTOM();_delay_us(IR_PULSE_MOD);} /* Le Report Descriptor, celui-ci est "vide" */ PROGMEM const char usbHidReportDescriptor[22] = { /* USB report descriptor */ 0x06, 0x00, 0xff, // USAGE_PAGE (Generic Desktop) 0x09, 0x01, // USAGE (Vendor Usage 1) 0xa1, 0x01, // COLLECTION (Application) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255) 0x75, 0x08, // REPORT_SIZE (8) 0x95, 0x01, // REPORT_COUNT (1) 0x09, 0x00, // USAGE (Undefined) 0xb2, 0x02, 0x01, // FEATURE (Data,Var,Abs,Buf) 0xc0 // END_COLLECTION }; uint8_t current_command; uint8_t command_count; /* Cette fonction est livrée telle quelle (je ne l'ai pas rédigée). Il s'agit d'une fonction permettant de calibrer le micro-controleur afin qu'il fonctionne à 16Mhz. Je ne me suis pas attardé à la comprendre. */ static void calibrateOscillator(void) { uchar step = 128; uchar trialValue = 0, optimumValue; int x, optimumDev, targetValue = (unsigned)(1499 * (double)F_CPU / 10.5e6 + 0.5); do{ OSCCAL = trialValue + step; x = usbMeasureFrameLength(); if(x < targetValue) trialValue += step; step >>= 1; }while(step > 0); optimumValue = trialValue; optimumDev = x; for(OSCCAL = trialValue - 1; OSCCAL <= trialValue + 1; OSCCAL++){ x = usbMeasureFrameLength() - targetValue; if(x < 0) x = -x; if(x < optimumDev){ optimumDev = x; optimumValue = OSCCAL; } } OSCCAL = optimumValue; } void ir_init_sequence(){ uint8_t i; for(i = 0; i<255; i++) PULSE(); for(i = 0; i<88; i++) PULSE(); //too lazy too swap to uint_16t (love your memory) _delay_us(IR_INIT_DELAY); } void ir_send_bit(uint8_t bit){ int8_t i; for(i = 0; i<21; i++) PULSE(); if (bit & 0x01) _delay_us(IR_1_DELAY); else _delay_us(IR_0_DELAY); } void ir_send_command(uint8_t address, uint8_t command){ ir_init_sequence(); int8_t i; for(i=7;i>=0;i--) ir_send_bit(address >> i); for(i=7;i>=0;i--) ir_send_bit(~address >> i); for(i=7;i>=0;i--) ir_send_bit(command >> i); for(i=7;i>=0;i--) ir_send_bit(~command >> i); wdt_reset(); } /* * Il s'agit d'une fonction de rappel (callback) executée lorsque le protocole USB reçoit une commande RESET Elle permet de calibrer l'horloge sur 16.5MHz sur un ATTiny85*/ void hadUsbReset(){ cli(); calibrateOscillator(); sei(); } /* * Il s'agit d'une fonction de rappel (callback) executée lorsque le protocole USB reçoit une requête */ usbMsgLen_t usbFunctionSetup(uchar data[8]){ cli(); usbRequest_t *rq = (void *)data; switch(rq->bRequest) { case CUSTOM_RQ_SEND_COMMAND: current_command = rq->wValue.bytes[0]; ir_send_command(0x00,current_command); break; case CUSTOM_RQ_REPEAT_COMMAND: current_command = rq->wValue.bytes[0]; command_count = rq->wValue.bytes[1]; while(command_count--){ ir_send_command(0x00,current_command); _delay_ms(IR_REPEAT_DELAY); } break; } sei(); return 0; } int main(){ wdt_enable(WDTO_1S); // On active le chien de garde (watchdog), pour qu'il redémarre le micro-contrôleur dans le cas d'une inactivité de plus d'une seconde IR_DDR |= (1<<IR_PIN); // On active la broche de l'infra-rouge en sortie usbInit(); // On charge tout ce qu'il faut pour que ça marche usbDeviceDisconnect(); // On force une déconnexion de l'USB uint8_t i = 0; while(--i){ // On attend environ 250ms avant de reconnecter l'USB wdt_reset(); // On tient au courant le chien de garde que tout va bien _delay_ms(1); } usbDeviceConnect(); // On reconnecte l'USB sei(); // On active les interruptions for(;;){ wdt_reset(); // On tient au courant le chien de garde que tout va bien usbPoll(); // C'est ainsi que les "interruptions" USB fonctionnent } } |
Makefile
Ici il faut faire quelques ajouts, pour prendre en compte la bibliothèque. J’ai mis en surbrillance les lignes qui diffèrent par rapport à d’habitude.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 |
PRG = remote OBJ = remote.o PROGRAMMER = avrisp PORT = COM4 MCU_TARGET = attiny85 AVRDUDE_TARGET = t85 OPTIMIZE = -Os DEFS = LIBS = -Iusbdrv -I. -DDEBUG_LEVEL=0 FUSE = -U lfuse:w:0xe1:m -U hfuse:w:0xdd:m HZ = 16500000UL OBJECTS = usbdrv/usbdrv.o usbdrv/usbdrvasm.o usbdrv/oddebug.o $(OBJ) # You should not have to change anything below here. CC = avr-gcc # Override is only needed by avr-lib build system. override CFLAGS = -g -DF_CPU=$(HZ) -Wall $(OPTIMIZE) -mmcu=$(MCU_TARGET) $(DEFS) $(LIBS) override LDFLAGS = -Wl,-Map,$(PRG).map OBJCOPY = avr-objcopy OBJDUMP = avr-objdump all: $(PRG).elf lst text #eeprom .S.o: $(CC) $(CFLAGS) $(LDFLAGS) -x assembler-with-cpp -c $< -o $@ $(PRG).elf: $(OBJECTS) $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJECTS) #$^ clean: rm -rf $(OBJECTS) *.o $(PRG).elf *.eps *.png *.pdf *.bak *.hex *.bin *.srec rm -rf *.lst *.map $(EXTRA_CLEAN_FILES) lst: $(PRG).lst %.lst: %.elf $(OBJDUMP) -h -S $< > $@ # Rules for building the .text rom images text: hex bin srec hex: $(PRG).hex bin: $(PRG).bin srec: $(PRG).srec %.hex: %.elf $(OBJCOPY) -j .text -j .data -O ihex $< $@ %.srec: %.elf $(OBJCOPY) -j .text -j .data -O srec $< $@ %.bin: %.elf $(OBJCOPY) -j .text -j .data -O binary $< $@ # Rules for building the .eeprom rom images eeprom: ehex ebin esrec ehex: $(PRG)_eeprom.hex #ebin: $(PRG)_eeprom.bin esrec: $(PRG)_eeprom.srec %_eeprom.hex: %.elf $(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O ihex $< $@ #%_eeprom.srec: %.elf # $(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O srec $< $@ %_eeprom.bin: %.elf $(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O binary $< $@ # command to program chip (invoked by running "make install") install: $(PRG).hex avrdude -F -p $(AVRDUDE_TARGET) -c $(PROGRAMMER) -P $(PORT) -b 19200 -v \ -U flash:w:$(PRG).hex format: avrdude -p $(AVRDUDE_TARGET) -c $(PROGRAMMER) -P $(PORT) -b 19200 -v \ -e -F fuse: avrdude -F -p $(AVRDUDE_TARGET) -c $(PROGRAMMER) -P $(PORT) -b 19200 -v \ $(FUSE) ddd: gdbinit ddd --debugger "avr-gdb -x $(GDBINITFILE)" gdbserver: gdbinit simulavr --device $(MCU_TARGET) --gdbserver gdbinit: $(GDBINITFILE) $(GDBINITFILE): $(PRG).hex @echo "file $(PRG).elf" > $(GDBINITFILE) @echo "target remote localhost:1212" >> $(GDBINITFILE) @echo "load" >> $(GDBINITFILE) @echo "break main" >> $(GDBINITFILE) @echo @echo "Use 'avr-gdb -x $(GDBINITFILE)'" |
Le programme hôte
Ici, tout se passe sur une machine sous Fedora 20.
commande-hote.c
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 |
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <stdbool.h> #include "libusb.h" #include "../requests.h" #include "../usbconfig.h" const char * command_name; static void usage() { fprintf(stderr, "usage:\n"); fprintf(stderr, " %s command <command id> # run command on IR\n", command_name); fprintf(stderr, " %s repeat <command id> <times> # run command on IR and repeat\n", command_name); } int main(int argc, char **argv) { command_name = argv[0]; int return_code = 0; if(argc<2){ fprintf(stderr, "Missing command.\n"); usage(); exit(1); } const unsigned char rawVid[2] = {USB_CFG_VENDOR_ID}; const unsigned char rawPid[2] = {USB_CFG_DEVICE_ID}; char vendor[] = {USB_CFG_VENDOR_NAME, 0}; char product[] = {USB_CFG_DEVICE_NAME, 0}; unsigned char buffer[4]; int vid, pid; vid = rawVid[1] * 256 + rawVid[0]; pid = rawPid[1] * 256 + rawPid[0]; libusb_device **list; libusb_context *ctx = NULL; libusb_init(&ctx); libusb_set_debug(ctx,3); libusb_device * current_device; libusb_device_handle * handle; ssize_t cnt = libusb_get_device_list(ctx, &list); ssize_t i = 0; bool device_found = false; for(i=0;(i<cnt) && !device_found;i++){ struct libusb_device_descriptor desc; current_device = list[i]; libusb_get_device_descriptor(current_device, &desc); device_found = (desc.idVendor == vid) && (desc.idProduct == pid); } if(!device_found){ fprintf(stderr, "Cannot find device %04x:%04x. Leaving.\n",vid,pid); exit(2); } if(libusb_open(current_device, &handle)){ fprintf(stderr, "Cannot open device %04x:%04x. Leaving.\n",vid,pid); exit(3); } if(strcasecmp(argv[1], "command") == 0) { if(argc<3){ fprintf(stderr, "Missing argument."); usage(); return_code = 1; }else{ unsigned char command = atoi(argv[2]); libusb_control_transfer(handle, LIBUSB_ENDPOINT_OUT | LIBUSB_REQUEST_TYPE_VENDOR|LIBUSB_RECIPIENT_DEVICE, CUSTOM_RQ_SEND_COMMAND, command, 0, buffer, 0, 5000 ); } }else if(strcasecmp(argv[1], "repeat") == 0) { if(argc<4){ fprintf(stderr, "Missing argument."); usage(); return_code = 1; }else{ unsigned char command = atoi(argv[2]); unsigned char times = atoi(argv[3]); /* Voici la ligne la plus interessante : c'est elle qui déclenche l'appel à usbSetupFunction() sur le micro-contrôleur. */ libusb_control_transfer(handle, LIBUSB_ENDPOINT_OUT | LIBUSB_REQUEST_TYPE_VENDOR|LIBUSB_RECIPIENT_DEVICE, CUSTOM_RQ_REPEAT_COMMAND, command | (times << 8), 0, buffer, 0, 5000 ); } }else{ fprintf(stderr, "Command %s not supported.\n",argv[1]); usage(); return_code = 1; } libusb_close(handle); return return_code; } |
Comme vous pouvez le voir, ce code à besoin d’inclure les fichiers ../requests.h et ../usbconfig.h .
Makefile
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
NAME = send USBFLAGS = `pkg-config --cflags libusb-1.0` USBLIBS = `pkg-config --libs libusb-1.0` OBJECTS = $(NAME).o CC = gcc CFLAGS = $(CPPFLAGS) $(USBFLAGS) -O -g -Wall LIBS = $(USBLIBS) PROGRAM = $(NAME) all: $(PROGRAM) .c.o: $(CC) $(CFLAGS) -c $< $(PROGRAM): $(OBJECTS) $(CC) -o $(PROGRAM) $(OBJECTS) $(LIBS) clean: rm -f *.o $(PROGRAM) |
Je ne sais pas ce qu’il en ait quant à l’outil pkg-config en dehors de Fedora, mais celui est plutôt pratique puisqu’il génère les options tout seul.
Utiliser un ATTiny85
Le problème que pose l’utilisation d’un ATTiny, est qu’il faut utiliser une horloge cadencée au minimum à 12MHz. Or l’ATTiny ne fonctionne correctement à 8MHz maximum. On va utiliser une astuce pour le passer à 16.5MHz sans cristal externe : la PLL (Phase-Locked Loop : boucle à verrouillage de phase).
Sans entrer dans les détails, il s’agit d’un dispositif qui permet d’augmenter la fréquence d’un micro-contrôleur (basée sur un cristal), au prix de sa stabilité. Il est ainsi possible de faire fonctionner un ATTiny au delà de 80MHz ! Mais dans notre cas, 16.5MHz suffiront.
Pour cela il est nécessaire d’harmoniser la fréquence au début de l’exécution. Ceci se fait en définissant un « hook » dans le ficher usbconfig.h , en y ajoutant la fonction hadUsbReset() , qui s’occupera d’appeler une autre fonction ( calibrateOscillator() ), qui calibrera l’oscillateur PLL.
L’exemple donné dans cet article prend déjà en compte ces modifications.
Dans le cas d’un micro-contrôleur capable d’utiliser une horloge à 16.5MHz, il n’y a pas besoin de ce dispositif, et donc des fonctions hadUsbReset() , calibrateOscillator() ainsi que des lignes suivantes dans usbconfig.h :
1 2 3 4 |
#define USB_RESET_HOOK(resetStarts) if(!resetStarts){hadUsbReset();} #ifndef __ASSEMBLER__ extern void hadUsbReset(void); // define the function for usbdrv.c #endif |
Et voilà !
Voici les sources du projet : RGB remote (fichier 7z).
Lorsque vous branchez votre périphérique, les messages suivants doivent apparaitre dans dmesg.
1 2 3 4 |
[175698.607042] usb 1-6.3: New USB device found, idVendor=16c0, idProduct=05dc [175698.611020] usb 1-6.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [175698.615146] usb 1-6.3: Product: IR-Led [175698.619047] usb 1-6.3: Manufacturer: cicatrice.eu |
Une fois le programme hôte compilé, vous pouvez envoyer des commandes au micro-contrôleur avec les commandes suivantes :
1 2 |
./send command 2 #envoie la commande 0x02 ./send repeat 186 5 #envoie 5 fois la commande 0xBA |