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

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

Сообщение отредактировал a9d - Feb 9 2012, 21:59

Вы бы проект выложили что ли...
Может стека не хватает?

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

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


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


Была такая же фигня как-то. Так и не понял что: просто всё стёр и начал занового.
А ведь интересно узнать как можно добится такого эффекта...взять и испортить хорошую вещь.

Проекта нет.
Я скомпелировал шаблон с одним процессом и по юарту шлю байты.
В main 0
В proc1 1

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

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


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

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

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

Я порт 4.0 для AVR и примеры GCC, IAR проверяю на atmega168, atmega64, atmega2561. Пока всё работало.
Давайте мне (real на real.kiev.ua) архив проекта целиком, я попробую разобраться.

Проект отправил.
На меге168pа я в первый раз запустил 4.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, хотя его нет в документации на кристалл.

Сделайте пока правку как в теме по линку.
А я решу что делать дальше.

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

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

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