Комментарии 72
В большинстве случаев RTOS применяют не для того, чтобы обойти аппаратные ограничения, а из-за удобства - упрощения кода, повышения его читаемости, снижения трудозатрат и вероятности наплодить трудноотловимые баги.
Хотя неаккуратное использование RTOS само по себе может вызывать крайне сложно отлавливаемые баги и вызывает определённые коллизии для исключения которых необходимо глубоко понимать саму "идеологию RTOS". Приходится менять стиль программирования. Ну и задачи пожирают большое количество оперативной памяти.
По хорошему её использование раскрывает себя на микроконтроллерах начиная с ядра Cortex M4 с большим количеством параллельных процессов.
Я начал применять RTOS пар лет назад и поначалу периодически сталкивался с вводящими меня в тупик ситуациями достаточно часто.
RTOS применяют не для того, чтобы
По моему опыту RTOS применяют не потому что решили ее применить, а потому что она идет в комплекте с аппаратной платформой!
По хорошему её использование раскрывает себя на микроконтроллерах начиная с ядра Cortex M4
просто на Cortex M4, наверно проще разбираться с РТОС, чем с аппаратно реализованной моделью прерываний-исключений, управления памятью, ... , я подозреваю. Это такого уровня процессор что там уже сложно без какого-то промежуточного уровня софта, насколько я знаю. То есть на такого уровня процессорах наличие ОС действительно может упрощать задачу анализа программно-аппаратной платформы, поскольку не придется лазить глубже интерфейса к ОС во многих случаях, если ОС достаточно профессиональная.
Современные RTOS для микроконтроллеров, та же FreeRTOS v2, которой я пользуюсь имеет очень удобный механизм работы с прерываниями для выполнения задач, которые не могут ждать. Не сказал бы, что в суперцикле работать с ними сильно удобнее.
Мне кажется что ваша статья родилась из того факта, что у вас мало опыта работы с RTOS, использования фишек, которые она предоставляет и главное общей идеологии - переходя на RTOS приходится менять стиль программирования точно не в меньшей степени как в случае перехода на компонентную модель С++ с "классического" С.
Современные RTOS для микроконтроллеров, имеют очень удобный механизм работы с прерываниями для выполнения задач
Если бы вы привели хоть один пример того что они делают очень удобным, было бы очень интересно прочитать.
Все свои программы на Cortex M0 и половину на M3 я до сих пор пишу на основе бесконечного цикла.
Не считаю себя высокопрофессиональным пользователем RTOS чтобы приводить примеры своего кода, но RTOS отлично справляется у меня даже на STM32F103 c обработкой приёма и дешифрирования данных по CAN, общении с TFT панелью c сенсорным тачскрином по SPI, запись и считывания из FLASH.
В STM32F407, который работает в паре с TFT контроллером происходит обслуживание общение по CAN, дав RS232, 10 входов цифровых 12 каналов ДельтаСигма 24 битное АЦП от ADI(SPI) к которым подключены аналоговые датчики, 2DAC 16 битных по SPI, внешняя FLASH и такие мелочи как RTС, и BACKUP SRAM память.
При этом достаточно много свободных ресурсов пока. Безусловно всё это можно было бы написать и на основе суперцикла и я раньше писал, но уже начинает напрягать дирижировать таким оркестром без очередей и мьютиксов...
И наверно самый большой плюс таки - читаемость кода. Постоянно приходится делать какие то изменения, дополнения. Сложная программа без суперцикла менее структурированной получается.
Вполне понятно, теперь, что вы имеете ввиду, хоть читаемость кода понятие достаточно субъективное. Но я и не говорил что RTOS совсем не нужны!
Они не помогают предварительно выяснить-спланировать работающюю последовательность операций, но они вполне могут помочь реализовать нужную-уже-известную последовательность операций.
Вроде как основное что я хотел рассказать в статье это как и откуда берется эта "нужная-правильная-правильно-организованная последовательность операций".
Может быть действительно дело в не совсем корректном заголовке статьи.
Да, много примеров можно привести, вот нужно будет вам на индикатор графический вывести результат, вы что тут делать будете?
А в РТОС, заводите низко приоритетную задачу и делайте, там что хотите.
вот нужно будет вам на индикатор графический вывести результат, вы что тут делать будете?
А в чем проблема то? Рассмотрим добавление еще одной операции по времени, и добавим эту операцию с нужной частотой в нужном по времени месте. Я же не могу в одной статье расписать все что там было.
Там кстати индикатор был! Но я не помню уже никаких проблем с ним - все работало.
Кстати, можно посмотреть как выглядит монитор АД на сайте, который можно найти по ключевому слову BpLab, внешний вид коробочки почти не изменился.
Ну например, расчет вывода на индикатор занимает скажем 1 секунду, измерять АЦП нужно каждые 50мс и делать расчет чего-то на основе АЦП (фильтровать скажем) за 30мс.
На идикатор остается 20мс, как разбить задачу расчета, которая занимает 1секнуду на 20 мс? Придется дробить задачу расчета вывода на индикатор?
Ну например, расчет вывода на индикатор занимает скажем 1 секунду,
что то вы загнули с 1 секундой, мне кажется, я специально такую тормозную функцию не напишу, если только нарочно задержек наставить! Уж извините это из моего опыта работы и с индикаторами и целыми high definition экранами.
Но даже если 1 секунда, в принципе надо просто ответить на вопрос что сложнее:
запихать в процессор и отладить систему которая поддерживает несколько стеков и их переключение, или
как вы написали:
дробить задачу расчета вывода на индикатор
Задача, в-общем (!), не решается! все зависит от существующего окружения.
Как вы считаете что сложнее?
что то вы загнули с 1 секундой, мне кажется, я специально такую тормозную функцию не напишу, если только нарочно задержек наставить! Уж извините это из моего опыта работы и с индикаторами и целыми high definition экранами.
Ну почему же, у нас датчик работает на 962 кГц, и отрисовывает экран 128 на 128, как раз около 0.5 секунд. А полевые датички они все на низких частотах работают, им питания не хватит на большей частоте работать. 3.4 мА на 9 вольтах. А помимо вывода на графику, еще нужно измерительные параметры считать и по полевой шине общаться.
Вот например, https://www.youtube.com/watch?v=VhUcUpYbtMY датчик от токовой петли 4-20мА питается.
Задача, в-общем (!), не решается!
Как раз решается, за счет РТОС. То, что вы делает руками, там это делается автоматом. Есть свободное время - работает низкоприоритная задача, нет, работает выскокприоритетная, микроконтроллер не простаивает, использует все свое время. За это платим, небольшими накладными на переключение контекста.
Как вы считаете что сложнее?
Проще использовать РТОС (ну или хотя бы планировщик вытесняющий) - и задача в общем решается и проще.
А! Так вы тут с рекламой. Добро пожаловать.
Причём тут реклама? Это американский датчик, в России продаж нет и не будет. Я вам пример просто привёл.
А наш специально не тащу, чтобы не рекламировать.
Пример чего вы привели? я не вижу где американский датчик тратит 1 секунду (или 0.5 секунды) процесорного времени на отрисовку экрана 128 на 128, я вижу только рекламу. Откуда вы взяли эти 1 секунду (или 0.5 секунды) ? Что доказывает это видео?
Если вы в вашем датчике имеете такие цифры, ну это исключительно ваши проблемы.
Тогда получается что вы себе делаете анти рекламу, тогда очень жаль.
запихать в процессор и отладить систему которая поддерживает несколько стеков и их переключение, или
Кстати несколько стеков можно не тащить. Можно на одном все сделать. RunToComplition вытесняющий - очень просто.
Сразу обращаясь к заголовку статьи. Микроконтроллеры, прерывания и т.п. вещи сильно старше RTOS.
Как же тогда, в те времена, люди без шедулера и семафоров жили, раз?
Можете подсказать ресурс с кодом RTOS для микроконтроллера PIC16F675 (именно для него, более мощные не надо), например?
Я это написал потому, что заголовок "Можно ли решить задачу реального времени без RTOS, разберем реализованную задачу" - очень "кликбейтный". Ответом на него будет: "Можно, всегда так делали".
статья интересна достаточно грамотным системным анализом, насколько знаю примерно так проектировались все ранние системы реального времени, в том числе sage, естественно не было никакой RTOS, и само понятие OS появилось позже в процессе разработки, но временных диаграмм и схем подобных приведенным в статье использовалось много, интересные фотографии того времени (1956), на первой программисты sage Al Shoolman, Herb Benington обсуждают подобную диаграмму, вторая относится к технологии программирования того времени, на третьей процесс отладки:
Конечно спасибо за положительную оценку, но что уж очень далеко вы меня отослали (если не сказать послали :) с моим подходом, аж в 1956 год. Мне всего то 50 лет ... будет в следующем году :).
Вряд ли в 1956 году кто то оперировал понятиями прерывания, таймеры... планирование операций.
> уж очень далеко вы меня отослали
по важности технологии (особенно real time) sage это примерно как manhattan project для физики, так что скорее комплимент, другое дело что не особенно много писали долгое время по понятным причинам,
> Вряд ли в 1956 году кто то оперировал понятиями прерывания, таймеры... планирование операций
было многое, если не все, но несколько в другой форме, вообще система прерываний там использовалась для обмена сигналами между двумя машинами которые работали в спарке и общались через магнитные барабаны, модемы первые для sage были сделаны, также впервые ферритовая память (до 256KB), графические дисплеи и пр., на картинке стойка модемов
Совсем не далеко. Не скажу за 1956, но в начале 70-х у нас исходя из аналогичных идей разрабатывали системы реального времени. И достаточно сложные, расчитанные на циклическое исполнение десятков задач, многие из которых решались существенно дольше цикла. И состав задач был не фиксированным, а определялся по функционалу. И длительность цикла при этом выдерживалась с точностью до 1 мкс.
Все таки мне не совсем понятна эта отсылка к разным годам прошлого века.
Вы скажите тогда уж:
вы считаете что рисовать, анализировать, расчитывать временные диаграммы это несовременно что ли? Технология устарела? Такие задачи как то по другому теперь надо анализировать? Как?
Да нет. Это о том, что такой способ традиционный. Особенно для специализированных аычислителей.
> Технология устарела? Такие задачи как то по другому теперь надо анализировать?
конечно нет, здравый смысл не может устареть в принципе, просто надо знать чужой опыт, занимаюсь real time супер долго, на разных операционных системах, но к примеру детали как именно была сделана sage мне были супер интересны
неужели вы имеете ввиду вот эту вот SAGE:
The Semi-Automatic Ground Environment (SAGE) was a system of large computers and associated networking equipment that coordinated ...
Тогда ужасно интересно, с чем в описании этой космической системы перекликается то что я написал! И как найти это место с чем то подобным в космического масштаба описании.
конечно sage, другой такой нет, то что интересно - это естественно, в сети достаточно ссылок, но к сожалению большая часть лабуда, написанная студентами или около того, то что перекликается с Вашим проектом - это применение здравого смысла разработчиков и системный анализ, они типа делали буквально с нуля, даже терминологии нормальной в части sw не было, были только мозги и сравнительно короткий срок готовности, т.е. они первые прошли по пути системного анализа примерно как Вы только в другом масштабе, интересно что когда сделали первую сборку - по времени не просто не влезало в рабочий цикл, а примерно в 3-4 раза, доводили методом итераций, обучаясь по ходу дела, в результате сделали рабочую систему, которая была в деле примерно до конца 80х, хотя и со многими модификациями, как побочный эффект научили IBM mainframe делать, что стало доминирующим фактором на следующие 15-20 лет, если есть вопросы можно в личку
Думаю, было бы неплохо поставить возле АЦП свой контроллер за два доллара, который бы мог хранить 2, 3, ... n измерений. Таким образом период измерений ни когда не будет нарушен. А основной контроллер пусть его опрашивает, считает, и сохраняет в память когда хочет. Вот и нет никаких костылей в виде, как правило, притянутых за уши RTOS. PS: Считаю что большинство вопросов решаются административно, а не при помощи "волшебной кнопки".
Думаю, было бы неплохо поставить возле АЦП
ну да переразвести, заказать изготовление новой платы, по новой отладить железку, ...
Вы это серьезно?
Потом там и был поставлен контроллер, он же DSP процессор примерно как бы за 2 доллара, хотя может и за 20 я точно не знаю. Это был какой то TMS, с 16 битной шиной, кажется, но с поддержкой 32 битной арифметики в АЛУ.
Я это серьёзно, и об этом надо думать сразу, а не потом. Прекрасно понимаю вашу логику, сейчас так весь мир живет. Зачем шить новые штаны по размеру? Портного напрягать, швею! Вот есть штанишки на два размера меньше. Ну ни чего, сейчас по шву распорем, приложим, скотчем приклеим и готово. Делов та на копейку! Вот только лично мне такие брюки не по душе. О чём и написал.
об этом надо думать сразу, а не потом
Вы думаете кто то будет с вами спорить по поводу такого глобального утверждения? Вы совершенно правы, но я бы посоветовал вам внимательно послушать, например, монолог Архитектора из фильма Матрица, в его разговоре с Нео.
Может это позволит вам осознать что истина далеко не так примитивна, что бы ее можно было выразить одной фразой или даже абзацем.
Всю статью ждал когда на сцене появится DMA и освободит процессор от ненужной работы с периферией.
В том процессоре модуля ДМА не было в принципе, процессор был 16-битный насколько я помню, хотя и с поддержкой 32-битной арифметики в АЛУ.
Потом ДМА нужно использовать когда надо исключить прерывания, а тут прерывания нужны не только для чтения регистров переферии, тут еще некоторую логику в них приходится иметь.
С ДМА у меня есть текущий работающий проект - высокоскоростной конвертор SPI To Ethernet, там для обеспечения скорости, прям вот пришлось исключить прерывания, потому что вход и выход из прерывания это добавленнное время между SPI посылками. Может как нибудь соберусь, распишу как так получилось.
Потом ДМА нужно использовать когда надо исключить прерывания
Не совсем согласен, мне кажется цель ДМА освобождение полезного времени работы процессора в общем смысле, не важно от прерываний или поллинга.
Например, в вашем псевдокоде сохранение данных во флеш происходит в основном цикле. То есть лишних прерываний нет, но есть лишний поллинг силами процессора. Это накладывает определенные ограничения на время операции вычислений. Что случится в вашей программе если условие Tsyst - Tcalc > Tsave не выполнялось более 256 раз подряд и новые данные записывать некуда? Пришлось бы переходить на прерывания, а так как данных много, прерываний было бы несколько.
Реализация на ДМА выглядит максимально просто:
По прерыванию таймера стартовали ДМА транзакцию чтения АЦП.
По прерыванию завершения ДМА транзакции проверили нужно ли записать данные, если да - стартовали ДМА транзакцию записи во флеш.
В основном цикле вычисления и проверка недопустимо большого времени.
Противоречивые чувства от статьи. Вроде бы все верно написано, но на самом деле все в разы проще. Проблема не в RTOS/baremetal, а в ложном мнении, что RTOS - это панацея от необходимости архитектурного понимания / планирования синхронизации функций в устройстве.
При проектировании системы и выборе аппаратной платформы делается анализ, хватит ли производительности (в широком смысле - вычислительная мощность, объем памяти, пропускная способность шин и т.п.). Очевидно что платформа подбирается под "хватит".
Затем весь реалтайм вешается на прерывания с учетом приоритетом, где возможно - прикручивается DMA (но есть нюансы), остальное в конечный автомат в фоне. А RTOS может помочь только в обеспечении вытеснения менее приоритетных задач вместо ручной реализации разбиения длительных процессов на "псевдотакты" для кооперативного выполнения.
Применительно к описанной задаче:
1. Старт и обработка АЦП - вешаем старт на прерывание таймера
Пока АЦП работает, можно что-то повычислять, либо сидеть поллингом ждать окончание преобразования
2. Пришло прерывание / поднялся флаг что АЦП закончил преобразование - запускаем транзакцию записи во внешнюю память по SPI. Записываться должны уже заранее подготовленные данные, которые должны быть посчитаны на предыдущем шаге. Пока идет транзакция в память - вычисляем еще что-нибудь, либо ожидаем поллингом завершение работы с SPI-памятью.
Если вдруг оказалось, что записывать пора, а данных для записи нет, значит не записываем. Считать это ошибкой или нет - определяется на этапе анализа требований.
3. Все оставшееся время до следующего прерывания таймера для АЦП что-то считаем и готовим для следующего цикла записи в память.
Связка 1 и 2 обеспечивает строгую детерминированность во времени тех процессов, которые должны быть детерминированы.
Если дизайн таков, что транзакция в память длиннее чем период АЦП, то разбиваем транзакцию SPI на несколько тактов, отслеживая атомарность и контроль целостности всей записи.
Вопрос применения / неприменения RTOS: RTOS может облегчить механизм синхронизации тасков, может избавить от написания некоторых драйверов на аппаратные узлы платформы, может предоставить библиотечные сервисы какого-нибудь UDP и т.п., но не заменит архитектора системы.
неплохо написано, можно сказать RTOS = glue, может все соединить если спроектировано правильно, но типов клея как известно достаточно много, дело архитектора выбрать правильные компоненты и правильный клей по возможности "from the shelf", недостающие части качественно изготовить, собрать и испытать по правильной технологии, это если проект не слишком сложный, для сложных проектов бывает, что и клей специальный нужен, а иногда даже стандарты новые с которых приходится начинать
Пришло прерывание / поднялся флаг что АЦП закончил преобразование - запускаем транзакцию записи во внешнюю память по SPI. Записываться должны уже заранее подготовленные данные, которые должны быть посчитаны на предыдущем шаге. Пока идет транзакция в память - вычисляем еще что-нибудь, либо ожидаем поллингом завершение работы с SPI-памятью.
Все бы хорошо только вы выкинули обработку отсчета с АЦП, а обработка сигнала с этим новым отсчетом одна из приоритетных задач, если ее вовремя не выполнить система не имеет права дальше работать потому что может руку пациенту оторвать (маленько утрируя).
Но запись во флеш имеет тот же приоритет по другой причине, если нет записи во флэш нет смысла продолжать измерение потому что ему нельзя доверять!
Поэтому надо железно гарантировать и то и другое, а вы просто взяли и выкинули одно условие.
Потом работа с SPI шиной конечно велась через SPI прерывания, о которых я скромно умолчал, потому как во первых это отдельная песня, 2. она очень усложняет описание или уводит в сторону от анализа временных диаграм .
... вы выкинули обработку отсчета с АЦП, а обработка сигнала с этим новым отсчетом одна из приоритетных задач ...
... запись во флеш имеет тот же приоритет по другой причине ...
Я не выкидывал ничего, я приоретизировал описанные Вами процессы. Обработка отсчета АЦП производится все время, свободное от обслуживания периферии, и про это я в явном виде написал.
Совершенно очевидно, что если нет посчитанных данных, то записывать во флэш нечего (если это конечно не сырые отсчеты АЦП, но это тривиальный случай получили - записали). При этом не менее очевидно что жизнь пациента имеет наивысший приоритет.
Вам имеет смысл разобраться в требованиях, а не в реализации, расставьте запятые в "казнить нельзя помиловать". Процессор выполняет одну инструкцию (грубо) в один момент времени.
если это конечно не сырые отсчеты АЦП
Это именно сырые (первичные) данные, я же написал: "если они не сохраняются, измерять, имеется ввиду продолжать процедуру расчетов и измерения, не имеет смысла, потому что не выполнено требование медицинского стандарта, и результатам расчетов нельзя будет доверять, и значит их нельзя использовать"
и поэтому с точки зрения продолжения измерения
не менее очевидно что жизнь пациента имеет наивысший приоритет
это не правильное утверждение! нет разницы почему мы прекратим измерение, потому что пациента бережем или потому что результат измерения все равно придется выкинуть. Иногда очевидное не очевидно, видимо.
Это знаете как называется:
Смотрю в то что написано, но читаю что то свое.
Если все так, как Вы описали, то проблема вообще отсутствует при условии что в железо не упираетесь. Запустили АЦП, пришло прерывание об окончании - запустили на прерываниях и/или DMA транзакцию во флэш, все оставшееся время до и после прерываний в фоне считайте свои вычисления, где проблема-то вообще??? На картинке у Вас время сохранения и время вычисления последовательны, а в тексте Вы пишете, что работа по прерываниям.
Есть конечно еще шанс, что тормоза из-за неучтенного времени стирания сектора флэш, особенно если это не NOR FLASH, а чтото SSD-подобное, которое прячет от Вас проблемы со стиранием.
вы наверно пропустили что все это делалось больше 15 лет назад, такие буквы: DMA, NOR FLASH, SSD были, но в каких то космических далях.
То есть все действительно упиралось в железо.
Потом, нельзя, например, получить прерывание от АЦП когда АЦП висит через SPI, можно получить только прерывание SPI. И на том же (!) SPI висит флэш, соответственно это то же самое прерывание SPI в конечном итоге, куда бы писало DMA по прерыванию SPI, в АЦП или во флэш, как вы себе это представляете?
Надо просто разрулить обращения к шине по времени, при чем обращения обоих типов надо гарантированно обеспечить. Там просто такое железо было что когда процессор пишет во флэш он ничего больше не может делать, вот просто такое железо - бывают такие условия задачи.
А вообще я бы хотел чтобы читатель сосредоточился на методе анализа подобного рода задач во времени, а не на том почему такая задача возникла. Вот она возникла в таком виде - так бывает!
вы наверно пропустили что все это делалось больше 15 лет назад, такие буквы: DMA, NOR FLASH, SSD были, но в каких то космических далях
Я в embedded 25+ лет, начиная с середины 90-х и 8051, так что рассказывать и сам много могу, и были проекты когда на ассемблере пару байт памяти не хватало, как в той известной байке
Надо просто разрулить обращения к шине по времени
Именно это я и написал Вам в первом своем комментарии, в том числе и про необходимость сидеть в поллинге и тупо тратить такты, если железо не позволяет ничего больше, и про обработку ошибок
Дело в том, что последние лет 10 я в-основном пытаюсь сделать этот мир лучше, разгребая подобные решения, сделанные от непонимания базовых принципов этого самого embedded и realtime. И вроде программист отличный и код вроде классный, но люди вообще не понимают, что они делают, поскольку архитектор на проекте отсутствовал как класс (не важно, выделенная это должность или это программист или это железячник и т.п.).
Ваша статья озаглавлена "Можно ли решить задачу реального времени без RTOS, разберем реализованную задачу", а я пытаюсь донести сообществу, что RTOS тут как бы и ни причем, и про то, что Ваша задача не стоит выеденного яйца, если действовать не от реализации в железе, а от приоритетов функций, определяемых бизнес-логикой устройства.
Думаю больше переписываться действительно не стоит, мы на разных языках
куда бы писало DMA по прерыванию SPI, в АЦП или во флэш, как вы себе это представляете?DMA может писать туда, куда ему задаст процедура запуска измерений — то есть из SPI в буфер АЦП. А потом генерить прерывание, которое запустит запись во флэш через SPI, которая тоже может идти через DMA — но DMA нужно каждый раз перепрограммировать. И по окончании транзакции команды и данных во флэш также генерировать прерывание. Кстати, ADUM на ядре 5051 позволял делать это задолго до STM32, уже 15 лет назад. Правда, ему и внешний АЦП не особо-то нужен, разве что, для гальванической развязки.
А потом генерить прерывание, которое запустит запись во флэш через SPI, которая тоже может идти через DMA — но DMA нужно каждый раз перепрограммировать.
Ну вы дальше тогда рассказывайте: какой смысл тогда в DMA, если его надо каждый раз перепрограммировать??? То есть процессор все равно занят.
Я знаю как минимум одну причину почему в таком случае нужно рассуждать на такую тему: потому что когда есть ДМА это типа круто, а без ДМА так себе фигня какая то.
ДМА работает только для простого копирования слов, если вам надо сначала послать конфигурацию, потом послать данные, потом команду на запись, какую придется конфигурацию ДМА городить? А главное зачем, когда все нормально работает на обычных, практически крос-платформенных прерываниях?
Потом там же вроде совершенно ясно написано что после каж-до-го(!) АЦП надо запустить процедуру обработки отсчета, а это прямо противоречит принципу работы ДМА, ДМА используют чтобы процессор НЕ замечал появление отсчетов по отдельности.
Я не думаю что вы этого не понимаете, поэтому у меня только одно объяснение почему здесь надо приплести ДМА, просто хочется порассуждать про ДМА и про ADUM на ядре 5051 в котором оно было 15 лет назад.
интересно какой процент читателей с вами бы согласился, я не сомневаюсь что большой.
Но по моему мнению в ваших рассуждениях нет логики. Вы путаетесь в источниках прерываний, но без практического примера этого не доказать. Но вы игнорируете практический пример, а временные диаграммы и подавно.
В своих рассуждениях вы опираетесь только на свои рассуждения.
С шулером спорить бесполезно.
сохранять не результаты вычислений, а сырые данные АЦП — это противоречит этим диаграммам
интересно где же оно противоречит этим диаграммам? если вы такое утверждаете вы не имеете права их игнорировать!
Вообще я писал уже, что там так было сделано железо, что процессор не мог ничем заниматься во время сохранения, поэтому тут нечего обсуждать это просто внешнее условие задачи, даже, наверно, более того, это во многом определяло суть задачи.
Получается происхождение задачи вызывает вопросы, но моей целью было продемонстрировать метод анализа, метод того как идентифицировать и спланировать операции-события в системе работающей в реальном времени, задачу можно рассмотреть другую метод применить такой же.
Ну и ДМА в процессоре просто не было, на всякий случай напоминаю!
При проектировании системы и выборе аппаратной платформы делается анализ, хватит ли производительности
К сожалению, бывают задачи, когда нужно впихнуть систему в имеющуся аппаратную платформу. И накладные расходы по организации вычислений очень существенны.
Мне кажется, тут надуманные проблемы рассматриваются.
АЦП настраиваем на чтение по сигналу от таймера с сохранением результата в массив, и нам становится все равно, сколько что времени занимает. Лишь бы успевали обрабатывать очередь измеренных значений.
Если АЦП не умеет класть в массив (нет ПДП), реализуем то же самое программным путем: по прерыванию от таймера запускаем АЦП на измерение, по прерыванию от АЦП вынимаем данные и кладем в очередь.
АЦП не умеет генерировать прерывание? Ну что ж, выбираем время, за которое АЦП точно успеет измерить значение и настраиваем таймер (тот же или другой) на этот период времени, по прерыванию спокойно записываем данные в очередь. Нам все равно, что там делает основная программа - мы отработали строго через заданный интервал времени.
И этот подход в разных вариантах может быть реализован что с RTOS, что без нее. О чем тогда вопрос в заголовке?
И этот подход в разных вариантах может быть реализован что с RTOS, что без нее. О чем тогда вопрос в заголовке?
Вот именно что может быть реализован что с RTOS, что без нее! Вы даже ответ дали, а говорите что вам вопрос не понятен! Статья то, в общем, о том что,
есть у вас RTOS или нет RTOS, вам все равно нужно анализировать временную диаграмму операций и RTOS вам в этом не поможет.
Если уж придираться к заголовку...
Он как бы рисует следующую картину. Есть задача, которую надо решать в реальном времени. И RTOS всегда для этого используется, потому что без нее никак. В крайнем случае без нее ОЧЕНЬ сложно.
В действительности же очевидно, что RTOS нужна не для возможности работы с задачами реального времени, а для упрощения программирования сложных систем РВ. Если же задачи сами по себе простые, использование RTOS - лишняя трата ресурсов. А главное - да, думать всегда полезно. И более того - при использовании RTOS думать, возможно, придется гораздо больше.
В действительности же очевидно, что RTOS нужна не для возможности работы с задачами реального времени, а для упрощения программирования сложных систем РВ
вот и получается противоречие, потому что в конце вы написали:
И более того - при использовании RTOS думать, возможно, придется гораздо больше.
Дело в том что это противоречие действительно существует, это суровая реальность:
RTOS создаются чтобы жизнь упростить, но очень часто ее усложняют!
Можно проанализировать в каких случаях они ее усложняют, например
Если мы должны портировать RTOS на вновь созданную аппаратную платформу а потом поверх этой портированной RTOS реализовать свою задачу,
этот путь может оказаться гораздо длиннее чем
рализовать свою задачу сразу поверх тех функций которые предоставлены напрямую аппаратной платформой.
Поэтому я там вверху в коментариях и написал что обычно RTOS идет в комплекте с аппаратной платформой, потому что если вам приходится портировать RTOS самому сравнительная трудоемкость такого подхода как минимум вызывает вопросы. Интересно почему меня за это там заминусовали!
Если автор ведёт речь об этом дивайсе, и о микроконтроллераx типа MSP430, то картина в целом ясна. Они свои библиотеки поставляют без RTOS.
А RTOS, которые раньше позиционировались для MSP430 перестали существовать.
А ведь я в свое время на MSP430 c 2 КБ памяти! запускал uC/OS-II и получались отличные охранные централи с подключением к стационарным телефонным линиям (теперь такие никто не помнит) , GSM, GPRS ...
Мало того, uC/OS-II RTOS рекомендовалась для такого типа микроконтроллеров.
А теперь спланировать тайминги на такте считается подвигом.
В старые добрые времена делали АОН на компараторе с процессором на 2 МГц.
За последние 20 лет написал много прошивок для разных микроконтроллеров, ни разу не использовал RTOS. В этом нет каких-то больших проблем, берёшь анализируешь что устройство должно делать, какие параметры критичны по времени, из этого складывается что должно быть подключено по каким интерфейсам и с какой скоростью должно работать. Это не рокет сайнс.
Балалайка из далёкого прошлого, когда я был молодым программистом. Железка состоит из главной платы и пяти подчинённых. К главной плате подключен ПК через RS-232 и пять подчинённых плат, через RS-422, конечно все сидят на одной шине. Всё выглядит красиво и благородно. Но! По задумке архитекторов главная плата должна проводить ровно 125 сеансов связи в секунду (передать и принять примерно 90 байт) с каждой подчиненной платой. И ещё с ПК общаться, но там скорость медленная, что-то типа 4800. Я это всё прикинул в смысле скорости, получилось RS-422 должен непрерывно фигачить мегабит в секунду. И плюс ещё общение с ПК в фоне. С подчиненными платами проблем нет, там нужно провести 125 сеансов с главной платой и на каждый сеанс провести один сеанс с другим процессором (DSP от техаса, не спрашивайте почему так). Но №2! У меня в руках ATmega64L на 8 мегагерц. 8 мегагерц, Карл, т.е. 80 тактов на обработку каждого байта по RS-422, включая вообще все накладные расходы. Я даже сначала сказал, что это не очень возможно сделать. Но потом взял себя в руки, подумал, и написал программу, которая работает очень линейно, без прерываний (пролог и эпилог ISR это непозволительная роскошь в тех условиях), всё на флагах. 125 сеансов в секунду это 8 мсек на каждый цикл общения со всеми пятью подчиненными платами. Если подчинённый микроконтроллер не успел ответить за несколько микросекунд, то он не успел, опрашиваем следующего. Кстати, программа была на C, но на таком, который уже практически не отличается от ассемблера. Там даже goto были, и мне не стыдно за их применение.
Но в будущем мы такие вещи старались не допускать. Это получилось потому, что более опытные дяденьки не удосужились тупо посчитать количество информации, которое требуется прогнать через несчастный маленький микроконтроллер.
Ещё была занятная балалайка как мы делали PCI-плату, мне дали разработку WDM-драйвера. Я написал каркас драйвера, он умел все штуки, которые должна уметь PnP плата. Теперь нужно было делать сам функционал железки, но внезапно мы как-то поняли, что на плату тупо забыли добавить RAM. Ну вот не подумали, что в микроконтроллере памяти 4КБ, а хранить нужно немного больше. Так и загнулась эта плата, а жаль, очень хотелось написать дравйвер.
Такие вот задачи связанные с аппаратными ограничениями всегда становятся самым интересным опытом, которым хочется поделиться, и про который интересно послушать.
Да, это прямо такой интересный вызов. Но хочется чтоб их было поменьше )
Другой вызов был, когда нужно было утрамбовать программу бутлоадера в 8КБ. Проблема в том, что нужно было использовать библиотеку wiznet. Первая версия программы была 13КБ. Потом методом всяких ухищрений мы это дело ужали в примерно 7900 байт. Естественно тоже С, с плюсами это вообще не решалось никак.
Можно ли решить задачу реального времени без RTOS, разберем реализованную задачу