quarter2 0 19 января, 2011 Опубликовано 19 января, 2011 (изменено) · Жалоба Всем доброго времени суток! Кто-нибудь запускал scmRTOS на XMEGA ? У меня без проблем scmRTOS работает на atmega128. Хочу развести плату под atXmega256, но нет уверенности, что scmRTOS сможет работать на этом кристале. Пробую свои проекты с scmRTOS (работающие на atmega128) откомпилировать (IAR EWAVR 5.50) под Xmega256. Пока что результаты отрицательные. Изменено 20 января, 2011 пользователем quarter2 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 20 января, 2011 Опубликовано 20 января, 2011 · Жалоба Пока туда не лазил. Точнее, по диагонали просмотрел описание xmega, но в приложении к scmRTOS не осмысливал. EWAVR так и вообще совсем недавно поставил. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SWD 0 20 января, 2011 Опубликовано 20 января, 2011 · Жалоба Пытаюсь запустить scmRTOS на ATxmega128A1. Вопросы к автору: 1. Контроллер имеет многоуровневый контроллер прерываний, какие трудности это повлечет в части работы scmRTOS? 2. Стек : Цитирую: «Адрес возврата может быть представлен двумя или тремя байтами, что зависит от размера памяти микроконтроллера. У МК с памятью программ 128 кбайт и менее адрес возврата двухбайтный, поэтому, указатель стека декрементируется/инкрементируется на два. У тех же микроконтроллеров, которые оснащены памятью программ размером более 128 кбайт, адрес возврата трехбайтный, а декрементирование/инкрементирование SP выполняется на три.» Какие необходимо внести изменения в исходный код платформеннозависимой части? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 20 января, 2011 Опубликовано 20 января, 2011 · Жалоба Я веду AVR/GCC порт и потихоньку подхватываю AVR/IAR. По 2/3 байта - это похоже на то, что нужно для atmega256x (в группе гугла проскочило). Добавить под условную компиляцию запихивание в стек (возвратов) старшего байта в конструкторе TBaseProcess в Os_Target_cpp.cpp Для Xmega кроме этого надо править сохранение/восстановление контекста, так как добавляются RAMPX, RAMPY, RAMPD. Ну и EIND, как и для меги256х. А вот как раз над контроллером прерываний я ещё не задумывался. Отметил для себя, что место тонкое и требует внимания, но дальше не пошёл. В ближайшие выходные собирался проверить по-минимуму в железе на atmega2561. До следующих постараюсь опять почитать описание Xmega. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SWD 0 24 января, 2011 Опубликовано 24 января, 2011 · Жалоба Спасибо, я так и думал, осталось разобраться, как это сделать -). К концу недели должно прийти железо (ATAVRXPLAIN), на следующей неделе постараюсь на нем отладить … В файле OS_Target_asm.s90 заботливо описаны RAMP регистры XMEGи но их сохранение в контексте не производится …, интересно, кто позаботился и зачем? -) С вложенными приоритетными прерываниями пока вопрос открыт. Если я правильно понимаю, вложенные прерывания или не поддерживаются или не должны содержать вызовы системных функций? Очевидно, что системное прерывание должно быть самым низкоприоритетным. Если не прав, поправьте, пожалуйста. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 24 января, 2011 Опубликовано 24 января, 2011 · Жалоба В файле 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-признак. Надо всё внимательно просмотреть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SWD 0 25 января, 2011 Опубликовано 25 января, 2011 · Жалоба В файле 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 пока не переварил … ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 25 января, 2011 Опубликовано 25 января, 2011 · Жалоба В файле OS_Target_asm.s90 заботливо описаны все RAMP регистры: ... Сохранение их в контексте не увидел ). Описать наперёд никто не запрещает :-) RAMPZ сохраняется, цитата выше из исходников v3.10 В uC/OS-II сохраняются RAMPD, RAMPX, RAMPZ, EIND. Интересно, почему не сохраняется RAMPY?О, кстати, для IAR с RAMPY нужно внимательно, там же Y - укаатель стека данных «намертво». Похоже, придётся для XMEGA менять тип указателя стека процесса. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SWD 0 25 января, 2011 Опубликовано 25 января, 2011 · Жалоба И это место надо под #ifdef пустить об Xmega-признак. Может лучше отдельный порт? RAMPZ сохраняется ... Маловато будет )) О, кстати, для IAR с RAMPY нужно внимательно, там же Y - укаатель стека данных «намертво». Смотрю на него внимательно ..., не знаю что с ним делать :( . Что значит "намертво"? Похоже, придётся для XMEGA менять тип указателя стека процесса. На какой? )). ( ... Может лучше отдельный порт?) ))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 25 января, 2011 Опубликовано 25 января, 2011 · Жалоба Может лучше отдельный порт?Зачем? Общего достаточно много. Да, отличия немного больше, чем между мега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). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
quarter2 0 8 февраля, 2011 Опубликовано 8 февраля, 2011 (изменено) · Жалоба Может быть вопрос немного не в тему, но не хочется создавать товый топик. Как scmRTOS относится к записи данных в EEPROM? Ведь для корректной записи в EEPROM необходимо отключать прерывания на несколько милисекунд. Я использую специально для этих целей файл eeprom.s90 Не окажет ли это влияние на работу операционки? eeprom.rar Изменено 8 февраля, 2011 пользователем quarter2 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 8 февраля, 2011 Опубликовано 8 февраля, 2011 · Жалоба Ведь для корректной записи в EEPROM необходимо отключать прерывания на несколько милисекунд.Зачем ??? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
quarter2 0 9 февраля, 2011 Опубликовано 9 февраля, 2011 (изменено) · Жалоба Зачем ??? проблема есть реально, если на время записи в еепром не запрещать прерывание - данные могут записаться некорректно. после того как начал использовать вышеприведённый файл - проблема устранилась. вот здесь этот вопрос обсуждается 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) */ Изменено 9 февраля, 2011 пользователем quarter2 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 117 9 февраля, 2011 Опубликовано 9 февраля, 2011 · Жалоба проблема есть реально, если на время записи в еепром не запрещать прерывание - данные могут записаться некорректно.Неверно. Прерывания во время записи не мешают. Вот пример записи в еепром из даташита на Atmega128:Покажите, где тут запрещение прерываний на время записи, где тут миллисекунды запрещенных прерываний? после того как начал использовать вышеприведённый файл - проблема устранилась.Все вменяемые компиляторы имеют встроенные инструменты делать то же самое без этого файла. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
quarter2 0 9 февраля, 2011 Опубликовано 9 февраля, 2011 (изменено) · Жалоба Неверно. Прерывания во время записи не мешают. Покажите, где тут запрещение прерываний на время записи 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 нет запрещений прерываний на время ожидания окончания записи в ЕЕПРОМ Изменено 9 февраля, 2011 пользователем quarter2 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться