Раз уж я буду использовать UART для связки устройств блога с Вашими проектами немного расскажу как он устроен и как им пользоваться.
Универсальный асинхронный приемопередатчик (UART) довольно старый и распространенный интерфейс. До недавнего времени разъем COM порта (тот-же UART только уровни напряжения другие) был обязательным атрибутом каждого компьютера. Теперь COM порт постепенно «отмирает» и если на «башнях» он еще не редкость, то на ноутбуках его уже нет и в помине. Но в виду простоты и популярности интерфейса подавляющее большинство микроконтроллеров имеет UART в составе своей периферии. И если персональный компьютер UART перестает удовлетворять из-за низкой скорости и невозможности расширения, то для микроконтроллеров интерфейс удобен и использование его будет продолжаться.
Раз UART есть во многих микроконтроллерах, значит мы его будем использовать как один из интерфейсов связи устройств блога с Вашими электронными устройствами.
Для начала немного теории работы интерфейса
(без лишних подробностей). Для связи по интерфейсу UART используется две ножки контроллера RXD
– для приема сообщений (Receiver) и TXD
– для передачи сообщений (Transmitter). UART — полнодуплексный интерфейс. Это значит, что приемник и передатчик работают независимо друг от друга. Более того, передатчик или приемник можно отдельно отключить, освободив ножку контроллера для других нужд. Передача (соответственно и прием) сообщений осуществляется фиксированными пакетами битов (такой пакет называют кадром). Кадр состоит из старт-бита
(с него начинается каждый кадр), битов данных
(может быть от 5 до 9 бит), бита проверки четности
(проверка правильности передачи данных) и одного или двух стоп-битов
(сигнал об окончании кадра).
где:
IDLE
— ожидание обмена — должна быть 1
;
St
— Старт-бит — всегда 0
;
(n)
— Биты данных — может быть от 5 до 9 бит;
P
— Бит четности;
Sp
— Стоп бит — всегда 1.
Если посылка содержит более одного байта, каждый следующий байт передается отдельным кадром. Передача (и прием) данных ведется на определенных фиксированных частотах (измеряется в Бод=бит/сек) от 600 до 128 000 Бод. Условием правильной работы порта есть задание одинаковых параметров, как для приемника, так и для передатчика (скорость, количество бит данных, бит четности, количество стоп битов).
Договоримся о формате кадра (настройках UART) для устройств блога:
Скорость передачи – 9600
(это в пределах килобайта в секунду);
Количество бит данных – 8
(наиболее удобно работать);
Бит четности – Even
(производится проверка на четность);
Количество стоп-бит – 1;
В сокращенном варианте это выглядит так:
Baud Rate: 9600, 8 Data, 1 Stop, Even Parity
Еще UART может работать в синхронном режиме (для этого задействуется еще одна ножка контроллера) и поддерживать адресацию множества устройств. Но так как наши устройства несложны и нам не нужны данные функции, то рассматривать мы их не будем.
Если нужны дополнительные возможности, то полное описание UART есть в datasheet на микроконтроллер – обращайтесь к нему.
Для того чтобы устройство с блога начало работать с Вашим проектом через интерфейс UART нужно:
1 Подключить устройство блога к соответствующим ножкам микроконтроллера.
2 Настроить приемо-передатчик UART Вашего контроллера. Для этого в соответствующие порта ввода/вывода записать определенные значения.
3 Иметь (написать) процедуры приема/передачи сообщений по UART в Вашей программе.
Теперь рассмотрим подробно каждый пункт:
1 СОЕДИНЕНИЕ УСТРОЙСТВ ПОСРЕДСТВОМ UART.
Тут все просто:
— если планируется и прием и передача — устройства соединяются по двум линиям — TX_устройства с RX_проекта и TX _проекта с RX_устройства (здесь и далее под «устройством» я буду понимать устройство с блога, а под «проектом» — Ваш электронный проект);
— если нужен только прием (например принимаются данные с клавиатуры) — TX_устройства с RX_проекта;
— если нужна только передача (например передаются данные на устройство отображения) — TX _проекта с RX_устройства.
2 НАСТРОЙКА ПРИЕМО-ПЕРЕДАТЧИКА UART.
Как мы договорились выше, формат кадра для наших устройств:
Baud Rate: 9600, 8 Data, 1 Stop, Even Parity
Для работы в с этим форматом кадра нужно в разделе инициализации устройств в Вашей программе, записать соответствующие значения в нужные порта ввода/вывода контроллера. Для этого нужно открыть раздел USART datasheet’а на Ваш микроконтроллер и выбрать/вычислить необходимые значения. Но можно сделать все гораздо проще – использовать автоматические настройщики периферии – CodeWisard’ы.
Возьмем для примера микроконтроллер Attiny2313 (по аналогии можно настроить любой микроконтроллер) и настроим UART в разных языках программирования.
Для начала — Algorithm Builder
.
Тут все предельно просто – создаем проект (Файл/Новый
). Выбираем микроконтроллер и частоту задающего генератора в Опции/Опции проекта…
(ATtiny2313, внутренний задающий генератор на 8МГц). В панели инструментов жмем кнопочку «S»
— настройщик управляющих регистров» выбираем USART
и в открывшемся окошке заполняем все как на картинке. Там все подписано и понятно.
Жмем «ОК»
. Готово – UART проинициализирован и готов к работе.
Если нужен только приемник или только передатчик ставим только нужную галочку – незадействованную ножку можно использовать как порт ввода-вывода.
Так как в программе будут разрешены прерывания, нужно перед инициализацией USART установить указатель стека на конец памяти («S» /Stack Pointer SP ) и озаглавить вершину блока ключевым словом «Reset ».
В ассемблере. Честно говоря, я не знаю, есть ли в асемблерах для AVR настройщики периферии, но даже если нет, простое решение использовать все тот же Algorithm Builder. В окошке настройки USART, в правой части, прописаны мнемокоманды (Operations), обеспечивающие выбранные характеристики. Перевести их в ассемблерный код не составит труда.
Переводим в ассемблерные команды.
| ;USART initialization ;Communication Parameters: 8 Data, 1 Stop, Even Parity ;USART Receiver: On ;USART Transmitter: On ;USART Mode: Asynchronous ;USART Baud Rate: 9600 uart_init: LDI R16, $ 00 OUT UBRRH, R16 LDI R16, $ 33 OUT UBRRL, R16 LDI R16, $ 26 OUT UCSRC, R16 LDI R16, $ 00 OUT UCSRA, R16 LDI R16, $ 98 OUT UCSRB, R16 |
;USART initialization ;Communication Parameters: 8 Data, 1 Stop, Even Parity ;USART Receiver: On ;USART Transmitter: On ;USART Mode: Asynchronous ;USART Baud Rate: 9600 uart_init: LDI R16, $00 OUT UBRRH,R16 LDI R16, $33 OUT UBRRL,R16 LDI R16,$26 OUT UCSRC, R16 LDI R16,$00 OUT UCSRA, R16 LDI R16,$98 OUT UCSRB, R16
CodeVision содержит свой настройщик периферии (CodeWisard), еще похлеще чем у Algorithm Builder’а. Для генерации настроек UART, нажимаем на значок шестеренку (CodeWisardAVR ) на панели инструментов. В открывшемся окошке сначала выбираем вкладку Chip в ней выбираем микроконтроллер и устанавливаем частоту, с которой будет работать задающий генератор. Далее выбираем и заполняем вкладку USART в соответствии с нужными характеристиками (если нужен только приемник или только передатчик ставим соответствующую галочку).
| // USART initialization // Communication Parameters: // 8 Data, 1 Stop, Even Parity // USART Receiver: On // USART Transmitter: On // USART Mode: Asynchronous // USART Baud Rate: 9600 UCSRA= 0x00 ; UCSRB= 0x98 ; UCSRC= 0x26 ; UBRRH= 0x00 ; UBRRL= 0x33 ; |
// USART initialization // Communication Parameters: // 8 Data, 1 Stop, Even Parity // USART Receiver: On // USART Transmitter: On // USART Mode: Asynchronous // USART Baud Rate: 9600 UCSRA=0x00; UCSRB=0x98; UCSRC=0x26; UBRRH=0x00; UBRRL=0x33;
Сохраняем сгенерированный проект (File\Generate, Save and Exit ) — готово. Создан проект со всеми нужными установками для UART. В проекте инициализируется и другая периферия (зачастую не нужная). После создания проекта его можно подкорректировать – удалить все не нужное.
3 СОЗДАНИЕ ПРОЦЕДУР ОБРАБОТКИ СООБЩЕНИЙ UART.
Небольшое отступление.
Работу с UART можно организовать различными способами. Например:
— просто ожидать в теле программы когда придет сообщение, постоянно проверяя бит приема сообщения;
— разрешить прерывание и в теле прерывания обрабатывать сообщение;
— создать буфер куда по прерываниям будут загоняться сообщения, а уже в теле программы, «по свободе», считывать из буфера значения;
— еще куча вариантов – выбор за Вами.
Но , исходя из того, что сообщения от устройств, в большинстве своем, единичные (один байт) и не слишком часты (взять, к примеру, клавиатуру – пару нажатий в секунду, не больше), наилучшим вариантом, в плане экономии памяти и скорости обработки, будет обработка сообщения UART в теле прерывания. Под обработкой я понимаю чтение регистров, проверка на правильность приема и сохранение принятого байта в глобальной переменной (своего рода буфер в один байт). Если предполагаются несложные манипуляции с принятым байтом можно их тоже организовать в теле прерывания.В дальнейшем я буду ориентироваться на такой алгоритм работы, если другой не будет более оправданным.
Algorithm Builder.
Прием данных
осуществляется в процедуре обработки прерывания по окончании приема байта (кадра). Принятый байт записывается в глобальную переменную FromGCnDevice.
В теле программы проверяется значение FromGCnDevice ели оно нулевое ничего не принято.
Если работа с принятым значением несложна можно это сделать прямо в теле обработки прерывания.
Передача данных
производиться без использования прерываний и буфера (аппаратно у UART передатчика существует буфер на 2 байта). Это значит, что комфортно будут передаваться только единичные байты (что мы и планируем делать). Если зарядить сразу строку данных, то микроконтроллер будет заниматься только этой строкой.
Ассемблер.
Прием байта осуществляется в прерывании, результат остается в регистре r17 (если нужно сохраните в SRAM).
| ;Обработка прерывания по окончании приема байта PUSH R16 IN R16, SREG PUSH R16 IN R16, UCSRA ;Читаем статус из UCSRA IN R17, UDR ;Читаем данные из UDR ANDI R16, $ 1C BREQ _END ;Проверяем на ошибки CLR R17 _END: ;в R17 находится принятый байт POP R16 OUT SREG, R16 POP R16 RETI |
;Обработка прерывания по окончании приема байта PUSH R16 IN R16,SREG PUSH R16 IN R16,UCSRA ;Читаем статус из UCSRA IN R17,UDR ;Читаем данные из UDR ANDI R16,$1C BREQ _END ;Проверяем на ошибки CLR R17 _END: ;в R17 находится принятый байт POP R16 OUT SREG,R16 POP R16 RETI
Передача байта
LDI R16,значение SBIS UCSRA,UDRE RJMP PC-1 ; ждем готовности принять байт OUT UDR, R16 ; шлем байт
С — в программе CodeVisionAVR
.
Тут все просто CodeWizard вместе с инициализацией UART создает и процедуры для приема-передачи. Единственно что можно тут поковырять так это выкинуть буфер для приема (если разрешить прерывания по приему или передаче автоматически создается буфер). Если этот буфер не нужен процедура обработки прерывания приема байта и процедура передачи могут выглядеть так:
| // Глобальная переменная - полученные даные от устройства // Эсли FromGCnDevice==0 - ничего не получено char FromGCnDevice; // Обработка прерывания окончания приема байта interrupt [ USART_RXC] void usart_rx_isr(void ) { char status; // Получаем байт статуса и данных status= UCSRA; FromGCnDevice= UDR; // Если произошла ошибка при приеме байта то FromGCnDevice=0 if ((status & amp; (FRAMING_ERROR | PARITY_ERROR | DATA_OVERRUN) ) != 0 ) FromGCnDevice= 0 ; } // Процедура передачи байта void ToGCnDevice (char c) { // Ждем окончания передачи предідущего байта while ((UCSRA & amp; DATA_REGISTER_EMPTY) == 0 ) ; // Передаем байт UDR= c; } |
// Глобальная переменная - полученные даные от устройства // Эсли FromGCnDevice==0 - ничего не получено char FromGCnDevice; // Обработка прерывания окончания приема байта interrupt void usart_rx_isr(void) { char status; // Получаем байт статуса и данных status=UCSRA; FromGCnDevice=UDR; // Если произошла ошибка при приеме байта то FromGCnDevice=0 if ((status & (FRAMING_ERROR | PARITY_ERROR | DATA_OVERRUN))!=0)FromGCnDevice=0; } // Процедура передачи байта void ToGCnDevice (char c) { // Ждем окончания передачи предідущего байта while ((UCSRA & DATA_REGISTER_EMPTY)==0); // Передаем байт UDR=c; }
Во и все про UART. Этого должно хватить для того чтобы подключить устройство к Вашему проекту. По анологии приведенных примеров легко все можно проделать и для других микроконтроллеров АВР.
Ниже оставляю архивы программ с примерами работы UART для ATtiny2313.
- Пример проекта созданного автоматически CodeWisionsAVR
- Пример программы для работы с UART в Algorithm Builder
P.S. Я слабо знаю С и Asm, поэтому пинать и кидать тапками — разрешается! Мы все учимся.
Инициализируется
(Visited 10 796 times, 2 visits today)
Протокол передачи данных UART
Универсальный асинхронный приёмопередатчик
Предисловие
Современная цифровая электроника - это всегда соединения между цепями (процессорами, контроллерами и т.д.) для создания симбиотической системы. Для того, чтобы отдельные микросхемы могли бы "понимать" друг друга, они должны разделять некий общий протокол связи. За годы существования цифровой техники было разработано множество протоколов. В целом, их все можно разделить на две большие группы - параллельные и последовательные.
Параллельный или последовательный?
Параллельные интерфейсы передают одновременно (параллельно) несколько бит информации (отсюда, собственно и их название). Для передачи данных такие интерфейсы требуют наличия шин, состоящих из 8, 16 или более проводников.
Схема параллельного 8-разрядного интерфейса. Передача данных управляется тактирующим сигналом CLK. Байт данных передается по каждому импульсу CLK . Используется 10 проводов.
В противоположность параллельным, последовательные интерфейсы передают по одному биту за раз. Теоретически такой интерфейс может работать на одном единственном проводе. На практике используется до четырех.
Эти два интерфейса можно сравнить с потоком автомобилей. Параллельный интерфейс - это широкое шоссе с количеством полос движения более восьми, а последовательный интерфейс больше поход на двухполосную сельскую дорогу. Мега - Шоссе, потенциально, имеет бОльшую пропускную способность, но очень дорого с точки зрения строительства. Сельская дорога просто выполняет свою функцию и стоит во много раз дешевле многополосного мега-шоссе.
Вне всякого сомнения, параллельные интерфейсы имеют свои преимущества. Это прямота, быстрота, и легкость реализации. Но мы получаем это за счет большого количества проводов (линий) передачи данных. Если вам когда либо приходилось разрабатывать программы для микроконтроллеров (например в среде Ардуино), вы наверняка знаете, насколько драгоценными могут быть линии ввода/вывода. Поэтому мы часто останавливаем свой выбор именно на последовательной связи, жертвуя скоростью, но экономя драгоценные порты микроконтроллера.
Асинхронный последовательный интерфейс
За время существования цифровой техники были созданы десятки последовательных протоколов. USB (универсальная Последовательная Шина) и Ethernet - это пример двух наиболее популярных сейчас последовательных протоколов. Другие очень популярные последовательные интерфейсы - это SPI, I2C и последовательный интерфейс, о котором пойдет речь в этой статье. Каждый их этих интерфейсов можно отнести к одной из двух подгрупп - Асинхронные и Синхронные.
Синхронный протокол всегда включает линию тактового сигнала. Это обеспечивает более простую (и зачастую более быструю) передачу данных, но требует как минимум один дополнительный провод. Пример синхронных интерфейсов - это SPI и I2C.
Асинхронный интерфейс подразумевает, что данные передаются без поддержки внешнего тактового сигнала.Этот метод передачи идеально подходит для минимизации количества проводов, но это означает, но для надежной передачи и приема данных рнужно приложить дополнительные усилия. Последовательный интерфейс, который мы обсудим в этой статье, является наиболее распространенным и старым асинхронным и протоколом. Часто бывает так, что, когда человек говорит «последовательный», он имеет в виду именно этот протокол.
Асинхронный последовательный интерфейс, о котором здесь идет речь, широко используется во встраиваемых системах. Если вы хотите добавить в свой проект модуль GPS, Bluetooth, XBee, последовательные ЖК-дисплеи или многие другие внешние устройства, вам, вероятно, придется столкнуться с одним из последовательных интерфейсов.
Правила последовательного интерфейса.
Асинхронный последовательный протокол имеет ряд встроенных правил - механизмов, которые помогают обеспечить надежную и безошибочную передачу данных. Это те механизмы, которые позволяют передавать данные без использования внешнего тактового сигнала:
Биты данных
- Биты синхронизации
- Биты проверки четности
- Скорость передачи
Благодаря сочетанию этих правил - параметров, протокол очень гибкий. Для успешной связи нужно убедиться, что оба устройства на шине настроены на использование одинаковых правил.
Скорость передачи
Данный параметр определяет скорость передачи данных по последовательной линии. Обычно это выражается в единицах бит в секунду (бит / с или БОД). Если вы инвертируете этот параметр, выраженный в бодах, то получите время, которое требуется для передачи одного бита. Это значение определяет, как долго передатчик держит последовательную линию в высоком / низком состоянии или в какой период принимающее устройство производит выборку своей линии.
Скорость передачи может быть практически любой в пределах разумного. Единственное требование заключается в том, что оба устройства работали с одинаковой скоростью. Одна из наиболее распространенных скоростей передачи, особенно для простых применений, где скорость не критична, составляет 9600 бит / с. Другие «стандартные» скорости - 1200, 2400, 4800, 19200, 38400, 57600 и 115200.
Чем выше скорость передачи в бодах, тем быстрее осуществляется передача и прием данных. Но для максимальной скорости существуют физические ограничения. Обычно на практике вы не увидите скоростей, превышающих 115200. Для большинства микроконтроллеров это максимальная скорость. Если выбрать слишком высокую скорость, то неизбежно появятся ошибки на
принимающей стороне.
Кадры данных
Каждый блок данных (обычно это байт) фактически отправляется в пакете или кадре битов. Кадры создаются путем добавления бит синхронизации и бит четности к битам данным.
Давайте рассмотрим каждую часть кадра более подробно
Блок Данных (Data chunk)
Самая важная часть каждого пакета - это блок данных, так как именно этот блок несет полезную информацию. Мы намеренно называем этот блок "куском" данных (chunk), поскольку его размер конкретно не указан. Количество данных в каждом пакете может быть установлено любым - от 5 до 9 бит. Разумеется, стандартный размер данных - это наш с вами основной 8-разрядный байт, но другие его размеры также в ходу. 7-битный блок данных может быть более эффективным, чем 8-битный, особенно если вы просто переносите 7-битные символы ASCII (текст).
После согласования длины символа оба устройства на последовательной шине также должны согласовать достоверность своих данных. Являются ли данные наиболее старшим битом (msb) наименьшим, или наоборот? Если не указано иное, обычно мы предполагаем, что сначала передается младший бит (lsb)
Биты синхронизации
Биты синхронизации представляют собой два или три специальных бита, передаваемых с каждым фрагментом данных. Это стартовый и стоповый биты. Эти биты отмечают начало и конец пакета. Всегда есть только один стартовый бит, но количество стоповых бит настраивается отдельно. Может быть один или два стоп-бита (чаще всего используется один).
Старт-бит всегда определяется линией данных по его спаду (переходу от 1 в 0), в то время как стоп биты определяются линией по фронту, то есть по переходу из 0 в 1.
Биты четности
Четность - это форма очень простой, низкоуровневой проверки ошибок. Может быть два варианта такой проверки: нечетный или четный. Чтобы создать бит четности, все 5-9 бит блока данных складываются, а четность суммы определяет, установлен бит четности или нет. Например, представим себе что у нас проверка установлена в режим четности. Байт данных в двоичном представлении равен 01011101. Видим, что в байте нечетное количество единиц (пять единиц). В этом случае бит проверки четности будет установлен в 1. Если мы настроим режим проверки на на нечетность, то соответственно, бит проверки будет установлен в 0.
Пример настройки протокола: 9600 8N1
9600 8N1 - 9600 бод, 8 бит данных, без контроля четности и 1 стоповый бит - это одна из наиболее часто используемых настроек последовательного протокола. Итак, как выглядит пакет или два из 9600 8N1 данных? Приведем пример:
Фактически для каждого байта передаваемых данных отправляются 10 бит: начальный бит, 8 бит данных и стоповый бит. Таким образом, при 9600 бит / с мы фактически отправляем 9600 бит в секунду или 960 (9600/10) байтов в секунду.
Теперь, когда вы знаете, как создавать последовательные пакеты, мы можем перейти к разделу аппаратного обеспечения.
Мы увидим, как всё это будет реализовано на уровне сигнала.
Последовательная шина состоит всего из двух проводов: один для отправки данных и другой - для приема. Таким образом, последовательные устройства должны иметь два последовательных контакта: приемник, (RX ) и передатчик (TX ).
Важно понимать, что обозначения RX и TX относятся к самому устройству. Поэтому RX
одного устройства должен соединяться с TX
другого, и наоборот. Это может показаться странным, если вы привыкли подключать сигналы VCC к VCC, GND к GND, MOSI в MOSI и т.д. Но все-таки это имеет смысл, поскольку передатчик (TX
) должен разговаривать с приемником (RX)
, а не с другим передатчиком.
Последовательный интерфейс, в котором оба устройства могут отправлять и принимать данные, называется дуплексным или полудуплексным . Дуплексный означает, что оба устройства могут отправлять и принимать одновременно. Полудуплексная связь означает, что последовательные устройства должны по очереди отправлять и принимать данные.
Некоторые последовательные шины могут функционировать с помощью всего лишь одного провода между отправляющим и принимающим устройством. Например, ЖК-дисплеи с последовательным включением на самом деле не передают никаких данных обратно в управляющее устройство. Это называется симплексная последовательная связь. Все, что вам нужно - это один провод TX ведущего устройства к контакту RX управляемого.
Реализация в железе
Итак, мы с вами рассмотрели асинхронный последовательный протокол с концептуальной стороны. Мы знаем, какие провода нам нужны. Но как осуществляется последовательная связь на уровне сигнала? На самом деле, по-разному. Существуют всевозможные стандарты. Давайте рассмотрим пару наиболее популярных аппаратных реализаций последовательного интерфейса: логического уровня (TTL) и RS-232.
Когда микроконтроллеры и другие низкоуровневые ИС взаимодействуют между собой по последовательному протоколу, они обычно делают это на уровне TTL (транзисторно- транзисторная логика). Последовательные сигналы TTL живут между диапазоном напряжения питания микроконтроллера - обычно от 0 до 3,3 В или 5 В. Сигнал на уровне VCC (3,3 В, 5 В и т. д.) указывает либо о простое, либо это - бит 1 данных, либо стоп-бит. Сигнал 0 В (GND) представляет собой либо стартовый бит, либо бит данных значения 0.
Интерфейс , который можно найти на некоторых более старых компьютерах и периферийных устройствах, похож на обычный последовательный TTL. У них просто разные уровни напряжения. Обычно сигналы RS-232 варьируются от -13 В до +13В, хотя спецификация позволяет все что угодно в диапазоне от +/- 3 В до +/- 25 В. Низкое напряжение (-5 В, -13 В и т. д.) указывает либо холостой ход, либо стоп-бит, либо бит данных значения 1. Высокий сигнал RS-232 означает либо стартовый бит, либо 0-бит данных. В полярности сигналов как раз кроется противоположность последовательному TTL.
Во встроенных схемах (внутри одного устройства) намного проще использовать последовательные сигналы формата TTL. Но в случае с длинными линиями передачи данных низкие уровни TTL намного более восприимчивы к потерям и помехам. RS-232 или более сложные стандарты, такие как RS-485, лучше подходят для последовательных передач на большие расстояния.
Когда вы соединяете два последовательных устройства вместе, важно убедиться, что их сигнальные напряжения совпадают. Вы не можете напрямую соединять последовательное устройство TTL с шиной RS-232. Вам придется конвертировать их уровни для взаимной совместимости.
UART
Универсальный асинхронный приемник / передатчик (UART) представляет собой блок схем, ответственный за реализацию последовательной связи. По сути, UART выступает в качестве посредника между параллельными и последовательными интерфейсами. На одном конце UART есть шина из восьми (или около того) линий данных (плюс некоторые управляющие контакты), с другой - два последовательных провода - RX и TX.
Интерфейсы UART существуют в виде отдельных микросхем, но чаще всего они встроены в микроконтроллеры. Чтобы узнать, есть ли у вашего МК протокол UART, вам придется почитать даташит на этот контроллер. У некоторых нет ни одного, у некоторых есть, у некоторых их несколько. Например, Arduino Uno, основанный на старом добром ATmega328, имеет только один UART, в то время как Arduino Mega - построенный на ATmega2560 - имеет целых четыре UART.
R и T в терминологии UART несут ответственность за отправку и получение последовательных данных. На стороне передачи UART должен создать пакет данных - добавление битов синхронизации и четности - и отправить этот пакет по линии TX в соответствии с установленной скоростью передачи. На стороне приема UART должен проверять линию RX со скоростью, соответствующей ожидаемой скорости передачи в бодах, выбирать биты синхронизации и выделять данные.
Есть одна замечательная микросхемка — FT2232D. Это конвертер USB-UARTx2. Удобно когда надо получить два UART хвоста из одного USB провода. Но это семечки по сравнению с тем, что в эту микруху FTDI внедрили мощную аппаратную поддержку MPSSE (Multi-Protocol Synchronous Serial Engine), что позволяет на одной только этой микрухе реализовать кучу разных интерфейсов вроде SPI или JTAG.
Что дает просто широчайший простор под построение разнокалиберных программаторов под все что угодно. На данный момент я видел схемы для прошивки AVR, ARM, Altera и бог еще весть чего.
Теоретически, с ее помощью можно прошить что угодно, была бы программная поддержка и открытый и задокументированный протокол.
Поэтому, под такую няшечку, я не обломался и сделал универсальную платку, которая в последствии, путем навеса мезонинных платок будет превращаться в разные прошивальщики и отладчики.
Готовую программу надо каким-либо образом запихать в контроллер. Для этого существует множество способов.
JTAG/SWD адаптер
Так как часто для отладки под ARM используется JTAG, то этот метод получается наверное самым популярным. Для этой цели используется какой-либо адаптер. Например я использую так что показывать буду на его примере. Там все просто — подключаешь адаптер к контроллеру стандартным SWD или JTAG шлейфом. Через линии NRST/TDI/TDO/TCK/TMS для JTAG или через SWO/SWOCLK/SWDIO/NRST для SWD режима. На адаптере моей верси CoLinkEX оба эти разьема выведены на одну колодку, так что получается как бы сразу и JTAG и SWD соединение. А там какое надо такое и выбираешь. Особой разницы в отладке/прошивке между ними нет.
Либо используя утилитку CoFlash oт CooCox.com
Одним из серьезных достоинств контроллеров AVR является дикое количество прерываний. Фактически, каждое периферийное устройство имеет по вектору, а то и не по одному. Так что на прерываних можно замутить кучу параллельных процессов. Работа на прерываниях является одним из способов сделать псевдо многозадачную среду.
Идеально для передачи данных и обработки длительных процессов.
Для примера покажу буфферизированный вывод данных по USART на прерываниях.
В прошлых примерах был такой код:
// Отправка строки
void SendStr(char *string)
{
while (*string!="\0")
{
SendByte(*string);
string++;
}
}
// Отправка одного символа
void SendByte(char byte)
{
while(!(UCSRA & (1< Данный метод, очевидно, совершенно неэффективен. Дело в том, что у нас тут есть тупейшее ожидание события — поднятие флага готовности USART. А это зависит, в первую очередь, от скорости передачи данных. Например, на скорости 600 бод передача каких то 600 знаков будет длиться 9 секунд, блокируя работу всей программы, что ни в какие ворота не лезет. Как то раз мне потребовалось устройство способное соединяться с удаленным сервером и пересылать байты. Конечно, для этих целей можно использовать компьютер, но это громоздко и неудобно, да и надежность такой системы оставляет желать лучшего — слишком сложное устройство. Другое дело микроконтроллер, например Microchip PIC, MSC-51 или Atmel AVR — простой, надежный, потребляет минимум энергии и способен надежно выполнить узкий круг поставленных задач. Например, мониторинг сигнализации через Internet или Ethernet сеть. Всё бы хорошо, но тут появляется очередная проблема — протокол TCP/IP. Реализовать на AVR или PIC стек протоколов TCP/IP задача выполнимая, но требует времени, а время, как известно, деньги. Надо было срочно и с минимальным геморроем. И вот тут мне на помощь пришел интерфейсный модуль Ethernet — RS232. Прикупил я себе парочку модулей HM-TR433
. Так, помучить. Стоит такая радость на данный момент порядка 800рублей. Это трансивер, то есть он может как принимать, так и передавать. Мало того, тут стоит управляющий контроллер, который сам кодирует информацию, загоняет ее в радио канал и декодирует пойманное. То есть, по сути, мы получаем удлинитель UART и всякие проблемы вроде шума после пропадания несущей, какие были в связке HM-T433/HM-R433
нас уже не волнуют. Один минус — канал полудуплексный, то есть синхронный прием и передача невозможны, только по очереди. Но это не велика проблема — зачастую полудуплекса хватает за глаза. Существует две модификации этого модуля. Одна имеет окончание TTL другая RS232. Разница лишь в уровнях и в том, что в первую китайцы забыли впаять MAX232 и обвязку из конденсаторов, зато поставили перемычки. Так что имея прямые руки и нужный инструмент можно из TTL сделать RS232 и наоборот. Впрочем, по цене они копейка в копейку идут. Такс, в порядке работы над коммерческим проектом (и не спрашивайте о каком — не скажу), который сожрал все мое свободное время огромной зазубренной ложкой, раскурил до самого пепла радиомодули HopeRF HM-R433/HM-T433
. Сегодня собрал полудуплексную схему на четырех модулях и провел сеанс дальнобойной приемо-передачи.
Итак, что из себя представляла установка:
Блок А:
Блок Б:
Условие передачи:
При первоначальных испытаниях сея железка показала себя с лучшей стороны, но вот на практике вылезли не просто баги, а прям гигантские тараканы убийцы. Казалось бы, чему там работать не так? А, как оказалось, есть чему. Точнее это не баги, а особенности, о которых производитель самым подлым образом умолчал в даташитах. Знай я о них я бы еще подумал стоит ли их покупать. Итак:
Несущая Ждущий режим
Совместная работа
Баги при передаче
В числе прочих ништячков, помимо ультразвукового дальномера мне в посылке из Терры пришли еще и радиомодули. Hope HM-T433
и Hope HM-R433
На передачу и на прием, соответственно. Сам модуль представляет из себя крошечную платку 15х25 мм
с торчащим из нее разъемом. У передатчика разъем трехконтактный — GND, DATA и Vcc
у приемника есть еще вход ENABLE
при подаче на который высокого уровня разрешается прием. Возникла у меня необходимость забабахать себе девайсину, чтобы можно было с его помощью раздавать байты по i 2 c
и UART
, а также принимать байты по этим же протоколам и выдавать на экранчик. Как по одному, так и пачками. Этакий дебаггер.
Ну а чо, сказано сделано. Воткнул ATMega8535
— первая которая под руку подвернулась из многоногих. Вывел все что только можно наружу, присобачил небольшую клавиатурную матрицу 4х4 и LCD экранчик
. Экранчик мелкий WH0802A
8х2 символа, но уж какой был. Других у нас в продаже не встречал, а под заказ везти лень. Да и, думаю, там и не надо больше. А раз уж пошла такая пьянка, то до кучи вывел наружу пару каналов ШИМ
, да пару входов АЦП
. Ну и SPI
заодно — гулять так гулять. Там же можно и Dallas
1-wire
проткол организовать, приделать частотомер, индикатор сигнала, вольтмер и вообще можно много чего наворотить, было бы желание. Опять же, линий на вход/выход получается дофига, так что из нее можно сделать головной блок умного дома или контроллер чего нибудь. Корпус взял халявный, PAC-TEC
‘овский который намутил года два назад. Вот и пригодится коробочка:) Надо сказать, PAC-TEC
делает просто изумительные коробки. Не чета тому говну, что продается в наших радиомагазинах. Не скрипят, не люфтят, крепко сбиты, ладно скроены и выглядят круто. Где бы их еще продавали у нас. Пока только плату развел, еще некоторых деталей не хватает. На днях вытравлю плату, соберу и буду программировать. Вот тогда будет вам и примеры живого кода и подробное описание SPI
, i2c, UART,
клавиатура и LCD
. Кстати, обратите внимание как легко матрицировать обычные тактовые кнопки. А все благодаря тому, что у них четыре попарно соединенных вывода. Пока же, раз все еще в виде чертежа, набрасывайте в комменты свои идеи по поводу фич будущего девайса. Пока писал статью про UART пришла в голову одна извращенная идея — на базе UART же можно организовать самый натуральный низкодискретный ШИМ!
Достаточно только сделать где-нибудь в памяти переменную, куда мы будем совать число с заданной скважностью нулей и единиц, а по прерыванию опустошения буфера это число снова пихать в регистр UDRE. Таким образом, генерация ШИМ будет самопроизвольной, без лишних телодвижений. Правда можно получить всего 10 разных значений ШИМ, но зато нахаляву!!! Для тех кто не понял как, приведу числа которые надо будет непрерывно слать через UART: 00000000 — 1/10 Да и частоты там можно получить нефиговые! Почти каждый микроконтроллер имеет на борту универсальный последовательный интерфейс — UART
. AVR
тут не исключение и поддерживает этот протокол в полном обьеме полностью аппаратно. По структуре это обычный асинхронный
последовательный протокол, то есть передающая сторона по очереди выдает в линию 0 и 1, а принимающая отслеживает их и запоминает. Синхронизация идет по времени — приемник и передатчик заранее договариваются о том на какой частоте будет идти обмен. Это очень важный момент! Если скорость передатчика и приемника не будут совпадать, то передачи может не быть вообще, либо будут считаны не те данные. Протокол
В конце байта, перед стоп битом, может быть и бит четности. Который получается если поксорить между собой все биты, для контроля качества передачи. Также может быть два стопа, опять же для надежности. Битов может быть не 8, а 9. О всех этих параметрах договариваются на берегу, до начала передачи. Самым же популярным является 8 бит, один старт один стоп, без четности. Причем с самим протоколом можно не заморачиваться — все реализовано аппаратно. Разве что захочется завести второй UART, тогда придется делать его программно. По такому же протоколу работает COM порт компьютера, разница лишь в разнице напряжений, поэтому именно этот протокол я буду использовать для связи микроконтроллера с компом. Для преобразования напряжений можно использовать RS232-TTL конвертер.
COM
порт. Но есть тут одна проблема — дело в том, что комповый RS232
он за логические уровни принимает +/- 12
вольт, а UART
работает на пятивольтовых уровнях. Как их совместить? Для этого существует несоколько вариантов схем преобразователей уровня, но самая популярная это все же на специальном преобразователе RS232-TTL
. Это микросхема MAX232
и ее аналоги. Кстати, существует еще и MAX3232
это то же самое, но на выходе у него не 5вольт TTL, а 3.3 вольта TTL. Её используют для низковольтных контроллеров. Я себе сделал один такой универсальный шнурочек, чтобы к контроллерам цепляться было удобно по UART
. Для общей компактности всю схему запихал прям в разъем, благо у меня были ST232
в soic корпусе. Получилась платка не больше рублевой монеты. Так как под рукой не было мелких SMD конденсаторов, то пришлось напаять кондеры сверху, кто во что горазд. Главное работает, хоть и не очень красиво вышло. Если сомневаешься, что у тебя получится столь мелкий монтаж, то я тебе развел плату на стандартный PDIP корпус. Размером она будет со спичечный коробок, зато мельчить не надо. После сборки проверяется просто:
Дальше открваешь любую терминалку, хоть Hyper Terminal
, цепляешься к порту и начинаешь посылать байты, они должны тотчас возвращаться обратно. Если этого не произошло — проверяй схему, где то косяк. Если работает, то дальше все просто. Тот провод который идет от ножки 9 микросхемы MAX232
это передающий вывод
, его заводи на ногу RxD
контроллера. А тот который с ножки 10 — принимающий
, его смело сажай на вывод TxD
контроллера. Плата сделана была методом ЛУТ , в одном месте по моему недосмотру толщина просвета оказалась 0.05мм, протравилась, но со спайками, пришлось процарапывать. А в целом с первого раза ать и никаких проблем. Аж сразу захотелось сделать что нибудь маленькое маленькое, нафаршированное нафаршированное:) Universal Asynchronous Receiver-Transmitter, UART
— узел вычислительных устройств, предназначенный для организации связи с другими цифровыми устройствами. Преобразует передаваемые данные в последовательный вид так, чтобы было возможно передать их по цифровой линии другому аналогичному устройству. Метод преобразования хорошо стандартизован и широко применялся в компьютерной технике. Представляет собой логическую схему, с одной стороны подключённую к шине вычислительного устройства, а с другой имеющую два или более выводов для внешнего соединения. UART может представлять собой отдельную микросхему или являться частью большой интегральной схемы (например, микроконтроллера). Используется для передачи данных через последовательный порт компьютера , часто встраивается в микроконтроллеры . serial port
, COM-порт
, communications port
) — сленговое название интерфейса стандарта RS-232 , которым массово оснащались персональные компьютеры . Порт называется «последовательным», так как информация через него передаётся по одному биту , последовательно бит за битом (в отличие от параллельного порта). Несмотря на то, что некоторые интерфейсы компьютера (например, Ethernet , FireWire и USB) тоже используют последовательный способ обмена информацией, название «последовательный порт» закрепилось за портом стандарта RS-232 . В настоящее время в IBM PC-совместимых компьютерах практически вытеснен интерфейсом USB . Существуют стандарты на эмуляцию последовательного порта над USB и над Bluetooth (эта технология в значительной степени и проектировалась как «беспроводной последовательный порт»). Передача данных в UART осуществляется по одному биту в равные промежутки времени. Этот временной промежуток определяется заданной скоростью UART
и для конкретного соединения указывается в бодах (что в данном случае соответствует битам в секунду). Существует общепринятый ряд стандартных скоростей: 300; 600; 1200; 2400; 4800; 9600; 19200; 38400; 57600; 115200; 230400; 460800; 921600 бод. Скорость в бодах иногда называют
сленговым
словом битрейт
.
Помимо собственно информационного потока, UART автоматически вставляет в поток синхронизирующие метки, так называемые стартовый и стоповый биты
. При приёме эти лишние биты удаляются из потока. Обычно стартовый и стоповый биты обрамляют один байт информации (8 бит), однако встречаются реализации UART, которые позволяют передавать по 5, 6, 7, 8 или 9 бит. Обрамленные стартом и стопом биты являются минимальной посылкой. Некоторые реализации UART позволяют вставлять два стоповых бита при передаче для уменьшения вероятности рассинхронизации приёмника и передатчика при плотном трафике. Приёмник игнорирует второй стоповый бит, воспринимая его как короткую паузу на линии. Принято соглашение, что пассивным (в отсутствие потока данных) состоянием входа и выхода UART является логическая 1.
Стартовый бит всегда логический 0,
поэтому приёмник UART ждёт перепада из 1 в 0 и отсчитывает от него временной промежуток в половину длительности бита (середина передачи стартового бита). Если в этот момент на входе всё ещё 0, то запускается процесс приёма минимальной посылки. Для этого приёмник отсчитывает 9 битовых длительностей подряд (для 8-битных данных) и в каждый момент фиксирует состояние входа. Первые 8 значений являются принятыми данными, последнее значение проверочное (стоп-бит). Значение стоп-бита всегда 1
, если реально принятое значение иное, UART фиксирует ошибку. Для формирования временных интервалов передающий и приёмный UART имеют источник точного времени
(тактирования). Точность этого источника должна быть такой, чтобы сумма погрешностей (приёмника и передатчика) установки временного интервала от начала стартового импульса до середины стопового импульса не превышала половины (а лучше хотя бы четверти) битового интервала. Для 8-битной посылки 0,5/9,5 = 5 % (в реальности не более 3 %). Поскольку эта сумма ошибок приёмника и передатчика плюс возможные искажения сигнала в линии, то рекомендуемый допуск на точность тактирования UART — не более 1,5 %. Поскольку синхронизирующие биты занимают часть битового потока, то результирующая пропускная способность
UART не равна скорости соединения. Например, для 8-битных посылок формата 8-N-1 синхронизирующие биты занимают 20 % потока, что для физической скорости 115 200 бод даёт битовую скорость данных 92 160 бит/с или 11 520 байт/с. Многие реализации UART имеют возможность автоматически контролировать целостность данных методом контроля битовой чётности. Когда эта функция включена, последний бит данных в минимальной посылке («бит чётности») контролируется логикой UART и содержит информацию о чётности количества единичных бит в этой минимальной посылке. Различают контроль на четность (англ. Even parity
), когда сумма количества единичных бит в посылке является четным числом , и контроль на нечетность (англ. Odd parity
), когда эта сумма нечетна. При приеме такой посылки UART может автоматически контролировать бит четности и выставлять соответствующие признаки правильного или ошибочного приема. Был выработан и прижился короткий способ записи параметров UART, таких, как количество бит данных - наличие и тип бита четности - количество стоп-бит
. Выглядит как запись вида цифра-буква-цифра
, где: N
(No parity) — без бита четности; E
(Even parity) — с битом проверки на четность, O
(Odd parity) — с битом проверки на нечетность; Встречаются значения 1, 1.5 и 2 для длительности стоп-бита в 1, 1.5 и 2 битовых интервала соответственно. Например, запись 8-N-1 обозначает, что UART настроен на 8 бит данных без бита четности и один стоповый бит. Для полноты параметров эту запись снабжают указанием.
Специальная посылка -
состоит из непрерывного нулевого состояния линии длительностью заведомо больше минимальной посылки, обычно 1,5 минимальных посылки (для 8N1 это 15 битовых интервалов). Некоторые коммуникационные протоколы используют это свойство, например, протокол LIN использует Break для обозначения нового кадра.
Ранние устройства с UART могли быть настолько медлительными, что не успевали обрабатывать поток принимаемых данных. Для решения этой проблемы модули UART иногда снабжались отдельными выходами и входами управления потоком. При заполнении входного буфера логика принимающего UART выставляла на соответствующем выходе запрещающий уровень, и передающий UART приостанавливал передачу. Позже управление потоком возложили на коммуникационные протоколы (например, методом XOn/XOff), и надобность в отдельных линиях управления потоком постепенно исчезла. Логическая схема UART имеет входы-выходы с логическими уровнями, соответствующими полупроводниковой технологии схемы: КМОП , ТТЛ и т. д. Такой физический уровень может быть использован в пределах одного устройства, однако непригоден для коммутируемых длинных соединений по причине низкой защищённости от электрического разрушения и помехоустойчивости. UART микроконтроллеров AVR.
Одним из самых распространенных протоколов взаимодействия микроконтроллера с внешними устройствами является UART
(Universal Asynchronous Receiver-Transmitter
) - Универсальный асинхронный приёмопередатчик
. Данный протокол аппаратно реализован в большинстве микроконтроллеров AVR
, что позволяет разработчику не вдаваться в особенности реализации данного интерфейса. Для его использования достаточно настроить всего несколько регистров! Рассмотрим кратко принцип работы UART
.
Данный протокол является последовательным, то есть данные идут строго друг за другом, что в некоторой мере ограничивает скорость работы. Так как протокол является асинхронным, приемник и передатчик должны работать строго на одной частоте, которую необходимо настроить ещё до начала работы. При передаче байта передатчик изначально выставляет логический 0 на выводе TX
(Transmitter
). Это так называемый старт-бит, означающий начало передачи. После этого передатчик выставляет биты передаваемого байта через определенные промежутки времени, заданные частотой. Далее может быть передан бит четности, который служит для проверки качества передачи. Когда переданы все биты, выставляется стоп-бит, то есть логическая 1 на линии передачи. Число стоп-битов может быть различным:1
;
1
,
5
;
2.
Огромным плюсом данного интерфейса является возможность его использования для настройки связи с ПК. Для этого необходимо изготовить UART
—RS
232 или UART
—USB
переходники, основанные на микросхемах MAX
232 и FT
232RL
соответственно. Подробнее о переходниках здесь.
За работу с UART
(на самом деле USART
, о
днако, для нас это сейчас не важно) отвечают следующие регистры:
UDR
- Регистр данных
UART
. При передаче в него записываются данные, которые необходимо отправить, а при чтении — принятые данные. Всё просто.
UCSRA
- Регистр контроля и статуса
UART
.
Рассмотрим биты данного регистра подробнее: UCSRB
-
Регистр контроля и статуса
UART
.
UCSR
С
-
Регистр контроля и статуса
UART
.
Регистры UBRRL
и UBRRH
отвечают за настройку скорости работы приемопередатчика. Следует помнить, что при работе с регистром UBRRH
бит URSEL
должен быть равен 0. Для получения необходимой скорости работы UART
значение UBRR
(Пары регистров UBRRH
и UBRRL
) рассчитывается по следующей формуле: UBRR = (F
osc
/(B*16))-1
Где,
F
osc
- частота работы микроконтроллера (Гц). B
- необходимая скорость работы UART
(Бит/сек). Например, необходимо настроить скорость передачи 9600 бит/ сек при работе микроконтроллера на частоте 8 МГЦ(8000000 Гц). UBRR
= (8000000/(9600*16))-1 = 51.083333 Округляем до целого числа, то есть до 51.И уже данное число записываем в регистры UBRRL:UBRRH. Урок получился достаточно объемным, поэтому практическую реализацию протокола UART
на микроконтроллерах AVR
рассмотрим в следующем уроке. Любое копирование, воспроизведение, цитирование материала, или его частей разрешено только с письменного согласия администрации MKPROG
.RU
. Незаконное копирование, цитирование, воспроизведение преследуется по закону!
Задача стандартная, поэтому предложений на рынке готовых модулей предостаточно, однако не стоит торопиться. Тут есть ряд тонкостей, связанных с особенностями работы данных устройств. Например, подавляющее большинство модулей может работать исключительно в роли сервера, которому требуется выделенный IP адрес. Устройство-клиент работает только с специализированным софтом, как правило под Windows, и открывает виртуальный COM порт который соединяется с удаленной системой (UART — Ethernet модуль) и обеспечивает обмен данными. Не самый удобный вариант. Для моей задачи данная конструкция была совершенно непригодна. Поэтому я начал искать дальше, вскоре был обнаружен замечательный модуль EG-SR-7100
, а потом и его более новая модификация WIZ100SR
. Почитал характеристики — оно! Все для решения моей задачи! 
Блок Б дает десятибайтный пакет блоку А, тот, убедившись, что пакет принят без искажений, шлет подтверждение обратно на блок Б, те же десять байт. Блок Б, получив подтверждение зажигает зеленый диод. Передача идет с обрывом несущей. Т.е. после отправки пакета передатчик вырубается полностью.
Приемник ловит изменение несущей, которую генерирует передатчик. А если не будет передатчика, что будет ловить приемник? По идее не должен ловить ничего, а что на практике? А на практике дикий срач!!! Натурально белый шум по всему диапазону от 0 до 255. Фигасе бага, да? Но ладно, хрен с этим белым шумом, его, в конце концов, можно фильтровать, отслеживать в нем наличие чего либо разумного и лишь после начинать прием.
У передатчика, к моему, а также ряда внимательных читателей, удивлению нет входа Enable.
У приемника то есть. Редкостный бред, особенно ввиду того, что спустя 70mS простоя на линии DATA передатчик впадает в спячку
и… правильно, отрубает несущую — на выходе приемника начинается в этот момент жуткий срач. Так что либо шли данные непрерывным потоком, либо перед каждой посылкой шли идентификационный пакет. А еще не забыв предупредить приемник о том, что передача закончена и дальше ловить нечего.
Тут все просто, два передатчика одновременно работать не могут. От слова совсем. Либо по отдельности, либо никак. Это было ожидаемо и это надо учитывать.
Но что меня больше всего добило, так это баги. Если с первые три пункта можно учитывать и обрабатывать программно без лишних заморочек, то со последним уже все гораздо веселей.
два дополнительных значения мы получим за счет старт и стоп битов.
00000001 — 2/10
00000011 — 3/10
00000111 — 4/10
00001111 — 5/10
00011111 — 6/10
00111111 — 7/10
01111111 — 8/10
11111111 — 9/10
Красота!=)))))
Вначале передатчик бросает линию в низкий уровень — это старт бит
. Почуяв что линия просела, приемник выжидает интервал Т1 и считывает первый бит, потом через интервалы Т2 выковыриваются остальные биты. Последний бит это стоп бит
. Говорящий о том, что передача этого байта завершена. Это в самом простом случае.
Практически каждая фирма делает свой преобразователь, так что тут сгодится и ST232
, и ADM232
, и HIN232
. Схемка простая как три копейки — вход, выход, питание и обвязка из пяти конденсаторов. Конденсаторы обычно ставятся 1uF
электролиты, но в некоторых модификациях ставится 0.1uF
керамика. Я везде впаивал 0.1uF
керамику и обычно этого хватало. :) Работает как часы. Если же на высоких скоростях будет глючить, то надо будет повышать емкость.
Втыкается в разъем COM
порта. Подается 5 вольт питания на схему, а затем замыкаешь Rx
на Tx
(у меня это зеленый и желтый провода). 
Последовательный порт
Метод передачи и приёма
Скорость (, бод) и длительность бита (, секунд) связаны соотношением
Контроль чётности
Основная статья:
Бит чётности
Короткая запись параметров
Break
Управление потоком
Физический уровень
