Comment procéder lorsque vous avez besoin d'un système maître-esclave I2C personnalisé?

Quels sont les critères de conception à appliquer?

Quels sont les outils de débogage que l'on peut utiliser pour résoudre les problèmes?

Ce tutoriel que j'ai donné à la conférence Linux embarqué essaie de répondre aux questions, en fournissant des liens vers une description plus détaillée des sujets abordés et en utilisant l'exemple pratique de la conduite d'un drone 4WD, où un Arduino Mini Pro agit comme esclave et contrôle les 4 roues indépendantes . Le document original se trouve ici .

Remarque: Cette réponse est actuellement en cours d'élaboration, car j'adapte les faits saillants du lien.

Applications typiques du bus I2C

• Interface avec des périphériques relativement lents. Ex: capteurs, actionneurs mécaniques.

• Contrôle des périphériques «rapides», qui utilisent d'autres canaux pour l'échange de données. Ex: codecs.

  Dans un PC, le système d'exploitation interagit généralement sur I2C avec:

  • compteurs de température et de tension de batterie;
  • contrôleurs de vitesse de ventilateur;
  • codecs audio.

Dans le cas où plusieurs contrôleurs de bus sont disponibles, les périphériques sont regroupés par vitesse, afin que les plus rapides ne soient pas pénalisés par les plus lents.

Une introduction rapide au bus I2C - caractéristiques clés

• Bus série.
• Seulement 2 lignes: Serial CLock et Serial DAta (plus la masse).
• 4 vitesses: 100 kHz, 400 kHz, 1 MHz, 3,2 MHz.
• En règle générale, 1 appareil maître et 1 ou plusieurs esclaves.
• Les communications sont toujours initiées par un appareil maître.
• Plusieurs maîtres peuvent coexister sur le même bus (multi-maître).
• Drain ouvert: les deux SDA et SCL ont besoin de résistances de pull-up.
• «Étirement de l'horloge»
  • Le maître contrôle SCL, mais un esclave peut le maintenir enfoncé (car drain ouvert), s'il a besoin d'ajuster la vitesse.
  • Le maître doit vérifier ce scénario.
  • Un esclave peut se coincer et bloquer le bus: nécessité de réinitialiser les lignes du maître vers l'esclave.
• L'adressage généralement sur 7 bits, mais également sur 10 bits est pris en charge.
• Protocole logique: les niveaux de tension réels ne sont pas spécifiés et dépendent des implémentations individuelles. Ex: 1,8 V / 3,3 V / 5,0 V

URL de référence:

• http://www.i2c-bus.org
• http://www.robot-electronics.co.uk/i2c-tutorial

Exemple de configuration de bus

Caractéristiques du protocole (simplifié)

• 2 types de messages: lecture et écriture
• Bit de démarrage / d'arrêt - représenté par «[« et «]» dans le reste de la réponse
• Adresse: 7 ou 10 bits
• Bit R / W: R = 1 / W = 0 Utilisé pour discriminer le type de message envoyé.
• Données sur le bus: (Adresse << 1 | R / W)
• Enregistre en tant que gestionnaires d'informations, dans le périphérique sélectionné.

Exemple de trafic de bus

Esclaves personnalisés

Pourquoi créer un esclave I2C personnalisé?

• Capteur / actionneur souhaité non disponible avec l'interface I2C.
• Moins d'adresses uniques disponibles que les esclaves nécessaires.
• Fonctionnalité personnalisée souhaitée sur l'esclave:
  • Réactions semi-autonomes aux stimuli.
  • Filtrage / prétraitement des données d'entrée.
• Optimisation de l'alimentation: le «concentrateur de capteurs» personnalisé fait le ménage pendant que le processeur principal est inactif.
• Réponse en temps réel aux entrées.
• [votre imagination ici]

Comment concevoir un esclave I2C personnalisé?

• Définissez les exigences (voir la diapositive précédente).
• Choisissez un microcontrôleur ou un microprocesseur.
• Choisissez le planificateur ou le système d'exploitation (le cas échéant).
• Définissez le sous-protocole de communication:
  • Définissez les paramètres et les commandes à échanger.
  • Organisez-les en «registres» et choisissez une adresse gratuite.

Conception du maître I2C

Critères de conception clés:

• Poids / Dimensions.
• Puissance de calcul requise et latence moyenne.
• Appareil de type PC
  • Appareil intégré, généralement sans tête.
  • Langage de programmation préféré: interprété vs compilé.
• Disponibilité de bus / gpios pour conduire les esclaves:
  • GPIO uniquement: bitbang le protocole
  • I2C: application espace utilisateur vs pilote noyau.
  • Pas d'interfaces GPIO / I2C disponibles: adaptateur USB vers I2C.

Débogage: diviser et conquérir

Prenez le contrôle direct du bus avec un appareil ad hoc. Exemples:

• Pirate de bus (utile aussi pour d'autres bus)
• Adaptateur USB vers maître I2C, également basé sur la puce FTDI FT232R.
• Appareil personnalisé (pourrait être un projet distinct).

• Snoop le bus avec un analyseur logique ou un oscilloscope / mètre avancé. Exemples:

  • sigrok / pulseview avec analyseur logique compatible
  • Portée / mètre autonome 2 canaux

  • Utilisez un débogueur / émulateur de circuit spécifique à l'esclave.

    Exemple: AVR Dragon pour puces AVR (Arduino UNO, Nano, Mini, MiniPro)

Pirate BUS

• Principalement à des fins de développement.
• Peut à la fois renifler le bus et le conduire.
• Interface de console sur le port série (ttyACM), y compris les macros, ou accès programmatique pour plusieurs langages de programmation.
• Résistances de pullup et sources de tension intégrées (5V / 3,3V)
• Prend en charge de nombreux autres protocoles.
• Références: Wikipedia , page principale

Adaptateur USB vers I2C

• Petite empreinte.
• Convient aux installations permanentes.
• Pas besoin de connexions spéciales sur l'hôte: il peut être utilisé pour s'interfacer avec un PC typique.
• Variante disponible également compatible SPI.
• Pas d'interface console, uniquement un protocole binaire série.
• Nécessite un wrapper de protocole .
• Référence: protocole

sigrok et pulseview

logo sigrok (composant bakend)

exemple de pulseview (visualiseur)

Exemple d'analyseur logique bas de gamme

• Norme de facto pour les mesures pilotées par PC sur Linux (mais également disponible sur d'autres systèmes d'exploitation).
• Prise en charge d'une vaste gamme d'analyseurs logiques, de portées et de compteurs.
• Divers décodeurs de protocole, y compris I2C.
• Utile pour visualiser les signaux logiques et déboguer les erreurs de protocole.
• Même un matériel très bas de gamme et peu coûteux peut fournir une toute nouvelle dimension au débogage.
• Références: sigrok , pulseview , matériel pris en charge

Exemple: piloter un drone 4x4

Prototype construit avec 2 Arduino Mini Pro.

Que fait l'esclave dans l'exemple?

L'esclave I2C:

• Contrôle la quantité de couple appliquée à chaque roue.
• Contrôle la direction de rotation de chaque roue.
• Mesure la vitesse de rotation de chaque roue grâce à un codeur optique (compteur kilométrique).
• Expose les paramètres ci-dessus au maître I2C.

Schéma fonctionnel de haut niveau de l'esclave I2C.

Sélection de l'esclave: Arduino Mini Pro

• Assez de broches / fonctions pour fournir à chaque roue:
  • 1 sortie PWM avec configuration indépendante du rapport cyclique.
  • 1 GPIO pour enregistrer l'entrée du compteur kilométrique comme IRQ.
  • 2 GPIO pour sélectionner:
    • Vers l'avant
    • Sens inverse
    • Tourner au ralenti
    • Fermer à clé
• Bloc I2C HW pour les échanges i2c déclenchés par interruption.
• Broches dédiées pour la programmation basée sur SPI.
• Petite empreinte.
• À bas prix.
• La disposition de la carte du clone représenté dans l'image est optimisée pour un montage sur un socket DIL.

ICD spécifique à l'esclave: AVR Dragon

• Prend en charge divers modes de programmation, y compris la programmation SPI, via AVRDude .
• N'interfère pas avec les opérations normales de l'AVR, il peut donc être laissé branché sur le système.
• Après avoir activé l'interface debugWire, il permet de configurer les points d'arrêt HW / SW, par un backend dédié pour gdb / ddd.

Sélection du système d'exploitation: ChibiOS

• RTOS: préemption, tâches, sémaphores, tic système dynamique, etc.
• Petite empreinte: lien uniquement code / données utilisé.
• Distinction entre RTOS et BSP via HAL.
• GPLv3 pour une utilisation non commerciale.
• Activement développé, mais déjà mature.
• Prend en charge l'AVR 8 bits.

Cependant, il avait un support BSP limité pour AVR, manque de: - interruption du pilote pour les GPIO AVR (ajouté). - Prise en charge I2C pour le mode esclave AVR (personnalisé). Qui devait être développé séparément dans le cadre du logiciel Drone pour l'AVR .

Définition des paramètres de communication

Pour chaque roue:

• Cycle de service du signal PWM utilisé pour le piloter - 1 octet. 0xFF = couple max / 0x00 = pas de couple.

• Sens de rotation - 1 octet.

  • 0x00 = inactif
  • 0x01 = inverse
  • 0x02 = avant
  • 0x03 = verrouillé

• Période moyenne entre les créneaux du codeur optique - 2 octets.

  • L'écriture de quelque chose réinitialise la mesure.

• Index des paramètres - 1 quartet:

  • 0 = rapport cyclique
  • 1 = Direction
  • 2 = période moyenne

• Index des roues - 1 quartet:

  • 0 = arrière gauche
  • 1 = arrière droit
  • 2 = avant droit
  • 3 = avant gauche
  • 4 = Tout

Sous-protocole: définition des registres

Format de registre: 0xαβ - α = Index des paramètres - β = Index des roues

Adresse (choisie arbitrairement): 0x10

Format Bus Pirate: - [= bit de début -] = bit de fin - r = octet de lecture - temps d'adresse 2 (décalage à gauche 1), pour le bit R / W

Exemple - au format Bus Pirate

[i2c_addr reg_addr = (parm, wheel) reg_value]

[0x20 0x20 0x02]  Left Rear Forward
[0x20 0x21 0x01]  Right Rear Backward
[0x20 0x22 0x01]  Right Front Backward
[0x20 0x23 0x02]  Left Front Forward
[0x20 0x14 0xFF]  Wheels set to max torque

La voiture tourne dans le sens des aiguilles d'une montre.