Экран от смартфона в качестве дисплея какой выбрать?

[omercury]

Сообщение от jump

справится!... если будет софткором на ПЛИС

http://cxem.net/mc/mc87.php если руки не из..., вернее голова на месте.

Да хоть непосредственно из головы растут.
У Вас в третьем классе по арифметике что было?

Оптимальное разрешение выбрано для PAL это 192х144

есть 5 и 7 дюймовые, разрешением 800х480.

Если мне не изменяет склероз, длительность прямого хода луча равна 57мкс.
57мкс/192=296,875 наносекунд на точку. При такте 19,6608МГц на это время уходит 296,875/(1/19660800)=5,8368 такта (какое странное число...). Таки на вывод одного байта из ОЗУ по индексу с автоинкрементом требуется 5 тактов. Теоретически проходит.
Для вывода на экран 800х480 ей потребуется обеспечить поток в 800*480*3*24(кадра/сек)=27648000 байт/сек или 27 Мегабайт в секунду.

"Шире рыла не плюнешь" (с)

[vdlab]

...
"Шире рыла не плюнешь" (с)

Вы это мне? Я это прекрасно знаю, и не собираюсь мегой рулить подобными дисплеями, тем более, что ваши расчеты не совсем корректны(поток данных занижен почти втрое). Для работы с ними есть куда более приспособленные для этого микросхемы, типа того же SSD1963, ну или ПЛИС+память. Ну и, естественно, управляющий МК должен быть соответствующей "весовой категории" иначе отрисовка будет слишком длительной. В некоторых случаях это допустимо, о чем я и писал ранее, а вовсе не о том, что это единственный правильный путь.

[Андрей К]

"Шире рыла не плюнешь" (с)

пля, я чуть со смеху не обдристался..

[igogo2]

На самом деле все гораздо проще.
В условиях было только два пункта:
1. Экран (предположительно цветной) 7 дюймов.
2. "голая" АТМега (без внешней памяти, контроллера и т.п.)

Вынужден уточнить. В условиях был только пункт 1!

[nahimovv]

Finita la comedia! Через страниц 15 появится ещё уточнение "да и 3-4" хватит".

[vdlab]

Вынужден уточнить. В условиях был только пункт 1!

Имелись в виду условия в сообщении №115. Первоначальные условия уже никому не нужны и не интересны(кроме вас, естественно), тема окончательно скатилась в оффтоп, так что полезного из нее выудить скорее всего уже не получится.

[anatol378]

Господа-товарищи! Чел, то бишь топикстартер хотел сделать осциллограф.
Не углубляясь в детали, кто может сказать сколько времени может не обновляться выведенная на дисплей картинка?
Ему нет необходимости делать телевизор, денди, смотрелку фотографий и т.д.
Вопрос проще загватил сигнал, оцифровал, обработал и рассматривай целый день.
Так вот будет дисплей работать фоторамкой?

[nahimovv]

Если с памятью, то да, а иначе - откуда?
Сейчас на блохастом форуме ЛИ, 62256 и другие мэтры тужатся-пыжатся в изобретении очередного велосипеда-осцила на STM32F4XX. Но на "конструкцию выходного дня" это уже никак не тянет.

[vdlab]

Не углубляясь в детали, кто может сказать сколько времени может не обновляться выведенная на дисплей картинка?

Это больше вопрос комфортности восприятия, хотя в некоторых случаях может понадобиться и довольно частое обновление осциллограммы. В общем случае частота обновления должна быть 2-10 раз в секунду, меньше уже неудобно, можно пропустить выбросы или фронты, а чаще не имеет смысла так как глаз все равно не успеет уследить за сменой информации.
Впрочем, это, при правильной организации отображения, абсолютно не проблема даже на ПИК16, не говоря уже о АТМеге. Куда бОльшая проблема это собственно оцифровка а так же дальнейшая обработка сигнала (математические функции, маркеры, измерение частоты, амплитуды и т.д.) Вот тут то слабенький контроллер и не потянет.

[Vadim_sh]

пару лет пользуюсь, когда с авто ковыряюсь (кислородник глянуть, дпкв и т.д.), вполне хватает.
может и ТС не подумав пожелал 7"? Если время появится, хочу собрать себе логгер с 3.2", каном, к-лайном, осциллом и т.д. (на ПИКе 32-м )