Спасибо.
Ваш hex попробуем.
Посмотрим на мейк.
Скомпилировал в 2007. Вечером проверю. Доложу.

Кстати, а оптимизация не может негативно влиять?

У вас, я смотрю, оптимизация совсем никакая: опция OPT = -Os
И ещё по поводу стандарта.
У вас -std=c++98, у меня не знаю что Code::Blocks компилятору подсовывает

Самая правильная оптимизация для AVR
Вот за всякие дополнительные ручки по поводу лимита размера для inline и тому подобное - да, не дёргаю. И так не плохо.
Не думаю, что -O2 должна сильно поменять ситуацию.

Там оно вроде бы закомментировано, так что будет использоваться умолчание (gnu++98 для С++)

Виноват, буковку "s" не заметил.
Я сегодня совсем сплю

Кстати, посмотрел на описание оптимизации (перевод книги по GCC), там, вроде бы, часть флагов компилятора для разных режимов оптимизации смешивается...
Допустим, -Os включает -O3 и добавляет свои флаги...
-O3 включает -O2 и добавляет свои флаги...
-O2 включает -O и добавляет свои флаги...
А -O1 и -O вообще одно и то же...
Т. е., получается, что совместно использовать, например -O2 и -Os смысла никакого нет, т. к., -Os включает -O2 и добавляет свои флаги?
Кстати, опции -Oi фактически являются "обёртками", которые указывают на включение других дополнительных опций, как я понял?



Ага, этого я тоже не заметил...


Ещё вопросы...
ISR вызывается в контексте того процесса, который выполнялся при возникновении прерывания?
Как я понимаю, оптимальное содержимое ISR - инструкция перевода какого-либо эвента в сигнальное состояние?
А если в ISR модифицируются глобальные объекты, которые модифицируются так же в одном из процессов (или в нескольких), то необходимо использовать средства синхронизации для доступа к этим объектам (критические секции, семафоры)?
Причём, внутри ISR прерывания запрещены всегда и получается, что критические секции в ISR использовать бессмысленно, а семафоры вообще противопоказано... и средства синхронизации нужно использовать вне ISR в процессах, работающих с нашим глобальным объектом?
Помогите разобраться, пожалуйста, а то в голове каша

Откомпилировал в WinAVR 2007 - не работает.
Откомпилировал в WinAVR 20090313 - не работает.
То, что Вы прислали - тоже не работает!

Может, конечно, Proteus глючит... нету сейчас железки под руками проверить...
Странно.
Займусь сверкой ключей...

А Вы в выложенной мною программе ничего не меняли?
В протеусе я вижу на PC1 сигнал со скважностью отличной от двух... очень отличной.
А на PC2 - вообще нуль...
А Вы когда смотрели осциллографом видели на обоих выводах какие сигналы?

Огромная просьба, если Вас не затруднит, то проверьте, пожалуйста, на своём макете работу той же программы, откомпилированной у меня (файл Prob.elf.hex). Так мы и моё компилирование проверим и протеус...

ATmega168.
8000000 MHz.
WinAVR20090313.

Сообщение отредактировал n_bogoyavlensky - Jun 23 2009, 20:22

Ну не знаю...
Я же прицепил полный проект, который я собирал.
Не менял ничего, только приложил рядом сам scmRTOS и свои make-файлы
Меандры около 20мс и 60мс длительности уровня. 8MHz int RC в качестве тактирования. На время прошивки очередного варианта они пропадали :-)

Ой, а это нескоро. С выходных до следующих выходных я уезжаю, а до этого не до того.

Спасибо Вам большое за помощь!
Нашёл железку. В четверг обязательно на ней сам проверю.
Скорее всего это глюки протеуса.
О результатах напишу...

Проверил в железе.
ATmega48P, 20 МГц, оба способа передачи управления.
Работает замечательно.

Обидно, что Proteus меня подвёл...
Побегу жаловаться

ReAL, это опции линкера, как я понял (из вашего мейка)?



А зачем -Wl два раза указан?

Это опции, которые gcc передаст линкеру (ld).Об этом можно прочитать в документации на gcc. -Wl "действует" до ближайшего пробела.

По поводу нашего давнего разговора в этой ветке о сокращении размера кода при компиляции...
Разобрался...
Для линкера надо было писать
-Wl,-Map=$(TARGET_OUTPUT_FILE).map,--cref,--gc-sections,--relax

Я писал:
-Wl,-Map=$(TARGET_OUTPUT_FILE).map,--cref
--gc-sections
--relax


Поэтому и не работало...



Это понятно.
Я имею ввиду зачем две строчки с -Wl, если можно обойтись одной...

Сообщение отредактировал n_bogoyavlensky - Jun 25 2009, 07:23

Хотел попробовать запустить примеры для BF533.
К сожалению проект скомилировать не удаётся, ошибка такого плана:
".\Src\main.cpp", line 112: cc0167: error: argument of type
"void (*)(int, int, int)" is incompatible with parameter of type
"ex_handler_fn"
register_handler_ex(ik_timer, OS::SystemTimer_ISR, 1);
^

".\Src\main.cpp", line 113: cc0167: error: argument of type
"void (*)(int, int, int) C" is incompatible with parameter of type
"ex_handler_fn"
register_handler_ex(ik_ivg14, ContextSwitcher_ISR, 1);
^

2 errors detected in the compilation of ".\Src\main.cpp".
cc3089: fatal error: Compilation failed

Чтобы можно было закомментировать каждый ключ отдельно :-)


sevstels, я в режиме тормоза на старое ответил, по BF, увы, ничем помочь не могу

уже решил заменой файлов из snapshot
мне только одно не понятно, почему-бы сразу не выкладывать корректную версию для скачивания
или надо чтоб народ для начала немного помучился?

Дело в том, что в релизе лежит версия для VDSP 4.5 (и более старых), там прототип обработчика прерывания описывался с тремя аргументами типа int. Зачем так было сделано, не знаю. В версии VDSP 5.0 они, видимо, и сами это поняли, и убрали эти инты из прототипа. В соответствии с этим были внесены изменения, которые оперативно отразились в репе и в снапах. Но поскольку релиз еще не выпускался, то в архивах лежит версия для VDSP 4.5.

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

Это конечно удивительно, автор работает ещё 4.0 версией VDSP!
Надо иметь железные нервы... был в шоке.
Кстати потестил на BF561 (600/150) - всё аж летает

При компиляции есть предупреждение:
".\scmRTOS\BF533\OS_Target_cpp.cpp", line 61 (col. 5): cc1746: {D} warning:
Externally defined variable Kernel, possibly used in constructor
before it has been constructed


Дык что тут думать? Проще не бывает.

scmRTOS BF533 vdsp 4.0
scmRTOS BF533 vdsp 4.5
scmRTOS BF533 vdsp 5.0

Или на php простенький скрипт, по какой ссылке кликнули, сервер соответствующие файлы в архив и закатал.

-

Сообщение отредактировал sevstels - Oct 5 2009, 14:14