Mysterieuze RX-pulsen op UART-verbinding op OS X Arduino Due

Arduino IDE 1.6.8, Arduino Due, Mac OS 10.11.3

Ik zie acht mysterieuze pulsen op de RX-lijn wanneer ik verbinding maak met de seriële poort met behulp van meerdere clientbibliotheken (Python, JavaScript en de ingebouwde seriële monitor in de IDE). Ongeveer 78-79us per stuk, gesampled bij 1MS/s met een Logic Pro 16.

Mystery pulses

Deze acht pulsen wanneer geïnterpreteerd op 57600 baud zullen de Firmata-firmware blokkeren. En ze gebeuren op elke verbinding.

Dit gebruikt een nieuwe installatie van de Arduino 1.6.8 IDE en met meerdere schetsen (de normale "Blink" schets zal dit ook weergeven).

Repro-stappen op mijn machine:

  1. Installeer een schets
  2. Start een logicanalysator als je deze wilt vangen
  3. Ga naar seriële monitor. Ik heb de mijne geconfigureerd voor 57600 baud, het einde van de Newline-regel, maar dat maakt niet uit
  4. Als je wilt, sluit en herhaal je stap 3
  5. Opmerking pulseert elke keer dat u verbinding maakt met de seriële poort

Eventuele suggesties voor het diagnosticeren van dit? Het klinkt alsof het op een bepaald seriële driverniveau is.

14
Ongeacht waar het vandaan komt, bedenk dat het u een plezier heeft gedaan door een kritieke bug aan te geven in de firmware die u gebruikt - dit zou niet in staat moeten zijn om het in een onherstelbare staat te brengen. Is het een fout in de programmalogica of wordt de foutcode niet correct behandeld door de UART-verwerkingscode?
toegevoegd de auteur rossp, de bron
In termen van het opsporen van de bron, zou het nuttig zijn om een ​​ander serieel cliëntprogramma, een andere computer/besturingssysteem, een ander USB-serieel apparaat, enz. Te proberen ...
toegevoegd de auteur rossp, de bron
Je krijgt een enkele puls op Linux die wordt geïnterpreteerd op 57600 als 0xF0
toegevoegd de auteur Majenko, de bron
Je krijgt er ook een wanneer je de verbinding verbreekt. De verbindingsbaudrate heeft geen effect op de lengte van de puls. Mijn vermoeden is dat het de firmware van de ATMega16U2 is die het doet (of welke chip het ook is in welke versie dan ook).
toegevoegd de auteur Majenko, de bron
Bedankt voor de input, Chris. Wanneer de Firmata-firmware een 0xF0 ziet START_SYSEX , het zal bytes verwerken totdat het een 0xF7 ziet, en er is geen voorziening voor een time-out. Dus ik denk dat wat er gebeurt is dat deze pulsen een 0xF0 genereren (je kunt dit zien aan mijn decodering), waardoor de verdere commandoverwerking effectief wordt uitgeschakeld omdat er geen 0xF7 is die eindigt. Ik denk dat het beste wat ik kan doen voor Firmata is om een ​​patch in te leveren voor een time-out na een of ander interval dat lang genoeg is voor het langste legitieme datapakket.
toegevoegd de auteur user19292, de bron
Wat betreft het proberen van andere seriële programma's, zijn er meerdere bibliotheken die communiceren met het Firmata-protocol en verschillende onderliggende seriële implementaties gebruiken (Python, JavaScript en de ingebouwde Arduino IDE Seriële Monitor) die hetzelfde gedrag vertonen. Mijn volgende plan is om dit op een Linux-computer te proberen en te kijken of ik hetzelfde gedrag zie, dat hopelijk zal isoleren als dit OS X-specifiek is.
toegevoegd de auteur user19292, de bron
Wanneer u de seriële monitor start, stelt de software de arduino-module opnieuw in. Als de arduino-module een bootloader bevat, denk ik dat dit de STK500-protocolsignalen zijn.
toegevoegd de auteur Aleksandar Ivanisevic, de bron
Krijgt je Arduino de stroom van de USB?
toegevoegd de auteur U. Laxmeshwar, de bron

1 antwoord

kort:

Kijken naar de ATMEGA16U2-firmware ( https://github.com/arduino/ArduinoCore-sam/blob/master/firmwares/atmega16u2/arduino-usbserial/Arduino-usbserial.c ) Ik vind dat, wanneer u instellingen van de USB-emulatie configureert/wijzigt seriële poort, de USART wordt hervat. Dit gebeurt zelfs wanneer u de Arduino-seriële monitor opent (hij moet de seriële snelheid configureren, enz.). Dit veroorzaakt je piek.

Lang:

Kijk naar functie:

void EVENT_CDC_Device_LineEncodingChanged(USB_ClassInfo_CDC_Device_t* const CDCInterfaceInfo)

Daar zie je dat na enkele regels de USART wordt gereset door de registers op nul te zetten:

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

Op pagina 168 van het huidige ATMEGA16U2-gegevensblad ziet u dat u, door UCSR1B's bit 3 (TXEN1) in te stellen, de transmitter inschakelt, waarbij de normale poortbewerking wordt overschreven (d.w.z. deze wordt uitvoer). Citaat van de datasheet:

Als u dit bit naar een schrijft, kan de USART-zender worden gebruikt. De zender   zal de normale poortbewerking voor de TxDn-pin onderdrukken als deze is ingeschakeld. De   uitschakeling van de zender (TXENn naar nul schrijven) zal niet worden   effectief totdat lopende en hangende transmissies zijn voltooid, d.w.z.   wanneer het Transmit Shift Register en het Transmit Buffer Register dat niet doen   bevatten gegevens die moeten worden verzonden. Wanneer uitgeschakeld, zal de zender nee   verleng de TxDn-poort langer.

Daarom hebt u door het schrijven van UCSR1B = 0; niet langer de TXD1-pin te negeren, die als invoer fungeert.

De ATMEGA16U2 TXD is verbonden met de RX-lijn van de ATSAM3X8E. In normale werking, met de UART ingeschakeld, blijft die lijn hoog als er geen gegevens worden verzonden. Als u de UART uitschakelt, is die specifieke regel geen driver voor 1. Aangezien de initialisatiecode niet de pull-up op die pin instelt (en ook niet dat deze is geconfigureerd als uitvoer), wordt de pin een zwevende invoer en wordt elke lekkage naar GND of zelfs de ingangsimpedantie van uw sonde (die zich tussen uw pin en GND bevindt), brengt het logisch niveau langzaam naar 0.

Om dit probleem op te heffen, moet u: 1) Pas de ATMEGA16U2-firmware aan door die PIN in te stellen als OUTPUT, met waarde 1. 2) Pas de ATMEGA16U2-firmware aan door de pull-up op die pin in te schakelen. 3) (voorgesteld) Schakel de pull-up op de RX-lijn op de ATSAM3X8E in.

1
toegevoegd