Easyelectronics.ru

Здравствуйте. Кто-нибудь, когда-нибудь использовал
mikroC_PRO_AVR? Если-да, то поделитесь какие есть
плюсы и минусы у этого компилятора.

250$ - первый недостаток. Зачем искать что-то непонятное за деньги, когда есть бесплатный AVR_GCC (WinAVR), котрый входит в абсолютно бесплатную студию Atmel? К тому-же библиотеки у микроэлектроники поставляются без исходничков - еще один минус.

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


Как раз компиляторы МикроЭлектроники - куда понятнее для новичка, чем ваш AVR_GCC и прочие компиляторы.

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


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

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

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

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

Да я не новичок в микроконтроллерном деле. Много всего разного, за всем не уследишь, да и незачем. Просто случайно наткнулся, заинтересовался, что за штучка. Наличие или отсутствие библиотек меня как-то мало волнует.
Своя рубашка ближе к телу.

Тоже нравятся эти компиляторы и не только для AVR, но и для PIC и ARM и для 51.
Есть правда недостаток серьезный (кроме цены) - плохая оптимизация.
Но для "вхождения" в микроконтроллеры пойдут.

В случае оптимизации кода, наверное, лучше IAR нет.

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

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

Имеется в виду, что для одной и той же программы IAR лучше, чем
CodeVisionAVR/

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

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

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

Это отдельная реализация библы. У мя такая же есть (на gcc пишу). Выполнение дольше, размер дольше, выгода иногда уместна. Но не в библах дело. Как то читал статью с вырезками отдельный выкрутасов разных компиляторов (конечно же ссылку потерял). Компилятор microC заворачивал такие конструкции, что становилось не по себе. И это не от рук программиста зависит, и не от алгоритма, а от не оптимальности самого компилятора, который неспособен сразу сообразить, что в данном случае в AVR имеются средства, с которыми можно решить вопрос проще. Ну и еще один плюс в сторону более распространенных компиляторов - их распространенность. Легче получить помощь сообщества, больше информации по ньюансам компилятора и т.д.

Ещё по поводу оптимизации. В CodeVision оптимизация по скорости
приводит к увеличению размера кода. А при оптимизации по размеру
уменьшается скорость выполнения. А вдруг плохая оптимизация microC
увеличив код, приводит к молниеносному выполнению программы.
Кстати, попробовал сейчас скомпилировать программу, написанную,
в CodeVision. Прошло без ошибок. Может случайно. А в целом можно
сказать, что MicroC-одна из многих. На вкус и цвет товарищей нет.

Здесь не тот случай, когда можно говорить о вкусе.
CVAVR и микрос одного и вкуса и запаха
Дерьмо оно и в африке дерьмо.

Обычное явление. Чтобы сократить размер кода - надо больше использовать циклы, выделять одинаковые куски кода, оформляя их подпрограммами. При этом увеличивается время за счет проверок условий, переходов, и дополнительной работы стека.

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

Требования по быстродействию и размеру - всегда были противоречивыми.

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

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

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

Много еще всякого, на чем можно сэкономить...

Не нравится - не ешь.

Всю жизнь питайся только икрой и устрицами.

Вот и холиварчик :)
А вот объясните мне, любители микроси, чем он лучше атмеловской студии с ее тулчейном?

А зачем?
Лучше попробовать и сравнить. Не понравится - значит, не судьба...
Но это - и не повод обсирать, как тут некоторые. Ничем другим себя пока не проявившие.

Я - так себе, (перепробовав многое), - МикроПаскаль выбрал. Нравится.
Мог бы писать и на чем другом, но той легкости и удовольствия - почему - то от других компиляторов для микроконтроллеров - не ощущаю... А на этом - пишу, как думаю. Не заморачиваясь на борьбу с компилятором, не листая поминутно справочников по языку, не вглядываясь в Сишные закорючки.

Причем одинаково легко пишу и для PIC16, и для Меги 128, и для простых AVR...
Могу некоторые куски кода (например, разборку команд с радиоканала), напрямую с PIC16 ходового контроллера на Мегу 128 - Центрального, переносить, практически без переделок.
Да и снова написать - минутное дело...

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

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

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

Не знаю как в МикроС, но в МикроПаскале - давно есть, еще до PRO вроде уже было. Правда, я редко ей пользуюсь.
Давно еще как - то, несколько лет назад, поймался на том, что после неоднократных сверток и разворачивания, после сохранения программы потерял часть листинга. С тех пор не пользуюсь, на всякий случай... Да и при моих обьемах пока это неактуально. Только в ЦК, когда почти все его 128 кб забью, тогда - может, и понадобится. Для 8-16кб - вроде бы ни к чему.

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

Совсем уж низко, до просмотра регистров, - никогда не было необходимости опускаться. Всегда программа в основном работала, если что не так - то бывало уже на довольно высоком уровне, в самом алгоритме. А чтобы просто не работало что-то из железа (USART, ШИМ, АЦП, таймеры или еще чего), - под МикроПаскалем ни разу не было. Все идет с ходу.

Но если надо - всегда в программе можно затычку сделать для выдачи по команде любой переменной, слова состояния или регистра. В контроллере башни, например, использовал. Для прямой побитной установки внешних регистров 74HC595 при отладке.

Если вы думаете что ваш Arduino лучше перечисленных компиляторов, то это еще под вопросом. Там тоже не всё так гладко.

Дело не в "модности" или "крутости"... а в правильном выборе инструмента...
AVR-GCC... С30 GCC... С32 GCC... и на кой этот убогий микропаскаль или микроси сдался???

Никто никому ничего не навязывает... кому нравится пусть прямо в блокноте HEX строчит... маленькими буквами...
И "толпа" не всегда плохо... по AVR-GCC легко нагуглить кучу примеров, уроков, справок, исходников, что для новичка наиболее ценно...
Да и на форумах, если что, быстрее ответят по AVR-GCC, чем по микроси...
А профи просто не станут пачкаться об всякие микро... им некогда фигнёй заниматься...

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

Убогость - не столько в инструменте, сколько в головах и руках.
Сравните мебель, сделанную мастерами - краснодеревщиками 17-18 века, и супер-пупер технологичные клееные опилки современных коробок.

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

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

SWG, это все выяснено давно . Куча шишек набита , тонна холивара вылита.
А вот как Вы можете судить, работая только с одним компилятором и абсолютно не зная С ?

Компиляторы я пробовал разные. Хоть и не все существующие, естественно. Так что сравнивать есть с чем.
С я тоже пробовал. Как и кучу других языков. И С++ еще 20 лет назад.

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

Кроме того, я подбираю инструмент под задачу.
Если мне в огороде хватает тележки, нахрена мне загонять туда самосвал? Я дольше его нагружать и разгружать буду, проехав всего десяток метров... И не везде он проедет...

И у большинства тут присутствующих, особенно начинающих - задачи еще проще моих...

Ну, а для профессионала, как я уже писал - проблемы выбора нет. Какой компилятор на работе купили, на том и пиши. Да профессионал и не будет спрашивать, на чем ему писать.
Он и так знать все обязан (по определению).
Иначе - какой же он нахрен профессионал...

Но этот форум (даже по названию) - не для них.

Вот сделал тест двух компиляторов: CVAVR 2.05.0 и MikroC 5.8.0 на примере целочисленного комплексного БПФ над 1024 16бит int массивами.
Несколько удивило, мой любимый CVAVR 2.05.0 по оптимизации speed не много проиграл по размеру, и сильно проиграл по скорости, аж на треть медленнее!
cvavr 334b-6us 3832b-180us
mikroc 256b-6us 3620b-120us
Первые числа, это пустой цикл, 8МГц внутренний тактовый.
Можете проверить, в файле все и файл симуляции в proteus
Прошу, кто с GCC AVR на ты, сделайте этот пример, сравним.