[AlexG 1]

scmRTOS 4.0, ATmega1284, порт для IAR, IAR EWAVR 6.20

 

Возникла проблема с прерываниями RX USART1. Вызовы обработчика прерывания RX оказались синхронизированы с прерываниями системного таймера (при scmRTOS_SYSTIMER_NEST_INTS_ENABLE 1) или вызов обработчика не происходил совсем (при scmRTOS_SYSTIMER_NEST_INTS_ENABLE 0). При этом необходимые биты в регистрах были установлены - RXCIE1 в UCSR1B, RXC1 в USCR1A, I в SREG. USART0 работал корректно.

Причина проблемы по-видимому в переключения контекста scmRTOS с использованием программного прерывания (scmRTOS_CONTEXT_SWITCH_SCHEME 1), так как при scmRTOS_CONTEXT_SWITCH_SCHEME 0 проблема устраняется. Для переключения контекста в порте используется прерывание SPM_READY, которое имеет больший приоритет чем прерывания USART1.

 

Пока у меня есть две версии того что происходит:

1. Прерывание USART1_RX вызывается только по фронту, при установке бита RXC1 в 1 и если в этот момент прерывания были запрещены после их разрешения прерывание USART1_RX больше вызвано не будет. Насколько я понимаю документацию, обработка прерываний от USART не должена так работать:

When the Receive Complete Interrupt Enable (RXCIEn) in UCSRnB is set, the USART Receive Complete interrupt will be executed as long as the RXCn Flag is set (provided that global interrupts are enabled).

 

2. У контроллер прерываний ATmega1284 остались какие-то недокументированные особенности так как в Atmel никто не ожидал что прерывание SPM_READY будет использоваться без переноса таблицы векторов прерываний в область бутлоадера:

When using the SPM interrupt, the Interrupt Vectors should be moved to the BLS section to avoid that an interrupt is accessing the RWW section when it is blocked for reading.

[Сергей Борщ 119]

2. У контроллер прерываний ATmega1284 остались какие-то недокументированные особенности так как в Atmel никто не ожидал что прерывание SPM_READY будет использоваться без переноса таблицы векторов прерываний в область бутлоадера:

Вы не поняли этот отрывок документации. Он предполагает использование этого прерывания по прямому назначению, т.е. для сигнализации окончания записи во флеш. В процессе записи NRWW-область флеша блокируется от чтения. Разблокировка производится специальной командой. А прерывание возникает до выполнения этой команды и будет пытаться считать вектор из заблокированной области. У нас же прерывание используется без записи и блокировки флеша, нас этот момент не задевает.

 

Возникла проблема с прерываниями RX USART1. Вызовы обработчика прерывания RX оказались синхронизированы с прерываниями системного таймера

Как-то это странно. Я уже не помню, как там организовано в порте для AVR, но гляньте сюда: http://electronix.ru/forum/index.php?showt...p;#entry1144842, возможно это ваш случай.

 

[WHILE 0]

Как-то это странно. Я уже не помню, как там организовано в порте для AVR, но гляньте сюда: http://electronix.ru/forum/index.php?showt...p;#entry1144842, возможно это ваш случай.

 

Да, очень похоже на мой случай. Это-же одна линейка - 164-324-644-1284.

ex_AlexG, сделайте, как уже советовал Сергей Борщ,минимальный проект без РТОС.

Я сделал вывод в uart1 массива по прерыванию RX USART1, стартуемый по таймеру - это

около 10 строчек кода. Если хотите, могу выложить.

И расскажите, пожалуйста, о результате.

[AlexG 1]

гляньте сюда: http://electronix.ru/forum/index.php?showt...p;#entry1144842, возможно это ваш случай.

 

Да, очень похоже на мой случай. Это-же одна линейка - 164-324-644-1284.

ex_AlexG, сделайте, как уже советовал Сергей Борщ,минимальный проект без РТОС.

 

И расскажите, пожалуйста, о результате.

 

Действительно похоже, у меня даже обработчики прерываний UART'ов тоже статические члены класса.

Проект без RTOS делать я уже пробовал (просто закомментировал лишнее), такой вариант работает корректно. Не думаю что эффект вызывает ошибка в компиляторе, во всяком случае обработчик прерывания не выкидывается и его вызов в таблице векторов прерываний на месте. Сегодня проверю влияет ли на спецэффекты scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE, о результатах отпишусь.

 

Проверил, прерывания USART1 обрабатываются корректно при scmRTOS_CONTEXT_SWITCH_SCHEME 1 если в конфигурации RTOS установить scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE 1

Изменено 15 марта, 2013 пользователем ex_AlexG

[WHILE 0]

Проверил, прерывания USART1 обрабатываются корректно при scmRTOS_CONTEXT_SWITCH_SCHEME 1 если в конфигурации RTOS установить scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE 1

 

две недели мотался по командировкам,было не до проекта.

Сейчас проверил- я ошибался,а правы _Артём_ ex_AlexG.

то есть это глюк RTOS.

А кто поддерживает ветку IAR AVR? ReAl?

Что-то его не видно...

В качестве баг-репорта прикладываю минимальный проект.

 

TEST.TAR

TEST.RAR

[Сергей Борщ 119]

Что-то его не видно...

Он старался помогать. Но после нескольких хамских выпадов в его адрес в последнее время решил тратить время на что-нибудь более полезное для себя.

[WHILE 0]

Он старался помогать. Но после нескольких хамских выпадов в его адрес в последнее время решил тратить время на что-нибудь более полезное для себя.

 

На форуме?! Или...

В любом случае очень жаль.

 

[WHILE 0]

мда,не идет у меня прект,хоть тресни.

На тестовом проекте при включении scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE 1 прерывания USART1 обрабатываются,в боевом проекте все равно нет.Хотя они точно возникают,но программа не аходит в обработчики прерываний.

Ладно, попытался включить прямую передачу управления #define scmRTOS_CONTEXT_SWITCH_SCHEME 0 -

не компилируется вовсе, линкер в ассемблерном файле OS_Target_asm.s90 не видит определения os_context_switcher и os_context_switch_hook.

Короче, все плохо.

Придется переписывать код в безосевом варианте,наверно...

 

 

[Артём__ 0]

На тестовом проекте при включении scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE 1 прерывания USART1 обрабатываются,в боевом проекте все равно нет.

Сравните конфигурации проектов (scmRTOS_CONFIG.h).

 

Хотя они точно возникают,но программа не аходит в обработчики прерываний.

Откуда это известно?

Обработчики-то есть в программе?

 

Ладно, попытался включить прямую передачу управления #define scmRTOS_CONTEXT_SWITCH_SCHEME 0 -

не компилируется вовсе, линкер в ассемблерном файле OS_Target_asm.s90 не видит определения os_context_switcher и os_context_switch_hook.

Что линкеру их обоих надо? Сомнительно как-то...

Или os_context_switch_hook - это context_switch_user_hook? Тогда в конфиге задайте

#define  scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE  0

Или определите хук в своём коде. Только зачем он вам...

 

Короче, все плохо.

Думаю, проблема у вас также с файлом OS_Target_asm.s90 - макросы scmRTOS_CONTEXT_SWITCH_SCHEME и другие не доходят до ассемблера, и возможно получается так, что в случае с прямой передачей линкер не может найти os_context_switcher и выдаёт ошибку, а в случае переключения через прерывание не линкует os_context_switch_hook и заменяет его на RETI (попробуйте убрать галку в настройках проекта которая заполняет неиспользуемые прерывания командой возврата - выскочит ошибки линкера?).

Наверное нужно задать в настройках проекта пути к файлам конфигурации или прописать в OS_Target_asm.s90 что-то типа такого:

#include "<полный путь к файлу>\scmRTOS_CONFIG.h"

#include "<полный путь к файлу>\scmRTOS_TARGET_CFG.h"

 

[WHILE 0]

_Артём_ тестовый проект с прямой передачей управления собирается-была моя ошибка.

Сейчас после вашего поста заметил интересную вещь-в боевом проекте пофигу,какую я выбору схему вызова планировщика-проект не перекомпилируется.Даже если вообще закомментирую define scmRTOS_CONTEXT_SWITCH_SCHEME проект все равно собирается!!

Тестовый ессно на такое ругается что макрос должен быть определен.

Я понимаю,что ошибка у меня вот только где??

 

 

[Артём__ 0]

_Артём_ Даже если вообще закомментирую define scmRTOS_CONTEXT_SWITCH_SCHEME проект все равно собирается!!

Я понимаю,что ошибка у меня вот только где??

Наверное вы меняете scmRTOS_CONFIG.h от другого проекта.

[WHILE 0]

Наверное вы меняете scmRTOS_CONFIG.h от другого проекта.

да нет,это я проверил сразу.

но сейчас с утра сделал clean project и factory settings , вернул руками свои настройки и все заработало!!!

но с абсолютно одинаковым кодом и вызовом шедулера через программное прерывание среднее время пинга равно примерно 130ms, а при прямой передаче управления- 5ms!!!. Разница в скорости в 20 с лишним раз.Похоже,из-за постоянного висения в прерывании SPM_READY.

Пока меня такой вариант устраивает, мне сильно не хотелось возвращаться к ручному закату солнца(безосевой вариант).

 

[Артём__ 0]

но с абсолютно одинаковым кодом и вызовом шедулера через программное прерывание среднее время пинга равно примерно 130ms, а при прямой передаче управления- 5ms!!!. Разница в скорости в 20 с лишним раз.Похоже,из-за постоянного висения в прерывании SPM_READY.

А прерывания USART1 при этом работают?

 

P.S. Если scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE задать 1, время ответа на пинг уменьшается или всё работать перестаёт?

[WHILE 0]

А прерывания USART1 при этом работают?

 

да,боевой проект полностью заработал.

 

P.S. Если scmRTOS_CONTEXT_SWITCH_USER_HOOK_ENABLE задать 1, время ответа на пинг уменьшается или всё работать перестаёт?

при каком режиме шедулера?

[Артём__ 0]

при каком режиме шедулера?

С прерыванием на векторе SPM_READY.