Здравствуйте, уважаемые форумчане. Есть опытный образец тензоизмерительной системы на 64 канала на контроллере stm32f107.
Необходимо реализовать синхронизацию между несколькими такими системами.
И вот в чём трудность:
1) так как частота опроса одного канала 250 раз в секунду, то имеем времени на один канал порядка 62,5 микросекунд, каким образом можно добиться синхронизации, чтобы несколько модулей одновременно (или почти одновременно) выполняли преобразование по каждому каналу, за указанный промежуток времени?
2) как сделать так, чтобы в случае внезапного выхода из строя одного или нескольких модулей, работоспособные модули оставались синхронизированными?

Пока решили проблему с помощью двух выводов на одном из портов (эти выводы соединены соответственно у всех контроллеров между собой):
1)В начальный момент времени оба вывода настроены как входы с подтяжкой к питанию.
2)Перед запуском преобразования ПЕРВЫЙ вывод опрашивается до тех пор пока не будет прочитана "1" (или таймаут, сейчас он равен 10000 мс), т.е. определяем готовы ли все модули к работе.
3)Затем ПЕРВЫЙ вывод настраивается в режим выхода на все время опроса и держится равным "0" (сигнализируя нам о том, что модули находится в режиме опроса каналов).
4)Далее ВТОРОЙ вывод (перед началом преобразования АЦП) настраивается на выход и переводится в "0".
5)По завершению преобразования АЦП, ВТОРОЙ вывод настраивается на вход с подтяжкой к питанию и опрашивается до тех пор пока не будет прочитана "1" (или таймаут, сейчас он равен 55 мкс), т.е. все модули завершили преобразование по одному каналу.
6)После, пока не принята команда "СТОП", циклически повторяем пункты 4 и 5.
7)Когда принята команда "СТОП" ПЕРВЫЙ и ВТОРОЙ выводы настраиваются в режим входа с подтяжкой к питанию (сигнализируя нам о том, что модули вышли из режима опроса каналов).

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

Может быть есть какой-либо вариант решения проблемы? (например, один модуль мастер, а остальные слейвы, но что делать, если мастер завис?, в общем непонятно...).

А в чём именно трудность? Завести на все модули параллельно один сигнал и по этому сигналу стартовать измерения.

Т.е. получается должен быть ведущий МК, я правильно понял? А если он зависнет? По приоритетам и таймаутам инициализировать другой мастер? (Например, чем ниже приоритет тем больше таймаут ожидания сигнала от мастера).

Зачем ведущий? Вам же известен период синхронизации и он постоянный. Просто генератор периодического сигнала с этой частотой.
Вы что-то нагромождаете сложности на пустом месте. Имхо.

Нет частота может меняться и задается пользователем (я как-то не подумал, что это надо указать) от 20 до 250 Гц на канал, как и количество каналов в списке от 8 до 64. И управляется всё по Ethernet-UDP. В том-то и трудность, что времени нет на синхронизацию (по тому же Ethernet c PTP протоколом нет сервера PTP, и знаний на реализацию пока не хватает) на максимальной частоте опроса, вот и приходится городить... Поэтому и подумал, что вы подразумеваете, чтобы был ведущий МК.

Слишком сложно и муторно. Все это можно было реализовать на одном выходе, настроив его в режим открытого стока (open drain). Логику "первый-второй вывод" реализовать программно.


То есть сначала настраивается на вывод с произвольным уровнем, а потом переводится в ноль? И при этом он снаружи закорочен на ПЕРВЫЙ вывод, который уже выводит ноль? Да вы рисковые парни

ПЕРВЫЙ и ВТОРОЙ вывод не соединены между собой, они подсоединены к соответствующим выводам других контроллеров.

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

Тогда задача единственно решается путём заменой Вас на соответствующего специалиста, знающего соответствующий протокол привязки к единому времени.

Но задаётся она кому? Одному из этих МК? Или все МК знают установленную частоту?
Тогда можно генерить эту частоту таймерами этих МК: каждый МК запускает таймер, по истечении таймаута на каком-то выводе МК формируется 0, все такие выводы МК имеют ОК и соединены "монтажным И". И данный вывод заведён также на все эти МК как вход прерывания от внешнего сигнала и по событию "переход в 0" на данном выводе, запускается преобразование, а также останавливается и перезапускается свой таймер. Так что - если Вы боитесь, что какой-то из МК зависнет, то тут если хотя-бы один из МК не завис, то генерация будет идти.
Ну а если боитесь, что повисший МК зафиксирует линию в постоянном "0", можно сигнал с МК на эту общую линию заводить не напрямую, а через дифференцирующую цепочку или через ждущий мультивибратор (который из перехода 1->0, будет формировать импульс "0" фиксированной длительности).


Если Ethernet заведён на все эти МК, то конечно синхронизировать их всех и нужно от этого Ethernet.

Plain, насчет единого времени, да пробел, но я только начинаю осваивать контроллеры.
jcxz, Про "монтажное И" с открытым стоком я и не додумался, хорошая идея, тогда действительно реализуется все на одном выводе.
Plain, а синхронизация по протоколу PTP, выполнение преобразования АЦП и отправка пакетов по UDP успеет все это выполниться за 60 микросекунд?

Это и не надо делать за 60мкс.
Протокол PTP синхронизирует таймеры во всех МК. А уже от них синхронизируются преобразования (или какие другие процессы) в МК.

jcxz, т.е. синхронизацию необходимо делать перед самым началом измерений? А если измерения идут несколько дней непрерывно, как выполнять синхронизацию не прерывая измерения? Или все-же следует прерывать измерения через определенный промежуток времени, выполнять синхронизацию и снова запускать измерения?

Как там у вас устроена работа измерений - только Вы знаете.
Синхронизацию таймера можно выполнять при каждом пришедшем кадре со временем.
А запускать измерения - уже от этого таймера. Имхо так. Если я правильно понимаю Вашу задачу....

Если кадров установки времени по Ethernet долго не будет (несколько дней), то постепенно таймеры в разных МК разойдутся и измерения будут несинхронны.
Если у Вас возможна такая ситуация (когда долго нет кадров установки времени по Ethernet), то необходима синхронизация таймеров МК между собой (как выше описывалось).
Да и синхронизация времени по Ethernet,
если она у вас может пропадать, зачем тогда она вообще нужна вам? Ведь если речь идёт о десятках мкс - тут таймеры могут рассинхронизироваться уже через несколько секунд, в зависимостьи от точности вашего кварца.

..если МК с отлаженной прошивкой виснет по электрическим причинам то это очень большая проблема и в принципе недопустимо, и если уж такое в КРАЙНЕМ случае произошло то компенсируется супервизором.
Поэтому, я за один мастер МК управляющий кучей слейвов.

jcxz, т.к. софт на управляющем компьютере уже разработан не нами, то и синхронизация по Ethernet под вопросом. Поэтому мы и начали использовать синхронизацию аппаратную по состоянию выводов (как написано в самом начале созданной темы).
Lmx2315, тоже сначала была мысль Мастер-слейв, но для этого надо перед началом измерений настроить контроллеры в нужный режим (мастер или слейв), что опять требует команд с главного компьютера, что в свою очередь упирается в софт. Поэтому и хотели отвязаться от внешних воздействий с точки зрения синхронизации. А за супервизор (возможно ли вместо него использовать внутренний сторожевой таймер в случае электрического зависания или он тоже окажется неработоспособным?) спасибо, учтем.

И к вопросу по PTP-протоколу, почитал про него и все же не понял, а именно, допустим процедура синхронизации с главным компьютером прошла успешно, мы вычислили поправку времени и, так сказать, выставили точное время в подчиненном контроллере. А что дальше? ведь мы только настроили ход системных часов контроллера, а тактовая частота же контроллера осталась без изменений.
Т.е. получается, если я хочу использовать для каких-то внутренних процессов, например таймер 3 (задает период опроса АЦП), то ему же побоку как идут системные часы на контроллере или я чего-то не понимаю? Разъясните, мне дураку, пожалуйста...
И в случае использования фичи синхронизации по протоколу точного времени, применительно к stm32f107(f407), единственным решением я вижу установку будильника (прерывание по target time) и запуску какой-либо задачи (например того же таймера 3) в этом прерывании с последующей перестановкой будильника на заданную величину dT, после чего процесс повторяется циклически, или я снова чего-то не понимаю?

Или я чего не понимаю или, возможно, имелось в виду "частота опроса одного мудуля 250 раз в секунду".
В одном модуле 64 канала, на каждый канал выделяется 62.5мкс.
Значит, все 64 канала модуля опрашиваются за 64*62.5мкс=4000мкс=4мс, что как раз и составляет 1/250Гц=0.004с=4мс=4000мкс.
Так?


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


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

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

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

jcxz, так я же и прошу разъяснить, хотя бы в общих чертах.

То что я многого не знаю, я не оспариваю, знал бы, не писал бы на этом форуме вопросы. Наверное, для того и форум, чтобы разъяснить непонятные моменты у опытных товарищей, или я снова ошибаюсь?
Я же не прошу здесь никого написать мне рабочий код. Напишу сам, дело времени. Ведь написал текущую версию программы, пусть и простейшую и может быть "говнокодную" (и вроде не глючит даже), но написал сам на регистровом CMSIS. И если мне что-то не понятно, что бросать все и уходить на работу уборщиком? (хотя с моим уровнем знаний только туда и дорога ).

"Некоторые моменты" можно, но как объяснить эти моменты, если нет понимания?

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

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

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

Plain, модули соединены через коммутатор Ethernet по локальной сети с главным компьютером. Программа на компьютере управляет всеми модулями (команды старт, стоп, настройка и т.д.).
В целом идея ясна, если главный компьютер имеет обеспечение для PTP, то будем осваивать протокол PTP и внедрять его в МК.
Если такой возможности нет, будем применять аппаратную синхронизацию (монтажное И, или мастер-слейв), благо имеются внешние выводы у каждого модуля для соединения между собой.
На этом тему можно считать закрытой.