Всем доброго времени суток!
Кто-нибудь запускал scmRTOS на XMEGA ?
У меня без проблем scmRTOS работает на atmega128.
Хочу развести плату под atXmega256, но нет уверенности, что scmRTOS сможет работать на этом кристале.
Пробую свои проекты с scmRTOS (работающие на atmega128) откомпилировать (IAR EWAVR 5.50) под Xmega256.
Пока что результаты отрицательные.

Сообщение отредактировал quarter2 - Jan 20 2011, 07:52

Пока туда не лазил. Точнее, по диагонали просмотрел описание xmega, но в приложении к scmRTOS не осмысливал.
EWAVR так и вообще совсем недавно поставил.

Пытаюсь запустить scmRTOS на ATxmega128A1.
Вопросы к автору:
1. Контроллер имеет многоуровневый контроллер прерываний, какие трудности это повлечет в части работы scmRTOS?
2. Стек :

Цитирую:
«Адрес возврата может быть представлен двумя или тремя байтами, что зависит от размера памяти микроконтроллера. У МК с памятью программ 128 кбайт и менее адрес возврата двухбайтный, поэтому, указатель стека декрементируется/инкрементируется на два. У тех же микроконтроллеров, которые оснащены памятью программ размером более 128 кбайт, адрес возврата трехбайтный, а декрементирование/инкрементирование SP выполняется на три.»

Какие необходимо внести изменения в исходный код платформеннозависимой части?

Я веду AVR/GCC порт и потихоньку подхватываю AVR/IAR.
По 2/3 байта - это похоже на то, что нужно для atmega256x (в группе гугла проскочило). Добавить под условную компиляцию запихивание в стек (возвратов) старшего байта в конструкторе TBaseProcess в Os_Target_cpp.cpp
Для Xmega кроме этого надо править сохранение/восстановление контекста, так как добавляются RAMPX, RAMPY, RAMPD.
Ну и EIND, как и для меги256х.

А вот как раз над контроллером прерываний я ещё не задумывался. Отметил для себя, что место тонкое и требует внимания, но дальше не пошёл.

В ближайшие выходные собирался проверить по-минимуму в железе на atmega2561.
До следующих постараюсь опять почитать описание Xmega.

Спасибо, я так и думал, осталось разобраться, как это сделать -). К концу недели должно прийти железо (ATAVRXPLAIN), на следующей неделе постараюсь на нем отладить …

В файле OS_Target_asm.s90 заботливо описаны RAMP регистры XMEGи но их сохранение в контексте не производится …, интересно, кто позаботился и зачем? -)

С вложенными приоритетными прерываниями пока вопрос открыт. Если я правильно понимаю, вложенные прерывания или не поддерживаются или не должны содержать вызовы системных функций? Очевидно, что системное прерывание должно быть самым низкоприоритетным. Если не прав, поправьте, пожалуйста.

Они (в IAR-порте) сохраняются/восстанавливаются не в макросах save, а прямым текстом ниже, в коде функций.
и так далее. В avr-gcc сохраняются в основных макросах save_context. Это всё «косметика», вохможно, позже сведу к единообразному виду.

Для avr-gcc исправления для mega256x я ужен проверил в железе и вбросил в ветку pre-v400. Для IAR ещё не проверял, вброшу позже.

Вложенные прерывания и на обычных AVR могут быть, см class TNestedISRW в scmRTOS_TARGET_CFG.h

Системные вызовы имеют критические секции, котрые делаются через запрет всех прерываний битом I в SREG, так что наличие любых вложенных прерываний не страшно для их работы. Нужно внимательно просмотреть обёртки TISRW/TISRW_SS, возможно, для xmega ISR_Enter() тоже придётся делать с критической секцией, так как у Xmega бит I не сбрасывается при входе в прерывание.

Возможно, в сохраняемый контекст процесса также стоит включить тот регистр, в котором маски разрешённых уровенй прерывания. Собственно, у «более других» процессоров, бывает, прямо в статусном регистре сидит не один бит I, а несколько бит с уровнем приоритета процессора.
Пример.
Высокоприоритетный процесс. Настолько высоко, что при свой работе запрещает низкоприоритетные прерывания, шоб не мешались. Но если этот процесс засыпает по sleep/wait/..., то у пришедшего ему на смену менее приоритетного процесса те уровни прерываний должны бы быть и разрешены.
Просится при старте ОС разрешать все уровни прерываний, а уж там если кто-то что-то запретит, так оно вместе с ним будет из контекста восстанавливаться, а у оcтальных — по умолчанию. И лучше всего это сделать через контекст.
Я для Xmega ничего не писал и очень уж внимательно описание не читал, но такая мысль возникла.

Ах, да, ещё SYS_TIMER_CRIT_SECT() в OS_Target.h тоже на тему возможности вложенных прерываний без специальных на то разрешений. И это место надо под #ifdef пустить об Xmega-признак.
Надо всё внимательно просмотреть.

В файле OS_Target_asm.s90 заботливо описаны все RAMP регистры:

#define SREG 0x3F
#define SPH 0x3E
#define SPL 0x3D
#define RAMPX 0x39
#define RAMPY 0x3a
#define RAMPZ 0x3b
#define EIND 0x3c

Сохранение их в контексте не увидел ).

В uC/OS-II сохраняются RAMPD, RAMPX, RAMPZ, EIND. Интересно, почему не сохраняется RAMPY?
Если интересен порт uC/OS-II для XMEGA, готов куда ни будь его выложить.


Из описания ОСи:
"ЗАМЕЧАНИЕ. В текущей версии scmRTOS при использовании пере-
дачи управления на основе программного прерывания вложенные
прерывания не поддерживаются. Точнее, не поддерживаются вло-
женные прерывания, где задействуются механизмы ОС – главным
образом, касающиеся планировки процессов. Остальные преры-
вания могут быть использованы в обычном порядке."

Исходники scmRTOS пока не переварил … )

Описать наперёд никто не запрещает :-)
RAMPZ сохраняется, цитата выше из исходников v3.10

О, кстати, для IAR с RAMPY нужно внимательно, там же Y - укаатель стека данных «намертво». Похоже, придётся для XMEGA менять тип указателя стека процесса.

Может лучше отдельный порт?


Маловато будет ))


Смотрю на него внимательно ..., не знаю что с ним делать . Что значит "намертво"?


На какой? )). ( ... Может лучше отдельный порт?) )))

Зачем? Общего достаточно много.
Да, отличия немного больше, чем между мега32 и мега256х, но не такие и большие. Как по мне, то вариант с #ifdef может оказаться проще и в сопровождении, и в использовании.

Для ATmega128 этого было достаточно, а Xmega никто и не обещал :-)

То, что Y всегда указатель стека данных.
В avr-gcc Y - это указатель стековго кадра — тогда, когда это нужно. Туда копируется SP и данные на общем стеке адресуются относительно Y. Что-то похожее на использование регистра BP в x86.
Поэтому с точки зрения порта scmRTOS и пара Y, и RAMPY идут на тех же правах, что и X, Z, RAMPX, RAMPZ, за контекст отвечает SP.
А у IAR стековдва и «основной» для scmRTOS стек — CSTACK, т.е. RAMPY:YH:YL
Соответственно, в состоянии процесса храниться должно такое расширенное состояние.
Для простоты можно сохранять uint32_t. Для экономии места и, возможно, времени - 3-байтовую структуру uint8_t page; uint16_t sp;

Или считать, что стеки всех процессов всегда в нижних 64К (пока нет Xmega с внутренним ОЗУ больше, это синоним "стеки во внутреннем, быстром, ОЗУ") и думать, что RAMPY всегда 0.

p.s. Порт AVR/IAR для mega256x проверен и вброшен в ветку pre-v400 (ревизия 306, дальше могут пойти изменения в других местах scmRTOS).

Может быть вопрос немного не в тему, но не хочется создавать товый топик.
Как scmRTOS относится к записи данных в EEPROM?
Ведь для корректной записи в EEPROM необходимо отключать прерывания на несколько милисекунд.
Я использую специально для этих целей файл eeprom.s90
Не окажет ли это влияние на работу операционки?

Сообщение отредактировал quarter2 - Feb 8 2011, 15:53

Зачем ???

проблема есть реально, если на время записи в еепром не запрещать прерывание - данные могут записаться некорректно.
после того как начал использовать вышеприведённый файл - проблема устранилась.
вот здесь этот вопрос обсуждается
http://electronix.ru/forum/lofiversion/index.php/t16140.html
http://electronix.ru/forum/index.php?showt...amp;#entry71028
Вот пример записи в еепром из даташита на Atmega128:
Assembly Code Example
in r16, SREG ; store SREG value
cli ; disable interrupts during timed sequence
sbi EECR, EEMWE ; start EEPROM write
sbi EECR, EEWE
out SREG, r16 ; restore SREG value (I-bit)
C Code Example
char cSREG;
cSREG = SREG; /* store SREG value */
/* disable interrupts during timed sequence */
__disable_interrupt();
EECR |= (1<<EEMWE); /* start EEPROM write */
EECR |= (1<<EEWE);
SREG = cSREG; /* restore SREG value (I-bit) */

Сообщение отредактировал quarter2 - Feb 9 2011, 08:17

Неверно. Прерывания во время записи не мешают.
Покажите, где тут запрещение прерываний на время записи, где тут миллисекунды запрещенных прерываний?
Все вменяемые компиляторы имеют встроенные инструменты делать то же самое без этого файла.

The following example shows how this can be used to avoid interrupts during the
timed EEPROM write sequence
/* disable interrupts during timed sequence */
__disable_interrupt();
EECR |= (1<<EEMWE); /* start EEPROM write */
EECR |= (1<<EEWE);
SREG = cSREG; /* restore SREG value (I-bit) */

Есть ни что иное, как запрещение прерываний на время окончания записи в ЕЕПРОМ
Время записи в ЕЕПРОМ в Atmega128 согласно тому же даташиту:


Table 2. EEPROM Programming Time
EEPROM Write (from CPU) = 8.5 ms



В IAR EWAVR 5.50 в файле eeprom.s90 нет запрещений прерываний на время ожидания окончания записи в ЕЕПРОМ

Сообщение отредактировал quarter2 - Feb 9 2011, 09:06