IBAH (31.08.2026 18:51, просмотров: 93) ответил SciFi на Зачем?-
- Библиотечные memcpy не по байтику копируют, там разогнано. Ну и
опять же, зачем? Куда-то опаздываем? - SciFi(31.08.2026 19:07)
- Делал наложение текста идущего с uart, на картинку с видеокамеры на f103. Модуляция dma из битового массива в ОЗУ в spi по прерыванию телевизионной строки, проц параллельно конвертировал полученное с uart в этот битовый массив и ещё разными делами успевал. Без dma никак. В промэлектронике был пример подключения, матрицы LCD там тоже хитрое каскадное включение счётчиков с dma для формирования сигналов управления матрицей. - jlm(02.09.2026 09:33)
- Мы не опаздываем, мы НЕ УСПЕВАЕМ... - klen(31.08.2026 22:17)
- Быстрее будет только на заметных объемах данных, т.к. ДМА надо
настроить, это время. А еще ДМА может работать на частоте в разы
ниже процессорной, тогда выигрыша по скорости может не быть. AlexBi(104 знак., 31.08.2026 19:06)
- А в этих ваших интернетах пионеры пишуть, что через ДМА получается
меднение чем через memcpy() - IBAH(31.08.2026 19:16)
- ДМА для пересылки надо несколько тактов. Например для STM32F103 пишут что надо 5 тактов, тактируется ДМА от АНВ (будем считать оно тактируется частотой ядра). Для пересылки память память ядром могут использоваться команды LDM/STM с ними на пересылку одного слова может уходить менее 3 тактов. Итого получается что ядром быстрее. Но это вопрос к реализации ДМА в STM32F103 - AlexBi(31.08.2026 19:45)
- А в этих ваших интернетах пионеры пишуть, что через ДМА получается
меднение чем через memcpy() - IBAH(31.08.2026 19:16)
- Могу ошибаться, но разве DMA не через раз (условно) шевелится,
только когда шина высвободилась?... POV(189 знак., 31.08.2026 18:55)
- Обычно шины ОЗУ и ПЗУ разные, шина ОЗУ часто свободна - AlexBi(31.08.2026 19:09)
- Насколько я понимаю проц имеет самый высокий приоритет на шине, и
если его усыпить, то DMA все по быстренькому перекидает, и гораздо
быстрее чем проц ручками. - IBAH(31.08.2026 19:09)
- Всё уже было. Вот тут с картинками: SciFi(2 знак., 31.08.2026 19:14 - 19:25, ссылка, картинка)
- Странно: почему у newlib-nano такое сильное отставание в memcpy()? Eddy_Em(107 знак., 01.09.2026 09:03)
- Там как раз по байтику. Зато минимум кода. - SciFi(01.09.2026 09:16)
- Ты в листинг загляни. Бывает, оно оптимизирует и всё, что можно,
копирует полными словами. А бывает - по байтам. Может от версии
библиотеки зависеть. YMMV. - Nikolay_Po(01.09.2026 09:16)
- Еще ведь от модели МК зависит: на всяких "нулевках", если копировать невыровненными словами, будет хардфолт. Т.е. недостающие до слова из головы и хвоста надо побайтно, остальное - по словам. Eddy_Em(546 знак., 01.09.2026 10:27)
- По умному эти функции должны инлайниться самим компилятором (его
оптимизатором), и не зависеть от библиотеки. Такие компиляторы
есть, но не все. - AlexBi(01.09.2026 09:51)
- memcpy не такая уж простая функция. я бы сказал, что инлайнятся
реализации в зависимости от условий. самое жирное в плане
реализации - копирование перекрывающихся областей - когда
(src+size) > dst. потому везде пихать одинаковое - как-то
нерационально. и вместо поиска оптимальной реализации в рантайме и
соответствующего оверхеда это дело по возможности инлайнится именно
компилятором. - Vit(01.09.2026 12:25)
- У memcpy в мане написано, что перекрывающиеся области - UB,
пользуйтесь, мол, более правильной memmove для таких случаев. - Eddy_Em(01.09.2026 13:25)
- об memmove первый раз слышу. наверно потому и придумали. - Vit(01.09.2026 19:17)
- В смысле "первый раз"? Неужто ни разу ман на memcpy не читал? Вот,
цитирую: Eddy_Em(162 знак., 02.09.2026 09:05)
- Во-первых, маны это маны, а не это. (сильно недолюбливаю формат). И
то, что проблема организационная, понятно даже из легенды о
впихивании нахненужной memmove. - Vit(02.09.2026 09:53)
- Отличный формат. Понятно, что в латехе было бы лучше - pdf какую сгенерить, вот только без иксов pdf смотреть не кошерно, так что формат манов - самый что ни на есть правильный. Eddy_Em(130 знак., 02.09.2026 10:16)
- Пророки Керниган и Ричи про это не говорили, значит ересь :-) - SciFi(02.09.2026 09:06)
- +1 - Vit(02.09.2026 09:53)
- Во-первых, маны это маны, а не это. (сильно недолюбливаю формат). И
то, что проблема организационная, понятно даже из легенды о
впихивании нахненужной memmove. - Vit(02.09.2026 09:53)
- В смысле "первый раз"? Неужто ни разу ман на memcpy не читал? Вот,
цитирую: Eddy_Em(162 знак., 02.09.2026 09:05)
- об memmove первый раз слышу. наверно потому и придумали. - Vit(01.09.2026 19:17)
- У memcpy в мане написано, что перекрывающиеся области - UB,
пользуйтесь, мол, более правильной memmove для таких случаев. - Eddy_Em(01.09.2026 13:25)
- Есть плюсы и минусы у этого подхода. Обобщать "умно" или "неумно"
здесь едва ли имеет смысл. - SciFi(01.09.2026 09:54)
- Можете сказать какие есть минусы? - AlexBi(01.09.2026 09:56)
- memcpy не такая уж простая функция. я бы сказал, что инлайнятся
реализации в зависимости от условий. самое жирное в плане
реализации - копирование перекрывающихся областей - когда
(src+size) > dst. потому везде пихать одинаковое - как-то
нерационально. и вместо поиска оптимальной реализации в рантайме и
соответствующего оверхеда это дело по возможности инлайнится именно
компилятором. - Vit(01.09.2026 12:25)
- Что интересно - с отключенным у DMA FIFO получается немного быстрее. - ЫЫyкпy(01.09.2026 07:12)
- негрузиться!!! что там? - IBAH(31.08.2026 19:21)
- Странно: почему у newlib-nano такое сильное отставание в memcpy()? Eddy_Em(107 знак., 01.09.2026 09:03)
- Всё уже было. Вот тут с картинками: SciFi(2 знак., 31.08.2026 19:14 - 19:25, ссылка, картинка)
- Библиотечные memcpy не по байтику копируют, там разогнано. Ну и
опять же, зачем? Куда-то опаздываем? - SciFi(31.08.2026 19:07)
