Т.е. вместо чтоб почитать мануал и подумать человек тратит время на бессмысленное применение метода тыка к кнопочкам. Иногда это приводит к резуьтату (сомнительному...) Иногда нет. Чтение мануала даёт результат за некое конечное время.
И где надо вникать в такие подробности работы компилятора, о каких программист под ПЦ может запросто и не догаддываться.
Потому что там чётко отделены мухи от котлет. Это компилятор, а не редактор или что-то ещё. GNU предлагает редактор отдельно... как и множество других утилит.
А про документацию -- это не так. GNU имеет *хорошую* пользовательскую документацию. Часто значительно более хорошую, чем даётся с коммерческими компиляторами. Понятную (я не спорю, hitech и keil, например, дают тоже неплохую документацию, но там часто, почему-то часть опций компилятора то ли скрывается, то ли забыта...) У некоторых вон Эндцать дисков документации (я до конца жизни не осилю) на непонятном неанглийском-английском... Другое дело, что GCC -- это одно, а "бакенд" AVR к нему -- совсем другое. И результат соответствующий.
За примерами тоже далеко ходить не надо, не дальше гугля и мне повезёт.
Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 26 Jul
2006 12:02:56 +0000 (UTC):
KF>>> Это очень модное в настоящее время мнение. Что я, юзер что ли, KF>>> мануалы читать. Дайте мне IDE, где на всякий случай есть KF>>> специальная кнопка (список прилагается...)
KF> Т.е. вместо чтоб почитать мануал и подумать человек тратит время KF> на бессмысленное применение метода тыка к кнопочкам. Иногда это
Это не так. В смысле не бессмысленное. Во-первых, во всех подобных программах кнопочки более-менее похожи. Во-вторых, там есть хэлп, который в подобной ситуации читать легче, чем мануал - он контекстный.
KF> приводит к резуьтату (сомнительному...) Иногда нет. Чтение мануала KF> даёт результат за некое конечное время.
За заметно большее время и при приложении бОльших усилий. Разобраться в линкерных скриптах, куче опций компиляции, управлении сборкой проекта в IDE на несколько порядков проще, чем читать кучи довольно невнятной в случае gcc документации, тем более не знаю как сейчас, а до недавнего времени нужно было отдельно читать про gcc вообще, отдельно про его особенности для того же AVR, отдельно про остальной инструментарий. И документация не была отягощена примерами готовых проектов и пошаговым описанием их создания.
KF> И где надо вникать в такие подробности работы компилятора, о каких KF> программист под ПЦ может запросто и не догаддываться.
Иногда надо, иногда не надо. Почти всегда это можно сделать потом, когда что-то уже начнет "дышать".
KF> Потому что там чётко отделены мухи от котлет. Это компилятор, а не
А заодно котлеты от всего остального обеда. В результате чтобы пообедать нужно половину приготовить самостоятельно. Причем системы с IDE (тот же IAR) это тоже позволяют, но позволяют и пообедать в режиме fastfood all included.
KF> редактор или что-то ещё. GNU предлагает редактор отдельно... как и KF> множество других утилит.
И во всем этом надо разбираться, вместо того, чтобы заниматься своей основной задачей...
KF> А про документацию -- это не так. GNU имеет *хорошую* KF> пользовательскую документацию.
Плохую, см. выше. Возможно что-то поменялось, но что-то верится с трудом.
KF> Часто значительно более хорошую, чем даётся с коммерческими KF> компиляторами. Понятную (я не спорю, hitech и keil, например, дают тоже KF> неплохую документацию, но там часто, почему-то часть опций компилятора KF> то ли скрывается, то ли забыта...)
В Hitech? И что конкретно там забыто?
KF> Другое дело, что GCC -- это одно, а "бакенд" AVR к нему -- совсем KF> другое. И результат соответствующий.
Отож. А меня не интересует что у него внутри. Я же не знаю про то где у IAR фронт, а где бэк энд. Я беру документацию на пакет для AVR или еще чего и читаю конкретное описание на конкретный инструмент.
KF> За примерами тоже далеко ходить не надо, не дальше гугля и мне KF> повезёт.
Ну да, на заборе тоже много чего написано. Я предпочитаю получить все в одной упаковке.
Wed Jul 26 2006 19:34, Dmitry Orlov wrote to Kirill Frolov:
KF>> Т.е. вместо чтоб почитать мануал и подумать человек тратит время KF>> на бессмысленное применение метода тыка к кнопочкам. Иногда это DO> Это не так. В смысле не бессмысленное. Во-первых, во всех подобных DO> программах кнопочки более-менее похожи. Во-вторых, там есть хэлп, DO> который в подобной ситуации читать легче, чем мануал - он контекстный.
Подтверждаю. Я с gcc знаком давно (в его кроссовых вариантах). Большинство прилагаемых мануалов не имело ничего общего с конкретным компилятором. Без упомянутого "тыка" с gcc ничего не сделаешь. Факт. В отличие от нормальной среды разработки, на освоение которой, при наличии опыта работы с подобными системами, тратится исчезающе малое время.
KF>> приводит к резуьтату (сомнительному...) Иногда нет. Чтение мануала KF>> даёт результат за некое конечное время. DO> За заметно большее время и при приложении бОльших усилий. Разобраться в DO> линкерных скриптах, куче опций компиляции, управлении сборкой проекта в DO> IDE на несколько порядков проще, чем читать кучи довольно невнятной в DO> случае gcc документации, тем более не знаю как сейчас, а до недавнего DO> времени нужно было отдельно читать про gcc вообще, отдельно про его DO> особенности для того же AVR, отдельно про остальной инструментарий. DO> И документация не была отягощена примерами готовых проектов и DO> пошаговым описанием их создания.
Соверщенно справедливо. В общем, gcc - для мазохистов-пингвинятников :-) Им лишняя, и совершенно ненужная, трахаловка - "неземное наслаждение!" :-)
KF>> И где надо вникать в такие подробности работы компилятора, о каких KF>> программист под ПЦ может запросто и не догаддываться. DO> Иногда надо, иногда не надо. Почти всегда это можно сделать потом, когда DO> что-то уже начнет "дышать".
А, типа, при использовании gcc вникать не нужно?! Hа порядки больше! Поди, составь Makefile с нуля... Hе то что для начинающего, для опытного пользователя - это серьезная проблема.
Ой ли...
DO> А заодно котлеты от всего остального обеда. В результате чтобы пообедать DO> нужно половину приготовить самостоятельно. Причем системы с IDE (тот же DO> IAR) это тоже позволяют, но позволяют и пообедать в режиме fastfood all DO> included.
Святая правда!
Я, вообще-то, сторонник gcc. Даже самолично скомпилировал gcc из исходников для своего микроконтроллера. Однако. Сколь ни велика моя любовь к халяве, но я _вынужден_ признать, что получившееся поделие и рядом не лежало с нормальными, коммерческими компиляторами. (Hе в плане генерируемого кода. Тут часто бывает вполне неплохо.) Я это знаю не понаслыщке. Моя библиотека арифметики с плавающей точкой (только для типа float) лежит в общем доступе (я оптимизировал оптимизированную стандартную библтотеку, исправил несколько ошибок, отличие от стандартной fplib по скорости примерно в 2,5 раза). Тем не менее я снимаю шляпу перед на самом деле серьезными продуктами...
KF>> редактор или что-то ещё. GNU предлагает редактор отдельно... как и KF>> множество других утилит. DO> И во всем этом надо разбираться, вместо того, чтобы заниматься своей DO> основной задачей...
Если еще получится разобраться... Я пробовал многократно. Всякий раз это давалось очень не легко. Оно и понятно. Если ты заплатил (имею за пазухой парочку примеров), то можешь рассчитывать, что тебя выслушают и помогут. А если нет - тут уже зависит от того, с какой ноги встал утром знаток...
KF>> А про документацию -- это не так. GNU имеет *хорошую* KF>> пользовательскую документацию. DO> Плохую, см.выше. Возможно что-то поменялось, но что-то верится с трудом.
Hичего там не поменялось. Документация на *nix-овый gcc крайне мало подходит для AVR например...
KF>> Другое дело, что GCC -- это одно, а "бакенд" AVR к нему -- совсем KF>> другое. И результат соответствующий. DO> Отож. А меня не интересует что у него внутри. Я же не знаю про то где у DO> IAR фронт, а где бэк энд. Я беру документацию на пакет для AVR или еще DO> чего и читаю конкретное описание на конкретный инструмент.
Именно! Мне, как пользователю, глубоко накласть на некий обобщенный gcc! Мне интересно, как это дело работает в контексте AVR. Хорошо, что я умею пользоваться поиском в FAR-е... А если нет?
KF>> За примерами тоже далеко ходить не надо, не дальше гугля и мне KF>> повезёт. DO> Hу да, на заборе тоже много чего написано. Я предпочитаю получить все DO> в одной упаковке.
Тем более, что гуголь выдаст столько ссылок, что ты их будешь до старости ковырять... ;-)
Автор не иначе или как читать не умеет, или нагло лгёт.
Афтар не сделает может быть. Другие -- делают.
Ага. Ноль в пределе -- выкрасить и выбросить.
Бред.
А типа от компилятора это не зависит. При использовании gcc только, вникать нужно на порядок меньше, наоборот. Потоу как у него независимо от платформы опции более или менее похожи. Как и многое другое. То ли дело с Hitech на keil переползать...
Если это проблема для тебя -- из этого ещё ничего не cледует. Makefile -- это какой никакой, а формальный способ записи правил сборки. Галочки в IDE таковым не всегда являются.
Ой ли что?
Особенно когда "нармальный коммерчческий компилятор" внутри содержит тот же gcc...
Компилятор -- это программа path\to\bin\cc.exxe. А не то, что тут некоторые считают.
Разобраться с особенностями редакторов в десятке IDE -- я точно не в состоянии. С одним как-нибуь разберусь. Хотя нет, я вот не знаю как сделать, чтоб я мышкой в строкку тыкал, а оно cvs annotate смотрело и потом log для этой строчки вытягивало. Расскажи, какая IDE так умеет?
Расчитывать ты можешь на что угодно. А получить только то, за что заплатил.
Это твои, как пользователя, личные трудности. Инфомрация есть и она любому разумному человеку вобщем-то доступна.
Если нет -- вам вообще компутер не нужен. А то вдруг, вы читать не умеете вовсе?
Это сильно лучше, чем когда он их вообще не выдаёт.
Можно ли методом тыка изучить, например, язык программирования C?
Ага. Т.е. он на каждую клнопочку выдаст подробнейшее описание. Замечательно. Вот только связной картины, с какой кнопочки начинать, он всё же не даёт.
Один хрен, если это что-то сложенй helo world со всем этим придётся разбираться. И всевозможные ограничения IDE попросту могут заставтиь её выкинуть.
Так и сейчас. С примерами может действительно плохо. Впрочем -- они легко ищутся на гугле. Пошаговые описания -- это что, для идиотов?
Тут не можно сделать, а *придётся* делать.
"Системы с IDE " -- это собственно само IDE. IDE -- это не редактор с кнопками, как тут некоторые думают, а development environment, составленная из различных средств. GCC же ни разу не IDE -- это исключительно компилятор, обычно входящий в состав т.н. IDE. К GCC обычно же ещё прилагается binutils, gdb... Если всё это собрать вместе, а сверху прикрутить редактор с кнопками -- получится что-то похожее на IDE.
Нулевого порога вхождения - не бывает. Воспринимай как аксиому.
Я считаю её хорошей. Доступной для понимания. Для меня. Бывает что и с примерами и с чем угоодно ещё, а уму не постижимо ниикак.
Часть опций линкера и objtohex. У cpp (препроцессора) тоже вроде были "недокументированные опции".
Несложно показать, что такой подход быстренько заводит в тупик. Потому как сильно ограничевает само исло доступных тебе инстументов.
Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Jurgis Armanavichius on Wed, 26 Jul 2006 21:27:46 +0000 (UTC):
KF> Автор не иначе или как читать не умеет, или нагло лгёт.
Больше похоже, что это ты нагло врешь... Где описание gcc для avr?
KF> Афтар не сделает может быть. Другие -- делают.
Делают. Но с нормальным коммерческими системами это на порядок проще.
KF>>>> И где надо вникать в такие подробности работы компилятора, о KF>>>> каких программист под ПЦ может запросто и не догаддываться. DO>>> Иногда надо, иногда не надо. Почти всегда это можно сделать потом, DO>>> когда что-то уже начнет "дышать". >> А, типа, при использовании gcc вникать не нужно?! Hа порядки больше!
KF> А типа от компилятора это не зависит. При использовании gcc
Зависит.
KF> только, вникать нужно на порядок меньше, наоборот. Потоу как у него KF> независимо от платформы опции более или менее похожи. Как и многое
Бред полный. Какое мне дело до того какие платформы еще он поддерживает, если нужна одна конкретная? А что до embedded, то IAR или HiTech их куда больше поддерживает.
KF> другое. То ли дело с Hitech на keil переползать...
Не переползай.
KF> Если это проблема для тебя -- из этого ещё ничего не cледует.
Следует, что это проблема. Которой при использовании IDE нет вообще (если не хочешь сам себе ее создать).
KF> Makefile -- это какой никакой, а формальный способ записи правил KF> сборки.
Скорее никакой. На редкость уродский язык.
KF> Галочки в IDE таковым не всегда являются.
Ничуть не в меньшей степени, чем закорлючки вроде $<
KF> Особенно когда "нармальный коммерчческий компилятор" внутри KF> содержит тот же gcc...
Да хоть лысого черта пусть содержит. Лишь бы снаружи был удобен.
KF> Компилятор -- это программа path\to\bin\cc.exxe. А не то, что тут KF> некоторые считают.
Компилятор - это только часть системы разработки.
KF>>>> редактор или что-то ещё. GNU предлагает редактор отдельно... как KF>>>> и множество других утилит.
DO>>> И во всем этом надо разбираться, вместо того, чтобы заниматься DO>>> своей основной задачей...
KF> Разобраться с особенностями редакторов в десятке IDE -- я точно не KF> в состоянии. С одним как-нибуь разберусь. Хотя нет, я вот не знаю
Это твои проблемы. Многим никакие десятки не нужны. Один, ну два одновременно. Надо будет что-то другое новое - оно осваивается быстро, потому как (слава Гейтсу) похоже.
KF> Расчитывать ты можешь на что угодно. А получить только то, за что KF> заплатил.
Именно. В случае gcc - ноль.
KF> Это твои, как пользователя, личные трудности. Инфомрация есть и KF> она любому разумному человеку вобщем-то доступна.
Информации нет. Я специально развернул winavr и посмотрел что там есть. Все, как я и говорил по опыту нескольколетней давности. Разве что более-менее человеческий инсталятор сделали вместо .tgz.
KF> Если нет -- вам вообще компутер не нужен. А то вдруг, вы читать не KF> умеете вовсе?
KF>>>> За примерами тоже далеко ходить не надо, не дальше гугля и мне KF>>>> повезёт.
DO>>> Hу да, на заборе тоже много чего написано. Я предпочитаю получить DO>>> все в одной упаковке.
KF> Это сильно лучше, чем когда он их вообще не выдаёт.
Он их по нажатию F1 должен выдавать. А там нажимать негде. Не в каталоге же man с каим-то мусором.
Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 26 Jul
2006 21:42:27 +0000 (UTC):
KF>>> Т.е. вместо чтоб почитать мануал и подумать человек тратит время KF>>> на бессмысленное применение метода тыка к кнопочкам. Иногда это >> Это не так. В смысле не бессмысленное. Во-первых, во всех подобных
KF> Можно ли методом тыка изучить, например, язык программирования C?
Можно даже язык С, не говоря уж о компиляторе и прочем инструментарии. Особенно если он нужен не весь.
KF> Ага. Т.е. он на каждую клнопочку выдаст подробнейшее описание. KF> Замечательно. Вот только связной картины, с какой кнопочки начинать, KF> он всё же не даёт.
Для этого туториал есть.
KF>>> приводит к резуьтату (сомнительному...) Иногда нет. Чтение мануала KF>>> даёт результат за некое конечное время.
KF> Один хрен, если это что-то сложенй helo world со всем этим
А если не сложенй?
KF> придётся разбираться. И всевозможные ограничения IDE попросту могут
Или нет. Я обычно разбираюсь (по старой привычке), другие коллеги пользуются IDE и не морочат себе голову. Я тоже начинаю с этого.
KF> заставтиь её выкинуть.
Или да или нет. Ужасы ide сильно преувеличены.
KF> Так и сейчас.
Кто б сомневался...
KF> С примерами может действительно плохо. Впрочем -- они легко ищутся на KF> гугле.
Бог в помощь. Я предпочитаю структурированные на диске и в хэлпе.
KF> Пошаговые описания -- это что, для идиотов?
Нет. Это для специалистов в других областях, вынужденных заниматься и программированием тоже.
KF>>> И где надо вникать в такие подробности работы компилятора, о KF>>> каких программист под ПЦ может запросто и не догаддываться.
KF> Тут не можно сделать, а *придётся* делать.
Не факт совершенно. Особенно если с gcc не связываться.
KF>>> Потому что там чётко отделены мухи от котлет. Это компилятор, а KF>>> не
KF> "Системы с IDE " -- это собственно само IDE. IDE -- это не
Нет. Там и все ее составляющие доступны.
KF> редактор с кнопками, как тут некоторые думают, а development KF> environment, составленная из различных средств. GCC же ни разу не KF> IDE -- это исключительно компилятор, обычно входящий в состав т.н. IDE. KF> К GCC обычно же ещё прилагается binutils, gdb... Если всё это KF> собрать вместе, а сверху прикрутить редактор с кнопками -- получится KF> что-то похожее на IDE.
Кто все это будет делать и за чей счет?
KF>>> редактор или что-то ещё. GNU предлагает редактор отдельно... как и KF>>> множество других утилит.
KF> Нулевого порога вхождения - не бывает. Воспринимай как аксиому.
Нулевого не бывает. Но он бывает выше и ниже. Для IDE (в частности IAR) он гораздо ниже gcc. Точно также как написать что-то работающее под винду при помощи CBuilder'а на три порядка проще, чем с помощью gcc.
KF>>> А про документацию -- это не так. GNU имеет *хорошую* KF>>> пользовательскую документацию.
KF> Я считаю её хорошей. Доступной для понимания. Для меня.
А я - плохой. Слишком трудоемкой.
KF> Бывает что и с примерами и с чем угоодно ещё, а уму не постижимо KF> ниикак.
Бывает. Надо смотреть на хорошее, а не на плохое.
KF>>> Часто значительно более хорошую, чем даётся с коммерческими KF>>> компиляторами. Понятную (я не спорю, hitech и keil, например, дают KF>>> тоже неплохую документацию, но там часто, почему-то часть опций KF>>> компилятора то ли скрывается, то ли забыта...)
KF> Часть опций линкера и objtohex. У cpp (препроцессора) тоже вроде KF> были "недокументированные опции".
А по-конкретней нельзя? Кстати, никогда не приходилось пользоваться этой утилитой... Вообще хватает picc для компиляции и линковки.
KF>>> Другое дело, что GCC -- это одно, а "бакенд" AVR к нему -- совсем KF>>> другое. И результат соответствующий.
KF> Несложно показать, что такой подход быстренько заводит в тупик.
Покажи.
KF> Потому как сильно ограничевает само исло доступных тебе инстументов.
Не сильно, это gcc сильно ограничен и ни для чего что я применю его нет.
Thu Jul 27 2006 01:27, Kirill Frolov wrote to Jurgis Armanavichius:
Hеа. К примеру, точный список ключей компилятора я смог получить только с помощью команды "h8300-hms-gcc.exe --help > gcc.help". Потом в этом очень кратком "хелпе" пришлось догадываться, как именно работает тот или иной ключ в данной конкретной реализации компилятора.
:-) "Афтар" как раз делает и довольно давно. Hо именно после многочисленных тыков. Hе иначе.
Типа, возразить нечего? Я так и подумал :-)
Докажи.
Бред. И, в отличие от тебя, могу обосновать. При использовании gcc нужно вникать в гораздо бОльшее число вещей, чем при использовании компилятора в составе IDE. Я имею богатый опыт применения того и другого, поэтому так говорю.
KF> Потоу как у него независимо от платформы опции более или менее похожи. KF> Как и многое другое. То ли дело с Hitech на keil переползать...
Очередной бред. Опции для микроконтроллера Hitachi и для AVR разняться настолько, что нужно долго и нудно разбираться.
Ты хочешь сказать, что галочки в IDE, вроде "use two DPTR", сложнее для понимания, чем маловразумительные синтаксические конструкции Makefile-а?! Я-ж говорю: мазохист-пингвинятник! :-))) (Для справки: это я беззлобно пошутил. Hе обижайся, пожалуйста! :-)
Ой ли, что там "чётко отделены мухи от котлет". Там за сонмом мух котлету бы увидать... ;-)
Ты такой знаешь? Мне как-то пока не попадался... Я всегда смотрю, какой код порождает компилятор, и вижу много мест, где можно было бы существенно улучшить машинный код (кстати, это почти единственное место, где ЯВУ пока немножко проигрывают Ассемблеру). А уж про арифметику с плавающей точкой на замену стандартной gcc-шной fplib, которую я модифицировал и существенно ускорил, я уже писал. (Забыл только уточнить, что она применяется мною в программе для хитачевского микроконтроллера серии H8/3048.)
Кстати, ты пробовал породить смешанный текст Си/Ассемблер для WinAVR? Я порождаю (как уже говорил). В получившемся листинге приведена такая каша, что разбираться просто противно (хотя и возможно). Иногда я даже с помощью avr-objdump порождаю дизассемблированный листинг, и то легче разобраться...
KF> Компилятор -- это программа path\to\bin\cc.exxe.
Мне такое расширение незнакомо.
"Афтар не в состоянии может быть. Другие -- в состоянии." (C) перефр. твой. ;-)
KF> С одним как-нибуь разберусь.
Во, во. Вот я, например, как познакомился много лет назад с Turbo C, так почти все IDE с тех пор - как родные. А их редактор - незабвенный WordStar.
KF> Хотя нет, я вот не знаю как сделать, чтоб я мышкой в строкку тыкал, KF> а оно cvs annotate смотрело и потом log для этой строчки вытягивало. KF> Расскажи, какая IDE так умеет?
А мне не нужно в ластах, в гамаке и с аквалангом... ;-)
Совершенно справедливо. Если я купил среду разработки фирмы Tasking, то получаю помощь по этой среде разработки. Ведь не по Fox Pro же мне от них помощь получать! ;-) (Про Tasking я потому, что имел с ними плодотворный контакт. Причем, через несколько лет после покупки их IDE. Все сроки техподдержки давно прошли, тем не менее, они мне прислали исправленную версию. Бесплатно.)
Hе надо ля-ля. Ты впаривай свои фантазии тем, кто еще не работал с gcc :-) Мне - бесполезно, я много лет работаю. Чувствую, что ты уже утратил нить разговора, поэтому помогу тебе: я не говорю, что gcc плох, я говорю, что в области embedded разобраться в применении среды разработки, на нем основанной, гораздо сложнее, чем в нормальной IDE.
Конечно, о Великий! Думаю, что большинство присутствующих давно и прочно усвоило, что ты - Солнцеподобный Гуру! Однако... Я вспоминаю мой недавний спор в RU.LINUX.CHAINIK на предмет применения коммандеров (речь шла о mc). Опытные линуксоиды, которые помогают в этой эхе чайникам, аргументированно и твердо настаивали, что использование FAR-а (ну или его жалкого подобия mc) - некошерно. Они были не правы?!
А для нелюбителя в ластах, в гамаке и с аквалангом намного проще нажать F1...
KF> >> KF> Т.е. вместо чтоб почитать мануал и подумать человек тратит время >> KF> на бессмысленное применение метода тыка к кнопочкам. Иногда это >> Это не так. В смысле не бессмысленное. Во-первых, во всех подобных
KF> Можно ли методом тыка изучить, например, язык программирования C?
Turbo C 2.0 в качестве "среды тыка" - пойдет?
KF> Ага. Т.е. он на каждую клнопочку выдаст подробнейшее описание. KF> Замечательно. Вот только связной картины, с какой кнопочки начинать, он KF> всё же не даёт.
Для умеющих думать хелпа вполне достаточно
KF> Один хрен, если это что-то сложенй helo world со всем этим придётся KF> разбираться. И всевозможные ограничения IDE попросту могут заставтиь её KF> выкинуть.
Скольким людям вышепомянутый борландовский продукт помог освоить Си гораздо полнее и быстрее, чем маны, унихи и цэцэ.ехе, все вместе взятые, на разных могучих мейнфреймах?
KF> Так и сейчас. С примерами может действительно плохо. Впрочем -- они KF> легко ищутся на гугле. Пошаговые описания -- это что, для идиотов?
Borland Turbo C существовал тогда, когда аффтары гуглей еще трепыхались сперматозоидами известно где.
Не пойдёт. Пробовал, не помогло. Очень помогает керниган с пайком и что-то похожее на GCC. Чтоб без хитрых кнопок скрывающих всю суть. Хорошо, не GCC, а hitech-C. ТАм хоть, в старых IDE, видно с какими ключиками он что запуизапускает. А сейчас такой ужас на жабе наваяли...
В хелпе многие вещи не описываются а своим умом дойти -- далеко не для каждого.
НЕ знаю. Мне не помог, а ровно наоборот. Мне Hitech помог очень сильно.
Полный список из самого gcc приведённой командой никак не выдавить. Для этого нужна другая команда.
Сферический конь в вакууме. Сказки не надо рассказывать.
Бред излечивают другие специалисты. Что такое именно GCC написано на
formatting link
Имел бы опыт знал бы, что банальный cc file.c получает, для целевой платформы, готовый бинарник в наиболее приемлемом виде. Без всяких знаний. А опция задаваемая в командной строке вобщем-то мало чем отличается от галочки в IDE. О назначении и имени опции или галочки один хрен знать нужно. Про Makefile я даже не заикаюсь -- можно в "батнкик' прописать.
x51. Поддерживают тот и другой.
Именно так. Потому как человек оперирует в своих рассуждениях
*понятиями*, которые легко могут быть выражены как на естесственном, так и на искусственном (компьютерном) языке. Выразить их картинками (пиктограммами) или жестами "мыши" достаточно сложно.
А главное даже не это, а то что Makefile может быть банально
*прочитан* человеком. С галочками это сложней. Их просто прочитать нельзя. Надо брать лист бумаги и выписывать какие из них включены (по ходу дела получая, фактически, список ключей компилятору).
Вспомни турбо-паскаль. И почему так любили опции компилятору записывать в комментариях, когда можно было их просто включать в менюшке.
И про маловразумительные конструкции не надо. Опять же простой Makefile на вид мало чем отличается от "батника" (или это тоже, "маловразумительные конструкции")? Makefile -- это не более чем /программа/, которую, конечно, можно записать так, что никто потом не разберётся (типичный writeonly -- многие программы на perl...), а можно и комментарии написать и код более-менее вразумительный.
CR32 в своё время использовал.
GCC порождает отвратительный листинг ассемблера -- это факт. Тут есть чему поучиться у того же hitech.
*cc.exe
Может быть и в состоянии, но он мне cvs annotate показывать будет, а когда мышой тыкаю -- cvs log?
WordStar -- это где Ctrl-K Ctrl-X... А тут CUI.
Ну так ты скажи, какая IDE это без ластов и акваланга позволяет? Сказать нечего?
Ключевое слово -- если. И ещё -- украл. Вместо купил. А так всё абсолютно верно, я не сомневаюсь, support у них замечательный.
Нити разговора ты сам не видишь. И пытаешься сравнивать сапоги с пряниками. Если сравнивать GCC с KEIL, то не с uVision конечно, а с программой CC.exe и каталога bin.
Конечно некошерно. Опытные линуксоиды вводят программу сразу в машинных кодах: xxd -r > a.out && ./a.out.
КАк в uVision увидеть (хорошо ещё, что uVision...) увидеть cvs log для данной строчки?
KF> >> KF> Можно ли методом тыка изучить, например, язык программирования C? >> Turbo C 2.0 в качестве "среды тыка" - пойдет?
KF> Hе пойдёт. Пробовал, не помогло. Очень помогает керниган с пайком и KF> что-то похожее на GCC. Чтоб без хитрых кнопок скрывающих всю суть.
Для начального изучения Си достаточно Болски, маленького и синенького
KF> Хорошо, не GCC, а hitech-C. ТАм хоть, в старых IDE, видно с какими KF> ключиками он что запуизапускает. А сейчас такой ужас на жабе наваяли...
В поставке турбоси точно был компилятор для работы из командной строки. Ключики тоже можно было легко посмотреть, ассемблерный листинг - тоже.
\**\
KF> Афтар жестоко бредит. Была altavista, yahoo.
Во времена турбоси в этой стране даже "доступ по UUPC" был не у всех. Ты хотя бы в курсе, что дистрибутив турбоси шел на пятидюймовых флопах, кажется по 360 килобайт?
AS = a51 define ASFLAGS # set (large) debug errorprint endef
Но это ещё что. Для hitech я как-то уже приводил...
Что зависит? Возьму я KEil тот же или gcc, допустим, появился для x51. Опций сразу у Keil что ли сильно поубавится? Вряд ли.
Это твои личные психологические трудности.
Факт в том, что любой backend к GCC не так сильно отличается от других backend'ов, как могут различаться два компилятора разных фирм. В равной степени, как и все компиляторы hitech software более-менее похожи.
Там есть другая проблема -- правильно выставить все кнопочки. Впрочем даже это не проблема. Непонятно что делать при перетаскивании проекта на другой компиутер или в другой каталог -- там все пути прописанные абсолютные и приходится файл проекта править руками. Наворочено внутри покруче чем в любом Makefile.
Ну возьми Ant... Никто ж не заставляет именно make. Просто почему-то традиционно используется именно он. Видать, не такой уж и негодный инструмент.
soource-file-name = $<
file.obj: file.c cc $(source-file-name)
Извращенцы могут ещё через cpp makefile пропускать... Но меня и так устраивает.
Цитирую с сайта atmel.com:
AVR Studio 4.12 (build 460) (45 MB, updated 11/05) AVR Studio 4.12 includes new device support and numerous overall enhancements; new breakpoint system, integrated AVR GCC development and improved docking system! See release notes for more details.
Ну и слава билу гейцу. Что гцц -- это только компилятор -- понимаешь?
Я использую текстовый редактор, однозначно, чаще любых других программ. Так зачем вместо того, чтобы выбрать один удобный должен мучаться в десятке неудобных?
В случае GCC ты получишь что публично доступно. В случае ворованного коммерческого компилятора -- действотельно 0. Покупать тут не в моде.
Когда я несколько лет назад развернул то же самое только по линухом на недостаток информации жаловаться не приходилось. Вот gdb не прикручивался никак к монитору. Тут можно скаать глобальный недостаток. Но это уже не к GCC.
А для иконки интернет експлорера в качестве горячей кнопки F1 точно никак не прописат? И стартовой страницей гугль.
Hello, Kirill Frolov! You wrote in conference fido7.ru.embedded to Jurgis Armanavichius on Thu, 27 Jul 2006 11:42:20 +0000 (UTC):
KF>>> Автор не иначе или как читать не умеет, или нагло лгёт. >> Hеа. К примеру, точный список ключей компилятора я смог получить >> только с помощью команды "h8300-hms-gcc.exe --help > gcc.help". Потом >> в этом очень кратком "хелпе" пришлось догадываться, как именно >> работает тот или иной ключ в данной конкретной реализации >> компилятора.
KF> Список опций приводится в файле gcc.info.
KF> Полный список из самого gcc приведённой командой никак не KF> выдавить. Для этого нужна другая команда.
Тоже радости мало.
KF> Имел бы опыт знал бы, что банальный cc file.c получает, для KF> целевой платформы, готовый бинарник в наиболее приемлемом виде. Без KF> всяких знаний. А опция задаваемая в командной строке вобщем-то мало KF> чем отличается от галочки в IDE. О назначении и имени опции или
Много чем. Галочка прямо возле себя подписана, если стоя на ней вызвать хэлп, можно прочитать подробности. Кроме того, галочки все видны, не надо вычитывать в киких-то файлах их список - он перед глазами. Кроме того, зависимые галочки становятся неактивными, если не выбрана главная. Не надо гадать что же будет при задании исключающих или невключенных опций (скажем одновременно оптимизации по скорости и размеру или включении какого-то типа оптимизации с отключенной оптимизацией вообще. Галочки тебе просто не дадут задать неправильную комбинацию.
KF> галочки один хрен знать нужно. Про Makefile я даже не заикаюсь -- KF> можно в "батнкик' прописать.
А в IDE - просто включить файл в проект... И не надо ничего никуда прописывать.
KF> Именно так. Потому как человек оперирует в своих рассуждениях KF> *понятиями*, которые легко могут быть выражены как на естесственном, KF> так и на искусственном (компьютерном) языке. Выразить их картинками KF> (пиктограммами) или жестами "мыши" достаточно сложно.
Их можно выразить осмысленными подписями на человеческом языке, а не птичьем языке мейкфайлов, линкерных и компиляторных скриптов и команд командной строки.
KF> А главное даже не это, а то что Makefile может быть банально KF> *прочитан* человеком.
Для этого человек должен знать язык мейкфайлов, причем не вообще, а конкретного make'а.
KF> С галочками это сложней. Их просто прочитать нельзя. Надо брать лист
Их именно что можно просто взять и прочитать.
KF> бумаги и выписывать какие из них включены (по ходу дела получая, KF> фактически, список ключей компилятору).
Зачем выписывать-то? Нужно на бумаге, PrintScreen нажми.
KF> Вспомни турбо-паскаль. И почему так любили опции компилятору KF> записывать в комментариях, когда можно было их просто включать в KF> менюшке.
Потому что это позволяет ограничиться передачей/хранением одних исходников, управляющих и компиляцией и сборкой, а не всего проекта вместе с .dsk файлом.
KF> И про маловразумительные конструкции не надо. Опять же простой KF> Makefile на вид мало чем отличается от "батника" (или это тоже,
Увы, он много чем отличается. Там разделены правила, и то, к чему они применяются.
KF> "маловразумительные конструкции")? Makefile -- это не более чем KF> /программа/, которую, конечно, можно записать так, что никто потом KF> не разберётся (типичный writeonly -- многие программы на perl...), а KF> можно и комментарии написать и код более-менее вразумительный.
Как минимум, требующий знания еще одного языка.
KF> Нити разговора ты сам не видишь. И пытаешься сравнивать сапоги с KF> пряниками. Если сравнивать GCC с KEIL, то не с uVision конечно, а с KF> программой CC.exe и каталога bin.
Нет. Subj посмотри. Сравниваются среды разработки. gcc (и winavr в частности) - вообще к оным не относится.
KF> КАк в uVision увидеть (хорошо ещё, что uVision...) увидеть cvs log KF> для данной строчки?
KF> Но это ещё что. Для hitech я как-то уже приводил...
Приводил что?
KF>>>>>> И где надо вникать в такие подробности работы компилятора, о KF>>>>>> каких программист под ПЦ может запросто и не догаддываться. DO>>>>> Иногда надо, иногда не надо. Почти всегда это можно сделать DO>>>>> потом, когда что-то уже начнет "дышать". >>>> А, типа, при использовании gcc вникать не нужно?! Hа порядки >>>> больше! KF>>> А типа от компилятора это не зависит. При использовании gcc >> Зависит.
KF> Что зависит? Возьму я KEil тот же или gcc, допустим, появился для
Зависит удобство.
KF> x51. Опций сразу у Keil что ли сильно поубавится? Вряд ли.
KF>>> только, вникать нужно на порядок меньше, наоборот. Потоу как у KF>>> него независимо от платформы опции более или менее похожи. Как и KF>>> многое
KF> Это твои личные психологические трудности.
Мои трудности в том, что gcc не поддерживает нужные мне платформы? Скорее твои, мне gcc не нужен.
KF> Факт в том, что любой backend к GCC не так сильно отличается от KF> других backend'ов, как могут различаться два компилятора разных KF> фирм. В равной степени, как и все компиляторы hitech software KF> более-менее похожи.
И что? И все компиляторы IAR похожи. Только у него список поддерживаемых embedded архитектур в 10-20 раз шире, чем у gcc.
KF>>> Если это проблема для тебя -- из этого ещё ничего не cледует.
KF> Там есть другая проблема -- правильно выставить все кнопочки. KF> Впрочем даже это не проблема. Непонятно что делать при KF> перетаскивании проекта на другой компиутер или в другой каталог -- KF> там все пути прописанные абсолютные и приходится файл проекта KF> править руками.
Далеко не всегда. А абсолютные пути могут и в мейкфайле быть прописаны.
KF>>> Makefile -- это какой никакой, а формальный способ записи правил KF>>> сборки.
KF> Ну возьми Ant... Никто ж не заставляет именно make. Просто
Вот мне больше делать нечего. Когда мне нужен мейк, я беру борландовский, все же более привычный.
KF> почему-то традиционно используется именно он. Видать, не такой уж и KF> негодный инструмент.
Годный. Неудобный просто.
KF>>> Галочки в IDE таковым не всегда являются. >> Ничуть не в меньшей степени, чем закорлючки вроде $<
KF> soource-file-name = $<
KF> file.obj: file.c KF> cc $(source-file-name)
Вот-вот. Птичий язык.
KF> Извращенцы могут ещё через cpp makefile пропускать... Но меня и KF> так устраивает.
KF>>> Особенно когда "нармальный коммерчческий компилятор" внутри KF>>> содержит тот же gcc...
KF> Цитирую с сайта atmel.com:
Зачем? Пускай нальют в один флакон со всем остальным, сделают по-человечески " компилятоp С и сpеда pазpаботки для AVR", напишут нормальную документацию, тогда и можно будет этим пользоваться, особенно если оно умеет нормальный код генерировать.
KF>>> Компилятор -- это программа path\to\bin\cc.exxe. А не то, что KF>>> тут некоторые считают. >> Компилятор - это только часть системы разработки.
KF> Ну и слава билу гейцу. Что гцц -- это только компилятор -- KF> понимаешь?
Понимаю. Обрезок недоделанный.
KF>>> Разобраться с особенностями редакторов в десятке IDE -- я точно KF>>> не в состоянии. С одним как-нибуь разберусь. Хотя нет, я вот не KF>>> знаю
KF> Я использую текстовый редактор, однозначно, чаще любых других KF> программ. Так зачем вместо того, чтобы выбрать один удобный должен KF> мучаться в десятке неудобных?
Не мучайся, никто не заставляет.
KF>>> Расчитывать ты можешь на что угодно. А получить только то, за KF>>> что заплатил.
KF> В случае GCC ты получишь что публично доступно. В случае KF> ворованного коммерческого компилятора -- действотельно 0. Покупать KF> тут не в моде.
Это уж точно твои психологические проблемы. У меня ворованные дома, на работе - купленные.
KF> Когда я несколько лет назад развернул то же самое только по KF> линухом на недостаток информации жаловаться не приходилось.
Видимо ты привык к корявым линуховым средствам кое-как документированным, сделанным хакерами для хакеров, а не для людей, в массе своей далеких от всего этого, нуждающихся в максимально простом и удобном, интуитивно понятном инструменте.
KF> Вот gdb не прикручивался никак к монитору. Тут можно скаать глобальный KF> недостаток. KF> Но это уже не к GCC.
KF> А для иконки интернет експлорера в качестве горячей кнопки F1 KF> точно никак не прописат? И стартовой страницей гугль.
Никак. Не желаю я ничего никуда прописывать, особенно когда я вижу, что этого можно не делать и все работает. И стартовые страницы у меня другие.
Thu Jul 27 2006 15:42, Kirill Frolov wrote to Jurgis Armanavichius:
Точно! Hашел этот файл! Большое тебе спасибо за наводку :-) Жалко, что я не линуксоид - узнал бы об этом файле много раньше. А то я с великим трудом (правда, не долго) пытался man-ы ковырять. Брррр! ;-)
Про ноль - это ты :-)
Да ладно, не злись :-) А на
formatting link
я частенько захаживаю, пытаюсь дождаться новых портов gcc...
А вот и нет! Я понял твою позицию. Ты постоянно опираешься на практику работы под Линуксом (что, IMHO, само по себе отнюдь не тривиально для обычного embedded-инженера, который Линукса не знает) и смотришь с этой колокольни. А я смотрю со своей колокольни: разработать программу для своего embedded-девайса. С помощью команды "cc file.c" я получу фигу с маслом, а не файл прошивки микроконтроллера :-)
Hу ты загнул! Вот запускаю IDE, выбираю новый проект, назначаю кристалл фирмы Cypress. Многие опции уже изначально выставлены под этот кристалл. Идем в Target. Смотрим: птичка Use On-chip ROM (0x0-0x3FFF). Используем внутреннее ПЗУ? Да, птичку ставим. Птичка Use On-chip XRAM (0xE000-0xE1FF). Используем внутреннее ОЗУ? Да, птичку ставим. Птичка Use multiple DPTR registers. Конечно да, птичку ставим. И так далее.
И это сложнее, чем ковыряться в Makefile-е?! :-)))
KF> А главное даже не это, а то что Makefile может быть банально KF> *прочитан* человеком. С галочками это сложней. Их просто прочитать KF> нельзя. Hадо брать лист бумаги и выписывать какие из них включены KF> (по ходу дела получая, фактически, список ключей компилятору).
А я на бумажку не выписываю за полной ненадобностью :-) Я просто изучаю применяемую микросхему и соответствующим образом выставляю "птички". Этого процесса никак не избежать (изучения микросхемы), а изучать Makefile мне и вовсе не нужно.
KF> Вспомни турбо-паскаль. И почему так любили опции компилятору KF> записывать в комментариях, когда можно было их просто включать KF> в менюшке.
Hе знаю почему, но как-то никогда не любил турбо-паскаль... Hе могу объяснить, почему...
Даже не слышал про такого... Он для каких микроконтроллеров?
Причем, это так грустно... Радует только то, что ковыряться в критических местах программы нужно очень редко. Раз поковырялся и все.
Что-то ты очень заумное требуешь... Hе знаю, кто такой cvs annotate... Слава Аллаху, мне это нафиг не сдалось :-)
Hичего страшного! И в ГУЯх Ctrl-Ins, Shift-Del, Shift-Ins исправно работают :-) (Я как-то больше к этим комбинациям привык.)
Есть чего :-) Повторю, мне эти cvs annotate нафиг не сдались. Если тебе это почему-то нужно - сочувствую... Впрочем, для правоверного линуксоида борьба с трудностями - вторая натура! Я прав? ;-) (Это я пошутил! :-)
Так ты же сам пишешь: "А получить только то, за что заплатил." При чем тут воровство? Ты запутался? ;-)
Это как раз ты куда-то съехал. Мы ведь о средах разработки говорим, или о чем? Иначе что CC.exe, что любой другой компилятор - один хрен, ничего результирующего не породишь. Hужен еще линкер, библиотеки, опять же, редактор текста программы, хорошо бы еще какой-никакой отладчик... В общем, нормальная IDE нужна! ;-)
О Боже! Все-таки как хорошо, что я не опытный линуксоид! А то так и заразиться недолго... Как мне потом от этой мазохистской линуксилии лечиться?! ;-) (Hе серчай, это я снова пошутил! :-)
20 Jul 06 23:58, Nicolas Minakov писал Yuri Nikiforov:
NM> Чтоб не говорили, что я NM> чтото там не то пишу - взял пример avr306 (UART),
А я все-таки скажу надцатый раз: пример от Атмел - худшее, что можно взять в качестве примера. Пусть они сначала научатся писать программы без грубых ошибок...
NM> Мне кажется что компилятор, который без предупреждений компилит NM> неработоспособный код для простейшнго примера - вещь не для NM> начинающих... Hадеюсь, что потом разберусь. Nicolas
Вот и не надо давать компилятору в качестве примера неработоспособный код. :)
Всего наилучшего, [Team PCAD 2000] Алексей М. ... Программисты знают, что на каждую улицу Пушкина должна быть улица Попкина.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.