компилятор С и среда разработки для AVR

Hello Alex.

28 Jul 06 02:44, you wrote to me:

NM>> Чтоб не говорили, что я NM>> чтото там не то пишу - взял пример avr306 (UART),

В 306

----------- #pragma vector=UART_UDRE_vect __interrupt void UART_TX_interrupt( void )

----------- Я недолго думая, написал ISR(UART_TX_vect), и получил бесконечный ресет.

----------- Эта ошибка не у них!

Nicolas

Hello Alex.

28 Jul 06 03:23, you wrote to me:

NM>> А винавр обязательно надо юзать с аврстудией. Ктобы людский фак NM>> написал...

Тебе действительно нужен ответ с моей позиции чайника?

Я имел ввиду эмулятор. Он мне помог. И потом ключи. Что я насовал в мейк - это моя проблема. А авторы студии info по ключам к gcc читали.

Правильный вопрос - 50% ответа. Его можно не задавать публично. Hеправильный вопрос приводит к ответу в стиле - "Автар ЖЖОТ", такой лучше не задавать.

Nicolas

Hello, Nicolas!

??>> А по поводу FAQ - задавай конкретные вопросы, и тебе скорее ??>> всего ответят. NM> Правильный вопрос - 50% ответа. Это если вопрос простой и ответ (почти) всем известен, а если вопрос чуть посложнее (или про новую технику) про фифти-фифти мечтать не приходится. NM> Его можно не задавать публично. Hеправильный вопрос приводит к NM> ответу в стиле - "Автар ЖЖОТ", такой лучше не задавать. Ну почему? Просто в этом случае отвечающему перед ответом следует подумать о том, а что же именно задавший вопрос в этом случае может не понимать. А взявшиеся вставить свои пять копеек от апломба и со скуки - это особый разговор.

With best regards, Andrej Arnold. E-mail: snipped-for-privacy@aol.com

"Этой страны" давно не существует. Как и таких дискет.

Как ты мог. Непременно и исключительно только *.doc.

Вот ты их сам процитировал.

Нечто больше похожее на UUE-код, чем на Makefile.

Т.е. вместо --option удобней писать /option? Никогда бы не подумал.

А как они там могут оказаться? Никто ведь не заставляет.

Борландовский make -- на редкость уродский язык. НО только потому что тебе нечего делать ты продолжаешь с ним мучаться.

Борландовский? Точно негодный.

Но галочек-то нет?

Так вроде как уже налито в их студию. Хотя я сам не смотрелм, не знаю. Но, тезис о том, мол всё это негодные поделки финских студентов, надеюсь, отметается?

Чем он недоделанный, по сравнению, например, с hitech C? Если тот ужас, на жабе сделанный, выкинуть по-дальше?

Странно не знать, что GNU "продвигает" info как замену "неудобным" с их точки зрения манам. Т.е. практически на всё гнутое манов-то нормальных нет, одни info.

Бесконечно-малая величина, 1/Inf, в компутерах обычно даёт 0:

octave:1> 1/inf ans = 0

Да, придётся заморочиться с objcopy для получения чего-то, что сможет переварить программатор. И ещё указать конкретный тип процессора. Остальное от практики в линухе практически не отличается.

К вопросу о туториалах -- в комплекте к avr-libc прилагаются, на

Нужно знать какие опции компулятора будут использованы. В том и другом случае. Вписать это в Makefile совсем не сложно. Т.е. все трудности заключаются в том, чтобы заглянуть в даташит и найти там нужные опции. Описываемые, часто, параллельно с птичками из GUI. И то и другое не очень сложно. Хотя, наверное, если в даташит вообще не заглядывать -- птичками проще. Но ровно до того момента, когда окажется, что этих птичек там три экрана с пятью закладками и их дефолтное состояние тебе не понятно вообще. Тогда бегом побежишь писать Makefile -- проще из даташита выбрать десяток нужных опций, чем вникать в каждую птичку.

Изучать Makefile вообще не нужно. Т.е. нужно, но один раз в жизни. Выставить птички это одно, а понять потом что они значат -- сможешь? Вон у keil есть такая малопшриметная птичка, noaregs, без неё такие глюки начинаются... Даташит, короче говоря, читать всё равно надо и внимательно. После чего Makefle, с его опциями умещающимися на пол-экрана, кажется прочем чем полсотни "причек".

CR16 и CR32 -- CPU ядра для микроконтроллеров. Делал их National Semiconductors, верней чипы на их основе. В комплект раздаваемого development environment входил GCC.

Вот будет у тебя немерянный дифф справа, немерянный дифф слева и полное непонимание в мозгах сути происходящего -- узнаешь.

Ты много видел покупных компиляторов? Я ни одного.

GCC включает в себя и компоновщик. Библиотеки даются отдельно (их разных есть). Редактор сам где-нибудь найдёшь (впрочем GNU даёт и редакторов разных, и gnu make). С отладчиком вот сплошное шаманство... Что в остатке?

Мы о разном говорим. По галочке GCC тоже можно элементарно вызвать хелп и они тоже подписаны (gcc --help -v | grep галочка).

Вопрос в том, что о галочке вообще знать нужно. А для этого нужно читать даташит на компилятор. И никакая IDE тут не поможет.

На это я бы вообще не полагался...

Просто. А какой галочкой можно функции по банкам в uVision растолкать? А то не влезает так просто. Нет, сиди пиши линкерный скрипт. Мышкой он из кубиков почему-то не строится. А здорово было бы, мышкой функции таскать. И чтоб на экране они пропорционально размеру рисовались.

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

Если выкинуть всякие борланды, где всё переврано, конкрентные make мало чем отличаются. По сути их два: один GNU, второй из BSD. Есть ещё десяток альтернативных, вроде борландовского, есть ещё всякие Ant. Но называть их make как-то уже не получается.

Все последовательно. На треёх экранах. У меня в мозгах не умещается.

Чтоб компактно, в несколько строчек.

Или потому, что с нужной галочкой куда как сложенй совладать, чем с опцией в комментарии. Да и не все галочки были доступны, вроде как.

Тут надо думать наоборот, не *как оно будет исполняться*, а *что надо сделать*, для того чтобы получить результат. Это не императивный язык, где сверху-вниз записана последовательность действий. Вот в чём разница.

Есть вещи, которые сожно не знать. Их не так уж и много. И язык make вполне может входить в их число (как например, и стандартная библиотека языка C).

Нуы и отлично. Что тогда сравнивать, если gcc -- не среда разработки?

Никак. Он не редактор. Говорят, в emacs можно как-то. Но emacs я не унмею.

Привет!

Thu Jul 27 2006 19:57, Nicolas Minakov wrote to Jurgis Armanavichius:

NM> Hашол c:\WinAVR\doc\gcc.pdf NM> на 420стр. NM> "Using the GNU Compiler Collection NM> by Richard M. Stallman and the GCC Developer Community NM> Last updated 23 May 2004 for GCC 3.4.6" NM> Это оно?

Да, оно. Правда, он обобщенный какой-то, но читать можно. Его бы на несколько лет раньше найти... ;-)

Юргис

Привет!

Fri Jul 28 2006 14:09, Kirill Frolov wrote to Jurgis Armanavichius:

Да, для AVR и Hitachi я именно так и делаю. Hачальное въезжание в этот процесс был очень нелегким... Майкфайлы эти проклятые с их крайне туманным синтаксисом немало кровушки выпили... И еще, черт подери, все вызубренное очень быстро забывается! :-)

KF> К вопросу о туториалах -- в комплекте к avr-libc прилагаются, KF> на

Спасибо за ссылку! Полюбопытствую.

Даташит читать в любом случае нужно. Однако, если в даташите я вычитал, что в кристалле есть два DPTR'а, то включить соответствующую птичку много проще, чем разыскивать требующуюся опцию компилятора :-)

KF> Описываемые, часто, параллельно с птичками из GUI. И то и другое не KF> очень сложно. Хотя, наверное, если в даташит вообще не заглядывать -- KF> птичками проще. Hо ровно до того момента, когда окажется, что этих KF> птичек там три экрана с пятью закладками и их дефолтное состояние KF> тебе не понятно вообще. Тогда бегом побежишь писать Makefile -- проще KF> из даташита выбрать десяток нужных опций, чем вникать в каждую птичку.

Понял! Ты рассматриваешь этот процесс с позиции системного программиста, ну или администратора. А я - с позиции прикладного применения, т.е. для меня пусть будет хоть черный ящик. Я этому ящику задал тип микросхемы, указал требующиеся мне режимы работы и фичи - и все, скармливаю этому черному ящику исходные тексты моей программы, а на выходе получаю готовый файл прошивки ПЗУ. То, что я поставил, к примеру, внешнюю ПЗУ - я знаю, т.к. почитал даташит, апноты, разобрался с вопросом. А вопрос, в каком виде, с каким синтаксисом, в каком порядке все нужные мне фичи следует задать компилятору - мне становится уже неинтересен. Я просто знаю, _что_ нужно задать, и мне важно задать это максимально простым путем, т.е. посредством "птичек" :-)

Т.е. именно черный ящик - средство порождения файла прошивки из моих исходных текстов программы.

KF> Изучать Makefile вообще не нужно. Т.е. нужно, но один раз в жизни. KF> Выставить птички это одно, а понять потом что они значат -- сможешь?

Конечно! Я ведь даташит почитал, схему разработал, мне плату изготовили. Естественно, что я прекрасно знаю все нужные мне особенности кристалла. А, следовательно, если в диалоге конфигурирования опций компилятора я увижу переключатель: "Use On-chip ROM (0x0-0x3FFF)", то я точно знаю, что это означает и как именно нужно выставить эту опцию. Я ведь схему не с потолка брал, мне точно известно Use или не Use! :-)

KF> Вон у keil есть такая малопшриметная птичка, noaregs, без неё такие KF> глюки начинаются... Даташит, короче говоря, читать всё равно надо KF> и внимательно. После чего Makefle, с его опциями умещающимися на KF> пол-экрана, кажется прочем чем полсотни "причек".

Если у компилятора имеется опция noaregs, то будь то Makefle, будь то какая-нить IDE - все едино, придется разбираться, что это за опция. Если она вызывает глюки - птички тут уже ни при чем. Ведь похожий глюк будет и в gcc, и для него придется разбираться и правильно устанавливать соответствующую опцию. К примеру, мой кросс-компилер для Hitachi создавал глюк с опцией -mrelax. Пришлось сначала с нею разбираться, а потом просто выкинуть к хренам :-)

Так что, глюки - вещь особая, от конкретного компилятора не зависящая. Глюки бывают в любом компиляторе.

KF> CR16 и CR32 -- CPU ядра для микроконтроллеров. Делал их National KF> Semiconductors, верней чипы на их основе. В комплект раздаваемого KF> development environment входил GCC.

Редкая вещь, видать... Т.е. из рассмотрения можно выбросить :-) Тогда получится, что gcc в современные IDE не включают :-) Фирма Atmel вон включила немножко поддержки gcc в свою студию, но скачивать его надо все-равно отдельно. А потом устанавливать эти две штуковины в нужном порядке (недавно я это делал, но забыл, то-ли первым нужно ставить WinAVR, то-ли студию...). После беглого опробования я это дело похерил. Вернулся к своему старому методу компиляции посредством Makefile'а ;-) (Компиляция у меня получалась, но выходной файл почему-то раздувался, и в результате не срабатывала окончательная сборка, т.к. из размеров ПЗУ вылезало... Разбираться не стал, просто плюнул :-)

:-) Hадеюсь, что еще не скоро. Я ведь здоровенных систем не разрабатываю, я все больше по embedded... ;-)

Хм... Ой как некрасиво... А у меня все применяемые на работе компиляторы покупные. Кроме трех gcc под три платформы (Hitachi, AVR и Win32). Пока я щупаю что-то новенькое, пользуюсь демо-версиями. Если это полезно для работы - покупаем. Правда, мне для работы совсем немного нужно :-)

Hу а хобби - тут проще. Отучаю всяческие фирмы от излишней жадности и все дела ;-) (2 коллега Орлов: я у тебя АВР Воркбенч тяну, спасибо тебе большое!)

В остатке - в точности то, что я и говорю: нормальная IDE нужна! И не надо ничего разыскивать, стыковать друг с другом, шаманить. Черный ящик! ;-)

Юргис

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Fri, 28 Jul

2006 09:39:59 +0000 (UTC):

KF> Как ты мог. Непременно и исключительно только *.doc.

Ну если тебе doc нравится больше...

KF>>>>> Афтар не сделает может быть. Другие -- делают.

KF>>> Кроме вот таких вот выкрутасов для проталкивания опций KF>>> компилятору: KF>>> comma = , csv = $(subst $(space),$(comma),$(strip $(1))) KF>>> lsv = $(subst $(eol),$(space),$(1))

KF> Вот ты их сам процитировал.

То есть в твоих письмах? Ну это дело привычное.

KF>>> Но это ещё что. Для hitech я как-то уже приводил...

KF> Нечто больше похожее на UUE-код, чем на Makefile.

Во-первых, мейкфайл как мейкфайл, ничего особенного. Во-вторых, если пользоваться например MPLab'ом, не нужны вообще никакие мейкфайлы. Наверное и с HiTide не нужно, я не смотрел еще (я-то как раз этими оболочками не пользуюсь).

KF> Т.е. вместо --option удобней писать /option? Никогда бы не KF> подумал.

Не надо вообще ничего такого писать. IDE сама все напишет.

KF>>> Там есть другая проблема -- правильно выставить все кнопочки. KF>>> Впрочем даже это не проблема. Непонятно что делать при KF>>> перетаскивании проекта на другой компиутер или в другой каталог -- KF>>> там все пути прописанные абсолютные и приходится файл проекта KF>>> править руками. >> Далеко не всегда. А абсолютные пути могут и в мейкфайле быть >> прописаны.

KF> А как они там могут оказаться? Никто ведь не заставляет.

Так и в IDE никто не заставляет их писать.

KF>>>>> Makefile -- это какой никакой, а формальный способ записи правил KF>>>>> сборки. >>>> Скорее никакой. На редкость уродский язык.

KF>>> Ну возьми Ant... Никто ж не заставляет именно make. Просто

KF> Борландовский make -- на редкость уродский язык. НО только потому

Ничуть не более, чем любой другой.

KF> что тебе нечего делать ты продолжаешь с ним мучаться.

Мне как раз есть что делать, потому пользуюсь тем, что когда-то освоил. Было бы нечего, я бы их перебирал

KF>>> почему-то традиционно используется именно он. Видать, не такой уж KF>>> и негодный инструмент. >> Годный. Неудобный просто.

KF> Борландовский? Точно негодный.

Как и любой другой. Нет больщой разницы, она в мелочах.

KF>>>>> Галочки в IDE таковым не всегда являются. >>>> Ничуть не в меньшей степени, чем закорлючки вроде $< KF>>> soource-file-name = $< KF>>> file.obj: file.c cc $(source-file-name) >> Вот-вот. Птичий язык.

KF> Но галочек-то нет?

Главное, нет к ним подписей.

KF> Так вроде как уже налито в их студию. Хотя я сам не смотрелм, не знаю. KF> Но, тезис о том, мол всё это негодные поделки финских студентов, KF> надеюсь, отметается?

Не надейся. Как было недоведенным до ума, так и осталось.

KF> Чем он недоделанный, по сравнению, например, с hitech C? Если тот KF> ужас, на жабе сделанный, выкинуть по-дальше?

Отсутствием примеров и внятной документации. Даже если все оболочки выкинуть. Хотя на хрена они в девятой версии переделали все ключи я не понимаю...

dima

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Fri, 28 Jul

2006 10:22:54 +0000 (UTC):

KF>>> Имел бы опыт знал бы, что банальный cc file.c получает, для KF>>> целевой платформы, готовый бинарник в наиболее приемлемом виде. KF>>> Без всяких знаний. А опция задаваемая в командной строке вобщем-то KF>>> мало чем отличается от галочки в IDE. О назначении и имени опции KF>>> или

KF> Мы о разном говорим. По галочке GCC тоже можно элементарно вызвать KF> хелп и они тоже подписаны (gcc --help -v | grep галочка).

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

KF> Вопрос в том, что о галочке вообще знать нужно. А для этого нужно KF> читать даташит на компилятор. И никакая IDE тут не поможет.

Поможет - см выше. И не надо ничего лишнего читать.

KF> На это я бы вообще не полагался...

То твои личные трудности.

KF>>> галочки один хрен знать нужно. Про Makefile я даже не заикаюсь -- KF>>> можно в "батнкик' прописать.

KF> Просто. А какой галочкой можно функции по банкам в uVision KF> растолкать?

Если бы я работал с uVision, возможно я бы тебе и рассказал или посоветовал другое средство. GCC-то (три раза ха) для х51 вообще нет.

KF> А то не влезает так просто. Нет, сиди пиши линкерный скрипт. Мышкой KF> он из кубиков почему-то не строится. А здорово было бы, мышкой KF> функции таскать. И чтоб на экране они пропорционально размеру KF> рисовались.

Есть кстати и такие системы.

KF>>> Именно так. Потому как человек оперирует в своих рассуждениях KF>>> *понятиями*, которые легко могут быть выражены как на KF>>> естесственном, так и на искусственном (компьютерном) языке. KF>>> Выразить их картинками (пиктограммами) или жестами "мыши" KF>>> достаточно сложно.

KF> Самое идиотское в том что ты сказал -- так это именно то, что оно KF> в любом компиляторе на "птичьих" языках и выражается. А никак не KF> подписями, скрывающими примерно половину нужных ручек управления.

Плевать как оно там внутри выражается. Важно как оно выглядит снаружи.

KF>>> А главное даже не это, а то что Makefile может быть банально KF>>> *прочитан* человеком.

KF> Если выкинуть всякие борланды, где всё переврано, конкрентные make

Ничего там не перврано.

KF> мало чем отличаются. По сути их два: один GNU, второй из BSD.

А реально - гораздо больше. Обычно в каждом пакете свой.

KF> Все последовательно. На треёх экранах. У меня в мозгах не KF> умещается.

А сотни страниц убогого man'а помещаются... Ты просто своими хрюнисками мозги себе свернул :)

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

KF> Чтоб компактно, в несколько строчек.

Бумаги жалко?

KF>>> Вспомни турбо-паскаль. И почему так любили опции компилятору KF>>> записывать в комментариях, когда можно было их просто включать в KF>>> менюшке.

KF> Или потому, что с нужной галочкой куда как сложенй совладать, чем KF> с опцией в комментарии. Да и не все галочки были доступны, вроде KF> как.

Опять сказки, как и с опциями к утилитам HiTech. Примеров, надо полагать, как и тогда не будет?

KF>>> И про маловразумительные конструкции не надо. Опять же простой KF>>> Makefile на вид мало чем отличается от "батника" (или это тоже,

KF> Тут надо думать наоборот, не *как оно будет исполняться*, а *что KF> надо сделать*, для того чтобы получить результат. KF> Это не императивный язык, где сверху-вниз записана KF> последовательность действий. Вот в чём разница.

Я знаю в чем разница. И она такова, что во-первых, оно имеет мало общего с командными файлами. И во-вторых, представляет собой еще один язык, знание которого не нужно для решения конечной задачи.

KF>>> "маловразумительные конструкции")? Makefile -- это не более чем KF>>> /программа/, которую, конечно, можно записать так, что никто потом KF>>> не разберётся (типичный writeonly -- многие программы на perl...), KF>>> а можно и комментарии написать и код более-менее вразумительный.

KF> Есть вещи, которые сожно не знать. Их не так уж и много. И язык KF> make вполне может входить в их число (как например, и стандартная KF> библиотека языка C).

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

KF>>> Нити разговора ты сам не видишь. И пытаешься сравнивать сапоги с KF>>> пряниками. Если сравнивать GCC с KEIL, то не с uVision конечно, а KF>>> с программой CC.exe и каталога bin.

KF> Нуы и отлично. Что тогда сравнивать, если gcc -- не среда KF> разработки?

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

KF>>> КАк в uVision увидеть (хорошо ещё, что uVision...) увидеть cvs KF>>> log для данной строчки? >> А в gcc как?

KF> Никак. Он не редактор. Говорят, в emacs можно как-то. Но emacs я KF> не унмею.

Я вообще не понимаю что тебе надо сделать...

dima

Привет Jurgis!

27 Jul 06 10:43, Jurgis Armanavichius писал Kirill Frolov:

JA> Hеа. К примеру, точный список ключей компилятора я смог получить JA> только с помощью команды "h8300-hms-gcc.exe --help > gcc.help". Потом JA> в этом очень кратком "хелпе" пришлось догадываться, как именно JA> работает тот или иной ключ в данной конкретной реализации компилятора.

Удивился прочитанному, не поленился собрать h8300-hms-gcc и вывести его

--help. Сравнил написанное с мануалом. Из всех его опций в мануале не оказалось только отладочной опции -print-multi-os-directory. Все остальные в мануале описаны. Hе слишком ли большое преувеличение - называть это "ничего общего"?

JA> Кстати, ты пробовал породить смешанный текст Си/Ассемблер для WinAVR?

Я не то что пробовал, а очень часто это делал.

JA> Я порождаю (как уже говорил). В получившемся листинге приведена такая JA> каша, что разбираться просто противно (хотя и возможно).

Хочется увидеть какой-нибудь пример для более предметного разговора. Из общих соображений - при сильно включенной оптимизации оптимизатор может так сильно переставлять группы инструкций, что действительно, результат становится мало похож на исходную мысль. Hо это вполне понятно, и в вину ему быть поставлено никак не может. Обычно же все вполне читаемо: кусочем исходного кода, за ним получившийся из него код. Следующий кусочек исходника - следующий кусочек асемблера. Что еще может быть нужно от листинга?

JA> Иногда я даже JA> с помощью avr-objdump порождаю дизассемблированный листинг, и то легче JA> разобраться...

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

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Западно-уральское региональное общество добровольных учредителей.

Привет Nicolas!

28 Jul 06 09:15, Nicolas Minakov писал Alex Mogilnikov:

NM>>> А винавр обязательно надо юзать с аврстудией.

NM> Тебе действительно нужен ответ с моей позиции чайника?

Hе прибедняйся. Ты слишком много лет в этой эхе (хоть и редко пишешь), чтобы таким уж чайником прикидываться. :) А ответ мне не нужен, я ничего не спрашивал. Я только сказал, что твое утверждение неверно: винавр не обязательно юзать с аврстудией.

NM> Я имел ввиду эмулятор. Он мне помог.

Ты говоришь об аппаратном эмуляторе или программном (который обычно называют симулятором)? Если об аппаратном - сочувствую. Hесколько лет назад я именно из-за необходимости работать с эмулятором ICE200 был вынужден использовать аврстудию. Глючила она по-страшному. Мой отлаживаемый код работал гораздо надежнее чем это "средство отладки". :( Поэтому когда ты написал, что винавр надо обязательно использовать с ней, я аж вздрогнул. :)

NM> Что я насовал в мейк - это моя проблема. А авторы NM> студии info по ключам к gcc читали.

А-а-а, ну тогда твою фразу об обязательном использовании авр-студии позволю себе переформулировать так: "надо обязательно читать документацию".

NM> Правильный вопрос - 50% ответа. Его можно не задавать публично.

А как тогда писать FAQ, если никто не будет публично задавать вопросов? :) Я вот навскидку не могу вспомнить ни одного вопроса по gcc, который можно было бы в FAQ записать. Как-то не повторяются они...

NM> Hеправильный вопрос приводит к ответу в стиле - "Автар ЖЖОТ", такой NM> лучше не задавать.

Согласен.

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Посетители должны общаться по сети.

Привет Nicolas!

28 Jul 06 09:06, Nicolas Minakov писал Alex Mogilnikov:

NM> В 306 NM> ----------- NM> ----------- NM> Эта ошибка не у них!

Да не, я по сути 306-й пример не смотрел, просто опять же был печальный опыт: купили демо-плату от Атмела, к ней прилагался CD с кучей демо-проектов. Эти примеры (которые по идее должны были показывать как надо писать) были полну грубых ошибок. Hапример только в одном проекте, где под uCos-II несколько задач лампочками мигали не работали запрещения прерываний в критических секциях (то есть вообще прерывания не запрещались никогда в процессе работы), а при переключении контекстов задач умудрились терять содержимое одного из регистров. И это при том, что на сайте uCos были вполне нормальные порты для этого же ядра. После этого я понял, почему так глючила авр-студия. :) С тех пор у меня вполне понятное предубеждение против программных продуктов от Атмел...

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Если ты коп, почему я весь взмок?

Привет!

Fri Jul 28 2006 20:48, Alex Mogilnikov wrote to Jurgis Armanavichius:

JA>> Hеа. К примеру, точный список ключей компилятора я смог получить JA>> только с помощью команды "h8300-hms-gcc.exe --help > gcc.help". JA>> Потом в этом очень кратком "хелпе" пришлось догадываться, как именно JA>> работает тот или иной ключ в данной конкретной реализации компилятора. AM> Удивился прочитанному, не поленился собрать h8300-hms-gcc и вывести AM> его --help. Сравнил написанное с мануалом. Из всех его опций в мануале AM> не оказалось только отладочной опции -print-multi-os-directory. Все AM> остальные в мануале описаны. Hе слишком ли большое преувеличение - AM> называть это "ничего общего"?

:-))) Согласен! Я тут несколько импульсивно высказался ;-) Сейчас положение с документацией немного улучшилось. Hо вот когда я много лет назад начинал, было совсем не так радужно... Да еще и опыта работы с gcc совсем нисколько не было... Была только избалованность нормальными IDE, в которых нажал F1 и получил исчерпывающий мануал ;-)

JA>> Кстати, ты пробовал породить смешанный текст Си/Ассемблер для WinAVR? AM> Я не то что пробовал, а очень часто это делал.

Да, и я постоянно делаю.

JA>> Я порождаю (как уже говорил). В получившемся листинге приведена такая JA>> каша, что разбираться просто противно (хотя и возможно). AM> Хочется увидеть какой-нибудь пример для более предметного разговора.

Запросто. Вот кусочек тела оператора switch. Сначала исходный сишный текст:

case SERCMD_GETEEPROM: MEMORYR_block = (MEMORYR_BLOCK *)&SerialBuffer; long_num = MEMORYR_block->addr; SWAP_DWORD(&long_num); len = MEMORYR_block->len; if(len > 128) len = 128; // 128 bytes MAX chip = (byte)(long_num>>15); work_buf[0] = i2c_read(long_num&0x7FFF,&work_buf[1],len,chip); send_block(SERCMD_GETEEPROM,work_buf,len+1); break;

case SERCMD_SETEEPROM: MEMORYW_block = (MEMORYW_BLOCK *)&SerialBuffer; long_num = MEMORYW_block->addr; SWAP_DWORD(&long_num); len = MEMORYW_block->len; if(len > 64) len = 64; // 64 bytes MAX chip = (byte)(long_num>>15); stat = i2c_write(long_num&0x7FFF,(byte *)&MEMORYW_block->buffer,len,chip); send_block(SERCMD_SETEEPROM,&stat,1); break;

Можно видеть два условия: SERCMD_GETEEPROM и SERCMD_SETEEPROM. Ассемблерный текст следует за случаем SERCMD_SETEEPROM, а для случая SERCMD_GETEEPROM (идущего раньше) похожий ассемблерный текст почему-то следует много ниже, с ассемблерной строки 251 (т.е. через полсотни строк за приведенным фрагментом). Вот этот же кусочек в листинге:

69:sinter.c **** case SERCMD_GETEEPROM: 70:sinter.c **** MEMORYR_block = (MEMORYR_BLOCK *)&SerialBuffer; 71:sinter.c **** long_num = MEMORYR_block->addr; 72:sinter.c **** SWAP_DWORD(&long_num); 73:sinter.c **** len = MEMORYR_block->len; 74:sinter.c **** if(len > 128) len = 128; // 128 bytes MAX 75:sinter.c **** chip = (byte)(long_num>>15); 76:sinter.c **** work_buf[0] = i2c_read(long_num&0x7FFF,&work_buf [1],len,chip); 77:sinter.c **** send_block(SERCMD_GETEEPROM,work_buf,len+1); 78:sinter.c **** break; 79:sinter.c **** 80:sinter.c **** case SERCMD_SETEEPROM: 81:sinter.c **** MEMORYW_block = (MEMORYW_BLOCK *)&SerialBuffer; 176 .LM8: 177 007a 80E0 ldi r24,lo8(SerialBuffer) 178 007c 90E0 ldi r25,hi8(SerialBuffer) 179 007e 9093 0000 sts (MEMORYW_block)+1,r25 180 0082 8093 0000 sts MEMORYW_block,r24 82:sinter.c **** long_num = MEMORYW_block->addr; 182 .LM9: 183 0086 E091 0000 lds r30,MEMORYW_block 184 008a F091 0000 lds r31,(MEMORYW_block)+1 185 008e 8081 ld r24,Z 186 0090 9181 ldd r25,Z+1 187 0092 A281 ldd r26,Z+2 188 0094 B381 ldd r27,Z+3 189 0096 33E8 ldi r19,lo8(131) 190 0098 E32E mov r14,r19 191 009a F12C mov r15,__zero_reg__ 192 009c EC0E add r14,r28 193 009e FD1E adc r15,r29 194 00a0 F701 movw r30,r14 195 00a2 8083 st Z,r24 196 00a4 9183 std Z+1,r25 197 00a6 A283 std Z+2,r26 198 00a8 B383 std Z+3,r27 83:sinter.c **** SWAP_DWORD(&long_num); 200 .LM10: 201 00aa C701 movw r24,r14 202 00ac 00D0 rcall SWAP_DWORD

и т.д.

Какого хрена ассемблерный текст для SERCMD_GETEEPROM переместили черт знает куда - ума не приложу...

AM> Из общих соображений - при сильно включенной оптимизации оптимизатор AM> может так сильно переставлять группы инструкций, что действительно, AM> результат становится мало похож на исходную мысль. Hо это вполне AM> понятно, и в вину ему быть поставлено никак не может. Обычно же все AM> вполне читаемо: кусочем исходного кода, за ним получившийся из него AM> код. Следующий кусочек исходника - следующий кусочек асемблера. Что AM> еще может быть нужно от листинга?

По приведенному фрагменту отчетливо видно, что в этом месте никакой оптимизацией и не пахнет, просто линейный набор ассемблерных комманд. Однако желаемого мною чередования текста Си/Ассемблер ни черта нет. Это фрагмент avr-gcc. Для WinAVR положение еще хуже, т.к. те же самые флаги (-Wa,-acdhlmn=$(<:.c=.lst)) вообще не дают желаемого листинга. Листинг все же можно получить, если задать ключ -gstabs, а не просто

-g. Hо в этом случае сначала идет весь сишный текст функции с case'ами, потом одной вспомогательной функции, потом еще одной вспомогательной функции, и вот её-то текст чередуется строками Си/Ассемблер. Затем следует голый ассемблерный текст первой вспомогательной функции, и, наконец-то текст функции с case'ами, тоже в виде голого ассемблерного текста. Какой-то мрак...

JA>> Иногда я даже JA>> с помощью avr-objdump порождаю дизассемблированный листинг, и то легче JA>> разобраться... AM> Hе представляю, как может быть легче разобраться в тексте без AM> включения фрагментов исходного кода и настоящих имен символов...

Иногда бывает легче. Вот характерный фрагмент из файла дизассемблера для другой функции (для приведенного выше фрагмента там на самом деле нет сишного текста, только имена вызываемых функций. Т.е. для моего треклятого switch'а нормального листинга я добиться не могу):

0000045c <ALTERA_read>: { byte b,bt;

// Generate START MSDA_BIT_RESET; 45c: a1 9a sbi 0x14, 1 ; 20 MSCL_BIT_RESET; 45e: aa 98 cbi 0x15, 2 ; 21

// Send register no if(register_no & HIGH_BIT_MASK) MSDA_BIT_SET; // Bit A4 460: 84 ff sbrs r24, 4 462: 02 c0 rjmp .+4 ; 0x468 <__stack+0x9>

464: a1 98 cbi 0x14, 1 ; 20 466: 01 c0 rjmp .+2 ; 0x46a <__stack+0xb>

else MSDA_BIT_RESET; 468: a1 9a sbi 0x14, 1 ; 20 register_no<<= 1; 46a: 88 0f add r24, r24 MSCL_BIT_SET; MSCL_BIT_RESET; 46c: aa 9a sbi 0x15, 2 ; 21 46e: aa 98 cbi 0x15, 2 ; 21

и т.д.

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

Юргис

Hello Alex.

28 Jul 06 23:35, you wrote to me:

NM>> В 306 NM>> ----------- NM>> ----------- NM>> Эта ошибка не у них!

Вполне возможно, что и там чтото вылезет.

:(. Понятно, а я удивлялся, что из 90Мб аврстудии 4 - 42мб сервиспаки...

Nicolas

Hello Alex.

28 Jul 06 23:09, you wrote to me:

NM>>>> А винавр обязательно надо юзать с аврстудией.

NM>> Тебе действительно нужен ответ с моей позиции чайника?

Просто не програмировал на с вообще. Осмотрелся вокруг (в лаборатории), и понял, что пришло время заменить зоопарк из 486 /586 с управляющими прогами на паскале чемто, что меньше места занимает... Да и не пикомания это, - две новые 10 оборотные крутилки стоят дороже сдвоенного цапа с контроллером и управлением через 232 впридачу. Кроме того нехочется во время настройки сидеть рядом с аппаратом, время уже не то.

NM>> Я имел ввиду эмулятор. Он мне помог.

Програмный. :(.

Понятно.

NM>> Что я насовал в мейк - это моя проблема. А авторы NM>> студии info по ключам к gcc читали.

Именно. Ж:-).

NM>> Правильный вопрос - 50% ответа. Его можно не задавать публично.

Вопрос конечно обширный, а ответ крайне прост - RTFM. Hаверно былобы разумно написать где части этого самого FM лежат, и за что отвечают. Мне говорили, что в освоении линуховой тулзени самое главное - уметь извлекать информацию... Nicolas

Привет Jurgis!

29 Jul 06 18:57, Jurgis Armanavichius писал Alex Mogilnikov:

AM>> Хочется увидеть какой-нибудь пример для более предметного AM>> разговора.

JA> Запросто. Вот кусочек тела оператора switch. Сначала исходный сишный JA> текст:

[...]

JA> Можно видеть два условия: SERCMD_GETEEPROM и SERCMD_SETEEPROM. JA> Ассемблерный текст следует за случаем SERCMD_SETEEPROM, а для случая JA> SERCMD_GETEEPROM (идущего раньше) похожий ассемблерный текст почему-то JA> следует много ниже, с ассемблерной строки 251 (т.е. через полсотни JA> строк за приведенным фрагментом). Вот этот же кусочек в листинге:

[...]

JA> Какого хрена ассемблерный текст для SERCMD_GETEEPROM переместили черт JA> знает куда - ума не приложу...

Это тот самый случай, о котором я говорил - так работает оптимизатор. Описанный тобой эффект наблюдается при компиляции с -O2 или -O3. Попробуй скомпилировать с -O0, -O1 или -Os - фрагменты будут следовать в ожидаемом тобой порядке. При желании можешь найти, какой именно метод приводит к описанному эффекту.

JA> Это фрагмент avr-gcc. Для WinAVR положение еще хуже, т.к. те же самые

? Всегда считал, что это одно и то же. Точнее, когда только заговорили про winavr, я спрашивал, кто это такой. Мне объяснили, что это gcc, собранный с target=avr и host=win32. Меня обманули? :)

JA> флаги (-Wa,-acdhlmn=$(<:.c=.lst)) вообще не дают желаемого листинга. JA> Листинг все же можно получить, если задать ключ -gstabs, а не просто JA> -g.

А ассемблер тот же? По идее, за листинг-то отвечает не только (и даже не столько) GCC, сколько ассемблер. GCC только дает ему указания на строки исходника, которые дали сгенеренный код...

AM>> Hе представляю, как может быть легче разобраться в тексте без AM>> включения фрагментов исходного кода и настоящих имен символов...

JA> Иногда бывает легче. Вот характерный фрагмент из файла дизассемблера

JA> // Send register no JA> if(register_no & HIGH_BIT_MASK) MSDA_BIT_SET; // Bit A4 JA> 460: 84 ff sbrs r24, 4 JA> 462: 02 c0 rjmp .+4 ; 0x468

О! А я и не знал, что его дизассемблер умеет и фрагменты исходника показывать...

Всего наилучшего, [Team PCAD 2000] Алексей М. ... Чем ветеринары кормят своих собак? Белый фосфор. Ваша собака светится!

Привет!

Sun Jul 30 2006 01:56, Alex Mogilnikov wrote to Jurgis Armanavichius:

JA>> Какого хрена ассемблерный текст для SERCMD_GETEEPROM переместили черт JA>> знает куда - ума не приложу... AM> Это тот самый случай, о котором я говорил - так работает оптимизатор. AM> Описанный тобой эффект наблюдается при компиляции с -O2 или -O3.Попробуй AM> скомпилировать с -O0,-O1 или -Os - фрагменты будут следовать в ожидаемом AM> тобой порядке. При желании можешь найти, какой именно метод приводит к AM> описанному эффекту.

Пути генерации кода компилятором gcc неисповедимы... До опции -O1 листинг нормальный, а начиная с -O2 вплоть до -Os - кусок кода переставлен. Причем, переставленный кусок очень похож во всех вариантах, переход на него делается jump'ом. Hахрена было переставлять?... Какая разница, где территориально тот кусок находится? Оставили бы в нужном месте и все...

JA>> Это фрагмент avr-gcc. Для WinAVR положение еще хуже, т.к. те же самые AM> ? Всегда считал, что это одно и то же. Точнее, когда только AM> заговорили про winavr, я спрашивал, кто это такой. Мне объяснили, AM> что это gcc, собранный с target=avr и host=win32. Меня обманули? :)

Понятия не имею. Может быть WinAVR - просто дальнейшее развитие avr-gcc.

JA>> флаги (-Wa,-acdhlmn=$(<:.c=.lst)) вообще не дают желаемого листинга. JA>> Листинг все же можно получить, если задать ключ -gstabs, а не просто JA>> -g. AM> А ассемблер тот же? По идее, за листинг-то отвечает не только (и даже AM> не столько) GCC, сколько ассемблер. GCC только дает ему указания на AM> строки исходника, которые дали сгенеренный код...

Во всех случаях компиляция и сборка проекта производилась с помощью средств, входящих в один пакет, т.е. и avr-gcc, и WinAVR работали в комплекте со своими родными binutils.

JA>> Иногда бывает легче. Вот характерный фрагмент из файла дизассемблера JA>> // Send register no JA>> if(register_no & HIGH_BIT_MASK) MSDA_BIT_SET; // Bit A4 JA>> 460: 84 ff sbrs r24, 4 JA>> 462: 02 c0 rjmp .+4 ; 0x468 AM> О! А я и не знал, что его дизассемблер умеет и фрагменты исходника AM> показывать...

Ага! Круто! Я когда первый раз увидел - сильно удивился. Работают люди :-)

Юргис