Чт июн 30, 2016 11:25:55
Чт июн 30, 2016 13:59:17
Ну в последовательном то же самое... установил адрес и шуруй 32 байта данных... потом адрес следующей строки... и т.д.WiseLord писал(а):В параллельном режим можно данные в дисплей посылать "пачками", то есть:
Фаза 1: RS = 0, D7-D0 = Адрес Y, строб
Фаза 2: RS = 0: D7-D0 = Адрес X, строб
Фаза 3: (RS = 0: D7-D0 = данные, строб ) * 32 раза подряд, после чего нужно снова устанавливать адреса (переходить в режим команд)
Вот об этом я даже не позаботился... у меня шурует подряд (за исключением пару нопов) и все работает... мож это касается только параллельного режима??? или может это должно обеспечиваться между сменами адресации???WiseLord писал(а):Между стробами нужно обеспечить не менее 50мкс.
Наверное всегда должно быть вначале 11111(RW)(RS)0WiseLord писал(а):Интересно, есть ли возможность и в режиме SPI передавать не три байта данных (режим - старшие биты - младшие биты), а лишь два последних. Наверное, нельзя, и последовательность 11111(RW)(RS)0 должна присутствовать всегда.
Ну в общем как я и сказал - этой задержки у меня вообще нет... надо разобраться почему у меня работает и где это вообще должно быть... возможно что это касается параллельного режима...WiseLord писал(а):И ещё интересно, 50мкс в этом случае надо обеспечивать лишь между группами по 3 байта, или между каждыми байтами, т.е.
11111(RW)(RS)0 - 50мкс - HHHH0000 - 50мкс - LLLL0000 - 50мкс
или достаточно
11111(RW)(RS)0-HHHH0000-LLLL0000 - 50мкс
Чт июн 30, 2016 14:50:54
Чт июн 30, 2016 16:39:54
Возможно... наверное при программном формировании потока скорость примерно такая и будет...WiseLord писал(а):50мкс - это на передачу всей посылки, т.е. 24 бит. Вот и получается, что скорость SPI нужна порядка 24*(1/50мкс) = 500кбит/с, тогда и задержки не нужны.
Обычно реалтайм функции реализуются в прерываниях, так что тут проблем нет... а вот все остальное - типа отработки результатов нажатий кнопок, ветвлений алгоритмов, и прочих телодвижений в майне - тут 50мс вааще погоды не делают... тем более что отрисовка обычно нужна именно ПОСЛЕ какого то из этих событий...WiseLord писал(а):За 50мкс отрисовывается 8 точек, значит весь экран - за 50мс приблизительно. Вполне быстро, но вот в течение этого времени контроллер будет "висеть" - ну, не считая возможных прерываний, само собой.
Согласен... не очень красиво... но для самых простейших применений пойдет... вот как выглядит такой вариант http://asis-kbr.ru/forum/viewtopic.php?p=1168#p1168WiseLord писал(а):Кстати, что Вы имеете в виду, говоря о некоем "текстовом буфере"? Ведь, по идее, если экономить память и буферизовать не весь экран (1КиБ ОЗУ), а некий текстовый буфер, требующий в 8 раз меньше памяти, мы фактически привязываемся к определённым позициям символов. То есть, максимум 16 букв в ширину с большими расстояниями между ними. Как-то это не очень красиво выглядеть будет, слишком разреженно.
Чт июн 30, 2016 17:21:26
Чт июн 30, 2016 18:54:54
Кто сказал "Мяу"?!. Я же выдал расчет, медленный SPI будет выдавать один байт из трех (8 бит из 24) в течение 128 тактов. А на обслуживание прерывания, сохранение-восстановление, выдачу нового байта в РД SPI и пр., нужно, максимум, 20-30 тактов (на асме, вестимо). Так, что спокойно переносим выдачу через SPI в прерывания, свободная сотня тактов на любые действия останется. То есть сотню или чуть больше тактов занимаемся своими делами, 20-30 тактов тратим на прерывание от SPI и связанные с ним дела. Если часть условно свободного времени (в смысле часть основной задачи) будет при закрытых прерываниях, максимум неприятностей - это очередной байт будет передан с задержкой, да и на здоровье - кроме замедления выдачи на экран это ничем не грозит.WiseLord писал(а):Кстати, тут ранее писали, что можно SPI настроить на более медленный режим и якобы не заботиться о задержках, мол, всё будет обеспечиваться аппаратно. Но хрен редьки не слаще. Какая разница - быстрый SPI + _delay_us(50); или медленный SPI и висение а-ля while (SPI_is_ready())? Так или иначе процессор полезного кода не выполняет в это время, вися в ожидании.
Чт июн 30, 2016 19:15:46
Я сравнил этот подход со своим. Как я понимаю, вся разница в том, что у меня прерывания получаются втрое чаще - с параллельным интерфейсом байт передается за один прием, а в последовательной передаче - в три приема, для программы на Си это, скорее всего, существенно. Зато проводов меньше...WiseLord писал(а):Позже, когда на ATmega32 перешёл, выделил целый половину ОЗУ - килобайт - под кадровый буфер. Основной код просто пишет данные в этот буфер, а уже в прерывании (раз в те самые 50мкс) берётся очередная порция данных (или команда, если её черёд) и посылается в дисплей - без всяких задержек, максимально быстро.
В итоге получается крайне быстрая реализация вывода. Необходимые данные - текст, графика, да что угодно - просто и быстро записываются в этот буфер, а уже из прерывания это всё дело попадает в реальный дисплей. Итого - порядка 18 обновлений экрана в секунду "в фоне" и этот вывод совершенно не блокирует основной поток программы, замедляя его от силы на процентов 5.
Собственно, вот так это и работает потом на ST7920 - хватает времени и на анализ Фурье, и на обработку кнопок, пульта и прочие красоты:
Чт июн 30, 2016 19:47:30
Неплохо неплохоWiseLord писал(а):Собственно, вот так это и работает потом на ST7920 - хватает времени и на анализ Фурье, и на обработку кнопок, пульта и прочие красоты:
Чт июн 30, 2016 21:18:28
Да, но при таком подходе всё равно нужен какой-то буфер в ОЗУ, из которого "параллельный поток кода" на базе прерываний будет брать очередной байт для записи в дисплей, в идеале - те же 1КиБ на хранение всего кадра.afz писал(а):Так, что спокойно переносим выдачу через SPI в прерывания, свободная сотня тактов на любые действия останется. То есть сотню или чуть больше тактов занимаемся своими делами, 20-30 тактов тратим на прерывание от SPI и связанные с ним дела.
Ну так-то да. Но я не заморачивался с SPI, поскольку проект поддерживает ещё и KS0108 (да и начинался с него). Поэтому смысла городить SPI не было, т.к. всё равно ноги D0-D7 заняты дисплеем, а параллельный интерфейс всё же максимально быстрый.afz писал(а):Я сравнил этот подход со своим. Как я понимаю, вся разница в том, что у меня прерывания получаются втрое чаще - с параллельным интерфейсом байт передается за один прием, а в последовательной передаче - в три приема, для программы на Си это, скорее всего, существенно. Зато проводов меньше...
___|Thh__Shh__Shh_______________________~_______|Thh__Shh__Shh_______________________~_______|Thh__Shh__Shh________
| 5us | 45us | 5us | 45us | 5us |
___|Shh____________Shh____________Shh___________|Shh____________Shh____________Shh___________|Shh____________Shh____
| 17us | 17us | 17us | 17us | 17us | 17us | 17us |
Это именно ST7920.shads писал(а):Как я понял - это KS0108? или все таки ST7920? просто обычно у ST7920 - экран синий...
Чт июн 30, 2016 21:58:01
Чет дороговатый какой то...WiseLord писал(а):Это именно ST7920.
Пт июл 01, 2016 07:52:23
Сб июл 02, 2016 06:55:03
Необязательно, зависит от того, что надо выводить. Я прикидываю метеостанцию, собираюсь рисовать график изменения атмосферного давления. Такую картинку можно генерить "на лету". Чисто текстовую строку также можно генерить на лету. Впрочем, небольшой буфер FIFO не помешает...WiseLord писал(а):Да, но при таком подходе всё равно нужен какой-то буфер в ОЗУ, из которого "параллельный поток кода" на базе прерываний будет брать очередной байт для записи в дисплей, в идеале - те же 1КиБ на хранение всего кадра.
Тогда, конечно, понятно.WiseLord писал(а):Ну так-то да. Но я не заморачивался с SPI, поскольку проект поддерживает ещё и KS0108 (да и начинался с него).
Как мы видим, скорость тут ни разу не нужна. А вот ноги поэкономить вполне можно, моя проектируемая метеостанция имеет реальный шанс влезть в 8-ю Мегу. Не хватит памяти (ОЗУ, флеши мне хватит по-любому, писать буду на асме), поставлю 328-ю Мегу.WiseLord писал(а):Поэтому смысла городить SPI не было, т.к. всё равно ноги D0-D7 заняты дисплеем, а параллельный интерфейс всё же максимально быстрый.
Увы, не выйдет. У 7920 ограничение по частоте SCLK 2.5 МГц. (В ДШ прямо это не заявлено, но длительность импульса и длительность паузы не должны быть меньше 200 нс каждый, итого минимальный период SCLK 400 нс.) Да и таймер может пригодится для чего-то другого - зачем использовать еще и таймер, когда SPI справится с этим ничуть не хуже? Таймер здесь - классическая лишняя сущность.WiseLord писал(а):Если SPI настроить на максимальную частоту (8МГц при 16МГц), получится, вся передача по SPI займёт около 5мкс (3мкс на три байта плюс небольшие накладные расходы на обработку прерывания), остальные 45мкс контроллер будет делать полезную работу. Да и между прерываниям SPI будет ещё некоторое "полезное" время.
Во-первых, не 50 мкс, а 72 мкс. 50 - это разгон. Тут на предыдущих страницах кто-то отписался, что разгонять можно до 33 мкс, при меньшем времени цикла (большей частоте передачи данных) появляются артефакты.WiseLord писал(а):И ещё интересно, 50мкс в этом случае надо обеспечивать лишь между группами по 3 байта, или между каждыми байтами, т.е.
11111(RW)(RS)0 - 50мкс - HHHH0000 - 50мкс - LLLL0000 - 50мкс
или достаточно
11111(RW)(RS)0-HHHH0000-LLLL0000 - 50мкс
А вот это тоже интересно. Как я понимаю, если регулярно дрыгать 4-й ножкой дисплея (CS ), то точно нельзя, ибо где-то в ДШ упоминается, что она сбрасывает весь автомат обмена по SPI. А вот если CS оставить в единице, то черт его знает, что там будет. Или дисплей заработает, или его расколбасит по-тяжелому...Интересно, есть ли возможность и в режиме SPI передавать не три байта данных (режим - старшие биты - младшие биты), а лишь два последних. Наверное, нельзя, и последовательность 11111(RW)(RS)0 должна присутствовать всегда.
Вт мар 21, 2017 21:38:30
afz писал(а):А вот если CS оставить в единице, то черт его знает, что там будет
Вт апр 18, 2017 12:19:29
Вт апр 18, 2017 14:19:01
Тут, ЕМНИП, другая организация. Всего 32 строки, по 32 байта каждая. Байты ложатся горизонтально. Если писать последовательно данные, то первые 16 байт занимают всю верхнюю строчку, далее строка продолжается во второй (нижней) половине дисплея.krepitsin писал(а):Нижняя строка (получается 7-ая)
Вс апр 23, 2017 07:39:57
Вс апр 23, 2017 09:16:05
Вс апр 23, 2017 18:44:47
Пн июн 12, 2017 14:22:04
Пн июн 12, 2017 16:32:55