[a9d 0]

ОС не стартует.

А точнее управление постоянно передается в main. Он вертится по кругу.

 

В scmRTOS_TARGET_CFG.h все, что нужно, ссылается на iom32u4.h

Изменено 9 февраля, 2012 пользователем a9d

[Артём__ 0]

ОС не стартует.

А точнее управление постоянно передается в main. Он вертится по кругу.

 

В scmRTOS_TARGET_CFG.h все, что нужно, ссылается на iom32u4.h

Вы бы проект выложили что ли...

Может стека не хватает?

[a9d 0]

Кх кх.

ОС не стартует. Проекта еще никакого и нет. Там всего один процесс и ниодного пользовательского прерывания.

[Артём__ 0]

Проекта еще никакого и нет.

Ка же нет, когда вы что-то запускаете.

 

Там всего один процесс и ниодного пользовательского прерывания.

Тем проще разобраться...

 

 

Была такая же фигня как-то. Так и не понял что: просто всё стёр и начал занового.

А ведь интересно узнать как можно добится такого эффекта...взять и испортить хорошую вещь.

 

 

 

 

 

 

[a9d 0]

Проекта нет.

Я скомпелировал шаблон с одним процессом и по юарту шлю байты.

В main 0

В proc1 1

 

На выходе есть только 0.

[Артём__ 0]

Я скомпелировал шаблон с одним процессом и по юарту шлю байты.

Непонятная фраза, обычно файл компилируется (или единица компиляции). А шаблон...чего на свете не бывает...

Компилятор какой кстати?

 

В main 0

В proc1 1

 

На выходе есть только 0.

А OS::Run(); у вас в main есть, и что в конфигах, какое количество процессов?

[a9d 0]

Протестил версию 3.10.

Все работает.

 

Версия 4.0

Не пашет. Постоянно валится в main.

JTAG нет. Отследил только до прерывания таймера. После выхода из него ОС улетает.

[ReAl 0]

Я порт 4.0 для AVR и примеры GCC, IAR проверяю на atmega168, atmega64, atmega2561. Пока всё работало.

Давайте мне (real на real.kiev.ua) архив проекта целиком, я попробую разобраться.

 

[a9d 0]

Проект отправил.

На меге168pа я в первый раз запустил 4.0 , там все нормально. Для того и этого проекта использовался идентичный шаблон.

[ReAl 0]

Похоже, зараза, близкая к тому, что было с ATmega1280/1281. Которая имеет 64 килослова флеша и, соответственно, 2-байтовый PC и отсутствие необходимости в командах EIJMP/EICALL и регистре EIND.

 

Упс! Я до сих пор не вбросил правку этого в репозиторий!

Похоже, в это воскресенье нужно выделить пол дня на подчистки scmRTOS/AVR

 

Проверка __AVR_3_BYTE_PC__ это хорошо, но макрос присутствует начиная с версии avr-gcc 4.1.2, поэтому необходимость резервирования места на стеке для дополнительного байта PC при инициализации начального стекового кадра я определял по EIND. В итоге нужна более сложная проверка. Или, наоборот, более простая — по макросу размера флеша FLASHEND.

Или отказ от поддержки версий до, например 4.3.2.

Там уже есть полный набор __AVR_HAVE_RAMPZ__ __AVR_HAVE_16BIT_SP__ и т.п.

 

Ну так вот. Не знаю, как в других сборках (может зависеть от версии avr-libc), но в имеющейся у меня в файле iom32u4.h есть определение для регистра EIND, хотя его нет в документации на кристалл.

 

Сделайте пока правку как в теме по линку.

А я решу что делать дальше.

 

Наверное, что-то в духе

#if !defined(__AVR_3_BYTE_PC__) && !defined(__AVR_2_BYTE_PC__)
// опереться на FLASHEND < 0x20000
#endif

[ReAl 0]

Вбросил обновление.

«что-то с памятью» — был уверен, что в какой-то из версий avr-gcc поддержка atmega256x уже была, а предопределённых __AVR_*_BYTE_PC__ еще не было. Но они появились синхронно. Так что для 3-го байта и для EIND простая проверка.

 

А вот с RAMPZ, чтобы зря не сохранять/восстанавливать для контроллеров с <= 64K флеша, пришлось сделать с проверкой версии GCC.