Имеется проект с несколькими прерываниями: UARTы, ADC, PIO, таймеры и TWI.
Поскольку TWI у SAMa не имеет PDC, а на на нем висят графический индикатор, FRAM и RTC, то есть обмен достаточно интенсивный, я сделал "подкачку байтов" в прерывании. Прерывание короткое, с максимальным приоритетом, так как TWI у SAMa не любит пауз на шине.
Вызов прерываний сделан с использованием Сstartup.s79.

Теперь самое интересное:
- компилю проект с уровнем оптимизации Medium (здесь и далее по тексту: code или size - один хрен). Устройство устойчиво работает сутками, то есть все пучком.
- повышаю уровень оптимизации до High. Короткий всплеск активности на шине TWI и все погибает. Даже индикатор мертв, программа циклит в совершенно левом месте. Думаю, хрен с ним, у IAR-а всегда были такие проблемы при макс. оптимизации. Но:
- снижаю уровень оптимизации до Low. Индикатор работает, а при обмене с FRAM и RTC идут периодические сбои. Но в целом изделие работает.
- отключаю оптимизацию, поведение как в предыдущем случае + через некотое время (час-два) TWI переходит в режим самоудовлетворения - по шине хреначит беспорядочная передача, не прекращающаяся даже при остановке процессора.

Вопрос: как к этому относиться и, главное, кто виноват? Сижу не первый день, свои варианты закончились.
Может кто-нибудь выскажет соображения? Буду рад любой идее.

1.Относится к этому следует плохо.
2.Виноват в этом обычно программист неясно выразивший свою мысль компилятору, который тоже, увы,
не совершенен, особенно в предугадании последствий.
3.Локализуйте поблемный кусок включая/отключая оптимизацию на части проекта и локализовав, думайте над более однозначным написанием куска программы.
4. Ну и в качестве надежды на чудо - используйте свежий компилятор:
IAR ARM ANSI C/C++ Compiler V4.40A-P060613/W32
__________________________________^^^^^^^^^

1 и 2 - полностью согласен, хотя не могу понять вариант с правильным "угадыванием" именно в среднем положении.
А 3-им путем я уже иду, но проект большой, файлов много, а сбои редки. Экстенсивный путь, боюсь, до отпуска не управлюсь.

1.Вы все возможное пообъявляли как volatile?
У меня были случаи когда код выделывал кренделя, даже если переменная в прерывании не менялась. Просто инитилась в самом начале.
2.Написать обработчик аварийных ситуаций, в случае проблем, вылететать и инитить TWI заново.

PS Откуда они этот макроселл взяли? Я пока не столкнулся, думал что там наследник АВРовского, еще и продвинутый(как USART с SPI). А как посмотрел, за голову схватился.

Просто проблема не одна а несколько, хоть и приводят к универсальному результату варианту "не работает". При отключеной оптимизации, если не используется какая-либо система позволяющая делить
недостающие ресурсы, у Вас просто все "захлебывается" и какой-то кусок начинает жить исключительно
своими проблемами.




Фу, какой моветон :-( Зачем-же "все возможное" - нужно только "нужное" :-)

А вы точно знаете, что точно "нужное", а что "ненужное"?
Тай отож
Тем более собака порылась в оптимизаторе

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

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



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

Это именно компилятор или очередной патч для full версии?
На сайле IAR пишется, что он не становится на eval.

Патч в виде совершенно автономного компилятора :-). Работает при наличии лицензии на full компилятор ЛЮБОЙ версии. Ну очень любезно со стороны IAR :-)

Гы-гы-гы! Еще одна жертва ИАРа...

Всегда приятно смотреть на смеющегося человека, даже если это "смех без причины..."

Вы можете сбросить на фтп вашу лицензию? У себя нашел только
EWARM Version: 2.1_WIN standalone license (dongled) (no:1000-005-880-9779)
но с ней не работает, т.к. это dongled лицензия. А генераторы делают лицензии для евалюшн версий

Я пользую:
2.1_WIN\0EWARM\0\0....

Готовый выложил в первоначальную ветку:
http://electronix.ru/forum/index.php?showt...mp;#entry137296

Да бросьте этот ИАР аб землю и плюньте на него слюной! Поставьте нормальный ARM Ltd. компилер и он никогда не ударит вам ножом в спину!

Пластинка становится несколько заезженной. Вам не показалось?

Про заезженость пластинки вы расскажите кому либо другому, кто не переходил с ИАРа в середине проекта на АРМ Лтд. из-за неимоверной глючности первого и невозможности включить хоть малейшую оптимизацию...

Я с Вами лично не знаком и пожалуйста не принимайте это близко к сердцу. Но обычно такие проблемы возникают с ЛЮБЫМ компилятором в 99% только в случае, если программист не может ясно выразить свою мысль. В таком случае поведение компиляторов начинает отличаться, и отнюдь не факт,
что возлюбленный вами компилятор так-же удачно догадается о Ваших намерениях в другом проекте.
Ваши метания на другой компилятор только подтверждают в моих глазах тот факт, что понимание того, что Вы пишите, Вами пока невелико :-(. Огорчает то, что вместо анализа сложившийся ситуации во всем был обвинен компилятор и эти "обвинения" сейчас с упорством достойным лучшего применения широко разбрасываются Вами на просторах форума.
Ошибки встречаются в любом компиляторе.
Имея за плечами два десятка лет общения с разнообразными "C" компиляторами, я при активнейшем использовании в течении последних 9 месяцев IAR компилятора в том числе и при портировании на ARM платформу значительного числа своих предыдущих наработок с проблемами не встретился. Наступил только на одну явную ошибку компилятора, которая была локализована (вместо поиска другого компилятора) за, примерно, 20 минут. Причем в следующей версии компилятора эта ошибка (согласно честно ведущегося перечня исправленных ошибок) была устранена. Оптимизация всегда используется максимальная или по производительности или по размеру (для некоторых кусков кода). К качеству полученного кода у меня "претензии" минимальные:
- мог-бы шире пользоватся условным выполнением команд вместо JUMP;
- есть тяготение даже в ARM mode к использованию непосредственных значений в поле команды
в диапазоне характерном для Thumb mode.

Глобальная оптимизация вполне достойна, как минимум, если попытаться улучшить результат руками,
потеть придется явно не пропорционально достигнутому результату.

P.S.
IDE от IAR (впочем, как и любаяя другая) меня не интересует в принципе и ее я обсуждать не собираюсь.

Имхо вы слишком категоричны в высказываниях. "глючности и невозможность" - звучит как то слишком фантастично.

За последние несколько лет активной работы с иарарм и иар430 в моем репозитории было всего 5 багов. В последних версиях осталось всего два. Оба связаны с шаблонами, которые практически никем не применяются. Да и то, одну ошибку и ошибкой назвать трудно - просто разночтения стандарта у ИАР и Мелкософта. Это приводит к неудобству ведения общих исходников и только.

Другое дело, что с ИАРом тяжело контачить по поводу багов, по крайней мере все мои обращения остались без ответа. Возможно, потому, что я у них ничего не покупал. Лицензионные кустомеры говорят, что суппорт работае вполне оперативно.

А почему бы вам не рассказать о том как IAR ARM страдал падучей болезнью при входе и выходе из режима отладки, которую поправили только в версии 4.3. А его знаменитое неубирающееся окошко "не могу прочитать R0-R14" от которого спасает только ЦТРЛ_АЛТ_ДЕЛ? Оно до сих пор еще не поправлено! При чем оно умудряется выскакивать даже при использовании ДЖЕЙЛИНКА! Конечно если писать программки типа "мама мыла раму" или лед блинк то ему равных нет, а вот предьявите пожалуйста хоть одну серьезную программу ну хотя-бы кил на 200-300 сделаную на ИАР АРМЕ! Тогда и поговорим...

"кил" чего, простите? исходников? так это совсем немного.

Использую EWARM 4.20 (+J-Link) для работы с SAM7S128, доволен вполне; пресловутые болезни обходят стороной.

Прерывание от TWI или от чего-то другого? Сколько у вас всего прерываний задействовано?
Может попробовать сделать тестовую программку с подкачкой без использования прерываний?
Если будет тот же эффект, значит прерывание тут не причём.

А потому, что я уже РАНЕЕ написал:

Растолковываю - меня интересуют только компиляторы. "родными" IDE не пользуюсь и пользоваться не буду ввиду cуществования более приспособленного для профессиональной работы инструментария. Мое мнение об IDE "компиляторов" вообще и об IDE IARа в часности Вы можете найти на этом форуме.
Внутрисхемным отладчиком пользуюсь крайне редко и переживу почти любой.
Только как соотносится IDE IAR с качеством РАНЕЕ критикуемой Вами генерации компилятором кода я
не понял.


Насколько я понимаю, это вариант бессмерного аргумента Паниковского: "А ты кто такой?".
Потом что будет? "Поезжайте в Киев и спросите, кем до революции был Паниковский, нет вы поезжайте и спросите!"?

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

Очень приятно иметь дело с человеком утруждающим себя подробным растолковыванием всяческих мелочей этим бестолковым ламерам. Так все-таки покажите пожалуйста реально работающую программу (особенно в реальном масштабе времени) обьемом 200 и более килобайт бинарного ВЫХОДНОГО кода компилятора ИАР.

А какая принципиальная разница 200K, или 2 по 100K, или 999 по 99K.
Если Вам любопытно, то суммарный объем наработанный за 9 месяцев по 6 девайсам много превосходит 200K СОБСТВЕННОРУЧНО написанного "реалтаймового" кода.

1. Если Вы полагаете, что хоть какой-то компилятор способен заниматься хоть какой-то разумной оптимизацией в пределах ОДНИМ куском написанного кода размером 200K, то это просто детская наивность.
2. Я находясь в здравом не писал, не пишу и не буду писать ничего ОДНИМ куском, что будет выливаться в ОБЪЕКТНЫЙ код более чем несколько десятков килобайт.
3. Или у Вас претензии к линкеру от IAR? Вроде нет - катятся бочки на оптимизацию...
4. Если о моей способности писать программы превышающий магический размер 200K embedded кода, то отвечаю - способен и писал под x86 платформу.

Надеюсь, я доходчиво и без "аргументов" типа:

объяснил, почему представление или не представление "программы" размером 200K просто ни о чем ни свидетельствует? И почему я ранее написал, что не могу могу воспринять сие "требование" иначе чем

Огромное спасибо за проявленное внимание, но компилятор абсолютно не виноват.
Была абсолютно ламерская ошибка человека (то бишь меня), 20 лет работавшего с 8-миразрядниками и впервые воспользовавшегося 32-х битником. Господин zltigo был абсолютно прав.

У меня был недавно глюк с IAR 4.20. Он гад константу, описанную через #define, в проге почему-то увеличивал на 16. Это я в отладчике выяснил, взглянув на асм-код. Приходилось в нескольких местах писать "константа-16".
Странный, да, глюк?

Ну раз недавно, значит не забыт :-) давайте сюда - посмотрим....

Пока неясно.

А вот это точно странное и совершенно ошибочное решение с Вашей стороны.
Подгонка под ответ нахудшее из всех возможных решений.

Да и число 16 какое-то... наводящее на мысли. Константа вычисляемая да?

Да, да! Я тоже так подумкал. Константа - простое число.

Подождите немножко, щас всё несущественное вырежу (типа коммерческая тайна), а чё останется - запостю.

Зацените вырезку из отладчика:

Касательно константы NET_VAR_DOUT1, которая реально описана как:
#define NET_VAR_DOUT1 64+8
__________________________________

Ой, бл@@!
Тока щас понял в чём косяк. Таки мой косяк >:(
Надо было этот сраный дефайн в скобки заключить.

Я как бы извиняюсь, что воду тут намутил. Зря.

А я только собрался про скобки написать

Драку я, к сожалению, пропустил, но скажу пару слов о столь любимом мной и господином d__ компиляторе от ARM Ltd. Точнее, не о компиляторе даже, а о линкере. Так вот, этот линкер имеет прелестную привычку глухо виснуть при ошибках, особенно в сложных скриптах с ROPI/RWPI. Не мало он крови мне в свое время испортил.

Я к тому, что глюки есть у всех, а не только у IAR'а, но это еще не повод бросать что-либо об стенку.

Хм у меня есть уже определенная методика обнаружения своих тупых ошибок - объяснить оппоненту, пусть даже воображаемому, (очень желательно вслух или на бумаге хотябы) то как работает этот кусок программы. Часто помогает.

А еще может кто-нибудь все-таки объяснит возможно ли в реалвью исполнять код из RAM. Даже в gcc это есть, сегмент fast кажется.

Конечно возможно. Я такое делал в IAR. перед процедурой пишется __ramfunc. Мне надо было обрабатывать прерывания прямо во время записи во флэш LPC213x. Только в раме они и могут обрабатываться.

Я имел ввиду RealVeiw от ARM, сколько не смотрел в их гайды так ничего и не нашел относительно преноса кода в память.
В мануале указано что прагмами можно размещать код по секциям
• code
• rodata
• rwdata
• zidata.
В rodata и rwdata в примерах помещаются именно данные.

Почитайте мануал на линкер, там должна быть глава "Using Scatter-loading description files".
Вот пример скрипта для AT91SAM7S64 без Remap'а:



Если нужно поместить функцию в RAM, пишем:

Да чтото до ллинкера я не дошел так глубоко, а надо было. Там и про фромельф написано.
Спасибо aaarrr сам я бы до этого долго доперал.

Да нет там ничего вложенного, только намерение выложить.

Было выложено. Потом удалено по настоянию модератора :-)