Если у вас есть свое промежуточное ПО взамен тому что есть у MQX, то конечно вы можете все сделать без RTOS.
Но у меня половина прерываний в драйверах используют объекты событий.
Даже не знаю чем вы их сможете заменить без RTOS. Циклами ожидания?

у меня был один суперцикл с флагами от прерываний + поллинг + state machine. не идеально но хватало. хотя там не было драйвера 3-х фазного двигателя со всей его алгоритмикой и наворотами.

Контроллер двигателя с эзернетом обязательно надо строить на двух микроконтроллерах- один отвечает за интерфейс, а второй- за собственно управление мотором. Эзернет может отличаться непредсказуемым флудом пакетов, который заторомозит любую RTOS до невменяемости. У нас такое подгоревший свитч устроил, который изобразил логическую петлю внутри себя.

И кто вас этому обязывает?


Затормозить могут только кривые руки программиста. Какая бы ни была RTOS, но драйвер MAC-уровня Ethernet пишет всё-таки программист. Если у него есть голова на плечах, то никакой флуд не страшен.

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



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

У меня вообще задача обслуживания стека Ethernet-а имеет самый низший приоритет. И не может затормозить никого.
А приём/передача пакетов Ethernet выполняются по DMA.

PS: Тут как обычно - тема про плохого танцора которому что-то мешает....


А зачем его делать? Ну потеряются эти пакеты, не получит их программа и что?
Это же ситуация нештатной работы Ethernet - связь по Ethernet возможно будет со сбоями, но остальным задачам поплохеть от этого не должно.

Ну у нас же управление движением, по сети идут не только пакеты задания скорости, но и пакеты положения с оптических линеек ( обычно это отдельное устройство со своим адресом).
Потеря пакетов в случае если петля ос по положению заведена через интерфейс чревата непрятностями. А если еще и рассинхронизация осей произойдет.
А прерывания от ДМА по окончанию приема пакета могут перегрузить например прерывания управлени ШИМ BLDC мотора совсем уж с грустными последствиями
А флуд может произойти из за банальности- портальный станок, витая пара идет на подвижную часть шпинделя, постоянно перегибается, протерлась изоляция ( именно витой пары, почему то они это любят). Появляется мерцающий контакт, свитч на станке получает кучу битых пакетов, начинается флуд. Это реальный пример, с весьма печальными финасовыми последствиями, хотя эзернет и был дублированный.
После этого интерфейс подвижной части поменяли на световоды.
Ну и от длительности сервоцикла зависит, мне например требовалось около 2 мсек в вышеописанном примере. Это надо было и датчики позиций осей опросить, и задание раскидать по сервоприводам, и со шпинделя скорость и позицию считать.

Ну это у вас. Непонятно только - зачем вы тогда так сделали?
У нас, например, по Ethernet осуществляется только конфигурирование. Да в будущем будет осуществляться мониторинг возможно.
А задание скорости, передача положения угла ротора и др. критичные по времени операции - по специально для этого выделенным интерфейсам (даже не по общему CAN-у).


Не могут в принципе. Прерывания по завершению DMA генерятся когда принят очередной пакет DMA. Который в свою очередь может быть принят только если есть свободное место в очереди DMA-пакетов. А это свободное место появляется только в случае обработки и удаления из очереди одного из пакетов низкоприоритетной задачей TCP-стека.
Более того - после обработки очередного RX-пакета, прерывание о завершении RX-DMA следующего пакета может генериться только одно, а на следующие пакеты прерывания генериться не будут, до момента удаления из очереди RX-DMA-пакетов хотя-бы одного пакета задачей TCP-стека.
Т.е. - всё завязано на низкоприоритетную задачу TCP-стека и всё что выше её по приоритету будет работать независимо от её загрузки.
Да и мест пакетов в очереди RX-DMA немного - у меня всего-то их 5 в цепочке.
Если свободного места в очереди RX-DMA пакетов нет, то очередной пакет будет потерян. И выставится флажок о его потере в соотв. регистре контроллера Ethernet.


В текущей задаче у нас считывание и вычисление позиции ротора занимает ~340 тактов CPU. Это вместе с фильтрацией, коррекцией нелинейности, вычислением скоростей и т.п.
С ресольвера или синус-косинусных датчиков. Это на частоте >100 МГц сущие копейки...
Вычисляем её каждый период ШИМ 10кГц.

или стек переписать

Это не мы, это готовый общепромышленный ethercat.
Если для критической информации есть отдельный CAN то конечно мои замечания теряют смысл.



Интерсный вариант. Хотя возможно и чреват рассинхронизацией, т.к доступен наиболее старый пакет. Мы наоборот старались сохранить самый последний пакет из валидных.
Вот только что с броадкастами делать? Вообще их не обрабатывать? Флуд по ним самый убийственный.

Ну это же не петля положения, а петля скорости. А ШИМ это вообще петля тока/момента, самая быстрая.
Кстати, в случае ресолверов, что там с приоритетом прерываний АЦП? Ресолверы ведь синус-косинусом запитаны? Или два канала в квадратурах на прием? А потом обрабатывать тригонометрию. за 340 тактов никак не управится.

Что значит старый или не старый пакет? Естественно DMA-пакеты обрабатываются стеком в порядке их прихода. Если в очереди их сразу несколько, то естественно первым будет обработан самый старый в очереди. А как иначе TCP-стек ещё может работать?
И в чём проблема броадкастов? Они принимаются в ту же самую очередь DMA-блоков. И обрабатываются тем же самым стеком. Если там нет места - пропуск.


да.


Управится. Вот именно в эти 340 тактов и укладывается вычисление арктангенса угла по полученным синусу и косинусу. И прочие вычисления.
Прерывания АЦП синхронизированы с периодом ШИМ.
Арктангенс - по таблице.
Все вычисления - в фиксированной точке.

А Ethernet flow control не судьба была сделать?
По мне так наиболее логичный путь для тех кто не на EtherCat-е.

А что - это разве спасёт от флуда, о котором говорит khach?
А при штатной работе и так всё успевает с любым наполнением web-сервера. А может даже flow-control уже включён, не помню уже тонкостей.

khach Вот объясните мне, дураку, что за флуд может быть в отдельно выделенной сети для управления? Или вы что, эти контроллеры в инет выставили?? Ну тогда это просто прекрасно - тихий ужас такое настраивать и админить. На счет подгорелый свичей - так позаботьтесь, чтоб в сети промавтоматики и оборудование было соответствующее...

Сообщение отредактировал mantech - Oct 30 2017, 14:31

5 страниц, задача не озвучена.
Управление мотором:
- алгоритм - как мотор должен работать?
- диапазон рабочих скоростей?
- точность позиционирования в движении?
- точность позиционирования при остановке?
- частота импульсов датчика?
- время реверса?
- целевая цена?
... и еще куча вопросов

Зато разговор о веб-сервере