Офигеть, из Китая за 12 дней дисплюй на ST7920 приехал! Я его если честно раньше конца февраля и не ждал!!!
Приветствую! А не подскажете более подробно как выписать из Китая дисплей. Я ссылку видел, но много непоняток. Вы какой заказали? Можно в личку sergeyn22@gmail.com Заранее благодарю
Такой вопрос по обучению пульта. При обучении пульта на экране появляется код кнопки и он сохраняется, но усилитель не начинает реагировать на новую кнопку. В чем может быть проблема? И еще вылез такой баг: при быстром нажатии любой из кнопок примерно через 3 - 5 нажатий вместо кода кнопки считывается код 00. Это баг пульта или прошивки?
Доброго времени суток всем. Скажите автор, а реально ли реализовать вашу схему с прошивкой под дисплей от Нокиа или Сименса, ну или от китайца какого? Если да, можно краткий курс о том, что нужно добавить/изменить/удалить? Заранее благодарен
З.Ы. У меня ресивер Grundig hi-fi receiver 30, тюнер давно не работает, усилитель немного переделан/модернизирован, а на месте шкалы осталось пустое место. Хотелось бы собрать туда это устройство, с тюнером и с дисплеем по-больше. Правда, родной тембр блок прийдётся или отключить или не использовать цифровой...
Изначально прошивка делалась на ATmega16 с 1кБ памяти. При этом поддерживались разные дисплеи - KS0108A/B (128x64), LS020 (176x132) и даже знакосинтезирующие. Естественно, что ввиду разного размера в пикселах любые экраны приходилось отрисовывать для каждого дисплея по-своему. Например, функция отображения информации от пульта (тестовый режим проверки пульта):
И так, по большому счёту, написан весь файл (и не только он) для вывода на экран. Сплошные #ifdef/#else и т.д. инструкции препроцессора. Это всё потому, что изначально планировался только один вариант железа, а уже потом пользователи стали просить добавить поддержку то того, то другого.
Это долго, сложно, громоздко. При добавлении новой функции, выводящей что-то на экран, приходилось реализовывать её для каждого дисплея по своему, учитывая его размеры и особенности работы.
После перехода проекта на ATmega32 решено было для ускорения вывода на экран использовать кадровый буфер и ограничиться размером экрана 128x64. Принцип простой - имеется массив 128x64 точек и мы рисуем картинку не в дисплей, а в этот массив. В частности, та же функция для работы тестового режима начинает выглядеть уже так:
Гораздо короче, но, при этом, гораздо функциональнее.
Весь специфичный для дисплея код описан в соответствующих файлах - ks0108.c и st7920.c.
Всё, что нужно - это: 1. Реализовать кадровый буфер - массив fb[] - размером 1 кБайт (в случае ks0108 это массив 128x8, в случае st7920 это массив 32x32 - это с учётом организации пикселов в байты в этих дисплеях). 2. Написать функции для инициализации дисплея (init), очистки (clear) и для записи пиксела (drawPixel) в этот буфер. 3. За счёт таймера Timer0 организовать периодическую запись информации из буфера в дисплей.
Таймер настроен на вызов прерывания по переполнению 20000 в секунду (т.е., с периодом 50мкс). При каждом вызове он стартует АЦП, обеспечивая 10кГц анализ Фурье и пишет очередную пачку данных из кадрового буфера в дисплей. За 50 мкс дисплей вполне успевает обработать эту запись и быть готовым к следующей.
Итак, принцип такой: а) любые функции пишут что-то в буфер (через функцию записи пиксела по нужным координатам), при этом не заморачиваясь по поводу экрана. б) таймер, вызываясь 20000 раз в секунду, записывает очередной байт из буфера в экран. При размере буфера 1024 байта и небольших накладных расходах на позиционирование в начале строки весь экран обновляется около 18..19 раз в секунду.
Если нужно в эту систему добавить свой дисплей (свой файл myDisplay.c), нужно: а) чтобы он имел те же размеры 128x64 б) завести 1кБ буфер для хранения картинки в) написать обработчик прерывания таймера 0, записывающий очередной байт из буфера в дисплей и переходящий на следующий байт для будущей записи
В общем, архитектура проекта в плане работы с дисплеями, такова:
Код:
ks0108.h / ks0108.c / / остальные ----- gdfb.c --- st7920.h файлы gdfb.h st7920.c проекта \ \ \ myDisplay.h myDisplay.c
gdfb.c/gdfb.h - это своего рода абстрактный 128x64 дисплей, пробрасывающий графические функции дальше конкретному дисплею. И именно в него попиксельно рисуется картинка.
В принципе, подобным образом написаны и другие вещи (абстрактный тюнер + конкретные реализации, абстрактный аудиопроцессор + конкретные реализации), но там это не так сильно заметно, особенно по поводу аудиопроцессоров. Просто нет времени доделать это всё "красиво", да и, как говорится, работает - не трогай.
В исходниках в Makefile всё есть. Если настроить avrdude, то команда make - соберёт прошивку make flash - прошьёт make eeprom_<lang> - зальёт eeprom с нужным языком make fuse - зашьёт фьюзы
Уважаемый WiseLord, похоже я один кто повторил Ваш бюджетный вариант на ATmega 8. Все было прекрасно пока не собрал весь усилитель, не знаю, может так и задумано, но есть некоторые неудобства. В контролере управления, ATmega 8, все настройки (№ входа, настройки уровня громкости и тембров и т. д...), сохраняются. А вот аудиопроцессор, после отключения питания, возвращается в исходное состояние, то есть после включения приходится регулировать все по новому или же, не снимать питание с аудиопроцессора хотя бы в дежурном режиме. Можно ли сделать так что бы при включении ATmega отправляла в аудиопроцессор все сохраненные параметры, или может я что-то не так сделал. Заранее спасибо.
WiseLord, понял, спасибо. Ещё такой интересный вопрос: SC7313S откопал на плате со старой магнитолы. По данным интернета - клон TDA7313. Но, если вдруг что-то не так будет, какие данные из даташита брать для написания под этот проц кода? От этой же магнитолы есть тюнер на LA1787.
Все параметры, в том числе и звуковые, сохраняются в EEPROM при выходе в ждущий режим. После этого питание с контроллера можно снимать.
При подаче питания на контроллер эти параметры снова вычитываются из EEPROM и по I²C-шине инициализируют аудиопроцессор.
Наблюдаемый Вами эффект не должен проявляться. Если, конечно, Вы при входе в ждущий режим по какой-то причине не обесточиваете аудиопроцессор. Естественно, потом, при подаче питания, он находится в некоем своём дефолтном состоянии.
На данный момент схема (не только ATmega8-вариант) рассчитана на то, что аудиопроцессор запитан постоянно, в том числе и в ждущем режиме.
Если у Вас схема сделана так, что в дежурном режиме питание аудиопроцессора пропадает, то такой эффект вполне может наблюдаться.
На всякий случай, последние на текущий момент прошивки для ATmega8.
Ещё такой интересный вопрос: SC7313S откопал на плате со старой магнитолы. По данным интернета - клон TDA7313.
В китайских магнитолах менял эту микросхему на TDA7313, все функции работали как и с родной. WiseLord, питание с аудиопроцессора снимал специально выключением усилителя, переделать питание на аудиопроцессор, что-бы присутствовало постоянно не проблема.
Цитата:
При подаче питания на контроллер эти параметры снова вычитываются из EEPROM и по I²C-шине инициализируют аудиопроцессор.
А нельзя ли что-бы контролер инициализировал процессор и при выходе из дежурного режима.
ОК, сделаю. Тем более, что так правильнее. Основную прошивку (для ATmega32) уже переделал - в ждущем режиме можно обесточивать тюнер, аудиопроцессор, в общем, всё, кроме контроллера. Сейчас доработаю и для других прошивок.
- Инициализация тюнера и аудиопроцессора не только на старте микроконтроллера, но и при выходе из ждущего режима. Теперь в ждущем режиме их можно обесточивать, уменьшая общее энергопотребление. Запитанным от дежурного источника должен оставаться только МК с часами.
- Косметические изменения в исходниках.
По поводу первого изменения - в железе проверено на основной прошивке с кадровым буфером (m32fb) и обычной (m32). В остальных правки аналогичные, поэтому должно работать и там.
infinity19891 писал(а):
как обучить прошивку принимать сигналы с другого пульта?
Если прошивка с графическим дисплеем с кадровым буфером (m32fb, m64fb), доступен удобный режим обучения. В ждущем режиме одновременным нажатием кнопок 1 и 2 входим в этот режим. На экране отображается название функции. Жмём нужную кнопку на пульте, связывая её с этой функцией. Кнопкой 5 подтверждаем ввод и проделываем аналогично для других функций.
Если прошивка без кадрового буфера - аналогичным образом вызывается экран, на который выводятся hex-коды нажимаемых клавиш. Эти коды нужно hex-редактором внести в eeprom.bin файл, и зашить его.
Коды кнопок начинаются с адреса, определяемого макросом eepromRC5Cmd (см. eeprom.h), количество кодов и их порядок в eeprom определяются макросом RC5_CMD_COUNT и перечислением там же (см. input.h).
В любом случае, протокол пульта должен быть RC5. Другие протоколы не поддерживаются, по крайней мере, пока.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения