[klen 1]

че за базар?

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

я книгу пишу по GNU tools for ARM, часть текста будет "как я перевел из ...." и примеры не все мною будут писаны! и че теперь я плагиатор?

цель - дать информацию в нужном виде для решения поставленной задачи

[Petka 0]

че за базар?

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

я книгу пишу по GNU tools for ARM, часть текста будет "как я перевел из ...." и примеры не все мною будут писаны! и че теперь я плагиатор?

цель - дать информацию в нужном виде для решения поставленной задачи

Спокуха. Вы же ссылки не забудете сделать? Есть ссылка - это уже не плагиат а цитата =) Ссылки нужны ещё для того, если возникнут вопросы, можно было заглянуть в первоисточник и узнать ошибка возникла в процессе перевода или так и задумано было...

[ReAl 0]

Спокуха. Вы же ссылки не забудете сделать? Есть ссылка - это уже не плагиат а цитата =) Ссылки нужны ещё для того, если возникнут вопросы, можно было заглянуть в первоисточник и узнать ошибка возникла в процессе перевода или так и задумано было...

+1

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

 

Ну а по сути предложенных исходников

 

Мелочи, но сильно затрудняющие чтение - "исходные исходники" отформатированы так, как будто кто-то вставил цитату в форум без тега code. Понятно, что это исправляет один вызов indent или пара тыков в редакторе, но... "осадок остался"

А портированные на avr-gcc (с которых я начал) изобилуют маслом масляным комментариями вида

mRTOS_Tasks[mRTOS_InitTasksCounter].CurrentPriority = Priority; // установить текущий приоритет задачи

что тоже только затрудняет чтение.

 

Никак не могу понять смысла сохранения статусного регистра при синхронном переключении. Всё равно никакой компилятор не ждёт, что после возврата из любой функции (а не только кооперативного переключения) статусный регистр будет тот же, что и перед вызовом.

 

Ну и - это уже касается порта avr-gcc - обёртки ATOMIC_BLOCK(ATOMIC_RESTORESTATE) всё равно напрочь затирают сохранённое в блоке задачи и восстановленное значение тем, которое "получили в наследство" от той задачи, с которой идёт переключение. Тот, кто портировал - мог бы это и заметить и вместе с автором оси задуматься над смыслом проделываемых операций.

 

Хитрая хитрость с "приоритетами"... Что это даёт?

Пусть есть четыре задачи(с приоритетами)

A(10) B(3) C(3) В(3)

Тогда, при условии, что все задачи что-то молотят, не переходят в ожидание, вызовы будут идти так

AAAAAAABCDABCDABCD

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

Если "приоритет", означает "суммарное время, отданное задаче", то зачем так сложно?

А если

Чем больше это число, тем чаще будет переходить управление к этой задаче

втрое более высокий приоритет означает более выскоую частоту вызова, то задача решена в объёме средней температуры по больнице.

К примеру, сначала AAAAAAA просто тупо прокуртится в if( !flag ) DISPATCH; а потом флаг взведётся, но сначала выполнятся все низкоприоритетные, и только потом вернётся управление к А, она не будет вызываться чаще на этом участке.

Тут бы

ABACADABACADABACADA

но это требует совсем другого подхода.

 

А в таком виде, как оно есть, на мой взгляд, не имеет смысла. Только ОЗУ и код даром выброшены.

[oll 0]

Может "ОЗУ и код даром выброшены", но мне эта ос оказалась по силам для понимания (ну тупой - scmRTOS не осилил).

Показалось что удобно:

в одной задаче обслуживается семисегментный индикатор, в другой кнопки, в третей энкодер, в четвертой тиристор, в пятой шим для полевика и все это на одном таймере (остальные заняты). Может можно было и по другому сделать, но с использованием mRTOS получилось наглядно и главное работает. Использовал Кодевижн, хотя пробовал и GCC.

 

Да еще вопрос автору - в старых версиях Кодевижена почему-то не удалось запустить, только в версии 2.хх.

Изменено 1 ноября, 2009 пользователем oll

[sensor_ua 0]

и все это на одном таймере

для чего этот таймер использовали?

[LVII 0]

Хитрая хитрость с "приоритетами"... Что это даёт?

Пусть есть четыре задачи(с приоритетами)

A(10) B(3) C(3) D(3)

Тогда, при условии, что все задачи что-то молотят, не переходят в ожидание, вызовы будут идти так

AAAAAAABCDABCDABCD

 

Не совсем так, точнее совсем не так. В документации нарисован алгоритм переключения. Он прост, но не до такой степени.

Будет так - ABACADABACADABACAD....... - именно когда все молотят. Т.е. задача А получит в три раза больше времени.

Проверьте в AVR Studio. Это просто.

 

Сохранение статусного регистра позволяет произвести анализ состояния, которое было до выхода из процесса.

Существует такая необходимость.

[ReAl 0]

Может "ОЗУ и код даром выброшены", но мне эта ос оказалась по силам для понимания (ну тупой - scmRTOS не осилил).

Причём тут это? Я где-то хоть слово сказал про то, что обсуждаемая ОС фигня, потому что не вытесняющая?

ОЗУ и код даром выброшены на вещи абсолютно не нужные (сохранение SREG в невытеснялке) и в данном исполнении при анализе на худший случай бесполезные ("кагбе" приоритеты)

 

Показалось что удобно:

в одной задаче обслуживается семисегментный индикатор, в другой кнопки, в третей энкодер, в четвертой тиристор, в пятой шим для полевика и все это на одном таймере (остальные заняты). Может можно было и по другому сделать, но с использованием mRTOS получилось наглядно и главное работает.

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

Возможно, всего два приоритета - "высокий" и "низкий" - два массива задач, задачи из второго вызываются по одной по очереди после полного прокрута первого массива - было бы ничем не хуже, ОЗУ было бы потрачено меньше, кода тоже, переключение быстрее.

А может и одного массива хватило бы, искать тех, кто дождался события (точно так же, как это сделано сейчас), при отсутствиии таковых продолжать топать по кругу по массиву.

 

Будет так - ABACADABACADABACAD....... - именно когда все молотят.

Проверьте в AVR Studio. Это просто.

Хм. Я просто смотрел код. Может чего недосмотрел, гляну позже ещё.

 

Сохранение статусного регистра позволяет произвести анализ состояния, которое было до выхода из процесса.

Существует такая необходимость.

Например?

[LVII 0]

Да еще вопрос автору - в старых версиях Кодевижена почему-то не удалось запустить, только в версии 2.хх.

 

Странно. Разрабатывалась на версии 1.25.3.

И еще человек 5 работают в 1-ой версии.

Я конечно проверил и на 2-ой версии, тоже было все хорошо.

Но сам до сих пор сам сижу на 1.25.9.

[haker_fox 61]

я книгу пишу по GNU tools for ARM, часть текста будет "как я перевел из ...." и примеры не все мною будут писаны! и че теперь я плагиатор?

Для исключения подобного рода недоразумений, должны быть обязательно ссылки на первоисточник!

[ReAl 0]

Я просто смотрел код. Может чего недосмотрел, гляну позже ещё.

Да, пропустил с наскоку то, что текущая задача на время поиска следующей принудительно переводится в suspend а после поиска назад в active.

 

Поскольку таки не в avr studio, а глазками по исходнику ходил - по дороге заметил, что

        // Поиск задач в состоянии задержки.
        if (!tasks[i_shed].delay && tasks[i_shed].st == Wait) {
            pri = tasks[i_shed].current_pri;

.delay анализируется без запрета прерываний и без явного специального порядка чтения старшего-младшего байта. Могут быть глюки.

Вроде бы ж я не пропустил нигде cli, хоть уже и почти три часа ночи :)

 

Кстати, мелочь, но в среднем

        if (tasks[i_shed].st == Wait && tasks[i_shed].delay == 0)  {

будет отрабатывать быстрее (даже если забыть на время про неатомарность доступа к delay), так как для не-ожидающих задач не будет зря зачитываться и проверяться delay. Да и логика понятнее -

если задача ожидает - то посмотрим, не пора ли её по таймеру проснуться

а не

если таймер занулился - то надо ещё глянуть, важно ли это

Аналогично с поиском по приоритету - да какая разница какой он, если задача не в active

 

Например?

А вот для чего может быть нужно сохранять статусный регистр процессора при переключении задач в кооперативной ОС - всё таки хотелось бы услышать. Тем более, что в avr-gcc варианте он восстанавливается.

[oll 0]

для чего этот таймер использовали?

Это я про системный таймер 0.

 

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

Я только за, просто хотел сказать, что использовал эту ОС как есть и меня это устраивает. Буду рад если Вы поможете автору усовершенствовать его ОС.

Это моя первая проба ОС. Исходник не изучал - попробовал пример. До этого делал без ОС - динамическая индикация на прерывании таймер 0, знкодер на int 0, кнопки в общем цикле. С ОС приоритет индикатора самый высокий, далее энкодер, потом кнопки и прочее. Знкодер используется без int 0 - пропусков нет, индикатор не мигает.

Хотелось бы, чтобы из одной задачи можно было остановить другую - типа STOP(N)

[_Pasha 0]

С ОС приоритет индикатора самый высокий, далее энкодер, потом кнопки и прочее. Знкодер используется без int 0 - пропусков нет, индикатор не мигает.

Это же совсем простая программа. А как быть, если одну из задач нагрузить на 1-WIRE ? ;)

[oll 0]

Это же совсем простая программа. А как быть, если одну из задач нагрузить на 1-WIRE ? ;)

Согласен - 1-WIRE трудновато. У меня там используется KTY. Придется поставить дополнительную Tiny13 (шутка).

Кстати, это из другой темы (к ОС не имеет отношения), может подскажете, для 1-WIRE :

есть прерывания для обслуживания 7-сегментного индикатора,

есть датчик DS18B20,

для 1-WIRE нужны точные временные интервалы (задаю delay_us()),

прерывания делают временные интервалы непредсказуемыми,

как Вы решили бы подобную проблему?

[MrYuran 29]

для 1-WIRE нужны точные временные интервалы (задаю delay_us()),

прерывания делают временные интервалы непредсказуемыми,

как Вы решили бы подобную проблему?

Там критично только начало слота, первые 10-20 мкс.

На это время прерывания можно и отключить. А окончание слота довольно расплывчатое, там лишний десяток мкс роли не играет.

Если, конечно, в прерывании не стоит delay_us(), или ещё круче, delay_ms()

 

А если есть лишний УАРТ - то на него повесить - святое дело. И забыть микросекунды, как страшный сон.

[_Pasha 0]

как Вы решили бы подобную проблему?

1. Миллисекундные задержки строгому контролю не подлежат.

2. Для микросекундных помещаю текст приема /передачи бита в ATOMIC_BLOCK(ATOMIC_RESTORESTATE)

3. После отработки одного бита не спешу переходить к следующему - вызываю idle() или отдаю управление, если использую protothread-подобную организацию сопрограмм, итд итп.

 

MrYuran: "А окончание слота довольно расплывчатое" - кстати да, это тоже за пределы ATOMIC_BLOCK выносится.