[Arlleex 131]

Только что, Forger сказал:

Это справедливо отчасти если в проекте не используется RTOS и через прерывания и их приоритеты по сути организована ее некая "эмуляция".

Если РТОС есть, то в прерываниях подолгу делать нечего, быстренько проверили флажки прерываний от железа, сложили данные в буфер, просемафорили куда надо и скорее на выход.

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

Нет, любой батарейный проект это весь код в прерываниях...

[Forger 17]

30 minutes ago, Arlleex said:

любой батарейный проект это весь код в прерываниях...

ничего не мешает вводить камень в спячку из фона задач

будить понятно что от прерываний

[amaora 21]

1 hour ago, Forger said:

Это справедливо отчасти если в проекте не используется RTOS и через прерывания и их приоритеты по сути организована ее некая "эмуляция".

А ещё есть "event driven" планировщики вместо классических потоков исполнения. Не помню как точно называется, но здесь на форуме был длинный тред. Тоже неплохой способ организации кода, и возможности C++ там есть куда приложить.

 

1 hour ago, Forger said:

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

Для каких-то "средних" задач наверно. У меня контуры управления 30 кГц, обработка занимает 80% времени. В остатке работает ртос с потоками и другие прерывания, вот там уже можно как в книжках.

Изменено 18 сентября, 2023 пользователем amaora

[tonyk_av 31]

3 hours ago, Forger said:

Если РТОС есть, то в прерываниях подолгу делать нечего

Подолгу- это сколько? О каких цифрах идёт речь? Опять же, в сопоставлении со временем входа. Раз тут люди рассуждают, что 40 тактов- это плохо, а 4- круто, значит, у них есть какие-то цифры в руках, из которых следует вывод о том, что хорошо, и что плохо. Если говорят, что нужно 4 такта, а не 40, значит, должны быть цифры, подтверждающие такую необходимость.

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

[EdgeAligned 53]

Ну я же, кажется, достаточно объяснил в двух словах. В 10 раз - это ощутимая разница. В 10 раз медленнее в одном месте, в 10 раз медленнее в другом, в 10 в третьем - оно помаленьку-потихоньку и набегает то того уровня, когда производительности даже 480 МГц будет не хватать. С другой стороны, допустим, производительности на максималках худо-бедно хватает. Но остается фактор энергосбережения и тепловыделения для устройств с аккум.питанием или с высокой темпер.нагрузкой. Тоже фактор! Те же 480 МГц подогревают чип и воздух вокруг уже ощутимо, да и амперы хавают как не в себя. 
Не думал, что такие простые истины нужно дважды объяснять. Лень программиста - хуже конечный результат в устройстве, с этим не поспоришь.

Другой пример: некоторые очень сильно ругают кубовский HAL за его расточительность на ресурсы и медленность работы. А вы как считаете - может пофик на медленность, зато какое удобство ведь? И Cube HAL нынче весьма популярен благодаря маркетингу. Это тоже мода - мода на Cube HAL.

[Forger 17]

36 minutes ago, tonyk_av said:

Подолгу- это сколько?

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

Т.е. сильно нарушается сама задумка кода в задачах с разными требованиями к их приоритету.

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

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

А если все уже запущено и лень переписывать толстые обработчики, то эта лень в итоге рискует погубить весь проект. 

Сужу исключительно по своему личному опыту.

 

42 minutes ago, tonyk_av said:

Может, и с прерываниями так же?

странное сравнение, мой код я пишу прежде всего для себя, т.к. мне же его потом и сопровождать, а себя я люблю, себе подлянок делать не стану )

Если кому то под заказ без сопровождения, то может сделаю как нибудь с длиннющими обработчиками, а там пофиг, пусть другие расхлебывают )) В таком подходе конечно можно сделать вход в прерывания хоть на сотню тактов, не мои проблемы )))

[tonyk_av 31]

21 minutes ago, Forger said:

(если конечно не заморачиваться с вытесняющими друг друга прерываниями и их приоритетами, что вообще лишает смысла наличия в проекте РТОС)

Очень даже заморачиваюсь. И откровенно не понимаю, почему разнесение приоритетов прерываний лишает смысла работу под РТОС. И никакого бардака не наблюдаю. Да и откуда ему взяться? Не понятно. Коллега, может какой-нить примерчик покажешь? ИМХО, ARM не от скуки заморочилась за NVIC, чтобы мы все прерывания тупо разделили на две группы, РТОС и все остальные.

Опять же, я не понимаю, почему разделение прерываний на группы усложняет даже самому автору сопровождение кода. На себе я этого не заметил. Возможно, мало отлаживал чужой код.

Коллега, я просто стремлюсь изучить твой опыт и постараться избежать ошибок в своей работе, а не говорить, что ты чё-то не отдупляешь, нет. Ну не сталкивался я с проблемами, когда используется несколько уровней приоритетов, кроме как размер стэка. Даже если не соглашусь, всё равно с интересом прочитаю ответ.

[Arlleex 131]

USB-стек почти весь крутится в прерываниях - вся машина состояний и обмены - в прерываниях.

Плюс не все МК (я про Cortex-ы в основном щас) имеют много приоритетов в NVIC. Запросто может быть 8 или 4 (меньше не видел).

При весьма частых запросах и низкой тактовой загрузка CPU существенно сожрется лишь на входах/выходах из прерываний.

К чему сжирать производительность, которой иногда итак весьма впритык? Причем: на ровном месте.

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

[Forger 17]

28 minutes ago, tonyk_av said:

Очень даже заморачиваюсь

А мне не приходится это делать. Могу вообще все прерывания сделать с равным приоритетом в одной группе, и все одно проект будет так же работать. Потому по замерам в прерываниях он живет крайне мало времени.

И меня такой прогнозируемый расклад полностью устраивает.

Другое дело проекты без RTOS, там вообще вся жисть в прерываниях. Тут уж что есть то есть. Но там и проекты слишком простые.

2 minutes ago, Arlleex said:

USB-стек почти весь крутится в прерываниях - вся машина состояний и обмены - в прерываниях

а это зависит от стека

например я пользуюсь решением от ARM, библиотека закрытая, но она при запуске для USB сама создает как миминум одну задачу, несколько семафоров и вроде даже мьютекс (или EventFlags), точно не помню. Моя задача лишь определить ей размер стека этой задачи и несколько интерфейсных функций, чтобы связать стек с железом.

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

[Arlleex 131]

7 минут назад, Forger сказал:

а это зависит от стека

Это зависит и от железа, а USB (девайс) построен так, что очень хорошо ложится на событийно-ориентированное взаимодействие с хостом.

Поэтому подавляющее большинство примеров стеков "живут" в прерываниях на 99% своего исходного кода.

В задачи RTOS выносятся всякие диспетчеры сервисных функций, живущих рядом со стеком (или его обслуживающих).

[Forger 17]

24 minutes ago, Arlleex said:

Это зависит и от железа, а USB (девайс) построен так, что очень хорошо ложится на событийно-ориентированное взаимодействие с хостом.

И что мешает разместить ее вне стека? Что мешает в прерываниях оставить лишь быстрые действия с событиями с аппаратными буферами, а наружу в задачи вынести разгребание их содержимого и по сути весь USB стек?

По-моему ничего не мешает. Кмк ARM в своих библиотеках MDK-Middleware пошли именно по такому пути, иначе какой смысл создавать для стека отдельную задачу, точно также для работы с файловой системой они создали еще одну задачу, не спрашивая разрешения

Но я этот момент обязательно изучу, стало любопытно )

24 minutes ago, Arlleex said:

В задачи RTOS выносятся всякие диспетчеры сервисных функций, живущих рядом со стеком (или его обслуживающих).

Откуда такое необычное мнение? 

Я вот сторонник нафик убрать из  прерываний все что можно по максимуму, как советуют гуру в своих книгах. Мне эта мысль кажется логичной.

25 minutes ago, Arlleex said:

Поэтому подавляющее большинство примеров стеков "живут" в прерываниях на 99% своего исходного кода.

Это печально

[Arlleex 131]

1 час назад, Forger сказал:

И что мешает разместить ее вне стека? Что мешает в прерываниях оставить лишь быстрые действия с событиями с аппаратными буферами, а наружу в задачи вынести разгребание их содержимого и по сути весь USB стек?

Все действия в USB-стеке событийно-ориентированные. Многие (большинство) из них требуют в качестве реакции не просто перекладывания данных из одного места в другое, а быстрого управления флажками в USB-периферии. Устанавливать в прерывании некий флажок-семафор ОС, который потом обрабатывать в задаче - это только усложнять обработку. Я не знаю, что там в закрытых стеках ARM, посмотреть же нет возможности.

Более того, некоторые флажки периферии, которые генерят прерывания, можно сбросить только неким побочным действием, и это побочное действие может быть результатом конкретного состояния соответствующего драйвера. Т.е. просто так сбросить флажок в периферии и выдать семафор ОС, чтобы "дообработать" реакцию на это прерывание не получится, т.к. сброс флага вполне может переводить периферию в какое-то другое состояние, которое ломает логику стека. Запросто.
 

Цитата

Откуда такое необычное мнение?

Это я не про вообще все USB-стеки. Это я про, например, те, которые мне доводилось видеть в качестве работающих реализаций.

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

RTOS или просто кусочек в суперцикле обрабатывает, например, различные таймауты, логику переключения классов USB, и т.д.

P.S. Проблема то не в том, что много кода в прерываниях. Это решается приоритетами прерываний, в конце концов. Проблема в потенциально длинных накладных расходах на вход/выход из них: речь о выше заявленных условных 10-кратных потерях. Одно дело 10 тактов, другое - 100, зато код красивый и понятный. И когда такие прерывания вызываются весьма редко, бог бы с ними. Но когда на них "живет" какой-то бодрый процесс, а трассировщик показывает 20% потерь производительности CPU лишь на холостых тактах входа/выхода прерываний - это весьма огорчает.

[Forger 17]

10 hours ago, Arlleex said:

Проблема в потенциально длинных накладных расходах на вход/выход из них: речь о выше заявленных условных 10-кратных потерях.

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

 

10 hours ago, Arlleex said:

это весьма огорчает.

Это еще не самое страшное, это можно пережить )) Куда хуже когда из-за "этого" весь проект летит "коту по хвост", а сроки поджимают 

[Forger 17]

10 hours ago, Arlleex said:

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

Вот только что из академического интереса проверил сколько тактов в потолке проводит стек USB от ARM MDK-Middleware, под руками проект с MSC устройством (host тут есть, но пока не используется).

Короче, вышло максимум 873 такта на работу библиотечного OTG_FS_IRQHandler(), который я должен вызывать в прерывании. В среднем счетчик показывал около 400 тактов. Замерял по циклам из DWT_CYCCNT.

Проц. старый добрый F407 на 168MГц. Итого, если считать по тактам выходит время жизни в прерывании в среднем 2,5мкс, максимум около 5мкс.

 

Интересный момент, при подключении по USB (после вызова USBD_Initialize и USBD_Connect) сразу создаются две задачи:

Степень их загруженности тут не могу посмотреть.

 

Получается что мой выигрыш в несколько тактов на входе в прерывание при отказе от делегата никакой погоды вообще не сыграет, овчинка выделки не стоит ))

 

[Arlleex 131]

43 минуты назад, Forger сказал:

Куда хуже когда из-за "этого" весь проект летит "коту по хвост", а сроки поджимают 

Еще страшнее, когда он летит коту под хвост из-за того, что весь проект ты когда-то решил написать пока что еще не до конца освоенными подходами в программировании))

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