Я не специалист по высасыванию из пальцев, потому не берусь тут что-то комментировать. Вам виднее. При работе мк с пк лучше не изобретать велосипедов. После тестового эхо-проекта при подключении индикатора самое простое - перенаправить вывод символов на ЖКИ. Нужно давать людям дополнительную степень свободы в творчестве или работе, а не умышленно их ограничивать.
То, что вы цените своё время - это хорошо заметно, т. к. пока кроме словоблудия на сцене не видно ни инструкций, ни "простого батника", ни указания плюсов и минусов своего подхода. Одни только предъявления. Если это настолько просто, то что же остановило? Сделайте доброе дело и упростите жизнь коллегам. Мне даже из любопытства хотелось бы посмотреть на реализацию потокового фильтра.
uni писал(а):То, что вы цените своё время - это хорошо заметно, т. к. пока кроме словоблудия на сцене не видно ни инструкций, ни "простого батника", ни указания плюсов и минусов своего подхода. Одни только предъявления. Если это настолько просто, то что же остановило? Сделайте доброе дело и упростите жизнь коллегам. Мне даже из любопытства хотелось бы посмотреть на реализацию потокового фильтра.
Потоковый фильтр с регулярными выражениями - это по-вашему просто? А на Линуксе это тоже работает? Я не смотрел есть ли там исходник, но где гарантия что, пропуская все свои исходники через эту утилиту, она ещё чего-нить там не поменяет? Что в makefile писать и где? Куда нужно правильно расположить утилиту, чтобы при переносе проекта не забыть про неё?
Если вы такой правдоруб, то приведите и минусы такого подхода, ибо автор сделать это постеснялся.
uni писал(а):Потоковый фильтр с регулярными выражениями - это по-вашему просто? А на Линуксе это тоже работает? Я не смотрел есть ли там исходник, но где гарантия что, пропуская все свои исходники через эту утилиту, она ещё чего-нить там не поменяет? Что в makefile писать и где? Куда нужно правильно расположить утилиту, чтобы при переносе проекта не забыть про неё?
Если вы такой правдоруб, то приведите и минусы такого подхода, ибо автор сделать это постеснялся.
а я-то тут при чем? хотите - спрашивайте автора и все ваши вопросы - это ВАШИ вопросы, не мои. я на них отвечать не намерен. я как-то для себя нашел способ эту утилиту применять - и мне хватило. а на всех не напасешься.
особенно меня линух умилил вы б еще про apple спросили или андроид.
и при чем тут "правдоруб"?
битва с дураками проиграна, победители торжествуют. слава победителям!
Если ваш мир такой одноразовый, то это ещё не повод тиражировать его модель другим. Если вы так доверяете сторонним утилитам, то стоит напомнить, что автор написал свой grep - потоковый фильтр из мира Линукс. Ваш си-компилятор (скорее всего) и всё его окружение - изначально набор линуксовых утилит, в чём легко убедиться (потоковый фильтр egrep идёт в комплекте). Я больше бы доверял потоковой замене символов на его основе, т.к. это стандартная утилита, чем сторонней дополнительной утилите. Так что оставьте свои восклицания для девушек, они их оценят.
В мире проектировщиков ценят стандарты, а отклонения от известных путей обычно называют костылями. Ваш пример имеет право на использование, но это костыль, т.к. он по умолчанию несёт за собой ограничения и мы теряем в степенях свободы, о которых я говорил выше. Вариант с таблицей в исходном коде не имеет ограничений по ОС, на которой идёт разработка. И этот вариант может использоваться как универсальный, т.к. он устроит подавляющее большинство. Он компактен, прост и не требует вообще никаких дополнительных телодвижений в настройках проекта. Да он занимает 256 байт флеша - это очевидный минус, но далеко не всем это важно. Кроме того, таблицу можно очевидным образом уменьшить, как я писал выше.
Так что вы не убедили, но спасибо за ещё одну ссылку и обилие разумных доводов. Всегда приятно пообщаться с опытным человеком.
Я лишь спросил про возможность перекодирования, на этапе компиляции, как один из способов вывода кириллицы.
Считаю нужно рассматривать разные варианты. Пусть даже не очень гибкие..
По скорости и объему например, у статического варианта есть не большой выигрыш.
А применять тот или иной способ будет решать каждый сам в зависимости от задачи.
Использовал таблицу (uni) в проекте с STM32. Доволен..
Думаю, тут никто не против разных вариантов. Я просто предлагаю напротив каждого варианта приводить его ценник из плюсов и минусов. Если уж что-то советовать, то делать это грамотно. Мне бы и самому хотелось, чтобы перекодировка осуществлялась сама собой, но кто-то как-то должен выполнять эту работу. Если перенимать опыт, тот не плохо бы перенимать обоснованно хороший опыт.
Кстати, моя реализация этой табличной идеи специально сделана таким вот образом. Обрамление в виде комментариев сделано для быстрого ручного поиска пути перекодирования символа. Нижнюю часть таблицы (первые 128 байт) я оставил из-за нескольких символов, которых нет в знакогенераторе индикатора (обратной косой черты и фигурных скобок). Некоторые такие символы я заменил пробелом (но можно самому вписать адреса символов пользователя).
Что касается препроцессора, то это упрощённый язык программирования и как бы реализация такой функции на нём не выглядела, вряд ли это было бы также наглядно и удобно в использовании как табличной метод.
Думаю также, что скоростью работы в табличном методе можно пренебречь в виду того, что вывод символа занимает гораздо больше времени, чем табличное преобразование.
Да, если в проекте не планируется вообще использование вывода с ПК, либо подключение клавиатуры, либо любое другое взаимодействие через стандартные интерфейсы или, к примеру, программист не против заливать в репозиторий исходного кода ещё и дополнительный exe-файл (лично я против этого), то почему бы и не использовать?
Обычно в даташите пишут. Тут зависит от того, есть ли встроенный источник отрицательного напряжения и коэффициента мультиплексирования.
С источником работает от 3 В.
[ Всё дело не столько в вашей глупости, сколько в моей гениальности ] [ Правильно заданный вопрос содержит в себе половину ответа ]
На LCD 1602 в обеих строках на 8 знакоместе не засвечивается правая вертикальная полоска пикселей.
Видимо где то не контачит внутри.
Кто разбирал дисплей, подскажите можно там найти причину и исправить, или не стоит даже пытаться?
И еще вопрос.
Подключаю готовую резиновую матричную клавиатуру 6х3 (от охранной системы). Особенность - 3 столбца резисторами 100к подтянуты к общему проводу. Т.е. опрос 6 строк ведется подачей лог. 1 через резисторы 1 кОм. Но 6 строка в приборе сформирована через отдельный элемент И со строк 4 и 5 (видимо не хватило ног у МК). МК - Zilog R911.
Заменяю на МК ATtiny2313 с подключенным LCD 1602 по 4х-битной шине
Может быть уже обсуждались похожие проблемы?
Как в таком случае бороться с дребезгом?
P.S. После многократного нажатия на стекло LCD в районе 8 знакоместа работа восстановилась, так что это неконтакт видимо резинки со стеклом LCD (аппаратная проблема).
