реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> Не работает шедулер OS на MSP430F5437a
SMRM
сообщение Aug 25 2016, 13:51
Сообщение #1


Участник
*

Группа: Участник
Сообщений: 19
Регистрация: 26-06-09
Пользователь №: 50 667



В проекте на 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.
Go to the top of the page
 
+Quote Post
mcheb
сообщение Aug 25 2016, 14:06
Сообщение #2


Местный
***

Группа: Участник
Сообщений: 288
Регистрация: 30-05-06
Пользователь №: 17 602



Программируя 16-Bit Ultra-Low-Power Microcontroller, 256KB Flash, 16KB RAM, 12 Bit ADC, 2 USCIs, 32-bit HW Multi
на ассемблере, можно очень многого добиться. Примените более простое решение для достижения результата.
Go to the top of the page
 
+Quote Post
k155la3
сообщение Aug 26 2016, 11:57
Сообщение #3


Знающий
****

Группа: Свой
Сообщений: 521
Регистрация: 8-03-09
Из: Днепр
Пользователь №: 45 848



Тики тикают ? Проверьте не на отладчике, а аппаратно, методом ногодрыга.
Неполиткорректный вопрос. Почему uCOS, а не scmRTOS или FreeRTOS ?
Go to the top of the page
 
+Quote Post
SMRM
сообщение Aug 30 2016, 07:00
Сообщение #4


Участник
*

Группа: Участник
Сообщений: 19
Регистрация: 26-06-09
Пользователь №: 50 667



Цитата(k155la3 @ Aug 26 2016, 14:57) *
Тики тикают ? Проверьте не на отладчике, а аппаратно, методом ногодрыга.
Неполиткорректный вопрос. Почему 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мкА.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Aug 31 2016, 02:51
Сообщение #5


Гуру
******

Группа: Свой
Сообщений: 3 383
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(SMRM @ Aug 30 2016, 13:00) *
Может есть какие-то другие решения потоковой защиты библиотечных элементов Heap, которые можно применить с контроллерами у которых
ограничен ресурс ОЗУ.

Для МК у которых "ограничен ресурс ОЗУ" не нужно применять Heap. Это самое правильное решение.
Ну а если так уж чешется, то что мешает использовать семафоры например? (OSSemPend()/OSSemPost())
Go to the top of the page
 
+Quote Post
ViKo
сообщение Aug 31 2016, 06:03
Сообщение #6


Универсальный солдатик
******

Группа: Модераторы
Сообщений: 7 429
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362



Цитата(jcxz @ Aug 31 2016, 05:51) *
Для МК у которых "ограничен ресурс ОЗУ" не нужно применять Heap. Это самое правильное решение.

А для чего же тогда куча придумана, как не для использования "ограниченного ресурса ОЗУ"? rolleyes.gif
Go to the top of the page
 
+Quote Post
k155la3
сообщение Aug 31 2016, 06:22
Сообщение #7


Знающий
****

Группа: Свой
Сообщений: 521
Регистрация: 8-03-09
Из: Днепр
Пользователь №: 45 848



Цитата(SMRM @ Aug 30 2016, 10:00) *
. . .
. . . . с контроллерами у которых ограничен ресурс ОЗУ.

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


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


Go to the top of the page
 
+Quote Post
jcxz
сообщение Aug 31 2016, 08:16
Сообщение #8


Гуру
******

Группа: Свой
Сообщений: 3 383
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(ViKo @ Aug 31 2016, 12:03) *
А для чего же тогда куча придумана, как не для использования "ограниченного ресурса ОЗУ"? rolleyes.gif

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

Цитата(k155la3 @ Aug 31 2016, 12:22) *
И чтоб его заполнить (эффективно-полезно) проект должен быть большой (по коду-алгоритму).

Приложение из пары тысяч строк, выводящее некую инфу на пиксельный LCD разрешением скажем 320x240 при 4х цветах - это большой проект?
А ведь всего-то потребует порядка ~38КБ только под видеобуфер в ОЗУ....
Или например: простой логгер (может даже меньше 1000 строк) пишущий всего пару параметров в журнал находящийся в большой внешней флешке с размером блока стирания 128КБ, но с необходимостью изредка корректировать записанные данные в середине журнала. А значит нужен буфер 128КБ чтобы считать/скорректировать/стереть/записать.
Имхо: много или мало ОЗУ определяется не архитектурой (MSP430, ARM, etc.), а задачей.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 23rd June 2017 - 20:35
Рейтинг@Mail.ru


Страница сгенерированна за 0.01407 секунд с 7
ELECTRONIX ©2004-2016