Em::blocks IDE (EmBitz)

[Andrew Martin]

По мне в даташите всё хорошо расписано. Нужно - вычитывай, не нужно - не вычитывай.

На F0 попробуй не вычитать!

прикрутить DMA

Проще, но я до этого ещё не дополз. Времени, знаете ли, в обрез.

[arkhnchul]

ну мы тут еще и про stm8 вдруг вспомнили, у которого во многих моментах периферия с stm32 общая. Там DMA не наблюдается.

[a5021]

Это смотря у какого stm8. Местами там DMA вполне себе наблюдается.

[scorpi_0n]

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

Я действительно там не вижу ничего страшного и укуренного. Все биты расписаны в референсе. Примеры работы таймера в различных режимах есть. И вообще настройка любой периферии is enabled by a combination of the ............. registers.

А не проще для вывода через SPI прикрутить DMA, чем вызывать процедуру однобайтовой посылки множество раз?

DMA не является панацеей по разным причинам. В некоторых случаях задачи без применения DMA выполняются проще быстрее и не отнимают определённых ресурсов. С TFT как раз как мне кажется именно такой случай.

На F0 попробуй не вычитать!

Если SPI работает только на вывод то и смысла вычитывать DR как бы нет. Всё равно приём игнорируется.

[a5021]

В некоторых случаях задачи без применения DMA выполняются проще быстрее и не отнимают определённых ресурсов. С TFT как раз как мне кажется именно такой случай.

Не надоело бредить? Толкать данные в SPI побайтово дольше и более громоздко в записи. Проинициализировать один раз DMA и выгнать данные блоком быстрее, проще и компактнее. Если конкретно у вас сложности с использованием DMA, то это не значит, что сей метод ущербен в принципе. А в части работы с экранами, так вообще DMA может оказаться панацей, т.к. требования по скорости там обычно весьма жесткие. Какие уж оно "отнимает определенные ресурсы", я даже спрашивать вас боюсь.

[scorpi_0n]

Да чушь всё это. Для того чтобы понять что лучше надо сделать с ДМА и без. Посмотреть померять. А так это ни о чём. Если ОЗУ очень много для полного буфера или гнать картинки из SPI flash на ТФТ напрямую тогда да и ДМА оправдано. Если графика или раскодировка то ДМА отнимет только ОЗУ которого у STM32F030 и так немного и канал но скорости не добавит. Для таких задач узким горлышкои будут вычислительные возможности самого МК.
Как пример. Если работа с шрифтами или графикой в одной итерации больше чем 34 такта для SPI 16 бит то канал ДМА уже как козе баян. Тогда проще всего слать данные в DR даже без проверки флагов так как всё будет выдерживаться автоматически. Единственное что понадобится проверить это окончание передачи если дёргать CS.

Последний раз редактировалось scorpi_0n Вт дек 08, 2015 11:56:39, всего редактировалось 1 раз.

[a5021]

Да чушь всё это. Для того чтобы понять что лучше надо сделать с ДМА и без. Посмотреть померять. А так это ни о чём.

Для вас ни о чем. Через DMA быстрее будет всегда. Это аксиома. Не на что смотреть и нечего мерять. А вам надо не фантазировать, а матчасть учить. В противном случае так и будете всегда бред нести с важным видом.

[scorpi_0n]

Через DMA быстрее будет всегда. Это аксиома.

Где это написано? Зависит от задачи. Приведите факты по поводу аксиомы.
Ещё пример если говорим о скорости. Открываем референс раздел SPI. Там есть описание непрерывного режима работы SPI. Смотрим в раздел ДМА. Какой там максимальный расмер счётчика? То есть за один присест даже экран одним цветом не заполнить. Нужна вторая транзакция. Это выключить канал настроить регистры и запустить передачу. А это тоже время. При непрерывном режиме передачи этого делать не надо а следовательно при непрерывной передаче скорость заполнения экрана по любому будет выше. Не верите? Проверьте сами.

[a5021]

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

[scorpi_0n]

Я думал вы что-то не понимаете, но вы не понимаете, похоже, ничего.

Широко задвинуто с размахом. Вот только с ваших слов толку ноль.
Похоже вы и сами ничего не понимаете но своё непонимание цените выше. Так бывает.

В этом случае не вижу для себя смысла продолжать разговор.

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

Очень надеюсь, если вы когда нибудь с этим разберетесь, вам станет стадно за тот бред, что здесь несли.

Для начала потрудитесь осознать с чем мне нужно разобраться. С вашим настойчивым упоминанием слова "бред"?
А за упоминание референса мне не стыдно.

[a5021]

Конечно, чего ж стыдится, если вы даже не в состоянии посчитать затраты процессора на обслуживание SPI при запихивании в регистр передачи данных побайтово. Уж не говорю про то, чтобы сравнить с затратами в виде инициализации пары регистров на блок передачи при использовании DMA. У кого в голове звенящая пустота, тому стыдиться решительно не получится.

[scorpi_0n]

Ваша звенящая пустота конечно звонче. Я даже не спорю.
В первом случае основное время занимают вычисления и от этого никуда не деться. И ДМА тут не при делах. Куда складывать данные уже не важно в буфер или в DR. Пока идёт расчёт следующих данных SPI уже успеет отработать по любому и без ДМА.
Во втором случае был разговор про скорость а не про затраты процессора. Непрерывная передача данных отработает экран быстрее по любому. Нравится вам это или нет.
Читайте внимательнее прежде чем пытаться что-то доказывать.

[a5021]

В первом случае основное время занимают вычисления и от этого никуда не деться. И ДМА тут не при делах.

Какие еще вычисления? Тема про DMA и возникла от того, что у автора идет просто последовательная укладка констант в регистр передачи. Вы о чем тут фантазируете?

Во втором случае был разговор про скорость а не про затраты процессора. Непрерывная передача данных отработает экран быстрее по любому.

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

Чтобы вы наконец затихли со своим безумием, вот демо различных режимов SPI для дисплея на ILI9341:



Технические подробности здесь.

[scorpi_0n]

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

Освободить процессор да. А максимальную скорость это уже вы придумали. Частенько это и не факт.
Ещё пример. ТФТ на одном SPI а SD на другом. Пока вычитываются следующие данные с SD предыдущие передаются на ТФТ. Получаем непрерывный режим на обоих SPI. И на кой здесь ДМА и что он ускорит если работу с FAT никак не обойти?
Другой пример. Тут в другой ветке приводили ссылку на шилд с ТФТ для ардуины на STM32F0xx. Там парраллельная шина. Автор довольно известный пошёл путём разгона МК и оптимизации скорости вывода на АСМе. А почему не ДМА если ДМА всегда быстрее как вы уверяете?
Получается что ваша аксиома про исключительную скорость ДМА вся в дырках. В каких-то случаях с ДМА будет быстрее в каких-то нет.

[a5021]

Ещё пример. ТФТ на одном SPI а SD на другом. Пока вычитываются следующие данные с SD предыдущие передаются на ТФТ. Получаем непрерывный режим на обоих SPI. И на кой здесь ДМА и что он ускорит если работу с FAT никак не обойти?

Бредите? Юлите? Ну-ну. За каким хреном вы в тему скорости вывода на экран тянете еще никаким боком сюда не относящуюся скорость чтения с карточки? По другому доказательства не складываются? И не сложатся. И насчет видео у вас никаких комментариев. Рассказать, почему? Потому, что ваша дивная теория, насчет сверхбыстрого вывода по spi без dma лопнула с оглушительным грохотом. Вывод посредством dma оказался самым быстрым. И хоть вывернитесь на изнанку, вы не в состоянии отменить результаты. Бредни вида "как влияет течение сточных вод на скорость вывода по SPI" оставьте лучше благодарным слушателям, к каковым я уж точно не отношусь.

Другой пример.

На кой мне эти тухлые примеры, где ограничение на скорость вывода накладывают сторонние устройства ? Что демонстрируют доказательства вида "почему автор сделал так, а не так?" У нас этот неназванный "автор" -- эталон единственно-верных технических решений? Да с хрена ли? Один тухляк и дешевое словоблудие вместо доказательств.

[scorpi_0n]

А чо это вас вдруг так оглушительно порвало?

Вывод посредством dma оказался самым быстрым.

Ага. Халва халва халва.
Никто не говорил что ДМА это плохо. Но ваша теория с аксиомой красочно облажалась.

На кой мне эти тухлые примеры, где ограничение на скорость вывода накладывают сторонние устройства ?

Вот это поворот! Спасибо сильно улыбнуло. Сам по себе SPI и даром бы не впёрся как сферический конь в вакууме если бы его не поддерживали сторонние устройства со всеми ограничениями на скорость и прочее. ТФТ флэш SD и прочее и есть сторонние устройства нравится вам это или нет.
Что-то у вас не то в консерватории.

[a5021]

В сухом остатке имеем: я привел пруф, который измеряет чистую скорость вывода на экран, а вы, кроме собственных глаголаний не привели ничего. С тем и оставайтесь.

[scorpi_0n]

Ничего вы не привели и не доказали и даже остаток у вас сухой. И ваш пруф никем не принят за стандарт. Таких пруфов ни о чём в инете пруд пруди.
Могли бы сослаться и на что-то другое. Вот только толку с этого аж никакого.
Всё просто как два байта по SPI.
Я ссылаюсь на референс. Вы ссылаетесь на какие-то там пруфы. Возникает коллизия недоверия. Так как оснований не доверять референсу нет то все ваши пруфы автоматически доверия не вызывают.

У нас этот неназванный "автор" -- эталон единственно-верных технических решений? Да с хрена ли?

Не эталон. И решения может быть не единственно верные. Но вам у него есть чему поучиться.
http://andybrown.me.uk/2015/02/02/awcopper/

[a5021]

Ничего вы не привели и не доказали и даже остаток у вас сухой. И ваш пруф никем не принят за стандарт. Таких пруфов ни о чём в инете пруд пруди.
Могли бы сослаться и на что-то другое. Вот только толку с этого аж никакого.

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