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

[=GM=]

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

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

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

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

[_artem_]

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

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

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

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

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

[mse]

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

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