-
- РЕШЕНО! спасибо il-2 за наводку! размещение обоих половин буффера ( circular &
double_buffer_mode_enable & burst_mode_enable ) dma в d2_sram1 приводило к тому что dma и cpu встречались на шине доступа к d2_sram1 - dma пишет в одину половинку, cpu копирует в d1_axi_sram вторую. тут же и eth_dma пытается влезть. решение есть -
разместить половинки отдельно в d2_sram1 и d2_sram2 имеющие отдельные шины доступа! буффер eth_dma klen(250 знак., 08.05.2022 22:26, картинка)
- Есть и более традиционные способы замучить ребёнка. Сольфеджио какое-нибудь... - SciFi(08.05.2022 22:29)
- Абсолютно ничего странного. 25Мгц - это сильно высокая частота
запросов. См. AN4031, 2.1.3. BusMatrix arbitration and DMA transfer
delays worst case - там очень впечатляющие задержки - у CPU до
14AHB при использовании LDM/STM (можно попробовать с опцией
компиляции "Split load/store multiple registers", чтобы избежать
этих инструкций). Арбитраж мастеров шины (CPU, DMA, USB, ETH) -
Round-robin, т.е. при появлении запросов от еще одного мастера шины
задержки для остальных тоже il-2(14 знак., 08.05.2022 15:24)
- да... подзабыл я эту доку.... интересненько... появились иде как этих баранов ( cpu и dma ) развести на разные мостики ( куски озу )..... щас мы поглядим... из веселых картинок следует что при обращении двух мастеров к шинной матрице в адрес одного таргета нужно чтоб частота запросов была не менее в 8 раз меньше чем частота клока шины и матрицы, если три сразу как у меня - cpu & dma & eth_dma - то то наверно в 1,5-3 раза меньше. у меня же как раз и не хватает - AHB klen(259 знак., 08.05.2022 16:04, картинка)
- Рассуждения в слух. Может что то не так в процедуре прерывания от
eth? Может что то делает с контроллером дма? - framer(08.05.2022 14:37)
- в обработчике прерывания еth только чтения причины и отпускание семафора klen(2533 знак., 08.05.2022 15:41)
- Странно конечно. На F4 я одновременно принимал видео с камеры и
отправлял его по сетке. Может настройки FIFO покрутить у DMA
контроллера, чтобы он бОльшими блоками к ОЗУ обращался? Ну и потом,
ETH в режиме store and forward работает надеюсь? - LightElf(08.05.2022 13:40)
- dma работет в burst режиме, 1 пропих в озу на 8 считваний из
переферии, приоритет масимальный, кроме этого стрима больше в dma1
ничего нет. store and forward - это можно по подробнее. код eth
передрат из примеров ST к которому я прикрутил крайнюю версию lwip.
ниже смычки eth <-> lwip не лазил. видно что почти все
100 мбит в обе стороны выжимаются без загрузки проца - значит там
почти все хорошо работает. затраты только на заполнение списка
буферов. - klen(08.05.2022 15:18)
- Я про st-шные примеры не копенгаген, но у ETH есть два режима работы буферов: FIFO и store and forward. В режиме FIFO он тянет данные из ОЗУ кусочками и передает сразу, а в store and forward - вытягивает сначала весь пакет в свой буфер и потом уже оттуда передаёт. Ессно в S&F могут быть длинные бурсты. - LightElf(08.05.2022 18:12)
- dma работет в burst режиме, 1 пропих в озу на 8 считваний из
переферии, приоритет масимальный, кроме этого стрима больше в dma1
ничего нет. store and forward - это можно по подробнее. код eth
передрат из примеров ST к которому я прикрутил крайнюю версию lwip.
ниже смычки eth <-> lwip не лазил. видно что почти все
100 мбит в обе стороны выжимаются без загрузки проца - значит там
почти все хорошо работает. затраты только на заполнение списка
буферов. - klen(08.05.2022 15:18)
- РЕШЕНО! спасибо il-2 за наводку! размещение обоих половин буффера ( circular &
double_buffer_mode_enable & burst_mode_enable ) dma в d2_sram1 приводило к тому что dma и cpu встречались на шине доступа к d2_sram1 - dma пишет в одину половинку, cpu копирует в d1_axi_sram вторую. тут же и eth_dma пытается влезть. решение есть -
разместить половинки отдельно в d2_sram1 и d2_sram2 имеющие отдельные шины доступа! буффер eth_dma klen(250 знак., 08.05.2022 22:26, картинка)