SMRM 0 25 августа, 2016 Опубликовано 25 августа, 2016 · Жалоба В проекте на 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. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mcheb 0 25 августа, 2016 Опубликовано 25 августа, 2016 · Жалоба Программируя 16-Bit Ultra-Low-Power Microcontroller, 256KB Flash, 16KB RAM, 12 Bit ADC, 2 USCIs, 32-bit HW Multi на ассемблере, можно очень многого добиться. Примените более простое решение для достижения результата. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 26 августа, 2016 Опубликовано 26 августа, 2016 · Жалоба Тики тикают ? Проверьте не на отладчике, а аппаратно, методом ногодрыга. Неполиткорректный вопрос. Почему uCOS, а не scmRTOS или FreeRTOS ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SMRM 0 30 августа, 2016 Опубликовано 30 августа, 2016 · Жалоба Тики тикают ? Проверьте не на отладчике, а аппаратно, методом ногодрыга. Неполиткорректный вопрос. Почему 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мкА. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 31 августа, 2016 Опубликовано 31 августа, 2016 · Жалоба Может есть какие-то другие решения потоковой защиты библиотечных элементов Heap, которые можно применить с контроллерами у которых ограничен ресурс ОЗУ. Для МК у которых "ограничен ресурс ОЗУ" не нужно применять Heap. Это самое правильное решение. Ну а если так уж чешется, то что мешает использовать семафоры например? (OSSemPend()/OSSemPost()) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 31 августа, 2016 Опубликовано 31 августа, 2016 · Жалоба Для МК у которых "ограничен ресурс ОЗУ" не нужно применять Heap. Это самое правильное решение. А для чего же тогда куча придумана, как не для использования "ограниченного ресурса ОЗУ"? :rolleyes: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 31 августа, 2016 Опубликовано 31 августа, 2016 · Жалоба . . . . . . . с контроллерами у которых ограничен ресурс ОЗУ. Использование MSP430F5437A обусловлено требованием малого потребления. Устройство в моем старом проекте в основном режиме потребляет 30мкА. для MSP430 16k - это не "ограниченный ресурс", это даже много :) И чтоб его заполнить (эффективно-полезно) проект должен быть большой (по коду-алгоритму). Или - Вы делаете нечто вроде мобильного (на батарее) сервера, каждое из подключений будет "кушать" RAM. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 31 августа, 2016 Опубликовано 31 августа, 2016 · Жалоба А для чего же тогда куча придумана, как не для использования "ограниченного ресурса ОЗУ"? :rolleyes: Для систем где этот ресурс можно считать неограниченным, естественно. Как только этот ресурс становится ограниченным, вылазят все проблемы связанные с кучей. И чтоб его заполнить (эффективно-полезно) проект должен быть большой (по коду-алгоритму). Приложение из пары тысяч строк, выводящее некую инфу на пиксельный LCD разрешением скажем 320x240 при 4х цветах - это большой проект? А ведь всего-то потребует порядка ~38КБ только под видеобуфер в ОЗУ.... Или например: простой логгер (может даже меньше 1000 строк) пишущий всего пару параметров в журнал находящийся в большой внешней флешке с размером блока стирания 128КБ, но с необходимостью изредка корректировать записанные данные в середине журнала. А значит нужен буфер 128КБ чтобы считать/скорректировать/стереть/записать. Имхо: много или мало ОЗУ определяется не архитектурой (MSP430, ARM, etc.), а задачей. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться