Простой копировщик домофонных ключей - Страница 619

petr5555 · 27.01.2016, 18:39

Опять борьба за mA.

Тогда уж вообще надо выкинуть всё лишнее.
В том числе и детектор. Это абсолютно ненужная функция.
При разряде батареи всё равно сначала исчезает индикация на дисплее.
А блок для работы с RF ключами сделать съёмным......

Конечно самое правильное - это отказаться от схемы с двумя МК.
И сделать всё на одном....

NewWriter · 27.01.2016, 20:15

Да это не борьба за миллиамперы. Это борьба за КПД. Разве ж плохо? по-моему, нет. Энергоэффективностью не пренебрегают и серьезные производители. А мы то тут чем хуже?

Сообщение от petr5555

Конечно самое правильное - это отказаться от схемы с двумя МК.

Насколько я понял, не хватило буквально пары-тройки выводов и некоторого количества строчек кода? Нууу в принципе, выводы утолкать то можно, причем без проблем, а для кода оптимизировать надо.

RECTO · 27.01.2016, 21:03

Сообщение от NewWriter

Однако, судя по получаемой структуре, пишется на Си.

Ну, насчёт Си скромно промолчу, а вот касательно текстов сообщений...

Сообщение от NewWriter

Взять например формирование текстовых сообщений. Около 1100 программных слов они занимают. То есть, более чем четверть ёмкости, просто на текст! А сообщения ведь можно ужать в два раза, не потеряв ни буквы! В два, прикиньте! До 650 программных слов. И это просто если подумать о том, какие средства заложены в 88-й. То есть, вместо того, чтобы получать символ универсальным retlw, прибегаем к возможности читать и передавать содержимое произвольной ячейки памяти программ, через EEPGD=1 в регистре EECON1 - Accesses program memory.

Это значит, нужно будет отказаться от поддержки 628-го и 648-го ПИК-ов. Они таких возможностей не предоставляют, к сожалению.

Сообщение от NewWriter

Ну а главный секрет сжатия в том, что выводимые на индикатор символы - 7-битные (старший восьмой бит только для переключения кодовых страниц, то есть, языков алфавита), а ячейка памяти программ - 14-битная, значит, в нее помещаются два символа, безбаразу, отвечаю

.

Идею Вашу я понял, но как её реализовать в данном случае - не совсем. Беда в том, что у этих дисплеев нет полноценной "русскоязычной" страницы. В ней нет символов, совпадающих по начертанию с латинскими и они берутся из "младшей" части таблицы. То есть, например, в слове "заготовка" будет 5 русских символов и 4 латинских, причём с чередованием. Придётся всё время переключаться...

Сообщение от NewWriter

Чем лучше? Тем, что можно использовать экономичный микромощный ИОН и получить программную установку порога для "батарея разряжена" (в том числе, изменяемую юзером, заменой одной цифры в EEPROM), а так же вообще для индикации степени разряда батареи.

В общем, да, идея хорошая...

Сообщение от NewWriter

То, что сотня человек собрали устройство, это не говорит о том, что не нужно его никак изменять. Изменение конструкции - это нормальная тема. Заставлять переделывать не надо. Будет просто другая конструкция, более совершенная. Это нормально. Вон, в инструкциях на промышленные приборы часто приходится видеть "производитель имеет право изменять конструкцию..."

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

NewWriter · 27.01.2016, 21:38

Сообщение от RECTO

в слове "заготовка" ... Придётся всё время переключаться...

Да, разумеется. И именно поэтому перед сохраненным словом "заготовка" идет 14-разрядное слово (в памяти программ то), из которого как раз и берется бит для каждой буквы, определяющий страницу. Конечно, получается не чисто в 2 раза сжатие, но экономия есть. Я пробовал. Наибольшая эффективность при сообщении длиной, кратной 14. Ну и количество текста должно быть большим, чтобы накладные затраты на дешифрование не были столь заметны.

Сообщение от RECTO

В общем, не хотелось бы менять схему без действительно веских на то оснований...

Ну, дело хозяйское, конечно... А пардон, сколько лет этой схеме? Я просто не читал всей темы. Лет 5 вроде?

buny · 27.01.2016, 23:50

Сообщение от reviver

Вот например; от принтера XEROX WORKCENTRE 3119:

практически любая серия имеет исполнение без подсветки. и у мэлта, и у вина, да и остальных...

RECTO · 28.01.2016, 00:20

Сообщение от NewWriter

Да, разумеется. И именно поэтому перед сохраненным словом "заготовка" идет 14-разрядное слово (в памяти программ то), из которого как раз и берется бит для каждой буквы, определяющий страницу. Конечно, получается не чисто в 2 раза сжатие, но экономия есть. Я пробовал. Наибольшая эффективность при сообщении длиной, кратной 14. Ну и количество текста должно быть большим, чтобы накладные затраты на дешифрование не были столь заметны.

Ну да, понятно в общем... Да, это вполне можно было бы использовать, если бы читать программную память позволял не только 88-й ПИК, но и 628-й и 648-й...

Сообщение от NewWriter

Ну, дело хозяйское, конечно... А пардон, сколько лет этой схеме? Я просто не читал всей темы. Лет 5 вроде?

Конкретно этой схеме - поменьше, года три... Но я писал уже чуть ранее - следующее обновление (6.23, с поддержкой ТМ-01А будет для нее уже последним, скорее всего). Следующая версия (7.00) будет с другой схемой, на другом ПИК-е.