RS-485 на отечественных микроконтроллерах от фирмы Миландр

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

Простыми словами о преобразовании Фурье

спасибо, это вернуло мой покой:)
На самом деле я изначально неправильно воспринимал дельту функцию именно Дирака. И излишне упрощал.

Простыми словами о преобразовании Фурье

.

Простыми словами о преобразовании Фурье

что значит сложно? Это просто математически неверно :).
Автор утверждает что функцию умножить на гребенку дирака — получаем оцифрованную функцию, дальше он это переводит в фурье образы, перемножает и получает повторение спектра.

Если повторить рассуждения автора, но с вашей функцией
f(x) = 1 для x = kT
f(x) = 0 для x != kT
то слева у нас точно оцифровка, а справа получается свертка нуля и спектра функции, то есть ноль. И вся теория рушится…

Однако если собраться и принять что оцифровка — это свертка гребня дирака и исходной функции. То слева все получается, за счет фильтрующего свойства дельта функций мы получаем семплинг. Теперь осталось понять что у нас справа.

Или я где то не прав?

Простыми словами о преобразовании Фурье

У меня проблема с тем что есть переход от поточенного перемножения функций к их свертке после преобразования. И все замечательно, но только к сожалению первоначальная функция умноженная на бесконечность не дает отсчеты начальной функции :(. Если бы там где-то был бы интеграл, то было бы применено фильтрующее свойство, а так я что-то не понимаю как :(

Простыми словами о преобразовании Фурье

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

FPGA для программиста, конечные автоматы (verilog)

Сброс должен был быть асинхронным чтобы реагировать на события даже в отсутствии клока. Источников событий было несколько в том числе и этот сигнал.

то кто мешал отдельно этот сигнал пропустить через триггер

Именно с этим сигналом так и было сделано. Поскольку его порождает тактируемая логика его можно было пропустить через триггер.

Я просто хочу отметить, что часто внутри синхронных дизайнов мы начинаем считать комбинаторные сигналы неизменными между клоками, как выходы триггеров. Так происходит с выходами автоматов описанных в 2 блока, которые по сути комбинаторные. И пока они управляют внутри схемы, работают с тактируемыми ее участками все Ок. Но при реюзе или поддержке проекта это может вылезти боком. Как и получилось с этим сигналом, он же использовался на самом деле много где, но всегда синхронно, и его асинхронная суть потерялась %)

FPGA для программиста, конечные автоматы (verilog)

Последние где я наступил:

Из памяти читается код безопасности и его контрольная сумма. Для считанного кода считается контрольная сумма и сравнивается со считанной из памяти. Это сравнение вырабатывает разрешение на работу.

То есть схематично:
MEM -> CS1
MEM -> Code -> Calc -> CS2
assign allow = (CS1 == CS2)? 1'b1: 1'b0;

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

Конечно, это можно списать на «кривость» проекта. И да это примитивная ошибка.

FPGA для программиста, конечные автоматы (verilog)

несомненно, при организации любого сброса выход из него должен быть синхронным. Но проблемы именно со входом.

FPGA для программиста, конечные автоматы (verilog)

Но когда мы говорим о FPGA мы подразумеваем концепцию синхронного проектирования

Это очень сильное ограничение :).

Мы отвлеклись от основной мысли. Выхода автомата может быть комбинаторный (описание в 2 части) и регистровый (описание в 3 части). Разница между ними в том что комбинаторный выход имеет иголки и его потребителем могут быть только синхронные схемы, причем желательно на той же частоте что работает автомат. Регистровый выход лишен иголок, его могут потреблять как синхронные, так и асинхронные схемы.

Асинхронными могут быть как внутренние блоки (асинхронный сброс, установка), так и внешние для фпга устройства.

FPGA для программиста, конечные автоматы (verilog)

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

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

Абсолютно те-же иголки формируются при синхронном переключении состояний автомата.

А вот это неверное утверждение.

например:

...
//-----------------------------------------------
assign next_cnt = cnt + 1'b1;
always @(posedge clk)
  cnt <= next_cnt;

//-----------------------------------------------
assign out_a = (cnt != 0) ? 1'b1 : 1'b0;
always @(posedge clk)
  out_s <= (next_cnt != 0) ? 1'b1 : 1'b0;
...

на сигнале out_s никогда не будет иголок, как могут быть на сигнале out_a. Подщелкивать выходные сигналы является хорошим тоном, даже в асиках, которые очень любят комбинаторику :).

FPGA для программиста, конечные автоматы (verilog)

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

Не понимаю как можно сделать правильно:) Комбинаторная схема во время переключения входных сигналов имеет полное право генерировать «иголки», которые вызовут сброс.
Все тоже самое верно и для комбинаторных выходов. Комбинаторные сигналы безопасно идут только внутри домена синхронных схем, как только вы их выдали наружу или в домен с другим клоком, вы потенциально породили проблемы. Если не сейчас, так завтра.

На скорую руку сделал проект, как я его вижу.

Понятно, спасибо. Я не стал отделять счетчик от автомата, чтобы не размывать суть повествования. Статья не про оптимизацию автоматов, а про разные виды записи. В любом случае спасибо за потраченное время! :)

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

FPGA для программиста, конечные автоматы (verilog)

Писать автомат в 2 always блоках или в 3 — вопрос чисто философский

Нет, если мы говорим не про формальное разделение на блоки, а про функциональное. Третий always блок для формирования регистрового, а не комбинационного выхода. И это не философия.

порождает на выходе FSM лишние и, самое главное, никому не нужные триггеры.

До тех пор пока выход автомата не зашел на какой-либо асинхронный сброс или подобное…

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

Я бы не называл данный автомат в 7 состояний большим, но интересно было бы посмотреть вашу реализацию. Пока мне не очевидно как предлагаемое Вами разбиение сделает работу более наглядной.

FPGA для программиста, конечные автоматы (verilog)

Пожалуйста, рад что вам понравилось.

Во-первых, как я понимаю код автора содержит генерацию латчей, что не очень хорошо, и даже плохо

Ну во-первых не содержит, потому что есть состояние дефолт. Латч появляется если существуют сочетания условий в которых комбинаторная переменная не имеет описания выхода и следовательно вынуждена сохранять свое значение. Добавление в начале значения по умолчанию — это защита на случай если что-то забудем описать в вариантах.
Во-вторых у ксалинкса есть примитивы латчей, у альтеры их симуляция, а в асиках их применяют довольно таки часто.

По крайней мере, на VHDL это так

И на ВХДЛ тоже.

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

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

В-третьих, можно заметить что описанная FSM всегда синхронизированна по clk, что не оптимально по скорости.

Неужели вы предлагаете на клоковые входы триггеров заводить комбинаторные сигналы. И это в FPGA? И это для увеличения скорости?

Рекомендую обратиться к коду примеров Xilinx что бы «ужаснуться» от количеству процессов даже в простом коде ;)

Вы либо только начинаете, либо уже так продвинуты в описании железа, что на моем уровне мне трудно понять что вы имеете в виду %). Но все же я больше склоняюсь к первому, чем ко второму).
В любом случае, спасибо за мнение :)

FPGA для программиста, конечные автоматы (verilog)

Я думаю не стоит сокрушаться, что я не написал в статье то, что вы хотели бы видеть. Это же дает вам огромные возможности для своих статей :)

Если говорить про оптимизацию (по разным параметрам) то сильнее влияют способы кодирования состояний и типы автоматов, чем число always блоков при их описании.

И да, я пытаюсь говорить о стилях и строках, потому что считаю немаловажными параметрами качества кода: его читаемость, управляемость, поддерживаемость.

FPGA для программиста, конечные автоматы (verilog)

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

FPGA для программиста, конечные автоматы (verilog)

Я не затрагивал виды автоматов, кстати, их больше двух. Я сосредоточился именно на способе их описания. Так что может и формальность, но именно на формальности я и сосредоточился)

FPGA для программиста, конечные автоматы (verilog)

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

FPGA для программиста, конечные автоматы (verilog)

Я пытаюсь говорить про разницу между 2(3) и 1 частным описаниями автоматов. Технически, конечно, можно комбинаторный always блок написать через

assign r = (c1) ? a  : 
           (с2) ? b  : 
           ....  

но это жестоко).
Поэтому 2 частному автомату я определяю 2 always блока. Я не пытаюсь числом always блоков определить тип описания, скорее тип описания определяет минимальный набор блоков.

FPGA для программиста, простые рецепты

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