Ну а 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?

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

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


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

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




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

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

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

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

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

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

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

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

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

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

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

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

я выбрал 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 так разбросаны по ногам контроллера?

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

aaarrr


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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Из NANDFlash.

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

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

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

Qwertty

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


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



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


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


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

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

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