Спасибо Вам, за конструктивный подход к диалогу. Сразу оговорюсь, что в плане разработки программного обеспечения есть над чем работать… и при чем усердно!) В плане аппратаной реализации кстати тоже, но там опыта поболее. Да и работаю я, к сожелению, не по специальности, поэтому электроника и программирование вмещаются в промежутки свободного времени.
Структуры стараюсь использовать как можно чаще, но иногда автоматически набиваю куски быдло-кода, а приводить все к «правильному» структурированному виду либо не успеваю, либо просто забываю. Я понимаю, что «правильно» писать код нужно изначально, но все же, не всегда это получается…
По поводу контролля данных — возможно, я просто непридал этому необходимого значения. Данные, которые передаются с программы на ПК в устройство, записываются в буфер, который опять возвращается на ПК и там происходит сравнение отправленных и принятых данных. Возможно, это не лучший вариант реализации. Я думал про CRC16, но видимо желания не хватило довести все до необходимого уровня. Текущие данные, отправляемые на ПК для отображения информации, посчитал излишним контроллировать, т.к. даже если они будут некорректными, то через 3 секунды будет следующий пакет для отображения. Да и более чем для отображения они нигде не фигурируют. Я согласен, что все транзакции, передачи данных в устройстве должны контроллироваться! Все это будет реализовано в последующей доработке ПО.
Сложно самому все предусмотреть и реализовать на достойном уровне. Поэтому я и выложил весь проект с исходниками, и благодарен всем, кто тратит на это свое время.
Я Вас понял. Но можно уточнить, зачем такие повышенные требования к проверке EEPROM? Для какого именно случая? Пропадание питающего напряжения во время записи, или искажение данных с течением времени? За много лет использования ни разу не было подобного случая.
Извиняюсь заранее, но сложно уследить за всем, что пытаешься реализовать. Спасибо, что обратили внимание — действительно недочет! Хотя на практике работает без сбоев, но все же! В моей прошивке, конечно же, нужно реализовать немного по-другому. Самое простое — выставлять оба флага: и по началу записи данных в EEPROM, и по ее завершению. Если выставлен один из двух флагов — значит запись была прервана, необходимо повторить запись и/или вывести соответствующую индикацию об ошибке. Чуть более сложный вариант — делать несколько флагов, через определенное кол-во ячеек памяти, дабы повысить вероятность проверки целостности данных. Это как вижу я… Если Вы предложите что-то более рациональное — буду весьма благодарен! Что же касается целостности данных в EEPROM — вопрос весьма неоднозначный. За все время эксплуатации контроллеров AVR не встречался с подобным. Единственное, с чем приходилось сталкиваться — это с ошибками записи в первые ячейки памяти EEPROM, вроде как даже в Errata было описано подобное, но ручаться не буду, нужно перепроверить. Если же во время записи данных в EEPROM пропало питающее напряжение, то этот случай можно отследить при помощи стартового и завершающего флагов. Поэтому при соблюдении требований по питанию и помехоподавлению несанкционированных изменений данных в EEPROM быть не должно.
Если говорить честно, даже не знаю, почему Bluetooth был реализован отдельным модулем. Почему-то изначально была принята подобная концепция. Хотя, конечно, расположение всех составляющих компонентов предпочтительно на одной плате. Да и свободного места на плате достаточно, — нет нужды ставить что-либо вертикально, нарушая эстетичность вида!) Нужно лишь немного поиграться расположением проводников. Тоже самое я уже осмыслил и на счет усилителя электродов. Будет учтено в будущих конструкциях.
Какое отношение имеют обитатели аквариума к управляющему контроллеру? Сегодня это маленькие неприхотливые рыбки, завтра — дискусы или другие товарищи. Текущее фото прямого отношения в теме не имеет!) Попросили — я выложил. Кстати, там порядка 100 рыбок, если их не видно фото, это не занчит что их там нет.
По поводу расстояний между силовыми дорожками 220В и земляным полигоном — согласен, что больше расстояние тем лучше. Но и коммутировать кВт нагрузки я им не собирался. Если будет таковая надобность, в следующем устройстве это тоже будет учтено. По поводу влажности — 2 кулера, периодически выгоняющих воздух из крышки, вполне достаточно.
Что бы не скапливался конденсат в крышке установлено 2 кулера, и организован программный режим продувки. Через заданный интервал времени они включаются и продувают курышку. Как показала практика — этого вполне достаточно даже для высокой температуры воды и большого кол-ва испарений.
Более подробная информация есть в «Техническом описании», выложенном на github. Там же приведена схема платы усиления. Для замеров используется самый обычный стеклянный pH-электрод, предназначенный для измерения и контроля уровня концентрации свободных ионов водорода в воде в бытовых и промышленных установках, оснащенный BNC штекером. К примеру электрод-pH E201-C-9. Каллибровка коэффициентов программного обеспечения производится по 2 растворам, чаще всего со значениями 7 и 4 ph.
Стараюсь подходить к решению любого вопроса максимально ответственно!) Возможно не всегда это получается, но все же стараюсь продумывать наперед. Прикрепляю фото обитателей аквариума:
Структуры стараюсь использовать как можно чаще, но иногда автоматически набиваю куски быдло-кода, а приводить все к «правильному» структурированному виду либо не успеваю, либо просто забываю. Я понимаю, что «правильно» писать код нужно изначально, но все же, не всегда это получается…
По поводу контролля данных — возможно, я просто непридал этому необходимого значения. Данные, которые передаются с программы на ПК в устройство, записываются в буфер, который опять возвращается на ПК и там происходит сравнение отправленных и принятых данных. Возможно, это не лучший вариант реализации. Я думал про CRC16, но видимо желания не хватило довести все до необходимого уровня. Текущие данные, отправляемые на ПК для отображения информации, посчитал излишним контроллировать, т.к. даже если они будут некорректными, то через 3 секунды будет следующий пакет для отображения. Да и более чем для отображения они нигде не фигурируют. Я согласен, что все транзакции, передачи данных в устройстве должны контроллироваться! Все это будет реализовано в последующей доработке ПО.
Сложно самому все предусмотреть и реализовать на достойном уровне. Поэтому я и выложил весь проект с исходниками, и благодарен всем, кто тратит на это свое время.
По поводу расстояний между силовыми дорожками 220В и земляным полигоном — согласен, что больше расстояние тем лучше. Но и коммутировать кВт нагрузки я им не собирался. Если будет таковая надобность, в следующем устройстве это тоже будет учтено. По поводу влажности — 2 кулера, периодически выгоняющих воздух из крышки, вполне достаточно.