nanoKernel for the AT90S1200, Зачем это надо в принципе? Опции

[=GM=]

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

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

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

[defunct]

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

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

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

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

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

[=GM=]

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

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

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

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

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

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

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

[defunct]

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

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

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

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

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

[=GM=]

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

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

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

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

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

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

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

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

[Прохожий]

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

[=GM=]

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

Уважаемый, =GM=!
Второй день наблюдаю, как Вы пытаетесь объяснить в общем-то очевидные вещи.

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

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

Ответы по существу.
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

[_artem_]

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

Уважаемый, =GM=!
Второй день наблюдаю, как Вы пытаетесь объяснить в общем-то очевидные вещи.

Код

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 изврашения )