Arduino Mega. Контроллер теплицы. Хроники - 3.0

РЕКЛАМА НА ФОРУМХАУС

Обновил, попробуйте, плз, как оно сейчас. Если будет виснуть - буду подключать к Due внешнюю EEPROM и пробовать сам, т. к. надо разбираться, что именно не нравится Due.

 

@promavto, подключил внешнюю EEPROM к Due, выясняю причины зависания. Как пофиксю - отпишусь.

 

Нашёл ошибку, виснет вот здесь:

Код:

while((USART2->US_CSR & UART_SR_TXRDY) != UART_SR_TXRDY);

Разбираюсь.

 

Поправил, напутал с номерами UART. @promavto - просьба проверить, у меня сейчас всё стартует. Заодно сейчас поправлю в контроллере теплицы - там тоже, видимо, с этим беда под Due.

 

1. Пмсм, правильно.
2. Зависит от многих факторов: критично ли потребление слейвов, частота опроса, количество слейвов и т. д., т. е. смотрел бы по месту.
Сейчас, правда, очень медленно, заканчиваю беспроводные включатели освещения по второй схеме (батарейки - т. е. минимальное потребление, автоповтор уже заложен в nrf24l01 аппаратно, частота опроса очень низкая)

Пмсм, во время ожидания ответа от слейва можно чем-то другим заняться. Если взять для примера nrf24l01, то у него есть нога IRQ. Мастер выдает в эфир запрос, настраивает IRQ на прерывание по приходу пакета, а какой-нить свой таймер на прерывание по таймауту. Есть прерывание по IRQ - обработка, прерывание по таймауту - запрос следующему. Т. е. время на ожидание не тратится.

А такой вариант: слейв отправил данные, квитанцию не получил, повтор через (1мС*N), где N -номер слейва? (Цифры условные)

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

 

@timon2006, спасибо большое за ответ. Мне тоже кажется, что вариант номер 2, когда слейвы сами отдают данные в эфир - более прозрачен, т. к., по сути, не накладывает ограничения на кол-во собирающих информацию узлов (мастеров, назовём их так, для простоты). Да даже при наличии всего одного мастера - это сильно проще: мастер просто слушает эфир, принимая данные, и всё.

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

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

Ещё раз спасибо за ваши мысли.

 

Спасибо Дима! Завтра на работе проверю. А то Мега одна работала, а другая даже и не загружалась (перепроверял). Когда то была опция переключения Mega/DUE. Сейчас, я так понял, она убрана.

 

Это в ArduinoCore? Дык там для Due критична только настройка EEPROM на внешнюю, я ж сделал автовыбор EEPROM, и всё. Но настройки используемой EEPROM по прежнему можно менять, как хочется. Всё остальное - я завязал на выбранную в Arduino IDE плату: если выбрать Due, то автоматом скомпилируется под ней, если Mega2560 - под Мегу. Так удобней

В контроллере теплицы - обновил проверку статуса Serial для RS-485, когда компилируется под Due. Впрочем, оно и раньше не висло, иначе я бы заметил Ну и выбор платы в проекте контроллера теплицы - прежний: в Globals. h.

 

Пмсм, мастер обязательно должен подтверждать прием. Когда мастер не один - это проблема.

Мало того, в nrf24l01P добавили возможность прямо в квитанции пересылать пользовательские данные.
Вот к этому:

З. Ы. К сожалению, с LoRa пока тоже не работал.

 

Обновил ядро на гитхабе. Короче, с LoRa сделал пока просто (благодаря обсуждению тут), процитирую сам себя, из комментариев в исходниках:

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

Если квитанция не получена - слейв пытается N раз перепослать данные, после каждого неудачного отсыла чуть сдвигая время до отсыла следующего пакета. Если не получилось все N раз перепослать - считаем, что мастер в дауне, и засыпаем до следующего цикла.

Осталось дело за малым - таки запаять ножки на LoRa и попробовать на двух Mega это дело протестировать. Но пока - не могу, у мну сейчас с текущей шабашкой на одной Меге висит W5100 и SD, оба через 74HC125, на макетке, сопли, вопли, чудеса, и вообще - там лучше не трогать

Но логика кода вроде получилась понятная и правильная. Впрочем, вскрытие покажет

Теперь не спеша можно заниматься выгрузкой конфига в камень из конфигуратора, и после этого наступит долгожданный момент - главный скетч станет почти пустым (с конфигом по умолчанию мааахоньким), и всё будет настраиваться через конфигуратор. Вот тогда заживём

З. Ы. Неудачное название дефайна - CORE_LORA_DATA_SHIFT, не отражает суть, надо переименовать в CORE_LORA_TIME_SHIFT

 

Вынес часть новых настроек LoRa в конфигуратор - кол-во перепосылок пакета и интервал между посылкой данных с датчиков (до 255 секунд, ибо - 1 байт, не хотелось возиться ). Т. е. в будущем мона будет настроить и это дело. Пока представляется, что максимальный интервал в 4 минуты - это норм, хотя, если поступят предложения - готов рассмотреть, вдруг кому максимум 4 минуты маловато.

 

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

 

Arduino Core заработала на DUE.

 

А кого волнует каша в эфире? Радиоволны мешают дышать ? К тому же - при небольшом кол-ве устройств никакой каши не будет, т. к. всё настраивается - интервалы отсылки и пр. А при большом кол-ве устройств - каша всё равно будет, неважно, кто инициатор - надо ведь за разумное время опросить все устройства.

От регистрации в сети как раз я хочу уйти, именно поэтому всё заточено в этом направлении. Оставляю пока так, как сделал, всё равно LoRa ещё тестировать. Как покажет себя система - такие выводы и будем делать, по результату - будем что-то предпринимать.

 

Полностью с этим согласен