Последний релиз WinAVR 20060421 доступен для скачивания:

http://winavr.sourceforge.net/

А чем он от предыдущего отличается?

1.0 What's New
Below is just a sample of what's new.

Support for many new processors in the toolchain.

New versions of GCC, avr-libc avrdude, SRecord, etc. including fixing a major compiler bug.

Additional new Makefile material from Carlos Lamas for C++ projects, and more material to support building libraries.

Еще в папке Doc pdf-ники gcc , cc , gdb . Описания не новые ессно но приятно когда они собраны
вместе и всегда под рукой. В старом релизе этого не было, только avrlibc.

Кто пользовался, объясните пожалуйста, в mfile
при добавлении C/C++ source file ошибка Oops, SRC not found
С старым makefile_template.old все нормально. Это что получается,
новый только для проектов С++? Или я что то не так делаю?

http://uos.vak.ru/doku.php
На данной страничке есть GCC 4.1.0 для Atmel AVR
Это чем то отличается?

В составе проекта WinAVR используется компилятор :

GNU Compiler Collection (GCC) 3.4.6

C language and C++ language compiler for AVR target. There are
caveats for using the C++ compiler. See the installed avr-libc
User Manual in the <InstallDir>\doc directory.With the following patches:gcc-3.4.3-c-incpath.patch
Used to build GCC in MSYS. See GCC PR #20594.

gcc-collect2-win32-dave.patch
Used to build GCC for MinGW host.

gcc-fixinc-win32.patch
Used to build GCC for MinGW host.

gcc-misspelled-signames-ada.patch
Patch to catch misspelled interrupt and signal names. Can be used in Ada.

gcc-binary-constants.patch
Written by Joerg Wunsch. This adds the ability to write and use binary constants in the form of: 0b01011010

gcc-3.4.5-newdevices.patch
This adds new AVR devices to the toolchain.

gcc-3.4.5-dwarf2-address-size.patch
GCC bug #19087.



А сам проект WinAVR не является компилятором.

Скажите пожалуйста, а почему Вы такого скверного мнения о WinAVR? И чем связка CV + VMLAB лучше? В конце концов, объектные файлы с WinAVR вроде тоже можно загрузить в VMLAB, а если я не ошибаюсь, то последний как раз и ориентирован на применение с компилятором GCC. Я использовал в свое время WinAVR - вполне рабочая вещь

Не много не в тему. Есть книга "C Programming for Microcontrollers
Featuring ATMEL's AVR Butterfly and the Free WinAVR Compiler", в ней описан С применительно к WINAVR, очень даже доходчиво. Кстати Vmlad работает с WINAVR очень хорошо, С код можно править прямо в VMLab не переключаясь в winavr.

Вот-вот, я это и имел ввиду. Правда VMLAB'ом не пользовался никогда, предпочитал все отлаживать в AVRStudio и на железе.

На WinAVR можно и забить (особенно если у вас linux ), но на gcc забивать сооовсем не стоит:
1) хотя бы потому что на нём вы можете писать под AVR, под windoze (linux, qnx), если нужна программа верхнего уровня (mingw),
2) можно легко перенести Ваш проект на другую архитектуру, (ARM хотя бы, для меня актуально), даже не сейчас, а через 5 лет на в данный момент не существующую,
3) алгоритмы (не ногодрыгства, а помехоустойчивого кодирования и т.д.) гораздо легче отлаживать на компе - как CodeVisionAVR что-то соберёт под i386?
4) и много других причин (бесплатная, свободная прога и т.д. и т.п.)

Так что - "Очень советую забить на CodeVisionAVR"

Здорово изложили!!! Именно по этим причинам я тут в последнее время подумываю, а не вернуться обратно к GCC?

На счет последней фразы, хоть она и со смайликом, но давайте жить дружно

P.S. Кстати отлаживать некоторые, не зависящие от железа, подпрограммы очень удобно на ПК. Потом лишь достаточно перенести код (благо это Си - минимальные доработки) на конечную платформу и насладжаться результатом.

И все-таки, простите за назойливость, не могли бы Вы рассказать, чем так хорош CV, и почему следует "забить" на WinAVR?

Присоединяюсь, особо интересует собственно компилер.

Насколько я понял (возможно неправильно) - Вы пользовались обоими, рассказ хотелось бы услышать. Мне как-то не хочется заморачиваться с vmware, виндой, чтобы потестить CodeVisionAVR, потому Ваш опыт (возможный) весьма интересен.

Тогда наверно еще не стоит забывать про такой популярный компилятор, как IAR ;)


Присоединяюсь.

Строки с сайта, из курса №4



Особенно инетерсно звучит это



В резултате работы мастера генерации кода наинающий программист избавляет себя от "тяжелого" труда. Но если мастер не удовлетворяет его потребностям или что-то делает не так, начинаются подобные вопросы, как здесь http://electronix.ru/forum/index.php?showtopic=15868

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

to [banned] а вы никогда с багами визарда CV на новые камни не сталкивались? я лично дважды
согласен заранее,они оперативно в следующей версии исправлялись,но тем не менее...
и смысл визарда не в освобождении от чтения шита,а для совсем небольшого облечения труда програм-
мера.я к чему все это-описалово читать надо в любом случае,особенно начинающему

WHALE,
про баги CV в конфах как-то не особенно слышно, а вот про баги EWAVR сообщения частенько проскакивают.
Я за 4 года работы с CV столкнулся с багом в нем только один раз.

IAR мощнее, лучше жмёт код, но работать с CV проще, удобнее, и начинать с него - легче, значительно меньше тратится времени. Переход на CV с ассемблера даётся вообще без усилий - идеология построения проекта та же самая, плюс возможность свободно смешивать сишный и ассемблерный код. Набор полезных библиотек прямо в дистрибутиве, и другие удобные мелочи.

Пишу на IAR для ARM-ов, а AVR по-прежнему программирую с помощью CV - устраивает целиком и полностью.

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

Да, Вы конечно можете сказать, что если нужно по-быстрому сделать хоть как-то работающий проект прошивки МК, только бы поскорее и тут визард даст выигрыш по времени. И я с этим соглашусь. НО. Если говорить о долгосрочной перспективе, мой опыт показывает, что этот путь - порочен. И один из его пороков заключается в том, что изменить что-то, лежащее за пределами возможностей визарда, частенько оказывается невозможным. Для этого приходится начинать борьбу со средой разработки, которая ориентирована на несколько неподходящий способ разработки проекта. И тут многие интегрированные среды оказываются неудобны. В то время как GNU Tools и в частности WinAVR - это конструктор, в котором можно разобраться от самых низов и до самых верхних уровней. Т.е. предоставляет максимум возможностей. А если учитывать ее интеграцию с AVR Studio и т.п. средствами моделирования, то лично для меня выбор очевиден. Плата за все эти плюсы - время на изучение. Но это оправданная плата, к тому же сейчас документации по большинству вопросов стало несравненно больше и есть много людей, которые могут подсказать и помочь.

У меня на этот счет есть такая мысль: пусть новичка удовлетворяет wizard на 100%. Он им пользуется продолжительное время. Соответственно человек не выполнял в ручную той работы, которую за него добросовестно выполняет мастер. А так как мастер конфигурирует периферию МК - фактически саму сущность МК, то при необходимости настроить периферию на какой-то отличный режим, чем предлагает мастер могут возникнуть проблемы. И ладно если человек заглянет в даташит, разберется..., а если начнет задавать вопросы в конференции или на форуме?? А фактически это фундаментальные знания (ИМХО) при программировании МК.

Я считаю, что новичку нужно дать почувствовать всю мощность МК: при этом не использовать ни каких Wizard'ов и языков высокого уровня. Начинать я считаю нужно с ассемблера. А для кого это тяжело - так может тот и не годится для программиста в сфере МК?

Эта фраза касается визардов вообще. Попробуйте хотябы пописать на MFC, что-нибудь дописать руками и потом радостно убедиться, что визард больше не работает.
Если говорить о CV и визардах, для генерации стартапа, то тут действительно, изменить можно. Но, чтобы что-то изменить разумно, нужно хорошо понимать как и что делает стартап (если под изменением понимается что-то большее, чем изменение начального значения одного или нескольких регистров), а если все это человек понимает, то для уверенности в правильности своего проекта ему проще будет написать стартап самому. Парадокс?

Цитируя haker_fox:


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

Тут дело вот в чем.
Представить возможности кристалла лучше как раз с помошью визарда, который все эти возможности раскроет в удобном для восприятия виде, ведь чем нагляднее, тем проще осмыслить. В противном случае придется долго вникать в даташит, запоминать настройки периферии, источники прерываний и прочие неочевидные моменты, и сводить всё это вместе самостоятельно. Разумеется, это не означает, что его не надо читать без изучения DS всё равно программы не написать, какой бы там визард не был.

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

Третье - начинать с готового шаблона проще, чем с пустого места; как человек, знакомый с MFC, вы должны это понимать. Понимают это и разработчики всевозможных IDE, оснащая свои творения набором визардов на все случаи жизни. Цель всё та же - ускорение разработки и отладки.

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

Не согласен, т.к. визард в первую очередь нацелен на решение какой-то частной задачи и далеко не всегда может решить общую проблему. Не может визард за разработчика написать програму. Т.е. в любом случае правильный путь это последовательное изучение DS, и только потом уже визард. Но никак не наоборот.



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



Как человек, когда-то разобравшийся с MFC, могу сказать, что если бы я сначала начал разбираться с этой библиотекой без мастеров и т.п., то гораздо раньше понял бы ее проблемы и ограничения. По этому поводу могу привести еще один пример: есть человек, который с помощью мышки и визардов пишет на MFC и не лезет глубоко внутрь. Иногда перед ним встают "нерешаемые" с помощью мыши проблемы, для решения которых нужно понимание некоторых внутренних процессов, принципов работы, которые скрыты от него визардами. Что получается? Да в общем-то ничего: человек говорит, что эта проблема не решаема, будем делать что-нибудь другое, по-проще. Если бы он начал с общих принципов (документации) и разобрался бы сначала без визардов, то я практически уверен в том, что он был решил все свои проблемы.

С целью я согласен, ускорение может иметь место. Но, ускорение будет лишь в том случае, если человек умеет эффективно использовать имеющийся инструмент. Для меня такими инструментами являются vim+консоль. Некоторые же люди не могут ими пользоваться и крутят пальцем у виска, когда я говорю, что vim очень удобный редактор исходных текстов... Это я к тому, что без знаний, которые визард не дает (не в том его задача), эффективности и скорости разработки не будет.



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

PS: Есть уже один пример - http://electronix.ru/forum/index.php?s=&sh...ndpost&p=111564

Народ, подскажите пожалуйста, как сделать что бы avrstudio c winavr показывала размер кода?

Да он и так показывает размер.

У меня
AVR Studio 4.12.462 Service Pack 1, winavr WinAVR-20060421проект на си
при компеляции показывает

Build started 12.5.2006 at 03:16:31
make: Nothing to be done for `all'.
Build succeeded with 0 Warnings...

если использовать внешний make

Program: 158 bytes
(.text + .data + .bootloader)

Data: 0 bytes
(.data + .bss + .noinit)

Вот и вопрос был.

AVRStudio4.12SP2Build471 WinAVR-20060421
показывает:
Device: atmega16
Program: 2494 bytes (15.2% Full)
(.text + .data + .bootloader)
Data: 106 bytes (10.4% Full)
(.data + .bss + .noinit)