scmRTOS + XMEGA, порт scmRTOS для XMEGA Опции

[quarter2]

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

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

[ReAl]

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

[SWD]

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

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

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

[ReAl]

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

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

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

[SWD]

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

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

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

[ReAl]

В файле 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]

В файле 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]

В файле OS_Target_asm.s90 заботливо описаны все RAMP регистры:
...
Сохранение их в контексте не увидел ).

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

В uC/OS-II сохраняются RAMPD, RAMPX, RAMPZ, EIND. Интересно, почему не сохраняется RAMPY?

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

[SWD]

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

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

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

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

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

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

Похоже, придётся для XMEGA менять тип указателя стека процесса.

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

[ReAl]

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

Зачем? Общего достаточно много.
Да, отличия немного больше, чем между мега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]

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

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

Прикрепленные файлы

 eeprom.rar ( 3.25 килобайт ) Кол-во скачиваний: 24

 

[ReAl]

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

Зачем ???

[quarter2]

Зачем ???

проблема есть реально, если на время записи в еепром не запрещать прерывание - данные могут записаться некорректно.
после того как начал использовать вышеприведённый файл - проблема устранилась.
вот здесь этот вопрос обсуждается
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

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

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

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

Вот пример записи в еепром из даташита на Atmega128:

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

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

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

[quarter2]

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

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

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

Есть ни что иное, как запрещение прерываний на время окончания записи в ЕЕПРОМ

Внимательно читайте даташит и включайте голову. Это запрещение прерываний на две команды запуска процесса записи, 4 такта.

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

В IAR EWAVR 5.50 есть ключевое слово __eeprom. eeprom.s90 пора забыть еще в версии 1.26. Ждать окончания записи можно и с разрешенными прерываниями.

[quarter2]

Внимательно читайте даташит и включайте голову. Это запрещение прерываний на две команды запуска процесса записи, 4 такта.

Про пример из даташита - согласен. В примере как раз прерывания отключаются на время запуска процесса записи в ЕЕПРОМ.
Но в файле eeprom.s90 как раз прерывания отключаются на время окончания записи в ЕЕПРОМ:
;----------------------------------------------------------
; ?eewait
;
; Wait for previous eeprom write operation to complete
;
; SIZE: 6 bytes

RSEG CODE:CODE:NOROOT(1)
?eewait:
CLI
SBIS EECR,EEWE ; Loop until previous write is completed
RET
OUT SREG,T0
RJMP ?eewait

В IAR EWAVR 5.50 есть ключевое слово __eeprom. eeprom.s90 пора забыть еще в версии 1.26.

Неправильно. Все переменные, которые объявлены ключевым словом __eeprom при компиляции для работы с областью памяти ЕЕПРОМ используют файл
eeprom.s90

Ждать окончания записи можно и с разрешенными прерываниями.

Если бы не наступал на эти грабли - не поднимал бы вопрос. Без запрещения прерываний на время окончания записи есть вероятность некорректной записи данных в область ЕЕПРОМ

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

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

Неправильно. Все переменные, которые объявлены ключевым словом __eeprom при компиляции для работы с областью памяти ЕЕПРОМ используют файл
eeprom.s90

Не совсем так - они используют функции из библиотеки. Возможно, источником при компиляции библиотеки является этот самый eeprom.s90. Если вы добавите этот файл в проект, то его функции заменять одноименные библиотечные. Давно не пользуюсь ИАРом для AVR, не могу посмотреть что он там берет из библиотеки. Посмотрел старый проект - использовался компилятор версии 2.28, прерывания мною не запрещались, прерывания шли довольно активно, сбоев при записи не было.

Без запрещения прерываний на время окончания записи есть вероятность некорректной записи данных в область ЕЕПРОМ

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

[quarter2]

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

На IAR EWAVR только что откомпилил простенькую программку с записью в ЕЕПРОМ, при это файл eeprom.s90 в проект не включал. В дебаг-режиме увидел, что линкер точно подставляет в выходной код строки из C:\Program Files\IAR Systems\Embedded Workbench 5.5\avr\src\lib\eeprom.s90

Возможно вы используете (хотя бы и на чтение) __eprom-переменные в прерываниях, в этом случае - да, будут проблемы. Но это уже не проблема прерываний, а неверное архитектурное решение.

Нет, в прерываниях __eprom-переменные не использую. При этом ЕЕПРОМ случайным образом, то пишется правильно, то с ошибками. Если включаю в проект файл eeprom.s90, в котором отключаются прерывания - данные в ЕЕПРОМ пишутся абсолютно правильно.

[SWD]

Здравствуйте.
scmRTOS работает на ATxmega128A1 (спасибо ReAl за подсказки).
Пока в контексте сохраняются не все RAMP регистры (пока не нужны).
Возникли трудности с многоуровневым контроллером прерываний. Критические секции вставил и в SYS_TIMER_CRIT_SECT() и в обёртки TISRW/TISRW_SS. Уровни всех прерываний установлены LO, при установке уровня прерывания системного таймера MED через пару секунд все перестает работать.
У кого какие мысли по этому поводу?, как заставить ОСь работать с различными уровнями прерываний?

[SWD]

Добавил сохранение в контекст RAMPD и RAMPX.
Проблему прерываний решил установкой уровня программного прерывания "HI".
Возможно, есть и другие решения …, предположительно два … )

[ReAl]

Возникли трудности с многоуровневым контроллером прерываний. Критические секции вставил и в SYS_TIMER_CRIT_SECT() и в обёртки TISRW/TISRW_SS. Уровни всех прерываний установлены LO, при установке уровня прерывания системного таймера MED через пару секунд все перестает работать.
У кого какие мысли по этому поводу?, как заставить ОСь работать с различными уровнями прерываний?

Надеюсь, доберусь до этого где-то в середине марта.
Раньше никак, хотя всё думал «ну вот в ближайшие выходные».

[quarter2]

Вопрос к разработчикам scmRTOS:
1. почему исходники не содержат __watchdog_reset() хотя бы через #define ?
каждый раз после апдейта приходится практически во всех файлах после while и for вставлять __watchdog_reset()
2. было бы неплохо внести дополнения в описание класса process:
template<TPriority pr, size_t stack_size, size_t rstack_size>
class process : public TBaseProcess
{
public:
INLINE_PROCESS_CTOR process();

int StackFree() {
word Free = 0;
for(;;) { // stack always has non-0xAB items.
if( Stack[Free] != 0xAB )
return Free;
++Free;
}
}

int StackUsed() { return stack_size - StackFree(); }

OS_PROCESS static void exec();

private:
stack_item_t Stack [stack_size/sizeof(stack_item_t)];
stack_item_t RStack[rstack_size/sizeof(stack_item_t)];
};

template<TPriority pr, uint16_t stack_size, uint16_t rstack_size>
process<pr, stack_size, rstack_size>::process() : TBaseProcess( &Stack[stack_size/sizeof(stack_item_t)]
, &RStack[rstack_size/sizeof(stack_item_t)]
, pr
, reinterpret_cast<void (*)()>(exec)
#if scmRTOS_DEBUG_ENABLE == 1
, Stack
, RStack
#endif
)
{
stack_item_t *pDst = Stack;
word Size = StackPointer - Stack;
while(Size)
{
*pDst++ = 0xAB;
--Size;
}
}

т.к. StackUsed() и StackFree() очень сильно помогают при отладке

[ReAl]

1. почему исходники не содержат __watchdog_reset() хотя бы через #define ?
каждый раз после апдейта приходится практически во всех файлах после while и for вставлять __watchdog_reset()

1. Назачем нужен WDT, который тупо сбрасывается во всех цилах?
2. Где в потрохах scmRTOS есть циклы, в которых управление задерживается на время, критичное с точки зрения успевания сбросить WDT ?

2. было бы неплохо внести дополнения в описание класса process:

Контроль стеков и профилировщик добавлены в ветке репозитория branches/pre-v400, которая в скором времени превратится в scmRTOS v4.00

[_Артём_]

Здраствуйте.
Попробовал недавно scmRTOS - понравилось, но толку...для xmeg поддержки нет, а хотелось бы.
Появилось желание перенести версию 3.10 на хмегу. Но возникло столько вопросов и непонятных
моментов, что кажется хотелки так хотелками и остануться...
Попытаюсь здесь изложить моменты которые, как мне кажется нужно поменять в версии и
вызывающие у меня сомнения.
хотелось бы увидеть критику/советы как сделать лучше/как делать не надо, тд и тп.

Общие для разных схем переключения контекста моменты.
1. Функции SetDataSP/GetDataSP:

Заменить на (для начала сгодится, хотя лишний call/ret, но как лучше не нашёл):

Код

GetDataSP:
    mov        R16, R28
    mov        R17, R29
    ret
SetDataSP:
    mov        R29,R17
    mov        R28,R16
    ret

и соотв.

Код

extern "C" {
    TStackItem* GetDataSP();
};

extern "C" {
    void SetDataSP(TStackItem* sp);
};

2. Добавить в контекст RAMP_XYD. С этим понятно.
3. Были тут высказаны идеи о включении в контекст
регистра разрешённых прерываний, но мне кажется что это необязательно.
Или нет?

I. Схема переключения контекста по прерыванию.

1. Добавить запрет прерыванию после перехода на вектор ContextSwitcher_ISR,
но пока не понял куда именно добавить чтоб и наверняка и критическая секция
была как можно короче?

Код

     save_SREG
     cli; запрет прерываний
     save_SP
     save_regs
     save_SFRS
    
;cli; запрет прерываний или здесь правильней?
     mov   r16,r28                    ; load current stack pointer
     mov   r17,r29
                            ; as argument
    
     xcall OS_ContextSwitchHook          ;
     mov   r28,r16                    ; set next stack pointer
     mov   r29,r17                    ; from return value

2. Ещё совершенно непонятный для меня момент: каким уровнем лучше расположить
ContextSwitcher_ISR? Или не это непринципиально, а атомарность переключения?

С этой схемой как бы всё. Или нет? Тогда что я упустил?

II. Схема с прямой передачей управления.

1. Прерывания с TISRW_SS

Если я правильно понял, то в мегах выход из прерывания при переключении
реализуется таким путём:

Код

переход на вектор прерывания->
функция прерывания->
вариант 1: перепланировка не нужна->reti
вариант 2: перепланировка нужна->OS_ContextSwitcher->ret

Если использовать прерывания, использующие сервисы ОС, только одного уровня,
то можно так:

Код

OS_ContextSwitcher:

     save_SREG
     save_SP
     save_regs
     save_SFRS


     mov  r30,r16; Curr_SP_addr
     mov  r31,r17;
     std  Z+0,r28; save process's Stack Pointer
     std  Z+1,r29;
    

    

     mov  r28,r18; load next process Stack Pointer
     mov  r29,r19;
    
     lds  R16, 0x00A0; PMIC.STATUS
     andi R16, 7
     BRNE Int_RestoreContext    
      
L_RestoreContext:

      
     restore_SFRS
     restore_regs
     restore_SP
     restore_SREG

     ret
    
Int_RestoreContext:
     restore_SFRS
     restore_regs
     restore_SP
     restore_SREG

     reti

Но решение какое-то ограниченное...
Попробовал изменить TISRW_SS

CODE

class TISRW_SS
{
public:

INLINE TISRW_SS(byte int_level) {
#if scmRTOS_CONTEXT_SWITCH_SCHEME==0
CurrentInterruptLevelMask=~int_level;
CurrentInterruptLevelMask&=scmRTOS_INTERRUPT_LEVEL_MASK;
#endif
ISR_Enter();
}

INLINE ~TISRW_SS() { ISR_Exit(); }

private:
#if scmRTOS_CONTEXT_SWITCH_SCHEME==0
byte CurrentInterruptLevelMask;
#endif
//-----------------------------------------------------
INLINE void ISR_Enter() // volatile
{
TCritSect cs;
if(Kernel.ISR_NestCount++ == 0)
{
SavedSP.DataSP = GetDataSP();
SavedSP.ReturnSP = GetReturnSP();
SetISRStackPointers();
}

#if scmRTOS_CONTEXT_SWITCH_SCHEME == 1
DisableContextSwitch();
#endif
}
//-----------------------------------------------------
INLINE void ISR_Exit()
{
TCritSect cs;
if (--Kernel.ISR_NestCount==0) {
SetReturnSP(SavedSP.ReturnSP);
SetDataSP (SavedSP.DataSP);
}
#if scmRTOS_CONTEXT_SWITCH_SCHEME==0
if (PMIC.STATUS&CurrentInterruptLevelMask) return ;
#endif
Kernel.SchedISR();
}
//-----------------------------------------------------
};

Но тоже какая-та ерунда: теперь получается что все прерывания
одного уровня должны либо использовать, либо не использовать TISRW_SS.
В общем тоже костыль получился, хотя и выглядит работающим (см. приложение).

В связи с этой проблемой вопрос: можно ли заставить IAR сделать функию
прерывания ещё и __monitor (возможно ли это в хмегах вообще - запретить прерывание более
высокого уровня след. командой после перехода с вектора прерывания и будет ли этот
запрет отрабатываться)? Этот вариант завтра попробую.

Спасибо.
 xm.rar ( 539.45 килобайт ) Кол-во скачиваний: 115

[ReAl]

Ой-ой-ой... Мне самому xmega до сих пор как-то не нужна, вот я и тяну.
В очередной раз достал наверх макетку с atxmega128a1, помигал светодиодом, буду искать время на scmRTOS на ней.

[_Артём_]

Ой-ой-ой...

Это вы о чём?
По поводу моей писанины или вообще?

Мне самому xmega до сих пор как-то не нужна, вот я и тяну.

Это понятно.
STM8 лучше xmeg-и?

В очередной раз достал наверх макетку с atxmega128a1, помигал светодиодом, буду искать время на scmRTOS на ней.

Ждём.

[a9d]

Стмка на порядок дешевле. И там есть свои вкусности. Например можно подгружать с внешней памяти функции в оперативку и выполнять их.
Но у них есть большой минус связанный с ихним трехуровневым конвейером. Из за него нельзя делать софтварные задержки и будут проблемы с софтварным 1-wire.

[_Артём_]

Стмка на порядок дешевле.

Реально на порядок? Посмотрю.

Например можно подгружать с внешней памяти функции в оперативку и выполнять их.

Жаль в АВР такого нет. Полезная возможность.

Но у них есть большой минус связанный с ихним трехуровневым конвейером. Из за него нельзя делать софтварные задержки и будут проблемы с софтварным 1-wire.

Зачем программно? Аппаратные ресурсы надо задействовать.

[a9d]

stm8 настолько дешевые, что стоят почти как stm32. И тут стоит вопрос нахрена их брать?
В ST конечно умные дядьки сидят и они выпустили ультра дешевые stm8 с менее прочной флешпамять(100 гарантированных циклов записи), но полностью совместимый с полноценными микроконтроллерами. Т.е. проект разрабатываешь на нормальном камне а в серию идут дешевые мк.

[ReAl]

Это вы о чём?

Это по поводу моего «в очередной раз достал наверх». Уже ведь лежала наверху, но опять в отложения прошлых веков попала.

STM8 лучше xmeg-и?

Свои приятности есть. Хмегу я внимательно не смотрел, на первый взгляд на уровне.

Реально на порядок?

В двоичной системе счисления.

[_Артём_]

stm8 настолько дешевые

Если учесть время на освоение, то нек и дешево.

Т.е. проект разрабатываешь на нормальном камне а в серию идут дешевые мк.

Интересная рацуха.

В двоичной системе счисления.

Тогда верю.

[ReAl]

В ST конечно умные дядьки сидят и они выпустили ультра дешевые stm8 с менее прочной флешпамять(100 гарантированных циклов записи), но полностью совместимый с полноценными микроконтроллерами. Т.е. проект разрабатываешь на нормальном камне а в серию идут дешевые мк.

Какие?
ST7? Так они послабее по периферии. Да и система команд попроще.
STM32? Так они другие.
В любом случае после отладки — заново отлаживать.

100 циклов стирания+записи не важны для серийного изделия, Оно один раз пишется. Ну два — тестово-калибровочная программа и рабочая.
У альтеровских MAX3000 тоже 100 циклов. «И ничё». Никто не парится.
УФ ПЗУ-шки вообще 25 циклов имели, они что — менее надёжны из-за этого?
Куча циклов флеша нужна только для эмуляции EEPROM.

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

Зато у STM8 для некоторых SFR в железе два регистра с прямым и инверсным значением. Если вдруг они перестанут совпадать — происходит сброс «EMC reset».
Не похоже на экономию для ультрадешёвости, правда?

[a9d]

Как раз по этому они и умные.
Другие не догадались выпускать две версии одного и тогоже микроконтроллера. Так можно экономить кучу денег при серийном производстве.

stm32 и stm8 жутко похожи. Это и не удивительно.
Но stm8 все равно из серии нахрена? Есть же cortex-m0. Цена, энергопотребление, средства разработки - с этим все хорошо.
А вот у stm8 с компилятором немного похуже.

[Anatoly74]

Что-то тема порта XMega давно не обсуждалась. Какие-нибудь есть подвижки в данном направлении? Уж больно проц. хорош и востребован.

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

Уж больно проц. хорош и востребован.

Чем хорош? Там где не хватает мелких мег Cortex гораздо лучше хмеги по цене, скорости, памяти и прочему. Там, где хватет мелких мег - они гораздо лучше хмег по цене.

Исходники scmRTOS открыты. Хотите - пишите порт и добро пожаловать в коллектив разработчиков. Из действующих разработчиков ОС никто хмеги не применяет и не собирается, поэтому писать порт нет ни времени, ни желания.