Таємничі імпульси RX на UART підключаються до OS X Arduino Due

Arduino IDE 1.6.8, Arduino Due, Mac OS 10.11.3

Я бачу вісім загадкових імпульсів на лінії RX, коли я підключаюся до послідовного порту, використовуючи декілька бібліотек клієнтів (Python, JavaScript, а також вбудований послідовний монітор в IDE). Близько 78-79us за одиницю, вибірка при 1MS/s з Logic Pro 16.

Mystery pulses

Ці вісім імпульсів при інтерпретації при 57600 бодах заклинюють прошивку фірми. І вони відбуваються на кожному зв'язку.

Це використовує нову установку Arduino 1.6.8 IDE і з декількома ескізами (звичайний "Blink" ескіз буде відтворювати це також).

Повторні кроки на моїй машині:

  1. Установити будь-який ескіз
  2. Запустіть логічний аналізатор, якщо ви хочете його схопити
  3. Перейти до послідовного монітору. У мене є налаштований на 57600 бод, закінчення лінії нового рядка, але це не має значення
  4. Якщо потрібно, закрийте та повторіть крок 3
  5. Зверніть увагу на імпульси при кожному підключенні до послідовного порту

Будь-які пропозиції щодо діагностики цього? Це звучить як серійний рівень драйвера.

14
Незалежно від того, звідки він приходить, вважайте, що він зробив вам користь, вказавши критичну помилку в прошивці, яку ви працюєте - це не повинно бути в змозі покласти його в непоправному стані. Це помилка програмної логіки, або код обробки UART не справляється належним чином з прапором помилки?
додано Автор rossp, джерело
З точки зору відстеження джерела, було б корисно спробувати іншу послідовну клієнтську програму, інший комп'ютер/операційну систему, інший USB-послідовний пристрій і т.д.
додано Автор rossp, джерело
Ви отримуєте один імпульс на Linux, який інтерпретується на рівні 57600 як 0xF0
додано Автор Majenko, джерело
Ви також отримуєте один при відключенні. Швидкість передачі зв'язку не впливає на довжину імпульсу. Мої підозри в тому, що це прошивка ATMega16U2, яка робить це (або яка б вона не була на будь-якій версії).
додано Автор Majenko, джерело
Дякуємо за внесок, Кріс. При прошивці Firmata бачить 0xF0 START_SYSEX , він обробляє байти, поки не побачить 0xF7, і не існує положення для тайм-ауту. Так що я думаю, що відбувається, що ці імпульси генерувати 0xF0 (ви можете бачити це з мого декодування), який ефективно вимикає подальшу обробку команд, оскільки немає припинення 0xF7. Я думаю, що найкраще, що я можу зробити для Firmata, є подання виправлення на тайм-аут після деякого інтервалу, який є достатньо довгим для найдовшого пакета даних.
додано Автор user19292, джерело
Що стосується спроб інших послідовних програм, існує кілька бібліотек, які взаємодіють з протоколом Firmata і використовують різні основні серійні реалізації (Python, JavaScript і вбудований серійний монітор IDE Arduino), які демонструють таку ж поведінку. Наступний мій план полягає в тому, щоб спробувати це на машині Linux і подивитися, чи я бачу таку ж поведінку, яка, сподіваюся, виділить, якщо це специфікація OS X.
додано Автор user19292, джерело
Коли ви запускаєте серійний монітор, програмне забезпечення скидає модуль arduino. Якщо arduino модуль має завантажувач в ньому, я думаю, що це сигнали протоколу STK500.
додано Автор Aleksandar Ivanisevic, джерело
Чи приймає ваш Arduino живлення від USB?
додано Автор U. Laxmeshwar, джерело

1 Відповіді

Короткий:

Дивлячись на прошивку ATMEGA16U2 ( https://github.com/arduino/ArduinoCore-sam/blob/master/firmwares/atmega16u2/arduino-usbserial/Arduino-usbserial.c ) Я вважаю, що при налаштуванні/зміні налаштувань USB послідовний порт, USART скидається. Це відбувається навіть при відкритті послідовного монітора Arduino (він повинен налаштувати послідовну швидкість і т.д.). Це викликає ваш сплеск.

Довго:

Подивіться на функцію:

void EVENT_CDC_Device_LineEncodingChanged(USB_ClassInfo_CDC_Device_t* const CDCInterfaceInfo)

Там ви побачите, що після деяких рядків він скидає USART, обнуляючи його регістри:

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

На сторінці 168 поточної таблиці ATMEGA16U2 ви побачите, що, встановивши біт 3 UCSR1B (TXEN1), ви включите передавач, перекриваючи нормальну роботу порту (тобто він стає виходом). Цитування даних:

Запис цього біта на один дає перемикач USART. Передавач   буде перевизначено нормальну операцію порту для PIN-коду TxDn, якщо увімкнено. The   Відключення передавача (написання TXENn до нуля) не стане   діє до тих пір, поки не будуть завершені поточні та очікувані передачі, тобто   коли реєстр передачі та реєстраційний буфер не є   містять дані для передачі. Коли вимкнено, передавач буде відсутній   більше перевизначити порт TxDn.

Тому, якщо ви пишете UCSR1B = 0; , ви більше не перекриваєте висновок TXD1, який буде діяти як вхідний.

TXD ATMEGA16U2 підключено до лінії RX ATSAM3X8E. При нормальному режимі роботи з включеним UART ця лінія залишається високою, якщо дані не передаються. Якщо ви відключите UART, цей рядок не буде більше драйвером до 1. Оскільки код ініціалізації не встановлює підтягування на цьому шпильці (і ніхто не налаштований як вихідний), контакт стає плаваючим входом, а будь-яка витік до GND або навіть вхідний опір вашого зонда (який знаходиться між вашим штифтом і GND), буде повільно довести рівень логіки до 0.

Щоб змінити цю проблему, вам слід: 1) Змініть прошивку ATMEGA16U2, встановивши цей PIN як OUTPUT, з значенням 1. 2) Змініть прошивку ATMEGA16U2, увімкнувши підтягування на цьому виводі. 3) (запропоновано) Увімкніть підтягування лінії RX на ATSAM3X8E.

1
додано