Mystérieuses impulsions RX sur UART connect sous OS X Arduino Due

Arduino IDE 1.6.8, Arduino Due, Mac OS 10.11.3

Je vois huit impulsions mystérieuses sur la ligne RX lorsque je me connecte au port série en utilisant plusieurs bibliothèques clientes (Python, JavaScript ainsi que le moniteur série intégré dans l'EDI). Environ 78-79us chacun, échantillonné à 1 ms / s avec un Logic Pro 16.

Ces huit impulsions, lorsqu'elles sont interprétées à 57600 bauds, bloqueront le firmware Firmata. Et ils se produisent à chaque connexion.

Cela utilise une nouvelle installation de l'Arduino 1.6.8 IDE et avec plusieurs croquis (le croquis "Blink" normal le reproduira également).

Étapes de repro sur ma machine:

Installer n'importe quel croquis
Démarrez un analyseur logique si vous voulez l'attraper
Accédez à Serial Monitor. J'ai le mien configuré pour 57600 bauds, fin de ligne Newline, mais cela n'a pas d'importance
Si vous le souhaitez, fermez et répétez l'étape 3
Notez les impulsions chaque fois que vous vous connectez au port série

Des suggestions pour diagnostiquer cela? Il semble que ce soit au niveau du pilote série en quelque sorte.

arduino-due uart osx

— Blake Ramsdell
source

Peu importe d'où il vient, considérez qu'il vous a rendu service en indiquant un bogue critique dans le firmware que vous exécutez - cela ne devrait pas pouvoir le mettre dans un état irrécupérable. S'agit-il d'un bogue de logique de programme ou le code de gestion UART ne traite-t-il pas correctement un indicateur d'erreur?

— Chris Stratton

En termes de traçage de la source, il serait utile d'essayer un autre programme client série, un autre ordinateur / système d'exploitation, un autre périphérique USB série, etc ...

— Chris Stratton

En ce qui concerne les autres programmes série, il existe plusieurs bibliothèques qui interagissent avec le protocole Firmata et utilisent différentes implémentations série sous-jacentes (Python, JavaScript et Arduino IDE Serial Monitor intégré) qui présentent le même comportement. Mon prochain plan est d'essayer cela sur une machine Linux et de voir si je vois le même comportement, ce qui, espérons-le, isolera si c'est spécifique à OS X.

— Blake Ramsdell

Vous en obtenez également un lorsque vous vous déconnectez. Le débit en bauds de connexion n'a aucun effet sur la durée de l'impulsion. Je soupçonne que c'est le firmware du ATMega16U2 qui le fait (ou quelle que soit la puce sur n'importe quelle version).

— Majenko

Lorsque vous démarrez le moniteur série, le logiciel réinitialise le module Arduino. Si le module Arduino contient un chargeur de démarrage, je pense que ce sont les signaux du protocole STK500.

— Mert Gülsoy

Court:

En regardant le firmware ATMEGA16U2 ( https://github.com/arduino/ArduinoCore-sam/blob/master/firmwares/atmega16u2/arduino-usbserial/Arduino-usbserial.c ), je trouve que, lorsque vous configurez / modifiez les paramètres du Port série émulé USB, l'USART est réinitialisé. Cela se produit même lorsque vous ouvrez le moniteur série Arduino (il doit configurer la vitesse série, etc.). Cela provoque votre pic.

Longue:

Regardez la fonction:

void EVENT_CDC_Device_LineEncodingChanged(USB_ClassInfo_CDC_Device_t* const CDCInterfaceInfo)

Vous verrez qu'après quelques lignes, il réinitialise l'USART, en mettant à zéro ses registres:

/* Must turn off USART before reconfiguring it, otherwise incorrect operation may occur */
    UCSR1B = 0;
    UCSR1A = 0;
    UCSR1C = 0;

À la page 168, de la feuille de données ATMEGA16U2 actuelle, vous constaterez qu'en définissant le bit 3 de l'UCSR1B (TXEN1), vous activez l'émetteur, remplaçant le fonctionnement normal du port (c'est-à-dire qu'il devient une sortie). Citant la fiche technique:

L'écriture de ce bit sur un active l'émetteur USART. L'émetteur annule le fonctionnement normal du port pour la broche TxDn lorsqu'il est activé. La désactivation de l'émetteur (écriture de TXENn sur zéro) ne prendra effet que lorsque les transmissions en cours et en attente seront terminées, c'est-à-dire lorsque le registre à décalage de transmission et le registre de tampon de transmission ne contiennent pas de données à transmettre. Lorsqu'il est désactivé, l'émetteur ne remplacera plus le port TxDn.

Par conséquent, en écrivant, UCSR1B = 0;vous ne remplacez plus la broche TXD1, qui agira comme entrée.

L'ATMEGA16U2 TXD est connecté à la ligne RX de l'ATSAM3X8E. En fonctionnement normal, avec l'UART activé, cette ligne reste élevée si aucune donnée n'est transmise. Si vous désactivez l'UART, cette ligne particulière n'est plus un pilote à 1. Étant donné que le code d'initialisation ne définit pas le pull-up sur cette broche (et qu'il n'est pas configuré en sortie), la broche devient une entrée flottante et toute fuite vers GND ou même l'impédance d'entrée de votre sonde (qui est entre votre broche et GND) ramènera lentement le niveau logique à 0.

Pour contourner cela, problème, vous devez soit: 1) Modifier le micrologiciel ATMEGA16U2, en définissant ce code PIN comme SORTIE, avec la valeur 1. 2) Modifier le micrologiciel ATMEGA16U2, en activant le pull-up sur cette broche. 3) (suggéré) Activez le pull-up sur la ligne RX sur l'ATSAM3X8E.

— prochain hack
source