Программно уровень тоже регулируется (см. в софте Scale). Но подстроечник - это намного удобнее, поэтому его оставил. В первой версии схемы яркость регулировалась только программно. Потом подумал и добавил на плату подстроечники. Отвертка всегда под рукой. А тащить комп, подключаться к индикатору - это крайне неудобно.
Но настройка индикатора ведь в любом случае осуществляется с компа. Оптимальное значение с/ш и динамические характеристики индикатора взаимосвязаны, поэтому на мой взгляд удобнее крутить все коэффициенты программно. Но спорить не буду - схемотехника уже реализована и моё замечание - это просто реплика 'из зала' )
Схема нарисованная на компе неочевидным образом переключает левый и правый каналы при оцифровке... подстроечников видимо надо было бы нарисовать 2шт и как-то обозначить мультиплексор ацп. Но это тоже всё больше про бантики ) в целом индикатор получился приятный во всех отношениях.
С компьютера устанавливаются параметры, менять которые нет нужды. Они устанавливаются один раз. А регулировка чувствительности - это оперативная регулировка, удобнее подстроечник. В цифровом виде это регулировать хуже, будет теряться динамический диапазон. А так диапазон АЦП оптимальным образом привязан к шкале, а задача подстроечника - совместить ноль шкалы с нужным уровнем напряжения на входе.
В программе нарисован один канал измерителя. Параметры для правого и левого каналов общие, вряд ли будет хорошей идеей рисовать оба канала.
Вот и хороший конкретный пример, почему с++ в микроконтроллерах не только не нужно, но и вредно.
Например. Создаются два объекта TProcess. Для экономии места, я так понимаю, используются статичные калибровочные коэффициенты. Все бы хорошо, но переменные инициализируются в конструкторе каждого класса. Т.е. дважды. А загрузка из eeprom проходит вообще в третьем. И где тут принципы объектно-ориентированного программирования?
Я уже не говорю про дефайны и глобальные переменные.
Этот исходник - очень ранняя и сырая версия. Указанные переменные сделал статическими по ходу, решив, что для левого и правого канала всегда нужны общие настройки. Но пока в этом несколько сомневаюсь. Может и уберу статические. Инициализацию вообще забыл выбросить, она не нужна, так как делается при чтении EEPROM. Чтение EEPROM тоже пока решаю, куда вставить. Логичнее было бы в TProcess. Мне очень трудно составлять общую структуру программы, так как я не программист.
Если параметры оставить общими, тогда, по идее, их надо обернуть в отдельный класс TParams, который будет содержать методы Set, Get, чтения и сохранения в EEPROM. А объектам TProcess будет предоставлять параметры, например, по указателю. А может наследовать TProcess от TParams? Тогда в TParams должны быть статические поля.
Было бы интересней выслушать, как лучше сделать, а не то, что все плохо.
Согласен, что принципы ООП соблюдаются не полностью, но на чистом Си это выглядело бы еще хуже - все в одной куче.
Глобальные переменные какие имеете в виду? Статические параметры? Так они видны только в одном модуле, извне доступ к ним через геттеры - сеттеры.
Дефайны рекомендуют заменять на константы заданного типа. Но это тоже палка о двух концах. В некоторых случаях на константы компилятор тратит память. Макросы тоже не получается полноценно заменить инлайн-функциями. В готовых программах, которые приходилось видеть, обычно полно дефайнов. В фирменных библиотеках, например.
Выкинуть кресты на помойку. Отказаться от динамического выделения памяти (оно там нафиг не нужно, а пул ОЗУ поджирает). Сделать структуру, передавать ее параметром и все. Это просто, масштабируемо и не нужно каждый раз думать, как рефакторить, чтобы и памяти хватило и код не рассыпался.
Comments 72
Reply
Reply
Reply
Схема нарисованная на компе неочевидным образом переключает левый и правый каналы при оцифровке... подстроечников видимо надо было бы нарисовать 2шт и как-то обозначить мультиплексор ацп. Но это тоже всё больше про бантики ) в целом индикатор получился приятный во всех отношениях.
Reply
В программе нарисован один канал измерителя. Параметры для правого и левого каналов общие, вряд ли будет хорошей идеей рисовать оба канала.
Reply
Например. Создаются два объекта TProcess. Для экономии места, я так понимаю, используются статичные калибровочные коэффициенты. Все бы хорошо, но переменные инициализируются в конструкторе каждого класса. Т.е. дважды. А загрузка из eeprom проходит вообще в третьем. И где тут принципы объектно-ориентированного программирования?
Я уже не говорю про дефайны и глобальные переменные.
Reply
Reply
Было бы интересней выслушать, как лучше сделать, а не то, что все плохо.
Согласен, что принципы ООП соблюдаются не полностью, но на чистом Си это выглядело бы еще хуже - все в одной куче.
Глобальные переменные какие имеете в виду? Статические параметры? Так они видны только в одном модуле, извне доступ к ним через геттеры - сеттеры.
Дефайны рекомендуют заменять на константы заданного типа. Но это тоже палка о двух концах. В некоторых случаях на константы компилятор тратит память. Макросы тоже не получается полноценно заменить инлайн-функциями. В готовых программах, которые приходилось видеть, обычно полно дефайнов. В фирменных библиотеках, например.
Reply
Reply
Reply
Reply
Reply
Leave a comment