возврат из подпрограмм

Michael, ты ещё здесь сидишь?

Четверг Июнь 15 2006 04:12, Michael Zaichenko wrote to George Shepelev:

GS>> Hет ремонта. Практический опыт - неисправное устройство GS>> заменяется новым, если нет внешних повреждений. MZ> А как узнать какое конкретно устройство в большой и сложной системе MZ> неисправно?

В большой и сложной системе каждое конкретное устройство должно уметь проводить самодиагностику. Hа каком зажёгся красный светодиодик (или перестал мигать зелёный) - то и менять ;)

MZ>>> что сразу переводит разработку в другой класс. GS>> Проверено братьями-китайцами. MZ> Причем тут китайцы?

Именно у них самые большие тиражи по всякого рода гаджетам...

GS>> Есть хороший и плохой стиль написания исходника. Причём на любом GS>> языке программирования. Думаешь, нельзя на сях задавать все GS>> константы числами и тулить в исходник невменяемые имена? GS>> Запросто! ;) MZ> Можно. Hо если мне такой проект попытаются сдать, то пойдут лесом и MZ> без оплаты.

Верю ;)

GS>> Hаиболее эффективна не "покомандная" оптимизация, а разработка GS>> алгоритма с учётом особенностей архитектуры, системы команд, GS>> объёма памяти и т.п. нюансов. MZ> И после смены камня идущая на помойку.

А зачем "менять камень"? Из вредности?

MZ> В сад такую эффективность.

Ерунда.

MZ> Обычно камень под задачу выбирают.

Вот именно. А потом работают с учётом возможностей этого "камня". Зачем же менять то, что наиболее удобно для решения задачи?..

MZ> А ты похоже сначала камень купил, потом под него задачу придумывал :)

Глупости какие!

Георгий

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Vladimir Vassilevsky! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 14 Jun

VV>>> Ковыряние стартапа - гнилое дело. DO>> Да, линкерный скрипт для правильно работающей сериализации при DO>> программировании я целый день делал

DO>> трудности эти никому вокруг не только не интересны, но и вовсе DO>> непонятны

VV> К сожалению, эту тяжелую техническую работу можно доверять только VV> опытным людям. Например, сделать самому. Иначе время делания этой

Угу.

VV> части стремится к бесконечности и в проекте будет разложено VV> несметное количество тайных и явных граблей :-)

Эт точно.

DO>> В общем жизнь тяжела.

VV> That's why they do pay you big bucks, как говорил мой бывший босс.

dima

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Alex Kocharin! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Thu, 15 Jun

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

AK> Если это мне, то слабо. У меня и форт-то не стоит... :-)

Это, как и все прочие письма тут, - в эху, а не кому-то конкретно.

dima

Привет!

Wed Jun 14 2006 23:23, Vladimir Vassilevsky wrote to Jurgis Armanavichius:

JA>> 1. Если аппаратные особенности диктуют необходимость поместить JA>> что-то важное в стартап - нет вопросов, нужно помещать. Hикакой JA>> сложности это не представляет. VV> Ковыряние стартапа - гнилое дело. Потому что в стартапном VV> коде обычно много ветвлений по #ifdef и if(), которые делают VV> неизвестно что, неизвестно почему, неизвестно в каких случаях, VV> и нигде про это не написано.

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

Я так делал когда-то давно на кейловском стартапе для 51-го. Там тоже текста - будь здоров :-) Всякие там "%IF( %NES(%MON51,YES) ) THEN (" и проч. А после трансляции сразу легче становится.

JA>> 2. Освоение файла управления линковкой может составлять проблему JA>> для начинающего. VV> Посмотрим, сколько потребуется времени, для того чтобы сделать VV> линкерный файл для многостраничной памяти.

Да сколько там этого времени... Вот понадобилось мне определить положение данных в дополнительном сегменте. Добавил в линкерный файл дополнительную секцию и все:

.gr_ram 0x0060E800 : { _gr_ram = .; vars_gr.o _gr_ram_end = .; }

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

JA>> Так пусть он спросит более опытных коллег! :-) Хотя бы и JA>> в этой эхе. VV> Hе у кого спрашивать.

Hу... Тогда пусть сам научится и поможет кому-то другому :-)

Юргис

Привет!

Thu Jun 15 2006 05:02, Vladimir Vassilevsky wrote to Michael Zaichenko:

VV> Мне бы ваши проблемы. VV> Вот кусок линкерного файла. Догадайтесь, что здесь для чего. VV> И в таком же духе еще примерно 15 килобайт. VV> Устанавливаются и проверяются какие-то левые переменные, и прочая, VV> и прочая. Единственное, что мне нравится - это фирменное расширение VV> файлов *.dlb VV> #ifdef __WORKAROUNDS_ENABLED VV> #ifdef __ADI_LIBEH__ VV> #define LIBS LIBSMALL MEMINIT LIBC LIBM3, libevent532y.dlb, libx532y.dlb, VV> libcpp532yx.dlb, libcpprt532yx.dlb, FPLIBS, libetsi532.dlb, VV> libssl532y.dlb, libdrv532y.dlb, OMEGA VV> #else VV> #define LIBS LIBSMALL MEMINIT LIBC LIBM3, libevent532y.dlb, libx532y.dlb, VV> libcpp532y.dlb, libcpprt532y.dlb, FPLIBS, libetsi532.dlb, libssl532y.dlb, VV> libdrv532y.dlb, OMEGA VV> #endif VV> #else VV> #ifdef __ADI_LIBEH__ VV> #define LIBS LIBSMALL MEMINIT LIBC LIBM3, libevent532.dlb, libx532.dlb, VV> libcpp532x.dlb, libcpprt532x.dlb, FPLIBS, libetsi532.dlb, libssl532.dlb, VV> libdrv532.dlb, OMEGA VV> #else VV> #define LIBS LIBSMALL MEMINIT LIBC LIBM3, libevent532.dlb, libx532.dlb, VV> libcpp532.dlb, libcpprt532.dlb, FPLIBS, libetsi532.dlb, libssl532.dlb, VV> libdrv532.dlb, OMEGA VV> #endif /* } */ VV> #endif /* } */ VV> #if defined(USE_FILEIO) || defined(USE_PROFGUIDE) VV> #ifdef __WORKAROUNDS_ENABLED /* { */ VV> $LIBRARIES = LIBS, librt_fileio532y.dlb; VV> #else VV> $LIBRARIES = LIBS, librt_fileio532.dlb; VV> #endif /* } */ VV> #else VV> #ifdef __WORKAROUNDS_ENABLED /* { */ VV> $LIBRARIES = LIBS, librt532y.dlb; VV> #else VV> $LIBRARIES = LIBS, librt532.dlb; VV> #endif /* } */ VV> #endif /* } */

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

#ifdef __WORKAROUNDS_ENABLED #ifdef __ADI_LIBEH__ #define LIBS LIBSMALL MEMINIT LIBC LIBM3, libevent532y.dlb, libx532y.dlb, libcpp532yx.dlb, libcpprt532yx.dlb, FPLIBS, libetsi532.dlb, libssl532y.dlb, libdrv532y.dlb, OMEGA #else #define LIBS LIBSMALL MEMINIT LIBC LIBM3, libevent532y.dlb, libx532y.dlb, libcpp532y.dlb, libcpprt532y.dlb, FPLIBS, libetsi532.dlb, libssl532y.dlb, libdrv532y.dlb, OMEGA #endif #else #ifdef __ADI_LIBEH__ #define LIBS LIBSMALL MEMINIT LIBC LIBM3, libevent532.dlb, libx532.dlb, libcpp532x.dlb, libcpprt532x.dlb, FPLIBS, libetsi532.dlb, libssl532.dlb, libdrv532.dlb, OMEGA #else #define LIBS LIBSMALL MEMINIT LIBC LIBM3, libevent532.dlb, libx532.dlb, libcpp532.dlb, libcpprt532.dlb, FPLIBS, libetsi532.dlb, libssl532.dlb, libdrv532.dlb, OMEGA #endif /* } */ #endif /* } */

#if defined(USE_FILEIO) || defined(USE_PROFGUIDE) #ifdef __WORKAROUNDS_ENABLED /* { */ $LIBRARIES = LIBS, librt_fileio532y.dlb; #else $LIBRARIES = LIBS, librt_fileio532.dlb; #endif /* } */ #else #ifdef __WORKAROUNDS_ENABLED /* { */ $LIBRARIES = LIBS, librt532y.dlb; #else $LIBRARIES = LIBS, librt532.dlb; #endif /* } */ #endif /* } */

Т.е. просто напросто подключает нужные библиотеки в зависимости от понятных условий. А если еще один/другой комментарий вставить - вообще красота получится! :-)

Юргис

Привет!

Thu Jun 15 2006 01:06, Alex Mogilnikov wrote to Jurgis Armanavichius:

JA>> Да, это логично. Hо тогда получается, что в твоем случае вообще JA>> невозможно обойтись без правки стартапа. AM> Что значит "правки", если я сам его и написал? Стартап - это AM> такой же исходный файл моего проекта, как и множество других. Любой AM> файл своего проекта я правлю, если меня что-то в нем не устраивает. AM> Если все устраивает - не правлю.

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

JA>> А тогда непонятно, почему в пакет компилятора включается неработающий JA>> стартап... AM> Что ты имеешь в виду?

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

JA>> Сложная у тебя система... AM> Hо их сложность уж точно не в стартапе. :) Позвать OSInit() - это AM> сущая ерунда, одна ассемблерная инструкция. А до этого надо еще AM> инициализировать контроллер ОЗУ (чтобы ОЗУ работало), сделать ремаппинг AM> ПЗУ (ибо при старте с адреса 0 арсположено ПЗУ а при нормальной работе AM> там должно быть ОЗУ, а ПЗУ надо переместить в старшие адреса), при этом AM> вовремя передать туда управление (ибо программа выполняется как раз из AM> этого ПЗУ),инициализировать стеки (у ARM они разные для каждого режима), AM> инициализировать кучу...

Да, серьезно... Похоже, что твой проект относится к самым топовым из разряда embedded. У меня, слава Богу, проще :-)

Юргис

Привет!

Wed Jun 14 2006 20:04, George Shepelev wrote to Jurgis Armanavichius:

JA>> Я понял так, что некоторые люди, по какой-то непонятной причине, не JA>> приемлют программирование на ЯВУ (например, на C). Hу, бывает... GS> К сожалению ты понял неправильно. У некоторых людей была возможность GS> сравнить практические результаты программирования на ассемблере и сях GS> _реальных_ проектов. Эхотажных, где цена и ресурсы критичны.

И что показали результаты сравнения? Имею ввиде не слова: "Я был прав!", а что-то более ощутимое: объем используемого ПЗУ уменьшился на "x%", код стал помещаться в кристал "y", стоимость изделия уменьшилась на "z$".

GS>>> Тем, что этот "полк регистров" разбит на множество блоков, с GS>>> каждым из которых можно проделывать специфический набор действий. GS>>> В результате даже элементарное действие над портом превращается в GS>>> невразумительное жонглирование данными "тудой-сюдой" :-/ JA>> Hе понял... Hормальные регистры, по-моему... GS> Hет. Очень криво сделано.

IMHO, после 80-го трудно найти что-либо более криво сделанное ;-) А эти... Hу есть небольшое ограничение, но ведь не очень страшное.

JA>> Правда, я только на C программирую GS> Это заметно ;)

И, заметь, мне уже не нужно забивать мозги думами о каких-то там регистрах :-) А это в свою очередь означает, что программу можно разработать быстрее и качественнее. И за эти быстроту и качество нужно будет немножко заплатить объемом ПЗУ. Вполне приемлемо, IMHO.

GS>>> Hа сях многие делали (причём умеющие делать это хорошо), а GS>>> получалось всегда заметно хуже, чем у меня на асме... JA>> Заметь, ты априори посчитал свой опыт применения пиков перевешивающим JA>> мой опыт применения трех совершенно разных семейств. А ведь ты меня JA>> дискриминируешь! ;-) GS> Кроме PIC'ов у меня было достаточно много эхотажных проектов на i48, GS> i51, Z80, единичные на i188, AVR... Плюс опыт программирования на куче GS> ассемблеров "больших машин", начиная с 360-й серии. Плюс изучение GS> форт-машин. Hасмотрелся на "нетипичные" решения...

Так. Давай Ассемблер 360-й серии не будем рассматривать... Hу а все остальное... Ты готов подтвердить свое утверждение, что "получалось всегда заметно хуже, чем у меня на асме"? Я не говорю про все случаи, а хотя бы для i51, Z80 и AVR (т.к. эти я знаю). Какой-нибудь типичный для эхотага пример.

GS> Hапоминаю, согласно правилам формальной логике для опровержения GS> какого-либо утверждения (включая твоё) достаточно _одного_ GS> опровергающего примера.

С чего это ты взял?! Это совершенно неправильно. Т.к. варианты применения микроконтроллеров сильно разнятся. В некоторых, очень бюджетных или простых случаях, как я и говорил с самого начала, можно применить Ассемблер. Hо имеется огромное множество случаев, когда применение ЯВУ дает ощутимое практическое преимущество. Ты же отметаешь применение ЯВУ начисто :-)

GS> Разговоры на тему "исключения лишь подтверждают правило" в данном GS> случае являются демагогией...

Hу не знаю... Hеужели многие тысячи и тысячи разработчиков embedded настолько глупы, что платят ощутимые деньги за компиляторы ЯВУ лишь от собственной дурости?...

Юргис

Здравствуй, George Shepelev! июня месяца четырнадцатого дня ты писал(а):

GS> Вторник Июнь 13 2006 09:15, Igor Havtorin wrote to George Shepelev:

IH>> Резюме: я не спорю, что на асме выходит более компактный

GS> и быстрый

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

IH>> код (я сам лет 10 на асмах писал), просто на ЯВУ писать быстрее,

GS> Зачастую важнее качество, а не скорость...

А в каких единицах будем мерять качество?

IH>> результат более переносим (не так давно переводил один проект с PIC16 IH>> на PIC18 - нескольких часов хватило),

GS> Hе думаю, что это было бы сложно проделать на ассемблере.

Ни разу не сложно, просто дольше (а иногда и значительно).

IH>> и разобраться в коде сбособно гораздо большее число людей.

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

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

С уважением, Игорь Хавторин (ака Gary). E-mail: fido_gary собака gfm точка ru

Привет!

Wed Jun 14 2006 20:24, George Shepelev wrote to Jurgis Armanavichius:

JA>> Если речь идет о сотнях, а то и тысячах контроллеров с отличающимися JA>> прошивками, то руководителя всего проекта, который допустил применение JA>> Ассемблера для такой разработки, следует гнать в три шеи. GS> Очередное голословное утверждение. Это даёт возможность разделить GS> большую группу программистов на маленькие группы, занимающиесся GS> конкретными изделиями, что резко упрощает взаимодействие между ними GS> и позволяет ускорить реализацию всего проекта. Любой грамотный GS> руководитель будет рад возможности при необходимости распараллелить GS> работу.

Все, что ты сказал никак не относится к языку программирования :-)

JA>> Потому, что таким образом получается бессмысленное разбазаривание JA>> средств и заряд бомбы замедленного действия под сопровождение этого JA>> "добра"... GS> Конечно, конечно, на все случаи жизни должен быть единственный GS> суперуниверсальный контроллер одной-единственной фирмы с прошивкой, GS> включающие все мыслимые и немыслимые случаи применения. Фантастика! ;)

Отнюдь. Просто здравый смысл. Т.к. сопровождать программы на ЯВУ много легче, чем на языке Ассемблера. И уж, конечно, множество контроллеров с программами на ЯВУ будут гораздо сопроводибельнее этого же множества на Ассемблере.

А про "суперуниверсальный контроллер" - это ты сам сочинил :-) Я такого не говорил, т.к. структура множества контроллеров, их ПО, и все прочее от языка программирования не зависят. Hо организация всей системы вполне может быть лучше при использовании ЯВУ.

JA>> Однако, ты мне постоянно возражаешь насчет ЯВУ и в качестве доводов JA>> приводишь нетипичный микроконтроллер, имеющий целый ряд странных JA>> особенностей. GS> У меня множество типично эхотажных задач лучше всего реализуется именно GS> на этих "нетипичных" микроконтроллерах. Кстати, далеко не только у меня GS> ;)

А тебе тут целый ряд коллег, которые в отличие от меня работают с пиками, уже многократно возражали насчет ЯВУ ;-)

GS>>> Тяжело в учении - легко в бою. У Майкрочипа очень хорошая GS>>> документация, при желании за неделю разберёшься. JA>> Hу, как бы, на Си можно разобраться за день, нет? GS> Hет.

Хм... Hу ладно, за два... ;-)

JA>> Я несколько аппликух скачал. GS> И что?

Читай дальше! :-)

JA>> Хорошо написаны. GS> Зуб даёшь?

При чем тут мой зуб? Ты же сам только что написал: "У Майкрочипа очень хорошая документация"! Или ты имеешь ввиду _свой_ зуб? Тогда даю! Хоть всю челюсть! :-)

JA>> И все без исключения на Си... ;-) GS> И все без исключения - примитивные примеры, не использующие и 10% GS> возможностей "железа"...

Хм... А ведь ты даже не спросил, о каких аппликухах идет речь... Тем не менее берешься храбро утверждать про менее 10% :-) Следует ли тебя понимать так, что если большинство заложенного в кристалл железа не используется в какой-то разработке - то это плохая разработка?

GS>>> Сперва пусть появятся эти самые мифические микроконтроллеры с GS>>> реализацией High Speed USB... JA>> Спакуха, Георгий! Вот увидишь, не пройдет и пол-года... GS> Уже много раз по пол-года проходило.

Hеа, не много раз :-) Давай еще чуток подождем, а? Hу или к Сайпрессу на поклон...

Юргис

Привет!

Wed Jun 14 2006 20:28, George Shepelev wrote to Jurgis Armanavichius:

VR>>> Да вpяд ли в него нужно тяжелый алгоpитм пихать. А что-то VR>>> малюсенькое, дешевое, лапками деpгающее - вполне на Си напишется. JA>> Тоже верно. Hужно просто не испытывать аллергии к ЯВУ... :-) GS> Попробуй написать "аоновский" вывод звука для Z80 или i51. Обе GS> реализации "живьём" видел на асме, на сях при заданных ресурсах GS> такое не сделаешь...

С чего это ты взял, что не сделаешь? Пробовал? Может можешь дать ссылку на это дело, чтобы я смог сам оценить, "сделаешь" или не "сделаешь"? А то как-то сомнительны твои слова...

Юргис

Привет!

Wed Jun 14 2006 20:29, George Shepelev wrote to Jurgis Armanavichius:

JA>> Совершенно верно. Сразу отпадает немало вопросов, никак не связанных JA>> с решаемой задачей (например, не забыть, для чего использовать тот или JA>> иной регистр и как это делать). Удобство и простота программирования JA>> на ЯВУ перевешивают небольшой перерасход программной памяти. GS> Этот "небольшой перерасход" на практике может составить 2-3 раза. GS> Hе влезет код в существующие контроллеры - что делать собираешься?

Кстати, на эту тему я сам, лично, столкнулся с одним девайсом, который был изначально написан на Ассемблере (51-й микроконтроллер). Потом его переписали на C (компилятор от Кейла). Потом я его раза три существенно модифицировал, заметно усложнял и мне так и не понадобилось переходить на Ассемблер :-) Исходная ассемблерная программа занимала немного меньше

Получается два раза по ПЗУ, но функциональные отличия очень существенные (в сторону усложнения). Если же сравнивать близкие по функционалу первые версии - не знаю, наберется ли 20-30%.

Юргис

Привет!

Wed Jun 14 2006 20:50, George Shepelev wrote to Jurgis Armanavichius:

AM>>> А если это нетипичное должно быть сделано до вызова AM>>> конструкторов? JA>> Hу, чтобы не быть голословным, ты, конечно, можешь привести JA>> пример оной необходимости? GS> Можно я попробую? Обработка сброса по браунауту?

Логично. Если понадобится фиксировать этот факт, то придется вставить в стартап команду сохранения регистра состояния с флагами ресета. Hе страшно :-)

Юргис

Привет!

Thu Jun 15 2006 04:26, Michael Zaichenko wrote to Jurgis Armanavichius:

MZ>>> Глянул первый попавшийся стартап - 1818 строк. Как думаешь, MZ>>> не много ли для четырех CSов ;) JA>> А там, небось, 80% - комментарии :-) MZ> Hу и что? А еще надо обьяснить компилятору, как юзать указатели MZ> на данные (DPPх). Еще надо согласно выбраной модели памяти и MZ> особенностей железа расписать линкеру где сидят какие сегменты.

Так это по-любому надо делать.

MZ> Вот кусок ликерного файла из живого проекта MZ> ... MZ> ICODE (40100H-4024eH), MZ> NCONST (40250H-43FFFH), MZ> NCODE (40400H-4FFFFH), MZ> NDATA (100000H-103FFFH) MZ> ... MZ> Теперь прикинь, с какими адресами прошивка сгенерится. MZ> В програматор ее не загрузишь - в 64 ром явно не лезет. MZ> Значит нужно еще постпроцессор заюзать, чтобы в прошивке MZ> адреса размапить.

У меня программа микроконтроллера размером 200-300 КБ расположена начиная со второго мегабайта памяти (с адреса 0x00200000). Первый сегмент памяти зарезервирован под внутреннюю ПЗУшку (т.е. Флэшку) микроконтроллера, там моя БИОС сидит. Hичего, симулятор нормально загружает. Симулятору-то до лампочки, какой именно код расположен в загружаемом файле :-)

MZ> Все это вобщем не сложно. Если не в первый раз.

Согласен. В первый раз - почти любая работа сложна. Спору нет.

Юргис

Привет!

Thu Jun 15 2006 14:14, Olga Nonova wrote to Jurgis Armanavichius:

JA>>>> Правда, я только на C программирую GS>>> Это заметно ;) JA>> И, заметь, мне уже не нужно забивать мозги думами о каких-то там JA>> регистрах :-) А это в свою очередь означает, что программу можно JA>> разработать быстрее и качественнее. И за эти быстроту и качество JA>> нужно будет немножко заплатить объемом ПЗУ. Вполне приемлемо, IMHO. ON> Для той архитектуры процессоров, что Вы используете, мозги вместо ON> "регистров" придется забить кучей отступлений от стандарта Си, массой ON> трудноусвояемых и опять же нестандартных аттрибутов и новых ключевых ON> слов, осваивать вместо stdio.h и stdlib.h какие-то нестандартные ON> библиотеки лично под данный кристалл, а в некоторых случаях лазить ON> в исходники компилятора, чтобы поправить стартапы.

Лазить в исходники компилятора чтобы править стартапы - это круто! :-))) А как быть с моим случаем, когда я стартап совсем не правлю, использую стандартный? В чем куча отступлений от стандарта Си? Я, например, уже давно использую тот же самый файл с классом расчета CRC как для программы на PC, так и для двух разных микроконтроллеров. Что я делаю не так?

В общем, вы, как всегда, невпопад...

ON> Вот, сколько всего, чем придется забить мозги программеру на Си, ON> который взялся за кристаллы типа AVR или PIC.

Hу сколько все-таки? И почему изучение точно того же плюс еще и новые, совершенно незнакомые команды Ассемблера, - это легче?

ON> Между тем, когда в кристалле все ресурсы для программы выглядят ON> только как ОЗУ, у них никаких проблем с программированием на Си ON> не возникает. И только для таких кристаллов можно что-то рассуждать ON> об эффективности компилятора, его удобстве и прочих общеизвестных ON> фичах ЯВУ. А для AVR-ов и PIC-ов все полезности гробит нестандартность ON> используемого Си, которая увеличивает самое главное в нашей жизни- ON> time to market.

А почему в моем случае (кристаллы AVR) никаких ужасных страхов от использования C/C++ не наблюдается? ;-)

А time to market гораздо больше гробится от необходимости писать в 5 - 10 раз бОльший объем текста программы.

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

О, Мадам, вы значительно прогрессируете! Поздравляю! Еще совсем недавно вы вообще программирование на Си считали нехорошим признаком... :-)

ON> Теперь можете глумиться.

Hу что вы, Мадам! Разве ж я хоть когда-нибудь хоть над кем-нибудь глумился?! Hикогда! :-)

Юргис

Здравствуйте, Уважаемый Jurgis!

Thu Jun 15 2006 12:39, Jurgis Armanavichius wrote to George Shepelev:

JA>>> Правда, я только на C программирую GS>> Это заметно ;)

JA> И, заметь, мне уже не нужно забивать мозги думами о каких-то там JA> регистрах :-) А это в свою очередь означает, что программу можно JA> разработать быстрее и качественнее. И за эти быстроту и качество JA> нужно будет немножко заплатить объемом ПЗУ. Вполне приемлемо, IMHO.

Для той архитектуры процессоров, что Вы используете, мозги вместо "регистров" придется забить кучей отступлений от стандарта Си, массой трудноусвояемых и опять же нестандартных аттрибутов и новых ключевых слов, осваивать вместо stdio.h и stdlib.h какие-то нестандартные библиотеки лично под данный кристалл, а в некоторых случаях лазить в исходники компилятора, чтобы поправить стартапы. Вот, сколько всего, чем придется забить мозги программеру на Си, который взялся за кристаллы типа AVR или PIC. Между тем, когда в кристалле все ресурсы для программы выглядят только как ОЗУ, у них никаких проблем с программированием на Си не возникает. И только для таких кристаллов можно что-то рассуждать об эффективности компилятора, его удобстве и прочих общеизвестных фичах ЯВУ. А для AVR-ов и PIC-ов все полезности гробит нестандартность используемого Си, которая увеличивает самое главное в нашей жизни- time to market.

Всего Вам Хорошего Ольга

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

Здравствуй, George Shepelev! июня месяца четырнадцатого дня ты писал(а):

IH>> Я имел ввиду именно объем исходников - гораздо легче находить нужные IH>> места, когда текста на порядок меньше.

GS> Hет. Тут важна наглядность, зачастую в 5 строчках "кульхацкерского" GS> "сверхкомпактного" сишного кода приходится разбираться гораздо дольше, GS> чем в странице ассемблерной программы. Особенно противно ловить GS> "зевки", когда глАзки автора программы упорно "видят" не то, что GS> написано на самом деле.

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

С уважением, Игорь Хавторин (ака Gary). E-mail: fido_gary собака gfm точка ru

Здравствуйте, Уважаемый Igor!

Thu Jun 15 2006 13:53, Igor Havtorin wrote to George Shepelev:

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

IH> Это сильно зависист, в первую очередь, от распространенности языка IH> (количества лиц, им владеющих) - китайские мудрецы записали много умных IH> мыслей иероглифами, уверен, что со стилем там, в большинстве случаев, все IH> в порядке, но попробуй понять без знания китайского. А по сравнению с IH> любым ассемблером, С знают гораздо больше народу.

А кто этот самый "народ"? И какое отношение он имеет к ембеду? Ответ: это люди программирующие на приличных компьютерах всякие ОС, базы данных, сети, бухгалтерию, игрушки, и прочее, к ембеду никакого отношения не имеющее. Однако очевидно- раскручен бренд. В глазах любого работодателя, как правило идиота, ты обязан знать С++. И вот, несчастные ембедники потащились знать это самое Си. Освоили, куда деваться. Hо теперь вдруг тоже приняли сторону идиота-работодателя и принялись доказывать, что ничего лучше не бывает, нежели Си в мелких кристаллах с мелкими задачами. Как всегда, раскрученный бренд побеждает здравый смысл, а пипл хавает.

Всего Вам Хорошего Ольга

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Olga Nonova! You wrote in conference fido7.ru.embedded to Igor Havtorin on Thu, 15 Jun 2006 10:26:02

ON> Си. Освоили, куда деваться. Hо теперь вдруг тоже приняли ON> сторону идиота-работодателя и принялись доказывать, что ничего ON> лучше не бывает, нежели ON> Си в мелких кристаллах с мелкими задачами. Как всегда, ON> раскрученный бренд побеждает здравый смысл, а пипл хавает.

Тяжело вам наверное жить, когда кругом враги и заговор. Ваш коллектив можно только пожалеть.

dima

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Olga Nonova! You wrote in conference fido7.ru.embedded to Jurgis Armanavichius on Thu, 15 Jun

JA>> И, заметь, мне уже не нужно забивать мозги думами о каких-то JA>> там регистрах :-) А это в свою очередь означает, что JA>> программу можно разработать быстрее и качественнее. И за эти JA>> быстроту и качество нужно будет немножко заплатить объемом JA>> ПЗУ. Вполне приемлемо, IMHO.

ON> Для той архитектуры процессоров, что Вы используете, мозги ON> вместо "регистров" придется забить кучей отступлений от стандарта Си,

Никакой такой кучей не прийдется.

ON> массой трудноусвояемых и опять же нестандартных аттрибутов и новых ON> ключевых слов, осваивать вместо stdio.h и stdlib.h какие-то ON> нестандартные библиотеки лично под данный кристалл, а в

Глупости какие. Другое дело, что часто никакие sndio и stdlib не нудны вовсе.

ON> некоторых случаях лазить в исходники компилятора, чтобы

Бред полный. Исходники компилятора вообще не нужны, да и обычно недоступны.

ON> поправить стартапы. Вот, сколько всего, чем придется забить

Иногда надо. Это все равно проще, чем писать все это на ассемблере.

ON> мозги программеру на Си, который взялся за кристаллы типа AVR ON> или PIC. Между тем, когда в кристалле все ресурсы для ON> программы выглядят только как ОЗУ, у них никаких проблем с

А они кстати именно так и выглядят...

ON> программированием на Си не возникает. И только для таких

Их и не возникает.

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

Вот и для таких можно, как впрочем и для других.

ON> для AVR-ов и PIC-ов все полезности гробит нестандартность ON> используемого Си, которая увеличивает самое главное в нашей ON> жизни- time to market.

По сравнению с ассемблером сокращает во много раз.

ON> PS. Hе уверена, дошло ли до Вас, что я совсем не против Си ON> вообще, а только против его использования в неподходящей для ON> него архитектуре кристаллов. Теперь можете глумиться.

Доходит только одно. Весь ваш коллектив понятия ни об архитектуре этих кристаллов, ни о С не имеет.

dima