[Alexandr54 0]

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

Если задача не решается с точностью до одного такта, можно ли как-то отличить произошло ли второе событие раньше чем через N тактов или позже? N может быть довольно мало, до 10.

Понимаю то задача более подходит для ПЛИС, но нужно решение для уже имеющегося микроконтроллера.

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

Можно с ОС реального времени или baremetal.

STM32F7, 24МГц

[AlanDrakes 1]

На ассемблере - вряд ли. И прерывания на STM32 занимают от 12 тактов, но в некоторых случаях вход займёт больше немногим времени.

https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/beginner-guide-on-interrupt-latency-and-interrupt-latency-of-the-arm-cortex-m-processors

https://stackoverflow.com/questions/12371064/compensating-latency-on-arm-interrupts - плавающее время +/- 5 циклов

В вашем варианте - было бы интереснее делать захват сигнала через Timer Capture. Таймер в этом случае лучше бы использовать длинный, 32 битный, в режиме захвата на максимально возможной рабочей частоте. В момент перехода сигнала тот аппаратно копирует данные из регистра счётчика в регистр результата и взводит прерывание, так что ядру останется только прочитать результат. Соответственно, для другого входа нужно сделать то же самое. Но есть проблема, если это разные таймеры в их синхронизации. Если удастся развести сигнал на пины одного таймера - то таких проблем не будет.

 

2 часа назад, Alexandr54 сказал:

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

Нет. У ARM процессоров имеется такая интересная штука как конвейер. Количество тактов на инструкцию может и будет немного меняться. Чаще в бОльшую сторону, если вдруг произойдёт задержка доступа к Flash. Плюс, минимальный цикл "Чтение состояния порта, Выборка нужного бита, Сравнение, Переход, Увеличение переменной, Переход" - занимает куда больше двух тактов даже с кэшем и конвейером. Так что всё ещё рекомендую использовать таймер, раз он имеется.

> STM32F7, 24МГц

Медленно. Но если не нужна большая точность - то можно. На таймере теоретически можно получить разрешение вплоть до ~5нс (Тактовая частота ядра и таймеров 200МГц, считаем что обе линии имеют одинаковую нагрузочную способность, длина линий более-менее совпадает).

[haker_fox 61]

3 hours ago, Alexandr54 said:

Понимаю то задача более подходит для ПЛИС, но нужно решение для уже имеющегося микроконтроллера.

Я может сейчас откровенную хрень скажу, тем более я даже в доку не заглядывал Вашего МК, но... может быть попробовать задействовать имеющуюся периферию в нестандартном режиме? Например, тактируете SPI от системной частоы без делителя. Если это невозможно, то дальше можно не читать. И в MISO загоняете свои события с пина. Затем, зная цену одного такта, по данным, принятым в SPI считаете время... Либо другой синхронный последовательный интерфейс может быть есть на этом МК? Это годится лишь потому, что Вы назвали всего 10 тактов. Большие времена уже не поместятся во входные буфера периферии.

[dxp 58]

4 часа назад, Alexandr54 сказал:

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

У многих процессоров есть специальные аппаратные счётчики тактов, предназначены как раз для замера производительности, организации профилировки. Имхо, самое правильно использовать эти средства. Вроде бы у многих Cortex-M они имеются.

[x893 55]

5 hours ago, Alexandr54 said:

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

В тактах процессора

Но перед этим надо заставить себя прочитать

https://developer.arm.com/documentation/ddi0489/f/data-watchpoint-and-trace-unit/dwt-functional-description?lang=en

Или пересилить себя и в гугле посмотреть примеры

[Arlleex 178]

С точностью до такта вряд ли получится, особенно если используется DMA или подобные bus-master-ы.

[ViKo 1]

В симуляторе посчитать, если очень сильно надо. В Кейле.

[haker_fox 61]

Может быть автору топика рассказать, что ему нужно сделать на уровне выше? Т.е. не такты считать, а, например, измерить скорость отражённого сигнала? Глядишь, и альтернативное решение появится.

[x893 55]

55 minutes ago, haker_fox said:

Может быть автору топика рассказать, что ему нужно сделать на уровне выше?

Конечно можно. Только какой он - "уровень выше" ?

56 minutes ago, haker_fox said:

Глядишь, и альтернативное решение появится.

Оно всегда есть. Это - УТКИ !

[jcxz 234]

7 часов назад, Alexandr54 сказал:

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

Значит надо выбрать соответствующий МК, который это умеет, а не какой попало.

Например на XMC4xxx это возможно с точностью до такта CPU. Ассемблер не нужен, нужно уметь прочитать мануал о периферии.

Цитата

Можно с ОС реального времени или baremetal.

без разницы

2 часа назад, Arlleex сказал:

С точностью до такта вряд ли получится, особенно если используется DMA или подобные bus-master-ы.

Получится. Если взять соответствующий МК и прочитать мануал на периферию. DMA вообще не причём - ТС ведёт речь о реальных сигналах на пинах МК.

 

PS: Например в текущем проекте (XMC4700) мне нужна синхронизация работы ШИМ-ов в 2-х разных МК посредством старт-бита UART с точностью до такта CPU.

Решение: Имеется ведущий (синхронизирующий) МК и ведомый (синхронизируемый).

1. В ведущем МК я предварительно записываю передаваемое (по UART) сообщение в FIFO UART-а (без старта передачи!). Делаю это в ISR середины периода ШИМ.

2. Стартую передачу содержимого FIFO UART - по регистру сравнения таймера ШИМ ведущего МК (с точностью до такта таймера/CPU). В заранее предопределённой точке периода ШИМ (позже середины периода).

3. Приёмную линию UART на ведомом МК я также завожу на управляющий вход таймера (выбираем такой пин МК, который одновременно соединён с входом захвата таймера и входом UART.RX).

4. По началу старт-бита символа UART - защёлкиваю содержимое таймера, работающего синхронно с ШИМ-таймером в ведомом МК.

Итог: ведомый МК знает относительную разницу в тактах таймера/CPU между периодом своего ШИМ-а и ШИМ-а ведущего МК. С точностью до такта. И может сделать автоподстройку своего периода к периоду ведущего МК.

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

[Arlleex 178]

1 час назад, jcxz сказал:

Получится...

Это я на идею с опросом входа в цикле отвечал (пардон за отсутствие цитаты)

Цитата

...вставить цикл проверки входа и инкрементирования счетчика...

озвученную автором топика. Естественно, только возможностями периферии задачу решать.

Цитата

Итог: ведомый МК знает относительную разницу в тактах...

Не понятно, как ведомый узнает об этом. Грубо говоря, начало старт-бита в ведущем МК всегда где-то внутри периода ШИМ (и не меняется), а ведомый защелкивает это положение и понимает, какой период у ведущего? Ну так тут не обязательно UART можно было (хотя я не знаю Ваших реалий) - так можно было и ножку настроить на переключение по совпадению у ведущего.

[jcxz 234]

14 минут назад, Arlleex сказал:

Не понятно, как ведомый узнает об этом. Грубо говоря, начало старт-бита в ведущем МК всегда где-то внутри периода ШИМ (и не меняется), а ведомый защелкивает это положение и понимает, какой период у ведущего?

Ведомый не период ведущего измеряет (заведомо известно, что периоды у них равны), а фазовую разницу между периодом ведущего и своим. Чтобы сделать их (периоды) синхронными.

 

14 минут назад, Arlleex сказал:

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

UART - обязательно, так как кроме синхронизации периодов ШИМ, само содержимое передаваемое по UART тоже несёт полезную нагрузку - передаёт инфу от ведущего ведомым.

Такое решение позволяет использовать только одну единственную линию UART для решения 2-х задач. И не нужно прокладывать другие линии.

[haker_fox 61]

3 hours ago, jcxz said:

который одновременно соединён с входом захвата таймера и входом UART.RX)

А так бывает? Такие чудеса позволяет делать XCM4700? Или Вы очень быстро переключаете функцию пина с захвата на вход приёмника УСАПП?

[Arlleex 178]

7 минут назад, haker_fox сказал:

А так бывает? Такие чудеса позволяет делать XCM4700? Или Вы очень быстро переключаете функцию пина с захвата на вход приёмника УСАПП?

Там грамотно сделан мультиплексор альтернативных функций - одновременно к ноге может быть подключены 1 выход но куча входов периферии.

[jcxz 234]

21 минуту назад, haker_fox сказал:

А так бывает? Такие чудеса позволяет делать XCM4700?

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

И такое решение имхо - более правильное, чем у STM32 & LPC.

Расширяйте кругозор: мир не ограничен одними STM32 и LPC. И у разных производителей есть разные интересные решения.  

 

PS: Кроме того - внутри имеется и "Event Request Unit" - что-то типа простейшей ПЛИС, позволяющий соединять внешние пины и внутренние различные периферийные сигналы, объединять их различными логическими функциями. Правда - очень ограниченное по количеству. Но в STM32 и такого нет.