Перейти к содержанию
    

Не работает шедулер OS на MSP430F5437a

В проекте на MSP430F5437a пытаюсь применить uCOS-III.

По старту OS в OSStart(&os_err) - заполняются TCB - вроде все правильно.

Затем начинается вызов самих тасков в порядке приоритета.

Сначала вызывается первый task - все нормально.

Затем первый task в pend, переходим на второй. И здесь проблема в schedulere.

Вместо перехода на следующий похоже возвращаемся на старую точку.

Вот код:

OSCtxSw

POPX.W R12 ; Pop lower 16 bits of PC.

 

POPX.W R13 ; Pop upper 4 bits of PC.

 

PUSHX.W R12 ; Save lower 16 bits of PC.

 

RLAM.A #4, R13 ; Save SR + upper 4 bits of PC.

RLAM.A #4, R13

RLAM.A #4, R13

MOVX.W SR, R12

ADDX.A R13, R12

PUSHX.W R12

 

PUSHM.A #12, R15 ; Save R4-R15.

 

MOVX.A &OSTCBCurPtr, R13 ; OSTCBCurPtr->StkPtr = SP

MOVX.A SP, 0(R13)

 

CALLA #OSTaskSwHook

 

MOVX.B &OSPrioHighRdy, R13 ; OSPrioCur = OSPrioHighRdy

MOVX.B R13, &OSPrioCur

 

MOVX.A &OSTCBHighRdyPtr, R13 ; OSTCBCurPtr = OSTCBHighRdyPtr

MOVX.A R13, &OSTCBCurPtr

 

MOVX.A @R13, SP ; SP = OSTCBHighRdyPtr->StkPtr

 

POPM.A #12, R15 ; Restore R4-R15.

 

RETI

 

После

POPM.A #12, R15

все регистры заполняются верно(смотрел в debug), в том числе и SP.

Если поставить точку останова на RETI и затем сделать один шаг в Debug, то

переходит как и требуется на следующий task, записанный в контексте.

Если же после RETI продолжить в автомате, то переключается не на task,

а похоже в точку вызова OSCtxSw.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Программируя 16-Bit Ultra-Low-Power Microcontroller, 256KB Flash, 16KB RAM, 12 Bit ADC, 2 USCIs, 32-bit HW Multi

на ассемблере, можно очень многого добиться. Примените более простое решение для достижения результата.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Тики тикают ? Проверьте не на отладчике, а аппаратно, методом ногодрыга.

Неполиткорректный вопрос. Почему uCOS, а не scmRTOS или FreeRTOS ?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Тики тикают ? Проверьте не на отладчике, а аппаратно, методом ногодрыга.

Неполиткорректный вопрос. Почему uCOS, а не scmRTOS или FreeRTOS ?

 

Извините, что не сразу ответил.

Тики тикают.

Вопрос решить удалось. Были мои ошибки связанные с оформлением прерываний.

Но в целом пока проект не запустил, возникло много других моментов.

 

Почему uCOS. Да просто получилось исторически так, что ранее ее использовал для проектов на ARM и все устраивало.

Для MSP430 давно уже применяю scmRTOS(правда так как началось это уже очень давно, то еще версию V2.03) и

тоже было нормально. Находил пару багов, исправлял и все работало.

Но сейчас решил применить опыт работы с ARM (STL:vectore, list, map, string) в MSP430, ну и понадобилось защищать

heap для библиотечных элементов. Для ARM делал это через TLS, а для scmRTOS писал простой диспетчер и всю динамику делал

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

Правда, как сейчас вижу, возникает много вопросов, в особенности с размером требуемого ОЗУ для heap и с тем что DLIB IAR-MSP430

не поддерживает подсчет размера используемой кучи.

Недавно увидел, что с scmRTOS можно прикрутить аллокатор, в частности bget. Может кто имеет опыт этого, например, сколько потребуется ОЗУ, и

ляжет все это для MSP430F5437A. Может есть какие-то другие решения потоковой защиты библиотечных элементов Heap, которые можно применить с контроллерами у которых

ограничен ресурс ОЗУ.

Использование MSP430F5437A обусловлено требованием малого потребления. Устройство в моем старом проекте в основном режиме потребляет 30мкА.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Может есть какие-то другие решения потоковой защиты библиотечных элементов Heap, которые можно применить с контроллерами у которых

ограничен ресурс ОЗУ.

Для МК у которых "ограничен ресурс ОЗУ" не нужно применять Heap. Это самое правильное решение.

Ну а если так уж чешется, то что мешает использовать семафоры например? (OSSemPend()/OSSemPost())

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для МК у которых "ограничен ресурс ОЗУ" не нужно применять Heap. Это самое правильное решение.

А для чего же тогда куча придумана, как не для использования "ограниченного ресурса ОЗУ"? :rolleyes:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

. . .

. . . . с контроллерами у которых ограничен ресурс ОЗУ.

 

Использование MSP430F5437A обусловлено требованием малого потребления. Устройство в моем старом проекте в основном режиме потребляет 30мкА.

 

для MSP430 16k - это не "ограниченный ресурс", это даже много :)

И чтоб его заполнить (эффективно-полезно) проект должен быть большой (по коду-алгоритму).

Или - Вы делаете нечто вроде мобильного (на батарее) сервера, каждое из подключений будет "кушать" RAM.

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А для чего же тогда куча придумана, как не для использования "ограниченного ресурса ОЗУ"? :rolleyes:

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

 

И чтоб его заполнить (эффективно-полезно) проект должен быть большой (по коду-алгоритму).

Приложение из пары тысяч строк, выводящее некую инфу на пиксельный LCD разрешением скажем 320x240 при 4х цветах - это большой проект?

А ведь всего-то потребует порядка ~38КБ только под видеобуфер в ОЗУ....

Или например: простой логгер (может даже меньше 1000 строк) пишущий всего пару параметров в журнал находящийся в большой внешней флешке с размером блока стирания 128КБ, но с необходимостью изредка корректировать записанные данные в середине журнала. А значит нужен буфер 128КБ чтобы считать/скорректировать/стереть/записать.

Имхо: много или мало ОЗУ определяется не архитектурой (MSP430, ARM, etc.), а задачей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...