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, это зависит от специфики задачи, поэтому в контексте ртос или же ее игнорирования надо разделить круг задач где ее применение будет оправданным.