Простой стабилизированный регулятор мощности ТЭНа из китайских модулей (Страница 19 из 73)

Покритикую?

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

Не факт. Работать с кусками байта в ардуине не особо комфортно.
Придётся формировать некий буфер, кратный байту, потом отсылать его.
Нуегонах, а?
А так взял байт целиком и послал его в порт.
Одна команда.
---
По большому счету ресурсов что на отсылку 4, что 20 байт, много не надо.
Охота тебе была писать упаковщик-распаковщик на стороне ардуины?
Он же ресурсов сожрёт.

А зачем оно нам?
Если оно малО для установки нужного значения на выходе, то этим же ошибка №хх заведует.

Лишний код. Я думаю в этом случае проще сразу слать человекомсъедобные данные.

Думаю вид и модель стабилизатора не должна иметь никакого значения для внешнего устройства.
На мой взгляд стабилизатор должен давать данные, которые он способен измерять и регулировать.
Исходя из них внешнее устройство примет решение, какую величину регулировать можно, а какую нет смысла - отклика не будет.
Т.е., если агрегат выдаст в поле "желаемое напряжение" строку "....", то значит регулировку по напряжению он не поддерживает
и посылать ему команду "установить напряжение 195.5 вольт" не имеет смысла.
Если ещё и в поле "желаемая мощность" такая же "....", то это вообще не регулятор, а просто измеритель,
посылать ему команды нет смысла, мирно курим и показываем на индикаторе измеренные значения.
Так же и с другими полями.
Это я к моему варианту.
Ну а байт под режимы/ошибки тоже лишним не будет.
Мало ли, что в будущем в голову взбредёт, а места в битовом поле уже нет.
Там всего 8 вариантов, а ASCII байтов несколько больше, как минимум 96.
Обидно будет.

Может это издержки arduino ide ?
Я то на асме всем этим извращаюсь, так сказать ближе к железу. 
Там натолкал данные в буфер в ОЗУ, включил прерывание UART "буфер передачи пуст" в нужный момент времени и всё.
Оно само работает и никому не мешает.
А как в ide, я не знаю, может как по-чудному сделано.

Не только. Используя его можно легко отделять "мух" от "котлет".
Вот смотри.
Ты предлагаешь использовать для передачи данных весь диапазон значений байта от $00 до $FF.
А также завершать пакет символом $0D.
Следовательно этот символ должен встречаться только в конце передаваемых данных и нигде больше.
Но что делать, если измеренная величина, та же мощности, содержит в своем теле код $0D ?
Например 3341 Вт это $0D0D или 180.5 Вольт это $070D .
Программа приемник посчитает этот $0D концом данных и всё что после началом нового блока данных.
Вот тут и начнутся чудеса.
ASCII, да передаваемый пакет больше, но такого пердимонокля в нем не произойдёт.

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

Не должна, я на одно из своих игрушек отправляю по 80 байт ежесекундно на скорости 9600 и всё нормально.

Ага.

Так она и неизвестна.
Фиксированная длина ничего не даёт.
У нас отсутствует возможность узнать, что очередной принятый байт принадлежит текущему пакету данных, а не следующему.
Вот, допустим, передаём 4 байта. 0-1-2-3. Следом ещё 4 байта 4-5-6-7. Потом ещё 8-9-10-11.
Байт "2" каким-то образом потерялся.
Помеха в линии, барабашка, сбой передатчика, всё что угодно.
В приемнике, нарезающем принятые данные только по длине, получим:
0-1-3-4
5-6-7-8
9-10-11- и что там дальше...
Всё, синхронизация потеряна, а восстановить нет возможности.
"Строб" отсутствует.
Данные, полученные таким способом, становятся дракхом.

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

Тоже не особо радуют пустые поля.
Можно передавать данные в пакете, разделённые запятыми.
Т.е. пакет со всеми данными будет такой: (например)
Байт синхронизации,значение1,значение2,значение3,значение4, признак конца пакета (запятые тоже передаются).
Если какой-то величины нет, то и не надо ничего передавать, будут две или больше запятых подряд.
Байт синхронизации,значение1,,,значение4,признак конца пакета(значения 2 и 3 не передаются, запятые передаются)
Перед признаком конца пакета запятую можно не ставить.
----
Можно в принципе передавать сколько угодно данных в пакете, но надо однозначно зафиксировать первые несколько мест за конкретными данными.
Между запятых данные по-идее могут быть не фиксированного размера.
Где надо два байта - передаем два, где пять - передаём пять.
А остальное уже по желанию.
----
Тоже избыточно, но у нас и объёмы передаваемой информации мизерные.