SPI требует задержки в 1 такт SCK перед началом передачи очередного байта. В течение этого времени на ноге MOSI будет сохраняться значение последнего выведенного бита. На экране это будет вылядеть как пиксел двойной ширины. В общем SPI не очень подходит для вывода графики.Сообщение от Lisitsin
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
А если выводить следующий байт не дожидаясь полного вывода последнего бита? И поставить соответствующую фазу и полярность SCK?
Прийдется дожидаться не просто полного вывода последнего бита, а еще и плюс длительность 1го такта SCK - прощупано лично: если произвести запись в Data Register не дождавшись этого момента, то будет устанвлен Write COLlision Flag и передача нового байта не начнется. Вот цитата из datasheet на ATmega32:
У других контроллеров, и не только ATmega, ситуация в режиме SPI таже. Также все вышеизложенное действительно и для всех вариантов фазы и полярности.The system is single buffered in the transmit direction and double buffered in the receive direction.
This means that bytes to be transmitted cannot be written to the SPI Data Register before
the entire shift cycle is completed.
Здесь можно разве что поизголяться с двумя каналами SPI, естественно на тех контроллерах где они есть, объединив их выходы MOSI и попеременно: выводим через первый, когда MOSI второго в Z-состоянии, затем выводим через второй, переведя ногу первого в Z-состояние. Но на экране будет все же заметен момент переключния в Z, когда MOSI одного уже перевели в Z, а MOSI другого будет переведен на OUT только следующей командой + до момента реального начала вывода первого бита. Здесь можно поэксперементировать с очередностью действий, например сначала записать байт для вывода, а затем уже переводить ноги в Z / из Z, но все равно на экране этот переход между байтами будет слегка отличаться от переходов между битами.
В ситуации с внешним регистром сдвига тоже не все так гладко: очень сложно (=практически не возможно) произвести в него запись нового байта стробом от МК так, что бы не исказился последний, выводимый на экран, бит предыдущего байта. Получим примерно ту же ситуацию, что и с SPI за исключением 1го дополнительного такта SCK. Но здесь уже можно поискать решение:
Вариант1: МК выдает только "разрешение" на параллельную загрузку в сдвиговый регистр в момент окончания вывода предыдущего байта, а непосредственно самим стробом записи служит сигнал сдвига битов. Грубо говоря объединяем по AND строб сдвига битов и "разрешение" загрузки нового байта и результирующий сигнал подаем на вход "параллельная загрузка" регистра.
Вариант2: на выходе сдвигового регистра ставим еще один "буфер" (регистр / D-триггер), строб записи в который будет слегка задержан по времени относительно строба сдвига бит в сдвиговом регистре. Т.о. запись в последний, выходной, регистр будет производиться только тогда, когда на выходе сдвигового регистра установится заведомо правильное значение и не будет разницы между выводом битов в пределах одного байта и битами двух соседних байтов.
Последний раз редактировалось acx; 19.05.2012 в 19:06.
Есть ещё вариант с SPI:
Конфигурируем ногу порта вывода данных SPI на выход. При этом при отключенном SPI нога будет обычным выходом, а включение SPI будет конфигурировать её в своих интересах.
Включаем SPI, начинаем передачу данных. В порт, по которому передаются данные SPI выдаём последний бит передаваемого байта. То есть при отключении SPI он окажется в порте. В конце предпоследнего бита передаваемого байта выключаем SPI по питанию. Тут же включаем его и следующей командой передаём очередной байт. По идее должно работать ...
Да, интересная мысль! Как реально отрабатывает SPI On/Off не проверял, но первое что видится, что в этом варианте будет искажаться не последний бит, а предпоследний. Т.к. момент переключения ноги с SPI на OUT, вполне возможно, не совпадет с моменом окончания такта SCK предпоследнего бита. Но это уже надо проверять и смотреть вживую.
Но в любом из этих всех вариантов появляется еще один недостаток: все эти манипуляции съедают драгоценные такты в пределах времени вывода одного байта.
собственно это просто одна давняя идея, реализовывать не стал из за того что действительно жесть, тем более,модель в тетрадке очень сырая, пересмотрел её свежим взглядом и думаю что в нынешнем виде работать не будет.
Набросал в протеусе проект mega664+hc165, и vsm для эмуляции телевизора, avr выплёвывает 32 байта за 64ms ( именно 64 потому что горизонтальная синхорнизация в vsm сделана не отдельным входом, - переход "луча" происходит перед каждым 5мс импульсом уровня чёрного,поэтому два последних байта из 32 всегда 0xff)
vsm пока довольно глючный, на выходных постараюсь доработать и выложу сюда, вроде в интернете не встречал такую
Последний раз редактировалось Zarax; 22.05.2012 в 07:59.
вобщем не всё гладко как хотелось бы - через hc165 плывёт картинка, грешил на несинхронную работу регистра, но проблема существует и на заведомо рабочем проекте http://pmd85.topindex.sk/ , где нет регистра, перелопатил VSM похоже там всё в порядке, простую графику (например линии толщиной 0.5мс) выводит без проблем, видимо сам протеус создаёт некий джиттер, на скрине видно как плывёт надпись ** PMD-85 READY /1.0 ** - буду думать как с этим бороться
Последний раз редактировалось Zarax; 28.05.2012 в 16:58.
http://www.avrfreaks.net/index.php?n...topic&p=844369
там народ обсуждает проблему и вроде даже решение найдено( во всяком случае чел положил какието сорсы).
Amiga 1200+Blizzard 1260 72 Mb+Mtek 68030,Compozit 128, Leningrad 2,
Atari STE 1040,ZX Spectrum +2,Pentagon 48, Speccy2007 - 2 , ATAS 256k.
ZX Evo 4Mb- в строю.
Speccy2010 v1
Специалист (пока готовлюсь к восстановлению).
Это все мое!
Родное!
Все люблю на свете я! Это родина моя!
я видал эту ссыль, но всё равно спасибо..в железе эмулятор PMD-85 из верхней ссылки тоже, должно быть, работает нормально, жаль у меня нет возможности убедится в этом - банально нет AVRки нужной жирности, по этому приходится в Протеусе моделировать, и скриншот - результат работы модели, а не железяки
2 Zarax
Интересно было бы посмотреть на модель телевизора(монитора) для протеуса.
Вот тут http://zx.pk.ru/showthread.php?t=6499 вроде искали тоже.
P.S. У Вас и SDK для протеуса наверное есть ? )
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
