Собираюсь изучать программирование AVR на языке Си (Ассемблер я так понял можно будет изучить потом, так как он посложней язык).
И столкнулся с такой проблемой:
Как выбор компилятора AVR studio 5 или CodeVision AVR или WinAVR
Так как я Новичок. Подскажите в чем мне программировать и какая в этих компиляторах разница ???

Ну ежели для баловства то можно CodeVision AVR.
Ну а если не в игрушки играть, то видимо WinAVR.

Лучше начать с ассемблера, а затем перейти на Си.
Чтобы использовать ассемблерные вставки в программах на Си.

У всех "спецов" я спрашиваю один вопрос -"
Не могли бы в двух словах обозначить,отсутствие каких функций или типов данных Вас расстраивает CVAVR?" и никак не могу добиться внятного ответа.Только ссылки на каких-то "очень уважаемых" спецов,которым не верить - преступление.Может Вы просветите.
Хотя мне всё равно,какой диалект языка С использовать.

Вы видите разницу между трёхколёсным велосипедом и спортивным?
Что у одного есть и колёса и шины и педали, но почему-то спотсмены катаются на спортивных, а дети на трёхколёсном.
Так-же и сдесь.

radiokot__ Спасибо Вам за ответ, мне понравилось как вы ответили.

Очень распальцованно вы ответили. А конкретно пшик.

конкретно - юнионы там появились, начиная с версии 2.3.4 - до нее ими там и не пахло.
Формат long у меня в каких-то ситуациях становился двухбайтовым, я не спорю, может так и задумывалось.
По поводу мат вычислений - много буков, имхо, ОЧЕНЬ сильно проигрывает винавр.
А так ничего, можно работать, если не пользоваться встроенными стандартными библиотеками, которые единолично пожирают ресурсы контроллера.

И еще подскажите мне в AVR Studio 5 есть проект AVRGCC С Executable Project он и есть WinAVR ?

Во-первых, из перечисленных вариантов выбора AVR Studio не является компилятором, это всего лишь интегрированная среда разработки (IDE), "оболочка", к которой можно "прикрутить" в принципе любой компилятор, вызываемый из командной строки. Ранниее версии AVR Studio делались на доморощенной платформе Atmel, затем им надоело изобретать велосипеды, и они взяли за основу "пустую" заготовку от Microsoft Visual Studio. В комплект поставки по умолчанию подключен toolchain WinAVR, но, как уже говорилось, можно подключить любой другой toolchain, если сочтете целесообразным.

В принципе с тем же успехом можно выбрать и другую оболочку, например, ту же Eclipse (см. соответствующую тему в этой ветке). Плюсы и минусы каждого варианта - предмет отдельного обсуждения, просто имейте в виду, что на AVR Studio (она же с недавних пор Microsoft Visual Studio) свет клином не сошелся.

Из оставшихся двух: с CodeVision, пожалуй, проще начинать, к тому же там имеются "визарды", генерирующие код работы со встроенными устройствами чуть не на любой случай жизни (качество этого кода - отдельный вопрос, как уже упоминалось в теме, но в принципе работает). Совместимость диалекта языка C с другими реализациями компиляторов C (а главное, со стандартом) не ахти. Если планируете долгое время работать только с AVR и только в CodeVision, Вас это может и не слишком огорчить. Еще есть некоторые сомнения, станут ли lint и ему подобные (например, splint) работать с диалектом CodeVision. На практике не проверял, впрочем; может, и обойдется.

WinAVR базируется на версии GCC для AVR, и этим все сказано. Сегодня трудно сказать, GCC ли пишут по стандарту или стандарт подгоняют под GCC, но с соответствием там все довольно неплохо. Кроме того, GCC реализован для огромного количества процессоров, так что сменить аппаратную платформу при необходимости будет гораздо проще (например, решите впоследствии перейти на ARM). Кроме того, GCC имеется и для IBM PC (под Windows и Linux), поэтому более 90% кода сможете выполнить (и протестировать) на своей персоналке, даже не прошивая его контроллер. Еще один фактор - при желании перейти на Linux практически ничего для Вас не изменится, в случае же CodeVision возможны проблемы (личо мне не попадались версии для других ОС, кроме Windows).

Вот Вам вкратце основные плюсы и минусы, окончательный выбор за Вами.

Не могли бы указать слабые места "трёхколесности".
В CVAVR,к примеру, можно отметить участки кода,в которых будет отключена оптимизация при компиляции.Да есть ещё одна приятная фишечка-можно отключать варнинги участков кода,в безопасности кода которых Вы уверены,и долгое время используете в своих библиотеках.





Что-то из темы -"Не читал,но осуждаю"(с).

Странно, порылся в своих старых сырцах:

Озадачили вы меня ) Сейчас почитаю соответствующею ветку. А вот ваши слова "на AVR Studio свет клином не сошелся" мне понравились.

Начинать полюбому лучше с ассемблера чтения документации, уже после этого ассемблер. Не для использования вставок, разумеется а для понимания функционирования контроллера (что такое стек, разрядность переменных, скорость выполнения, работа подпрограмм и тому подобное).
Потом можно браться за языки высокого уровня: Наиболее распространен Си но встречаются извращенцы и С++ и Pascal и даже Basic, выбор языка - на ваш вкус.
Что-то говорили о портируемости... Вряд ли портировать С-код намного проще чем ассемблерный, уж больно много места занимают непосредственное использование регистров и прочего платформо-зависимого. И даже avr-gcc не совсем совместим со стандартом языка C (хотя бы обращения к различным областям памяти - flash, SRAM, EEPROM - функции отличаются)
Именно про avr-gcc vs cvavr: несмотря на те же костыли для работы с флешом, avr-gcc гораздо ближе к реализации стандарта Си. После некоторого времени программирования для компьютера конструкции PORTD.5 вызывают довольно сильную неприязнь. Библиотеки cvavr ("не читал но осуждаю", да) используют наиболее универсальную реализацию. Соответственно без использования прерываний, таймеров и прочих полезных вещей. Насчет надежности говорить не буду, наверняка не меньше чем у самописных а куда как больше. Зато, например, чтобы получить байт от UART'а придется тормозить весь камень, нехорошо-с. Хотя, конечно, никто не возбраняет переписать с нуля.
что-то подобное volatile?
Ну это смотря как программировать. Мне было неудобно отказываться от подсказок AVRStudio и программатора с графическим интерфейсом. Но это скорее дело привычки. А так да, avr-gcc(Си), avra (ассемблер), avrdude(программатор, причем во много раз универсальнее AVRProg'a) вполне достаточно.

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

Если бизнес-логика аккуратно отделена от жонглирования битами в портах, тут все попроще. Если же вся аппаратная зависимость сосредоточена в тонкой прослойке HAL, объем работ минимален. Люди Linux таскают с платформы на платформу, а мы тут с несчастным дрыганьем битов в портах проблемы создаем на пустом месте...

IMHO превосходная практика - использование паттерна MCH (близкий аналог паттернов MVC и MVP из мира десктопных приложений). Примеры применения: "Развитие в направлении разработки встроенных систем", "Эффективная разработка встроенного ПО через тестирование".

Я бы даже сказал, "смотря что понимать под программированием". Если сам процесс заливки кода в кристалл, то да, все выглядит по-другому. Если в более широком смысле (как весь процесс разработки от сбора требований до выпуска релиза), то разница в наборе кнопочек редактора и подсказках среды большой погоды не делает. Опять же, дело вкуса.

Лично мне, наоборот, не слишком комфортно было регулярно прыгать из Studio, где производится собственно кодирование, в StarUML, где ведется проектирование программы, и обратно. Не нашел ничего подходящего для работы с UML в среде Studio. А вот для Eclipse быстро нашелся подходящий плагин, и теперь проект действительно интегрирован, а не раскидан по разным файлам. Опять же - без жесткой привязки к ОС...

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

Как splint в действительности относится к особенностям синтаксиса CodeVision?

Для ясности. Проект WinAVR ушёл под клыло Atmel и теперь называется Atmel AVR Toolchain.
Можно скачать как отдельно (win, lin), так и в составе AVR studio.

ds1307, попробуйте в этой версии работу в юнионах с битовыми полями - я не привык флудить. Если я пишу, что были проблемы, которые вылечились версией 2.3.4 - значит, так и было. Но поднимать свои проекты 4 летней давности - не буду. Я ценю свое время.

volatile - это спецификатор переменной,которая изменяется в прерываниях,а я говорил о командах препроцессора CVAVR(#pragma optsize- и #pragma optsize+).Если Вы посчитали,что Ваш код получается где-то кривоватым,то там можно отключить оптимизацию,но только там где это необходимо Вам,а не отключать оптимизацию полностью.
Гляньте настройки проекта в CVAVR и WinAVR,в первом кнопочек поболее будет.

Теперь о WinAVR,небольшие непонятки у меня возникли в нём с привидением типов,вот такой код


вызывает такую ошибку - error: lvalue required as left operand of assignment

... лучше понять, чего Вы хотите этим добиться?

PS. Думаю, что или даже сработают как нужно, но в последнем случае возможно предупреждение...