Наткнулся на сайт http://www.lancos.com/projects.html, в частности http://www.lancos.com/mthreads.asm.html, где предлагается использовать наноЯдро для мелких МК АВР.

Пытаюсь понять, зачем в принципе нужна в малоресурсном микроконтроллере кооперативная ОС? Или я ничего не понимаю, или они имеют оч-чень хороший план(:-).

Может кто-нибудь объяснить мне более-менее внятно, можно даже на пальцах, куда катится мир?

а зачем lancos ассоциируется у Вас с миром ?)

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

По мне так это програмный алгоритм для применения в задачах определенного назначения. На вкус и цвет как говорится.

=GM=, как Вы верно заметили, вопрос применения ОС в микроконтроллерах здесь неоднократно поднимался и обсуждался. Достаточно поднять эти темы и внимательно и НЕПРЕДВЗЯТО почитать (это чтобы снова не поднимать известную тему, грозящую перерасти в религиозный спор).
С другой стороны, если Вы ещё не чувствуете острой необходимости применения какой либо ОС, то и не применяйте.
ОС, о которой идёт речь, скорее написана как пример неординарного подхода, из которого можно кое что и для себя почерпнуть.
Необходимость применения того или иного средства (и ОС в частности) определяется конкретным программистом и поставленной задачей.
И последнее, я бы очень хотел чтобы на форуме решались больше вопросы "Как?", а не "Зачем?"
И это не столько моя прихоть, сколько свидетельство неумолимой статистики, которая на 99% утверждает, что темы, ориентированные на вопрос "Зачем?" как правило не несут полезной информации, а больше призваны просто потрепаться.

Ну не хотелось бы быть причиной возникновения квази-псевдо-религиозного спора(:-). И причина поднятия данной темы не просто потрепаться. Я на самом деле не понимаю необходимости применения миниОСей в МК. Хотя, как обратный пример, могу высказать мысли, которые возникли недавно при разговоре на форуме с одним товарищем. Как мне показалось, он просто размещает целиком неизвестные программы (в смысле не им написанные) в некотором месте ОЗУ, добавляет свою собственную квазиОС и может эти программы запускать и переключать. Здесь необходимость ОС очевидна, хоть это и не разработка собственного софта.

перечитайте еще раз это:



ОС понятие растяжимое, в контексте МК с крошечным объемом памяти как в S1200 в роли ОС может выступать некий шаблон кода или модуль, который просто упростит Вам жизнь тем, что возьмет на себя ответсвенность за обслуживание портов I/O и за запуск некоторых функций обработчиков по некоторым событиям. Вам же останется лишь задать события и написать те самые функции обработчики.

Конечно, может быть в том есть особый кайф если для каждого проекта заново описывать работу с УАРТом, таймерами, продумывать планировщик задач и т.п. Говоря Вашими словами: но я на самом деле не понимаю необходимости переписывания одного и того же несколько раз на год, когда можно применить уже готовую ОС. Нечто сродни изобретению велосипеда получается.

Очень приятно читать ответы зубров. Кратко. Чётко. Доступно для понимания. Самому очень помогали. С другой стороны, понятно, что с точки зрения модераторов, такие топики являются, в принципе, мусором "не несущим информации". А хранить и модерировать приходится.

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

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

С уважением.

Не так все просто. Я вот не чувствую острую необходимость применения ОС, но этот вопрос меня интересует, и я, стараясь не ввязываться в "религиозные споры", пытаюсь его выяснить. Кинуться в бой сразу и без оглядки было бы рискованно для текущих проектов.


Ни в коей мере не желая кого-то задеть, в первую очередь авторов. Модератор стерпит :-)
Уровень многих тем "Как" настолько низок, что назвать их несущими полезную информацию тоже было бы слишком оптимистично. А в "трепе", если в нем нет перехода на личности, есть много полезного.

Спасибо всем, выходит, тема интересует не только меня(:-).

Покамест, никто более-менее внятно не ответил на мой вопрос. Не надо трепа и общих слов, просто скажите, как вы применяете, какую-либо ОС, если применяете.

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

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

Ответ на этот вопрос в этой ветке уже был дан.

А с вопросом "куда катится мир?" вы обратились явно не по адресу. Вам лучше ответят в форумах по философии.
Других вопросов я здесь не заметил.

Не задавайте "общих" вопросов класса "расскажите мне все обо всем" и с гораздо большей вероятностью не услышите в ответ

>> достаточно экзотическая идея переключения с одного
>> процесса на другой
Интересно, как вы поняли, что эта идея экзотическая, если до этого не использовали ни вытесняющую, ни кооперативную ось?

Думаю экзотика заключается в их неприменении.

Делаем программный или ставим в позу аппаратный стек и говорим бай-бай всем осям.

=GM= я правильно угадал Ваш способ,или мне опять прийдется за пивом сбегать?

Классик-баснописец сказал: "Беда, коль сапоги начнет тачать пирожник, а пироги печи - сапожник"!
Когда инженер-электрик берется программировать - это пол-беды, а вот когда он же берется учить программированию других - совсем беда!

Чтобы не плодить много бесплодных постов(:-), соберу все в один и попробую ответить всем сразу.

Вопрос был такой. Зачем в принципе нужна в малоресурсном микроконтроллере кооперативная ОС? На мой взгляд, ОС нужна, чтобы облегчить жизнь пользователю данной системы, помочь ему комфортно запускать разные задачи и работать с ними, как в ДОС или в Виндоуз. А у микроконтроллера, в основном, есть одна задача и она, как правило, не меняется за время жизни МК (я не беру в расчет обновления). Как спрашивается в анекдоте, Моня, зачем нам эти шутки?


Я вас умоляю! Ответственность за обслуживание портов! Это одна строка кода, какая ответственность? Что я не так напишу строку кода, или что? Пока я не чувствую необходимости применения ОС, пока я чувствую необходимость обсуждения вопроса применения миниОС в МК(:-).


Кто мешает скопировать все процедуры инициализации, работы с уартом, таймерами из предыдущего проекта, как вы предлагаете сделать с ОС?


Вот только не надо надувать щеки(:-). Не хочу никого обидеть, ответа я не заметил. Можете привести конкретный пример из вашей практики, или два, чтобы прочувствовать, как много надо было бы писать, переходя с проекта на проект, не имея готовую ОС под рукой?


Вопрос "куда катится мир?" был задан именно о применении ОС в микроконтроллерах, а не в общефилософском смысле. Все и так знают, что мир катится к гибели(:-(. Каждый день.


Я нигде не видел похожего, пришлось придумывать самому. Да и ничего там сложного не было. По сравнению с применением Осей(:-). Подробнее чуть ниже.


Вы как-то туманно выражаетесь(:-), мне бы поузить...
Идея заключалась в разбиении всех процессов на регулярные и нерегулярные части, регулярные части присутствовали в каждом фрагменте, нерегулярные – только в одном или нескольких фрагментах, и каждая часть самостоятельно решала, кому отдать управление в следующем фрейме. В моем случае все фрагменты удалось привести к единой временной базе в 800 МЦ, хотя можно сделать и на переменной базе. Зависит от задачи. Виртуального пива нам пока хватит с того проекта, я вам там довел дело до 8 МЦ, а вы куда-то пропали…Решили, видимо, ограничить виртуальные пивные расходы(:-).


Чёт я не понял, это камень в чей огород(:-)? Если в мой, то я не собираюсь никого учить, кто бы меня научил, что правильно, а что нет. Приходится до всего доходить своим умом, иногда ум заходит за разум, становится совсем не виден(:-).

Вторая часть вашего поста весьма примечательна. Низ-зя программить инженерам-электрикам? А кому можно? У кого есть сертификат? У меня есть, выдан Тексас Инструментом, учился в ихнем филиале в Нортхемптоне. Но не вижу никакого криминала(:-), если кто-то, не имея никакого сертификата и зная больше меня в данной области, покажет мне (и остальным участникам форума), как программить, новые приемы, нестандартное решение проблемы...

По поводу сертификатов: Наличие прав на управление автомобилем вовсе не означает умения это делать!

=GM=, поскольку Вы обременены вопросом "как бы ОС поюзить", то она Вам не нужна . А когда нужна будет - тогда юзать и будете.)

Один пример - в системе будут четыре задачи , одна задача постоянно выполняется но может прерываться, вторая задача сродни первой , третья и четвертая задачи требует быстрого реагирования на события , которые нельзя реализовать в прерываниях из-за длительности выполнения, так как вложенные прерывания могут привести к переполнению стека. Можно ли это ЛЕГКО сделать без применения ртосоподобного подхода?

to pitt По поводу прав на управление автомобилем. Тут вы в корне неправы, наличие прав на управление как раз и означает, что владелец может управлять автомобилем в приемлемых для государства рамках, и государство официально подтверждает его умение.

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

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

Ну не так сильно "обременён", как вам кажется, это сильно сказано! Кстати, так уже говорили, не повторяйтесь. Если она мне пока не нужна, почему я не могу к ней подступиться прямо сейчас? Может быть, это как раз начало моей нужды в ОС, почём знать? Должен я держать нос по ветру, э(:-)?

Если под быстрым реагированием вы имеете в виду выставление прерыванием флага события, чтобы потом ОС могла передать управление соответствующей программе, то ДА, это можно ЛЕГКО сделать без применения ОС. И даже в прерывании. И с помощью ОС этого нельзя сделать быстрее, можно только замедлить в два-три раза. Увы.

Я хочу понять, какие преимущества дает карманная ОС, или это фикция, дань моде?

Порты в контексте ОС это не GPIO. Это вся имеющаяся периферия.


задачка-пример:
В процессе выполнения некоторых чередующихся сложных функций - зажечь и потушить через определенное время любую комбинацию из 10 светодиодов. Функции задержки применять нельзя.

Дополнительное условие задачи - программа без существенных изменений структуры должна поддерживать работу с индикатором (из тех же 10-ти светодиодов) через UART/SPI/I2C.

А что если при прерывании предназначенном для задачи номер 3 или 4 , работает задача номер 1 или 2? Вы то после прерывания не вытесняете медленную задачу 1 или 2 и она продолжает работать как и обычно до прерывания.

П.С. Не смотрел что пишут другие , не люблю плагиат.)

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

Давайте.

2GM: не обижайтесь, но Вы просто не доросли до уровня понимания понимания данной темы...

Я вот тоже раньше не понимал зачем нужны простейшие тригонометрический функций (sin, cos, tg), пока не столкнулся в плотную с механикой в институте... теперь понял) а до этого никак.

Про порты вы сказали "порты I/O", а сейчас говорите "Порты это не GPIO, а вся имеющаяся периферия". Где правильно?

Вот пример - это уже ближе к делу. Зажечь и потушить через определенное время любую комбинацию из 10 светодиодов на фоне сложных функций - это не просто, а очень просто, менее 30 МЦ в прерывании! Здесь ОС просто не нужна. Без нее будет быстрее и ресурсов будет потребляться меньше! Также и в отношении работы с индикатором через UART/SPI/I2C. Не видно преимущества применения ОС, хотя, возможно, был выбран неудачный пример?

Да, просто пример неудачный. Единственно доступный для понимания вариант - пользовать чужие программы в своих устройствах. Как на писюке. Или свои в своих ;О)... В обчем, именно туда мир и катицца. И, получается, именно там ему и место. ;О)

Отвечу скопом(:-)

Хорошо, вы меня уговорили. Порекомендуйте “ось какую-нить” достойную по-вашему мнению к изучению, я посмотрю и тогда, может быть, вернемся к теме необходимости использования ОС в МК. Пока я не вижу “разов” даже на пальцах(:-).


1) Да желаю я, же-ла-ю. Пока только один defunct привел пример, крайне неудачный на мой взгляд, который работает скорее против ОС, чем за.
2) И не оппонирую я, задал простой вопрос, на который пока не получил внятного ответа, только отписки для галочки(:-). Вопрос-то простой.


Думаю, что легче, чем с ОС или РТОС. Почему-то все думают, что программирование начинается с написания строчек кода, а заканчивается, когда транслятор не выдал ошибок трансляции. Также все почему-то думают, что применение модной “миниОС” в микроконтроллере автоматически решит все их проблемы. Не решит, а добавит! По крайней мере, абсолютно точно в плане быстродействия.


Может не дорос, а может и перерос уже(:-). Вы тоже не обижайтесь, как вы определяете, кто дорос, а кто нет? Как у вас было с ОС, вы утром встали, позавтракали, пришли на работу и внедрили ОС? Не сомневаясь, ни с кем не обсуждая, так?

Прекрасно, рад за вас, серъезно. Мне в этом плане было легче. В свое время я считал и функции Бесселя сотого порядка и простые и модифицированные (и Неймана и Ханкеля тоже), и бесконечные ряды Пуассона доводилось, я уж не говорю про учет поправок между географической и сферической системой координат...Как сказал поэт: “все было брат со мной на этом белом свете и ездил я к одной на велосипеде”. Только вот все сказанное никакого отношения к теме не имеет(:-(.


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

Но может все ж таки есть рациональное зерно в применении ОС? Наши оппоненты умнейшие люди, они ОС применяют without flinching так сказать, значит должно быть рациональное объяснение.

Голословность утверждения не является аргуметном в дискуссии. Было бы интересно увидеть функциональный алгоритм в вашем изложении В моем изложении это будет так

[censored]
>> на который пока не получил внятного ответа
Вам ответили несколько раз, внятно и доступно.

>> Думаю, что легче, чем с ОС или РТОС
Не легче. Если у вас в основной задаче будет работать библиотечная функция (sprintf, например), а среагировать и запустить другую задачу нужно очень быстро, но нельзя этого делать в прерывании (ОЗУ мало) - как вы выкрутитесь инетересно?

>> По крайней мере, абсолютно точно в плане быстродействия.
Вот это уже точно от недопонимания...

>> своей программы в своем устройстве
Вам похоже никогда не приходилось работать в команде или с "наследством" другого программиста

[censored]

I/O = Ввод/Вывод.
Любая периферия с т.з. ОС(и процессора) работает по принципу Ввод/Вывод через порты. Неужели вы не в курсе? У AVR есть даже специальная область в начале памяти зарезервированная под I/O.


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

ЗЫ: А что за еденица измерения такая "МЦ"?

Шутите? А я думал, что процессор всё делает через РЕГИСТРЫ портов И периферии(:-). Чуть более серьезно, таймер это порт или периферия?

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


МЦ - машинный цикл, неужели вы не в курсе(:-)?

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


Нет ,я Вам там после вашего поста, поставил три пива,но похоже Вы не успели ,модераторы "выпили",
я расплакался,обиделся и ушел.

Уважаемый, =GM=!
Второй день наблюдаю, как Вы пытаетесь объяснить в общем-то очевидные вещи. Меня всегда поражали инфантильные надежды некоторых разработчиков, что некий добрый дядя сделает за них черновую работу в виде карманной ОС, а им, таким умным и продвинутым, останется только написАть свою гениальную программу из трех строчек на С. Не будет этого. Если хочешь, чтобы все работало и успевало в свое время, надо потрудиться самому.
Теперь ряд вопросов по-существу.
1. В одном из постов в этой теме Вы упомянули про процессы. Что Вы подразумеваете под этим термином?
2. Что такое джиттер в Вашем определении и почему нельзя применять прерывания?
3. Вы обещали поделиться сутью Вашей методологии. Хотелось бы все-таки дойти до ее рассмотрения по существу и сравнить с моей собственной.
Со своей стороны обещаю рассказать Вам о своих наработках в этой области.
Правда, думаю, здесь это вряд ли кому будет интересно... К сожалению.

Таймер это устройство с регистрами которого проц общается как с памятью, замапленную в область I/O портов.


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

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

Думаю, вы непрально поняли движущие силы объекта своего наблюдения. ;О) =GM= пытаецца просто получить от кого-нить осознанный ответ о пользе и выгоде применения ОС в эмбеддед приложениях вообще, и в мелких МК, в частности. Ну и в желании поговорить на вполне приличную тему с умными людьми. Гениальную программу из 3 строчек, уверен, он сможет написать самостоятельно. ;О) И, судя по моим двухдневным наблюдениям, без ОС.

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

А-а-а!!! Большой брат наблюдает! (С)Оруэл,1984(:-) Ну и ладно!

Это какие же? Я пытаюсь получить ответ на свой вопрос, только и всего. Попутно идет треп, но перефразируя Капицу, спрошу, можно ли прожить без трёпа (Он говорил: без бездельников не проживёшь)?

Ответы по существу.
1) Трудно объяснмть в двух словах. Возможно даже, что я неправильно употребляю термин. Процесс - это что-то относительно независимое, законченное и регулярное. Скажем подготовка нескольких байт в буфере и запуск прерывания на передачу - это процесс. Чтение датчика температуры по протоколу и2с - тоже процесс. Дрыгание ногой порта ввода вывода в определенном порядке тоже можно отнести к процессу. Хотя есть спорные моменты. Надеюсь, вы поняли, что я имею в виду.

2) В той задаче, о которой я упоминал, мне надо было сформировать три последовательности, 10 кГц, 5 кГц и свинутые 5 кГц. Причем так, временные соотношения между первыми двумя фиксированы, а третья последовательность может гулять динамически, т.е. фазовые соотношения меняются программно. Ну поскольку частоты низкие, казалось можно было сделать с помощью прерывания. Однако как вы знаете, прерывание может возникнуть во время выполнения длинной команды 2-3-4 такта, и прерывание обязано ждать завершения данной команды, из-за этого получалось небольшое подрагивание последовательностей, которое мы назвали джиттером. На самом деле природа джиттера может быть и другая, но назвали так, как назвали...В связи с джиттером пришлось отказаться от прерываний вообще, поскольку наша двухканальная следящая система оказалась чувствительной к джиттеру, увы. Кстати, можно было бы решить проблему аппаратно, добавив пару триггеров, но наш электронщик категорически отказался, увеличивается стоимость системы, понимаешь...

3) Сути методологии по существу никакой нет, как я сейчас понимаю. Вся программа была разбита на 800-цикловые фрагменты (всего 11 типов), которые обеспечивали программное изменение двух фиксированных последовательностей, третья формировалась аппаратно с помощью блока сравнения МК. Остальные процессы встраивались по мере необходимости внутрь этих фрагментов. Их много, скажу про самые крупные: измерение разностной частоты 0.5-1.6 Мгц, измерение температуры, вычисление крутящего термокомпенсированного момента, выдача результата измерений на ЦАП и в последовательный интерфейс, мониторинг захвата по двум каналов...ну и так по мелочи еще кое-что. Основной цикл программы - 1200 мкс. Без джиттера, голый процессор.

Как это делалось. Для передачи управления использовался регистр Z (регистровая пара r31,r30) и косвенный переход ijmp. Ничего супер-пупер, но быстро и эффективно передается управление любому фрагменту из любого фрагмента, для отладки было удобно зацикливать один фрагмент и смотреть, что он делает...Структура фрагментов выглядела примерно так, как показано ниже. Естественно, принятие решений в каждом фрагменте осуществлялось индивидуально.

Код

loop_i:
<формирование последовательности 1>
<выполнение задачи j>
<формирование последовательности 2>
<формирование последовательности 3>
<выполнение задачи j+1>
<формирование последовательности 2>
<формирование последовательности 3>
<мониторинг захвата канала 1>
<мониторинг захвата канала 2>
<программная задержка для достижения 800МЦ>
<принятие решения о передаче или непередаче управления, например так>
eolock: subi   frcnt0,1
        sbci   frcnt1,0
        brcc   noend3
        ldi    frcnt1,high(locktim);
        ldi    frcnt0,low(locktim) ;
        ldi    fradr1,high(loop1)  ;
        ldi    fradr0,low(loop1)   ;
        cbi    portd,6             ;enable is not active(0)
        ldi    temp1,0xB0          ;disable states
        out    porta,temp1
<здесь принято решение о переходе на фрагмент loop1>
        ijmp                       ;completion of loop2
<а здесь принято решение остаться на фрагменте loop2>
noend3: ijmp                       ;continue loop2

Нормальный пример rtosless изврашения )

Ну вы сказанули! Вы что же, с таймером общаетесь, как с памятью, через LD и ST команды? А я думал, что проще общаться с таймером, как с устройством ввода-вывода, через команды IN и OUT(:-). Как видите не всё так просто. Итак, что же такое таймер? Вернее, его точное определение.


Ну, hang on, вы же разумный человек. Людям надо помогать, это по-христиански. Если всем будет хорошо, то и вам будет хорошо. Скажу больше, бескорыстно помогая людям, вы получите много положительного, поверьте. Будет хорошо на душе.

Ну вы как-то чересчур прямолинейно. Зачем тогда на форуме участвуете? Вот братья Гонкуры говорили, что людьми движут три вещи: любовь, корысть, тщеславие (в порядке возрастания).
Что касается конкретно меня, то мне и так хорошо, без ОС(:-), но разобраться не помешает, э? Примите во внимание, что есть ещё и другие программисты, начинающие и не очень, лично я не прочь с ними поделиться, с собой все не унесешь, и лишний кошелек к гробу не прибьешь, знаете ли. Ладно, закончу на этом, а то так мы с вами дойдем до выяснения гносеологических корней альтруизма.

Ну не хуже, чем с флагами и семафорами. По крайней мере без задержек и проволочек. И побыстрее, чем с любой микроОС(:-).

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

Профи artem, как бы вы стали решать подобную задачу на основе ртос?

Во первых , Вы куда то спешите? Вас так стесняют семафоры ? Или нельзя найти микро побыстрее ? Так ли дорого стоят ?А то что данную программу на ртос можно написать намного быстрее, с меньшим количеством ошибок и с намного более читабельным кодом наверно не будем обсуждать. Я понимаю что можно в какой то мере удовлетворить свое честолюбие затратив определенное время на разработку более быстрого кода по сравнению с ртос.Зато работаюшим с ртос достанется больше свободного времени для лицезрения вашего трудопроцесса над тем же заданием.
(Сказанное наверху не означает что ртос должен применяться для всех задач.)
Во вторых - я не профи.
В третьих - свое изложение написал наверху. Вы то не удосужились на него ответить.

како-то злой форум стал в последнее время это уже не первая тема, в которой вместо конкретных ответов по существу народ пишет многозначительные абстрактные посты, а потом каждый важно достает их широких штанин дроссель и начинает сравнивать его с соседским
по поводу осей. ось нужна для того, чтоб не зацикливаться на реализации ф-ий планировщика, синхронизации, таймеров и т.д. при этом ось обязательно отъедает ресурсы и процессорное время, поэтому применять ее можно только тогда, когда ресурсов проца больше, чем на самом деле требуется.
кроме того, как уже было сказано, ось полезна при работе в команде.
а еще полезно иметь ось для реализации стеков разных протоколов: TCP/IP, USB, IRDA - это все уже написано. и с появлением чего-то нового достаточно будет подлинковать соответствующий модуль - и радоваться жизни.
имхо можно посидеть месяцок-другой и наваять собственную операционку. но тогда возникает вопрос "зачем"? я не говорю. что операционка - самый лучший, быстрый и компактный вариант. это просто самый униврсальный вариант, имеющий все плюсы и минусы любого другого универсального варианта.

Ну...программа для устройства пишется один раз. На всю оставшуюся жизнь. Устройства, разумеется.
Негрешно потратить на это некоторое время. ненамного бОльшее. А то и меньшее. Устройство будет работать, а сколько на него потратили времени, забудут через неделю. Спешка нужна, как говаривал классик, в другом месте. ;О)

2 mse, это зависит от специфики задачи, поэтому в контексте ртос или же ее игнорирования надо разделить круг задач где ее применение будет оправданным.

GM>> на который пока не получил внятного ответа
Alex B.>> Вам ответили несколько раз, внятно и доступно.
Где это, неужто пропустил? И внятно, и доступно? Ткните носом, пожалуйста.

GM>> Думаю, что легче, чем с ОС или РТОС
Alex B.>> Не легче. Если у вас в основной задаче будет работать библиотечная функция (sprintf, например), а среагировать и запустить другую задачу нужно очень быстро, но нельзя этого делать в прерывании (ОЗУ мало) - как вы выкрутитесь интересно?

Вы какие-то страшные вещи говорите. С ОС можно выкрутиться, а без ОС ну никак нельзя! Что за чушь!? Ну и как ВЫ запустите "другую задачу очень быстро" с помощью ОС, если нельзя делать в прерывании?

GM>> По крайней мере, абсолютно точно в плане быстродействия.
Alex B.>> Вот это уже точно от недопонимания...
Недопонимания чего? Вы же не будете отрицать, что ОС занимает какую-то часть производительности процессора 1-10-20(?)%, это факт. Следовательно, меньше производительности отводится другим, полезным, процессам, следовательно быстродействие уменьшается.

GM>> своей программы в своем устройстве
Alex B.>> Вам похоже никогда не приходилось работать в команде или с "наследством" другого программиста
Приходилось-приходилось, и не раз. Бардака и раньше хватало, и сейчас тоже хватает (на команду из 6 человек). Мы же не об этом говорим, а о применении ОС. Наверное у вас очень сложный алгоритм, вы получили его в наследство и даже не знаете, как оно там все работает(:-). На моей памяти был только один сложный пример софта - ПО станции спутниковой связи "Волна-СА", 30 кбайт ассемблерного кода для 8080, написанного командой из 30 девушек-программисток, если вы конечно понимаете о чем я говорю(:-).



О, mse, прямо в точку! А какой классик говорил? А я знаю три случая спешки.

Похоже, что ничего конструктивного здесь не появится.
На этом и закончим.