тип данных параметров в массиве содержится в нулевом элементе первого измерения массива
т.е. #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, то никому данный параметр не отсылается
broadcast, //1 //датчик температуры
node_4_Net_center_Due1, //2 //датчик влажности
node_4_Net_center_Due1, //3 //датчик давления
node_4_Net_center_Due1, //5 //датчик движения
node_4_Net_center_Due1, //6 //датчик вибрации
0xFF, //7 //датчик шума
0xFF, //8 //датчик освещенности
node_4_Net_center_Due1, //14 //Температура тела
0xFF, //40 //Температура батареи
0xFF, //46 //Счетчик газа
0xFF, //47 сервисный байт
node_4_Net_center_Due1, //52 //Счетчик электричества
0xFF, //53 сервисный байт
0xFF, //54 сервисный байт
0xFF, //55 сервисный байт
node_21_Cabinet_main, //56 //напряжение АКБ бесперебойника
0xFF, //57 сервисный байт
0xFF, //58 сервисный байт
0xFF //59 сервисный байт
},
для каждого параметра в отдельности выбирается узел, на который будет посылаться этот параметр периодически или по изменению. Начиная с 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 для знаковых. Примерно так
int8_t bme_temp() {} byte bme_hum() {} byte bme_pres() {}2. Надо так
тип данных параметров в массиве содержится в нулевом элементе первого измерения массива
т.е. #define TYPE_VAR 0
правильно ты показал для air_t это BYTE_1_SIGNED. При отправке по CAN эта инфа (тип данных) будет содержаться в фрейме и приёмник соответствующим образом интерпретирует этот параметр.
Параметр отсылается на один выбранный узел по изменению или периодически, в зависимости от того, что наступит раньше. На ещё один узел я не сделал возможности так отправлять параметры. НО, если какому то узлу нужен параметр - он может запросить у нашего узла и наш узел ему ответит этим параметром. (Сообщение - запрос параметра).
Можно ( и это в принципе не сложно) добавить в код, чтобы был выбор - чтобы на ещё один узел отправлять параметры. Т.е. в целом будут выбирается два адреса, на которые будут передаваться параметры периодически или по изменению (смотря что наступит раньше).
А если нужно больше узлов, то проще уж широковещательное сообщение делать, из которого все кому надо возмут инфу. Так и шина меньше нагружаться будет.
версия 14.
- Добавил в отладку версию скетча, скорость шины, инфу что именно было рестарт mcp2515 и/или ардуино.
- исправил небольшой косяк с запросом параметра от другого узла.
версия 14.
- Добавил в отладку версию скетча, скорость шины, инфу что именно было рестарт mcp2515 и/или ардуино.
- исправил небольшой косяк с запросом параметра от другого узла.
Есть вопрос, я канхакером увидел что узлы произвольно обмениваются параметрами, хотя код одинаковый и везде стоит отправлять к 4. Как это поправить.
судя о канхакингу , ты сначала видимо отправлял команды 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 секунды налетело)
И еще глобальная просба, на тему структуризации кодо и его наследования. Просьба переделать немного основной файл и 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?
Увы опять сбой, ресет не сработал
00:02:37:00 NODES CAN COMMUNICATION: node_5_Net_center_Due2 OK!!! node_6_Hallway_net_center OK!!! node_7_Hallway_main OK!!! node_8_Hallway_light OK!!! node_9_Kitchen_net_center OK!!! node_10_Kitchen_main OK!!! node_11_Kitchen_light OK!!! node_12_WC_main OK!!! node_13_WC_waterleak OK!!! node_14_Bathroom_main OK!!! node_15_Boxroom_main OK!!! node_18_Loggia_recuperator OK!!! node_19_Livingroom_main OK!!! node_20_Bedroom_main OK!!! node_21_Cabinet_main OK!!! 00:02:37:30 NODES CAN COMMUNICATION: node_5_Net_center_Due2 OK!!! node_6_Hallway_net_center OK!!! node_7_Hallway_main OK!!! node_8_Hallway_light OK!!! node_9_Kitchen_net_center OK!!! node_10_Kitchen_main OK!!! node_11_Kitchen_light OK!!! node_12_WC_main OK!!! node_13_WC_waterleak OK!!! node_14_Bathroom_main OK!!! node_15_Boxroom_main OK!!! node_18_Loggia_recuperator OK!!! node_19_Livingroom_main OK!!! node_20_Bedroom_main OK!!! node_21_Cabinet_main OK!!! 00:02:37:33 Принято из CAN: NULL_C От Кого: Неизвестный адрес - ID 801B0C07 00:02:37:33 Принято из CAN: NULL_C От Кого: Неизвестный адрес - ID 801B0C07 00:02:37:33 Принято из CAN: NULL_C От Кого: ШИРОКОВЕЩАТЕЛЬНО - ID 0 Error Initializing MCP2515... РЕСТАРТ MCP2515 00:02:37:33 Принято из CAN: NULL_C От Кого: ШИРОКОВЕЩАТЕЛЬНО - ID 0 Error Initializing MCP2515... РЕСТАРТ MCP2515 Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A04010A 20 Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A04010B 21 Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A04010C 22 Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A04010D 23 Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A04010E 24 Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A04010F 25 Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040112 26 Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040113 27 Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040114 28 Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040115 29 Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040105 2A Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040106 2B Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040107 2C Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040108 2D Отправлено в CAN: АВАРИЯ Кому: node_1_Net_center_PC - ID 9A040109 2E 00:02:38:00 NODES CAN COMMUNICATION: node_5_Net_center_Due2 FAIL!!! node_6_Hallway_net_center FAIL!!! node_7_Hallway_main FAIL!!! node_8_Hallway_light FAIL!!! node_9_Kitchen_net_center FAIL!!! node_10_Kitchen_main FAIL!!! node_11_Kitchen_light FAIL!!! node_12_WC_main FAIL!!! node_13_WC_waterleak FAIL!!! node_14_Bathroom_main FAIL!!! node_15_Boxroom_main FAIL!!! node_18_Loggia_recuperator FAIL!!! node_19_Livingroom_main FAIL!!! node_20_Bedroom_main FAIL!!! node_21_Cabinet_main FAIL!!! 00:02:38:30 NODES CAN COMMUNICATION: node_5_Net_center_Due2 FAIL!!! node_6_Hallway_net_center FAIL!!! node_7_Hallway_main FAIL!!! node_8_Hallway_light FAIL!!! node_9_Kitchen_net_center FAIL!!! node_10_Kitchen_main FAIL!!! node_11_Kitchen_light FAIL!!! node_12_WC_main FAIL!!! node_13_WC_waterleak FAIL!!! node_14_Bathroom_main FAIL!!! node_15_Boxroom_main FAIL!!! node_18_Loggia_recuperator FAIL!!! node_19_Livingroom_main FAIL!!! node_20_Bedroom_main FAIL!!! node_21_Cabinet_main FAIL!!!Нашёл довольно серьезный косяк. При периодической отправке параметров , весь список перебирается в цикле for. В теле цикла нет delay. Поэтому сообщения из списка от ардуины долбят в MCP2515 с большой скоростью. Опытным путём установил, что не все сообщения из списка передаются. Поставил delay (5). Стало всё гуд. Возможно из - за этого шина глючила. Что слишком маленькое было время между отправками соседних сообщений.
15 версия, это исправлено. Также добавил выбор автоматической отправки параметров ещё на один узел. (т.е. в целом 2 )
Вот интересно node_8_Hallway_light.ino.hex всегда немного отличается от всех остальных бинарников, все одинаковые а вот 8 немного меньше.
короче заливай этот короткий скетч. Если на нём тоже будет глючить - проблема все таки железячная , а не софтовая.
#include <mcp_can.h> #include <SPI.h> #include <EEPROM.h> // выберем как будет устанавливаться адрес данного узла вручную или из еепром #define EEProm_my_ADDRES //#define Manual_my_ADDRES // Выбираем аппаратную часть узла #define ARD_UNO //#define ARD_MEGA //#define ARD_DUE #ifdef EEProm_my_ADDRES const byte node_address = EEPROM.read(50); #endif #ifdef ARD_UNO #define can CAN0 MCP_CAN can(10); #endif #ifdef ARD_MEGA #define can CAN0 MCP_CAN can(53); #endif #ifdef ARD_DUE #define can CAN3 MCP_CAN can(52); #endif typedef enum Node_addr_enum { broadcast, //0 node_1_Net_center_PC, //1 node_2_Net_center_oraPi1, //2 node_3_Net_center_oraPi2, //3 node_4_Net_center_Due1, //4 node_5_Net_center_Due2, //5 node_6_Hallway_net_center, //6 node_7_Hallway_main, //7 node_8_Hallway_light, //8 node_9_Kitchen_net_center, //9 node_10_Kitchen_main, //10 node_11_Kitchen_light, //11 node_12_WC_main, //12 node_13_WC_waterleak, //13 node_14_Bathroom_main, //14 node_15_Boxroom_main, //15 node_16_Balcony_meteo, //16 node_17_Loggia_main, //17 node_18_Loggia_recuperator, //18 node_19_Livingroom_main, //19 node_20_Bedroom_main, //20 node_21_Cabinet_main, //21 SIZE_Node_addr_ENUM //22 size }Node_addr_enum; const byte NODS_NUMBER = SIZE_Node_addr_ENUM; // ниже вручную забьём адрес узла, если выше выбран дефайн #define Manual_my_ADDRES #ifdef Manual_my_ADDRES //const byte node_address = node_1_Net_center_PC; //1 //const byte node_address = node_2_Net_center_oraPi1; //2 //const byte node_address = node_3_Net_center_oraPi2; //3 //const byte node_address = node_4_Net_center_Due1; //4 //const byte node_address = node_5_Net_center_Due2; //5 //const byte node_address = node_6_Hallway_net_center; //6 //const byte node_address = node_7_Hallway_main; //7 //const byte node_address = node_8_Hallway_light; //8 //const byte node_address = node_9_Kitchen_net_center //9 //const byte node_address = node_10_Kitchen_main; //10 //const byte node_address = node_11_Kitchen_light; //11 //const byte node_address = node_12_WC_main; //12 //const byte node_address = node_13_WC_waterleak; //13 //const byte node_address = node_14_Bathroom_main; //14 const byte node_address = node_15_Boxroom_main; //15 //const byte node_address = node_16_Balcony_meteo; //16 //const byte node_address = node_17_Loggia_main; //17 //const byte node_address = node_18_Loggia_recuperator; //18 //const byte node_address = node_19_Livingroom_main; //19 //const byte node_address = node_20_Bedroom_main; //20 //const byte node_address = node_21_Cabinet_main; //21 #endif // Выбираем узлы подключенные к CAN шине const bool NodeCANpresence[22] = { 0, // broadcast, //0 0, // node_1_Net_center_PC, //1 0, // node_2_Net_center_oraPi1, //2 0, // node_3_Net_center_oraPi2, //3 1, // node_4_Net_center_Due1, //4 0, // node_5_Net_center_Due2, //5 0, // node_6_Hallway_net_center, //6 1, // node_7_Hallway_main, //7 1, // node_8_Hallway_light, //8 0, // node_9_Kitchen_net_center, //9 1, // node_10_Kitchen_main, //10 0, // node_11_Kitchen_light, //11 0, // node_12_WC_main, //12 0, // node_13_WC_waterleak, //13 0, // node_14_Bathroom_main, //14 0, // node_15_Boxroom_main, //15 0, // node_16_Balcony_meteo, //16 0, // node_17_Loggia_main, //17 0, // node_18_Loggia_recuperator, //18 0, // node_19_Livingroom_main, //19 0, // node_20_Bedroom_main, //20 0, // node_21_Cabinet_main, //21 }; // Выбираем смысловую нагрузку узла #define type_node_master //#define type_node_slave //#define type_node_mk long unsigned int rxId; unsigned char len = 0; unsigned char rxBuf[8]; #define CAN0_INT 2 // Set INT to pin 2 byte StatusMK[22] = {0}; unsigned long prevtimeStatus = 0; bool TimerStatus = 0; unsigned long prevPrintStatus = 0; void setup() { byte CAN_spEEd = CAN_250KBPS; Serial.begin(115200); if(can.begin(MCP_STDEXT, CAN_spEEd, MCP_8MHZ) == CAN_OK) Serial.println("MCP2515 Initialized Successfully!"); else Serial.println("Error Initializing MCP2515..."); #ifdef type_node_master can.init_Mask(0,0,0x07000000); //маска на самый левый разряд ID - для мастера can.init_Filt(0,0,0x00000000); // фильтр чтобы левый разряд ID был 0 - для мастера can.init_Filt(1,0,0x00000000); // фильтр чтобы левый разряд ID был 0 - для мастера can.init_Mask(1,0,0x07000000); //маска на самый левый разряд ID - для мастера can.init_Filt(2,0,0x00000000); // фильтр чтобы левый разряд ID был 0 - для мастера can.init_Filt(3,0,0x00000000); // фильтр чтобы левый разряд ID был 0 - для мастера can.init_Filt(4,0,0x00000000); // фильтр чтобы левый разряд ID был 0 - для мастера can.init_Filt(5,0,0x00000000); // фильтр чтобы левый разряд ID был 0 - для мастера #else can.init_Mask(0,0,0x07FF0000); //маска на все разряды id - для узлов can.init_Filt(0,0,0x06660000); // фильтр только 666 can.init_Filt(1,0,0x06660000); // фильтр только 666 can.init_Mask(1,0,0x07FF0000); //маска на все разряды id - для узлов can.init_Filt(2,0,0x06660000); // фильтр только 666 can.init_Filt(3,0,0x06660000); // фильтр только 666 can.init_Filt(4,0,0x06660000); // фильтр только 666 can.init_Filt(5,0,0x06660000); // фильтр только 666 #endif can.setMode(MCP_NORMAL); pinMode(CAN0_INT, INPUT); Serial.println("MCP2515 Library Receive Example..."); } void loop() { if(!digitalRead(CAN0_INT)) { can.readMsgBuf(&rxId, &len, rxBuf); #if defined (type_node_slave) or defined (type_node_mk) Serial.print (rxId, HEX); Serial.print (F(" ")); for (int i = 0; i < len; i++) {Serial.print (rxBuf[i] ); Serial.print (F(" ")); } if (rxId == 0x666) {prevtimeStatus = millis(); TimerStatus = 1; Serial.println (F(" Receive StatusMaster ")); } else Serial.println(); #endif #ifdef type_node_master if (rxId >0 && rxId<22) StatusMK[rxId] = 0; #endif } #if defined (type_node_slave) or defined (type_node_mk) if (TimerStatus && millis() - prevtimeStatus > node_address*50) { byte data[8]= {255,255,255,255,255,255,255,255}; byte sndStat = can.sendMsgBuf(node_address, 0, 8, data); if(sndStat == CAN_OK){ Serial.println(F("Send my Status successfully!"));} else { Serial.print(F("Error Send my Status!!! Error ")); Serial.println (sndStat);} TimerStatus = 0;} #endif #ifdef type_node_master if (millis() -prevtimeStatus > 2000) { for (int i = 0; i<22; i++) StatusMK[i]++; byte data[8]= {0,0,0,0,0,0,0,0}; can.sendMsgBuf(0x666, 0, 8, data); prevtimeStatus = millis();} if (millis() - prevPrintStatus > 15000) { Serial.println(); Serial.println(F("NODE STATUS")); for (int i = 1; i<22; i++) {if (i!=4 && NodeCANpresence[i]) {Serial.print (i); if (StatusMK[i]<=4) Serial.println (F(" OK")); else Serial.println (F(" FAIL")); }} Serial.println(); prevPrintStatus = millis(); } #endif }мне по твоим последним логам не нравятся некорые узлы. В отладке пишется что статус от мастера принят, а отсылка своего статуса сразу за ним не пишется, т.е. может подрят несколько принять потом только свой отсылает. Такого быть никак не должно.
Или обратная проблема. Получения статусов от мастера в отладке нет, а свой статус отсылает . Причём в эти моменты узел мастером расценивается как ОК!. Вот с этим непонятки. Как будто тут сама дуня глючит и чё то с памятью.
А есть узлы (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. Почитаешь, всё поймешь в первой вкладке, там минимум изменений.
Вот скетч для забивки в еепром адреса узла
typedef enum Node_addr_enum { broadcast, //0 node_1_Net_center_PC, //1 node_2_Net_center_oraPi1, //2 node_3_Net_center_oraPi2, //3 node_4_Net_center_Due1, //4 node_5_Net_center_Due2, //5 node_6_Hallway_net_center, //6 node_7_Hallway_main, //7 node_8_Hallway_light, //8 node_9_Kitchen_net_center, //9 node_10_Kitchen_main, //10 node_11_Kitchen_light, //11 node_12_WC_main, //12 node_13_WC_waterleak, //13 node_14_Bathroom_main, //14 node_15_Boxroom_main, //15 node_16_Balcony_meteo, //16 node_17_Loggia_main, //17 node_18_Loggia_recuperator, //18 node_19_Livingroom_main, //19 node_20_Bedroom_main, //20 node_21_Cabinet_main, //21 SIZE_Node_addr_ENUM //22 size }Node_addr_enum; #include <EEPROM.h> // ниже выберем адрес узла //const byte node_address = node_1_Net_center_PC; //1 //const byte node_address = node_2_Net_center_oraPi1; //2 //const byte node_address = node_3_Net_center_oraPi2; //3 //const byte node_address = node_4_Net_center_Due1; //4 //const byte node_address = node_5_Net_center_Due2; //5 //const byte node_address = node_6_Hallway_net_center; //6 //const byte node_address = node_7_Hallway_main; //7 //const byte node_address = node_8_Hallway_light; //8 //const byte node_address = node_9_Kitchen_net_center //9 //const byte node_address = node_10_Kitchen_main; //10 const byte node_address = node_11_Kitchen_light; //11 //const byte node_address = node_12_WC_main; //12 //const byte node_address = node_13_WC_waterleak; //13 //const byte node_address = node_14_Bathroom_main; //14 //const byte node_address = node_15_Boxroom_main; //15 //const byte node_address = node_16_Balcony_meteo; //16 //const byte node_address = node_17_Loggia_main; //17 //const byte node_address = node_18_Loggia_recuperator; //18 //const byte node_address = node_19_Livingroom_main; //19 //const byte node_address = node_20_Bedroom_main; //20 //const byte node_address = node_21_Cabinet_main; //21 void setup() { Serial.begin (115200); EEPROM.write(50, node_address); Serial.print ("В еепром зашит адрес узла № "); Serial.print (EEPROM.read(50)); } void loop() { // put your main code here, to run repeatedly: }Кстати, обнаружил что нет блокировки отправки самому себе и приема своего же броадкаста
По простому в RX отсечь, а по хорошему фильтр придумать для своего бордкаста, а на передачу самому себе внутри TX если rem_adr==dev_adr то return ;)
Постоянно шлют
21->21
19->19
Честно, я вообще перестал понимать логику программы. По какому алгоритму идет рассылка я смотрю в канхаекр и просто диву даюсь что происходит в сети.
Почему например остальные сами себе не шлют, почему типы сообщений не совпадают.
если отправка самому себе реально произошла с нашего MCP2515 то на приёмник она не попадёт. (по стандарту CAN шины сообщения из передатчика не попадают на приёмник).
Отправки самому себе и свои же бродкасты быть не должны, ну допустим что будут (какой то другой узел глюкнул и от нашего имени нам отправил), но не часто, поэтому проще программно В RX() сделать блокировку.
Ты спрашивал про алгоритм. Он очень простой :
У мастера: каждую секунду шлём бродкаст.
У узла: получил от мастера бродкаст - отправил свой статус мастеру.
Также периодически (в секунду равную адресу) отправляем на настроенный узел параметры.
Почему например остальные сами себе не шлют, почему типы сообщений не совпадают.
не понял про что именно ты говоришь. С чего вдруг они должны самы себе слать, и кто такие оставльные?
И какие типы сообщений и где не совпадают?
кстати у меня тут возникла очень здравая идея. адрес узла сохранить каждому в еепром . И при старте скетча адрес будет читаться. Таким образом на этапе тестирования (пока у всех узлов скетч одинаковый) - тебе не нужно будет создавать кучу папок скетчей с разными узлами. Один скетч льешь во все узлы и всё. Естественно предварительно нужно один раз забить в еепром адрес на каждый узел.
Так у тебя уменьшится время на заливку ПО всех узлов.
Вот это сделано в версии 16. Почитаешь, всё поймешь в первой вкладке, там минимум изменений.
Вот скетч для забивки в еепром адреса узла
typedef enum Node_addr_enum { broadcast, //0 node_1_Net_center_PC, //1 node_2_Net_center_oraPi1, //2 node_3_Net_center_oraPi2, //3 node_4_Net_center_Due1, //4 node_5_Net_center_Due2, //5 node_6_Hallway_net_center, //6 node_7_Hallway_main, //7 node_8_Hallway_light, //8 node_9_Kitchen_net_center, //9 node_10_Kitchen_main, //10 node_11_Kitchen_light, //11 node_12_WC_main, //12 node_13_WC_waterleak, //13 node_14_Bathroom_main, //14 node_15_Boxroom_main, //15 node_16_Balcony_meteo, //16 node_17_Loggia_main, //17 node_18_Loggia_recuperator, //18 node_19_Livingroom_main, //19 node_20_Bedroom_main, //20 node_21_Cabinet_main, //21 SIZE_Node_addr_ENUM //22 size }Node_addr_enum; #include <EEPROM.h> // ниже выберем адрес узла //const byte node_address = node_1_Net_center_PC; //1 //const byte node_address = node_2_Net_center_oraPi1; //2 //const byte node_address = node_3_Net_center_oraPi2; //3 //const byte node_address = node_4_Net_center_Due1; //4 //const byte node_address = node_5_Net_center_Due2; //5 //const byte node_address = node_6_Hallway_net_center; //6 //const byte node_address = node_7_Hallway_main; //7 //const byte node_address = node_8_Hallway_light; //8 //const byte node_address = node_9_Kitchen_net_center //9 //const byte node_address = node_10_Kitchen_main; //10 const byte node_address = node_11_Kitchen_light; //11 //const byte node_address = node_12_WC_main; //12 //const byte node_address = node_13_WC_waterleak; //13 //const byte node_address = node_14_Bathroom_main; //14 //const byte node_address = node_15_Boxroom_main; //15 //const byte node_address = node_16_Balcony_meteo; //16 //const byte node_address = node_17_Loggia_main; //17 //const byte node_address = node_18_Loggia_recuperator; //18 //const byte node_address = node_19_Livingroom_main; //19 //const byte node_address = node_20_Bedroom_main; //20 //const byte node_address = node_21_Cabinet_main; //21 void setup() { Serial.begin (115200); EEPROM.write(50, node_address); Serial.print ("В еепром зашит адрес узла № "); Serial.print (EEPROM.read(50)); } void loop() { // put your main code here, to run repeatedly: }Если это заработает, то будет совсем круто, а то перепрошивка 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 Где это прописано?
Ограничение циклов 100 000 операций записи это даже если делать 10 записей в день хватит на 10 000 дней т.е примерно на 27 лет.
А нам нужно раз записать и потом при отладке перезаписывать иногда.
ты про параметры говорил. Я думал ты про массив parameter[][] - он то часто обновляется. А ты про другие настройки типа скорости шины и т.д. Их то да конечно в еепром тоже можно записывать.
Я бы понял что все бы слали мастеру, на 00, и например 10, но ведь не так 0,4,19,21 Где это прописано?
в файле can_struct.h
{ // НИЖЕ УКАЗЫВАЕМ АДРЕС первого УЗЛА, КУДА ПЕРИОДИЧЕСКИ ИЛИ ПО ИЗМЕНЕНИЮ БУДЕТ ПОСЫЛАТЬСЯ КОНКРЕТНЫЙ ПАРАМЕТР, если 0xFF, то никому данный параметр не отсылается broadcast, //1 //датчик температуры node_4_Net_center_Due1, //2 //датчик влажности node_4_Net_center_Due1, //3 //датчик давления node_4_Net_center_Due1, //5 //датчик движения node_4_Net_center_Due1, //6 //датчик вибрации 0xFF, //7 //датчик шума 0xFF, //8 //датчик освещенности node_4_Net_center_Due1, //14 //Температура тела 0xFF, //40 //Температура батареи 0xFF, //46 //Счетчик газа 0xFF, //47 сервисный байт node_4_Net_center_Due1, //52 //Счетчик электричества 0xFF, //53 сервисный байт 0xFF, //54 сервисный байт 0xFF, //55 сервисный байт node_21_Cabinet_main, //56 //напряжение АКБ бесперебойника 0xFF, //57 сервисный байт 0xFF, //58 сервисный байт 0xFF //59 сервисный байт },для каждого параметра в отдельности выбирается узел, на который будет посылаться этот параметр периодически или по изменению. Начиная с 15 версии, можно для каждого параметра выбирать два узла, на которые он будет отсылаться
А 0xFF соответственно никому?
В общем EEPROM - "это просто праздник какой то" ©
Предлагаю Все настройки узла туда загрузить
адрес, скорость шины, IP адреса, мастер/слейв/узел, debug и его ключи и пр. даже пока не придумывается.
с адресом , скоростью шины, IP адреса это да, но вот мастер/слейв/узел, debug и его ключи у нас же делаются с помощью директив условной компиляции и этот выбор происходит ещё когда скетч не в узле, а при компиляции, т.е. твой НЕХ файл когда создаётся. Сделать то можно будет, но всё через флаги только, а это память расходует.
и какой смысл эти данные держать в еепром, когда их как раз и нужно изменять при необходимости. А так они всё время из еепром одни и теже будут грузиться, без возможности выбора.
А 0xFF соответственно никому?
да всё верно
Кликабельно
#define NOT_INCLUDED 0x06 // если параметр отсутствует на узле
типы данных :
debug и его ключи у нас же делаются с помощью директив условной компиляции и этот выбор происходит ещё когда скетч не в узле, а при компиляции, т.е. твой НЕХ файл когда создаётся. Сделать то можно будет, но всё через флаги только, а это память расходует.
и какой смысл эти данные держать в еепром, когда их как раз и нужно изменять при необходимости. А так они всё время из еепром одни и теже будут грузиться, без возможности выбора.
Согласен. Тогда и мастер/слейв/узел тоже нет смысла (или в прошивке держать оба кода и узла и мастера ).
Ну в общем я про смысл прошивки.
Тем более что с таким набором и возможностью хранить произвольные типы. И вот в серьез подумать именно про твои настройки на епром 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 с теми же вызовани сделать на время отладки.
блин ну не пойму я смысла. Это всё и так лежит в энергонезависимой памяти, которая называется флеш. В ней залит скетч. В скетче есть эта информация. Дак нафига её в еепром то пихать? В том то и дело, если ты ничего подключать дополнительно не собираешься вообще не имеет смысла в еепром пихать. Т.к. туда пихается обычно изменяемая инфа. А постоянная она из флеша (скетча) спокойно также грузится.