Перейти к содержанию
    

Всем доброго времени суток!

Кто-нибудь запускал scmRTOS на XMEGA ?

У меня без проблем scmRTOS работает на atmega128.

Хочу развести плату под atXmega256, но нет уверенности, что scmRTOS сможет работать на этом кристале.

Пробую свои проекты с scmRTOS (работающие на atmega128) откомпилировать (IAR EWAVR 5.50) под Xmega256.

Пока что результаты отрицательные.

Изменено пользователем quarter2

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Пока туда не лазил. Точнее, по диагонали просмотрел описание 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и но их сохранение в контексте не производится …, интересно, кто позаботился и зачем? -)

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В файле OS_Target_asm.s90 заботливо описаны RAMP регистры XMEGи но их сохранение в контексте не производится …, интересно, кто позаботился и зачем? -)
Они (в IAR-порте) сохраняются/восстанавливаются не в макросах save, а прямым текстом ниже, в коде функций.

ContextSwitcher_ISR:
     save_SREG
     save_SP
     save_regs

  #if HAS_RAMPZ == 1
     in  r31,RAMPZ
     st  -Y,r31
  #endif

и так далее. В 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 пока не переварил … )

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

...

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

Описать наперёд никто не запрещает :-)

RAMPZ сохраняется, цитата выше из исходников v3.10

 

В uC/OS-II сохраняются RAMPD, RAMPX, RAMPZ, EIND. Интересно, почему не сохраняется RAMPY?
О, кстати, для IAR с RAMPY нужно внимательно, там же Y - укаатель стека данных «намертво». Похоже, придётся для XMEGA менять тип указателя стека процесса.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И это место надо под #ifdef пустить об Xmega-признак.

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

 

RAMPZ сохраняется ...

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

 

О, кстати, для 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

Не окажет ли это влияние на работу операционки?

eeprom.rar

Изменено пользователем quarter2

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ведь для корректной записи в EEPROM необходимо отключать прерывания на несколько милисекунд.
Зачем ???

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Зачем ???

проблема есть реально, если на время записи в еепром не запрещать прерывание - данные могут записаться некорректно.

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

вот здесь этот вопрос обсуждается

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

проблема есть реально, если на время записи в еепром не запрещать прерывание - данные могут записаться некорректно.
Неверно. Прерывания во время записи не мешают.

Вот пример записи в еепром из даташита на Atmega128:
Покажите, где тут запрещение прерываний на время записи, где тут миллисекунды запрещенных прерываний?

после того как начал использовать вышеприведённый файл - проблема устранилась.
Все вменяемые компиляторы имеют встроенные инструменты делать то же самое без этого файла.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Неверно. Прерывания во время записи не мешают.

Покажите, где тут запрещение прерываний на время записи

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...