Jump to content

    
Sign in to follow this  
dexter_khm

AVR и Siemens M55

Recommended Posts

Подключил дисплей от S65 на контроллере LS020 к AT91SAM7.

Уря-я! :w00t:

Всё вроде работает :)

У немцев действительно перепутаны икс и игрек для команды задания координат окна:

0xEF90, 0x0504, 0x08X1, 0x09X2, 0x0AY1, 0x0BY2 - неправильно, на самом деле:

0xEF90, 0x0504, 0x08Y1, 0x09Y2, 0x0AX1, 0x0BX2

 

Частота SPI - 12 МГц. Весь экран полностью записывается за 31 с копейками миллисекунду.

И при этом всё равно видно, как он обновляется - раза 3 или 4 за это время.

В телефоне SPI работает на 13 МГц, что почти равно, но при этом (говорят) не видно обновления - значит, действительно, там используется какая-то синхронизация с ходом луча. Но чёрт его знает, как она задействуется...

В принципе, и так очень даже хорошо. :)

Share this post


Link to post
Share on other sites
Реплика по поводу того, как телефон определяеттип контроллера в подключенном дисплее. Я сейчас развлекаюсь с дисплеем от Nokia 6100. В этом дисплее может стоять либо PCF8833 либо S1D15G00. Мне попался филипок. В даташите на него написано, что в SPI режиме из него можно кое что прочитать в ответ на определенные команды, и идентификатор контроллера в том числе. И каково же было мое удивление, когда в ответ на неправильную команду с последующими данными на выводе DATA я увидел не двустабильные а трехстабильные уровни сигналов. Закралось подозрение что дисплей с контроллером бодаются на шине данных. И действительно, выдал команду прочитать статус контроллера дисплея, перевел вывод данных микроконтроллера в высокоимпедансное состояние и педергал линией SCK - в ответ дисплей выдал ожидаемую информацию из регистра идентификации.

Склатывается обоснованное подозрение, что производитель дисплея просто замкнул между собой вход и выход данных контроллера.

Что касается S1D15G00 - в даташите на него о выходе данных в режиме SPI ничего не сказано, следовательно ожидаю что этот контроллер ничего и не вернет в ответ на запрос статуса (кстати команда такая есть, но наверное она имеет смысл только при подключении через параллельный интерфейс).

Господа, эти протоколы (SPI, TWI) двунаправленные, и нормально, что после выдачи некоторых команд управляющее устройство ждет ответа от контроллера дисплея, тактируя по линии клок, линия данных двунаправленная, а не с замкнутым входом-выходом, это несколько разные вещи.

Share this post


Link to post
Share on other sites
Подключил дисплей от S65 на контроллере LS020 к AT91SAM7.

 

Частота SPI - 12 МГц. Весь экран полностью записывается за 31 с копейками миллисекунду.

И при этом всё равно видно, как он обновляется - раза 3 или 4 за это время.

В телефоне SPI работает на 13 МГц, что почти равно, но при этом (говорят) не видно обновления - значит, действительно, там используется какая-то синхронизация с ходом луча. Но чёрт его знает, как она задействуется...

 

При максимальной частоте SPI - 12 МГц еще и очень важное значение имеет быстрота обслуживания "околоSPI-шных" команд. Проще говоря от длительности машинного цикла микроконтроллера все зависит больше, чем от SPI. Это проверено. А какова длительность машинного цикла вашего ARM?

Share this post


Link to post
Share on other sites

Скорей всего контроллер дисплея имеет двойной буфер, телефон заполняет один, а потом практически мгновенно переключает буфера. При таком алгоритме скорость заполнения промежуточного буфера не играет огромной роли. Посмотрите в даташитах, может там это упоминается.

Share this post


Link to post
Share on other sites
... Посмотрите в даташитах, может там это упоминается.

Так если бы они были, эти даташиты. На Epson почти ничего и нет.

Share this post


Link to post
Share on other sites
При максимальной частоте SPI - 12 МГц еще и очень важное значение имеет быстрота обслуживания "околоSPI-шных" команд. Проще говоря от длительности машинного цикла микроконтроллера все зависит больше, чем от SPI. Это проверено. А какова длительность машинного цикла вашего ARM?

При чём здесь длительность машинного цикла? Используется аппаратный SSC. После передачи нескольких комманд идут данные битовым потоком в 371712 бит совершенно без пауз между словами. Время передачи уже указывал - 31,6 мс.

А ядро работает на 48 МГц. Один такт - около 21 нс.

 

Скорей всего контроллер дисплея имеет двойной буфер, телефон заполняет один, а потом практически мгновенно переключает буфера. При таком алгоритме скорость заполнения промежуточного буфера не играет огромной роли. Посмотрите в даташитах, может там это упоминается.

 

В даташитах это наверняка упоминается. Только их нет. На Sharp LR38826 тоже никаких даташитов нет. Те, что проскакивали в этой теме - или рекламка на одном листе, или совсем не то... Эх-х...

Share this post


Link to post
Share on other sites

Да-а-а, наверное придётся-таки делать аппаратный SPI-сниффер и анализировать поток команд и данных от живого телефона.

Share this post


Link to post
Share on other sites

Попробовал писать на дисплей так, как пишет сам телефон (если смотреть на дисплей так, как он стоит в телефоне - вертикальный дисплей) - сверху вниз.

Так получше - видно только один разрыв (полоску) за весь вывод.

Вместо трёх при выводе слева-направо (горизонтальный дисплей).

 

То есть сканирование и обновление пикселей железом панели идёт (вертикальный дисплей) сверху-вниз.

Частота - (если судить по трём полоскам за 30 мс) - 100 герц. Что-то многовато...

 

ЗЫ: у немцев на http://www.mikrocontroller.net огромная ветка по сабжу, но ничего ведь не понятно по-немецки... блин :)

 

ЗЗЫ: В общем-то проблемы с этой синхронизацией могут возникнуть только в случае просмотра видео.

При простой печати текста и выводе других необъёмных данных заметно быть не должно. По крайней мере на ARM.

Edited by sonycman

Share this post


Link to post
Share on other sites

При максимальной частоте SPI - 12 МГц еще и очень важное значение имеет быстрота обслуживания "околоSPI-шных" команд. Проще говоря от длительности машинного цикла микроконтроллера все зависит больше, чем от SPI. Это проверено. А какова длительность машинного цикла вашего ARM?

При чём здесь длительность машинного цикла? Используется аппаратный SSC. После передачи нескольких комманд идут данные битовым потоком в 371712 бит совершенно без пауз между словами. Время передачи уже указывал - 31,6 мс.

А ядро работает на 48 МГц. Один такт - около 21 нс.

 

Ну и что, что аппаратный SSC. В вашем случае ARM работает быстрее SPI. А на AVR например примерно одинаково. Отсюда и заметность на глаз обновления экрана. И 31,6 мс там уже не получить. Вот если к AVR подключить кварц на 48МГц, тогда да, но будет ли он при этом работать?

:)

Share this post


Link to post
Share on other sites
Ну и что, что аппаратный SSC. В вашем случае ARM работает быстрее SPI. А на AVR например примерно одинаково. Отсюда и заметность на глаз обновления экрана. И 31,6 мс там уже не получить. Вот если к AVR подключить кварц на 48МГц, тогда да, но будет ли он при этом работать?

:)

Да ну? :biggrin:

Не стоит делать столь голословных утверждений.

Передо мной на экране осциллографа прекрасно видно, как происходит передача данных. И сколько времени она занимает.

 

И насколько быстрее или медленнее работает ядро тут совершенно не важно. :)

Share this post


Link to post
Share on other sites

Ну и что, что аппаратный SSC. В вашем случае ARM работает быстрее SPI. А на AVR например примерно одинаково. Отсюда и заметность на глаз обновления экрана. И 31,6 мс там уже не получить. Вот если к AVR подключить кварц на 48МГц, тогда да, но будет ли он при этом работать?

:)

Да ну? :biggrin:

Не стоит делать столь голословных утверждений.

Передо мной на экране осциллографа прекрасно видно, как происходит передача данных. И сколько времени она занимает.

 

И насколько быстрее или медленнее работает ядро тут совершенно не важно. :)

 

Поставьте на свой ARM кварц на 10 МГц и все увидите

Share this post


Link to post
Share on other sites
Поставьте на свой ARM кварц на 10 МГц и все увидите

Зачем? Я и так всё вижу.

Вам же могу только посоветовать почитать главу по работе SSC или SPI в AT91SAM7. И посмотреть, как всё это работает на практике.

Тогда, может быть, и Вы всё увидите и поймёте :)

 

Ивиняюсь за оффтопик...

Share this post


Link to post
Share on other sites
... у немцев на http://www.mikrocontroller.net огромная ветка по сабжу, но ничего ведь не понятно по-немецки... блин :)

Попробуйте www.translate.ru, есть там опция перевода WWW-страниц. Понять уже можно, но иногда со смеху падаешь ...

Share this post


Link to post
Share on other sites
Попробуйте www.translate.ru, есть там опция перевода WWW-страниц. Понять уже можно, но иногда со смеху падаешь ...

Спасибо, потом попробую.

Там есть посты на инглише. Пока их и читаю.

Оказывается, наши там тоже побывали! :)

Edited by sonycman

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this