|
Синхронизация МК между собой |
|
|
|
Feb 1 2017, 09:10
|
Участник

Группа: Участник
Сообщений: 41
Регистрация: 25-08-15
Из: Рыбное
Пользователь №: 88 141

|
Здравствуйте, уважаемые форумчане. Есть опытный образец тензоизмерительной системы на 64 канала на контроллере stm32f107. Необходимо реализовать синхронизацию между несколькими такими системами. И вот в чём трудность: 1) так как частота опроса одного канала 250 раз в секунду, то имеем времени на один канал порядка 62,5 микросекунд, каким образом можно добиться синхронизации, чтобы несколько модулей одновременно (или почти одновременно) выполняли преобразование по каждому каналу, за указанный промежуток времени? 2) как сделать так, чтобы в случае внезапного выхода из строя одного или нескольких модулей, работоспособные модули оставались синхронизированными?
Пока решили проблему с помощью двух выводов на одном из портов (эти выводы соединены соответственно у всех контроллеров между собой): 1)В начальный момент времени оба вывода настроены как входы с подтяжкой к питанию. 2)Перед запуском преобразования ПЕРВЫЙ вывод опрашивается до тех пор пока не будет прочитана "1" (или таймаут, сейчас он равен 10000 мс), т.е. определяем готовы ли все модули к работе. 3)Затем ПЕРВЫЙ вывод настраивается в режим выхода на все время опроса и держится равным "0" (сигнализируя нам о том, что модули находится в режиме опроса каналов). 4)Далее ВТОРОЙ вывод (перед началом преобразования АЦП) настраивается на выход и переводится в "0". 5)По завершению преобразования АЦП, ВТОРОЙ вывод настраивается на вход с подтяжкой к питанию и опрашивается до тех пор пока не будет прочитана "1" (или таймаут, сейчас он равен 55 мкс), т.е. все модули завершили преобразование по одному каналу. 6)После, пока не принята команда "СТОП", циклически повторяем пункты 4 и 5. 7)Когда принята команда "СТОП" ПЕРВЫЙ и ВТОРОЙ выводы настраиваются в режим входа с подтяжкой к питанию (сигнализируя нам о том, что модули вышли из режима опроса каналов).
Только есть проблема, если хотя бы один модуль повис (хотя в программе все циклы конечные) и не сменил состояние ВТОРОГО вывода, то остальные модули всегда ждут таймаут и переходят к следующему каналу, т.е. получается, что они уже не синхронизированы между собой.
Может быть есть какой-либо вариант решения проблемы? (например, один модуль мастер, а остальные слейвы, но что делать, если мастер завис?, в общем непонятно...).
|
|
|
|
|
Feb 1 2017, 09:54
|
Участник

Группа: Участник
Сообщений: 41
Регистрация: 25-08-15
Из: Рыбное
Пользователь №: 88 141

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

Группа: Участник
Сообщений: 41
Регистрация: 25-08-15
Из: Рыбное
Пользователь №: 88 141

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

Гуру
     
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095

|
QUOTE (ivan24190 @ Feb 1 2017, 11:10)  оба вывода настроены как входы с подтяжкой к питанию. ... ПЕРВЫЙ вывод настраивается в режим выхода на все время опроса и держится равным "0" Слишком сложно и муторно. Все это можно было реализовать на одном выходе, настроив его в режим открытого стока (open drain). Логику "первый-второй вывод" реализовать программно. QUOTE (ivan24190 @ Feb 1 2017, 11:10)  Далее ВТОРОЙ вывод (перед началом преобразования АЦП) настраивается на выход и переводится в "0". То есть сначала настраивается на вывод с произвольным уровнем, а потом переводится в ноль? И при этом он снаружи закорочен на ПЕРВЫЙ вывод, который уже выводит ноль? Да вы рисковые парни
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
Feb 1 2017, 10:33
|
Участник

Группа: Участник
Сообщений: 41
Регистрация: 25-08-15
Из: Рыбное
Пользователь №: 88 141

|
ПЕРВЫЙ и ВТОРОЙ вывод не соединены между собой, они подсоединены к соответствующим выводам других контроллеров.
|
|
|
|
|
Feb 1 2017, 10:41
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Цитата(ivan24190 @ Feb 1 2017, 12:12)  Нет частота может меняться и задается пользователем (я как-то не подумал, что это надо указать) от 20 до 250 Гц на канал, как и количество каналов в списке от 8 до 64. И управляется всё по Ethernet-UDP. В том-то и трудность, что времени нет на синхронизацию (по тому же Ethernet c PTP протоколом нет сервера PTP, и знаний на реализацию пока не хватает) на максимальной частоте опроса, вот и приходится городить... Поэтому и подумал, что вы подразумеваете, чтобы был ведущий МК. Но задаётся она кому? Одному из этих МК? Или все МК знают установленную частоту? Тогда можно генерить эту частоту таймерами этих МК: каждый МК запускает таймер, по истечении таймаута на каком-то выводе МК формируется 0, все такие выводы МК имеют ОК и соединены "монтажным И". И данный вывод заведён также на все эти МК как вход прерывания от внешнего сигнала и по событию "переход в 0" на данном выводе, запускается преобразование, а также останавливается и перезапускается свой таймер. Так что - если Вы боитесь, что какой-то из МК зависнет, то тут если хотя-бы один из МК не завис, то генерация будет идти. Ну а если боитесь, что повисший МК зафиксирует линию в постоянном "0", можно сигнал с МК на эту общую линию заводить не напрямую, а через дифференцирующую цепочку или через ждущий мультивибратор (который из перехода 1->0, будет формировать импульс "0" фиксированной длительности). Цитата(Plain @ Feb 1 2017, 12:37)  Похоже, нам придётся Вас ещё немного доозвучить, а именно, что каждый модуль ни с чем в этом мире не связан, кроме как по локальной сети, в которой Вы не специалист. Если Ethernet заведён на все эти МК, то конечно синхронизировать их всех и нужно от этого Ethernet.
|
|
|
|
|
Feb 1 2017, 10:56
|
Участник

Группа: Участник
Сообщений: 41
Регистрация: 25-08-15
Из: Рыбное
Пользователь №: 88 141

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

Группа: Участник
Сообщений: 41
Регистрация: 25-08-15
Из: Рыбное
Пользователь №: 88 141

|
jcxz, т.е. синхронизацию необходимо делать перед самым началом измерений? А если измерения идут несколько дней непрерывно, как выполнять синхронизацию не прерывая измерения? Или все-же следует прерывать измерения через определенный промежуток времени, выполнять синхронизацию и снова запускать измерения?
|
|
|
|
|
Feb 2 2017, 08:44
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Цитата(ivan24190 @ Feb 1 2017, 13:31)  jcxz, т.е. синхронизацию необходимо делать перед самым началом измерений? А если измерения идут несколько дней непрерывно, как выполнять синхронизацию не прерывая измерения? Или все-же следует прерывать измерения через определенный промежуток времени, выполнять синхронизацию и снова запускать измерения? Как там у вас устроена работа измерений - только Вы знаете. Синхронизацию таймера можно выполнять при каждом пришедшем кадре со временем. А запускать измерения - уже от этого таймера. Имхо так. Если я правильно понимаю Вашу задачу.... Если кадров установки времени по Ethernet долго не будет (несколько дней), то постепенно таймеры в разных МК разойдутся и измерения будут несинхронны. Если у Вас возможна такая ситуация (когда долго нет кадров установки времени по Ethernet), то необходима синхронизация таймеров МК между собой (как выше описывалось). Да и синхронизация времени по Ethernet, если она у вас может пропадать, зачем тогда она вообще нужна вам? Ведь если речь идёт о десятках мкс - тут таймеры могут рассинхронизироваться уже через несколько секунд, в зависимостьи от точности вашего кварца.
|
|
|
|
|
Feb 2 2017, 12:22
|
Участник

Группа: Участник
Сообщений: 41
Регистрация: 25-08-15
Из: Рыбное
Пользователь №: 88 141

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