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

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


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

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

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

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

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

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

У меня 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 к камню?