бухой?
primuss3.com
Вы ее, похоже, убрали с форума, но я в свое время ее утянул и сохранил. Так вот, наконец-то, дошли до нее руки и я переделал ее на SPI - сначала сменил ноги на ноги аппаратного SPI, а затем заменил программный SPI аппаратным. Все получилось в лучшем виде, при кварце 16 мГц и делителе 64 частота получилась 250 кГц, одна полная передача трех байтов занимает 96 мкс, что не намного дольше заявленных 72 мкс для 7920. То есть, оно, конечно, выводит медленнее, чем на предельных 72 мкс, но, практически, незаметно. Ну, и один байт передается 64 * 8 = 512 тактов, т.е. передачу спокойно можно делать в прерываниях, даже в программе на Си.shads писал(а):Либка получилась достаточно компактная, помоему около 1-2 кило, даже на мега8 можно легко развернуться...
А, нет, недоглядел, лежит она, на стр. 7, сообщение от 12 июня 2017.afz писал(а):Вы ее, похоже, убрали с форума, но я в свое время ее утянул и сохранил.
На фига здесь нужен таймер, и на фига высокая скорость SPI? SPI настроен на 32 мкс, каждое прерывание от него посылаем очередной байт трехбайтовой последовательности, и все. Остальные преобразования делаем уровнем выше, по сигналу от драйвера SPI. Грубо говоря, SPI сам себе таймер. И пусть прерывания от него идут втрое чаще, чем были бы от таймера, все равно одно прерывание в 512 тактов - это немного. А дальше - все просто. Получив отметку, что три байта по SPI отправлены (и, если надо), генерим следующие 3 байта и отдаем их драйверу SPI. Тот, когда будет готов, снимет их в свою память, и начнет передавать, отметив, что можно генерить следующие три байта. Как-то так, без деталей, конечно.GoldenAndy писал(а):Тогда можно дергать прерывание от таймера каждые 75-80-85 мкс
Значит мне достался не совсем удачный экземпляр дисплея. Или я его чем-то подпортил...GoldenAndy писал(а):А касательно контраста - вполне нормальный там контраст.
Для таких задач я, обычно, клепаю собственную простенькую ОС РВ. Есть таблица задач, диспетчер ее постоянно просматривает. Если нашлась задача, готовая к выполнению, она выполняется, после чего возвращается в диспетчер. Все задачи предельно короткие, выполняются очень быстро. Если надо чего-то подождать, вызывается таймерная задача, которая прописывает таймер на заданное время, и опять же уходит в диспетчер. Если устройство батарейное, то последней задачей (с минимальным приоритетом) ставится задача Idle, которая переводит процессор в Sleep-mode.GoldenAndy писал(а):Т.е. какой то внешний движок должен отслеживать, что СПИ отстрелялся и бегом-бегом готовить данные...
ну, и шо?WiseLord писал(а):Если видеобуфер отсылается на дисплей в главном цикле, то нужно отправить 128*64/8 = 1024 байта только данных, плюс ещё на порядок меньшее число команд. Любая запись в дисплей требует паузы порядка 60мкс, т.е. в Вашем варианте, грубо, обновление экрана будет длиться около 70мс. То есть, отрабатывается, максимум, 13 главных циклов в секунду.
Зависит от. Если все делать ТОЛЬКО в прерываниях, то этот цикл вполне заменит собой обычную Idle многозадачки. Ну, и если вместо тупого ожидания циклом _delay (то есть считая количество прохождений эттого цикла, пока не пройдет нужное время), совместить этот подход с моим, то есть организовать там просмотр флажков и вызов некоторых процедур по значениям этих флажков, то может получиться довольно прилично...WiseLord писал(а):Крайне неэффективно. И память отъело, и огромная часть процессорного времени занята подвисанием в задержках дисплея в главном цикле.