[AlexandrY 3]

я понял. нет, я хотел отказаться вообще от операционки. у меня CAN, USB HS, Bluetooth, Log, SD и еще куча всего бежали без операционки.

Если у вас есть свое промежуточное ПО взамен тому что есть у MQX, то конечно вы можете все сделать без RTOS.

Но у меня половина прерываний в драйверах используют объекты событий.

Даже не знаю чем вы их сможете заменить без RTOS. Циклами ожидания?

[jenya7 0]

Если у вас есть свое промежуточное ПО взамен тому что есть у MQX, то конечно вы можете все сделать без RTOS.

Но у меня половина прерываний в драйверах используют объекты событий.

Даже не знаю чем вы их сможете заменить без RTOS. Циклами ожидания?

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

[khach 33]

can неплохой интерфейс для, но ethernet явно не хуже, не вижу никаких причин использовать can и не использовать ethernet

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

 

 

[jcxz 184]

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

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

 

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

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

[mantech 35]

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

 

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

 

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

 

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

[jcxz 184]

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

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

А приём/передача пакетов Ethernet выполняются по DMA.

 

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

 

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

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

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

[khach 33]

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

 

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

Ну у нас же управление движением, по сети идут не только пакеты задания скорости, но и пакеты положения с оптических линеек ( обычно это отдельное устройство со своим адресом).

Потеря пакетов в случае если петля ос по положению заведена через интерфейс чревата непрятностями. А если еще и рассинхронизация осей произойдет.

А прерывания от ДМА по окончанию приема пакета могут перегрузить например прерывания управлени ШИМ BLDC мотора совсем уж с грустными последствиями

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

После этого интерфейс подвижной части поменяли на световоды.

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

[jcxz 184]

Ну у нас же управление движением, по сети идут не только пакеты задания скорости, но и пакеты положения с оптических линеек ( обычно это отдельное устройство со своим адресом).

Ну это у вас. Непонятно только - зачем вы тогда так сделали?

У нас, например, по Ethernet осуществляется только конфигурирование. Да в будущем будет осуществляться мониторинг возможно.

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

 

А прерывания от ДМА по окончанию приема пакета могут перегрузить например прерывания управлени ШИМ BLDC мотора совсем уж с грустными последствиями

Не могут в принципе. Прерывания по завершению DMA генерятся когда принят очередной пакет DMA. Который в свою очередь может быть принят только если есть свободное место в очереди DMA-пакетов. А это свободное место появляется только в случае обработки и удаления из очереди одного из пакетов низкоприоритетной задачей TCP-стека.

Более того - после обработки очередного RX-пакета, прерывание о завершении RX-DMA следующего пакета может генериться только одно, а на следующие пакеты прерывания генериться не будут, до момента удаления из очереди RX-DMA-пакетов хотя-бы одного пакета задачей TCP-стека.

Т.е. - всё завязано на низкоприоритетную задачу TCP-стека и всё что выше её по приоритету будет работать независимо от её загрузки.

Да и мест пакетов в очереди RX-DMA немного - у меня всего-то их 5 в цепочке.

Если свободного места в очереди RX-DMA пакетов нет, то очередной пакет будет потерян. И выставится флажок о его потере в соотв. регистре контроллера Ethernet.

 

и со шпинделя скорость и позицию считать.

В текущей задаче у нас считывание и вычисление позиции ротора занимает ~340 тактов CPU. Это вместе с фильтрацией, коррекцией нелинейности, вычислением скоростей и т.п.

С ресольвера или синус-косинусных датчиков. Это на частоте >100 МГц сущие копейки...

Вычисляем её каждый период ШИМ 10кГц.

[VCucumber 0]

Контроллер двигателя с эзернетом обязательно надо строить на двух микроконтроллерах

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

 

[khach 33]

Ну это у вас. Непонятно только - зачем вы тогда так сделали?

У нас, например, по Ethernet осуществляется только конфигурирование. Да в будущем будет осуществляться мониторинг возможно.

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

Это не мы, это готовый общепромышленный ethercat.

Если для критической информации есть отдельный CAN то конечно мои замечания теряют смысл.

 

 

Если свободного места в очереди RX-DMA пакетов нет, то очередной пакет будет потерян. И выставится флажок о его потере в соотв. регистре контроллера Ethernet.

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

Вот только что с броадкастами делать? Вообще их не обрабатывать? Флуд по ним самый убийственный.

В текущей задаче у нас считывание и вычисление позиции ротора занимает ~340 тактов CPU. Это вместе с фильтрацией, коррекцией нелинейности и т.п.

С ресольвера или синус-косинусных датчиков. Это на частоте >100 МГц сущие копейки...

Вычисляем её каждый период ШИМ 10кГц.

Ну это же не петля положения, а петля скорости. А ШИМ это вообще петля тока/момента, самая быстрая.

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

 

 

 

 

[jcxz 184]

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

Вот только что с броадкастами делать? Вообще их не обрабатывать? Флуд по ним самый убийственный.

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

И в чём проблема броадкастов? Они принимаются в ту же самую очередь DMA-блоков. И обрабатываются тем же самым стеком. Если там нет места - пропуск.

 

Или два канала в квадратурах на прием?

да.

 

А потом обрабатывать тригонометрию. за 340 тактов никак не управится.

Управится. Вот именно в эти 340 тактов и укладывается вычисление арктангенса угла по полученным синусу и косинусу. И прочие вычисления.

Прерывания АЦП синхронизированы с периодом ШИМ.

Арктангенс - по таблице.

Все вычисления - в фиксированной точке.

[AlexandrY 3]

Прерывания по завершению DMA генерятся когда принят очередной пакет DMA. Который в свою очередь может быть принят только если есть свободное место в очереди DMA-пакетов.

А Ethernet flow control не судьба была сделать?

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

 

[jcxz 184]

А Ethernet flow control не судьба была сделать?

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

А что - это разве спасёт от флуда, о котором говорит khach?

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

[mantech 35]

А что - это разве спасёт от флуда, о котором говорит khach?

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

 

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

Изменено 30 октября, 2017 пользователем mantech

[DogPawlowa 0]

5 страниц, задача не озвучена.

Управление мотором:

- алгоритм - как мотор должен работать?

- диапазон рабочих скоростей?

- точность позиционирования в движении?

- точность позиционирования при остановке?

- частота импульсов датчика?

- время реверса?

- целевая цена?

... и еще куча вопросов

 

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