Очередной "Умный дом", на этот раз модульная система...

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

и нужно добавить ещё один тип сообщений - СOMMAND_ANSVER_OK - команда выполнена

отпличие от СOMMAND_ANSVER  - команда принята к исполнению

Честно говоря я думал раз СOMMAND_ANSVER то в данных и будет результат обработки ОК или не ОК. Типами сообщений тоже разбрасываться не стоит. У нас их всего 16 а по факту чтобы с 0000 не путаться то 15.

MaksVV
Offline
Зарегистрирован: 06.08.2015

найдётся этому direct применение. говорю тебе можно сделать отдадку по кан. Т.к. сказать типа ЭХО - чтобы по определённой команде МК слали в CAN, то что получают из CAN, но в ID будут ставить этот бит в единичку. 

По этой единичке мы будем отслеживать, что это дебагерские мессаги и начинаем все МК видеть с одного места из CANа - не нужна станет отладка через UART

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:

Честно говоря я думал раз СOMMAND_ANSVER то в данных и будет результат обработки ОК или не ОК. Типами сообщений тоже разбрасываться не стоит. У нас их всего 16 а по факту чтобы с 0000 не путаться то 15.

точно так  и сделаем

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

потому что у тебя нужно во всех скетчах сделать 8MHZ а не 16, (смотри на кварц на модулях)

if(CAN0.begin(MCP_ANY, CAN_500KBPS, MCP_8MHZ) == CAN_OK)

И ЕЩЁ!!! смотри на каком пине у МЕГИ прерывание INT0, на 23 вроде, попробуй это тоже поменять. У Наны на 2 пине.

скорость шины и компорт выбирается во вкладке Settings

PS в канхакере ( в библиотеке которая по ссылке) я там уже исправил. 

Вроде все поправил результата нет. Полезу в коробки Нану искать ;-) и mcp2515 надо докупить. У меня к мегам все припаяны на пин 2, от INT mcp2515 получается косяк? Надо перепаивать?

MaksVV
Offline
Зарегистрирован: 06.08.2015

посмотри, как тебе правленные TX  и RX ?

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
Вроде все поправил результата нет. Полезу в коробки Нану искать ;-) и mcp2515 надо докупить. У меня к мегам все припаяны на пин 2, от INT mcp2515 получается косяк? Надо перепаивать?

на 21 пин МЕГИ провод INT CAN модуля пробовал вешать?

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

найдётся этому direct применение. говорю тебе можно сделать отдадку по кан. Т.к. сказать типа ЭХО - чтобы по определённой команде МК слали в CAN, то что получают из CAN, но в ID будут ставить этот бит в единичку. 

По этой единичке мы будем отслеживать, что это дебагерские мессаги и начинаем все МК видеть с одного места из CANа - не нужна станет отладка через UART

Ок. Давай только это с тебя ;-). Я с битами и байтами на Вы. Я поэтому текстовый декодер и сделал. 

Ну и название переменной сам задавай. Чтобы назначение было понятно.

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
Ок. Давай только это с тебя ;-). Я с битами и байтами на Вы. Я поэтому текстовый декодер и сделал.

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

Также можно и канхакером в HEXe будет контролировать

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:
Вроде все поправил результата нет. Полезу в коробки Нану искать ;-) и mcp2515 надо докупить. У меня к мегам все припаяны на пин 2, от INT mcp2515 получается косяк? Надо перепаивать?

на 21 пин МЕГИ провод INT CAN модуля пробовал вешать?

Паяльник вот грею. Я после ремонта-переезда только стол себе завел и коробки только понемногу распаковываю.

Так отставить паяльник

http://arduino.ru/Reference/AttachInterrupt

Плата int.0 int.1 int.2 int.3 int.4 int.5
UNO, Ethernet 2 3        
Mega2560 2 3 21 20 19 18
Leonardo 3 2 0 1 7  

Я точно помню что сначала думал потом паял

int0 в меге на 2 пине на 23 вообще ничего на 21 int2

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
Полезу в коробки Нану искать

Из УНО сделай, на фото у тебя там она есть. 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:
Полезу в коробки Нану искать

Из УНО сделай, на фото у тебя там она есть. 

Это не чистая UNO это MassDuino UNO R3 (MD-328D) 

http://roboshop.spb.ru/arduino/MassDuino-UNO-R3-MD-328D

У нее другие библиотеки, с датчиками работает, с mcp2515 вроде тоже но кто знает. Лучше Nano найду. Где то лежала.

Но у нее хорошая стабилизация по питанию выдерживает нагрузку до 1.5А, и входное напряжение до 35В 

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
int0 в меге на 2 пине на 23 вообще ничего на 21 int2

не знаю, вроде на 21 INT0 смотри. Но это тебе не поможет, посмотрел там нет в библе канхакера прерывания, просто пин на вход настраивается и всё - ты это сделал?

riv
Offline
Зарегистрирован: 20.07.2017

Короче заработала. Перезалил скетч с лупом потом без него и пошла. Есть дока на прогу? Как трасер использовать.

Тут версия посвежее но дока скорее автомобильная http://canhacker.ru/%D1%81%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C/

И штука зачетная. Ее удобство в отправке. Просмотр я и в ардуине бы написал прием (DeCoDe) а вот отпарвка через консоль был бы геморой.

Вот нашел минимальное описание 

https://www.drive2.ru/b/2885373/

riv
Offline
Зарегистрирован: 20.07.2017

Вопрос такой. На видео по использовани. CanHacker видно что от вато бегут не только ID и Данные но и Comment

Где они у нас? И как их вставить?

MaksVV
Offline
Зарегистрирован: 06.08.2015

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

По ссылке на сайт  CANHACKER это не авторы этой проги. Её автор вроде немец. Протокол обмена с МК по УАРТ этот называется lawicel. 

По ссылке ребята сначала аппартарную часть сделали для этой проге на СТМ32, сейчас вроде свою прогу хотят выпустить. Парни с Новосиба вроде. Артем автор. Я с ним общался - мудрый чел. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:

Вопрос такой. На видео по использовани. CanHacker видно что от вато бегут не только ID и Данные но и Comment

Где они у нас? И как их вставить?

там можно расшифровывать байты поля данных, либо ASCII либо в DEC, кликай - ставь галку - пойдут параметры

riv
Offline
Зарегистрирован: 20.07.2017

Вот для чего direction нужен был. Нам теперь придется группировать команды по передаче и приему чтобы обрабатывать пин-понг с номером сообщения. С direction сразу понятно какой байт в сообщении анализировать последний или предпоследний а теперь смотрим что за сообщение. Смотрим где то - это отправка или прием. Потом анализирум байт номера сообщений. Так что либо думаем что делать и как упростить или возвращаем назад.

MaksVV
Offline
Зарегистрирован: 06.08.2015

а че сложного если 1 или 3 или 5 отправка 

и 2 , 4 или 6 - приём - не запомнишь?   четное, нечётное получается)))

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
С direction сразу понятно какой байт в сообщении анализировать последний или предпоследний а теперь смотрим что за сообщение. Смотрим где то - это отправка или прием.

надо не так. Если наш адрес стоит в разряде  адрес получателя . То обрабатываем полюбому. 

Смотри как ведь оно получается:

Если видим любой фрейм  - это уже будет 100% отправка)), ведь кто-то этот фрейм отправил, верно? Вопрос кто кому. А вот за это у нас отвечают разряды адресов. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

по идее когда ANSVER эти разряды в ID должны местами меняться МК сидящем на другом конце CAN

Например, МК_56 отправил команду на что либо на МК_48:      0x01564800

 и получил отчет о выполнении команды:                                 0x02485600

где тут отправка? а где приём?  по идее, и там и там, и отпавка и приём, смотря откуда смотреть)

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

а че сложного если 1 или 3 или 5 отправка 

и 2 , 4 или 6 - приём - не запомнишь?   четное, нечётное получается)))

Смотри мое сообщнние #249

Типов будет много больше и они имеют 2 направления

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

riv пишет:
С direction сразу понятно какой байт в сообщении анализировать последний или предпоследний а теперь смотрим что за сообщение. Смотрим где то - это отправка или прием.

надо не так. Если наш адрес стоит в разряде  адрес получателя . То обрабатываем полюбому. 

Смотри как ведь оно получается:

Если видим любой фрейм  - это уже будет 100% отправка)), ведь кто-то этот фрейм отправил, верно? Вопрос кто кому. А вот за это у нас отвечают разряды адресов. 

Супер! Чстно не думал в таком ключе!

MaksVV
Offline
Зарегистрирован: 06.08.2015

всегда когда мы отправляем в CAN сообщение мы адрес получателя ставим сюда 0x0000**00, а наш адрес( отправителя) сюда 0x00**0000. 

Исключение должно быть только, если будем использовать REMOTE FRAME, т.к. опонент должен повторить ID, т.е. мы в запросе уже подменим нарошно адреса местами, чтобы отчет на запрос уже к нам прилетел в правильном виде. 

Например, МК_56 отправил запрос данных на  МК_48:      0xС4485600 // это REMOTE FRAME

 и получил отчет с данными:                                             0x04485600

riv
Offline
Зарегистрирован: 20.07.2017

А я тут о FreeRTOS подумываю.  https://ru.wikipedia.org/wiki/FreeRTOS

Меня на работе програмеры убедили. Есть надстройка и для ардуино. 

Диспетчер (англ. scheduler) системы очень маленький (занимает, в зависимости от платформы и настроек ядра, 4-9 килобайт) и простой, однако позволяет задать различные приоритеты процессоввытесняющую и невытесняющую многозадачностьсемафоры и очереди.

А вот как в ардуине применять.

http://microsin.net/programming/avr/using-freertos-multi-tasking-in-arduino.html

Я ведь не просто так в CAN ушел. А то что это за умный дом где кнопку нажал и ждешь когда да тебя очередь дойдет (это про 485)

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

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

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

MaksVV
Offline
Зарегистрирован: 06.08.2015

ну что отметаем бит direction для CAN отладки? 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

ну что отметаем бит direction для CAN отладки? 

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

riv
Offline
Зарегистрирован: 20.07.2017

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

MaksVV
Offline
Зарегистрирован: 06.08.2015

да хватит нам быстродействия ты чё? это ж тебе не подушки открывать в авто при аварии - доли секунды. Всё, что не медлеенее 50мс, нас устроит. А 500 кбит/с CANa и 16 мгц дуни, я думаю, нам до попы хватит.

MaksVV
Offline
Зарегистрирован: 06.08.2015

вот пока такой Tx()  и Rx(). То, что сёдня намусолили, завтра попрограммируем. 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

да хватит нам быстродействия ты чё? это ж тебе не подушки открывать в авто при аварии - доли секунды. Всё, что не медлеенее 50мс, нас устроит. А 500 кбит/с CANa и 16 мгц дуни, я думаю, нам до попы хватит.

Ну апетит приходит во время еды. Задачи тоже. Потом захотим данные гонять. И пр. 

Тут вопрос скорее не в быстродействии а одновременной обработке нескольких процессов. 

Ладно это еще далекое будущее.

MaksVV
Offline
Зарегистрирован: 06.08.2015

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

Например сообщение по инициативе МК, дак ведь главное, какой функционал у мессаги. Например если это данные, то пофиг как оно по запросу или сам МК прислал, главное чтобы в обработчик данных оно пошло. 

Считаю как раз придумывать типы сообщений нужно по функциональному признаку. 

Про коды неисправностей кстати нужно не забыть. 

riv
Offline
Зарегистрирован: 20.07.2017

Вот с обменом инициативными сообщениями (ты дал команду я выполнил подтвердил) отправить получить все понятно.

Как теперь реализовать периодическую проверку состояния? 

Опрос датчиков.?

Обработку показаний.?

Принятие решений.?

Выдача управляющих воздействий.?

Анализ коректности управляющих воздействий новым опросом датчиков.?

И все это одновременно, да еще не забывая про диагностику, проверку доставки и инициативные сообщения и приоритеты исполнения?

Свет зажечь просто, Протечку поймать тоже. А вот климат это многофакторная система например. Ну как ABS например.

Как без многозадачности то?

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

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

Например сообщение по инициативе МК, дак ведь главное, какой функционал у мессаги. Например если это данные, то пофиг как оно по запросу или сам МК прислал, главное чтобы в обработчик данных оно пошло. 

Считаю как раз придумывать типы сообщений нужно по функциональному признаку. 

Про коды неисправностей кстати нужно не забыть. 

Вот тут как раз не забывай что CAN есть и в DUE и в Raspberry и в Сервере выше

Сейчас 3 типа сообщений

1. Команда запрос-ответ 

2. Датчик запрос-ответ 

3. Статус УЗЛА запрос-ответ 

Куда уж меньше.

Либо давай накидаем все возможные типы а потом выкинем лишнее. У нас может быть 15 типов.

MaksVV
Offline
Зарегистрирован: 06.08.2015

будем надеяться на расторопность считывающей линейчки, бегающей по loop()-у :))

главное вообще delay не применять

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:

Сейчас 3 типа сообщений

1. Команда запрос-ответ 

2. Датчик запрос-ответ 

3. Статус УЗЛА запрос-ответ 

Куда уж меньше.

Либо давай накидаем все возможные типы а потом выкинем лишнее. У нас может быть 15 типов.

это 6 вообще-то. Расскажи, что будет в статусе узла

MaksVV
Offline
Зарегистрирован: 06.08.2015

и по 2 типу Датчик запрос-ответ. Я бы назвал DATA запрос ответ. Нужно поле данных каждого такого фрейма, имхо, полностью заполнять данными, чтобы сообщений поменьше в сети бегало. А то будет на каждый датчик свой ID.  Поэтому может первый разряд 0x000000** сделать не тип устройства, а страница данных например

riv
Offline
Зарегистрирован: 20.07.2017

Ну пока кысли разбегаются но вот примерно так. 

Авария (типы аварий). Ожил после перезагрузки. Готов к прошивке. Перепрошился успешно. Готов к приему команд ....

Я еще подумаю.

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

и по 2 типу Датчик запрос-ответ. Я бы назвал DATA запрос ответ. Нужно поле данных каждого такого фрейма, имхо, полностью заполнять данными, чтобы сообщений поменьше в сети бегало. А то будет на каждый датчик свой ID.  Поэтому может первый разряд 0x000000** сделать не тип устройства, а страница данных например

Да но тогда нужно сразу думать про мултифрейм иначе мне например на 20 датчиков 8 байт (- 2 на номер собщения) не хватит. 1 Фрейм 6 датчиков. А если там 17 однотипных? У меня 2 контроллера обрабатывают освещение на нем повиснет 17 датчиков наличия напряжения и 17 твердотельных реле на управление. Причем нужно будет отследить событие переключение состояние в ручную с выключателя. (Я нажал на выключатель на стене а не с датчика движения или с телефона)

riv
Offline
Зарегистрирован: 20.07.2017

Посмотри на структуру и обменданными в MQTT с ним сопрягаться придется.

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:
Да но тогда нужно сразу думать про мултифрейм иначе мне например на 20 датчиков 8 байт (- 2 на номер собщения) не хватит. 1 Фрейм 6 датчиков. А если там 17 однотипных? У меня 2 контроллера обрабатывают освещение на нем повиснет 17 датчиков наличия напряжения и 17 твердотельных реле на управление. Причем нужно будет отследить событие переключение состояние в ручную с выключателя. (Я нажал на выключатель на стене а не с датчика движения или с телефона)

считаю нафиг пока эти мультифреймы. Поэтому и говорю номер страницы ( а лучше говорить строки по аналогии с таблицей) данных будет в ID заголовке. А поле данных это столбцы таблицы.

Получается 255 строк по 8 столбцов . 2 кБ инфы. За ранее придётся конечно придумать что в каждой ячейке должно лежать. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

в одном фрейме поместиться 64 булевых датчика или 8 датчиков с градацией от 0 до 255

riv
Offline
Зарегистрирован: 20.07.2017

Вот как раз фиксированная таблица и пугает. А завтра я решу изменить аппаратную конфигурацию а меняя протокол не пускает. Не это тупик. Фишка протокола это гибкость. Не нужно затачиваться под твою или мою специфику. Иначе у нас для 20 контроллеров будет 20 дефайнов и 20 разных блоков кода за исключением RX TX. В моем ENUM с адресами просто поменяй названия на свои и вот тебе все работает. Напиши обработчики для типовых датчиков и раздавай всем. Жесткая таблица привязанная к типам датчиков и без шага в право в лево это тупик. 

Я например с конкретными моделями датчиков не определился. И как быть. Структура сети еще до конца не определена и что не обмениваться?

И как мне быть с 17 однотипными датчиками на контроллере которые я могу или последовательно или паралельно в сеть отдать?

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

в одном фрейме поместиться 64 булевых датчика или 8 датчиков с градацией от 0 до 255

Если помниш мы хотели отдавать 2 байта под номер сообщения, так что режем осетра

48 bool и 6 byte

MaksVV
Offline
Зарегистрирован: 06.08.2015

дак у тебя в ENUM теже адреса, меняя название в ENUM на этом адресе будет уже другой параметр. 

В таблице также адреса. Просто нужно граммотно создать систему адресов для параметров и пользоваться ей. 

17 датчиков передашь в трёх фреймах, какие проблемы. 

MaksVV
Offline
Зарегистрирован: 06.08.2015

riv пишет:

MaksVV пишет:

в одном фрейме поместиться 64 булевых датчика или 8 датчиков с градацией от 0 до 255

Если помниш мы хотели отдавать 2 байта под номер сообщения, так что режем осетра

48 bool и 6 byte

а цель? я забыл. если только counter сделать для того чтобы видеть активность МК, то одного байта хватит

MaksVV
Offline
Зарегистрирован: 06.08.2015

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

- кадр мульти или нет

- сколько будет кадров, если мульти

- данный №кадра в мультикадре. 

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

Только как тут быть с адресацией булевых датчиков, которые я хочу по 8 штук в байты запихивать

riv
Offline
Зарегистрирован: 20.07.2017

>> а цель? я забыл. если только counter сделать для того чтобы видеть активность МК, то одного байта хватит

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

MaksVV
Offline
Зарегистрирован: 06.08.2015

del

MaksVV
Offline
Зарегистрирован: 06.08.2015

MaksVV пишет:

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

- кадр мульти или нет

- сколько будет кадров, если мульти

- данный №кадра в мультикадре. 

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

Только как тут быть с адресацией булевых датчиков, которые я хочу по 8 штук в байты запихивать

продолжая эту тему. Бит который мы освободили direction, назовём MULTI_FRAME, если он в единичке то данный фрейм - член серии фреймов.  Вот теперь, где можно использовать FRAME_REMOTE. Последним кадром в серии, МК шлёт этот FRAME_REMOTE, который явлется маркером того, что мультифрейм окончен.  

Собственно, при таком подходе, нам не нужно знать порядковый номер кадра в серии и сколько всего будет кадров в серии. При приёме мы ставим флаг, что начат приём мультика. Начинаем принимать кадры , после каждого кадра, включая таймер. Если по истечение таймера не пришел следующий кадр серии или не пришёл маркер  конца мультика - записываем код неисправности.

если получили маркер конца мультика (FRAME_REMOTE) - приём серии кадров закончен. 

Последнии разряд ID 0х000000** предалагаю сделать тип данных (булевые, одно-, двух-, 4-байтовые). 

В зависимости от этого будет происходить адресация данных в поле данных 

riv
Offline
Зарегистрирован: 20.07.2017

MaksVV пишет:

Последним кадром в серии, МК шлёт этот FRAME_REMOTE, который явлется маркером того, что мультифрейм окончен.  

Со всем согласен кроме FRAME_REMOTE

В спецификации CAN сказано

Remote Frame - это Data Frame без поля данных и с выставленным битом RTR (1 - рецессивные бит). Основное предназначение Remote кадра - это инициация одним из узлов сети передачи в сеть данных другим узлом. Такая схема позволяет уменьшить суммарный трафик сети. Однако, на практике Remote Frame сейчас используется редко (например, в DeviceNet Remote Frame вовсе не используется).

Давай огород не городить. Назначение специфицировано. 

Я бы потом Remote Frame использовал например для запроса готовности начать перепрошивку и для передергивания, помнишь 485 обсуждали.