Офигеть, из Китая за 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. Другие протоколы не поддерживаются, по крайней мере, пока.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 15
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения