На базе Ардуино Уно и климатических датчиков, взяв за основу готовый проект, доработал его по своим требованиям, добавил и вывел на улицу герметичный датчик температуры ds1820. Показалось мало. Добавил mp3 модуль, переписал скетч для станции с озвучиванием. Подумал и добавил реле для управления каким нибудь электроприбором. Опять мало и добавил модуль часов ds1307, опять же переписав скетч. Все режимы выбираются и включаются с телевизионного ИК пульта. Все данные и действия выводятся на OLED дисплей и озвучиваются. Демонстрация в файле.
Хорошо откоментировано!) Но у меня есть замечания, которые читать не обязательно. Спойлер: Замечания - слишком много делеев, хотя если работа удовлетворяет, то почему нет. Как я понимаю, если время попадает в 0 минут, то нужно ждать ~ 12-50 сек., до того момента как я смогу снова управлять прибором. - в процедуре switch только 1 case - в той же процедуре идут открывающие и закрывающие фигурные скобки подряд, так должно быть? - слишком много "магических чисел" в коде. - Большинство наборов if-ов можно оптимизировать применив switch-casе или else-if или проверяя в цикле Спс, за txt)
Согласен. Я в свободное время оптимизирую. Планирую все delay заменить и над if и циклами поработать. А магические цифры, это номера папок и файлов-треков на sd карте, ну и подсчет номера нужного для воспроизведения в зависимости от данных. Я вот только пока никак не могу оптимизировать определения конца трека в Mp3 DFRobotPlayer. Пробовал с помощью вывода Busy, не выходит. Толи сигнал опаздывает толи другая причина. Пока не понял. Может вы знаете?
Нет, я с ним не работал. Это любая цифра участвующая в коде - будь то время, имя папки или время задержки и т.п., которая читающему не понять без комментариев автора. Они приносят боль не только читающему, но и самому автору, когда он решит расширять возможности прибора. В любом случае, законченный проект это огромный опыт, который можно применить к следующему)
Согласен. Но без цифр никуда. А вот коментарии нужны, это да. Где то просмотрел, недописал. Но я работаю в свободное время. Это увлечение, за компанию с сынишкой.
А вот не подскажите как заменить delay на millis в промежутках между выводами и озвучиванием данных?. У меня пока не клеится. С таймером пооучилось, а в этих местах пока нет.
Там половину кода надо переписать, т.к. с делеями у нас конечный автомат всегда находится в определённом состоянии, а с миллис необходимо учитывать предыдущее состояние. Тут не подсказки слушать надо, а понять принцип работы МК устройств. Т.е. учиться составлять алгоритмы, а не кодингу. Закодить и обезьяна сможет по готовому алгоритму.
А зачем? Работает же... Проблема в том, что, ИМХО, стиль ардуины вынуждает новичка-программиста выполнять операции последовательно. С одной стороны это просто для понимания, с другой такие вот конструкции как у вас очень сложно "распараллеливаются". Тем более используется непонятная процедура myDFPlayer.playFolder ( число1 , число2 ). Как отреагирует проигрыватель когда вы попросите его воспроизвести 2 мелодии? а вдруг кто-то ещё и "стоп" нажмёт? Я советую завершить данный проект и перейти к следующему, уже зная некоторые нюансы и зная чего вы не знаете. Пример: У меня есть дисплей. Я ему написал несколько "экранов". Вызываю экран1 он мне выводит температуру, экран2 - время, экран3 - погоду на марсе. Показывать нужно некоторое время, чтобы человек мог спокойно прочитать. Ну что ж, раз в N (2-3 сек - человек успеет прочитать) сек. таймер смотрит какой экран нужно выводить и формирует команды на вывод, на том же таймере. Если вдруг мне нужно поменять экран, то я просто меняю номер выводимого экрана где-то в коде, чтобы через (меньше) N сек. таймер просто пошёл в другую ветвь в switch-case. У вас же какой-то неизвестный dfplayer, нужно почитать как работать с ним. Я бы организовал какой-нибудь буфер. В этот буфер помещал бы номера нужных дорожек и время на их воспроизведение и в лупе бы опрашивал буфер. Если он не пустой, то считать какую мелодию воспроизвести и сколько ей нужно времени. Вкл. воспроизведение и НЕ опрашивать буфер заданное время. Ещё любопытный момент. Индикация человеку не обязательна должна быть синхронна с внутренним состоянием МК. Пример: У меня есть датчик температуры и реле. Я вывожу температуру и состояние реле на экран. Но ещё я вычисляю скорость изменения температуры, если скорость больше VTmax, то я выключаю реле. Если у меня появится решение, о выключении реле, в то время пока дисплей НЕ меняется, то зачем мне организовывать срочное обновление информации на дисплее. Пусть уж человек подождёт N сек и дождётся когда на дисплее появится новая информация. И пожара нет, и человек информирован. Я считаю, что UI (пользовательский интерфейс) не должен мешать функционалу прибора. Вы с ребёнком это делаете, это будет сложно. Если быть кратким, то мой путь - усложнение программного кода.
Поддерживаю! Если автора устраивает работа агрегата, то норм! В следующем устройстве - изначально делаем с миллис и все!
