Cкpипaчпророк (24.02.2025 20:26, просмотров: 82) ответил LightElf на Спасибо за идейки и рекомендации. Похоже, все-таки, придется кусок
процессинга уносить в отдельное прерывание и перекраивать всю
работу :-(... но не любой ценой.
-
- По здравому размышлению - требуется задержка менее миллисекунды.
Что, в общем, не оставляет вариантов, кроме как разгребать IP
пакеты в прерывании. - LightElf(24.02.2025 20:28)
- Да. Это самый прямой путь. А значит самый короткий. Но миллисекунда
это довольно много, какая у вас тактовая? - Cкpипaч(24.02.2025 20:54)
- Прежде чем так инвазивно влезать, решил пока попробовать измерять
время, прошедшее от начала текущей итерации и если его уже много
набежало - выходить в начало цикла. Ну и еще несколько мелких
оптимизаций, типа: в итерации где была обработка принятого пакета -
не вызывать внутренние операции стека (ретрансмиты, arp и тыды). - _LightElf(26.02.2025 01:41,
) - Надо обработать пакет в прерывании за время межпакетного интервала
10 Мбит ethernet, переслать посредством DMA в буфер, чтобы ничего
не терять. Cortex M0, 32 МГц. Посмотрел я на это дело, почесал репу
и как то интерес к CH579 угас слегка ;) Чип безусловно классный и
китайский стек вроде справляется, но с добавлением еще чего-нить
ресурсоемкого уже начнутся шаманские танцы с бубном... - Гyдвин(24.02.2025 21:51)
- С обычной работой по сети чипуля справляется норм, тут
специфическая задача вылезла - надо принять пакет, разобрать его,
сформировать другой пакет и его отправить. Критичный параметр -
стабильность задержки между приемом и отправкой. При первичной
отладке на столе вполне укладывалось, но в тесте на реальном железе
оказалось все не так весело. - _LightElf(24.02.2025 23:13, )
- У меня подобное живёт на таймерах с наивысшим приоритетом. Аппаратный приём пакета с прерыванием высшего приоритета берёт текущее время из таймера. Затем планировщик рассчитывает время ответа так, чтобы оно было стабильным и чтобы данные были готовы к моменту отправки. Затем, по прерыванию таймера, инициируется отправка. И всё аппаратное, что связано с реальным временем и его точностью - имеет наивысший приоритет. Остальная обработка - поменьше, но всё равно выше, чем Nikolay_Po(11 знак., 24.02.2025 23:23)
- С обычной работой по сети чипуля справляется норм, тут
специфическая задача вылезла - надо принять пакет, разобрать его,
сформировать другой пакет и его отправить. Критичный параметр -
стабильность задержки между приемом и отправкой. При первичной
отладке на столе вполне укладывалось, но в тесте на реальном железе
оказалось все не так весело. - _LightElf(24.02.2025 23:13,
- Прежде чем так инвазивно влезать, решил пока попробовать измерять
время, прошедшее от начала текущей итерации и если его уже много
набежало - выходить в начало цикла. Ну и еще несколько мелких
оптимизаций, типа: в итерации где была обработка принятого пакета -
не вызывать внутренние операции стека (ретрансмиты, arp и тыды). - _LightElf(26.02.2025 01:41,
- Да. Это самый прямой путь. А значит самый короткий. Но миллисекунда
это довольно много, какая у вас тактовая? - Cкpипaч(24.02.2025 20:54)
- По здравому размышлению - требуется задержка менее миллисекунды.
Что, в общем, не оставляет вариантов, кроме как разгребать IP
пакеты в прерывании. - LightElf(24.02.2025 20:28)