Дисплеи от мобильных телефонов- осцилограммы работы

Avarges

BigallS писал(а):

sdsrem писал(а):

А чего рапортовать-то, сдесь вроде тоже самое есть,

И насколько быстрее варианта "Avarges", хотя бы 50 fps получается?

Сравнивать нельзя, потому что для моего варианта это ничего не меняет - данные всё равно с SD читать надо, на атмеге8 только один SPI. А то что есть аппаратный вариант подключения дисплея - это хорошо.

Кстати, sdsrem, тот вариант моего кода, что вы цитировали не самый лучший, позже написал на ассемблере, 8 бит в дисплей отправляет за 56 машинных тактов. А программно-аппаратный вариант с регистром за 29 тактов. Думаю, SPI справляется не быстрее, чем за 16 тактов, плюс приведенный код для SPI не оптимизированный - слишком уж много вложенных вызовов, а на каждый вызов идет потеря 7 тактов.

Реклама

BigallS

Avarges писал(а):

BigallS писал(а):

sdsrem писал(а):

А чего рапортовать-то, сдесь вроде тоже самое есть,

И насколько быстрее варианта "Avarges", хотя бы 50 fps получается?

Сравнивать нельзя, потому что для моего варианта это ничего не меняет - данные всё равно с SD читать надо, на атмеге8 только один SPI. А то что есть аппаратный вариант подключения дисплея - это хорошо.

Кстати, sdsrem, тот вариант моего кода, что вы цитировали не самый лучший, позже написал на ассемблере, 8 бит в дисплей отправляет за 56 машинных тактов. А программно-аппаратный вариант с регистром за 29 тактов. Думаю, SPI справляется не быстрее, чем за 16 тактов, плюс приведенный код для SPI не оптимизированный - слишком уж много вложенных вызовов, а на каждый вызов идет потеря 7 тактов.

Выложили бы код, в 2 вариантах народу бы пригодилось.

Реклама

Avarges

Код на 27 тактов (с регистром) и схема есть на 20 странице. Свой код на 56 тактов я не сохранил, зато недавно нашёл чужой (elm-chan.org) похожий вариант:

Код:

void __attribute__ ((noinline, naked)) send_data (
   BYTE d
)
{
   asm (
      "in r31, 0x12\n"
      "andi r31, 0x7F\n"
      "ori r31, 0x40\n"
      "out 0x12, r31\n"   // '1' indicates the frame is a data
      "sbi 0x12, 7\n"

      "bst r24, 7\n"
      "bld r31, 6\n"
      "out 0x12, r31\n"   // D7
      "sbi 0x12, 7\n"

      "bst r24, 6\n"
      "bld r31, 6\n"
      "out 0x12, r31\n"   // D6
      "sbi 0x12, 7\n"

      "bst r24, 5\n"
      "bld r31, 6\n"
      "out 0x12, r31\n"   // D5
      "sbi 0x12, 7\n"

      "bst r24, 4\n"
      "bld r31, 6\n"
      "out 0x12, r31\n"   // D4
      "sbi 0x12, 7\n"

      "bst r24, 3\n"
      "bld r31, 6\n"
      "out 0x12, r31\n"   // D3
      "sbi 0x12, 7\n"

      "bst r24, 2\n"
      "bld r31, 6\n"
      "out 0x12, r31\n"   // D2
      "sbi 0x12, 7\n"

      "bst r24, 1\n"
      "bld r31, 6\n"
      "out 0x12, r31\n"   // D1
      "sbi 0x12, 7\n"

      "bst r24, 0\n"
      "bld r31, 6\n"
      "out 0x12, r31\n"   // D0
      "sbi 0x12, 7\n"

      "ret\n"
   );
}

Процедура эта на чистом ассемблере, но вставляется в си-исходники. Распиновка для этого кода такая:
atmega64 PD7 - CLK, PD6 - DATA, PD5 - CS, PD4 - RS или поправить в коде адрес порта (0x12 на нужный)

BigallS

Avarges писал(а):

Код на 27 тактов (с регистром) и схема есть на 20 странице. Свой код на 56 тактов я не сохранил, зато недавно нашёл чужой (elm-chan.org) похожий вариант:
....

Процедура эта на чистом ассемблере, но вставляется в си-исходники. Распиновка для этого кода такая:
atmega64 PD7 - CLK, PD6 - DATA, PD5 - CS, PD4 - RS или поправить в коде адрес порта (0x12 на нужный)

Спасибо, прикошачим к Atmega 32a.

sdsrem

Avarges писал(а):

BigallS писал(а):

sdsrem писал(а):

А чего рапортовать-то, сдесь вроде тоже самое есть,

И насколько быстрее варианта "Avarges", хотя бы 50 fps получается?

Сравнивать нельзя, потому что для моего варианта это ничего не меняет - данные всё равно с SD читать надо, на атмеге8 только один SPI. А то что есть аппаратный вариант подключения дисплея - это хорошо.

Кстати, sdsrem, тот вариант моего кода, что вы цитировали не самый лучший, позже написал на ассемблере, 8 бит в дисплей отправляет за 56 машинных тактов. А программно-аппаратный вариант с регистром за 29 тактов. Думаю, SPI справляется не быстрее, чем за 16 тактов, плюс приведенный код для SPI не оптимизированный - слишком уж много вложенных вызовов, а на каждый вызов идет потеря 7 тактов.

А вы попробуйте флешку по програмному SPI а дисплей по апаратному запустить, т.к на дисплей ресурса больше надо, думаю получится должно получше.
И ещё я на мега 8 иногда ставлю кварц на 26мгц, и работает без проблем, тоже можете попробовать (как вариант).

Реклама

Avarges

Надоело уже мучать бедную атмегу, недавно арм прислали. Идеи неплохие и требуют тестирования, особенно кварц. Любители делать строго по даташиту нервно курят в сторонке

Реклама

Распродажа паяльного оборудования ATTEN!
Паяльные станции, паяльники и аксессуары по самой выгодной цене.

По промокоду radiokot скидка 10%

Foks

Avarges писал(а):

Аппаратный SPI использовал для чтения данных с SD. То что сам дисплей можно подключать к SPI в первый раз слышу и вообще-то сомнительно это. Если уж у вас получилось - рапортуйте о подробностях, всем пригодится.

Ну здрасте, а что мешает? То что у SPI линии передачи/приема разделены? Я поставил мультиплексор, и подключил к аппаратному, это гораздо быстрее работает.

Avarges

Здрасте и вам, давайте поточнее с цифрами, "гораздо быстрее" это ни о чём. С какой скоростью читаем SD, отсылая через этот же SPI в дисплей, битрейт в дисплей тоже. Чтоб всем сразу стали ясны возможности атмеги.

Раз в дисплее чистый SPI, то опять же поднимаю вопрос о том, почему бы не подключить напрямую SD к дисплею, а атмегой только тактировать и выдавать управляющие сигналы. Зачем читать байт с SD, потом его пересылать в дисплей, если можно напрямую передавать в дисплей, это гораздо быстрее работает :)))

Foks

У SPI в режиме 2X на отсылку байта уходит 16 тактов процессора. При тактировании МК в 16 МГц, это 1 МБит пропускной способности. При передаче циклами - минимум в 4 раза (add: даже не 4, а до десятка) дольше, и то если писать на ассемблере. Это еще не всё: при использовании аппаратного SPI программа "свободна" во время отправки данных, т.е. с точки зрения программы, на отправку байта данных уходит 2(!) такта процессора. Вот и всё, голая теория, и цифры из даташита.

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

Реклама

Avarges

Foks писал(а):

При тактировании МК в 16 МГц, это 1 МБит пропускной способности.

Что-то мало. У меня на практике получилось 2.13Мбит/с на программной реализации.

Foks писал(а):

Вот и всё, голая теория, и цифры из даташита.

Чем больше теоретики, тем больше ляп

Foks писал(а):

я таким не занимаюсь потому как не вижу в этом смысла, кроме того что поиграться.

Если хорошо вдуматься, то всё радиолюбительство не имеет смысла, кроме того что поиграться

sdsrem

А Foks прав, ежели использовать апаратный протокол, и для флешки и для стекла то получиться как минимум в два раза быстрей.
Только надо правильно всё организовать.

sdsrem

А вот радиолюбительство совсем не бестолковое занятие, если бы 50 лет (может больше) назад не придумали приёмник прямого преобразования, то небало-бы не сотовых ни интернета.
А придумали тоже радиолюбители.
А повторять МП-3 плеер, дейсвительно только для поиграться, и для общего развития.

Foks

Avarges писал(а):

Что-то мало. У меня на практике получилось 2.13Мбит/с на программной реализации.

Простите, я опечатался, 1 МБайт/с. Я говорю о пропускной способности линии связи с дисплеем, если кто не понял.
Цифровая схемотехника - это не та вещь, где теория может отличается от практики. Я понятия не имею, как измерены Ваши цифры - мне проще посчитать и быть уверенным в своих результатах. Собственно, наверное, поэтому я пишу даже большие проблеммы на ассемблере.

Радиолюбительство - не "поиграться". Оно приносит огромный опыт. Вывод видео - да, интересно, но я не понимаю, зачем уже N-ое количество страниц народ пытается выжать из этой игрушки +1 FPS.

Взять 32-битный процессор - разумное решение, но тогда стоит уже заняться MPEG-кодированием, вот это будет реально интересно! Чем оптимизировать цикл попиксельного вывода несжатого видео с карты памяти.

Satyr

Foks писал(а):

Взять 32-битный процессор - разумное решение, но тогда стоит уже заняться MPEG-кодированием, вот это будет реально интересно! Чем оптимизировать цикл попиксельного вывода несжатого видео с карты памяти.

Главное, взять правильное железо. Есть МК с аппаратным контроллером SD в нативном 4 битном, а не SPI режиме. Есть МК с внешней шиной под SRAM, на которую как родные вешаются телефонные экранчике с параллельной шиной. А дальше только организация процесса, а данные с СД и на экран польются DMA.

mpeg2 320x240 имеет шанс потянуть минимум кортекс-М4, да и то надо проверять

Igor_67

Всем привет! Имеется у меня дисплейчик цветной, точно знаю, что от Сименса, но вот от какого-забыл. Давно уже лежит... На задней стороне написано LM15SGFNZ20, ниже - 05J016345A L, плата зеленая, с обратной стороны платы написано SHARP QPWBN5016CPZZ, шлейф от самого индикатора к плате - желтый, на плате 10 прямоугольных контактов c обозначением CN1 и еще три круглых площадки подписаны DVDD TEST VM. Хотелось бы поэкспериментировать с ним и, как следствие узнать как его инициализировать и хоть что-то вывести на экран. Лучше конечно бы алгоритм вывода увидеть. Пишу в среде Bascom AVR, но пройдясь по ветке, ничего на Бейсике не увидел ( потому и прошу алгоритм). Фотки дисплея выложить не могу - не крепятся в сообщение почему-то... :dont_know:

BigallS

Igor_67 писал(а):

Всем привет! Имеется у меня дисплейчик цветной, точно знаю, что от Сименса, но вот от какого-забыл. Давно уже лежит... На задней стороне написано LM15SGFNZ20, ниже - 05J016345A L, плата зеленая, с обратной стороны платы написано SHARP QPWBN5016CPZZ, шлейф от самого индикатора к плате - желтый, на плате 10 прямоугольных контактов c обозначением CN1 и еще три круглых площадки подписаны DVDD TEST VM. Хотелось бы поэкспериментировать с ним и, как следствие узнать как его инициализировать и хоть что-то вывести на экран. Лучше конечно бы алгоритм вывода увидеть. Пишу в среде Bascom AVR, но пройдясь по ветке, ничего на Бейсике не увидел ( потому и прошу алгоритм). Фотки дисплея выложить не могу - не крепятся в сообщение почему-то... :dont_know:

А не LPH9157-2 это, посмотри страницу 2 этой темы.

Igor_67

Да нет, это не он. Фотки в архиве.

Satyr

Если кому интересно.

затарил такой TFT8K1658

распиновка с http://master-electrix.at.ua/publ/opisa ... d/2-1-0-15
совпадает, контроллер нет. на самом деле R61501

Валяются еще TFT8K0561 и пара других, но до них руки не дошли пока.

Chettuser

Satyr писал(а):

Есть МК с внешней шиной под SRAM, на которую как родные вешаются телефонные экранчике с параллельной шиной.

Это случайно не PMP например в PIC'ах? Или я ошибаюсь?

Satyr

Chettuser писал(а):

Satyr писал(а):

Есть МК с внешней шиной под SRAM, на которую как родные вешаются телефонные экранчике с параллельной шиной.

Это случайно не PMP например в PIC'ах? Или я ошибаюсь?

PICами не занимаюсь.

Конкретно сейчас к stm32f205 привинтил.

Дисплеи от мобильных телефонов- осцилограммы работы

Кто сейчас на форуме