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

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

.

Я понимаю, Сергей, что я оч сильно поотстал от конструирования. В моём случае есть Мега + SIM800L, которые не хотят (пока) работать в проекте. Помню шаманские пляски с Neoweem, в частности с сигналом BOOT, стартующий модем.
Догадываюсь, что и тут не без сюрпризов. Вот и обращаюсь за помощью.
Гуглю, но безрезультатно.
Делал проект сигнализации на этом модуле - без шаманств: VCC, GND, Tx, Rx - взлетало сразу.

 

Да на STM32 просто так перейти не получиться. Кроме этого есть еще одна не изученная проблема - I2C. В интернете многие сталкиваются с нестабильной работой этого протокола.

Эта же беда и у DUE. Я сегодня целый день потратил (за исключением пары часов для приготовления и поедания шашлыка) на выяснение проблемы работы с микроконтроллером DUE.

Что удалось определить. Периодически, особенно во время перезагрузки зависает шина SDA ("0" на шине) протокола I2C. В минимальном варианте у нас там сидят часы и память. Сначала предположил что емкость (длина) проводников слишком большая. Установил буфер шины PCA9515 (благо вчера подошли с Китая), все равно зависает после нескольких нажатий на кнопку "Сброс".

Стал искать, что же подсаживает шину. Удалил микросхемы часов и памяти. Зависать практически перестало, но иногда все же подвисало. При этом программа дальше выполнялась, изображение на дисплее появлялось, но все работало с большими глюками.
Поставил переключатель на шину SDA, что бы рвать линию. Все это, конечно обвязал подтягивающими резисторами к питанию. Пытался определить с какой стороны блокируется - микроконтроллера или схемы. Но выяснить не удалось. Шина сначала заблокирована, разрываю - со стороны микроконтроллера идут импульсы, но и со стороны схемы высокий уровень. То есть шину не блокирует. Или микроконтроллер получает сигнал, что шина свободна и начинает обмен.

"Лечить" все это возможно только отключением питания контроллера на 5-10 секунд. Простой сброс проблему не устраняет. Предположил, что если питание поступает на микросхемы, блокирование шины продолжается и после сброса. Это подтверждает и то что подача разрешающего сигнала на буфер шины при старте с задержкой (закрываю буфер при старте на некоторое время, что бы все модули пришли в чувство) не решило проблему. Дополнительно подал сигнал сброса на микросхему часов, проблема не исчезла.

Поискал в интернете что нибудь на эту тему - у всех описана эта проблема на STM32. Решение очень сложное, нужно лезть в регистры, перезапускать модуль I2C (внутри микроконтроллера).
Оперировать с сигналами ACK и так далее. Толком решения нет.

Очень удивлюсь, если на STM32 шина будет работать без проблем.

Короче ..., как решать проблему. Сторожевой таймер перенацелить не на сброс микроконтроллера, а на разрыв питания на несколько секунд. Это конечно фигня, но на данный момент другого простого решения не вижу. Есть еще вариант попробовать сменить библиотеку работы с I2C я не говорю уж поковыряться в регистрах (или еще поискать в интернете). Но тут уж можно нарваться на пару слов от Димы. Еще короче. рвем питание и ждем манны небесной, может кто то решит эту проблему.

А с STM32, ох есть у меня предчувствие, но пробовать нужно.

 

Лог с монитора порта в студию плз, при раскомментированном GSM_DEBUG_MODE. Без этого - ничего сказать нельзя. Откуда я знаю, что там с модулем? Вдруг по питанию его чего не устраивает? Или просто с ним общения нет?

 

Короче, нашёл частично портированную UTFT под STM32, насколько это взлетит - хз. Сейчас на гитхаб закачиваются обновы, будем пробовать.

Да чего-то сплошные проблемы с этим камнем, если честно. Не было печали - поддался Дима на уговоры "большой дисплей, хороший камень, ..." - работало всё на меге нормально, теперь одни проблемы.

Устал я от этого проекта, сил нет. Закрою нахрен к чертям, и всё - оставлю только поддержку меги, самое то будет. То одно не работает, то другое - достало.

 

Могу описать работу SIM800C, модули почти одинаковые.

1) Подаем питание на модуль 3.8-4.2 в (вывод 34, 35 VBAT).
2) Подаем импульс положительной полярности 100-300мс на вывод 39 (PWRKEY).
3) Контролируем включение питания на выводе 42 (STATUS).
4) На выводе 41 (NETLIGHT) должны появиться импульсы около 850 мс. Это ожидание подключения к базовой станции.
5) После подключения к станции длительность импульсов становиться 3 секунды.
6) При подключении к интернет, длительность импульсов уже 350мс.
7) При повторной подаче импульса положительной полярности 100-300мс на вывод 39 (PWRKEY), модуль отключается.

 

Кмк, надо начинать сначала: брать тестовые скетчи работы с часами и памятью - и гонять их на камне. Не будет подвисать - значит, дело в прошивке. Будет подвисать - значит, дело в железе. Сразу гоняя всю прошивку - мы так ничего не выясним.

 

А кто говорил "..мало памяти, мало памяти.." Вот и кушаем вдоволь. Жене не признаюсь, что контроллер в теплице работает хреново. Температуру видит и хорошо, не нужно бегать на второй этаж.

 

Ну вот и ладушки, зато выяснили, что виноват Дима.

 

В том то и дело, что на УРОВ (в крайнем случае у меня) такое практически не проявляется.
Я уж подумал сравнить библиотеки часов, но не думаю что ты применил другую.
Есть конечно нюансы с запуском, но они в основном связаны с выводом программирования (нужно продавать питание перед программированием для очистки памяти). Но иногда переходные процессы на ключе во время включения питания стирают программу или что то с ней делают. Я даже пробовал удалять ключ и пользоваться только Native USB. Ну микроконтроллер иногда плохо определяется на парту USB. У меня большие претензии к USB портам на ПК. Даже приходилось применять два компьютера не хотел порт определяться хоть тресни, а на другом работает без проблем.
Как твои SAMD21, у тебя не работают, у меня все нормально продключаеться.

 

Да, ладно. Искусил то я!

 

А вообще, китайцы виноваты. Или хреново делают или плохо копируют. Или и то и другое.
А мы тут вместо отдыха разгребаем, аж голова трещит.

 

Вариант развития темы с Nextion: https://ru.aliexpress.com/item/7-0-NX8048T070-HMI-Intelligent-Smart-USART-UART-Serial-Touch-TFT-LCD-Module-Display-Panel-For/32805624267.html?ws_ab_test=searchweb0_0,searchweb201602_3_10152_10151_10065_10344_10068_5722815_10342_10343_10340_5722915_10341_10543_5711416_5722615_10696_10084_10083_10618_10307_10301_5722715_5711215_10059_308_100031_10103_5711515_10624_10623_10622_5711315_5722515_10621_10620_10125,searchweb201603_1,ppcSwitch_5&algo_expid=e85c485f-48df-4bc4-b660-92745f35ac59-0&algo_pvid=e85c485f-48df-4bc4-b660-92745f35ac59&transAbTest=ae803_1&priceBeautifyAB=0

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

Пожалуй, подумаю в этом направлении, ибо Due достала, а с STM32 пока неясные перспективы.

 

Я, кстати, сначала так и хотел, но потом схватился за осциллограф. Думал, сейчас за раз вычислю кто глючит. Сейчас вернусь к этой теме.

 

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

 

Нее. Денег стоит не меренно, и не факт, что I2C не устроит подлянку.