тип данных параметров в массиве содержится в нулевом элементе первого измерения массива
т.е. #define TYPE_VAR 0
правильно ты показал для air_t это BYTE_1_SIGNED. При отправке по CAN эта инфа (тип данных) будет содержаться в фрейме и приёмник соответствующим образом интерпретирует этот параметр.
Параметр отсылается на один выбранный узел по изменению или периодически, в зависимости от того, что наступит раньше. На ещё один узел я не сделал возможности так отправлять параметры. НО, если какому то узлу нужен параметр - он может запросить у нашего узла и наш узел ему ответит этим параметром. (Сообщение - запрос параметра).
Параметр отсылается на один выбранный узел по изменению или периодически, в зависимости от того, что наступит раньше. На ещё один узел я не сделал возможности так отправлять параметры. НО, если какому то узлу нужен параметр - он может запросить у нашего узла и наш узел ему ответит этим параметром. (Сообщение - запрос параметра).
Можно ( и это в принципе не сложно) добавить в код, чтобы был выбор - чтобы на ещё один узел отправлять параметры. Т.е. в целом будут выбирается два адреса, на которые будут передаваться параметры периодически или по изменению (смотря что наступит раньше).
А если нужно больше узлов, то проще уж широковещательное сообщение делать, из которого все кому надо возмут инфу. Так и шина меньше нагружаться будет.
судя о канхакингу , ты сначала видимо отправлял команды id 11xxxxxx,соответственно потом приходили отчеты о командах - id 12xxxxxx. а все что ниже (id начинается c 14xxxxxx) это периодически узлы отправляют свои параметры на мастер и узел 21 (15h). Смотри там в can_struct.h я специально отправку одного параметра поставил не на мастер, а на узел 21.
судя о канхакингу , ты сначала видимо отправлял команды id 11xxxxxx,соответственно потом приходили отчеты о командах - id 12xxxxxx. а все что ниже (id начинается c 14xxxxxx) это периодически узлы отправляют свои параметры на мастер и узел 21 (15h). Смотри там в can_struct.h я специально отправку одного параметра поставил не на мастер, а на узел 21.
Так что всё гуд.
Я про это говорю, команды не отправлял. Все само. (Либо как вариант сыпется мусор из web потра 8266) К этому и спрашивал. Надо думаю test везде кроме мастера отключить.
И еще глобальная просба, на тему структуризации кодо и его наследования. Просьба переделать немного основной файл и System_Functions следующим образом:
Выделить отдельно
main_init в него настройка сериала, версий и пр. общего
can_init (у тебя CAN_Start и MCP2515_Init )
Это нужно чтобы разделить и мне потом не встраивать через ж свой код
смотри в can_struct.h - так настроена периодическая передача первого параметра (air_t) - широковещательно. Этим я проверял в это :
MaksVV пишет:
Можно ( и это в принципе не сложно) добавить в код, чтобы был выбор - чтобы на ещё один узел отправлять параметры. Т.е. в целом будут выбирается два адреса, на которые будут передаваться параметры периодически или по изменению (смотря что наступит раньше). А если нужно больше узлов, то проще уж широковещательное сообщение делать, из которого все кому надо возмут инфу. Так и шина меньше нагружаться будет.
Нашёл довольно серьезный косяк. При периодической отправке параметров , весь список перебирается в цикле for. В теле цикла нет delay. Поэтому сообщения из списка от ардуины долбят в MCP2515 с большой скоростью. Опытным путём установил, что не все сообщения из списка передаются. Поставил delay (5). Стало всё гуд. Возможно из - за этого шина глючила. Что слишком маленькое было время между отправками соседних сообщений.
15 версия, это исправлено. Также добавил выбор автоматической отправки параметров ещё на один узел. (т.е. в целом 2 )
мне по твоим последним логам не нравятся некорые узлы. В отладке пишется что статус от мастера принят, а отсылка своего статуса сразу за ним не пишется, т.е. может подрят несколько принять потом только свой отсылает. Такого быть никак не должно.
Или обратная проблема. Получения статусов от мастера в отладке нет, а свой статус отсылает . Причём в эти моменты узел мастером расценивается как ОК!. Вот с этим непонятки. Как будто тут сама дуня глючит и чё то с памятью.
А есть узлы (14 вроде) где вообще в отладке фразы на половину обрываются - явный признак нарушения памяти.
Вот эти косяки как раз указавают, что проблема софтовая.
Я только 15 залил. И проблема то не в сбое сети, которая блуждающая! То сутки стоит без проблем то опять повылазило сразу.
Проблема в рестарте по SPI как я почитал на буржуинских форумах, народ с этой проблемой сталкивался. Нужно ничего не передавать на MSP по SPI после ресета 128 тактов или 50-100мс (кто что пишет)
рестарт вообще не должен происходить, ну может совсем редко. А судя по логам, у тебя едва едва fail не выскакивало. Некоторые узлы с ума сходили. И кстати у нас delay (100) есть. Ну сделай 200.
рестарт вообще не должен происходить, ну может совсем редко. А судя по логам, у тебя едва едва fail не выскакивало. Некоторые узлы с ума сходили. И кстати у нас delay (100) есть. Ну сделай 200.
Ну выходные то после перепайки исправили ситуацию, и вчера стояли норм (правда на 125)
мне по твоим последним логам не нравятся некорые узлы. В отладке пишется что статус от мастера принят, а отсылка своего статуса сразу за ним не пишется, т.е. может подрят несколько принять потом только свой отсылает. Такого быть никак не должно.
Или обратная проблема. Получения статусов от мастера в отладке нет, а свой статус отсылает . Причём в эти моменты узел мастером расценивается как ОК!. Вот с этим непонятки. Как будто тут сама дуня глючит и чё то с памятью.
А есть узлы (14 вроде) где вообще в отладке фразы на половину обрываются - явный признак нарушения памяти.
Вот эти косяки как раз указавают, что проблема софтовая.
Поэтому и надо залить простой скетч и проверить.
Это проблема Wi-Fi вывода лога, я заметил что через Wi-Fi/IP/Serial лог идет с потерями. Через Web все нормально но там буфер маленький. Я лог снимаю через esp-link это проброс serial через wi-fi esp8266
да уж, вифи с одной стороны облегчил жись, а с другой... Как бы ещё не было проблем с корявой заливкой hex файла по воздуху. Хотя там верификация какаянибудь должна быть .
да уж, вифи с одной стороны облегчил жись, а с другой... Как бы ещё не было проблем с корявой заливкой hex файла по воздуху. Хотя там верификация какаянибудь должна быть .
таймаут я тоже у себя 100 поставил.
Я проблемы не вижу, он нужен для прошивки и MQTT а вот такие ОЖИДАЕМЫЕ потери и задержки как раз и покажывают место радио в системе автоматизации ;-) (А потери пулеметной ленты лога да еще через эмулятор Win telnet serial это не проблема, это норма. Кстати я прошиваю все только c linux машины, из под Win вообще не пошло)
кстати у меня тут возникла очень здравая идея. адрес узла сохранить каждому в еепром . И при старте скетча адрес будет читаться. Таким образом на этапе тестирования (пока у всех узлов скетч одинаковый) - тебе не нужно будет создавать кучу папок скетчей с разными узлами. Один скетч льешь во все узлы и всё. Естественно предварительно нужно один раз забить в еепром адрес на каждый узел.
Так у тебя уменьшится время на заливку ПО всех узлов.
Вот это сделано в версии 16. Почитаешь, всё поймешь в первой вкладке, там минимум изменений.
Кстати, обнаружил что нет блокировки отправки самому себе и приема своего же броадкаста
По простому в RX отсечь, а по хорошему фильтр придумать для своего бордкаста, а на передачу самому себе внутри TX если rem_adr==dev_adr то return ;)
Постоянно шлют
21->21
19->19
Честно, я вообще перестал понимать логику программы. По какому алгоритму идет рассылка я смотрю в канхаекр и просто диву даюсь что происходит в сети.
Почему например остальные сами себе не шлют, почему типы сообщений не совпадают.
если отправка самому себе реально произошла с нашего MCP2515 то на приёмник она не попадёт. (по стандарту CAN шины сообщения из передатчика не попадают на приёмник).
Отправки самому себе и свои же бродкасты быть не должны, ну допустим что будут (какой то другой узел глюкнул и от нашего имени нам отправил), но не часто, поэтому проще программно В RX() сделать блокировку.
Ты спрашивал про алгоритм. Он очень простой :
У мастера: каждую секунду шлём бродкаст.
У узла: получил от мастера бродкаст - отправил свой статус мастеру.
Также периодически (в секунду равную адресу) отправляем на настроенный узел параметры.
кстати у меня тут возникла очень здравая идея. адрес узла сохранить каждому в еепром . И при старте скетча адрес будет читаться. Таким образом на этапе тестирования (пока у всех узлов скетч одинаковый) - тебе не нужно будет создавать кучу папок скетчей с разными узлами. Один скетч льешь во все узлы и всё. Естественно предварительно нужно один раз забить в еепром адрес на каждый узел.
Так у тебя уменьшится время на заливку ПО всех узлов.
Вот это сделано в версии 16. Почитаешь, всё поймешь в первой вкладке, там минимум изменений.
Честно, я вообще перестал понимать логику программы. По какому алгоритму идет рассылка я смотрю в канхаекр и просто диву даюсь что происходит в сети.
Почему например остальные сами себе не шлют, почему типы сообщений не совпадают.
Ты спрашивал про алгоритм. Он очень простой :
У мастера: каждую секунду шлём бродкаст.
У узла: получил от мастера бродкаст - отправил свой статус мастеру.
Также периодически (в секунду равную адресу) отправляем на настроенный узел параметры.
Про запрос и ответ статуса узла на бродкаст от мастера понятно мастрер шлет на 0, узлы отвечают на 4
Вопрос в другом кому и где это прописано узел шлет параметры. Я не понимаю как залитый один и тот же код с отличием в имени узла начинает слать почему то разным узлам.
Я бы понял что все бы слали мастеру, на 00, и например 10, но ведь не так 0,4,19,21 Где это прописано?
Ограничение циклов 100 000 операций записи это даже если делать 10 записей в день хватит на 10 000 дней т.е примерно на 27 лет.
А нам нужно раз записать и потом при отладке перезаписывать иногда.
ты про параметры говорил. Я думал ты про массив parameter[][] - он то часто обновляется. А ты про другие настройки типа скорости шины и т.д. Их то да конечно в еепром тоже можно записывать.
// НИЖЕ УКАЗЫВАЕМ АДРЕС первого УЗЛА, КУДА ПЕРИОДИЧЕСКИ ИЛИ ПО ИЗМЕНЕНИЮ БУДЕТ ПОСЫЛАТЬСЯ КОНКРЕТНЫЙ ПАРАМЕТР, если 0xFF, то никому данный параметр не отсылается
для каждого параметра в отдельности выбирается узел, на который будет посылаться этот параметр периодически или по изменению. Начиная с 15 версии, можно для каждого параметра выбирать два узла, на которые он будет отсылаться
адрес, скорость шины, IP адреса, мастер/слейв/узел, debug и его ключи и пр. даже пока не придумывается.
с адресом , скоростью шины, IP адреса это да, но вот мастер/слейв/узел, debug и его ключи у нас же делаются с помощью директив условной компиляции и этот выбор происходит ещё когда скетч не в узле, а при компиляции, т.е. твой НЕХ файл когда создаётся. Сделать то можно будет, но всё через флаги только, а это память расходует.
и какой смысл эти данные держать в еепром, когда их как раз и нужно изменять при необходимости. А так они всё время из еепром одни и теже будут грузиться, без возможности выбора.
debug и его ключи у нас же делаются с помощью директив условной компиляции и этот выбор происходит ещё когда скетч не в узле, а при компиляции, т.е. твой НЕХ файл когда создаётся. Сделать то можно будет, но всё через флаги только, а это память расходует.
и какой смысл эти данные держать в еепром, когда их как раз и нужно изменять при необходимости. А так они всё время из еепром одни и теже будут грузиться, без возможности выбора.
Согласен. Тогда и мастер/слейв/узел тоже нет смысла (или в прошивке держать оба кода и узла и мастера ).
Ну в общем я про смысл прошивки.
Тем более что с таким набором и возможностью хранить произвольные типы. И вот в серьез подумать именно про твои настройки на епром byte parameter [6][parameters_quantity]
Тогда и мастер/слейв/узел тоже нет смысла (или в прошивке держать оба кода и узла и мастера ).
смысл в том чтобы, всё не подгружать в ОЗУ. В последствии на мастере можно сделать хранилище параметров от всех узлов. И тогда для остального места уже не остаётся. Поэтому для мастера нужен отдельный код. Тем более узлы можно не меги делать, а наны например, а у них памяти мало, поэтому нужны компактные скетчи для узлов.
Не вижу смысла грузить настройки parameter[][] в еепром
Не вижу смысла грузить настройки parameter[][] в еепром
Жаль, я в любом случае уникальные параметры каждого контроллера не зависящие от кода, в смысле перечень устройств, их адреса, куда направлять сообщения, у кого запрашивать и брать параметы положу в епром.
Просто это было бы красиво код одинаковый и отлаженый. Прошил епром подключил на универсальный разъем расширитель к которому подключил нужные датчики и ИУ. И вперед.
ну как ты тестировал стабильность v15 или v16 или может простой скетч #965 заливал?
Не я прежде чем "превращать в кирпич" ;-) т.е. писать в энергонезависимую память изучал вопрос, завтра соберу, прошью везде епром и залью 16 версию на 125к, я просто хочу сделать возможность через консоль дать команду на изменение скорости шины путем записи в епром и ресета. На подобе твоей test
путаться будешь, тут вот оно в скетче, правишь когда надо. А там в еепроме как посмотреть, что залито? И где он одинаковый код. На одном узле, например, используется 3 параметра, а на другом - 23. В основном скетче проще всё менять, чем еепром прошивать отдельным скетчем. Еепром считаю нужен как энергонезависимая память.
смысл в том чтобы, всё не подгружать в ОЗУ. В последствии на мастере можно сделать хранилище параметров от всех узлов. И тогда для остального места уже не остаётся. Поэтому для мастера нужен отдельный код. Тем более узлы можно не меги делать, а наны например, а у них памяти мало, поэтому нужны компактные скетчи для узлов.
Смотри, сеть стационарная, все на кабелях, какова Вероятность что ды доподключишь в последствии что то помимо уже установленного. Правильно, никакая. Тогда зачем делать централизованное хранилище конфига? Прошил в епром все типы подключенных датчиков, ИУ и все. В зависимости от этого инициируешь переменные.
А работать с наной я честно не готов, тогда уж при этом формфакторе есть 32 разрадные с памятью. А лучше тогда сразу ESP32.
путаться будешь, тут вот оно в скетче, правишь когда надо. А там в еепроме как посмотреть, что залито? И где он одинаковый код. На одном узле, например, используется 3 параметра, а на другом - 23. В основном скетче проще всё менять, чем еепром прошивать отдельным скетчем. Еепром считаю нужен как энергонезависимая память.
Тогда будет, по крайней мере в моем случае минимум 15 скетчей для узлов на меге, 2 мастер слейв на DUE.
Для всех нужно иметь свой разный конфиг и нигде не ошибиться. Я не просто так помнишь начинал с очень простых и читаемых типов у-в и ИУ.
Узлы у меня практически типовые с небольшими отличиями.
Ну на самом деле нужно подумать еще. Это не окончательное решение. Но уж больно идея заманчивая. Кстати чтобы не писать все время в процессе отладки можно эмулятор простой сделать читать не из памати а из файла ну типо ф-ю EEPROM1 с теми же вызовани сделать на время отладки.
Прошил в епром все типы подключенных датчиков, ИУ и все. В зависимости от этого инициируешь переменные.
блин ну не пойму я смысла. Это всё и так лежит в энергонезависимой памяти, которая называется флеш. В ней залит скетч. В скетче есть эта информация. Дак нафига её в еепром то пихать? В том то и дело, если ты ничего подключать дополнительно не собираешься вообще не имеет смысла в еепром пихать. Т.к. туда пихается обычно изменяемая инфа. А постоянная она из флеша (скетча) спокойно также грузится.
1. Код для обработки датчиков кидаю в файл Update_Parameters
int bme_temp() {}
int bme_hum() {}
int bme_pres() {}
2.
parameter [PARAMETER][param_addr (air_t)] = bme_temp();
parameter [PARAMETER][param_addr (air_h)] = bme_hum();
parameter [PARAMETER][param_addr (air_p )] = bme_pres();
С этим вроде понятно
а вот дальше типы параметров в byte parameter [5][parameters_quantity] нигде не описаны.
И как соотносится
#define air_t 1 //датчик температуры
BYTE_1_SIGNED, //1 //датчик температуры
1, //1 //датчик температуры
и как сделать чтоб ы температура отсылалась не только node_4_Net_center_Due1, //1 //датчик температуры
но и например
node_1_Net_center_PC, //1
node_2_Net_center_oraPi1, //2
И как понять отправка будет периодическая или по изменению параметра (где это указать)
1. Функции лучше делать чтобы тип данных был однобайтовый, например byte (для беззнаковых) или int8_t для знаковых. Примерно так
1int8_t bme_temp() {}23bytebme_hum() {}45bytebme_pres() {}2. Надо так
1parameter [PARAMETER][param_addr (air_t)] = (byte) bme_temp();23parameter [PARAMETER][param_addr (air_h)] = (byte) bme_hum();45parameter [PARAMETER][param_addr (air_p )] = (byte) bme_pres();тип данных параметров в массиве содержится в нулевом элементе первого измерения массива
т.е. #define TYPE_VAR 0
правильно ты показал для air_t это BYTE_1_SIGNED. При отправке по CAN эта инфа (тип данных) будет содержаться в фрейме и приёмник соответствующим образом интерпретирует этот параметр.
Параметр отсылается на один выбранный узел по изменению или периодически, в зависимости от того, что наступит раньше. На ещё один узел я не сделал возможности так отправлять параметры. НО, если какому то узлу нужен параметр - он может запросить у нашего узла и наш узел ему ответит этим параметром. (Сообщение - запрос параметра).
Можно ( и это в принципе не сложно) добавить в код, чтобы был выбор - чтобы на ещё один узел отправлять параметры. Т.е. в целом будут выбирается два адреса, на которые будут передаваться параметры периодически или по изменению (смотря что наступит раньше).
А если нужно больше узлов, то проще уж широковещательное сообщение делать, из которого все кому надо возмут инфу. Так и шина меньше нагружаться будет.
версия 14.
- Добавил в отладку версию скетча, скорость шины, инфу что именно было рестарт mcp2515 и/или ардуино.
- исправил небольшой косяк с запросом параметра от другого узла.
версия 14.
- Добавил в отладку версию скетча, скорость шины, инфу что именно было рестарт mcp2515 и/или ардуино.
- исправил небольшой косяк с запросом параметра от другого узла.
Есть вопрос, я канхакером увидел что узлы произвольно обмениваются параметрами, хотя код одинаковый и везде стоит отправлять к 4. Как это поправить.
001ID DLC Data Period Count Comment00211090A01 5 77 00 00 0C 2D 410 65 9->1000311090A02 5 76 00 00 0B 14 171 45 9->10004110A0A01 5 35 00 00 00 00 50 140 10->10005110A0A02 5 33 00 00 0B 14 178 115 10>10006110B0A01 5 C5 00 00 0C 2D 140 364 11>10007110B0A02 5 C4 00 00 0B 14 424 426 11->1000811130A01 5 30 00 00 00 00 81 209 19->1000911130A02 5 31 00 00 0B 14 400 202 19->1001012085509 0 0 1011120A0901 5 77 00 01 0C 2D 177 51 10->9012120A0902 5 76 00 01 0B 14 174 39 10->9013120A0B01 5 C5 00 01 0C 2D 161 300 10->11014120A0B02 5 C4 00 01 0B 14 415 359 10->11015120A1301 5 30 00 06 00 00 80 169 10->19016120A1302 5 31 00 01 0B 14 363 164 10->19017120B0101 5 C0 00 01 01 01 0 1 11->1018120B0121 5 04 00 08 00 01 0 1019120B0303 5 C0 00 01 01 01 0 1 11->3020120BB8B8 5 B8 00 01 01 01 0 1 11>??02114050401 5 09 00 09 08 00 124 773 5->402214050402 5 0A 00 09 01 00 124 735 5->402314050403 5 F3 00 09 01 00 64 725 5->402414050405 5 0C 00 09 01 00 125 735 5->402514050406 5 0D 00 09 01 00 125 741 5->40261405040E 5 0E 00 09 08 00 125 750 5->402714050434 8 0F 00 09 04 00 00 00 00 125 740 5->402814051538 8 10 00 09 09 00 00 00 00 125 724 5->2102914060401 5 F9 00 09 08 00 127 763 6->403014060402 5 FA 00 09 01 00 127 763 6->403114060403 5 FB 00 09 01 00 127 763 6->403214060405 5 FC 00 09 01 00 126 763 6->403314060406 5 FD 00 09 01 00 126 763 6->40341406040E 5 FE 00 09 08 00 126 754 6->403514060434 8 FF 00 09 04 00 00 00 00 126 750 6->403614061538 8 00 00 09 09 00 00 00 00 127 758 6->2103714070401 5 D1 00 09 08 00 125 759 7->403814070402 5 D2 00 09 01 00 125 758 7->403914070403 5 D3 00 09 01 00 125 758 7->404014070405 5 D4 00 09 01 00 124 758 7->404114070406 5 D5 00 09 01 00 124 758 7->40421407040E 5 D6 00 09 08 00 124 755 7->404314070434 8 D7 00 09 04 00 00 00 00 124 755 7->404414071538 8 D8 00 09 09 00 00 00 00 125 750 7->2104514080401 5 01 00 09 08 00 126 758 8->404614080402 5 02 00 09 01 00 126 758 8->404714080403 5 03 00 09 01 00 126 758 8->404814080405 5 04 00 09 01 00 126 758 8->404914080406 5 05 00 09 01 00 126 758 8->40501408040E 5 06 00 09 08 00 126 756 8->405114080434 8 07 00 09 04 00 00 00 00 126 747 8->405214081538 8 08 00 09 09 00 00 00 00 127 750 8->2105314090401 5 E9 00 09 08 00 122 762 9->405414090402 5 EA 00 09 01 00 124 762 9->405514090403 5 EB 00 09 01 00 123 761 9->405614090405 5 EC 00 09 01 00 124 759 9->405714090406 5 ED 00 09 01 00 124 761 9->40581409040E 5 EE 00 09 08 00 62 753 9->405914090434 8 EF 00 09 04 00 00 00 00 62 744 9->406014091538 8 F0 00 09 09 00 00 00 00 60 742 9->21061140A0401 5 51 00 09 08 00 70 768 10->4062140A0402 5 52 00 09 01 00 65 762 10->4063140A0403 5 53 00 09 01 00 63 762 10->4064140A0405 5 54 00 09 01 00 64 754 10->4065140A0406 5 55 00 09 01 00 64 751 10->4066140A040E 5 56 00 09 08 00 65 750 10->4067140A0434 8 57 00 09 04 00 00 00 00 59 745 10->4068140A1538 8 58 00 09 09 00 00 00 00 63 736 10->21069140B0401 5 01 00 09 08 00 60 762 11->4070140B0402 5 02 00 09 01 00 60 762 11->4071140B0403 5 03 00 09 01 00 60 762 11->4072140B0405 5 04 00 09 01 00 61 759 11->4073140B0406 5 05 00 09 01 00 60 761 11->4074140B040E 5 06 00 09 08 00 62 754 11->4075140B0434 8 07 00 09 04 00 00 00 00 61 694 11->4076140B1538 8 08 00 09 09 00 00 00 00 61 704 11->21077140C0401 5 F9 00 09 08 00 62 765 12->4078140C0402 5 FA 00 09 01 00 62 764 12->4079140C0403 5 FB 00 09 01 00 62 764 12->4080140C0405 5 FC 00 09 01 00 62 764 12->4081140C0406 5 FD 00 09 01 00 62 765 12->4082140C040E 5 FE 00 09 08 00 62 761 12->4083140C0434 8 FF 00 09 04 00 00 00 00 62 750 12->4084140C1538 8 00 00 09 09 00 00 00 00 63 758 12->21085140D0401 5 11 00 09 08 00 64 767 13->4086140D0402 5 12 00 09 01 00 64 768 13->4087140D0403 5 13 00 09 01 00 64 767 13->4088140D0405 5 14 00 09 01 00 64 767 13->4089140D0406 5 15 00 09 01 00 63 767 13->4090140D040E 5 16 00 09 08 00 63 766 13->4091140D0434 8 17 00 09 04 00 00 00 00 63 754 13->4092140D1538 8 18 00 09 09 00 00 00 00 64 764 13->21093140E0401 5 F1 00 09 08 00 62 763 14->4094140E0402 5 F2 00 09 01 00 62 763 14->4095140E0403 5 F3 00 09 01 00 62 763 14->4096140E0405 5 F4 00 09 01 00 62 763 14->4097140E0406 5 F5 00 09 01 00 62 763 14->4098140E040E 5 F6 00 09 08 00 63 763 14->4099140E0434 8 F7 00 09 04 00 00 00 00 62 750 14->4100140E1538 8 F8 00 09 09 00 00 00 00 62 755 14->21101140F0401 5 F9 00 09 08 00 67 764 15->4102140F0402 5 FA 00 09 01 00 67 764 15->4103140F0403 5 FB 00 09 01 00 67 765 15->4104140F0405 5 FC 00 09 01 00 67 764 15->4105140F0406 5 FD 00 09 01 00 67 764 15->4106140F040E 5 FE 00 09 08 00 67 760 15->4107140F0434 8 FF 00 09 04 00 00 00 00 67 761 15->4108140F1538 8 00 00 09 09 00 00 00 00 67 760 15->2110914120401 5 F9 00 09 08 00 63 763 18->411014120402 5 FA 00 09 01 00 63 760 18->411114120403 5 FB 00 09 01 00 63 765 18->411214120405 5 FC 00 09 01 00 63 763 18->411314120406 5 FD 00 09 01 00 63 764 18->41141412040E 5 FE 00 09 08 00 62 762 18->411514120434 8 FF 00 09 04 00 00 00 00 63 752 18->411614121538 8 00 00 09 09 00 00 00 00 62 760 18->2111714130401 5 09 00 09 08 00 70 766 19->411814130402 5 0A 00 09 01 00 70 766 19->411914130403 5 0B 00 09 01 00 70 766 19->412014130405 5 0C 00 09 01 00 70 767 19->412114130406 5 0D 00 09 01 00 70 767 19->41221413040E 5 0E 00 09 08 00 70 762 19->412314130434 8 0F 00 09 04 00 00 00 00 70 758 19->412414131538 8 10 00 09 09 00 00 00 00 70 760 19->2112514140401 5 E9 00 09 08 00 57 762 20->412614140402 5 EA 00 09 01 00 57 762 20->412714140403 5 EB 00 09 01 00 57 762 20->412814140405 5 EC 00 09 01 00 58 762 20->412914140406 5 ED 00 09 01 00 56 762 20->41301414040E 5 EE 00 09 08 00 56 759 20->413114140434 8 EF 00 09 04 00 00 00 00 56 753 20->413214141538 8 F0 00 09 09 00 00 00 00 56 757 20->2113314150401 5 09 00 09 08 00 62 766 21->413414150402 5 0A 00 09 01 00 62 766 21->413514150403 5 0B 00 09 01 00 63 766 21->413614150405 5 0C 00 09 01 00 63 766 21->413714150406 5 0D 00 09 01 00 64 766 21->41381415040E 5 0E 00 09 08 00 64 764 21->413914150434 8 0F 00 09 04 00 00 00 00 64 757 21->414014151538 8 10 00 09 09 00 00 00 00 63 765 21->21судя о канхакингу , ты сначала видимо отправлял команды id 11xxxxxx,соответственно потом приходили отчеты о командах - id 12xxxxxx. а все что ниже (id начинается c 14xxxxxx) это периодически узлы отправляют свои параметры на мастер и узел 21 (15h). Смотри там в can_struct.h я специально отправку одного параметра поставил не на мастер, а на узел 21.
Так что всё гуд.
судя о канхакингу , ты сначала видимо отправлял команды id 11xxxxxx,соответственно потом приходили отчеты о командах - id 12xxxxxx. а все что ниже (id начинается c 14xxxxxx) это периодически узлы отправляют свои параметры на мастер и узел 21 (15h). Смотри там в can_struct.h я специально отправку одного параметра поставил не на мастер, а на узел 21.
Так что всё гуд.
Я про это говорю, команды не отправлял. Все само. (Либо как вариант сыпется мусор из web потра 8266) К этому и спрашивал. Надо думаю test везде кроме мастера отключить.
001ID DLC Data Period Count Comment00211090A01 5 77 00 00 0C 2D 410 65 9->1000311090A02 5 76 00 00 0B 14 171 45 9->10004110A0A01 5 35 00 00 00 00 50 140 10->10005110A0A02 5 33 00 00 0B 14 178 115 10>10006110B0A01 5 C5 00 00 0C 2D 140 364 11>10007110B0A02 5 C4 00 00 0B 14 424 426 11->1000811130A01 5 30 00 00 00 00 81 209 19->1000911130A02 5 31 00 00 0B 14 400 202 19->1001012085509 0 0 1011120A0901 5 77 00 01 0C 2D 177 51 10->9012120A0902 5 76 00 01 0B 14 174 39 10->9013120A0B01 5 C5 00 01 0C 2D 161 300 10->11014120A0B02 5 C4 00 01 0B 14 415 359 10->11015120A1301 5 30 00 06 00 00 80 169 10->19016120A1302 5 31 00 01 0B 14 363 164 10->19017120B0101 5 C0 00 01 01 01 0 1 11->1018120B0121 5 04 00 08 00 01 0 1019120B0303 5 C0 00 01 01 01 0 1 11->3Скажи плиз какая комбинация ключей дебага отключает это (за 2 секунды налетело)
1Разобрался. Просто ты каждый раз меняешь имена переменных.И еще глобальная просба, на тему структуризации кодо и его наследования. Просьба переделать немного основной файл и System_Functions следующим образом:
Выделить отдельно
main_init в него настройка сериала, версий и пр. общего
can_init (у тебя CAN_Start и MCP2515_Init )
Это нужно чтобы разделить и мне потом не встраивать через ж свой код
Хотелось бы в основном файле получить
в setup
main_init can_init ethernet_init web_init wi-fi_init mqtt_init device_init
в loop (это например)
main_loop can_loop ethernet_loop web_loop wi-fi_loop mqtt_loop device_loop
И на выходе я сделаю
файлы - Ethernet.ino, Web.ini, Wi-Fi.ino, Mqtt.ino
Device.ino (у тебя это Update_Parametrs.ino) если хочешь можно оставить и так но вроде логичнее
Чтобы у нас получилось что я в основной файл вложу только выховы фиксированных функций и их #define
да, скороее всего это происходит из-за функции test. отключай её.
Так и еще начали в канхакере в последней версии лететь вот такие фреймы
14060001 14070001 .... 14150001 Зачем узел шлет что то на 00?
Увы опять сбой, ресет не сработал
00100:02:37:00002NODES CAN COMMUNICATION:003node_5_Net_center_Due2 OK!!!004node_6_Hallway_net_center OK!!!005node_7_Hallway_main OK!!!006node_8_Hallway_light OK!!!007node_9_Kitchen_net_center OK!!!008node_10_Kitchen_main OK!!!009node_11_Kitchen_light OK!!!010node_12_WC_main OK!!!011node_13_WC_waterleak OK!!!012node_14_Bathroom_main OK!!!013node_15_Boxroom_main OK!!!014node_18_Loggia_recuperator OK!!!015node_19_Livingroom_main OK!!!016node_20_Bedroom_main OK!!!017node_21_Cabinet_main OK!!!01801900:02:37:30020NODES CAN COMMUNICATION:021node_5_Net_center_Due2 OK!!!022node_6_Hallway_net_center OK!!!023node_7_Hallway_main OK!!!024node_8_Hallway_light OK!!!025node_9_Kitchen_net_center OK!!!026node_10_Kitchen_main OK!!!027node_11_Kitchen_light OK!!!028node_12_WC_main OK!!!029node_13_WC_waterleak OK!!!030node_14_Bathroom_main OK!!!031node_15_Boxroom_main OK!!!032node_18_Loggia_recuperator OK!!!033node_19_Livingroom_main OK!!!034node_20_Bedroom_main OK!!!035node_21_Cabinet_main OK!!!03603700:02:37:33 Принято из CAN: NULL_C От Кого: Неизвестный адрес - ID 801B0C0703803900:02:37:33 Принято из CAN: NULL_C От Кого: Неизвестный адрес - ID 801B0C0704004100:02:37:33 Принято из CAN: NULL_C От Кого: ШИРОКОВЕЩАТЕЛЬНО - ID 0042Error Initializing MCP2515...043044РЕСТАРТ MCP251504504600:02:37:33 Принято из CAN: NULL_C От Кого: ШИРОКОВЕЩАТЕЛЬНО - ID 0047Error Initializing MCP2515...048049РЕСТАРТ MCP2515050051Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A04010A 20052053Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A04010B 21054055Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A04010C 22056057Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A04010D 23058059Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A04010E 24060061Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A04010F 25062063Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040112 26064065Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040113 27066067Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040114 28068069Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040115 29070071Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040105 2A072073Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040106 2B074075Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040107 2C076077Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040108 2D078079Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040109 2E08008100:02:38:00082NODES CAN COMMUNICATION:083node_5_Net_center_Due2 FAIL!!!084node_6_Hallway_net_center FAIL!!!085node_7_Hallway_main FAIL!!!086node_8_Hallway_light FAIL!!!087node_9_Kitchen_net_center FAIL!!!088node_10_Kitchen_main FAIL!!!089node_11_Kitchen_light FAIL!!!090node_12_WC_main FAIL!!!091node_13_WC_waterleak FAIL!!!092node_14_Bathroom_main FAIL!!!093node_15_Boxroom_main FAIL!!!094node_18_Loggia_recuperator FAIL!!!095node_19_Livingroom_main FAIL!!!096node_20_Bedroom_main FAIL!!!097node_21_Cabinet_main FAIL!!!09809900:02:38:30100NODES CAN COMMUNICATION:101node_5_Net_center_Due2 FAIL!!!102node_6_Hallway_net_center FAIL!!!103node_7_Hallway_main FAIL!!!104node_8_Hallway_light FAIL!!!105node_9_Kitchen_net_center FAIL!!!106node_10_Kitchen_main FAIL!!!107node_11_Kitchen_light FAIL!!!108node_12_WC_main FAIL!!!109node_13_WC_waterleak FAIL!!!110node_14_Bathroom_main FAIL!!!111node_15_Boxroom_main FAIL!!!112node_18_Loggia_recuperator FAIL!!!113node_19_Livingroom_main FAIL!!!114node_20_Bedroom_main FAIL!!!115node_21_Cabinet_main FAIL!!!Нашёл довольно серьезный косяк. При периодической отправке параметров , весь список перебирается в цикле for. В теле цикла нет delay. Поэтому сообщения из списка от ардуины долбят в MCP2515 с большой скоростью. Опытным путём установил, что не все сообщения из списка передаются. Поставил delay (5). Стало всё гуд. Возможно из - за этого шина глючила. Что слишком маленькое было время между отправками соседних сообщений.
15 версия, это исправлено. Также добавил выбор автоматической отправки параметров ещё на один узел. (т.е. в целом 2 )
Вот интересно node_8_Hallway_light.ino.hex всегда немного отличается от всех остальных бинарников, все одинаковые а вот 8 немного меньше.
короче заливай этот короткий скетч. Если на нём тоже будет глючить - проблема все таки железячная , а не софтовая.
001#include <mcp_can.h>002#include <SPI.h>003#include <EEPROM.h>004005// выберем как будет устанавливаться адрес данного узла вручную или из еепром006007#define EEProm_my_ADDRES008//#define Manual_my_ADDRES009010011012// Выбираем аппаратную часть узла013014#define ARD_UNO015//#define ARD_MEGA016//#define ARD_DUE017018019020#ifdef EEProm_my_ADDRES021constbytenode_address = EEPROM.read(50);022#endif023#ifdef ARD_UNO024#define can CAN0025MCP_CAN can(10);026#endif027#ifdef ARD_MEGA028#define can CAN0029MCP_CAN can(53);030#endif031#ifdef ARD_DUE032#define can CAN3033MCP_CAN can(52);034#endif035036typedefenumNode_addr_enum037{038broadcast,//0039node_1_Net_center_PC,//1040node_2_Net_center_oraPi1,//2041node_3_Net_center_oraPi2,//3042node_4_Net_center_Due1,//4043node_5_Net_center_Due2,//5044node_6_Hallway_net_center,//6045node_7_Hallway_main,//7046node_8_Hallway_light,//8047node_9_Kitchen_net_center,//9048node_10_Kitchen_main,//10049node_11_Kitchen_light,//11050node_12_WC_main,//12051node_13_WC_waterleak,//13052node_14_Bathroom_main,//14053node_15_Boxroom_main,//15054node_16_Balcony_meteo,//16055node_17_Loggia_main,//17056node_18_Loggia_recuperator,//18057node_19_Livingroom_main,//19058node_20_Bedroom_main,//20059node_21_Cabinet_main,//21060SIZE_Node_addr_ENUM//22 size061}Node_addr_enum;062063constbyteNODS_NUMBER = SIZE_Node_addr_ENUM;064065066067// ниже вручную забьём адрес узла, если выше выбран дефайн #define Manual_my_ADDRES068069#ifdef Manual_my_ADDRES070//const byte node_address = node_1_Net_center_PC; //1071//const byte node_address = node_2_Net_center_oraPi1; //2072//const byte node_address = node_3_Net_center_oraPi2; //3073//const byte node_address = node_4_Net_center_Due1; //4074//const byte node_address = node_5_Net_center_Due2; //5075//const byte node_address = node_6_Hallway_net_center; //6076//const byte node_address = node_7_Hallway_main; //7077//const byte node_address = node_8_Hallway_light; //8078//const byte node_address = node_9_Kitchen_net_center //9079//const byte node_address = node_10_Kitchen_main; //10080//const byte node_address = node_11_Kitchen_light; //11081//const byte node_address = node_12_WC_main; //12082//const byte node_address = node_13_WC_waterleak; //13083//const byte node_address = node_14_Bathroom_main; //14084constbytenode_address = node_15_Boxroom_main;//15085//const byte node_address = node_16_Balcony_meteo; //16086//const byte node_address = node_17_Loggia_main; //17087//const byte node_address = node_18_Loggia_recuperator; //18088//const byte node_address = node_19_Livingroom_main; //19089//const byte node_address = node_20_Bedroom_main; //20090//const byte node_address = node_21_Cabinet_main; //21091#endif092093094095// Выбираем узлы подключенные к CAN шине096097constboolNodeCANpresence[22] =098{0990,// broadcast, //01000,// node_1_Net_center_PC, //11010,// node_2_Net_center_oraPi1, //21020,// node_3_Net_center_oraPi2, //31031,// node_4_Net_center_Due1, //41040,// node_5_Net_center_Due2, //51050,// node_6_Hallway_net_center, //61061,// node_7_Hallway_main, //71071,// node_8_Hallway_light, //81080,// node_9_Kitchen_net_center, //91091,// node_10_Kitchen_main, //101100,// node_11_Kitchen_light, //111110,// node_12_WC_main, //121120,// node_13_WC_waterleak, //131130,// node_14_Bathroom_main, //141140,// node_15_Boxroom_main, //151150,// node_16_Balcony_meteo, //161160,// node_17_Loggia_main, //171170,// node_18_Loggia_recuperator, //181180,// node_19_Livingroom_main, //191190,// node_20_Bedroom_main, //201200,// node_21_Cabinet_main, //21121};122123124// Выбираем смысловую нагрузку узла125126127#define type_node_master128//#define type_node_slave129//#define type_node_mk130131132133longunsignedintrxId;134unsignedcharlen = 0;135unsignedcharrxBuf[8];136137138#define CAN0_INT 2 // Set INT to pin 2139140byteStatusMK[22] = {0};141142143unsignedlongprevtimeStatus = 0;144boolTimerStatus = 0;145unsignedlongprevPrintStatus = 0;146147voidsetup()148{149byteCAN_spEEd = CAN_250KBPS;150Serial.begin(115200);151152153if(can.begin(MCP_STDEXT, CAN_spEEd, MCP_8MHZ) == CAN_OK)154Serial.println("MCP2515 Initialized Successfully!");155else156Serial.println("Error Initializing MCP2515...");157#ifdef type_node_master158can.init_Mask(0,0,0x07000000);//маска на самый левый разряд ID - для мастера159can.init_Filt(0,0,0x00000000);// фильтр чтобы левый разряд ID был 0 - для мастера160can.init_Filt(1,0,0x00000000);// фильтр чтобы левый разряд ID был 0 - для мастера161can.init_Mask(1,0,0x07000000);//маска на самый левый разряд ID - для мастера162can.init_Filt(2,0,0x00000000);// фильтр чтобы левый разряд ID был 0 - для мастера163can.init_Filt(3,0,0x00000000);// фильтр чтобы левый разряд ID был 0 - для мастера164can.init_Filt(4,0,0x00000000);// фильтр чтобы левый разряд ID был 0 - для мастера165can.init_Filt(5,0,0x00000000);// фильтр чтобы левый разряд ID был 0 - для мастера166#else167can.init_Mask(0,0,0x07FF0000);//маска на все разряды id - для узлов168can.init_Filt(0,0,0x06660000);// фильтр только 666169can.init_Filt(1,0,0x06660000);// фильтр только 666170can.init_Mask(1,0,0x07FF0000);//маска на все разряды id - для узлов171can.init_Filt(2,0,0x06660000);// фильтр только 666172can.init_Filt(3,0,0x06660000);// фильтр только 666173can.init_Filt(4,0,0x06660000);// фильтр только 666174can.init_Filt(5,0,0x06660000);// фильтр только 666175#endif176can.setMode(MCP_NORMAL);177178pinMode(CAN0_INT, INPUT);179180Serial.println("MCP2515 Library Receive Example...");181}182183voidloop()184{185if(!digitalRead(CAN0_INT))186{187can.readMsgBuf(&rxId, &len, rxBuf);188189#if defined (type_node_slave) or defined (type_node_mk)190Serial.print (rxId, HEX);Serial.print (F(" "));for(inti = 0; i < len; i++) {Serial.print (rxBuf[i] );Serial.print (F(" ")); }191if(rxId == 0x666) {prevtimeStatus = millis(); TimerStatus = 1;Serial.println (F(" Receive StatusMaster ")); }192elseSerial.println();193#endif194195#ifdef type_node_master196if(rxId >0 && rxId<22) StatusMK[rxId] = 0;197198#endif199}200201#if defined (type_node_slave) or defined (type_node_mk)202if(TimerStatus && millis() - prevtimeStatus > node_address*50) {203bytedata[8]= {255,255,255,255,255,255,255,255};204bytesndStat = can.sendMsgBuf(node_address, 0, 8, data);205if(sndStat == CAN_OK){Serial.println(F("Send my Status successfully!"));}206else{Serial.print(F("Error Send my Status!!! Error "));Serial.println (sndStat);}207TimerStatus = 0;}208#endif209210211212213214215#ifdef type_node_master216if(millis() -prevtimeStatus > 2000) {217for(inti = 0; i<22; i++) StatusMK[i]++;218219bytedata[8]= {0,0,0,0,0,0,0,0};220can.sendMsgBuf(0x666, 0, 8, data);221prevtimeStatus = millis();}222223224225if(millis() - prevPrintStatus > 15000) {226227Serial.println();Serial.println(F("NODE STATUS"));228for(inti = 1; i<22; i++) {if(i!=4 && NodeCANpresence[i]) {Serial.print (i);if(StatusMK[i]<=4)Serial.println (F(" OK"));elseSerial.println (F(" FAIL")); }}229Serial.println();230prevPrintStatus = millis();231}232233#endif234}мне по твоим последним логам не нравятся некорые узлы. В отладке пишется что статус от мастера принят, а отсылка своего статуса сразу за ним не пишется, т.е. может подрят несколько принять потом только свой отсылает. Такого быть никак не должно.
Или обратная проблема. Получения статусов от мастера в отладке нет, а свой статус отсылает . Причём в эти моменты узел мастером расценивается как ОК!. Вот с этим непонятки. Как будто тут сама дуня глючит и чё то с памятью.
А есть узлы (14 вроде) где вообще в отладке фразы на половину обрываются - явный признак нарушения памяти.
Вот эти косяки как раз указавают, что проблема софтовая.
Поэтому и надо залить простой скетч и проверить.
Я только 15 залил. И проблема то не в сбое сети, которая блуждающая! То сутки стоит без проблем то опять повылазило сразу.
Проблема в рестарте по SPI как я почитал на буржуинских форумах, народ с этой проблемой сталкивался. Нужно ничего не передавать на MSP по SPI после ресета 128 тактов или 50-100мс (кто что пишет)
рестарт вообще не должен происходить, ну может совсем редко. А судя по логам, у тебя едва едва fail не выскакивало. Некоторые узлы с ума сходили. И кстати у нас delay (100) есть. Ну сделай 200.
подключи канхакер на ночь, будет интересно словит ли он глюкавые сообщения или это они уже чисто на узлах возникают.
рестарт вообще не должен происходить, ну может совсем редко. А судя по логам, у тебя едва едва fail не выскакивало. Некоторые узлы с ума сходили. И кстати у нас delay (100) есть. Ну сделай 200.
Ну выходные то после перепайки исправили ситуацию, и вчера стояли норм (правда на 125)
Сегодня 250 и уже с глюками
Да кстати у меня #define TIMEOUTVALUE 100
мне по твоим последним логам не нравятся некорые узлы. В отладке пишется что статус от мастера принят, а отсылка своего статуса сразу за ним не пишется, т.е. может подрят несколько принять потом только свой отсылает. Такого быть никак не должно.
Или обратная проблема. Получения статусов от мастера в отладке нет, а свой статус отсылает . Причём в эти моменты узел мастером расценивается как ОК!. Вот с этим непонятки. Как будто тут сама дуня глючит и чё то с памятью.
А есть узлы (14 вроде) где вообще в отладке фразы на половину обрываются - явный признак нарушения памяти.
Вот эти косяки как раз указавают, что проблема софтовая.
Поэтому и надо залить простой скетч и проверить.
Это проблема Wi-Fi вывода лога, я заметил что через Wi-Fi/IP/Serial лог идет с потерями. Через Web все нормально но там буфер маленький. Я лог снимаю через esp-link это проброс serial через wi-fi esp8266
да уж, вифи с одной стороны облегчил жись, а с другой... Как бы ещё не было проблем с корявой заливкой hex файла по воздуху. Хотя там верификация какаянибудь должна быть .
таймаут я тоже у себя 100 поставил.
сделай скорость 125 и таймаут 125 ))
Кстати, обнаружил что нет блокировки отправки самому себе и приема своего же броадкаста
По простому в RX отсечь, а по хорошему фильтр придумать для своего бордкаста, а на передачу самому себе внутри TX если rem_adr==dev_adr то return ;)
Постоянно шлют
21->21
19->19
Честно, я вообще перестал понимать логику программы. По какому алгоритму идет рассылка я смотрю в канхаекр и просто диву даюсь что происходит в сети.
Почему например остальные сами себе не шлют, почему типы сообщений не совпадают.
да уж, вифи с одной стороны облегчил жись, а с другой... Как бы ещё не было проблем с корявой заливкой hex файла по воздуху. Хотя там верификация какаянибудь должна быть .
таймаут я тоже у себя 100 поставил.
Я проблемы не вижу, он нужен для прошивки и MQTT а вот такие ОЖИДАЕМЫЕ потери и задержки как раз и покажывают место радио в системе автоматизации ;-) (А потери пулеметной ленты лога да еще через эмулятор Win telnet serial это не проблема, это норма. Кстати я прошиваю все только c linux машины, из под Win вообще не пошло)
Провода наше все.
кстати у меня тут возникла очень здравая идея. адрес узла сохранить каждому в еепром . И при старте скетча адрес будет читаться. Таким образом на этапе тестирования (пока у всех узлов скетч одинаковый) - тебе не нужно будет создавать кучу папок скетчей с разными узлами. Один скетч льешь во все узлы и всё. Естественно предварительно нужно один раз забить в еепром адрес на каждый узел.
Так у тебя уменьшится время на заливку ПО всех узлов.
Вот это сделано в версии 16. Почитаешь, всё поймешь в первой вкладке, там минимум изменений.
Вот скетч для забивки в еепром адреса узла
01typedefenumNode_addr_enum02{03broadcast,//004node_1_Net_center_PC,//105node_2_Net_center_oraPi1,//206node_3_Net_center_oraPi2,//307node_4_Net_center_Due1,//408node_5_Net_center_Due2,//509node_6_Hallway_net_center,//610node_7_Hallway_main,//711node_8_Hallway_light,//812node_9_Kitchen_net_center,//913node_10_Kitchen_main,//1014node_11_Kitchen_light,//1115node_12_WC_main,//1216node_13_WC_waterleak,//1317node_14_Bathroom_main,//1418node_15_Boxroom_main,//1519node_16_Balcony_meteo,//1620node_17_Loggia_main,//1721node_18_Loggia_recuperator,//1822node_19_Livingroom_main,//1923node_20_Bedroom_main,//2024node_21_Cabinet_main,//2125SIZE_Node_addr_ENUM//22 size26}Node_addr_enum;272829#include <EEPROM.h>3031// ниже выберем адрес узла3233//const byte node_address = node_1_Net_center_PC; //134//const byte node_address = node_2_Net_center_oraPi1; //235//const byte node_address = node_3_Net_center_oraPi2; //336//const byte node_address = node_4_Net_center_Due1; //437//const byte node_address = node_5_Net_center_Due2; //538//const byte node_address = node_6_Hallway_net_center; //639//const byte node_address = node_7_Hallway_main; //740//const byte node_address = node_8_Hallway_light; //841//const byte node_address = node_9_Kitchen_net_center //942//const byte node_address = node_10_Kitchen_main; //1043constbytenode_address = node_11_Kitchen_light;//1144//const byte node_address = node_12_WC_main; //1245//const byte node_address = node_13_WC_waterleak; //1346//const byte node_address = node_14_Bathroom_main; //1447//const byte node_address = node_15_Boxroom_main; //1548//const byte node_address = node_16_Balcony_meteo; //1649//const byte node_address = node_17_Loggia_main; //1750//const byte node_address = node_18_Loggia_recuperator; //1851//const byte node_address = node_19_Livingroom_main; //1952//const byte node_address = node_20_Bedroom_main; //2053//const byte node_address = node_21_Cabinet_main; //2154555657voidsetup() {58Serial.begin (115200);5960EEPROM.write(50, node_address);6162Serial.print ("В еепром зашит адрес узла № ");Serial.print (EEPROM.read(50));6364}6566voidloop() {67// put your main code here, to run repeatedly:6869}Кстати, обнаружил что нет блокировки отправки самому себе и приема своего же броадкаста
По простому в RX отсечь, а по хорошему фильтр придумать для своего бордкаста, а на передачу самому себе внутри TX если rem_adr==dev_adr то return ;)
Постоянно шлют
21->21
19->19
Честно, я вообще перестал понимать логику программы. По какому алгоритму идет рассылка я смотрю в канхаекр и просто диву даюсь что происходит в сети.
Почему например остальные сами себе не шлют, почему типы сообщений не совпадают.
если отправка самому себе реально произошла с нашего MCP2515 то на приёмник она не попадёт. (по стандарту CAN шины сообщения из передатчика не попадают на приёмник).
Отправки самому себе и свои же бродкасты быть не должны, ну допустим что будут (какой то другой узел глюкнул и от нашего имени нам отправил), но не часто, поэтому проще программно В RX() сделать блокировку.
Ты спрашивал про алгоритм. Он очень простой :
У мастера: каждую секунду шлём бродкаст.
У узла: получил от мастера бродкаст - отправил свой статус мастеру.
Также периодически (в секунду равную адресу) отправляем на настроенный узел параметры.
Почему например остальные сами себе не шлют, почему типы сообщений не совпадают.
не понял про что именно ты говоришь. С чего вдруг они должны самы себе слать, и кто такие оставльные?
И какие типы сообщений и где не совпадают?
кстати у меня тут возникла очень здравая идея. адрес узла сохранить каждому в еепром . И при старте скетча адрес будет читаться. Таким образом на этапе тестирования (пока у всех узлов скетч одинаковый) - тебе не нужно будет создавать кучу папок скетчей с разными узлами. Один скетч льешь во все узлы и всё. Естественно предварительно нужно один раз забить в еепром адрес на каждый узел.
Так у тебя уменьшится время на заливку ПО всех узлов.
Вот это сделано в версии 16. Почитаешь, всё поймешь в первой вкладке, там минимум изменений.
Вот скетч для забивки в еепром адреса узла
01typedefenumNode_addr_enum02{03broadcast,//004node_1_Net_center_PC,//105node_2_Net_center_oraPi1,//206node_3_Net_center_oraPi2,//307node_4_Net_center_Due1,//408node_5_Net_center_Due2,//509node_6_Hallway_net_center,//610node_7_Hallway_main,//711node_8_Hallway_light,//812node_9_Kitchen_net_center,//913node_10_Kitchen_main,//1014node_11_Kitchen_light,//1115node_12_WC_main,//1216node_13_WC_waterleak,//1317node_14_Bathroom_main,//1418node_15_Boxroom_main,//1519node_16_Balcony_meteo,//1620node_17_Loggia_main,//1721node_18_Loggia_recuperator,//1822node_19_Livingroom_main,//1923node_20_Bedroom_main,//2024node_21_Cabinet_main,//2125SIZE_Node_addr_ENUM//22 size26}Node_addr_enum;272829#include <EEPROM.h>3031// ниже выберем адрес узла3233//const byte node_address = node_1_Net_center_PC; //134//const byte node_address = node_2_Net_center_oraPi1; //235//const byte node_address = node_3_Net_center_oraPi2; //336//const byte node_address = node_4_Net_center_Due1; //437//const byte node_address = node_5_Net_center_Due2; //538//const byte node_address = node_6_Hallway_net_center; //639//const byte node_address = node_7_Hallway_main; //740//const byte node_address = node_8_Hallway_light; //841//const byte node_address = node_9_Kitchen_net_center //942//const byte node_address = node_10_Kitchen_main; //1043constbytenode_address = node_11_Kitchen_light;//1144//const byte node_address = node_12_WC_main; //1245//const byte node_address = node_13_WC_waterleak; //1346//const byte node_address = node_14_Bathroom_main; //1447//const byte node_address = node_15_Boxroom_main; //1548//const byte node_address = node_16_Balcony_meteo; //1649//const byte node_address = node_17_Loggia_main; //1750//const byte node_address = node_18_Loggia_recuperator; //1851//const byte node_address = node_19_Livingroom_main; //1952//const byte node_address = node_20_Bedroom_main; //2053//const byte node_address = node_21_Cabinet_main; //2154555657voidsetup() {58Serial.begin (115200);5960EEPROM.write(50, node_address);6162Serial.print ("В еепром зашит адрес узла № ");Serial.print (EEPROM.read(50));6364}6566voidloop() {67// put your main code here, to run repeatedly:6869}Если это заработает, то будет совсем круто, а то перепрошивка 2-3 часа. Может все параметры в Eprom шить? Сколько туда лезет?
куда оно денется, заработает, я проверил. Лезет 512 кб помоему. Так еепром сдуется быстро если параметры туда лить постоянно .
куда оно денется, заработает, я проверил. Лезет 512 кб помоему. Так еепром сдуется быстро если параметры туда лить постоянно .
Нет всего 4096 байт
EEPROM:
1024 байта в ATmega328,
512 байт в ATmega168 и ATmega8,
4096 байт в ATmega1280 и ATmega2560
http://radioprog.ru/post/117
Конечно байт а не килобайт, перепутал слегка
В общем EEPROM - "это просто праздник какой то" ©
Предлагаю Все настройки узла туда загрузить
адрес, скорость шины, IP адреса, мастер/слейв/узел, debug и его ключи и пр. даже пока не придумывается.
Ограничение циклов 100 000 операций записи это даже если делать 10 записей в день хватит на 10 000 дней т.е примерно на 27 лет.
А нам нужно раз записать и потом при отладке перезаписывать иногда.
Честно, я вообще перестал понимать логику программы. По какому алгоритму идет рассылка я смотрю в канхаекр и просто диву даюсь что происходит в сети.
Почему например остальные сами себе не шлют, почему типы сообщений не совпадают.
Ты спрашивал про алгоритм. Он очень простой :
У мастера: каждую секунду шлём бродкаст.
У узла: получил от мастера бродкаст - отправил свой статус мастеру.
Также периодически (в секунду равную адресу) отправляем на настроенный узел параметры.
Про запрос и ответ статуса узла на бродкаст от мастера понятно мастрер шлет на 0, узлы отвечают на 4
Вопрос в другом кому и где это прописано узел шлет параметры. Я не понимаю как залитый один и тот же код с отличием в имени узла начинает слать почему то разным узлам.
Я бы понял что все бы слали мастеру, на 00, и например 10, но ведь не так 0,4,19,21 Где это прописано?
0114050001 5 49 00 09 08 00 65 101 5->00214050402 5 4A 00 09 01 00 65 96 5->40314050403 5 4B 00 09 01 00 65 101 5->40414050405 5 4C 00 09 01 00 64 100 5->40514050406 5 4D 00 09 01 00 64 101 5->4061405040E 5 4E 00 09 08 00 65 101 5->40714050434 8 4F 00 09 04 00 00 00 00 64 101 5->40814051301 5 51 00 09 08 00 65 101 5->190914051302 5 52 00 09 01 00 65 101 5->191014051303 5 53 00 09 01 00 65 100 5->191114051305 5 54 00 09 01 00 65 101 5->191214051538 8 50 00 09 09 00 00 00 00 64 101 5->21Ограничение циклов 100 000 операций записи это даже если делать 10 записей в день хватит на 10 000 дней т.е примерно на 27 лет.
А нам нужно раз записать и потом при отладке перезаписывать иногда.
ты про параметры говорил. Я думал ты про массив parameter[][] - он то часто обновляется. А ты про другие настройки типа скорости шины и т.д. Их то да конечно в еепром тоже можно записывать.
Я бы понял что все бы слали мастеру, на 00, и например 10, но ведь не так 0,4,19,21 Где это прописано?
0114050001 5 49 00 09 08 00 65 101 5->00214050402 5 4A 00 09 01 00 65 96 5->40314050403 5 4B 00 09 01 00 65 101 5->40414050405 5 4C 00 09 01 00 64 100 5->40514050406 5 4D 00 09 01 00 64 101 5->4061405040E 5 4E 00 09 08 00 65 101 5->40714050434 8 4F 00 09 04 00 00 00 00 64 101 5->40814051301 5 51 00 09 08 00 65 101 5->190914051302 5 52 00 09 01 00 65 101 5->191014051303 5 53 00 09 01 00 65 100 5->191114051305 5 54 00 09 01 00 65 101 5->191214051538 8 50 00 09 09 00 00 00 00 64 101 5->21в файле can_struct.h
01{0203// НИЖЕ УКАЗЫВАЕМ АДРЕС первого УЗЛА, КУДА ПЕРИОДИЧЕСКИ ИЛИ ПО ИЗМЕНЕНИЮ БУДЕТ ПОСЫЛАТЬСЯ КОНКРЕТНЫЙ ПАРАМЕТР, если 0xFF, то никому данный параметр не отсылается0405broadcast,//1 //датчик температуры06node_4_Net_center_Due1,//2 //датчик влажности07node_4_Net_center_Due1,//3 //датчик давления08node_4_Net_center_Due1,//5 //датчик движения09node_4_Net_center_Due1,//6 //датчик вибрации100xFF,//7 //датчик шума110xFF,//8 //датчик освещенности12node_4_Net_center_Due1,//14 //Температура тела130xFF,//40 //Температура батареи140xFF,//46 //Счетчик газа150xFF,//47 сервисный байт16node_4_Net_center_Due1,//52 //Счетчик электричества170xFF,//53 сервисный байт180xFF,//54 сервисный байт190xFF,//55 сервисный байт20node_21_Cabinet_main,//56 //напряжение АКБ бесперебойника210xFF,//57 сервисный байт220xFF,//58 сервисный байт230xFF//59 сервисный байт242526272829},для каждого параметра в отдельности выбирается узел, на который будет посылаться этот параметр периодически или по изменению. Начиная с 15 версии, можно для каждого параметра выбирать два узла, на которые он будет отсылаться
А 0xFF соответственно никому?
В общем EEPROM - "это просто праздник какой то" ©
Предлагаю Все настройки узла туда загрузить
адрес, скорость шины, IP адреса, мастер/слейв/узел, debug и его ключи и пр. даже пока не придумывается.
с адресом , скоростью шины, IP адреса это да, но вот мастер/слейв/узел, debug и его ключи у нас же делаются с помощью директив условной компиляции и этот выбор происходит ещё когда скетч не в узле, а при компиляции, т.е. твой НЕХ файл когда создаётся. Сделать то можно будет, но всё через флаги только, а это память расходует.
и какой смысл эти данные держать в еепром, когда их как раз и нужно изменять при необходимости. А так они всё время из еепром одни и теже будут грузиться, без возможности выбора.
А 0xFF соответственно никому?
да всё верно
Кликабельно
#define NOT_INCLUDED 0x06 // если параметр отсутствует на узле
типы данных :
1#define BYTE_1 012#define BYTE_2 023#define BYTE_4 044#define SERVICE_BYTE 055#define BYTE_4_SIGNED 066#define BYTE_2_SIGNED 077#define BYTE_1_SIGNED 088#define BYTE_4_FLOAT 09debug и его ключи у нас же делаются с помощью директив условной компиляции и этот выбор происходит ещё когда скетч не в узле, а при компиляции, т.е. твой НЕХ файл когда создаётся. Сделать то можно будет, но всё через флаги только, а это память расходует.
и какой смысл эти данные держать в еепром, когда их как раз и нужно изменять при необходимости. А так они всё время из еепром одни и теже будут грузиться, без возможности выбора.
Согласен. Тогда и мастер/слейв/узел тоже нет смысла (или в прошивке держать оба кода и узла и мастера ).
Ну в общем я про смысл прошивки.
Тем более что с таким набором и возможностью хранить произвольные типы. И вот в серьез подумать именно про твои настройки на епром byte parameter [6][parameters_quantity]
смысл в том чтобы, всё не подгружать в ОЗУ. В последствии на мастере можно сделать хранилище параметров от всех узлов. И тогда для остального места уже не остаётся. Поэтому для мастера нужен отдельный код. Тем более узлы можно не меги делать, а наны например, а у них памяти мало, поэтому нужны компактные скетчи для узлов.
Не вижу смысла грузить настройки parameter[][] в еепром
ну как ты тестировал стабильность v15 или v16 или может простой скетч #965 заливал?
Не вижу смысла грузить настройки parameter[][] в еепром
Жаль, я в любом случае уникальные параметры каждого контроллера не зависящие от кода, в смысле перечень устройств, их адреса, куда направлять сообщения, у кого запрашивать и брать параметы положу в епром.
Просто это было бы красиво код одинаковый и отлаженый. Прошил епром подключил на универсальный разъем расширитель к которому подключил нужные датчики и ИУ. И вперед.
ну как ты тестировал стабильность v15 или v16 или может простой скетч #965 заливал?
Не я прежде чем "превращать в кирпич" ;-) т.е. писать в энергонезависимую память изучал вопрос, завтра соберу, прошью везде епром и залью 16 версию на 125к, я просто хочу сделать возможность через консоль дать команду на изменение скорости шины путем записи в епром и ресета. На подобе твоей test
путаться будешь, тут вот оно в скетче, правишь когда надо. А там в еепроме как посмотреть, что залито? И где он одинаковый код. На одном узле, например, используется 3 параметра, а на другом - 23. В основном скетче проще всё менять, чем еепром прошивать отдельным скетчем. Еепром считаю нужен как энергонезависимая память.
смысл в том чтобы, всё не подгружать в ОЗУ. В последствии на мастере можно сделать хранилище параметров от всех узлов. И тогда для остального места уже не остаётся. Поэтому для мастера нужен отдельный код. Тем более узлы можно не меги делать, а наны например, а у них памяти мало, поэтому нужны компактные скетчи для узлов.
Смотри, сеть стационарная, все на кабелях, какова Вероятность что ды доподключишь в последствии что то помимо уже установленного. Правильно, никакая. Тогда зачем делать централизованное хранилище конфига? Прошил в епром все типы подключенных датчиков, ИУ и все. В зависимости от этого инициируешь переменные.
А работать с наной я честно не готов, тогда уж при этом формфакторе есть 32 разрадные с памятью. А лучше тогда сразу ESP32.
путаться будешь, тут вот оно в скетче, правишь когда надо. А там в еепроме как посмотреть, что залито? И где он одинаковый код. На одном узле, например, используется 3 параметра, а на другом - 23. В основном скетче проще всё менять, чем еепром прошивать отдельным скетчем. Еепром считаю нужен как энергонезависимая память.
Тогда будет, по крайней мере в моем случае минимум 15 скетчей для узлов на меге, 2 мастер слейв на DUE.
Для всех нужно иметь свой разный конфиг и нигде не ошибиться. Я не просто так помнишь начинал с очень простых и читаемых типов у-в и ИУ.
Узлы у меня практически типовые с небольшими отличиями.
Ну на самом деле нужно подумать еще. Это не окончательное решение. Но уж больно идея заманчивая. Кстати чтобы не писать все время в процессе отладки можно эмулятор простой сделать читать не из памати а из файла ну типо ф-ю EEPROM1 с теми же вызовани сделать на время отладки.
блин ну не пойму я смысла. Это всё и так лежит в энергонезависимой памяти, которая называется флеш. В ней залит скетч. В скетче есть эта информация. Дак нафига её в еепром то пихать? В том то и дело, если ты ничего подключать дополнительно не собираешься вообще не имеет смысла в еепром пихать. Т.к. туда пихается обычно изменяемая инфа. А постоянная она из флеша (скетча) спокойно также грузится.