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

Программирование ATMEL в BASCOM.

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Программирование ATMEL в BASCOM. » Кирпичи... » Кооперативная ОС реального времени AQUA RTOS для BASCOM AVR


Кооперативная ОС реального времени AQUA RTOS для BASCOM AVR

Сообщений 31 страница 39 из 39

31

Cirno_9 написал(а):

Ставите обработчик, код которого вызывает сервис ОС Сигнализировать.

имеется ввиду OS_WaitEvent? как это поможет если в сам обработчик диспетчер через раз пускает?

0

32

Новые грабли с этой ОС, теперь упёрся в приём данных через USART ((

0

33

Kasym написал(а):

Новые грабли с этой ОС, теперь упёрся в приём данных через USART ((

А в чем грабли?

В начале кода:

declare sub UART_GetChar()
dim evEVENT as byte

' *** объявляем событие; включаем прерывание, которое будет принимать символы из UART

evEVENT = OS_CreateEvent()   
on URXC UART_GetChar
enable URXC

' *** пишем обработчик прерывания UART:

sub UART_GetChar
   bUART_CHAR = inkey()                                                   ' get one symbol 
   ' *** some code *** какая-то обработка
   OS_SignalEvent evEVENT ' сигналим ОС, когда произошли заданные условия (совпадение строки и т.п.)
end sub

' *** какая-то задача ждет указанных условий, т.е. сигнала о событии

sub Task_TASK()
   do
      ' *** some code ***
      OS_WaitEvent evEVENT
      ' *** some code ***
   loop
end sub

Просто переключите голову на событийно-ориентированный подход.

Тут при старте ОС или где-то еще дальше по необходимости стартует задача Task_TASK, которая сразу же приостанавливает свое исполнение, ожидая события evEVENT (управление передается диспетчеру).
Прерывание порта принимает символы и ведет какую-то обработку и чаще всего представляет собой конечный автомат с несколькими состояниями и графом переходов.
Например,  он ожидает первый байт синхропоследовательности, затем переходит в состояние "ожидать второй байт", и если следующий принятый байт является вторым синхро-байтом, автомат чистит буфер и переходит в состояние "принимать строку".
Теперь он будет копить принятые символы в буфер до наступления каких-то условий (стоп-байт, достижение заданной длины буфера и т.п.). Затем могут быть и другие состояния типа проверки CRC.
И, наконец, если все в порядке, процедура обработки сигналит ОС о том, что строка принята, событием evEVENT.
После выхода из прерывания ОС ставит задачу Task_TASK в очередь на исполнение, и когда она подойдет, задача может продолжиться.
Очевидно, тут ей самое время разобрать принятую строку и выполнить какие-то действие (в кооперативной ОС, если это что-то довольно сложное -- выдать сообщение, просигналить о событии или непосредственно разрешить исполнение задаче, "привязанной" к данной строке).

Подобная схема покрывает большинство практических потребностей работы с UART.

Отредактировано Cirno_9 (2020-10-15 10:10:24)

+1

34

БАГФИКС

Обнаружила крайне неприятный логический баг в шедулере, из-за которого остановленная задача рестартовала не сначала, а продолжала исполнение как приостановленная.

Для исправления необходимо в процедуре sub OS_Sheduler() найти строку if task_state(task_current) <> OSTS_STOP or task_state(task_current) <> OSTS_RESTART then и заменить or на and

С наступающим! )

+1

35

Я решил попробовать Вашу ОС.  Скопировал текст ОС в отдельный файл. Взял первый пример из Вашей статьи.   Не компилирует - выдает ошибку:

Error : 323   Line :   184   Label too long [OSERR_CANT_FIND_TASK OR OSERR_CRITICAL]  , in File : OS_AQUA\OS_AQUA_RTOS.bas
..... ...

У меня Bascom AVR  2.0.7.1

0

36

Вы на какой версии Bascom обкатывали ОС  ??? 

Баг из прошлого поста обошел.
Добавил еще одну переменную :
dim OS_tmp1 as Byte 
Макрос исправил:   

Код:
macro MGetTaskIdByLabel
   for task_id = 1 to task_count                            ' по адресу задачи в task_label находит ее task_id в системе или возвращает 0
      if task_entry(task_id) = task_label then exit for
   next
   if task_id > task_count then
      OS_tmp1  = OSERR_CANT_FIND_TASK or OSERR_CRITICAL
      OS_RaiseErr OS_tmp1
   end if
end macro

Теперь вылез новый баг в OS_Sheduler()
Строка:    if task_state(task_queue(task_id)) <> OSTS_READY then continue 
Ошибка: Unknown statement [CONTINUE]   
т.е. Что происходит после  THEN  ???

И ещё из примера 1

Unknown statement [TOOGLE LED_1]
Unknown statement [TOOGLE LED_2]

Отредактировано SV12 (2021-01-12 10:33:28)

0

37

SV12 написал(а):

У меня Bascom AVR  2.0.7.1

Текущая врсия 2.0.8.3.

SV12 написал(а):

Ошибка: Unknown statement [CONTINUE]

Оператор continue добавлен в версии 2081.

0

38

Эх.. придется искать версию 2081.  А там посмотрим ... .

Отредактировано SV12 (2021-01-12 12:15:04)

0

39

SV12 написал(а):

Эх.. придется искать версию 2081.  А там посмотрим ... .

Отредактировано SV12 (Сегодня 09:15:04)

На цепочку сообщений о багах в BASCOM лучше не смотреть: после первого там лезет всякое невообразимое, типа "все пошло прахом".
Версию 2.8.0.3 раздают какие-то арабские товарищи.

0


Вы здесь » Программирование ATMEL в BASCOM. » Кирпичи... » Кооперативная ОС реального времени AQUA RTOS для BASCOM AVR