[IgorKossak 0]

Подскажите, а как пользоваться SVN под proxy? Есть проблемы с подключением к репозиторию, а вот как их решить - неразобрался. :(

На сайте http://subversion.tigris.org/ в поле поиска набираете proxy и вперёд.

[dxp 32]

Поднята и действует система ежедневних снапштотов. В снапшот входит порт+пример - тот же комплект, что и на download странице проекта. Берется это здесь. Дополнительная инфа тут.

[ReAl 0]

В порт avr-gcc добавлены недостающие примеры.

В примерах 1 и 3 для scmRTOS_CONTEXT_SWITCH_SCHEME == 1 используется преривание SPM_vect, для примера 2 сделан применявшийся ранее вариант прерывания по компаратору, пусть будут оба.

 

Обсуждение использования разных прерываний и логики их выбора где-то там:

http://electronix.ru/forum/index.php?showt...43646&st=15

там и продолжать, если что.

[Gradient 1]

Нашел небольшую недоработку.

 

При изменении значений параметров:

 

 

 

scmRTOS_IDLE_PROCESS_DATA_STACK_SIZE

scmRTOS_IDLE_PROCESS_RETURN_STACK_SIZE

 

 

 

(в версии 3.00-beta под AVR) возникает ошибка компиляции.

 

Приходится править вручную функцию:

 

OS_PROCESS void process<prIDLE, **, **>::Exec()

 

 

 

И если не сложно, подскажите где определяется размер стека прерываний?

[IgorKossak 0]

(в версии 3.00-beta под AVR) возникает ошибка компиляции.

 

И если не сложно, подскажите где определяется размер стека прерываний?

Эти параметры определяются в scmRTOS_TARGET_CFG.h.

Другое дело, что в соответствующем месте OS_Target_cpp.cpp вместо определений в версии 3.00 стояли численные значения.

В версии 3.05 уже исправлено.

[Gradient 1]

Спасибо.

Но это всё пол беды ... Не могу преодолеть трудность.

Запускаю прием данных по прерыванию от SPI. Система падает.

Причём, чёткой закономерности нет. Может работать очень долго а иногда после первого же байта и умирает.

Перевёл всё процессы в Sleep(0) чтоб не мешали, отключил всё лишнее, на вход поступает только SPI сигнал блоками по 8 байт 1 раз в секунду. Обработчик прерывания упрощён для отладки и выглядит так:

 

//SPI Interrupt Handler

#pragma vector = SPI_STC_vect

OS_INTERRUPT void SPI_ISR(void)

 

{

//класс обёртка

OS::TISRW_SS ISRW;

 

unsigned char temp;

 

//Забираем принятые данные из регистра SPDR

temp = SPDR;

 

//Загружаем следующий байт для передачи

//SPDR = 0xAA;

 

//импульс на осц для контроля

CLRBIT(PORTA,LED_AVR);

__delay_cycles(10);

SETBIT(PORTA,LED_AVR);

}

 

Аппаратно сдвиговый регистр SPI интерфейса работает, видно как он передаёт пустой байт вместо 0xAA.

Но прерывание не происходит.

Что можно сделать?

Изменено 4 ноября, 2008 пользователем sevstels

[ReAl 0]

И если не сложно, подскажите где определяется размер стека прерываний?

Зависит от применяемого класса в обработчике

 

TISRW - прерывание полностью работает на стеке прерванного процесса

 

TISRW_SS (Separate Stack) - прерывание сохраняет то, что счёл нужным компилятор, на стеке процесса затем переключается на отдельный стек.

Что за стек - надо смотреть конкретный порт. Порты avr использует основной стек (на котором начинается работа main), для avr/gcc размер - всё что осталось от памяти после статически размещённых переменных и стеков процессов, для avr/IAR - CSTACK и RSTACK.

 

Думается, TISRW_SS имеет смысл только при разрешении вложенных прерываний (тогда вложенное сразу начнёт работать на отдельном стеке) либо если прерывание вызывает каскад внешних функций, каждая из которых что-то сохраняет на стеке, или для жадных до стека (заводящих там переменные).

Если вложенных прерываний нет, а вызываемих функций нет либо стек не особо расходуется - отдельный стек ничего не сэкономит (а время на переключение займёт).

Разные прерывания могут пользоваться разной обёрткой.

 

p.s. на мой взгляд, тема не для "news:scmRTOS"

Может, для "Начало работы with scmRTOS"

[Gradient 1]

Спасибо :)

 

Нашел где было. Дело оказалось не в софте. Самопроизвольно останавливался кварц.

 

Как начались проблемы ещё год назад в AT90CAN с осц, так и не работает нормально.

 

 

 

 

 

-