Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: ATmega32u4 проблема.
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > scmRTOS
a9d
ОС не стартует.
А точнее управление постоянно передается в main. Он вертится по кругу.

В scmRTOS_TARGET_CFG.h все, что нужно, ссылается на iom32u4.h
_Артём_
Цитата(a9d @ Feb 9 2012, 23:58) *
ОС не стартует.
А точнее управление постоянно передается в main. Он вертится по кругу.

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

Вы бы проект выложили что ли...
Может стека не хватает?
a9d
Кх кх.
ОС не стартует. Проекта еще никакого и нет. Там всего один процесс и ниодного пользовательского прерывания.
_Артём_
Цитата(a9d @ Feb 10 2012, 00:14) *
Проекта еще никакого и нет.

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

Цитата(a9d @ Feb 10 2012, 00:14) *
Там всего один процесс и ниодного пользовательского прерывания.

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


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





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

На выходе есть только 0.
_Артём_
Цитата(a9d @ Feb 10 2012, 00:28) *
Я скомпелировал шаблон с одним процессом и по юарту шлю байты.

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

Цитата(a9d @ Feb 10 2012, 00:28) *
В main 0
В proc1 1

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

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

Версия 4.0
Не пашет. Постоянно валится в main.
JTAG нет. Отследил только до прерывания таймера. После выхода из него ОС улетает.
ReAl
Я порт 4.0 для AVR и примеры GCC, IAR проверяю на atmega168, atmega64, atmega2561. Пока всё работало.
Давайте мне (real на real.kiev.ua) архив проекта целиком, я попробую разобраться.
a9d
Проект отправил.
На меге168pа я в первый раз запустил 4.0 , там все нормально. Для того и этого проекта использовался идентичный шаблон.
ReAl
Похоже, зараза, близкая к тому, что было с 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
Вбросил обновление.
«что-то с памятью» — был уверен, что в какой-то из версий avr-gcc поддержка atmega256x уже была, а предопределённых __AVR_*_BYTE_PC__ еще не было. Но они появились синхронно. Так что для 3-го байта и для EIND простая проверка.

А вот с RAMPZ, чтобы зря не сохранять/восстанавливать для контроллеров с <= 64K флеша, пришлось сделать с проверкой версии GCC.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.