[Артём__ 0]

не-не не. у меня специально 2 фоновый процесс создан-там светик моргает,

значит задачи переключаются.

Может и так, ведь проекты у нас не совсем одинаковые, так как версии Иара разные и не все файлы есть.

Эти строки из OS_Target_asm.s90

#include "D:\Viktor\Проекты\микроконтроллеры\AVR-8\Progekts IAR\scm_rtos\snmp\soft\scm_rtos_Config\scmRTOS_CONFIG.h"

#include "D:\Viktor\Проекты\микроконтроллеры\AVR-8\Progekts IAR\scm_rtos\snmp\soft\scm_rtos_Config\scmRTOS_TARGET_CFG.h"

пришлось закоментировать, потому как у меня нет этих файлов...

 

 

и в порт раз в 8секунд вывод идет-но только 1 байт,а не 5- в прерывание не заходит.

8 секунд - не период ватчдога случайно?

 

А симулятору ОС крышу сносит напрочь своим переключением стековых фреймов,это да.

Не замечал такого - чтобы сносило, но мало ли, может и так.

То есть у вас вектор номер 0x6C в таблице есть?

 

Ладно,пора спать,утро вечера мудренее...

Тоже дело...

[Артём__ 0]

не-не не. у меня специально 2 фоновый процесс создан-там светик моргает,

значит задачи переключаются.

и в порт раз в 8секунд вывод идет-но только 1 байт,а не 5- в прерывание не заходит.

 

Получается, что если в scmRTOS_CONFIG.h (для АВР)

#define scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE 0

, то в context_switch_hook не будет вызвана функция

INLINE void block_context_switch() { SPM_CONTROL_REG &= ~(1 << SPMIE); } // disable SPM interrupt

и прерывание SPM будет происходить всегда и к тому же будут блокированы все вектора с номером большим, чем SPM.

То есть для АВР scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE должно быть равным 1, если используется переключение с помощью прерываний на векторе SPM. Тогда он не совсем user_hook - без него программа работать не будет?

 

В проекте WHALE прерывание USART1_TX не отрабатывается, потому что его приоритет ниже чем у прерывания SPM, которое не отключается после переключения контекста.

[WHILE 0]

Нет,Артем,все как всегда оказалось значительно проще.

РТОС вообще не причем.

на 3 сутки я обнаружил,что в камере нет одной стены упростил проект еще-убрал РТОС- и охренел,увидев что прерывание по концу передачи uart1 все-равно не работает.Стал восстанавливать порядок действий-доРТОС-ный вариант

у меня был собран на меге164.Но ОЗУ там было в обрез и при перепиливании на вариант с РТОС я перешел на 324.

И наткнувшись на этот баг решил,но виновата ОСЬ.

Сейчас проделал следующий эксперимент-достал плату с 164 мегой,сомпилировал под неё(не трогая кода)-все работает!!!

Компилю тот-же код под 324-не работает. :wub:

Ставлю версию IAR 6.12.1 - работает все.

Вывод мой такой-что-то в версии 6.20 яровцы порушили для 324 меги.

се ля ви...

[Артём__ 0]

Нет,Артем,все как всегда оказалось значительно проще.

РТОС вообще не причем.

Может и так.

Я запускал ваш проект в симуляторе, вроде работало правильно, но как он в железе поведёт - вопрос.

 

 

И наткнувшись на этот баг решил,но виновата ОСЬ.

Думаю, что она и виновата. Вернее неправильная настройка ОСи.

Обратите внимание на значение макроса scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE. Мне кажется, если он будет равен 0, то работа системы сильно замедлится и частично может быть заблокирована. Или я неправ?

 

Вывод мой такой-что-то в версии 6.20 яровцы порушили для 324 меги.

се ля ви...

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

[WHILE 0]

Думаю, что она и виновата. Вернее неправильная настройка ОСи.

Обратите внимание на значение макроса scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE. Мне кажется, если он будет равен 0, то работа системы сильно замедлится и частично может быть заблокирована. Или я неправ?

 

 

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

Артем, еще раз.Я вчера выкинул из проекта ось и прерывание USART1_TX_vect все равно не

работало.Этот -же код скомпилированный этим-же компилятором с теми-же опциями

под мегу 164 работает.

В iar 6.12 этот-же код скомпилированный с теми-же опциями работает и на 324 тоже.

Да,в боевом проекте при попытке выбора меги324p iar выдавал внутреннюю ошибку.

имхо,виноват iar.

 

[Romcik077 0]

Здравствуйте!

Помогите новичку. У меня проблема с запуском scmRTOS. Работаю я в Eclpse с компилятором GCC-ARM. В чем состоит суть моей задачи используя библиотеку mbed(mbed) запустить scmRTOS на этом деваисе LPC1768 используя для компиляций Eclipse. Ниже загрузил проект, он компилируется даже запускается но виснет на первой задаче. Если заметите то в програме прописаны пересылки через UART, так вот на выходе я получяю "Hello\r\nS", и диоды не мигают, тут програма и виснет. Помогите разобраться пожалуйста. Укажите куда копать код.

Заранее спасибо за помощь!!!

 

Myprog.zip

Изменено 6 апреля, 2013 пользователем Romcik077

[AHTOXA 15]

Вы используете стартовый код от mbed: mbed/LPC1768/GCC_ARM/startup_LPC17xx.o. (Там что, нет исходников?).

В нём используемые осью прерывания называются

SysTick_Handler и PendSV_Handler.

А в оси они называются иначе:

SystemTimer_ISR и PendSVC_ISR.

Соответственно, надо либо найти исходник от startup_LPC17xx.o и переименовать там, либо править в исходниках оси.

[Romcik077 0]

Вы используете стартовый код от mbed: mbed/LPC1768/GCC_ARM/startup_LPC17xx.o. (Там что, нет исходников?).

В нём используемые осью прерывания называются

SysTick_Handler и PendSV_Handler.

А в оси они называются иначе:

SystemTimer_ISR и PendSVC_ISR.

Соответственно, надо либо найти исходник от startup_LPC17xx.o и переименовать там, либо править в исходниках оси.

Спасибо за быстрый ответ.

К сожалению исходников LPC17xx.o нет, самому хотелось но нету. Так что пришлось менять исходники scmRTOS(ниже выложен измененый проект), изменил в трех файлах OS_Target_asm.S, scmRTOS_TARGET_CFG.h и OS_Target_cpp.cpp, но к сожалению это много не помогло. С помощью debugger-а проверил, прерывания пошли, но все равно виснет, вроде нашел точку блокировки но не знаю как исправить, останавливается он на коде: INLINE void disable_context_switch() { disable_interrupts(); }, в фаиле OS_Target.h, по краиней мере debugger зависает после этой строчки кода.

Myprog.zip

Забыл спросить прерывания PendSV_Handler тоже должны происходить переодически? Потому-что во время debugging-а ни разу ни вызывалось это прерывание, может в этом проблема?

Изменено 6 апреля, 2013 пользователем Romcik077

[Артём__ 0]

исправить, останавливается он на коде: INLINE void disable_context_switch() { disable_interrupts(); }, в фаиле OS_Target.h, по краиней мере debugger зависает после этой строчки кода.

У вас там не зашищённый режим (thread mode)?

 

Забыл спросить прерывания PendSV_Handler тоже должны происходить переодически?

Это прерывание возникает когда нужно передать управление другой задаче. Если оно у вас не происходит, то возможно раньше ошибка где-нибудь произошла.

 

 

 

[Romcik077 0]

У вас там не зашищённый режим (thread mode)?

Вы имеете в виду что не разрешается выполнение кода ассемблера? Вроде нет функция os_start из OS_Target_asm.S нормально проходит.

[Артём__ 0]

Вы имеете в виду что не разрешается выполнение кода ассемблера? Вроде нет функция os_start из OS_Target_asm.S нормально проходит.

Наверное моё предположение о thread-режиме неправильное.

 

disable_context_switch вызывается вроде только в функции TKernel::sched. То есть туда попадает? У вас HardFault не возникает какой-нибудь? Вы можете заменить их обработчик на свой и посмотреть адрес где возникает ошибка?

 

P.S. Интересно просто...зачем он - mbed, если он без исходников.

Что делать в случае ошибки в либе? Можно заменить своей? Какие ресурсы процессора либа использует и как(DMA и тд)? Можно ли заменить их реализацию своей?

[Romcik077 0]

Я решил заменить стартовые и системные библиотеки на те что даны в примере для LPC17xx. Помогите чтоб не ошибится что нужно заменить для компиляций. Вроде как startup_LPC17xx.o -> startup.c, system_LPC17xx.o -> sysinit.cpp и все это скомпилировать. Нужны еще какие-то зависимости?

[AHTOXA 15]

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

[Romcik077 0]

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

disable_context_switch вызывается вроде только в функции TKernel::sched. То есть туда попадает? У вас HardFault не возникает какой-нибудь? Вы можете заменить их обработчик на свой и посмотреть адрес где возникает ошибка?

Вы оказались правы он в функций TKernel::sched и зависает а иммено в цикле

do
{
     enable_context_switch();
     DUMMY_INSTR();
     disable_context_switch();
} 
while(CurProcPriority != SchedProcPriority);

Я так понимаю просто не происходит прерывание PendSV_Handler которая переключит контексты, потому-что ни разу за выполнение програмы меня не кидало туда. Что мне делать помогите пожалуйста?

А обработчик где заменить? В ассемблеревском коде или TKernel::sched.

Как проверить возникновение HardFault?

[Romcik077 0]

Всем спасибо за помощь!!! Проблема совсем в другом оказалась. Ну не совсем проблема... Оказывалось что програма заработала после смены SystemTimer_ISR и PendSVC_ISR на нужные, но из за функций sleep(), которому я задал слишком малый параметр и мне казалось что диоды не мигают. После смены SYSTICKINTRATE с 960 на 96 я заметил что диоды замигали и тут я понял в чем проблема. Что-ж осталось разобраться в чем измеряется параметр для sleep() и какие значения поставить для SYSTICKINTRATE и SYSTICKFREQ(теперь они 96 и 96000000). Если не трудно подскажите как правильно подобрать?

Еще раз спасибо за помощь и за такую простую и удобную ОСь.

Изменено 7 апреля, 2013 пользователем Romcik077