Arduino.ru

Внес изменения.

ещё тот видос навеял такую тему. Вместо 1-wire устройств сделать эдакие CAN-датчики и CAN-ИУ. Они будут на ардуино про мини и MCP2515 что в сумме 200р. Программа у них будет довольно тупая и слать в шину будет  11-битные сообщения. Так мы будем понимать, что перед нами "мелкота".  

Ну что решил со статусами?

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

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

Или ты с датчиками тоже хочешь на мастере ждать ответов от МК о состоянии датчиков?

Не забывай что команды они полюбому инициатива. Так что там без пин-понга не обойтись. Я понимаю проще просто слушать и на основании полученого создавать картину сети. Но без опроса никуда.

Посмотри идею разбивки мастер, слейв, МК, мониторинг https://yadi.sk/d/zkejlJ3K3Td48S

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

При таком раскладе плату надо свою делать ;-)

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

Статусы будут сами высылаться на мастер по умолчанию, но если тебе надо - запроси с любого МК, и на него и придёт РАЗОВО ответ статуса. Соотвественно если постоянно запрашивать, постоянно и будет отвечать статусом. 

Просто нафига постоянно с мастера запрашивать если и так по инициативе подчиненного можно слать. Так и шина меньше забита и код упрощается немного.  

Данные с датчиков , как ты сам говорил, будут высылаться :

- при изменении значений ,

- периодически,

- по запросу. 

В зависимости от того,  что раньше наступит. 

тут почти нечего затачивать. Слейв, как и все подчинённые, шлёт периодически статус мастеру. Так мастер узнает, если слейв лёг (что при этом будем делать?). 

А вот мастер периодически шлёт статус, по твоей логике, видимо, только слейву. Если мастер лёг, слейв об этом узнаёт и разово отправляет всем команду на изменение переменной-адреса высылания ими статуса по умолчанию. Далее все подчинённые начинают периодически слать статус слейву. 

Короче написал я часть программы, которая отвечает за отправку команд и получение отчетов . Т.е. для типов сообщений COMMAND_SEND и COMMAND_ANSWER. 

Суть такая. Название команды  я пока сделал в виде двух байт. Например 12 56. Далее, когда нам надо, мы, из любого места в скетче, отправляем название команды и адрес получателя в специальную функцию, которая ставит отправку данной команды в очередь. А точнее в определённую ячейку в очереди.  

Другая же функция крутится постоянно в лупе. Она проверяет, есть ли что-нибудь у нас в очереди на отправку. Если есть положительные ячейки на отправку , отпраляет в CAN их одну за другой, в каждой включается таймер. Ячейки при этом НЕ высвобождаются.

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

В функции RX( ) мы постоянно ждём прихода отчетов о выполнении назначенных до этого нами команд. Если такой отчет пришёл, название команды сравнивается с занятыми ячейками. При совпадении ячейка высвобождается. Данная команда прекращает отправляться к CAN. 

Соотвественно если отчёта в RX() мы так и не дожидаемся, то  

После 5 раз отправки одной и той же ячейки, она высвобождается, данная команда прекращает отправляться в CAN, высвечивается сообщение об ошибке отправки команды - "кончился таймаут принятия отчета!". 

Но, как всегда, ничего ещё не проверял. Позже выложу. 

Здесь у тебя автоответчик у NODE, т.е если на него пришел запрос он ответил. Это понятно.

У меня же мастер крутит цикл и по прошедствии определенного времени опрашивает кого то. Если убрать цикл то будет тоже самое. В чем вопрос то?

Я же сказал в базе использую твой механизм он эффективнее. Но мой тоже оставляю. Он мне нужен.

P.S.

Хотя глядя на твои идеи в следующих сообщениях понимаю что скорее всего мой алгоритм не понадобится.

Глань я структуру своей сети отрисовал. https://yadi.sk/d/zkejlJ3K3Td48S

Excellent!

Если мастер узнал что слейв лег, то шлет серверу мониторинга (серверу УД с Мажордомо там или еще с чем)

Ты просто монстр программирования! Будет интересно глянуть.

Короче крутяк, всё заработало с первого раза!!! Ща покажу. 

Скетч SEND ANSWER COMMAND

размер очереди по умолчанию у меня стоял 5 ячеек.  И как бы я часто не пытался команды отправлять - местА в очереди всё равно были, сделал для прикола размер очереди - 2 ячейки. Стали появляться сообщения об ошибке, что очередь забита:

Короче взял на всякий с запасом размер очереди - 10 ячеек, читай 10 сообщений.

Я там не исправлял дебаг TX и RX -  поправишь. Вот видос как я проверял работоспособность этой части программы. 

Сейчас нужно ещё добавить часть программы принимающей стороны - если мы получили, какую нибудь команду (ну помимо того что, чтонибудь там будем делать по команде) отправляем отчёт о том, что команда принята - 3 раза . Думаю трёх хватит. 

Тут, видимо , тоже придётся свою очередь сделать на COMMAND_ANSWER.

Вот ты и пришел к тому что я начал. Только ты реализовал эффективнее. Т.е ты отправляешь команду. Та сторона получает. И отправляет ответ.

Причем ты отправляешь n раз пока не дождешься квитанции. 

Кстати вот интересный вопрос. Отправил я увеличить яркость света. Отчет запоздал. Я отпавил еще раз. И еще.

Нужно думать.

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

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

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

И я сформулировал что меня немного напрягает в твоей идеологии. У тебя UDP (отправил забыл) а нужен TCP. Вот с той же командой.

1 узел  запустил счетчик повтора команды, отправил команду ->  узлу 2

2 узел получил команду, отправил отчет о получении -> узлу 1

1 узел получил отчет о получении команды, приостановил счетчик повтора и ждет отчета о исполнении.

2 узел выполнил команду, отправил отчет о выполнении -> узлу 1 

1 узел получил отчет о исполнении, снял счетчик повтора команды, если не получил либо диагностика узла, либо состояния, либо повтор команды

Как то так.

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

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

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

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

Кстати защита от не приема мастером тоже нужна.  Т.е я отправил мастеру статус, все видят а он нет, кто перегрузит мастера?

Ты не полный пример кинул. SendCommand вообще не используешь. 

В loop только SendCommand_queue();

Ну не знаю. Команды, имхо, нужно придумывать так, чтобы двойное исполнение не давало негативного эффекта. Но если уж без таких (полюбому разовых) команд никак, то только так, походу

Можно чтобы мастер слал всё время слейву, что получил статус (от каждого подчинённого). 

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

А вообщето там закоментировано в приеме RX

Т.е. я инициировал отправку команд, тоже как бы по команде с CANHACKER. Т.е. шлю с CANHackera 0xFB, вызывается эта функция и отправляет команду в кан. FA делает чуть другое - видос то смотрел?

На видео плохо слышно. Попробую в наушниках.

Эээх уже путаться начали везде send

Я специально в двух файлах send и answer храню. Send это отправка своя инициативная а Answer это отправка на чужой запрос.

В итоге SendCommand у тебя лежит в RX и срабатывает когда придет COMMAND_SEND (т.е прилетит команда от другого узла) и она отправляет ответ. Так что она send_answer_command видимо должна называться а то запутаемся.

Да и сообщение не по теме. У меня сегодня СЫН родился.

Хех, поздравляю !!!!

Да это я просто для примера сделал, чтобы отправлять команды от тестируемого МК не со скетча, а как бы с канХакера. 

Т.е. с канхакера посылаем команду тестируемуму МК (для него в RX она и будет как COMMAND_SEND)- отправить уже свою команду в CAN. 

я это сделал, чтобы регулировать самому вызов функции SendCommand(). Надо почаще кликаешь, надо - пореже

Я ещё не делал  send_answer_command, не успел

Так совсем запутал. Какой смысл в SendCommand и куда ее поместить в коде?

Если она не ответчик на принятую команду т.е не send_answer то тогда что она такое?

Вот тебе нужно включить свет . Допустим Свет находится на МК адрес 2. Выключатель на МК адрес 1. 

Нам нужно с МК адрес 1 отправить команду на включение света на МК адрес 2.    Пусть будет название команды "01 05"

В скетче МК адрес 1 так вызываешь  функцию так SendCommand (01, 05 , 02)

Собственно говоря, название функции буквально отображает то, что она делает - отправляет команду в CAN

Бллиин ты меня тестированием своим смутил. Положил ее в RX. Спасибо. 

SendCommand (01, 05 , 02) заполняет массив комманд с адресами получателей. Ее вызываем откуда угодно.

SendCommand_queue();  читает массив и отправляет команду. Ее крутим в loop

Так?

Да, SendCommand ставит в очередь команду на отправку - ищет свободную ячейку, как нашла - записывает два байта названия команды, и адрес получателя в эту ячейку массива очереди. 

это верно

А в примере ты просто с канхакера отправлял команду которую МК отправлял куда ты задал в адресе?

да , просто для примера, чтобы фунцкию SendCommand с канхакера повызывать. 

Да чужой код распутывать тяжелее чем свой запутывать.

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

Теперь вот смотри должно быть 2 механизма на каждый тип сообщения

1. периодическая отправка 

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

Причем по сложному многоступенчатому алгоритму

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

Т.е 2 сообщения 1. Принял команду. 2 Выполнил или не выполнил команду.

Ну и ENUM  с командами на все узлы один будешь делать? Или памяти жалко?

Это понятно, уже обсудили, что разовьём эту тему. 

Да, наверное ENUM пойдёт. Причем два нужно. Для каждого разряда названия команды. 

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

Все контроллеры отправляют статус на мастер. Если долго не получен статус, Мастер может поросить статус любого МК инициативно. И кстати как проверить что мастер не получает сам из-за себя? Тужно через Ethernet обмен мастер, слейв и мониторинг-УД продумать.

Все контроллеры шлют состояние датчиков и ИУ на мастер. Мастер может запросить статус датчика или ИУ

Ну наверное для команд может быть только инициатива

Для Аварии тоже только в одну сторону.

Я имел ввиду в принципе предусмотреть эти типы отправок. 

У нас же  sens_dev_enum род устройства. Он уже есть  и передается в CAN ID.

А ну да, ну тогда один байт можно в названии команды, т.к. адрес уже есть, тип устройства есть. Этот байт будет представлять собой:

1 , 0 для булевых. -  вкл/ выкл

от 0 до 255 для ШИМ , диммеров, % включения и т.д.

но нужны также спец команды. Например какую команду передать всем, чтобы сменили адрес отправки статуса. 

1. тип устройства- это sens_dev_enum

2. класс устройства (булево, ШИМ, аналоговое etc)

3. адрес устройства № pin на контроллере 

4. тип команды

Вот тут человек свою сеть сделал на своем железе и сфте. Идеи интересные.

https://habrahabr.ru/post/160469/

https://geektimes.ru/post/258656/

https://clusterrr.com/clunet/

https://github.com/ClusterM/clunet

https://github.com/dudanov/CLUNET-2.0

У него свой бутлоадер с прошивкой по сети. Прошивка overCAN это было бы совсем круто.

добавил SendCommandAnswer. Проверил - работает. После принятия любой команды , отсылает отчёт три раза (с периодичностью 200 мс). Пока так. 

1. Ты сделал 1 ступеньку, получил команду, выполнил команду, отправил статус исполнения Правильно?

Нужно внутри еще одну ступеньку делать, получил команду, отправил квитанцию что получил чтобы больше не слали, выполнил отчитался.

А то жалюзи кинешь команду открывать или котел греть а им время нужно на отчет.

2. Посмотри как я сделал в void send_status_request(uint8_t rem_addr)  и в RX case STATUS_REQUEST_ANSWER:

Если запрос отправлен и ответ получен то стоп и ждем большой период опроса, если ответ не получен ждем малый период и перезапрос, если опять не получен перезапрос, ждем еще и если не ответ кидаем аварию на сервер УД. Просто 3 раза кидать без ожидания ответа и таймера, как раз сеть забивать. 

+ Не забывай начсчет № сообщения в последнем байте данных и возврат мне моего номера сообщения в предпоследнем байте данных.

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

Только не понятно, что делать посылающей команду стороне, если она получила отчет "команда была принята - идёт выполнение". Как узнать сколько будем ждать? и, если не дождались, куда там жалуемся? на сервер?

эту проблему можно решить как раз с помощью твоего глобального счетчика. Вот ему и применение. Когда мы посылаем команду и НЕ получаем отчет, мы отправляем ещё раз ту же самую команду (и так 5 раз через 200мс), НО с таким же значением глобального счетчика. 

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

Прип отправке команды в CAN приращение глобального счетика  у команды делать один раз  - только при постановке в очередь на отправку. 

Нет перезапрос нухно оставить, просто сделать с подтверждением. посвтор если не получил подтверждение в течении определенного времени.

Насчет таймаута выполнения самое интересное,  мы же примерно знаем время выполнения. Делаем константы с предельныим временем исполнения . И ждем это время если не получили ок то перезапрос выполненной команды. Тут именно не повтор команды а запрос что с командой из сообщения №. 

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