Arduino.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

http://arduino.ru/Reference/AttachInterrupt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

48 bool и 6 byte

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

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

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

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

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

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

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

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

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

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

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

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

del

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

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

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

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

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

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

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

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

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

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