Попытка ускорить код Arduino

[BOB51]

Есть еще один нюанс...
В случае с ассемблером планировку ресурсов МК делает автор программы.
В случае с ЯВУ любая вставка на ассемблере подчиняется правилам того ЯВУ, на котором основная программа написана.
Планировка ресурсов ядра автору самодельной программы уже недоступна (то же касается и любой уже готовой РТОС ). Это в свою очередь приводит к неявно видимым расходам времени и ресурсов на "стыковочные модули" компилятора, "сшивающего" ассемблерных вставки с основной программой (те же расходы на стек для используемых регистров к примеру и прочую "начинку" компилятора).
Так что по отношению к устройствам реального времени подход у "чистого ассемблера" и ЯВУ всегда будет разным (а порой и резко отличающимся).

[MLX90640]

ART_ME писал(а):

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

...навряд ли будет тут уместно, ибо RTOS отнимает на себя процессорное время и никоим образом не способствует скорости работы. Название "real-time" не означает, что всё будет делаться прям мгновенно "здесь и сейчас". Скорее наоборот. И как раз чем глубже изучаешь RTOS, тем яснее это понимаешь. RTOS не позволит ускорить медленный МК. RTOS руководит кучей процессов в быстром МК, не позволяя ему за "зашится" в этом месиве, образно выражаясь.

[КРАМ]

С.Н. писал(а):

И вот пока скетч этим занимается, маховик пролетает уже положение, когда микроконтроллер должен был дать команду на искрообразование. В сухом остатке получается, что разница между временем чтения данных из области Flash и с ОЗУ между программой на ассемблере и скетчем Arduino IDE (обычными массивами и константами) составляет порядка 1 мкс. Таких операций надо сделать десятки во время расчета параметров, да и сам расчет, даже целочисленный требует временных затрат. В итоге на больших оборотах (период = 2-3 мс) маховик успеет уже сместится значительно.

Реальное время в подобных устройствах обеспечивается не кодом, а аппаратными средствами и пониманием работы системы автоматического регулирования. Маховик жутко инерционен, поэтому нет никакого смысла считать процессы с угловыми скоростями. Все, что требуется - это поддерживать генерацию событий через непрерывно работающий Output Compare и измерять времена посредством Input Capture. Причем с единой временной базой первого и второго.
А расчет может происходить со скоростями, которые на порядок ниже частоты вращения.

ART_ME писал(а):

Полагаю, что углубленное изучение RTOS, которые вроде как уже прижились

Это эпичная чушь. РТОС позволяет параллельно работать множеству тяжеловесных блокирующих задач без специальных мероприятий внутри этих задач. И все. В остальном РТОС по сравнению с суперлупом медленнее в части реализации реального времени хотя бы потому. что требует дополнительного времени на сохранение-восстановление достаточно объемного контекста.

[Eddy_Em]

Если разработчик под МК не может обойтись без ртос, гнать его ссаными тряпками, т.к. он совершенно не имеет квалификации!

[С.Н.]

КРАМ писал(а):

...Все, что требуется - это поддерживать генерацию событий через непрерывно работающий Output Compare и измерять времена посредством Input Capture. Причем с единой временной базой первого и второго.
А расчет может происходить со скоростями, которые на порядок ниже частоты вращения.

Что же Вы все Коты такие умные? Все тайны выдаете.

Всем спасибо. Мне больше ничего не надо. Однако имею право высказаться. Прошу без обид! Для меня все это выглядит просто как сюр какой-то.
В теме про Arduino и в расчете на быстрое решение был задан вопрос про Arduino IDE не специалистом по С со всеми своими ++ и прочими программными извращениями с громкими именами. Скетч приложен. Почему не компилируется скетч? Если там глупость написана или это не может там работать скажите?
Критически поглядите свои ответы и найдите там ответ по этим вопросам. По моему это просто соревнование между Вами кто больше всяких слов знает и кто из Вас круче или Вам просто скучно.

Всем удачи и добра.

[ART_ME]

С.Н. писал(а):

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

К сожалению, Вы правы.
Поэтому надо выбирать те сообщества, где описанного Вами отношения меньше всего.
К примеру, задаю вопрос на одном не нашенском форуме, а в ответ тишина. Хотя до этого на другие вопросы очень четко и доброжелательно отвечали.
Спустя какое-то время в процессе самостоятельного решения проблемы начинаю понимать, что мой вопрос получился... дурацким.
Но меня при этом никто не назвал "земляным червяком", а всего лишь тактично промолчали.
PS. По RTOS остался при своем мнении, ибо аргументы в стиле "чушь" считаю несомненным доказательством обратного.

[veso74]

С.Н. писал(а):

... Скетч приложен. Почему не компилируется скетч?...

Я дал решение этого вопроса на предыдущей странице: viewtopic.php?p=4337014#p4337014
Скетч компилируется. См. скрийн ниже.

Ваш ответ: Ни: работает? Ни: не работает? Хочете помощи, Вы даже не пробовали то, что мы дали ...

Вложения

Untitled-1.jpg

(107.06 KiB) Скачиваний: 36

[Morroc]

ART_ME писал(а):

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

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

[С.Н.]

veso74 писал(а):

С.Н. писал(а):

... Скетч приложен. Почему не компилируется скетч?...

Я дал решение этого вопроса на предыдущей странице: viewtopic.php?p=4337014#p4337014
Скетч компилируется. См. скрийн ниже.

Ваш ответ: Ни: работает? Ни: не работает? Хочете помощи, Вы даже не пробовали то, что мы дали ...

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

[КРАМ]

ART_ME писал(а):

решения проблемы начинаю понимать, что мой вопрос получился... дурацким.
Но меня при этом никто не назвал "земляным червяком", а всего лишь тактично промолчали.
PS. По RTOS остался при своем мнении, ибо аргументы в стиле "чушь" считаю несомненным доказательством обратного.

Есть разница между задающим вопрос и отвечающим на вопрос. Задавать глупые вопросы можно и нужно. А вот отвечать глупостями - нет. Вы упомянули про РТОС, не имея про нее никакого понятия.
Впрочем иметь мнение - не запрещено. Но не всегда стоит его публично афишировать.

Добавлено after 7 minutes 11 seconds:

С.Н. писал(а):

Что же Вы все Коты такие умные? Все тайны выдаете.

Всем спасибо. Мне больше ничего не надо. Однако имею право высказаться. Прошу без обид! Для меня все это выглядит просто как сюр какой-то.

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

[ART_ME]

КРАМ писал(а):

Впрочем иметь мнение - не запрещено. Но не всегда стоит его публично афишировать.

А тем более выдавать свое мнение за истину в последней инстанции.

Добавлено after 2 minutes 54 seconds:

Morroc писал(а):

ART_ME писал(а):

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

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

Если мы не знаем причины, по которой ТС во что-то упоролся, является это поводом для критики его позиции?

[MLX90640]

Нет, почему же? КРАМ тут совершенно прав по поводу RTOS. Просто RTOS стали впихивать в кодогенератор CubeMX и CubeIDE и активно пропагандировать, поэтому некоторые погромисты с радостью сели на RTOS, полагая, что она решит все их проблемы. Ну да, их проблемы она решает, поскольку занимается распределением системного времени и не нагружает мозги погромиста вопросами тайм-менеджемента и структуры программы в целом. Становится легче строить взаимодействие между задачами, вроде бы как тоже на пользу неокрепшим погромистам.
Но вот навряд ли эти погромисты всерьез задумываются, какой ценой достаётся такое упрощение. За неумения погромиста расплачивается микроконтроллер повышенным расходом ресурсов.

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

[КРАМ]

ART_ME писал(а):

А тем более выдавать свое мнение за истину в последней инстанции.

А откуда вы взяли, что я излагаю свое мнение?
Я канешна не Бог весть какой специалист в РТОС, но ее структуру и назначение я более-менее себе представляю...
И даже кое что от РТОС портирую в своих проектах...
И мой первоначальный коммент не содержал только оценку "чушь". Я объяснил откуда появилась такая оценка. Ну и разговор шел, если что, про вытесняющую РТОС. Так вот, основой вытесняющей РТОС (если оставить в покое подробности) является планировщик (шедулер), который вызывается всякий раз, когда нужно сменить исполняемую задачу (таск). Смена задачи происходит путем смены контекста задач. То есть, чем чаще переключаются задачи, тем выше накладные расходы времени.
Альтернативой РТОС может быть выполнение кода приоритетной задачи в прерывании (при наличии nested контроллера прерываний). Ну или внутренняя структура задач исключающая блокирование исполнения суперлупа на неприемлемое для алгоритма время. Например, с помощью машин состояний задач.
Преимущество РТОС проявляется при большом количестве задач, администрировать которые с РТОС гораздо проще. К ФУОЗ, которые имеет ввиду автор темы, это никак не относится. И уж точно такого рода устройства ногодрыгом не реализуются.
ЗЫ. Правда есть еще кооперативные РТОС, но они мало чем отличаются от суперлупа с точки зрения реализации РВ.

[ART_ME]

MLX90640 писал(а):

Нет, почему же?

Вы считаете, что RTOS для решения задачи ТС нежелателен на основании того, что какие-то неизвестные программисты, по Вашему мнению, что-то делают не так? Что RTOS стали впихивать в кодогенератор CubeMX и CubeIDE и активно пропагандировать, что Вам лично ужасно не нравится? Вас беспокоит слабая нагрузка каких-то там программистов? Вам очень хочется, чтобы строительство взаимодействия между задачами шло на пользу неопознанным неокрепшим погромистам? Вам важно, чтобы они понимали цену такого упрощения? Вас беспокоит повышение расходов ресурсов микроконтроллера ТС?
Вот именно об этом я и говорил - Вы ответили на кучу вопросов, которые Вам никто не задавал. А зачем собственно?

[КРАМ]

ART_ME писал(а):

Вы считаете, что RTOS для решения задачи ТС нежелателен на основании того, что какие-то неизвестные программисты... бла... бла...бла

Вы, милостивый государь, пустопорожний демагог и болтун. Пришли сюда с абсолютно бестолковым и безграмотным предложением и пытаетесь не потерять лицо.
Это выглядит смешно и жалко...
ЗЫ. Кстати, AVR не в состоянии реализовать вытесняющую РТОС. Кооперативная, как я ранее сказал, никаких преимуществ перед суперлупом в части реализации реального времени не имеет.

[ART_ME]

КРАМ писал(а):

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

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

[КРАМ]

ART_ME писал(а):

Мое предложение состояло в том, что ТС имеет смысл поискать ответы

Может приведете цитату, где автора оскорбляли или был флуд? Лично я все свои комментарии снабжал цитатами, на которые комментарий и был положен.
А то, что вы болтун и записной демагог, никакого отношения к автору не имеет. Да и не оскорбление это, а констатация факта.

[Eddy_Em]

Ну, ртось здесь как бы побочкой вылезла. А основной-то посыл о том, что на кой черт на асме писать? Я вообще не представляю себе, сколько страниц кода нужно накатать на асме, чтобы простой конечный автомат запрограммировать! А уж если ТС вдруг решит на ARMяней переползти, то ему только посочувствовать остается: там с асмом вообще делать нечего!

[КРАМ]

Eddy_Em писал(а):

на кой черт на асме писать?

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

[MLX90640]

По-моему, это господин ART_ME тут насылает волны флуда, всунувшись со своей RTOS в тему, не поняв её (темы) смысла. Зачем RTOS, если нет проблем с тайм-менеджментом в проге, но есть проблема быстродействия отдельных функций? RTOS не решает проблему быстродействия, она решает проблему тайм-менеджмента и обмена между задачами. ART_ME, просто изучите более углубленно эту самую RTOS, чтобы не пороть пурги, по-русски выражаясь. Извините за грубость, но пока что вы в этой RTOS нихренашеньки не петрите, кроме тупого "поставил и чето накрутил". И чето походу вы как-то не очень-то врубаетесь в толкование термина "задачи реального времени". Поскольку этот термин несколько сокращен. Полностью он называется "задачи реального МАСШТАБА времени". То есть дается некое дискретное значение квантования этого времени. А не исполняется "прям вот здесь и сейчас".

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

ART_ME писал(а):

Вы ответили на кучу вопросов, которые Вам никто не задавал.

А вы сами со своей RTOS на какой вопрос ответили? Вначале посмотрите на себя, потом других ругать будете.

временем чтения данных из области Flash

Если медленно читается из области флеша, перенесите требуемые данные в SRAM микроконтроллера еще до начала работы с ними. Это называется кэшированием данных и так принято поступать всегда в подобных случаях.