Помогите определиться с камнем, дисплеем и пр. Опции

[zheka]

Помогите определиться с камнем дисплеем и пр....

Господа!
Планируется мелкосерийное полукустарное устройство, для друзей и, что называется, "для сэбе".

Включает в себя дисплей 400х240 с тачскрином, SD карту, DataFlash для хранения картинок, возможно SDRAM и какой-нибудь камень.

Камень преткновения - дисплей. Если брать промышленный TFT с RGB интерфейсом - дороговато, да и камни интерфейсом LCD зело многоногие, да и частоты у них от 200 МГц, а я во-первых слаб в высокочастотной разводке, во-вторых боюсь как бы не пришлось на многослойке городить..

По цене, простоте освоения я пока склоняюсь к варианту дисплея от мобильного телефона Samsung S5230. Интерфейс у него параллельный (D[0.7], CS, RD, WR....). Управляется ногодрыганьем. Камень хочу взять LPC1768, c ядром Cortex M3 с его 100 МГц и FastGPIO скорости за глаза.

Теперь собственно вопросы:
1. Имеются ли промышленные дисплеи 400х240 со встроенным контроллером с параллельным интерфейсом? Если да, то я готов рассмотреть их пусть, даже они и дороже. Ведь если рассчитывать на экран от мобильного, лет через 5 его уже не найдешь. Впрочем отсюда следующий вопрос - как нынче с моральным устареванием промышленных дисплеев? Они так же держдатся на рынке в течение 5 лет, а потом становятся дефицитом?

2. Не подскажут ли люди знающие, какой частоты ногодрыганья можно достичь на 100 МГц c FastGPIO? Общение с дисплеем идет по простому протоколу - выдал данные, включил CLK, выключил CLK, следующие данные. По предварительной прикидке - 400х320*24бит*30fps =8 640 000 операций выдачи данных и передергивания CLK в секунду. Справится ли контроллер?

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

4. Можно ли сгородить это на ядре ARM7? Оно как-то попривычней...

В общем, я на распутье, наставьте на путь истинный.


Ну и конечно же шкурный вопрос - хочется чтобы каушек был не дороже 300 рублей. LPC1768 видел за 240 руб.

[EugenyAM]

По цене, простоте освоения я пока склоняюсь к варианту дисплея от мобильного телефона Samsung S5230. Интерфейс у него параллельный (D[0.7], CS, RD, WR....). Управляется ногодрыганьем.

STM32F103 с контроллером FSMC поддерживает ногодрыгание по параллельному интерфейсу аппаратно. Для пересылки данных из памяти поддерживается DMA.
Тактовая частота камня 72 МГц, цена до 300р
если надо до 120МГц, можно взять серию STM32F2xx, правда цена уже >400.

Сообщение отредактировал EugenyAM - Nov 29 2011, 07:48

[Dron_Gus]

Возьмите контроллер с LCD интерфейсом / внешней паралельной шиной и сэкономьте кучу нервов. Напрмер такой http://starterkit.ru/html/index.php?name=s...=view&id=66 . Если дисплей со встроенным флеймбуфером (например такой http://starterkit.ru/html/index.php?name=s...=view&id=46 ) то гемороя еще меньше. Двойной фреймбуфер имеет смысл городить, если Вы хотите выводить анимацию, трехмерную графику, видео и т.д. Если это просто юзер интерфейс - это лишнее.

[zheka]

STM32F103 с контроллером FSMC поддерживает ногодрыгание по параллельному интерфейсу аппаратно
Тактовая частота камня 72 МГц, цена до 300р

Тема частоты ногодрыганья не раскрыта.

Двойной фреймбуфер имеет смысл городить, если Вы хотите выводить анимацию, трехмерную графику, видео и т.д. Если это просто юзер интерфейс - это лишнее.

Недавно работал с дисплеем 800х480 точек. Картинки выводились из DataFlash. Кадр выводился примерно за 0.5-0.8 сек. Правда это был Jpeg. С бинарником быстрее, но он очень много памяти жрал. Даже несколько мелких картинок с кнопками при их прорисовке вызывали неприятный фликер. Приходилось грузить их в 2 из 4-х видеостраниц и оттуда выводить.

Посему все же акцентирую внимание на ранее заданном вопросе - за какой промежуток времени дисплеи обычно рисуют кадр? Точнее говоря, за какой промежуток времени контроллеры с LCD рисуют кадр? Они ведь рисуют его 30 раз в секунду, выводя содержимое видеопамяти. Сможет ли контроллер 100 МГц используя FastGPIO нарисовать 400х240 точек за тот же период времени? А то, может быть мне и не стоит заморачиваться и грузить картинки прямо из DataFlash?



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

[AlexandrY]

2. Не подскажут ли люди знающие, какой частоты ногодрыганья можно достичь на 100 МГц c FastGPIO? Общение с дисплеем идет по простому протоколу - выдал данные, включил CLK, выключил CLK, следующие данные. По предварительной прикидке - 400х320*24бит*30fps =8 640 000 операций выдачи данных и передергивания CLK в секунду. Справится ли контроллер?

Нынче редкий дисплей найдешь без параллельного 8080 интерфейса и видеопамяти.
Уже давно нет необходимости городить собственные протоколы на GPIO и с динамической разверткой.

Вот демопроект на обычном дисплее:

Подключение LCD к STM32F10x

Дисплеи такие производятся от силы по полгода и дальше новый надо искать. Но интерфейс типа 8080 неизменен и живет уже десятилетиями.
Переписать драйвер дисплея занимает не больше одного дня при известной сноровке.

[zheka]

STM32F103R6T6A

вообще 100 рублей стоит. Надо задуматься.

Уже давно нет необходимости городить собственные протоколы на GPIO и с динамической разверткой

Дисплей хочется дешевый, от мобильного.
Может быть есть что-то китайское недорогое, рублей за 300?

[AlexandrY]

Дисплей хочется дешевый, от мобильного.
Может быть есть что-то китайское недорогое, рублей за 300?

Делать для себя и ставить дешевый дисплей? ...

Кстати STR32F2xx аккурат 60 МГц выдает на GPIO если линейная последовательность операторов.
Но на ветвлениях под 60 нс задержки могут быть.

[Dron_Gus]

Ищите китайские фоторамки. Дешевле купить их и раздербанить. Но вот документацию на них Вам никто не даст.

[Axel]

... за какой промежуток времени дисплеи обычно рисуют кадр? Точнее говоря, за какой промежуток времени контроллеры с LCD рисуют кадр?...

Часто используемый контроллер TFT-матрицы HX8352 имеет время обращения менее 150ns при ширине шины 16 бит. Кадр дисплея 240х400 в формате 5-6-5 можно загрузить быстрее 20ms. Проверено с экраном DLC0320BMG-T.

[zheka]

Ды господи...
Причем здесь фоторамки?
Я же написал что у меня был выбор - дисплей от мобильного , дешевый, с документацией, с примером кода, но живущий не более 5-ти лет, после чего его не найдешь, либо промышленный дисплей, с контроллером, окучиваемый ногодрыганьем, который, как выяснилось тоже быстро морально устаревает.
Кроме того, насколько я знаю, может быть я ошибаюсь, но здесь же на форуме кажется читал, что дисплеи от мобильных хоть и хуже промышленных, но не намного, а дешевые они потому что производство их массовое, в тиражах, куда больших, чем у отдельных моделей промышленных. Так что почему бы не воспользоваться.

Кстати STR32F2xx аккурат 60 МГц выдает на GPIO если линейная последовательность операторов.

Это что - по одному такту на изменение состояние порта?

[AlexandrY]

Это что - по одному такту на изменение состояние порта?

Точно. GPIO же там теперь на 120 MHz AHB шине сидит.

[Dron_Gus]

Ды господи...
Причем здесь фоторамки?

Вы спросили:

Дисплей хочется дешевый, от мобильного.
Может быть есть что-то китайское недорогое, рублей за 300?

Я вам ответил.

Ищите китайские фоторамки. Дешевле купить их и раздербанить. Но вот документацию на них Вам никто не даст.

[-=Женек=-]

Хм.. изучаю линейку этих STM'ов - какие-то порты у них 16-тибитные. В AT91SAM7 вроде бы был порт A[0..31]. А как здесь быть? Если я закапризничаю и захочу 32-битное число за 1 такт записать.

Точно. GPIO же там теперь на 120 MHz AHB шине сидит.

Линейка F2хх не подойдет - излишне, да и дорого.
Присматриваюсь к F103хх. Там как дела обстоят с GPIO? Пока не нашел информации на этот счет.



Вот теперь нашел - 18 MHz toggling speed....
Получается 3 такта на пиксель - 6 Мпикселей в секунду... короче 50 мсек на заливку экрана. Скажите, визуально это будет восприниматься как мгновенная смена цвета или будет видна заливка?

[aaarrr]

Получается 3 такта на пиксель - 6 Мпикселей в секунду... короче 50 мсек на заливку экрана. Скажите, визуально это будет восприниматься как мгновенная смена цвета или будет видна заливка?

Будет видна. Чтобы не было никаких tearing-эффектов, нужно уложиться в 15мс с синхронизацией по началу кадра. Или использовать страницы памяти экрана, если они есть.

[-=Женек=-]

tearing-эффектов,

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

Уж извините за размер файла.

Еще вопрос - у меня сложилось впечатление, что равновесные LPC дороже чем STM. Чем это объясняется - ценовая политика?

Прикрепленные файлы

 S6D04D1X21_Data_Sheet_REV0.10.rar ( 5.34 мегабайт ) Кол-во скачиваний: 1727

 

[aaarrr]

Можно обновить экран за время, близкое ко времени развертки 2-х кадров: т.е. начинаем писать с задержкой относительно начала первого кадра (т.е. пишем в ту область, которую "луч" уже прошел) и продолжаем во время развертки второго.
Но все равно, 50мсек - это слишком долго.

[-=Женек=-]

Блин... А ведь есть решение. Я подобрал контроллер серии F2, но с меньшим количеством ног и памяти , за счет чего он в принципе недорогой - stm32f205rb
Итого имеем 120 МГц, 60 МГц переключения, тогда получаем ровно 15 мсек на заполнение экрана!

Но блин.... частота предъявляет требования. Скажите, на 120 МГц-х уже есть проблема гонки сигналов? Какой длины должны быть дорожки, чтобы гонка сигналов не влияла?

[aaarrr]

Итого имеем 120 МГц, 60 МГц переключения, тогда получаем ровно 15 мсек на заполнение экрана!

Заполнения одним цветом - да, но если нужно рисовать что-то осмысленное, то добавьте к этому еще время обращения к памяти.

Но блин.... частота предъявляет требования. Скажите, на 120 МГц-х уже есть проблема гонки сигналов? Какой длины должны быть дорожки, чтобы гонка сигналов не влияла?

Что такое "гонка сигналов"?

[Aner]

Может что-то готовое устроит за ~$70...$100 на 1ГГц 9-ом арме? Тамже точскрин хотите резистивный, или емкостной. И + всего прочего много.

[-=Женек=-]

Заполнения одним цветом - да, но если нужно рисовать что-то осмысленное, то добавьте к этому еще время обращения к памяти.

Я знаю об этом. Но ведь оценивать надо по базовым и более предсказуемым нагрузкам не так ли?

Может что-то готовое устроит за ~$70...$100 на 1ГГц 9-ом арме?

Нет, не подойдет.

[aaarrr]

Я знаю об этом. Но ведь оценивать надо по базовым и более предсказуемым нагрузкам не так ли?

Так базовая нагрузка это как раз "нарисовать что-то из памяти", разве нет?

[-=Женек=-]

Ааа.. ну если только нарисовать из памяти полный кадр, тогда вы правы.

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

[goodwin]

Нет, не подойдет.

Ну да. Какой интерес в автонафигаторе/планшете за 60-70$, подточенном под задачу при помощи C#...
То ли дело купить дисплей с тачем почти за эту же цену, камень, присопливить к нему SDRAM, изготовить плату-многослойку, выпилить лобзиком корпус из фанеры с благородными вставками из стеклотекстолита и главное натрахаться всласть до изнеможения Красота!

[-=Женек=-]

goodwin, если написать по делу нечего, если мысли ваши неадекватны обсуждаемой теме, может быть лучше помолчать?

[Dron_Gus]

Подключить все на ногодрыгвнье это пункт ТЗ? Или все же рассматриваете адекватные варианты?

[-=Женек=-]

Dron_Gus, Dataflash и SD-карта -по SPI.
А дисплей и SDRAM без ногодрыганья никак.
Надесюь не будете предлагать мне искать ARM9 со SDRAM интерфейсом? К тому же, SDRAM'ом я рулил даже с помощью AVR.

[Dron_Gus]

LPC1788 имеет интерфейс к SDRAM.
Дисплей (если со встроенным контроллером) прекрасно вешается на паралельную шину 8080, 6800. Или даже на SPI. Да и безконтроллерный можно с извратами навесить на паралельный интерфейс. Всяко быстрее ногодрыгства.

[-=Женек=-]

Ударим конкретикой по буржуазно-контрреволюционной абстракции, товарищи:

Или даже на SPI.

Не знаю, какова частота SPI в LPC, в STM32F2 она 30 мбит/сек. А ногодрыганьем с параллельным интерфейсом получается 20- мБАЙТ/сек При 3 операциях на пиксел и 120 МГц тактовой, 60 МГц чатоты переключения GPIO.

Да и безконтроллерный можно с извратами навесить на паралельный интерфейс. Всяко быстрее ногодрыгства.

Учитывая вышесказанное, мне сложно представить себе какой либо интерфейс в STM32, обеспечивающий, скажем так частоту смены состояния пинов более чем 60 МГц.

[-=Женек=-]

Вот скажите - это 8080 ? Можно этим управлять с помощью упомянутого параллельного интерфейса?

Прикрепленные файлы

 ___________________S5230.pdf ( 100.22 килобайт ) Кол-во скачиваний: 139

 

[aaarrr]

Да, это 8080.

[-=Женек=-]

Да, это 8080.

Очень хорошо.
Только что-то я не могу в 1312-страничном даташите найти информацию. По ключевому слову 8080 поиск результатов не дает. Слово parallel выдает кучу мусора. Хоть подскажите, где примерно искать описание этого интерфейса.

[M_Andrey]

Очень хорошо.
Только что-то я не могу в 1312-страничном даташите найти информацию. По ключевому слову 8080 поиск результатов не дает. Слово parallel выдает кучу мусора. Хоть подскажите, где примерно искать описание этого интерфейса.

Дисплей 480 x RGB x 272(TFT) с течскрином.  WF43ATIBEDB.pdf ( 428.54 килобайт ) Кол-во скачиваний: 372



Его контроллер.  SSD1963.pdf ( 1.69 мегабайт ) Кол-во скачиваний: 313

[aaarrr]

Static Memory Controller, FSMC он у ST называется, если не путаю.

[-=Женек=-]

Дисплей 480 x RGB x 272(TFT) с течскрином. WF43ATIBEDB.pdf ( 428.54 килобайт ) Кол-во скачиваний: 1

Как насчет цены в 2200 рублей?

[Jury093]

Планируется мелкосерийное полукустарное устройство, для друзей и, что называется, "для сэбе".
Включает в себя дисплей 400х240 с тачскрином, SD карту, DataFlash для хранения картинок, возможно SDRAM и какой-нибудь камень.

по экранам - полистайте тыц, там разнообразные экраны.. и SPI, и 8080 и RGB..
по STM32Fxxx - на сайте st.com была аппнота, как рулить rgb-экраном через gpio - поищите.. хотя это заведомо тупиковый вариант. толку от stm32+rgb-lcd столько же, как и от Atmega8+TV out, т.е. ноль..
чем гадать, купите один камень, подключите осцилл и все сами измерите..
и поотчетливее с начальными условиями - необязательно расписывать что будет делать ваш мегадевайс, достаточно дать базовые вводные "с датафлеша битмапы размером Х будут пересылаться на экран, с SD карты будет считываться поток со скор не менее 3МБ/с и тыпы"

[scifi]

Только что-то я не могу в 1312-страничном даташите найти информацию. По ключевому слову 8080 поиск результатов не дает. Слово parallel выдает кучу мусора. Хоть подскажите, где примерно искать описание этого интерфейса.

Эх, молодёжж... :-)
Вроде бы это называется Intel/Motorola или 8080/6800.
Описание можно тут: 8080, 6800.
Самая заметная разница - сигналы RD, WR.

[-=Женек=-]

ну блин... мнения ученых разошлись.. кто-то бьет себя в грудь про 60 МГц, кто-то говорит - купи камень и пощупай осциллографом. Ну а с моей стороны спросить - мож у кого есть камень, может кто уже мерял - это разве хамство?

толку от stm32+rgb-lcd столько же, как и от Atmega8+TV out, т.е. ноль..

Рулил AT90SAM7S и экраном 320х240. Получил 60 мс ногодрыганьем. Неужели с STM32 все будет так плохо? В конце концов кто-то тут писал что если не собираешься видео гонять, ради бога...
Я прекрасно понимаю, что результат меня устроит в любом случае, просто хочу наиболее рационально и по средствам и по возможностям подобрать колмбинацию компонентов. ОДнажды я уже поторопился и купил SAM7S, даже не зная, что пины у него не быстрее чем у АВР,

[scifi]

Если не секрет, что за нездоровое пристрастие к ногодрыганию? Бывают ведь интерфейсы внешней памяти (у STM32 - FSMC) или графические контроллеры для формирования сигналов RGB.
Ну а в семействах STM32F2xx, STM32F4xx частота FSMC - это Fcpu/2. GPIO там сидит на AHB, то есть может менять состояние с частотой Fcpu. В STM32F1xx GPIO сидит на APB2, что должно быть медленнее, чем AHB, но на сколько именно - хз.

[-=Женек=-]

В STM32F1xx GPIO сидит на APB2, что должно быть медленнее, чем AHB, но на сколько именно - хз.

в 2 раза медленней. 18 МГц при 72 МГц.

Если не секрет, что за нездоровое пристрастие к ногодрыганию?

Наличие готовой библиотеки. Шутка.

Бывают ведь интерфейсы внешней памяти (у STM32 - FSMC)

ОБъясните мне пожалуйста - использование FSMC для управления дисплеем по протоколу 8080 - это какое-то не совсем стандартное его применение? Просто в даташите ни слова не сказано ни про LCD ни про 8080. Насколько я понял при беглом просмотре, эту штуку при соответствующей настройке регистров можно приспособить под что угодно?

на сайте st.com была аппнота, как рулить rgb-экраном через gpio - поищите

Нашел. Еще бы аппликуху по интерфейсу 8080 для управления LCD

[aaarrr]

ОБъясните мне пожалуйста - использование FSMC для управления дисплеем по протоколу 8080 - это какое-то не совсем стандартное его применение?

Стандартнее не придумать.

[-=Женек=-]

Отлично. Нашел аппликуху с примером кода на STM32F1xx для интерфейса 8080.

Вот только на распутье я. Что за память поставить - SRAM или SDRAM. С одной стороны SRAM проще будет подключить, FSMC под нее заточен. С другой стороны - нужно минимум 512 Кб, да и то - они пойдут на одну видеостраницу. А вот ежели захочется сохранить фрагмент экрана в памяти - не получится.
SDRAM - можно порулить ей столь ненавистным всем ногодрыганьем, зато получим несколько видеостраниц, куда можно будет грузить все что захочешь.

Что в данной ситуации разумней?

[blackfin]

Что в данной ситуации разумней?

SDRAM, ессно.. ;)

[-=Женек=-]

Спасибо. К тому же со SDRAM может вообще выйти 2 операции на байт - CLK=1 и CLK=0, если гнать данные напрямую в дисплей, а контроллер будет просто управлять CLK.

Аналогичный вопрос -для хранения картинок, для создания подобия файловой системы что лучше - DataFlash или NANDFlash ?

[aaarrr]

Что в данной ситуации разумней?

А я скажу, что лучше PSRAM без "ногодрыганья".

[-=Женек=-]

Скажите чем она лучше ?

Она как-то слабодоставабельна. Недорогая за мегабайт, но малообъеных, дешевле 200 руб не сыщещь
Уж лучше SDRAM.

Так что насчет Флеши?

[Dron_Gus]

NAND дешевле за единичу объема, но сложнее в использовании. Для нормальной работы с НАНДом большого обьема необходимо достаточно большое количество РАМа.

[-=Женек=-]

ну если мне надо всего 1 мбайт, наверное DataFlash предпочтительней будет.

[aaarrr]

ну если мне надо всего 1 мбайт, наверное DataFlash предпочтительней будет.

Тогда уж лучше M25P(E).

P.S. А вообще, лучше нормальный процессор с контроллером SDRAM и TFT + экран без контроллера. Дешевле, мощнее и нет нужды в извратах.

[-=Женек=-]

P.S. А вообще, лучше нормальный процессор с контроллером SDRAM и TFT + экран без контроллера. Дешевле, мощнее и нет нужды в извратах.

Дисплей - 290 руб
Подходящий именно под этот дисплей корпус от мобильника - 100 руб.
Тачскрин - 60 руб
Проц STM32F2 - 290 руб
SDRAM - 110 руб.

Итого 850 руб


Приведите Вашу смету для сравнения.

[aaarrr]

Проц STM32F2 - 290 руб

За те же деньги (286.4 руб) можно взять LPC1788 с контроллерами SDRAM, TFT и прочими плюшками.

[-=Женек=-]

Ну а TFT без встроенного контроллера на 400х240 самый дешевый сколько?


дисплей планируется от мобильного - качество устраивает. Доставаемость за мкадом тоже. Цена особенно устраивает. А большинство из них с контроллером и интерфейсом 8080. Так что FSMC или ногодрыг рулят. Ибо на ногодрыг уже есть библиотека - уменьшатся сроки разработки. Ногодрыговая библиотека для SDRAM собственной выпечки тоже имеется.

[aaarrr]

Ну а TFT без встроенного контроллера на 400х240 самый дешевый сколько?

Если интересуют промышленные масштабы, то дешевле, чем аналогичный с контроллером. Для изделия в единичном экземпляре смысла считать цену не вижу.

дисплей планируется от мобильного - качество устраивает. Доставаемость за мкадом тоже. Цена особенно устраивает. А большинство из них с контроллером и интерфейсом 8080. Так что FSMC или ногодрыг рулят. Ибо на ногодрыг уже есть библиотека - уменьшатся сроки разработки. Ногодрыговая библиотека для SDRAM собственной выпечки тоже имеется.

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

[-=Женек=-]

Если интересуют промышленные масштабы, то дешевле, чем аналогичный с контроллером. Для изделия в единичном экземпляре смысла считать цену не вижу.

Ни то ни другое. В лучшем случае несколько десятков.

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

Да нет, просто не хочется брать многоножку. И ногодрыг не самоцель. Зачем искать контроллер со SDRAM и LCD TFT, после подключения которых у контроллера останется сотня лишних ног, если контроллеры эти не нужны по вышеуказанным причинам - мне выгоднее покупать дисплеи от мобильных со встроенным контроллером. А дисплей я уже давно, если кто не заметил не собираюсь управлять ногодрыгом, а буду разбираться с FSMC. Ну а SDRAM - мне и разбираться не нужно будет.

Ладно, я в принципе уже определился с камнем, аппликухи и примеры кода нашел. Объявляю перерыв до рисования схемы и платы, которые потом выложу на ваш суд.

[-=Женек=-]

поставщики в моем городе менее чем за 450 рублей LPC1788 не возят.
А доставка оттуда где дешевле, обойдется рублей в 200.

Хотя aaarrr уже убедил меня хотя бы рассмотреть этот вариант.

[-=Женек=-]

Господа, ну простите мне мою упертость и дремучесть. Я любитель, а не профессионал.

Значит решено, что SRAM неоправданно дорого и не позволит сделать несколько видеостраниц. Решено значит использовать SDRAM.
Управлять буду просто - адресные линии на один порт, линии данных на другой порт, линии команд - на третий порт. По крайней мере в AVR у меня это реализовано и проблем не вызывает.

Рисовать буду непосредственно в SDRAM, а потом, ориентируясь на сигшнал TE от дисплея перекидывать картинку в дисплей.
С целью максимальной скорости обновления информации линии данных SDRAM, будут напрямую физически подключены к линиям данных дисплея. ДАю команду на пакетное чтение в SDRAM, команду на запись в дисплей, а потом просто дергаю CLK с частотой 120 МГц/2.

Исходя из этого, объясните мне, какой преимущество даст FSMC? Нужно ли мне покупать многоножку на 100 ног, в которой есть этот контроллер или может быть обойтись контроллером с 64 ногами?

Какие преимущества по скорости и в плане программирования даст FSMC?

[Dron_Gus]

Какие преимущества по скорости и в плане программирования даст FSMC?

При таком подходе разве что обращения контроллера к дисплею будут занимать одну команду. Выполняться они, правда, будут дольше (в зависимости от настроек FSMC).
А в 64 ноги влезете?
Кстати клок можно генерировать аппаратным таймером - должно быть быстрее, чем програмно ножкой дергать.

[aaarrr]

С целью максимальной скорости обновления информации линии данных SDRAM, будут напрямую физически подключены к линиям данных дисплея. ДАю команду на пакетное чтение в SDRAM, команду на запись в дисплей, а потом просто дергаю CLK с частотой 120 МГц/2.

У контроллера вашего дисплея цикл записи 60нс, можно так не спешить.

Какие преимущества по скорости и в плане программирования даст FSMC?

Основное преимущество - свободное ядро. По скорости же без учета загрузки процессора железка все равно выиграет в девяти случаях из десяти.

[-=Женек=-]

Основное преимущество - свободное ядро. По скорости же без учета загрузки процессора железка все равно выиграет в девяти случаях из десяти.

То есть ему дал команду прочитать и передать 1 кб, он читает, а ядро можно занять чем-то другим?

контроллера вашего дисплея цикл записи 60нс, можно так не спешить.

При этом получается 1 кадр записывается за 17 мсек. А надо за 15. Странно все это.
Коли так, тогда и контроллер на 120 МГц не нужен

А если все-таки с контроллером 8080 - тогда непонятно, как ему объяснить, откуда брать данные - интерфейса к SDRAM он не имеет. В аппликухе написано конечно, как гнеать данные через DMA, но это для SRAM и NAND

[aaarrr]

А если все-таки с контроллером 8080 - тогда непонятно, как ему объяснить, откуда брать данные - интерфейса к SDRAM он не имеет. В аппликухе написано конечно, как гнеать данные через DMA, но это для SRAM и NAND

Задействовать M2M DMA. Ему все равно, откуда брать данные, будь то SRAM или SDRAM.

[-=Женек=-]

А скажите, адресные линии и линии данных SDRAM цеплять на любой порт? FSCM это потерпит?

[aaarrr]

А скажите, адресные линии и линии данных SDRAM цеплять на любой порт? FSCM это потерпит?

Линии адреса и данных должны быть подключены в соответствии с даташитом, и уж точно не на произвольные порты.
Что касается возможного swapping'а, то можно переставлять линии данных в пределах одного октета. Адреса в общем случае трогать нельзя.

[-=Женек=-]

да.. читаю даташит и в шоке... без поллитра даже не разберешься что и куда подключать...

[aaarrr]

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

[-=Женек=-]

да нет, просто в даташите в 5 раз большем по объему, чем от АВР и разобраться в 5 раз сложнее)))

Схемку ST-STM3210E-EVAL нашел, изучаю.
Я так понял, что можно разместить хоть 10 типов микросхем памяти, главное устроить для них общую шину данных?

[aaarrr]

Я так понял, что можно разместить хоть 10 типов микросхем памяти, главное устроить для них общую шину данных?

Ну, под десятью оно, положим, умрет, но 3-4, как в помянутом ките, разместить можно.

[-=Женек=-]

Не пойму, а где на 100-пиновых вариантах A0-и первые несколько адресов?

[aaarrr]

Вы бы уточнили, о каком процессоре идет речь вообще. Если о STM32F103, то у них стоногом корпусе FSMC урезан:

For the LQFP100 and BGA100 packages, only FSMC Bank1 and Bank2 are available. Bank1 can only
support a multiplexed NOR/PSRAM memory using the NE1 Chip Select. Bank2 can only support a 16- or
8-bit NAND Flash memory using the NCE2 Chip Select. The interrupt line cannot be used since Port G is
not available in this package.

[-=Женек=-]

я выбрал STM32F205V. Куда цеплять адресные линии для SDRAM?

[Axel]

я выбрал STM32F205V. Куда цеплять адресные линии для SDRAM?

В FSMC STM32 есть подводные грабли - биты адреса переназначаются в зависимости от разрядности шины данных:

"In case of a 16-bit external memory width, the FSMC will internally use HADDR[25:1] to generate the
address for external memory FSMC_A[24:0].
Whatever the external memory width (16-bit or 8-bit), FSMC_A[0] should be connected to external memory
address A[0]."

Мне довелось по ним пробежаться (после "нормального" LPC24)...

[-=Женек=-]

C удивлением обнаружил, что IAR 6.2 не поддерживает stm32F205Vхх.
Нет не только хидеров но и в настройках проекта выбрать нельзя.
Посему выбрал F103VE.


не могу только понять, биты данных FSMC так разбросаны по ногам контроллера?

[aaarrr]

C удивлением обнаружил, что IAR 6.2 не поддерживает stm32F205Vхх.

Да какая разница, ядро ведь поддерживает.

[scifi]

C удивлением обнаружил, что IAR 6.2 не поддерживает stm32F205Vхх.
Нет не только хидеров но и в настройках проекта выбрать нельзя.
Посему выбрал F103VE.

Хе-хе! До чего же несерьёзно. Эдак мы будем выбирать МК на основании гороскопа, продиктованного по утреннему радио.
Невредно было бы вспомнить (или почитать), что такое компилятор, процессор, набор инструкций. И что хедеры в крайнем случае можно написать самому довольно быстро, или выдернуть откуда-нибудь ещё.

[-=Женек=-]

Хе-хе! До чего же несерьёзно. Эдак мы будем выбирать МК на основании гороскопа, продиктованного по утреннему радио.
Невредно было бы вспомнить (или почитать), что такое компилятор, процессор, набор инструкций. И что хедеры в крайнем случае можно написать самому довольно быстро, или выдернуть откуда-нибудь ещё.

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

[011119xx]

Сейчас у меня к STM32F103 подключен дисплей 320х240 с контроллером ILI9325, шина данных 16-ти битная, соответственно и 16 бит на цвет. Пробовал подключать дисплей с использованием любимого многими FSMC и просто управлять дисплеем программно (так называемое ногодрыганье ). Так вот при ногодрыганье заполнение экрана ОДНИМ цветом занимает 9 мс. При использовании FSMC гораздо дольше (FSMC любит тратить время на совершенно лишнее действие по дрыганью ногой выбора кристалла памяти с которой работает, постоянно дергает. Спрашивается зачем). Поэтому я для себя однозначно решил забить на этот FSMC (для работы с дисплеем он не годится). Опять же если заполнять экран не одним цветом, а выводить какую то картинку из то ли карты памяти, то ли sFlash, то время заполнения однозначно увеличивается. Например, при выводе картинки из sFlash, получаем время порядка 96 мс. Если из карты памяти, то время вывода зависит от формата файла и измеряется уже от 235 мс и более. Вот проект http://vrtp.ru/index.php?showtopic=16957 , не сочтите за рекламу.

[-=Женек=-]

Становится интересно.
Начну-ка я с самодельной отладочной платы с выведенными под разъемы портами и светодиодами... А там видно будет.

011111119хх, а исходника нет?

[011119xx]

Исходники конечно же есть ... А может не стоит изобретать велосипед, а присоединиться к существующему проекту?

[aaarrr]

Тем более, что камень настолько хитрый что никто ответа на вопрос о подключении нестандартной микросхемы в посте 68 не знает.

Вам пины GPIO расписать что ли? Какая разница, куда цеплять SDRAM, если она не поддерживается все равно?

Так вот при ногодрыганье заполнение экрана ОДНИМ цветом занимает 9 мс. При использовании FSMC гораздо дольше

Насколько дольше, цифру можете привести? В жизни не поверю, что FSMC не может сделать цикл доступа 100нс.

Тормоза можно получить разве что используя для записи отдельные STRH вместо STM.

[011119xx]

Насколько дольше, цифру можете привести? В жизни не поверю, что FSMC не может сделать цикл доступа 100нс.

Тормоза можно получить разве что используя для записи отдельные STRH вместо STM.

Цифры привести к сожалению не могу, но на глаз ощутимо заметна разница (согласен, что это не конструктивный подход). Но вы же не будуте спорить с тем, что FSMC дергает ногой CS (грубо говоря) при каждой передаче? А на это тоже время уходит.

[aaarrr]

Но вы же не будуте спорить с тем, что FSMC дергает ногой CS (грубо говоря) при каждой передаче? А на это тоже время уходит.

Не буду. Но времени этого у него вагон - аж 100нс целых.

[011119xx]

Можем посчитать. Для диспа 320х240 имеем 76800 пикселей. Столько раз FSMC дернет ногу CS. Допустим дерганье одного раза 100 нс, тогда общее время получаем 7,68 мс. Так это только для CS, а там еще и другие сигналы есть.

Сообщение отредактировал 011119xx - Dec 6 2011, 08:00

[ViKo]

У меня STM32F103 работает с контроллером ЖКИ S1D13706, посредством FSMC.
Контроллер довольно медленный, задаю режимы, соответствующие его временным характеристикам.

Код

  FSMC_Bank1->BTCR[6] = 0x00009011; // ASWait,WrEn,WrapDis,FlashAccDis,16-bit,SRAM,NoMux,En
// (8T) дает то же, что и (11T), из-за WAITn
  FSMC_Bank1->BTCR[7] = 0x00000800; // Mode1 0(+1)\_08_____ _/(+1)

Проверял осциллографом. Точно не помню, кажется, весь цикл записи занимает именно 11 тактов, т.е. 153 ns.
Для пересылки пытался задействовать DMA, но, оказалось, программно перекидывать 32-битовые слова (хотя шина 16-битовая) - проще, надежней и, кажется, быстрее. Потому что при DMA шина задействуется еще и для других задач. Особенно поразило, что при работе в отладчике (Keil), процессор вообще улетал в HardFault. А если ту же программу запускать из Flash без отладчика, то не зависал.

[011119xx]

Проверял осциллографом. Точно не помню, кажется, весь цикл записи занимает именно 11 тактов, т.е. 153 ns.

Это время записи одного пикселя?

[ViKo]

Это время записи одного пикселя?

Да, одна запись 16-битового слова, хоть пикселя, хоть выборки, хоть символа.
Это время я сам задал приведенными выше командами. Можно сделать намного быстрее, если устройство тянет. Например, для обращения к ОЗУ хватило 5 тактов.

[011119xx]

Значит FSMC работает быстрее программного дерганья пинов?

[ViKo]

Значит FSMC работает быстрее программного дерганья пинов?

Никогда в этом не сомневался!

[011119xx]

Тогда почему FSMC может тормозить?

[ViKo]

Тогда почему FSMC может тормозить?

Проверьте свои настройки. Посмотрите осциллографом (зациклите программу на записи).
Если работает DMA и программный доступ к внешней памяти одновременно, то они будут делить шину.

[-=Женек=-]

aaarrr

Вам пины GPIO расписать что ли? Какая разница, куда цеплять SDRAM, если она не поддерживается все равно?

При всем уважении к Вам, вы сами себе противоречите:

А скажите, адресные линии и линии данных SDRAM цеплять на любой порт? FSCM это потерпит?

Линии адреса и данных должны быть подключены в соответствии с даташитом, и уж точно не на произвольные порты.
Что касается возможного swapping'а, то можно переставлять линии данных в пределах одного октета. Адреса в общем случае трогать нельзя.

ПРошу заранее меня простить, я как человек, не имевший дел с подобным камнем, понимаю все буквально.

[aaarrr]

При всем уважении к Вам, вы сами себе противоречите:

Никакого противоречия: в одном случае речь шла о подключении памяти к контроллеру SDRAM (и тут далеко не все равно куда и как), а в другом - о подключении SDRAM к GPIO (тут дело удобства и вкуса).

Просто из первого сообщения трудно было понять, куда и как Вы собирались подключать память. То есть на самом деле вопрос был о том, не помешает ли работе FSMC подключенная к GPIO SDRAM, так?

Если так, то можно подключать как удобно. Извините, если невольно ввел в заблуждение.

[-=Женек=-]

То есть на самом деле вопрос был о том, не помешает ли работе FSMC подключенная к GPIO SDRAM, так?

Если так, то можно подключать как удобно.

Да именно это я и хотел узнать. ТОлько я хотел узнать еще - если у меня линии данных дисплея и линии данных SDRAM сидят на разных пинах, то для прямой передачи данных потребуется DMA - вот я и спрашивал - контроллеру DMA не пофиг, откуда брать данные и куда их пересылать?
Но теперь у меня несколько иной вопрос - вот у нас FSMC - будь он неладен, хоть бы в двух словах понять смысл его работы, а то в даташите деталей на 100 страниц, не разберешся сразу.
Так вот если все таки подключить SDRAM на общую адресную шину, нельзя ли с помощью FSMC выбирать адрес и принимать данные (дабы не переключать пины каждый раз в режим GPIO и обратно), а управляющими ногами управлять с помощью GPIO?

ПОймите, я хочу во-первых использовать SDRAM, во вторых передавать данные из SDRAM в дисплей максимально быстро. А это можно сделать либо использовав одни и те же пины данных для дисплея и памяти, либо использовать DMA.
Как, учитывая это, набиолее рационально подключить SDRAM к камню?

[aaarrr]

ИМХО, дружить "ногодрыгательную" SDRAM и FSMC - не лучшая идея, т.к. от последнего толку не будет совсем в такой конфигурации.
То есть жизненные варианты такие:
1. Полностью программное управление. Можно использовать практически любой процессор, но 100% загрузка обеспечена. На мой взгляд, вариант интересен только в академических целях.
2. Процессор с контроллером SDRAM и DMA. Данными занимается DMA, ядро практически свободно. Если DMA поддерживает цепочки дескрипторов, то можно освободить процессор полностью.
3. Процессор с контроллером статической памяти. То же, что и п.2, но придется ставить (P)SRAM. Дороже и в большинстве случаев медленнее.

Контроллер DMA, умеющий собирать данные с порта GPIO - большая экзотика, хотя иногда и такое бывает.

[011119xx]

-=Женек=- какие функции хотите возложить на SDRAM?

И еще. Тут вот говорилось, что FSMC с диспом работает быстрее программного управления. Но хотелось бы чтобы кто нибудь привел конкретные цифры. Для дисплея 320х240 в режиме 16-бит на цвет с контроллером STM32F103. 1. Время заполнения диспа одним цветом, 2. Время вывода картинки во весь экран из например sFlash типа М25, или в крайнем случае из Flash самого STM32F103, 3. Время вывода картинки из карты памяти в формате BMP.

[-=Женек=-]

1. Полностью программное управление. Можно использовать практически любой процессор, но 100% загрузка обеспечена.

Для моей задачи загрузка не проблема. Мне надо чтобы пользователь тыкал по красивым кнопочкам, а конечный результат один - включить/выключить. Есть правда функция передачи большого потока информации по радио, но в этот момент все функции устройства будут недоступны, на экране будет ProgressBar.

-=Женек=- какие функции хотите возложить на SDRAM?

3 функции:
1. в ней будет рисоваться кадр, который по окончанию каждой процедуры рисования, ориентируясь на сигнал TE от дисплея, будет отправляться в память дисплея.
2. Когда на экране рисуется окошко, фон нужно сохранять. Для этого нужна память.
3. Я еще не знаю, с какой скоростью у меня будут грузиться картинки из NANDFlash, но если это будет медленно, мне проще загрузить их в память сразу.

Кроме того, аппетит приходит во время еды - если я захочу какие-нибудь движущиеся объекты на экране - для этого нужен будет двойной буфер. У меня был недавно проектик на дисплее 800х480 с контроллером TFT-компаньон - там было нечто вроде рабочего стола с 8 крупными иконками. Так вот при полном перерисовывании рабочего стола возникал неприятный видеоэффект. Может быть конечно он был связан с тем, что отсутствовалв синхронизация с "лучом", но использование двойного буфера при перерисовывании стола спасло.

Если использовать SRAM - за одну и ту же цену что и SDRAM у меня хватит памяти на 1.5 видеостраниц.
Может кто из корифеев подскажет - с какой скоростью можно грузить данные из 8-битной параллельной NANDFlash с помощью STM32F103 ? Ногодрыгом и FSMC.
А то может мне и не нужна внешняя память, может там скорость загрузки всего экрана будет меньше 16 мсек.

[011119xx]

А где будут храниться картинки изначально, то есть откуда будете их грузить в SDRAM?

[-=Женек=-]

Из NANDFlash.

[Qwertty]

Как же любит российский человек разбрасывать грабли и потом по ним ходить...
Вот почему не выбрать LPC1787FBD208? Из за доставки в 200р? Так это можно один раз потратить - заказать сразу десяток, ведь примерно столько девайсов планируется. Ну станет контроллер дороже на 20р - неужели это так критично? Зато все радости типа SDRAM и контроллера TFT уже в наличии будут. И это даже работать будет в отличии от попыток сэкономить и пытаться ногодрыгом чего то быстро извлечь из SDRAM. Кроилово ведет к попадалову(С).
ЗЫ. Страшно представить что с платой будет. Тут ведь утюгом не особо получится - питч у процессоров 0.5мм, ног много. А нормальное производство ПП не бесплатное. Там еще, не поверите, только за подготовку ~50$ сдерут...

[011119xx]

Из NANDFlash.

А что мешает выводить сразу из NANDFlash в дисплей?

[zheka]

А что мешает выводить сразу из NANDFlash в дисплей?

Уже писал - низкая скорость.

Qwertty

контроллера TFT

В очередной раз спрашиваю зачем лысому расческа? Зачем контроллер ТФТ дисплею с 8080 интерфейсом.

Тут ведь утюгом не особо получится - питч у процессоров 0.5мм, ног много.

Не поверите, фоторезистом платы делаю. НА качество не жалуюсь. Камень преткновения только металлизация. Это для макетки. А на итоговое устройство закажу, не поскуплюсь.

Там еще, не поверите, только за подготовку ~50$ сдерут...

Не поверите, всего один раз берут. ПРи повторном заказе за подготовку не платится.

питч у процессоров 0.5мм, ног много.

Я в 65 ноги пытался уложиться, а вы вмне 208 ногого монстра. ДА еще небось BGA.

LPC1787FBD208? Из за доставки в 200р? Так это можно один раз потратить - заказать сразу десяток, ведь примерно столько девайсов планируется. Ну станет контроллер дороже на 20р - неужели это так критично?

от 600 до 1050 рублей за штуку? Супротив 200 рублей за STM?
800 рублей*10 изделий = 8000 рублей?
Спасибо, я за 8 000 рублей лучше имеющуюся для LPC ногодрыгательную библиотеку под STM переделаю за час, чем буду платить за лень по 800 рублей с изделия.





Сообщение отредактировал zheka - Dec 8 2011, 03:55

[011119xx]

Уже писал - низкая скорость.

Я правильно понял, что низкая скорость NANDFlash? Тогда видимо при включении вы собираетесь все картинки загрузить из NANDFlash в SDRAM?

[Dron_Gus]

Вы портом о результатах расскажите. Интересно. Может я зря, позарившись на 32 Мб SDRAM, отладку на LPC1788 купил...