Приветствую, уважаемые посетители сайта www.pikabu.ru. Продолжаю статью о том, как написать приёмник UART на ПЛИС. Напоминаю, что в прошлом посте я постарался вас познакомить с самыми основами этого протокола, и попытался максимально подробно описать алгоритм работы приёмника, который мы будет создавать в ПЛИС.

http://pikabu.ru/story/prostenkie_primeryi_na_plis_uart_chas...

В данном посте я покажу, как всё, что я рассказывал в прошлом посте, описать на языке VHDL, протестировать и разместить в ПЛИС. Поскольку ответа на мой вопрос о том, в каком виде вы хотели бы видеть, выкладываемый код, от вас не поступило – то я буду код выкладывать в виде изображений, как и планировал изначально. Других вариантов я не вижу. Нужны исходники – пишите. Мне лень заморачиваться с файловыми хранилищами.

Внимание! Всё, что мною написано - это бред сумасшедшего это мои личные умозаключения, основанные на собственном опыте, на информации из различных источников, достоверность которых весьма спорная. Поэтому я не несу никакой ответственности за возможный вред, нанесенный вашей тонкой душевной организации, трату вашего бесценного времени. Поэтому пока не поздно закройте этот пост. А потом хорошо промойте глаза, желательно с мылом.

Внимание! Достаточно большое количество разработчиков на FPGA предпочитают язык Verilog/SystemVerilog. Я же предпочитаю язык VHDL, на котором буду выкладывать все тексты схем. Поскольку, я не ставлю своей целью научить вас писать именно на VHDL, поэтому я не буду объяснять, почему у меня написано именно так, а не иначе. Если вы все же начнете изучать язык VHDL, то поймете тесты схем. Если же не поймете, то всегда можете задать вопрос мне, я всегда объясню. А начнете изучать Verilog – то все мои объяснения вам будут нафиг не нужны. Для удобства восприятия текста я убрал все «фишки», которые делают модули настраиваемыми. Некоторые вещи у меня описаны не самым рациональным способом. Связанно это с тем, что мне просто так удобнее работать с текстом. Так же для удобства восприятия текста я оставил максимально подробные комментарии. И так приступим

Прошлый пост закончился на том, что я описал, какие функциональные элементы нам необходимы для реализации нашего приёмника, а именно:

1. Синхронизатор с клоковым доменом

2. Счетчик, считающий от 0 до 15, для того, чтобы можно было определять длительность периода старт бита, стоп бита, битов данных.

3. Счётчик от 0 до 7, считающий, сколько бит приняли.

4. 3 разрядный регистр, для хранения 3 выборок в середине битового интерала, чтобы провести голосование.

5. Мажоритарный фильтр.

6. 8 разрядный регистр для хранения принимаемых бит данных.

7. Цифровой автомат, управляющий работой всех элементов.

СИНХРОНИЗАТОР

Для начала опишем модуль, или как правильно говорить на языке VHDL – компонент, который мы будем применять для того, чтобы синхронизировать входной асинхронный сигнал с частотой нашего клокового домена. Напомню что базовый синхронизатор- это обычный сдвиговый регистр. Я всегда выделяю его в отдельный модуль. Мне так проще работать. Вот его описание на языке VHDL:

Давайте посмотрим, как наш синхронизатор выглядит на технологической карте. Технологическая карта показывает как наша схема «ложится» в логические ячейки, которых в ПЛИС очень много. Собственно будут задействованы 3 триггера из логических ячеек, которые соединены между собой вот таким вот образом:

Как видите это то, что нам необходимо.

Давайте теперь взглянем на временные диаграммы его работы – времянки. Моделирование я провожу в программе Modelsim altera SE и применяю функциональное моделирование, по этой причине на диаграммах отсутствуют временные задержки сигналов.

Вот временные диаграммы функционирования нашего синхронизатора:

Как видите, ничего сложного нет. Приходит асинхронный сигнал ADATA. Передним фронтом частоты CLK он защелкивается в младший разряд регистра SHIFT_REG(0). Следующим фронтом в младший разряд регистра SHIFT_REG(0) защелкивается лог. 0, поскольку на линии ADATA у нас лог.0, а единичка, которая была записана ранее, передается в следующий разряд. Т.е SHIFT_REG(1). Данные как бы сдвигаются от младшего разряда к старшему разряду. Поэтому регистр и называется сдвиговым. Ваш КЭП. Красные линии означают, что в эти моменты времени состояния этих сигналов имеют неопределённость, или правильнее говорить в данный момент времени сигналы неинициализированны. Например, сразу после включения непонятно что храниться в регистре.

РЕГИСТР ХРАНЕНИЯ ВЫБОРОК

А теперь давайте опишем наш 3 разрядный регистр хранения выборок, которые будут оцениваться мажоритарным фильтром. Вот текст нашего регистра на VHDL:

Если обратите внимание, то вы увидите что это такой же сдвиговый регистр как и наш синхронизатор. Только выходом этого модуля является не старший разряд, а все разряды регистра. Вот во что он синтезируется:

Я думаю, что его времянки объяснять не надо:

РЕГИСТР ХРАНЕНИЯ ДАННЫХ ПРИЁМА

А вот регистр хранения данных, чуть сложнее. У него добавляется управляющий вход ENA. Сигнал ENA –(от английского ENAble) сигнал, разрешающий или запрещающий работу регистра. Регистр работает только тогда, когда на этом входе есть лог.1. Если её нет, то регистр хранит данные, которые в него записали и игнорирует остальные сигналы. Вот его описание на VHDL:

Как видите, это практически такой же сдвиговый регистр. Разница в том, что он двигает данные слева направо. Т.е данные пишутся в старший разряд регистра SHIFT_REG(7) и потом сдвигаются в младшие разряды.

Внимание вопрос. Почему у меня регистр двигает данные слева направо. А не справа налево? Ответы можете оставить в комментариях.

А вот так он реализуется в логических ячейках ПЛИС:

А вот его времянки:

Пока сигнал ENA = 0, регистр не изменяет свое состояние, независимо от состояний входа данных, и синхрочастоты.

Когда сигнал становится активным, т.е. ENA = 1, значит, работа регистра разрешается, и он ведёт себя как обычный сдвиговый регистр.

Сигнал снова стал неактивным, т.е. ENA = 0, значит, регистр хранит в себе данные, и не меняет своё состояния, и т.д…

СЧЁТЧИК БИТОВЫХ ИНТЕРВАЛОВ

Тут все совсем просто, это классический 4 разрядный счетчик с сигналом синхронного сброса. Вот его описание на VHDL:

Давайте взглянем, как он выглядит в RTL Viewer. RTL Viewer показывает, как выглядит наше описание в виде схемы. Обратите внимание, что данная схема имеет лишь косвенное отношение к реализации нашего описания в логических ячейках ПЛИС:

А вот на технологической карте (то, что ложиться в логические ячейки ПЛИС) это выглядит так:

Программа сама минимизирует все логические, функции и то, в каком виде наш счётчик ложится в логические ячейки ПЛИС, решает софт для разработки. Для FPGA фирмы Altera Intel это Quartus. Эти алгоритмы закрыты для пользователей. Главное то, что счетчик работает, так как нам надо. А вот, кстати, как он работает:

Тут всё очевидно. Пока активен сигнал SCLR счетчик постоянно сбрасывается, поэтому его состояние 0. Сигнал SCLR перестал быть активным, счетчик начал считать. SCLR стал активным – счетчик сбросился. Когда счетчик досчитал до состояния, когда во всех разрядах единицы и следующим тактом у него произошло переполнение, и он снова стал считать с нуля. Поэтому на диаграммах вы видите, что после 15 счетчик считает с нуля.

СЧЕТЧИК ПРИНЯТЫХ БИТ

Он чуть сложнее чем обычный счетчик с синхронным сбросом, поскольку у этого счетчика есть вход ENA, т.е сигнал разрешения работы. Вот его описание на VHDL:

То, как он выглядит на RTL Viewer я показывать не буду, нас всё равно это мало интересует. А вот диаграммы всё же покажу:

Работает он так же как и простой счетчик с синхронным сбросом. Только считает он только тогда, когда сигнал ENA активен, т.е. ENA = 1. Если же сигнал не активный, т.е. ENA = 0 то счетчик хранит своё состояние. Ваш КЭП.

На этом описание наших «кирпичиков» окончено. Мажоритарный фильтр, я опишу там же где и автомат. В итоге у нас есть библиотека из следующих элементов:

COUNTER_SCLR

COUNTER_ENA_SCLR

PARALEL_SHIFT_REG

PARALEL_SHIFT_REG_ENA

SYNC_TO_CLOCK_DOMAIN

Данные компоненты мы описали один раз, и они формируют нашу библиотеку. В наших проектах мы их можем использовать бесчисленное количество раз. Особенно если их сделать параметризированными…

Когда компонент имеет чёткое имя, отражающее суть его работы, то его проще найти в библиотеке файлов, особенно когда у вас библиотека состоит более чем из 100 таких вот элементов. По правильному названию элемента вы можете иметь представление об его функционировании. Это очень удобно, так как со временем забывается, что в этой библиотеке есть. А по «говорящим» именам все легко искать. Конечно все, что я говорю, это лишь мои собственные предпочтения, вы можете называть элементы как вам удобнее. Как я делаю, я рассказал, выбор за вами.

Вот теперь можно приступить к описанию приемника UART, где цифровой автомат управляет нашими модулями, или как правильно говорить в VHDL – компонентами.

Полностью показывать весь код я не буду, поскольку это почти 200 строк. Поскольку ключевым устройством является именно цифровой автомат, то я просто выложу только те куски кода, которые, так или иначе, нужны для понимания логики работы автомата.

Подключаем наши описанные «кирпичики» и описываем поведение мажоритарного фильтра:

Автомат мы описываем 3 процессами.

Первый процесс описывает, когда происходит смена состояния автомата:

Второй процесс описывает, то, как вычисляется следующее состояние, в которое должен переключиться автомат:

Последний процесс описывает то, как автомат управляет нашими счетчиками, регистрами:

Ну и теперь, самое вкусное. Как всё это выглядит времянках. Для проверки я написал простенький тест, который отправляет приемнику байт: «01010101», он же число 55 в шестнадцатеричной системе. Очевидно, что если наш приёмник написан правильно, то на выходе этого приемника, должно появиться  число, которое мы ему отправляли. Учтите, что принятое значение должно быть верным только в момент, когда приёмник говорит, что данные корректны т.е. сигнал DATA_VALID = 1. Вот времянка:

И давайте посмотрим, как наш приёмник отработает корявый старт-бит:

Внимание вопрос! Почему я счетчик обнуляю, когда он досчитал до 14?(все ответы есть на времянках)

На этом статью про разработку простейшего приёмника UART я закончил. К сожалению, видео работы приёмника я показать не смогу, поскольку у меня нечем снимать видео. Но в «железе» приёмник работает так, как я и задумывал. Придется вам поверить на слово.

В процессе объяснения вам могло показаться, что все это слишком сложно. На самом деле это не так. Всё очень и очень просто. Данный приёмник я написал за 1 вечер неторопливой работы. Гораздо больше времени заняло изучение протокола UART.

Так же, наверное, у многих возник вопрос, а зачем такие сложности, когда на Arduino можно взять готовую библиотеку, написать несколько строчек кода и всё будет работать? От части это так, на Arduino все делается проще, если есть готовая библиотека. А если её нет? А если она криво написана? А если….

В общем скажу так: проще, не значит лучше. Например мой приёмник занимает в ПЛИС всего 37 логических ячеек. А у меня этих ячеек в ПЛИС около 10 000. Теоретически я могу в ПЛИС запихать 270 таких приёмников, которые будут работать одновременно и независимо друг от друга. Правда это нафиг никому не нужно. Да и, как я в самом первом посте говорил, задачи у ПЛИС и микроконтроллеров разные.

Приветствую уважаемые посетители сайта www.pikabu.ru. Решил продолжить статьи про разработку на ПЛИС. В первом посте я выложил самое начало, с чего стоило бы начать изучение ПЛИС. http://pikabu.ru/story/s_chego_nachat_izuchenie_fpga_plis__4...

Логичнее было бы продолжить постепенно объяснять базовые вещи. Но это был бы очень скучный, долгий и неинтересный материал, который бы только отпугнул и оттолкнул начинающих разработчиков своим объемом и сложностью. И я подумал, а не проще ли сначала показать, на что способна ПЛИС, как ведётся процесс разработки? Поэтому я решил выложить примеры простеньких проектов. А по задаваемым вопросам далее будет видно, какой материал лучше выкладывать.

В этом посте будет рассматриватся формальная постановка задачи написания простейшего приемника RS232, он же COM порт, он же UART*1 интерфейс, он же УАПП – Универсальный Асинхронный Приемо-Передатчик. Выбор пал на COM порт не просто так. Всё дело в том, что этот интерфейс самый простой для изучения и позволяет «подружить» компьютер и ПЛИС, научить их разговаривать друг с другом – передавать данные между собой. Сразу говорю, что полностью объяснять и расписывать все сигнальные линии и всю регистровую модель приемопередатчика я здесь не буду, поскольку для простой организации интерфейса между ПК и ПЛИС это нафиг не нужно. Более того, этого добра навалом во всемирной сетевой помойке и при желании или необходимости вы без проблем найдете всю интересующую вас информацию.

Внимание! Всё, что мною написано - это бред сумасшедшего это мои личные умозаключения, основанные на собственном опыте, на информации из различных источников, достоверность которых весьма спорная. Поэтому я не несу никакой ответственности за возможный вред, нанесенный вашей тонкой душевной организации, трату вашего бесценного времени. Поэтому пока не поздно закройте этот пост. А потом хорошо промойте глаза, желательно с мылом.

Внимание! КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНО подавать сигнал с COM порта компьютера напрямую в FPGA, без специальных преобразователей уровней! В данной статье я не рассматриваю вопросы согласования физических уровней COM порта, и ПЛИС. Исключение составляют виртуальные COM порты, реализуемые на микросхемах FTDI, имеющие уровни сигналов совместимые с ПЛИС.

Для начала совсем коротенько расскажу про протокол обмена информацией по COM порту. Вот посмотрите внимательно, на картинку:

Для начала введем некоторые определения. Высокое состояние линии – соответствует логической единице – лог.1. Низкое состояние линии соответствует логическому нулю – лог.0.

Что же мы видим на этой картинке? А мы видим кучу полезной информации, смотрим справа налево:

Изначально линия находится в состоянии лог.1.

Затем мы видим, что линия становится лог.0, на один период данных. Этот бит данных называется СТАРТ-БИТ, применяется для того, чтобы сообщить приёмнику о том, что началась передача одного пакета\кадра\фрейма информации.

После передачи СТАРТ-БИТА у нас начинают передаваться биты данных. Данные предаются ногами вперед начиная с младшего бита. Обычно в одной посылке 8 бит – т.е. 1 байт. Но это не всегда так. Как правило, сколько бит в посылке оговаривается заранее, и приёмник при приёме уже настроен на необходимое количество бит данных.

После того, как все биты данных переданы может передаваться контрольный бит – или его ещё называют бит четности\паритета (от анг parity). Например, если был выбран четный паритет, то после передачи данных, если количество бит данных было четным – передаётся бит паритета равным лог.1. Если количество бит данных было нечётным – то передаётся бит паритета равным лог.0.

При выбранном нечётном паритете всё в точности наоборот: передали нечётное количество бит данных – бит паритета равен лог.1. Если количество переданных бит было чётным – паритета равен лог.0. Бит паритета нужен для минимального контроля принятых данных. Принимая данные, приёмник подсчитывает количество принятых бит. Если паритет подсчитанный передатчиком не совпадает с принятым битом, означает, что произошёл сбой и работать с данными нельзя. Какой тип паритета будет, а также будет ли вообще использоваться бит паритета, опять же оговаривается до передачи данных.

Любая посылка заканчивается стоповым битом СТОП-БИТ. Во время действия стоп-бита линия данных должна находиться в лог. 1.

Был выработан и прижился короткий способ записи параметров передачи, таких, как количество бит данных, наличие и тип бита четности, количество стоп-бит. Выглядит как запись вида цифра-буква-цифра, где:

• Первая цифра обозначает количество бит данных, например, 8.

• Буква обозначает наличие и тип бита четности.

Встречаются:

N (No parity) — без бита четности.

E (Even parity) — с битом проверки на четность.

O (Odd parity) — с битом проверки на нечетность.

• Последняя цифра обозначает длительность стоп-бита. Встречаются значения 1, 1.5 и 2 для длительности стоп-бита в 1, 1.5 и 2 битовых интервала соответственно.

Например, запись 8-N-1 обозначает, что UART настроен на 8 бит данных без бита четности и один стоповый бит. Для полноты параметров эту запись снабжают указанием скорости UART, например, 9600/8-N-1. Если говорить про скорость, обычно говорят про бодовую скорость. Т.е скорость, с которой отправляется посылка, которая определяет период одного бита. Реальная скорость обмена информацией на скорости 9600/8-N-1 будет на 20% меньше, поскольку среди переданных 10 бит информацию несут только 8 бит, а остальные 2 бита это старт и стоп соответственно.

Асинхронным интерфейс называется так же не зря, у нас нет синхросигнала стробирующего данные. И приёмник должен сам синхронизироваться с передаваемыми данными, зная на какой тип передачи настроен передатчик. На этом наше знакомство с интерфейсом UART окончено, этих данных достаточно для реализации простейшего приёмника.

А сейчас я вас немного погружу информацией по ПЛИС, без которой нам не написать правильный приёмник. В частности я расскажу немного про клоковые домены.

Если взять за жабры гугл-переводчик и зпихать в него фразу «clock domain signals» – то он выдаст перевод: clock domain signals – сигналы тактовой области. Если говорить простыми словами то клоковый домен - это часть проекта, работающая на какой-то одной тактовой частоте. Если в проекте используется только одна тактовая частота – значит клоковый домен у нас один. Если тактовых частот две – значит клоковых доменов у нас уже два и.т.д*2.

Первое наперво, что надо уяснить при работе с ПЛИС – это то, что любой сигнал, пересекающий клоковый домен должен быть синхронизирован с клоковым доменом, в котором мы обрабатываем этот сигнал*3. Частный случай пересечения клокового домена – приём внешних данных, которые обрабатываются на частоте порожденной внутри ПЛИС блоком PLL*4 или на частоте тактирования этой ПЛИС от собственного тактового генератора.

Это очень важный момент, который обязательно надо учитывать при проектировании. Представим, что у нас есть проект, в котором, все триггеры срабатывают по переднему фронту. В проекте есть 9-разрядный счётчик, который работает на частоте 40MHz. Данные с этого счетчика поступают в другую часть проекта, работающего на частоте 37MHz. Т.е пересекают клоковый домен. Посмотрим картинку:

Сигнал CLK – синхросигнал работы счетчика, его частота 40MHz

Сигнал SCLR – сигнал синхронного сброса счётчика. Пока он в состоянии лог.1 счётчик не работает. Очевидно, что когда сигнал сброса прекратит своё действие счётчик заработает.

Сигнал DATA_OUT – выход счётчика..

Сигнал CLK_NEW_DOMAIN – синхросигнал другой части проекта, его частота 37MHz.

Когда сигнал сброса перестанет быть активным, после прихода синхроимпульса, счетчик изменит своё состояние, т.е. переключится из 0 в 1. Причём переключится не сразу, а через какое-то небольшое время. Когда придёт очередной синхроимпульс счетчик переключится из 1 в 2, и.т.д. счётчик же. Обратите внимание, что при переключении счётчика выходные 9 разрядов меняют свои значения не одновременно, а с небольшой задержкой, поскольку физически линии могут иметь разную длину, и разное время распространения сигнала. По одной из 9 линий сигнал пришел раньше, по другой позже, ничего страшного, это реальный мир. Из-за этого в моменты начала переключения счетчика он может выдать абсолютно любые значения, это нормально,

При неправильно сделанном проекте (как у меня на картинке), данные с этого счетчика обрабатываются по переднему фронту синхросигнала CLK_NEW_DOMAIN, например, записываются в регистр. Т.е данные не были правильно перенесены в новый клоковый домен - это серьезная ошибка !

Очевидно что, в зоне отмеченной красным в регистр запишется полная чушь. И поверьте, неправильные данные это меньшее из зол, как правило протоколы верхнего уровня фильтруют ошибочные пакеты. Самое страшное это то, что триггеры, из которых состоит регистр, могут попасть в так называемое метастабильное состояние, когда состояние триггера приняло некую величину промежуточную между состояниями лог.0 и лог. 1, или его выход данных вообще колеблется между ними. Это очень опасно, поскольку один кусок схемы воспримет это состояние как лог.0 , а другой кусок схемы воспримет как лог.1. и схема может выдать результат, которой разработчик даже не предполагал, вплоть до полного зависания схемы и потери работоспособности. Спасет только перезагрузка.

Приведу пример: вы разработали устройство, которое вам приносит тапки, или гладит котика, в зависимости от принятой команды. Но при проектировании этого устройства возможное метастабильное состояние вы не учли. И однажды, когда вы подали устройству команду принести тапки, устройство вместо того, чтобы принести вам тапки, начало с этим тапком гонятся за котиком. Котик очень недоволен!

Чуть более подробно про метастабильное состояние прочитайте тут, https://habrahabr.ru/post/254869/ очень неплохо изложено. Обязательно прочитайте!

Поэтому нельзя просто так взять и передать сигналы из одного клокового домена, в другой. Для того чтобы передать данные между клоковыми доменами их надо синхронизировать с частотой принимающего клокового домена. Блин ну вот напрашивается картинка:

Базовым синхронизатором является обычный последовательный сдвиговый регистр, который тактируется частотой нового клокового домена:

На его вход поступают асинхронные данные ADATA, а на выходе у него данные SDATA синхронные частоте нового клокового домена. Но у этой схемы есть один недостаток: если принимаемый асинхронный сигнал меньше периода синхрочастоты нового клокового домена или равен ей, существует вероятность потерять этот сигнал. Значит, напрашивается самый логичный вывод - приёмник должен работать на частоте большей, чем частота передатчика. Первая ближайшая частота, с которой должен работать передатчик – это частота как минимум в 2 раза быстрее частоты передачи данных.

Внимание вопрос, почему я не могу взять частоту приемника, к примеру, на 50% быстрее бодовой частоты? Ответы оставляйте в комментах.

Итак, частота работы приёмника должна быть выше частоты работы передатчика. А во сколько? В 2 раза, в 3 раза, в 5 раз? Оставим этот вопрос открытым. Далее я немножечко расскажу про ещё одну очень интересную схему, и после этого мы сложим весь пазл, в одно целое.

Представим ситуацию, вы собрались в компанию из 7 тел и решаете, куда бы вам завалиться, культурно отдохнуть. Одна часть решила пойти в бильярд шары погонять, другая часть хочет в боулинг, шары покатать. Альтернатив нет. Очевидно, что вся ваша компания идет туда, куда хочет большинство. Так вот в схемотехнике есть определенный класс схем, которые так же работают по принципу большинства. Такие схемы называются мажоритарные схемы. К чему я это всё пишу. Смотрим на картинку ниже:

Смотрим на верхнюю половину картинки. Пришла какая-то помеха, которая просадила нашу линию данных до лог.0. Вспомним условие старт-бита - это как раз перепад линии данных из 1 в 0. И если мы обработаем эту помеху как старт, и начнем принимать данные, то мы получим данные состоящие из 8 бит равных лог.1. Очевидно, что это ошибка, поскольку данные мы не отправляли, а приёмник что-то получил. Однако…

А если у нас очень много помех, и старт бит выглядит так, как на нижней части картинки?

Вот тут нам на помощь и приходят мажоритарные схемы: если большая часть времени битового интервала был лог.0, значит, приняли лог.0. Если большую часть времени битового интервала была лог.1, значит, приняли лог.1.

Теперь осталось определиться со временем, которое наш мажоритарный фильтр следит за битовым интервалом. У меня не просто так нижняя картинка со старт-битом была нарисована с 2 пиками помех. Всё дело в том, что очень часто любое изменение линии сопровождается неким высокочастотным звоном, особенно если линия несогласованна. И анализировать данные по краям битового интервала – это не совсем правильный подход. Стараются анализировать линии в середине битового интервала. При этом задача как можно более точно «нащупать» эту середину. Для этого применяют частоту приёмника в 16 раз больше частоты передачи, и примерно в середине бита делают 3 выборки. Почему именно значение 16? Первая причина – это то, что счетчик, считающий от 0 – до 15 это счетчик, который обнулятся сам, когда досчитает до конца, хотя точнее сказать счетчик не обнуляется, а у него происходит переполнение разрядов. Да и схемотехнически такие счётчики, более простые. А вот почему частота именно в 16 раз больше, а не в 8, тут сложно назвать какие-то объективные причины. Так сложилось исторически, и я не стал изобретать велосипед.

Итак, сделаем небольшой вывод:

1. Перед работой с данными мы их синхронизируем сдвиговым регистром.

2. Частота нашего передатчика в 16 раз больше частоты принимаемых данных.

3. В середине битового интервала делаем 3 выборки данных.

4. На основании 3 выборок мажоритарный фильтр делает вывод о значении принятого бита.

Вот картинка поясняющая принцип работы:

DATA_CLK – это частота с которой нам поступают данные. В реальности мы не имеем эту частоту, она показана просто для наглядности

UART_STATE_REG – это данные, которые нам передаются.

CLKx16 – частота работы нашего приёмника.

Красным отмечены места выборок для последующего определения того, что мы приняли.

Наш алгоритм действия можно представить в виде такой вот картинки. Сильно не ругайте, я не умею алгоритмы по ГОСТ рисовать.

Поскольку алгоритм у меня не очень красивый с точки зрения соблюдения ГОСТ, то дополнительно опишу все это словами.

Изначально приёмник следит за линией данных, и сбрасывает счетчик, который считает период битового интервала, и счетчик принятых бит.

Когда приёмник увидел, что на линии лог.0 он перестал сбрасывать счетчики и начинает делать выборки для проверки старт-бита.

Когда сделаны 3 выборки в середине битового интервала приёмник смотрит на то, что выдал мажоритарный фильтр. Если мажоритарный фильтр показал, что пришла лог.1, это означает старт-бит был ошибочный и скорее всего пришла помеха.

Если мажоритарный фильтр показал, что пришла лог.0 , это означает, что был принят старт-бит, и когда закончится период старт-бита, приёмник начнет принимать биты данных.

Изначально счетчик принятых битов равен 0, поскольку когда мы ждали старт-бита мы сбрасывали этот счетчик. При приёме данных в середине битового интервала приёмник опять сделал 3 выборки, и на основании того, что выдал мажоритарный фильтр, записал эти данные в регистр, в котором эти данные будут храниться.

В конце битового интервала приёмник проверил, сколько бит он уже принял. Если не все биты приняты, приёмник увеличит счетчик битов на 1, и совершит ещё один цикл приёма бита данных.

Если же все биты данных приняты, то приёмник начнёт анализировать стоп бит.

Анализ стоп-бита точно такой же, как и прошлые биты.

Вот только если фильтр покажет, что принятый бит это лог.0, значит произошла ошибка, и приёмник выставит флаг ошибки, поскольку стоп бит всегда лог.1. И перейдет в состояние ожидания нового старт-бита.

А если фильтр покажет что приняли лог.1 – значит всё в порядке. Приёмник выставит флаг о том, что данные в регистре правильные, и так же перейдет в состояние ожидания нового старт-бита.

На основании этого алгоритма можно сделать простой вывод о том, какие элементы нам понадобятся для его реализации:

1. Счетчик, считающий от 0 до 15, для того, чтобы можно было определять длительность периода старт, стоп бита, битов данных.

2. Счётчик от 0 до 7, считающий, сколько бит приняли.

3. 3 разрядный регистр, для хранения 3 выборок, чтобы провести голосование.

4. Мажоритарный фильтр.

5. 8 разрядный регистр для хранения принимаемых бит данных.

А ещё нам нужна фиговина которая всем этим барахлом управляет:

Эта вот фиговина называется цифровой автомат и будет управлять нашими счетчиками и регистрами, записывать данные, сбрасывать и пр. Я не буду подробно объяснять работу цифровых автоматов, поскольку это отдельная статья, при чём не маленькая. Чуть подробнее можете с автоматами ознакомиться тута:

https://habrahabr.ru/post/254885/ Вполне годно описано. Для написания простеньких автоматов тут информации достаточно.

На этом моменте я вынужден статью закончить. Поскольку дальнейшее объяснение как это все реализовать внутри ПЛИС и промоделировать потребует серьезного увеличения длины поста. Да и у меня к вам появился серьёзный вопрос. Каким образом мне построить продолжение? Основная проблема в том, что дальше будет достаточно много кода на VHDL. И если его выложить сюда, то он развалится из-за того, что pikabu не содержит тегов для вставки кода. Пока ничего лучше, чем выложить кучу скриншотов кусков кода на ум не приходит. А в конце просто дать несколько ссылок на исходники.

*1. Не совсем корректно так говорить, поскольку RS232 он же COM – это одна из разновидностей UART, написал для упрощения.

*2. Отдельный разговор про частоты, кратные основной, полученные делением на счетчике.

*3. Опять же не совсем корректно так говорить, поскольку существуют специальные алгоритмы, где не сигналы синхронизируются, а синхронизируются флаги валидности данных, так называемые алгоритмы handshake.

*4. Специальная фиговина внутри ПЛИС, которая может создать из частоты, от которой тактируется ПЛИС новую частоту.

В пятницу были самые интересные занятия. 87-ой год.

Всем привет. Я захотел себе домой вот такой дверной гонг. Купить его конечно можно, но вот стоят они от 3000 рублей, а тем более хочется действительно необычный звонок. И мне пришла идея создать полифонический дверной гонг на 12/24 трубы. Такое количество труб позволит закрыть две полных октавы, т.е. можно будет сыграть любую мелодию. Я читал много постов про самодельные электронные устройства и верю в силу Пикабу))) из моих предположений удобнее всего реализовать такое устройство на Arduino/Pi+электромагнитные реле, которые будут толкателями для труб. Может быть обойтись Атмегой. На ардуино закладывается роль преобразования мелодии в 12/24 ноты и управление реле с задержкой. Также нужно рассчитать длину труб для соответствия резонансной частоте каждой ноты. Буду рад советам, комментариям. Может кто согласится поучаствовать в таком проекте или сделать предзаказ, требуемые запчасти и расходники с меня. Также прошу помощи у бывалых и знающих: @miharus300, @BootSect, @QwertyOFF, и всех остальных))) Что думаете? Реально? Что потребуется?

Это пост является продолжением предыдущего, в котором я рассказывал о создании часов на газоразрядных лампах. Меня попросили сделать рассказ о том, как разрабатывалось железо.

Традиционно решение какой-либо задачи в электронике начинается с поиска аналогов. В открытом доступе легко гуглятся несколько вариантов схем. Задача инженера рассмотреть все варианты, выбрать оптимальные решения, либо переработать неоптимальные, разработать недостающие части схемы. Стоит понимать, что в разных условиях разные решения могут быть оптимальными. Зависит от кучи факторов: цена компонентов, их доступность, требуемые характеристики устройства (массогабаритные, электрические, интерфейс пользователя).

Мне приглянулась одна из схем на geektimes, которую для перового варианта я содрал практически полностью, по сути заменив лишь микроконтроллер на имевшийся под рукой и отказавшись от ввода питания из розетки (использую блок питания). По той схеме собрал такой макет:

Прошивку писал сам с нуля.

Здесь вылезло несколько проблем:

- У автора была микросхема часов DS1307, использующая внешний кварц. Очень люто убегает время из-за неточного кварца. Заменил часы на DS3231, там кварц термпокомпенсированный внутри микросхемы (датчик измеряет температуру и подстраивает частоту).

- Свист. Свистел дроссель высоковольтного преобразователя (о нем позднее), пришлось менять.

- Круглые лампы выглядят круто, но непригодны для жесткой установки на плату, т.к. во всех цифры под разным углом, выглядит некрасиво. Лампы заменил на ИН-12.

Внимание! Относитесь осторожно к указанным в схеме номиналам элементов и перепроверяйте их, после наладки я актуализировал только перечень элементов, поэтому в схеме могут быть неточности.

Обкатав макет и прошивку начал рисовать свою схему:

Первоначально нужно сделать питание. На вход устройства подается 12 В, микроконтроллеру нужно 5. Для этого стоит U4, это стабилизатор питания на 5 вольт L7805.

U3 это импульсный преобразователь напряжения. Так как лампам нужно напряжение около 180 вольт, приходится 12 вольт подавать на дроссель, а потом резко снимать с него это напряжение. Так как дроссель стремится сохранить в себе ток, напряжение в нем растет и заряжает высоковольтный конденсатор C10. Диод D1 не дает высокому напряжению утекать обратно, подойдет любой, который выживает при таких напряжениях, но лучше Шоттки. Напряжение на дросселе коммутируется транзистором Q16, который в свою очередь управляется микросхемой через пару вспомогательных транзисторов Q14 и Q15, чтоб Q16 открывался и закрывался дико дерзко и не вздумал греться. С2 это частотозадающий конденсатор, с какой частотой наша микросхема будет дергать дроссель. Ну и чтобы напряжение не стало выше необходимого к микросхеме идет обратная связь через резисторы R7, R6 и R5. Так она анализирует сколько вольт уже есть на конденсаторе. Расчет всех номиналов довольно муторный, но в интернетах есть отличные автоматические считалки. Едем дальше:

Тут наш микроконтроллер ATMEGA16, в принципе с задачей справится и восьмая мега. Рядышком разъем для программатора JTAG и конденсаторы (у каждой питательной ноги должен рядом стоять конденсатор, иначе контроллер может нестабильно работать). Слева микросхема дешифратора, по-советски К155ИД1, она получает двоичный код цифры и зажигает нужный катод лампы, притягивая его к земле, а остальные оставляет болтаться в воздухе (не совсем, но не важно). Справа D2 - это микросхема часов, точнее маленькая платка с уже распаянной микросхемой и ее обвязом. Взята у китайских братьев. Почему-то плата с микросхемой стоит дешевле, чем купить микросхему. Батарейка резервного питания часов находится там же.

Внимательный читатель не знакомый с динамической индикацией конечно же спросит, как так, микросхема дешифратора одна, а ламп четыре? Все просто, динамическая индикация, это такая штука, когда единовременно горит только одна лампа, но они быстро-быстро переключаются и кажется, что горят все. Питание на лампы подает вот такой каскад транзисторов:

Тут все просто, транзисторы в ключевом режиме. Микроконтроллер подает напряжение на Q3, он открывается, напряжение между R12 и R13 просаживается и открывает Q2, который и подает ток на лампу. Ток лампы ограничивается R10. Такой каскад нужен для каждой лампы, на разделители между часами и минутами я задействовал два каскада, но потом подключил обе точки к одному. Ток маленькой неонки разделителя гораздо меньше, R10 будет что-то около 200кОм.

Соответственно вот так подключены лампы. Уже на плате я внес исправление и высвободившийся каскад от разделителей, точнее Q3 от него выделил для поджига запятой на левой лампе. Так указываю то, что будильник включен.

Здесь транзистор, который пропускает ток через спикер будильника, подключенный к разъему J5. J3 и J4 это разъемы кнопок, одна часть подтянута к питанию и идет на МК, другая на земле. Когда кнопка будет нажата - на обоих контактах будет земля и МК обработает изменение напряжения с высокого на низкое. Будьте аккуратны с выбором кнопок, нужны без сильного дребезга, хорошо замыкающиеся. Отлично подойдут тактовые кнопки, но я не видел таких с креплением на корпус. J1 и J2 дырки под запайку центральных неонок-разделителй.

Еще одна вещь которой нет на схеме - датчик яркости. Я использовал фоторезистор. Нужно сделать резисторный делитель из фоторезистора и обычного резистора (я взял 12 кОм), а их среднюю точку завести на АЦП микроконтроллера. Измеряя напряжение этой средней точки можно узнать насколько светло снаружи и регулировать яркость ламп во время динамической индикации, т.е. зажигать их на более короткий период времени, и выжидать некоторое время в состоянии когда ни одна лампа не светится.

Такая милота получается после сборки. Если не дружите с AVR C, все то же самое можно сбацать и на народном ардуино. Как рассмотреть вопросы тонкостей программирования в рамках статьи я к сожалению не знаю, там нужен довольно широкий пласт знаний, кто знает - тот и сам напишет, а кто нет - тому за раз не рассказать.

В процессе как всегда набиты некоторые шишки и в следующей версии следует исправить некоторые проблемы:

- К155ИД1 стоит дорого, купить сложно. Можно заменить на горсть транзисторов.

- Выводные элементы. Бесят, жалею что сразу не взял транзисторы поверхностного монтажа. Паять неудобно.

- От электролитов в схеме по возможности стоит отказаться, через десяток лет могут и подсохнуть, но взяты они с хорошим годным запасом, а в часах не жарко.

- Еще можно рассмотреть идею установки GPS для получения времени. Тогда нужно только часовой пояс настроить. Фишка клевая, но смысла нет, так как часы за год убегут не больше, чем на минуту.

- Часы с батарейкой хочется таки распаять на основной плате, но будет чуть сложнее растрассировать плату в тех же габаритах. Вообще почему-то большинство авторов подобных часов использует структуру из нескольких плат, вероятно не могут уместить все на одной.

P.S. если есть технические вопросы, пишите их по возможности в ВК в сообщения сообщества(ссылка есть на одной из фоток в предыдущей статье, текстом ее писать нельзя по правилам). Здесь в комментах не очень удобно отвечать. Только в сообщество, а не админу, а то у меня и так уже кавардак в личных сообщениях)

P.P.S исходники печатной платы не отдам, извиняйте. К тому же это хорошее упражнение для ума. Исходники схемы отдам без проблем, PDFку или для Proteus (вообще гадкая среда, пожалел, что стал в ней делать). Исходники прошивки отдам любому, кто продемонстрирует, что у него уже готово устройство по моей схеме. Куда обращаться указал выше :)