Что-то я не уловил принцип работы «кольцевого буфера с кольцевой меткой». Если сохранять ссылку на текущее положение метки в EEPROM, то ресурс также будет расходоваться, а если не сохранять, то после рестарта система не будет знать где находятся актуальные данные. Кто-нибудь может объяснить сам принцип работы «кольцевого буфера с кольцевой меткой»?
Если имеете дело с массивами — используйте sizeof(). И sizeof(array)/sizeof(array[0]). И не будет таких ошибок.
Про это я естественно знаю и использую. Тут же дело в том, что этот многострадальный модуль был написан ещё за 3 года до появления АМС, т. е. 5 лет назад и работал в жёстко детерминированной системе в конфигурации 1/13.
Там не предусматривалось никаких изменений по каналам, поэтому и код такой. Потом модуль был интегрирован в АМС тоже в жёсткой конфигурации 1/13, а уже потом… я решил добавить возможность изменять количество каналов, а про отправку данных MajorDoMo просто забыл, потому, что к тому времени уже не использовал её.
Олег, дорогой мой, ваши попытки меня уесть с помощью копания в legacy-коде двухгодичной давности просто жалки — не позорьтесь. Вы задеты и уязвлены потому, что не привыкли, чтобы вам указывали на ваши ляпы и, как следствие, ваша реакция крайне предвзята.
Олег, у меня к вам вопрос: вы всегда пишете идеальный код который в принципе не содержит ошибок и всегда представляет собой идеальное решение? А если вы всё-таки иногда ошибаетесь, то откуда такое остервенение в ваших комментариях?
В экспериментальной ветке потокового декодера эта функция давно переписана в виде:
void addFN(char c) {
for (int i = MAX_FN_BUFFER - 1; i > 0; i--) {
fn[i] = fn[i - 1];
}
fn[0] = c;
}
в основной ветке код остался старым потому, что модуль сложный и легче его заменить целиком после отладки экспериментальной ветки, чем улучшать каждую функцию в отдельности.
Олег, посмотрел я код и вы правы — это ошибка. Поясню. Изначально этот модуль проектировался для конфигурации 1 канал напряжения и 13 токовых каналов и если выставить как было изначально
#define MAX_UI_SENSORS 14 // max 14
то ошибки не будет. В дистрибутиве количество токовых каналов уменьшено до 1 потому, что не всем нужно большее количество каналов и математика модуля отъедает очень много памяти.
А фрагмент отправки данных в MajorDoMo я просто забыл поправить, но это несложно сделать и в следующей версии я эту ошибку исправлю.
Читаю я ваши комментарии и удивляюсь: вы на лету точно схватываете все тонкие нюансы, которые до народа обычно не доходят даже после усердных объяснений. Любопытно, если не секрет, какой у вас опыт разработки и интересы в микроконтроллерной области?
Естественно, далеко не все кто скачивал устанавливали и работают с АМС, просто объективно оценить количество работающих систем мы не можем (поскольку они не шлют нам никакую телеметрию), объективно нам доступны только данные о скачивании, поэтому они и указываются.
Вот и выходит, что с вашей библиотекой софтовых таймеров не поморгаешь светодиодом на 1 кГц в параллель с обработкой данных от сенсора температуры.
Тут есть два разных момента: во первых, библиотека из статьи никакого отношения к пяти светодиодам не имеет — она предназначена совсем для других целей.
Во вторых, 1-wire датчики температуры имеют вполне приемлемый режим с дельтой 0,25 С и задержкой 190 мс и даже 96 мс при дельте 0,5 С, что во многих случаях тоже приемлемо.
И да, вы правы, мигать быстрее этих 96 мс не получится, но при скважности задержки 96 мс в 5 минут (типичное время замера температуры) на реальных задачах это особой роли не играет потому, что 99,(9) процентов времени в системе остаются типовые задержки в районе 10 мс.
Если нужен жёсткий реалтайм, то конечно это решение не подходит.
А уж про сотни сущностей и говорить не приходится.
Просто скачайте дистрибутив и ознакомьтесь с его работой.
Не совсем так, проблема в самом контроллере и связана она с режимами его работы и питанием. При некоторых условиях (редких) вачдог не срабатывает. Производитель об этом знает. Ссылки на статьи об этой проблеме и документацию можно погуглить.
Олег, вы ведёте себя мелочно и недостойно — вырываете неудачные (тестовые) куски кода из системы версии 0.17, то есть фактически концепта будущей полноценной системы.
По поводу недостатков платформы — это только версия 0.17 и вам эта цифра должна о многом говорить. Предъявлять какие-то претензии к проекту на такой стадии просто странно. Говорить о том, что проект развивается и через какое-то время все его «шестерёнки» улучшаться даже нет смысла, это само-собой.
Что касается вачдога на ATMega2560. У меня складывается впечатление, что вы, Олег, очень одинокий человек, в том смысле, что на Олимпе, на котором вы находитесь, вам уже давно не встречался человек который может вам аргументированно возразить и поставить вас на место.
И это играет с вами злую шутку — если вы имеете дело с достойным оппонентом, то вы с умным и многозначительным видом постоянно попадаете впросак. Если бы вы лучше разбирались в вопросе, а не только вещали с Олимпа, вы бы знали, что проблема с вачдогом на ATMega2560 — это известная проблема, о ней есть информация как в интернете, так и в документации производителя.
Так что, Олег, мой вам совет: снимите корону (она вам только мешает) и относитесь к людям попроще, а на вопросы смотрите поширше.
Про это я естественно знаю и использую. Тут же дело в том, что этот многострадальный модуль был написан ещё за 3 года до появления АМС, т. е. 5 лет назад и работал в жёстко детерминированной системе в конфигурации 1/13.
Там не предусматривалось никаких изменений по каналам, поэтому и код такой. Потом модуль был интегрирован в АМС тоже в жёсткой конфигурации 1/13, а уже потом… я решил добавить возможность изменять количество каналов, а про отправку данных MajorDoMo просто забыл, потому, что к тому времени уже не использовал её.
Вот и вся история вопроса.
в основной ветке код остался старым потому, что модуль сложный и легче его заменить целиком после отладки экспериментальной ветки, чем улучшать каждую функцию в отдельности.
то ошибки не будет. В дистрибутиве количество токовых каналов уменьшено до 1 потому, что не всем нужно большее количество каналов и математика модуля отъедает очень много памяти.
А фрагмент отправки данных в MajorDoMo я просто забыл поправить, но это несложно сделать и в следующей версии я эту ошибку исправлю.
Откуда вы взяли цифру 300 мс? Вы её измеряли или вывели из чего-то?
Тут есть два разных момента: во первых, библиотека из статьи никакого отношения к пяти светодиодам не имеет — она предназначена совсем для других целей.
Во вторых, 1-wire датчики температуры имеют вполне приемлемый режим с дельтой 0,25 С и задержкой 190 мс и даже 96 мс при дельте 0,5 С, что во многих случаях тоже приемлемо.
И да, вы правы, мигать быстрее этих 96 мс не получится, но при скважности задержки 96 мс в 5 минут (типичное время замера температуры) на реальных задачах это особой роли не играет потому, что 99,(9) процентов времени в системе остаются типовые задержки в районе 10 мс.
Если нужен жёсткий реалтайм, то конечно это решение не подходит.
Просто скачайте дистрибутив и ознакомьтесь с его работой.
Что касается вачдога на ATMega2560. У меня складывается впечатление, что вы, Олег, очень одинокий человек, в том смысле, что на Олимпе, на котором вы находитесь, вам уже давно не встречался человек который может вам аргументированно возразить и поставить вас на место.
И это играет с вами злую шутку — если вы имеете дело с достойным оппонентом, то вы с умным и многозначительным видом постоянно попадаете впросак. Если бы вы лучше разбирались в вопросе, а не только вещали с Олимпа, вы бы знали, что проблема с вачдогом на ATMega2560 — это известная проблема, о ней есть информация как в интернете, так и в документации производителя.
Так что, Олег, мой вам совет: снимите корону (она вам только мешает) и относитесь к людям попроще, а на вопросы смотрите поширше.