Изучаем STM32 Cortex M3

[DanilinSA]

Пришлось подбирать время пауз в процедуре обмена как то она сильно не совпало с даташником, что в итоге привело совсем медленной его работе!

Чем смотрел тайминги? Фронты не завалило? Наводок от параллельных линий не ловим?

подключение по параллельной шине должно быть быстрее последовательной

Теоретически верно. Но нужно смотреть применительно к общей загрузке чипа. f105 все-таки не особо производительный чип.

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

А тебе зачем максимально быстрая отрисовка? Видео на экране смотреть? Если у тебя просто цифры меняются на экране, то:
1) быстро сменять цифры - они станут не читаемые.
2) многократно перерисовывать статику - смысла нет.

Мои личные рекомендации по организации отрисовки визуального интерфейса:
1) Двойной буфер рулит! Один гоним по DMA на экран, второй заполняем. И меняем по мере готовности.
2) Обрисовываем по зонам. Делим экран на автономные зоны и отрисовываем только то, что нужно изменить. Т.е. если тебе ряд нужно результат замера изменить - не нужно весь экран перерисовывать.
3) Глянь осцилографом времянки обмена. Возможно косяки обмена. Видел проекты, где поток передавался по байтам с остановкой обмена.

[do-vitas]

Фронты не смотрел просто у уменьшал время до достижения артефактов на экране. Вообще надо было конечно глянуть осликом... я сейчас просто дисплей подключил и мк ничего больше не делал цифры это просто картинки как добьюсь чтобы экран показывал как надо тогда уже и дальше буду двигаться!
По скорости тут не знаю почему так. Физически то порты одни и теже ну допустим D тактуется от одной шини по идее так что по сути нет разницы. Но тут то как люди говорят настраивал их халакуб может тут где косяк... до этого таких проблем не было с 16Х2 и с 8Х2 они просто летали. Вообще есть мыли что тут в самом дисплее может быть собака зарыта....

[ProtAS-13]

подключение по параллельной шине должно быть быстрее последовательной а 8-bit-й режим он и там и там по идее!

Вы путаете 8-bit интерфейс подключения с 8-bit шириной шины данных.
В последовательном режиме необходимо в начале передачи передавать байт синхронизации, и ДВА байта данных с пустыми младшими 4-мя битами. А далее делать задержку на выполнение команды.
Посчитайте: при минимальной tSCYC (Serial clock cycle), равной 400ns, без учета накладных расходов в виде байта синхронизации, передача одного информационного байта = 400ns*16тактов=6.4us.
В параллельном 8-битном режиме передача всех 8-bit данных осуществляется за один такт tC (Enable Cycle Time), равный 1.2us.
Но на таких скоростях дисплей работать не может - в доках указано время выполнения команд: для большинства ~72us (при внутренней частоте дисплея 540 kHz).
Очевидно, что в зависимости от производителя и внутренней частоты это время может варьироваться. И лишь использование Busy Flag (BF) позволяет создать универсальную программу, работающую с дисплеем на близко к максимальной скорости, и не зависящую от вендора дисплея.
Для примера приведу осциллограмму работы дисплея в 8-bit интерфейсе (см. pic1).
Как видно, команды имеют различные времена выполнения: ~32...48us.
Если округлить до 50us, то заполнение всего экрана текстовыми символа: 64символа*50us=3.2ms (~312Hz), а графического экрана 128*64/8=1024байта*50us=51.2ms (~19Hz).
И данные расчетные значения будут справедливы как для параллельного, так и последовательного интерфейсов.

[do-vitas]

ProtAS-13, вы наверно редко имеете с ними дело у них есть и так и так 8бит-й режим просто нет необходимости в передаче старших и младших бит а все передается за раз:

[ProtAS-13]

вы наверно редко имеете с ними дело

Я модель ST7920 для Proteus'а писал - поэтому поверьте, уж с этим дисплеем я разобрался более, чем досконально.

[do-vitas]

ProtAS-13, я тоже когда-то на avr писал свои библиотеки для 16х2 8х2 дело то житейское... тогда должны были понимать что 8 проводов подключишь будет-8бит, 4 - будет 4 бит... ну да не суть... вот я и думаю что когда у тебя 8 проводов "дрыгаются" вместо одного должно было быть быстрее! тут причина может быть в том что внутри дисплея команды с разных интерфейсов обрабатывают разные "ядра". Тогда получается что в 4/8 бит параллельном интерфейсе в этом дисплее нет никакого смысла...

[akegor]

Тогда получается что в 4/8 бит параллельном интерфейсе в этом дисплее нет никакого смысла...

Сравните объем памяти для реализации параллельного и последовательного ногодрыга (софтового).

[ProtAS-13]

Тогда получается что в 4/8 бит параллельном интерфейсе в этом дисплее нет никакого смысла...

Смысл есть ВСЕГДА и во ВСЁМ. Даже там, где он явно не обнаруживается.
Вот только всё всегда упирается в физические ограничения - нельзя влить в 10 литровое ведро 10 тонную цисцерну.
А касательно наличия различных интерфейсов - здесь много смыслов, начиная от количества используемых физических проводников, сложностью программного обеспечения, до унификации устройств отображения и дополнительных "фишечек".
К примеру, тот же ST7920 в последовательном режиме позволяет осуществлять в дисплей только запись. Параллельные режимы позволяют также производить и считывание данных из дисплея. Тем самым, появляется возможность определить не только время готовности дисплея к получению следующей порции данных, что позволяет "отвязаться" от конкретного производителя дисплея, включая и будущие модифицированные ("ускоренные") его версии, но и, в случае необходимости, использовать неиспользуемые ресурсы дисплея - такие как память.
А почему бы и нет - ведь ST7920 имеет двухстраничную организацию, а следовательно, без ущерба для отображаемой информации, можно "извернуться" использовать неиспользуемые 64 байта DDRAM, 1024 байтов GDRAM и 128 байт CGRAM. Да, это будет оооочень медленная память, но для "клопов", имеющих на борту 32 байта SRAM, может иметь не самое последнее значение.

[DanilinSA]

Плюс параллельный интерфейс очень хорошо ложится на FSMC интерфейс. При его наличии.

[do-vitas]

ProtAS-13, вы мыслите широкими категориями! Мы же люди простые! Я пишу отталкиваясь от своих хотелок и возможностей! А о том как космические корабли бороздят просторы вселенной даже не поспоришь!
Теперь о своих "бздених" выходные убил на изучение CMSIS и таки все запустил и на нем! Зацепили меня эти антиХаловцы. Кварц у меня 24Mz и получились настройки не такие как у всех, не типичные, ну как бы со всем разобрался. Теперь по сути на выходе получились 2 проекта на cmsis и LL ну не HAL конечно. И вы знаете а разницы никакой и не где не в размере не в скорости Щас меня конечно закидают тапками лица приближенные к всевышнему но как бы так....