[Karl 0]

не стандартные, но очень удобные при разработке :).

[BVU 0]

не стандартные, но очень удобные при разработке :).

<{POST_SNAPBACK}>

 

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

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

[axis 0]

Доброго времени, Все.

 

Что характерно - буржуи с avrfreaks практически не используют IAR. Вместо этого они активно юзают GCC и WinAVR.

 

Базару нет, что IAR круче (он ведь денег стоит) чем халявный GCC.

 

Только вот как быстро вы "с нуля" реализуете проект какой-нибудь "пикалки" с LCD и i2c-периферией ?

 

Под IAR прийдется прописывать все низкоуровневые операции самостоятельно. Да - в итоге вы будете полность контролировать код (ведь это будет ваш код). Только вот времени на это уйдет - не одна неделя.

 

Чем берет GCC (CodeVision, etc...) - "в них есть все, что нужно". Вы пишите только свою бизнес-логику. А весь низкоуровневый геморр отдаете на совесть разработчика компилятора. Здесь тоже есть свои минусы - ибо реализация "стандартной" (которая на самом деле как раз и включает в себя кучу полезных "фишек") библиотеки не идеальна и, как правило, содержит трудноуловимые ошибки.

 

И тут, как всегда, мы приходим к вопросу - так что же делать ?

 

Лично я на своем опыте убедился - если важно сделать быстро (дабы обойти конкурентов и предъявить хотя бы что-то) - нужно юзать CodeVision (WinAvr, Atman). Пусть и "сырое" зато уже есть. Кстати - вы вспомните как развивались продукты Microsoft...

 

Если времени дофига и хочется сделать "конфетку" - базара нет - только IAR.

 

Это ситуация на данный момент. А что будет через полгода - посмотрим.

 

Спасибо за внимание...

[dxp 38]

Что характерно - буржуи с avrfreaks практически не используют IAR. Вместо этого они активно юзают GCC и WinAVR.

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

 

Только вот как быстро вы "с нуля" реализуете проект какой-нибудь "пикалки" с LCD и i2c-периферией ?

 

Под IAR прийдется прописывать все низкоуровневые операции самостоятельно. Да - в итоге вы будете полность контролировать код (ведь это будет ваш код). Только вот времени на это уйдет - не одна неделя.

Какие низкоуровневые операции переписывать? С чего переписывать?...

 

Чем берет GCC (CodeVision, etc...)  - "в них есть все, что нужно". Вы пишите только свою бизнес-логику. А весь низкоуровневый геморр отдаете на совесть разработчика компилятора.

В самом GCC никаких прикладных нестандартных вещей нет - это обычный программерский пакет, такой же как и IAR. Если кто-то для него написал библиотеку, так это другое дело. Для IAR тоже много чего написано. По большому счету, совершенно не важно, для какого пакета написан код, если он написан на С/С++ и написан грамотно. Наличие в CodeVision поддержки LCD для кого-то, возможно, и является значимым плюсом, но, имхо, это просто мелкая фенька. Гораздо важнее, что кодогенерация у IAR'а заметно лучше, и вообще фичи языка IAR поддерживает несравненно лучше - взять хотя бы ++, которых у CV вообще нет (и вряд ли появятся). К тому же лично, например, предпочитаю реализовывать подобные вещи сам - разобраться надо по-любому, а собственно реализация, когда уже знаешь, что к чему, много времени и сил не занимает.

 

Лично я на своем опыте убедился - если важно сделать быстро (дабы обойти конкурентов и предъявить хотя бы что-то) - нужно юзать CodeVision (WinAvr, Atman). Пусть и "сырое" зато уже есть. Кстати - вы вспомните как развивались продукты Microsoft...

 

Если времени дофига и хочется сделать "конфетку" - базара нет - только IAR.

<{POST_SNAPBACK}>

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

 

И напоследок. Вот подумайте над такой вещью. Вот надо мне кольцевой буфер. Для байтов. Вот написал я его. А потом понадобилось то же самое для целых. Или для структур. На IAR'е я напишу шаблон:

 

template<typename T, word size, typename S = byte>

class ring_buffer { ... }

 

и буду инстанцировать себе буфера:

 

ring_buffer<char, 16> CharBuf; // колцевой буфер на 16 char
ring_buffer<int, 8>   IntBuf;  // колцевой буфер на 8 интов

 

IAR это позволяет. GCC тоже. А CV? И сколько нужно времени, чтобы переписывать для CV одно и то же? И надо ли? Т.ч. еще вопрос, откуда и что переписывать. И где на выходе результат быстрее получится.

[IgorKossak 0]

Что касается буржуйских форумов, то надо знать их специфику.

Там в основном всё ориентировано на бесплатное или, по крайней мере, не дорогое (AtmanAVR, например).

Во вторых, любые разговоры о лекарствах пресекаются либо модераторами либо "продвинутыми" юзерами (электрода, например).

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

В последних, AVRfreaks далеко не последний и далеко не лучший форум.

[axis 0]

Что характерно - буржуи с avrfreaks практически не используют IAR. Вместо этого они активно юзают GCC и WinAVR.

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

 

Только вот как быстро вы "с нуля" реализуете проект какой-нибудь "пикалки" с LCD и i2c-периферией ?

 

Под IAR прийдется прописывать все низкоуровневые операции самостоятельно. Да - в итоге вы будете полность контролировать код (ведь это будет ваш код). Только вот времени на это уйдет - не одна неделя.

Какие низкоуровневые операции переписывать? С чего переписывать?...

 

Чем берет GCC (CodeVision, etc...)  - "в них есть все, что нужно". Вы пишите только свою бизнес-логику. А весь низкоуровневый геморр отдаете на совесть разработчика компилятора.

В самом GCC никаких прикладных нестандартных вещей нет - это обычный программерский пакет, такой же как и IAR. Если кто-то для него написал библиотеку, так это другое дело. Для IAR тоже много чего написано. По большому счету, совершенно не важно, для какого пакета написан код, если он написан на С/С++ и написан грамотно. Наличие в CodeVision поддержки LCD для кого-то, возможно, и является значимым плюсом, но, имхо, это просто мелкая фенька. Гораздо важнее, что кодогенерация у IAR'а заметно лучше, и вообще фичи языка IAR поддерживает несравненно лучше - взять хотя бы ++, которых у CV вообще нет (и вряд ли появятся). К тому же лично, например, предпочитаю реализовывать подобные вещи сам - разобраться надо по-любому, а собственно реализация, когда уже знаешь, что к чему, много времени и сил не занимает.

 

Лично я на своем опыте убедился - если важно сделать быстро (дабы обойти конкурентов и предъявить хотя бы что-то) - нужно юзать CodeVision (WinAvr, Atman). Пусть и "сырое" зато уже есть. Кстати - вы вспомните как развивались продукты Microsoft...

 

Если времени дофига и хочется сделать "конфетку" - базара нет - только IAR.

<{POST_SNAPBACK}>

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

 

И напоследок. Вот подумайте над такой вещью. Вот надо мне кольцевой буфер. Для байтов. Вот написал я его. А потом понадобилось то же самое для целых. Или для структур. На IAR'е я напишу шаблон:

 

template<typename T, word size, typename S = byte>

class ring_buffer { ... }

 

и буду инстанцировать себе буфера:

 

ring_buffer<char, 16> CharBuf; // колцевой буфер на 16 char
ring_buffer<int, 8>   IntBuf;  // колцевой буфер на 8 интов

 

IAR это позволяет. GCC тоже. А CV? И сколько нужно времени, чтобы переписывать для CV одно и то же? И надо ли? Т.ч. еще вопрос, откуда и что переписывать. И где на выходе результат быстрее получится.

<{POST_SNAPBACK}>

 

Ответ понятен.

Теоретически все правильно и логично.

 

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

 

Так вот, примерно год назад встал вопрос - чем написать софт под Мегу128.

Выбирал между CV и IAR.

 

IAR понравился сразу (ибо есть большой опыт работы под Visual Studio). Начал и погряз в рутине. Может быть плохо искал, но не нашел библиотек для работы с LCD на HD44780 и периферией на i2c. А затачивать под него написанное под другие среды оказалось не проще чем писать свое. А прописывать самому эту рутину было не в кайф (этож все-таки хобби).

 

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

И я считаю, что в качестве инструмента DIY-содера (типа,"сделай сам") это оптимальный выбор.

 

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

 

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

 

P.S. А вот в качетстве средства отладки _ОДНОЗНАЧНО_ всем рекомендую Proteus - вещь просто супер!

[ReAl 0]

С точки зрения качества генерируемого кода IAR безусловно опережает gcc.  Буквально неделю назад собрал проект под gcc и iar: gcc 3.4.1 нагенерил 18096, а iar 2.28a  12238 байт. У обоих включена оптимизация по скорости с максимальным уровнем оптимизации.

<{POST_SNAPBACK}>

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

Кроме того, при -O3 автоматически включается -funroll-all-loops, что тоже сильно раздувает код.

 

Как правило, достаточно -O2, возможно с некоторыми доп ключами и ручное static inline для нужных коротких функций. В этом случае разница в объёме не в полтора раза, а 5-15%.

 

Два основных источника:

- прологи/эпилоги функций, gcc использует один стек и ему надо модифицировать каждый раз SPH,SPL, да ещё и с запретом прерываний.

- gcc как правило обращается к глобальным переменным через sts/lds, тогда как зачастую выгоднее по коду загрузить указатель и ldd/std, IAR этого не упускает.

 

А вот на коротких функциях с малым числом аргументов/локальных переменных (без стекового кадра) gcc действительно зачастую даёт более короткий и быстрый код.

[m16 0]

Давно избитая тема но сравнение компиляторов всегда почему то однобокое - раз меньший объем кода генерит знач лучший. А если вопрос по другому поставить - чей код быстрее?(меньший по объему код совсем не значит что более быстрый).

[IgorKossak 0]

Давно  избитая  тема но  сравнение  компиляторов  всегда почему то  однобокое - раз меньший  объем кода  генерит знач лучший. А если вопрос  по  другому  поставить  - чей  код быстрее?(меньший по объему код совсем не  значит что более быстрый).

<{POST_SNAPBACK}>

Это Вы однобоко читаете форум.

Зачастую два параметра: скорость и компактность присутствуют в сравнениях на одном уровне.

[1891ВМ12Я 0]

IAR понравился сразу (ибо есть большой опыт работы под Visual Studio). Начал и погряз в рутине. Может быть плохо искал, но не нашел библиотек для работы с LCD на HD44780 и периферией на i2c.

Существуют ли готовые библиотеки функций для работы с LCD на HD44780 в среде IAR версии 4.11А?

[IgorKossak 0]

Существуют ли готовые библиотеки функций для работы с LCD на HD44780 в среде IAR версии 4.11А?

<{POST_SNAPBACK}>

А причём тут IAR?

Ищите просто библиотеки на C. Например на том же AVRFreaks или здесь на форуме.

Массу полезных ссылок можно найти.

[beer_warrior 0]

Серьезным преимуществом IAR IMHO являеться более удобная работа

с флеш-памятью.

Преимуществом WinAVR (опять же IMHO), более развитая библиотека

и контроль над процессом компиляции благодаря make.

В остальном они сравнимы.

[dxp 38]

Серьезным преимуществом IAR IMHO являеться более удобная работа

с флеш-памятью.

Преимуществом WinAVR (опять же IMHO), более развитая библиотека

и контроль над процессом компиляции благодаря make.

В остальном они сравнимы.

<{POST_SNAPBACK}>

IAR лучше avr-gcc во всем, кроме цены. Кодогенерация у него лучше, управление проще, поддержка оперативнее. Ничего не мешает использовать для сборки make (или хоть батник), чем лично я и пользуюсь.

[IgorKossak 0]

... контроль над процессом компиляции благодаря make...

<{POST_SNAPBACK}>

А как по мне, так гораздо важнее результат.

[1891ВМ12Я 0]

Существуют ли готовые библиотеки функций для работы с LCD на HD44780 в среде IAR версии 4.11А?

<{POST_SNAPBACK}>

А причём тут IAR?

Ищите просто библиотеки на C. Например на том же AVRFreaks или здесь на форуме.

Массу полезных ссылок можно найти.

<{POST_SNAPBACK}>

Есть ли программные эмуляторы HD44780 для IAR или AVRStudio?

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