Вопросы по OSA

[CERGEI1982]

Сообщение от tester

Примеры даны отдельно в разделе примеры: http://wiki.pic24.ru/doku.php/osa/ref/intro

Я понимаю,просто посмотрел что там идет увеличение сложности программы тестовых проектов и решил по ним научится,а не братся за проект,где есть все функции(задержки,таймеры,сообщения,приоритеты) думаю у меня в голове каша будет,а так потихоньку,пускай они даже и не совсем рабочие тем лучше,буду знать где и как сделать рабочими.Позже хочу собрать вот этот ваш проектик http://pickit2.ru/doku.php/%D0%BF%D1...B3%D0%BD%D0%B8

[CERGEI1982]

Сообщение от tester

Это правильно.

По твоему примеру:
Сразу бросилась в глаза ошибка: переменная c из задачи Task1 не объявлена как static. А через очередь передается указатель на нее. Переменные, значения которых должно быть сохранено после передачи управления планировщику должны быть объявлены как static, иначе их значение затрется локальными переменными других задач (обрати внимание, что msg1, msg2 и msg3 располагаются по одному адресу, потому что они локальные). Похоже, что по адресу 203 расположена как раз переменная c, запись в нее перетирает локальную переменную data.

Точно,до самого не дошло,ведь такая же проблема была у меня с переменой count.
Сделал переменую статической и теперь получаю в массив mas с запаздывание,то есть в задаче №1 она успела увеличится на 2,когда мне надо на каждое увеличение.Получается функция обработки сообщения OS_Queue_Wait(queue, msg2); в задаче №2 получает переменую в два раза дольше,чем отправляет задача №1 OS_Queue_Send(queue,&b); ?

[tester]

Сообщение от CERGEI1982

Точно,до самого не дошло,ведь такая же проблема была у меня с переменой count.
Сделал переменую статической и теперь получаю в массив mas с запаздывание,то есть в задаче №1 она успела увеличится на 2,когда мне надо на каждое увеличение.Получается функция обработки сообщения OS_Queue_Wait(queue, msg2); в задаче №2 получает переменую в два раза дольше,чем отправляет задача №1 OS_Queue_Send(queue,&b); ?

Это связано с тем, что при равноприоритетности задач Task1 и Task2 контекст переключается во второй задаче в два раза чеще, чем в первой, (один раз через OS_Yield, а второй - через OS_Queue_Wait). В принципе, это не страшно, т.к. когда выделенный буфер под очередь забьется, задача Task1 будет сама становиться в ожидание появления свободной ячейки в очереди.

Если принципиально, чтобы сообщения принимались синхронно с передачей, то нужно сделать приоритет задачи Task2 выше, чем у Task1.

[CERGEI1982]

Сообщение от tester

Переменая queue.Q.cBegin увеличивается на 1, а queue.Q.cFilled уменьшается на 1. Сам массив buf при этом остается неизменным.

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

[tester]

Сообщение от CERGEI1982

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

Первый вошел - первый вышел, поэтому и две переменные (это не стек, а очередь). Если бы принцип был первый вошел - последний вышел (типа стека), то можно было бы обойтись и одной переменной.

[tester]

Наконец, благодаря активной помощи tehnosoft, Mario и vitalka, за что им огромне СПАСИБО, удалось локализовать место и причину незапуска программы. А именно - отсутствие файла msflxgrd.ocx с описанием ActiveX-компонента (сам я в этом мало понимаю, но этот файл нужно зарегистрировать в системе через regsvr32, чтобы программа заработала).

Вот установочный файл, который сам делает регистрацию компонента (он там же) и устанавливает программу на компьютер:
http://wiki.pic24.ru/lib/exe/fetch.p...ro&cache=cache

(Я установщиком пользуюсь впервые, поэтому он выглядит пока немного коряво. Буду приводить его в порядок со временем).

[CERGEI1982]

Посмотрел алгоритм кода проекта "Бегущие огни" на ОСРВ
http://pickit2.ru/doku.php/%D0%BF%D1...B3%D0%BD%D0%B8
никогда бы так не смог сообразить,особенно програмнный шим,на выходных обязательно испробую в железе и если будет время дополню что будет скорость сама увеличиватся и уменьшатся,думая кнопочка лишняя и заодно испробую новый сервис OS_Run.

[CERGEI1982]

В описании OSA есть скоростные характеристики,так вот время реакции события измеряется в тактах микропроцессора?
И как понять среднее время поиска задачи для выполнения. (Вычисляется как среднее за 10000 вызовов OS_Sched())?

[tester]

Сообщение от CERGEI1982

В описании OSA есть скоростные характеристики,так вот время реакции события измеряется в тактах микропроцессора?
И как понять среднее время поиска задачи для выполнения. (Вычисляется как среднее за 10000 вызовов OS_Sched())?

Для информации: тесты по скорости проводились на тестовой программе TEST9 (она есть в папке TEST).

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

"Время работы OS_Sched" - среденее время (в тактах контроллера), затрачиваемое ядром ОС на поиск самой приоритетной готовой задачи. Если одна задача передает управление планировщику (например, через OS_Yield), то седующая задача получит управление через некоторое время (то самое, в течение которого планировщик будет ее искать).

Это время варьируется от раза к разу и зависит от многих факторов:
- количества активных (созданных) задач (чем больше здач, тем дольше выполняется OS_Sched; примерно 60-80 тактов на задачу);
- включен или отключен приоритетный режим;
- как расставлены приоритеты: в описании сделана ремарка про ускорние работы ядра за счет присваивания задачам высшего (нулевого) приоритета;
- состояний задач (приведены в порядке увеличения времени обработки): "не создана", "приостановлена", "готова", "в ожидании события";
- типа ожидаемого события (в порядке увеличения времени): выполнение задержки OS_Delay, ожидание семафора или сообщения, ожидание произвольного условия;

Точно сказать, сколько времени выполнится поиск (время работ OS_Sched), нельзя, т.к. задачи то готовы, то ожидают, то готовы, но еще не имеют высший приоритет и т.д. Поэтому и берется среднее время за 10 тыс. переключений контекста (вызовов планировщика).

[KeMik]

Здравствуйте! Решил начать освоение OSA. У меня проект на PIC16F689. Почитал что OSA pic16 поддерживает. Скачал с сайта wiki.pic24.ru саму ось и мануал по ней. Запустил MPLAB прописал её как сказано в мануале.
и в итоге компилятор у меня выдал ошибку:

HI-TECH C PRO for the PIC10/12/16 MCU family V9.60PL3
Copyright (C) 1984-2008 HI-TECH SOFTWARE
licensed for evaluation purposes only
this licence will expire on Fri, 14 Dec 2029
Error [237] D:\Docs & Manuals\OSA\osa_90406\OSA\port\osa_picc16.c; 440. function "__OS_Task_Create" redefined
Error [237] D:\Docs & Manuals\OSA\osa_90406\OSA\port\osa_picc16.c; 563. function "__OS_CheckEvent" redefined
Error [237] D:\Docs & Manuals\OSA\osa_90406\OSA\osa.c; 749. function "_OS_Init" redefined

Из ошибки видно что пользуюсь я компилятором HI-TECH PRO V9.60.
перешёл по вой ошибке и действительно:

#define _OS_Task_Create_DEFINED
//------------------------------------------------------------------------------

void _OS_Task_Create(_OST_INT_TYPE priority, OST_CODE_POINTER TaskAddr)
{ ...

По второй тоже самое:

#define _OS_CheckEvent_DEFINED
//------------------------------------------------------------------------------

bit _OS_CheckEvent (char bEvent)
{ ...

Третью я вообще не понял. Скажите что я не так сделал или понял?

[tester]

Сообщение от KeMik

Здравствуйте! Решил начать освоение OSA. У меня проект на PIC16F689. Почитал что OSA pic16 поддерживает. Скачал с сайта wiki.pic24.ru саму ось и мануал по ней. Запустил MPLAB прописал её как сказано в мануале.
и в итоге компилятор у меня выдал ошибку:

Из ошибки видно что пользуюсь я компилятором HI-TECH PRO V9.60.
перешёл по вой ошибке и действительно:
По второй тоже самое:
Третью я вообще не понял. Скажите что я не так сделал или понял?

OSA пока что не работает с PRO-версиями компиляторов, поддерживаются только STD (http://wiki.pic24.ru/doku.php/osa/ref/introduction/intro#поддерживаемые_компиляторы)

Если и удастся запустить ее под ПРО, то только не младше версии 9.65 (пока не удается).

[KeMik]

Сообщение от tester

OSA пока что не работает с PRO-версиями компиляторов, поддерживаются только STD (http://wiki.pic24.ru/doku.php/osa/ref/introduction/intro#поддерживаемые_компиляторы)

Если и удастся запустить ее под ПРО, то только не младше версии 9.65 (пока не удается).

Вот блин я... А чем PRO от STD отличается? да и вообще как можно откомпилировать строчку:

#define _OS_Task_Create_DEFINED
void _OS_Task_Create(_OST_INT_TYPE priority, OST_CODE_POINTER TaskAddr)
{ ..

Я конечно недавно на С пишу и мот чего-то не понимаю но по моему писать название в define а потом создавать функцию с таким же именем это не совсем правильно...

[tester]

Сообщение от KeMik

Вот блин я... А чем PRO от STD отличается?

Они сделаны на разных платфомах. PRO пока что, грубо говоря, в стадии отладки на людях.

да и вообще как можно откомпилировать строчку:
Я конечно недавно на С пишу и мот чего-то не понимаю но по моему писать название в define а потом создавать функцию с таким же именем это не совсем правильно...

Вы вчитайтесь в идентификаторы. Дефайном определяется константа _OS_Task_Create_DEFINED. Эта константа говорит основному файлу (osa.c), что для данного контроллера функция _OS_Task_Create() перегружена.

[militrik]

Как красивее сделать инверсию бинарного семафора.
Конструкция типа

     if (OS_Bsem_Check (BS_DIRECTION))    {OS_Bsem_Reset (BS_DIRECTION);}
  BTFSS 0xa, 0, ACCESS
  BRA 0xe78
  BCF 0xa, 0, ACCESS
  BRA 0xe7a
              else                                {OS_Bsem_Set (BS_DIRECTION);}
  0E78    800A     BSF 0xa, 0, ACCESS

выглядит не очень. Вот бы новый сервис типа OS_Bsem_Inv() или что то другое, чтоб на выходе получалось

movlw 0b0000001
xorwf XXX,f

Кстати, если убрать выделеные фигурные скобки, компилятор picc18 9.51.pl2 ругается на Error [248] inappropriate "else".

[tester]

Сообщение от militrik

Как красивее сделать инверсию бинарного семафора.
Конструкция типа

     if (OS_Bsem_Check (BS_DIRECTION))    {OS_Bsem_Reset (BS_DIRECTION);}
  BTFSS 0xa, 0, ACCESS
  BRA 0xe78
  BCF 0xa, 0, ACCESS
  BRA 0xe7a
              else                                {OS_Bsem_Set (BS_DIRECTION);}
  0E78    800A     BSF 0xa, 0, ACCESS

выглядит не очень. Вот бы новый сервис типа OS_Bsem_Inv() или что то другое, чтоб на выходе получалось

movlw 0b0000001
xorwf XXX,f

Недокументированный сервис OS_Bsem_Switch это делает. Для PICC18 на выходе получается инструкция btg.

Кстати, если убрать выделеные фигурные скобки, компилятор picc18 9.51.pl2 ругается на Error [248] inappropriate "else".

Большинство сервисов OSA - макросы, содержащие по несколько операторов, заключенных в фигурные скобки. Поэтому наличие ';' перед else и вызывает ошибку компилятора.

[militrik]

Крррасота . Хотя btg 0xa, 1 и не получилось.

546:                                       OS_Bsem_Switch (BS_DIRECTION);
  0CA8    0E01     MOVLW 0x1
  0CAA    1A0A     XORWF 0xa, F, ACCESS

Сколько я нервов и времени сберег используя OSA. Спасибо.

[picavr]

Хочу спросить, опыта в Си пока мало,только начал, присматриваюсь к операционным системмам для МК. Есть ли смысл использовать, понял что в простых задачках - есть смысл. И возник вот какой вопрос по ОСА.

Если запустить 6 задач, или больше подобных задач.
1-я драйвер 1-wire
2-я драйвер ЖКИ символьный 4 бита.
3-я драйвер USART 9600.
4-я драйвер клавиатуры 4 бита, подключеной к шине данных ЖКИ модуля.
5-я разборка того что пришло в буфер USART и формирование буфера USART для передачи
6-я анализ клавиатуры, подготовка надписей для ЖКИ анализ опраций 1 wire ... система меню. запись в EEPROM параметров...

Будут ли ресурсы МК (порты и АЛУ) распределятся между задачами что бы эти процессы обрабатывались параллельно. То есть происходил приём байт из модуля USART в буфер приёма, из буфера передачи передавался по USART, выводились строки в ЖКИ из RAM или ROM, обрабатывалась клавиатура, и считывался скажем DS18B20 или DS1990 ?
На асме это всё реализуется, написаны драйверы которые работают по прерываниям таймера.

Требуется ли переписывание драйверов, написаных не для многозадачного использования (на задержках програмных циклов, когда скажем в ЖКИ идёт запись строки и задержки между записями байтов отсчитываются тактами МК а не прерываниями таймера) или потребуется их переработать.?

Узкое место в этой задаче в переключении направления шины данных (клавиш-жки неизвестно в какой момент система передаст управление следующей задачке), и в обеcпечении временных интервалов для 1wire и USART 9600 и ЖКИ.
То есть обработка всех задачь должна производится короткими проходами по каждому драйверу в 10-20 микросек, потом передача другому драйверу.

Может быть я не совсем понятно спросил... раскажу по наводящим вопросам.

[tester]

3-я драйвер USART 9600.

USART лучше принимать/передавать в прерывании. Завести два буфера: для приема и для передачи, - и в задачах ОС работать через эти буферы. Т.е. 3-ю задачу не нужно офомлять в виде задачи ОС (это неэффективно). Все остальное распределено по задачам правильно.

Будут ли ресурсы МК (порты и АЛУ) распределятся между задачами что бы эти процессы обрабатывались параллельно. То есть происходил приём байт из модуля USART в буфер приёма, из буфера передачи передавался по USART, выводились строки в ЖКИ из RAM или ROM, обрабатывалась клавиатура, и считывался скажем DS18B20 или DS1990 ?

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

Требуется ли переписывание драйверов, написаных не для многозадачного использования (на задержках програмных циклов, когда скажем в ЖКИ идёт запись строки и задержки между записями байтов отсчитываются тактами МК а не прерываниями таймера) или потребуется их переработать.?

Перерабатывать не нужно.

Узкое место в этой задаче в переключении направления шины данных (клавиш-жки неизвестно в какой момент система передаст управление следующей задачке), и в обеcпечении временных интервалов для 1wire и USART 9600 и ЖКИ.

Раз ЖКИ и клавиши присоеденены к одним и тем же выводам, то следует эти выводы рассматривать как разделяемый ресурс. Заведи двоичный семафор, и им сигнализируй, что порт занят. Пока он занят одной задачей, другая не получит управление (OS_Bsem_Wait).

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

Каких микросек? Зачем? Разберись по каждой задаче, как часто ей надо запускаться. Например, 1-wire: если это 1820, то чаще, чем раз в секунду (а еще лучше - в минуту) эту задачу запускать не нужно (температура не будет меняться быстрее); если это 1990, то ее надо выполнять раз в 50-200 мс (сколько времени человек прижимает таблетку к считывателю?). Какие тут 20 мкс? Кнопки тоже нет смысла запускать чаще, чем в 20-100мс, причем интревалы могут быть разные. Пользователю главное, чтобы он нажал, - и что-то произошло.

[picavr]

Спасибо за ответ,

Сообщение от tester

USART лучше принимать/передавать в прерывании.

Обычно и обрабатываю передачу из буфера и приём в буфер в прерывании таймера с периодом менее времени приёма одного байта.

Сообщение от tester

Заведи двоичный семафор, и им сигнализируй, что порт занят.

понятно

Сообщение от tester

Каких микросек? Зачем? Разберись по каждой задаче, как часто ей надо запускаться.

Это у меня на АСМ так работает, драйвер вызывается из прерывания таймера и выполняется 5-10 микросек за один проход. К примеру: 1wire и ЖКИ работают в прерывании таймера с периодом 100 микросек,
Я поясню почему я так спросил.
Вот примерный алгоритм для 1wire.
1 проход - выставить выход в "0" (начало RESET) загрузит счётчик длительности = 500/100=5,выставить флаг формирования RESET.это около 20-30 команд, и выход.
2-6 проходы - отсчёт счётчика длительности -1, на последнем проходе выход переключаем на ввод, загружаем счётчик задержку (=2) для проверки отклика и выставляем флаг проверки отклика,это около 10-30 команд за каждый проход, и выход.
7-8 проходы - отсчёт счётчика задержки и после окончания проверяем наличие отклика. Если нет отклика выставляем флаг что нет ответа. Если есть ответ, загружаем счётчик задержку до конца тайм слота и выставим флаг ожидания, и выход.
9-10 отсчёт счётчика задержки конца тайм слота, и вывод первого бита команды для устройства на шине. Грузим счётчик битов=8, выставим флаг, и выводим первый бит команды, и выход.
11-16 проходы - отсчёт счётчика битов и вывод оствшихся битов команды, и так далеее...

Таким образом время на этот драйвер расходуется римерно 3-10% (это когда он работает, а в паузах проверка флага и выход), остальное время распределеяется так же на другие драйверы или задачи.

А в варианте с ОС 1wire и остальные конечно пишутся как непрерывная работа с задержками, это понятно.
СПАСИБО ЗА РАЗЬЯСНЕНИЯ.

Интересно. можно ли портировать на IAR AVR, насколько там привязано к железу? Просто хотелось бы иметь одну ОС для разных МК.

[tester]

Сообщение от picavr

Спасибо за ответ,
Обычно и обрабатываю передачу из буфера и приём в буфер в прерывании таймера с периодом менее времени приёма одного байта.

С таких допусков начинаются ошибки. В контроллере есть биты RCIF и TXIF, которые устанавливаются соответственно при приеме и при передаче байта по USART.

Это у меня на АСМ так работает, драйвер вызывается из прерывания таймера и выполняется 5-10 микросек за один проход.

Если ты будешь при работе с RTOS мыслить категорями тактов, то останутся только неприятные впечатления.

Попробуй так прикинуть (программа немного утрирована):

void Task_18B20 (void)
{
    for (;;)
    {
        OS_Delay(1000);
        DS18B20_ReadTemp();
        ...
    }
}

Пока выполняется OS_Delay, система занята другими задачами, а об этой даже не думает. Потом эта задача поучает управление и вызывает функцию чтения температуры. Это чтение может продлиться несколько миллисекунд, и в течение этого времени ни ЖКИ ни кнопки обрабатываться не будут. Так вот: в этом нет ничего страшного. Критичекие куски кода (в частности прием по USART) - в перерывании, а с остальными ничего не случится, если они подождут 10-20 мс.

Интересно. можно ли портировать на IAR AVR, насколько там привязано к железу? Просто хотелось бы иметь одну ОС для разных МК.

Последний раз я прикасался к АВРу лет 8 назад. Сейчас я уже не в курсе ни о новых контроллерах, ни о том, какие компиляторы сейчас самые распространенные, ни о том, какие ОСРВ уже есть... Сейчас я занят портированием на микроСи для ПИКов. Насчет АРВов пока не думал.

[picavr]

Сообщение от tester

С таких допусков начинаются ошибки. В контроллере есть биты RCIF и TXIF, которые устанавливаются соответственно при приеме и при передаче байта по USART.

Естественно по RCIF и TXIF, просто я не организовываю отдельное прерывание для USART а анализирую RCIF и TXIF в прерывании таймера. А за период таймера USART успевает принять-передать только один байт. Всё работает.

Сообщение от tester

Если ты будешь при работе с RTOS мыслить категорями тактов, то останутся только неприятные впечатления.

Это понятно, что задержки между считыванием температуры будут отрабатыватся средствами ОС.
А задержки формирующие таймслоты 1 wire - циклами?

Сообщение от tester

Пока выполняется OS_Delay, система занята другими задачами, а об этой даже не думает. Потом эта задача поучает управление и вызывает функцию чтения температуры. Это чтение может продлиться несколько миллисекунд, и в течение этого времени ни ЖКИ ни кнопки обрабатываться не будут. Так вот: в этом нет ничего страшного. Критичекие куски кода (в частности прием по USART) - в перерывании, а с остальными ничего не случится, если они подождут 10-20 мс.

Да это понятно что ЖКИ, клавиши и интерфейс пользователя подождут.
Но например динамическая индикация на АЛС будет мигать на время считывания иемпературы.
Или если обрабатывается АЦП от которого рулится ШИМ, то будут провалы или горбы в регулировании ШИМ. итд...
Или купюро- монето- приёмник начнёт выдавать информацию о принятых деньгах... им не скажешь подожди...

В моём варианте всё обрабатывается в прерываниях таймеров, и все задачи работают параллельно. Время ядра распределяется таким образом, что бы все задачи успевали отработать В ЛЮБОЕ ВРЕМЯ, и ЖКИ и USART и 1wire и клавиши итд..
Я хотел понять как именно распределяется время между задачами, поэтому я и начал задавать эти вопросы.
Просто думал, что обработка задач будет прерыватся, и на НЕКОТОРОЕ ВРЕМЯ передававать управление другим задачам, по кругу... а не только те которые чего то ожидают...
Теперь понятно, пока задача выполняется остальные ждут, кроме тех что в прерываниях. Спасибо ВАМ за разъяснения.

[militrik]

Как правильно написать ожидание выполнения условия с участием бинарного семафора. Например : ждем пока выход компаратора примет иное значение чем у бинарного семафора

OS_Cond_Wait (COUT != BS_Semafore);

[tester]

Сообщение от militrik

Как правильно написать ожидание выполнения условия с участием бинарного семафора. Например : ждем пока выход компаратора примет иное значение чем у бинарного семафора

OS_Cond_Wait (COUT != BS_Semafore);

OS_Cond_Wait(COUT != (OS_Bsem_Check(BS_Semaphore)?1:0));

Только тут налицо концептуально неправильное использование семафора (хоть и допустимое). Семафор - это не совсем битовая переменная. Здесь лучше использовать именно битовую переменную:

static bit s_bPrevCOUT;     // Например такую
...
OS_Cond_Wait(COUT != s_bPrevCOUT);  // Ждать так
...

[gromovi]

OSAcfg_Tool?

[gromovi]

ну нифига непонять на что жалуется