Ну что ж, всем спасибо, разъяснили на пальцах. Я понял. Просто писал и там и там, и вот подумал где кекс будет меньше. Как почитаешь топики разные, так получается, что каждый кулик своё болото хвалит)))) Вот и стало интересно)

Всем ещё раз огромное спасибо!!!!!!

...чуть-чуть по-занудствую
Термин элегантно, относиться, скорей, к искусству, нежели к программированию. Ну или к человеческому восприятию тех или иных вещей (в том числе и не материальных). А про меру элегантности я вообще молчу. И что значит "более элегантно"? В каких единицах измеряется? На сколько элегантнее? Смешно, однако.
Поэтому, IMHO, правильнее сказать эффективнее по критерию "размер генерируемого кода".
Теперь про "ассемблирует". Слово заимствованное, означает "сборка", "собирать" и т.п.
Если программа написана на языке ассемблера, т.е. в терминах непосредственно соответствующих машинным командам, то как раз и осуществляется, можно сказать, простая сборка готовой программы.
Если же брать ЯВУ, то компилятор осуществляет преобразование программы на ЯВУ в представление на более низкоуровневом языке (объектные файлы, байт-код, листинг на ассемблере, ... ). А потом может осуществляться та самая сборка. Обычно это выглядит как одна операция, но внутри компилятора это всегда несколько стадий. Поэтому компилятор - компилирует (транслирует) программу.
Термин сборка (собрать программу) применяется ещё касательно командных файлов и файлов сборки (makefile) с помощью которых осуществляется запуск программ необходимых для получения исполняемого файла или файла прошивки.

Что лучше, что хуже?... См. третью строку подписи.

Полностью согласен с Kavka.
Что касается эстетики программирования, то иногда смотря на исходный код, хочется задавить автора, а иногда... У меня в голове возникает термин "изящно".

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

... данный термин скорее всего ИМХО является аналогом фраз читаемость , удобство сопровождения и т.п...
... а кто запрещает сделать ручками то же самое?

В AVR Studio 4 есть вот такая фишка, которая может "побить" всё остальное. Когда проект вырастает из штанишек, то основным критерием становится отладка. Вряд ли может быть что-либо лучше оригинального отладчика. Между прочим, в AVR Studio 4 можно даже отлаживать в железе проекты BASCOM AVR, т.е. на бейсике написанные. Представьте себе, отладчик даже пытается ходить по коду листинга при отладке.

Довольно сомнительное и загадочное утверждение. Оновным критерием чего становится отладка?

По-моему, совсем наоборот: поскольку отладка - это лишь поиск и исправление ошибок, созидательным процессом она не является; время, потраченное на отладку, отнято у разработки, поскольку сроки не резиновые. Если разработчики много времени проводят в отладчике, это верный показатель незрелости процессов разработки. Так что штанишки могут оказаться даже великоваты, так сказать, на вырост.

Есть довольно интересные методики, которые помогают выявить ошибки как можно быстрее и практически устраняют необходимость отладки, например, TDD (test-driven development, разработка через тестирование), CI (Continuous Integration, непрерывная интеграция) и др. Для применения этих методик в разработке встроенных систем имеются специальные инструменты, но они слабо связаны со средой разработки; их с равным успехом можно применять как в атмеловских "Студиях" любой версии, так и в альтернативных средах вроде Eclipse или CodeBlocks.

Как раз те, кто говорят, что все едино, часто и оправдывают этим свою лень и нежелание учиться. : )

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

Из личного опыта:

1. пришедшие с ПК склонны пихать float везде. Особенно, если пришли с чего-то типа Python.

2. пришедшие с ПК склонны использовать тип bool там, где хватит бита в переменной состояния. На ПК с его гигабайтами оперативной памяти это и правда некритично, в эмбеде всегда лучше использовать флаги для экономии памяти, ибо один байт заменяет ВОСЕМЬ булевских переменных.

3. пришедшие с ПК склонны выбирать для переменных самый большой тип, или просто по умолчанию пишут int, в то время как в эмбеде лучше брать минимально достаточный по размеру тип.

Что характерно, порой пришедшие с ПК пытаются записать в int на AVR число, большее 0xFFFF, и удивляются, что оно не лезет.

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

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

Я соглашусь с вами, Goldsmith, если вы мне покажите реальный проект для встраиваемых систем, где эта TDD использовалась. Не теоретическая возможность, а нечто осязаемое, что можно потрогать, перенять, вставить в свой проект. Мне просто интересно как это может выглядеть для микроконтроллерных проектов.

Лет за 12 я видел всего одного человека, который пытался что-то такое делать и может быть у него даже что-то и получалось: Немного о тестировании программ для МК. Но подход его в массы не пошёл.

Остальные люди пользуются отладчиком для всего: отлов ошибок, изучение периферии, экспериментирование, доводка и т.д.

100% ...
Бредоносцы в потёмках это святое... без них скучно...

Что и следовало ожидать...

Да, я о том же...

YS, можно ещё добавить:

5. Пришедшие с ПК склонны в прерывания вставлять вывод в uart (с функцией sprintf()) и потом удивляться, что всё как-то не так работает.

6. Пришедшие с ПК вряд ли сообразят, что отладку "узких" по времени мест в коде можно делать при помощи осциллографа, используя свободные выводы контроллера как флаги. Так, кстати, делать правильнее, чем вставлять printf'ы и прочее в ISR.

На больших ПК между программистом и железом лежит толстая прослойка промежуточного ПО, которая скрывает устройство железок от пользователя. На низком уровне ничего такого нет, ты работаешь практически напрямую с сигналами и нет времени задуматься и сделать ещё что-то, разве что только ножкой дёрнуть, чтобы на осциллограмме это было заметно. Между прочим, я когда-то именно так проводил теститрование драйвера Modbus одного. Там важен один интервал в 3,5 символа, так вот нужно было убедиться, что он реально выдерживается, а как это сделать? У нас был один цифровой осциллограф, который более менее что-то там пытался оцифровывать, я наснимал на нём разные пакеты, потом загрузил их в Mathcad и расчётным путём подтвердил, что вроде всё нормально работает в разных режимах. Как такое сделать программным путём мне трудно представить, а ведь выдержка временных диаграмм в протоколах - это очень важная вещь, если она реализуется программно.

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

С такой аргументацией лучше в тему "Мяу - православие". Таки все пришедшие и таки везде?

Начсет Питона - ну несерьезно же. Вы бы еще взяли для себя ориентиром тех, кто программирует в 1С-Бухгалтерии или раскрашивают веб-странички.

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

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



К сожалению, да. Но это уже не эмбед, это дилетантство. Эмбеддер - человек, который разбирается и в схемотехнике, и в программировании. Этим он и ценен.



Общаюсь с большим удовольствием. С ними приятно говорить, поскольку они свободны от всех перечисленных ляпов. Более того, у них можно многому поучиться.

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



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



А вот это мейнстрим, именно то, что в среднем значит сейчас слово "программист". Естесственно, я ориентируюсь на большинство и под "программированием на ПК" понимаю именно это. С этим и боремся.

Если действительно интересно - извольте для начала:
http://www2.enel.ucalgary.ca/People/Smi ... _paper.pdf
http://www.atomicobject.com/files/EIT20 ... dedTDD.pdf
Если заинтересуют эти примеры, добавлю еще, "их есть у меня". в принципе можете самостоятельно найти примеры на сайте фирмы Atomic Object вместе с бесплатными инструментами весьма неплохого качества. Да и вообще эта команда открыта для общения, если решите пообщаться с ними, не пожалеете. Есть и другие, но не буду загромождать этот пост ссылками. Захотите еще - всегда пожалуйста.

Кстати, я и сам решился "поиграться" с микроконтроллерами лишь после того, как удалось подобрать адекватный набор инструментов для TDD. Уж очень сильный когнитивный диссонанс вызывал столь явный разрыв между дисциплиной программирования "больших" распределенных систем и убогостью инструментария для встроенных разработок. Как только выяснилось, что и в embedded мире дела обстоят не так уж плохо, сомнения исчезли.

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

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

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

А для бабушек из бухгалтерии "программист" - это тот, кто втыкает обратно вырванные уборщицей провода и меняет бумагу в факсе. Не доводилось встречать такую точку зрения? Если нет, Вам очень повезло.

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

P.S. Байки про тотальную глупость "больших" программеров оценил, смишно. При наличии достаточно извращенной фантазии можно сочинить аналогичный анекдот про то, как эмбеддер пишет программу "Hello World" под Windows пару месяцев, поскольку ему для вывода фразы на экран приходится сначала разрисовать шрифт по точкам, а затем написать свой драйвер для прямого доступа к памяти видеокарты, чтобы эти точки высветить на экране. Но нужно уметь отличать анекдоты от реальной жизни. А в реальной жизни зачастую оказывается, что другие не настолько глупее нас, как нам хотелось бы думать. Чем раньше сможете с этим смириться, тем меньше разочарований испытаете впоследствии.

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

Вот что тут чаще всего, насколько я заметил, народ делает? Пишет на скорую руку программку, при этом из разных частей, прошивает кое-как (программатор-то у всех есть), она с первого раза не работает и далее идёт процесс поиска ошибки. Большая часть ошибок, насколько я замечал, от недопонимания самого предмета - мк, следующая часть от недопонимания Си, далее - собственно, используемого алгоритма в программе. Что делает человек, когда сдался? Пишет пост, говорит, что не работает и прикладывает код как есть Телепаты начинают работу. А что могло бы быть, имей человек хотя бы какое подобие отладчика? Он мог бы набирать программу не целиком, а частями и постепенно двигаться к цели - кусочек за кусочком, проверяя работу в отладчике. Написал одну строчку - проверил, ещё одну - проверил... и так далее, пока не дойдёт до нужного результата. Если же код работает как-то не так, то он смотрит состояние отладчика и думает почему так. Такой подход используется для самообучения. Чем плох такой вариант? И чем он отличается от подхода при программировании в той же Delphi, Visual Studio? Да ни чем не отличается. Там точно также пишешь код, компилируешь и смотришь под отладчиком, причём, делаешь это постоянно и итеративно.

Ещё вариант. Приняли на работу человека и дали ему объём - сопровождай, говорят. Сидит человек, думу думает и спрашивает главного программиста, а как это вообще работает? И что, он будет схемы алгоритмов рисовать что-ли? Кто-нить их видел когда в чужом проекте? Я лично нет. В таком случае берёшь отладчик, задаёшь начальные условия и прыгаешь по коду, пока не поймёшь общую структуру. Я, к примеру, по тому же freemodbus'у долго так прыгал в отладчике, пока, наконец, до меня не дошло как меняются состояния в программе, т.е. как данные транслируются в процессе циклической работы. По листингам это понять можно, но только прокручивая это всё в голове, но голова от этого может заболеть и времени так удёт на порядок больше.

Я бы вообще рекомендовал всем местным товарищам освоить связку: AVR Studio 4.xx + Proteus VSM + виртуальный нуль модем + терминал. Это покроет многие вопросы при отладке программ на асме, Си и С++. При этом можно не иметь пока реального железа, но большую часть кода можно проверить виртуально, общаясь с мк через терминал и отладчик Студии.

Если заинтересуетесь, у меня в запасе еще есть подобные. Я пристально слежу за этой темой, поскольку пока материалов негусто, мало кто охотно делится своими наработками.

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

Мне искренне непонятен ваш с YS подход - выбирать какие-то маргинальные примеры и на их основе делать глубокие выводы. Один выбирает программистов-неумех и на этом основании делает вывод о плачевном состоянии отрасли в целом; другой наблюдает за горе-эмбеддерами и рисует столь же безрадостную картину. Неудивительно, что отсюда следует вывод: "гуанокодинг" на "больших" системах и "коекакерство" в эмбеддинге не имеют ничего общего (хотя с моей точки зрения это как раз одно и то же - халтура, она и есть халтура).

Переместитесь на другую сторону шкалы мастерства: сравните лучшие практики "большого" программирования и эмбеддерства. Удивитесь, как много среди них общего: методики, инструменты, паттерны... Это, конечно, потруднее, но куда результативнее.

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

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

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

К чему весь этот красивый бред, если сами ни разу этим не пользовались???
Спуститесь на землю, только не быстро, а то больно будет...
Я понимаю... хорошо писать красивые слова, особенно если ничего в этом не смыслишь... да и всегда найдутся те, кто будет слушать открыв рот...
"Ах, как она играла!"(С)


А если всё так легко и просто, почему всё так хреново с прогами на "большом сером брате"... глюк на глюке, тормоз на тормозе???
Никто не тестирует, или тесты гуано???

К сожалению, большая часть моих примеров это суровая реальность, а вовсе не маргинальность. Взять тот же UML2, честно говоря, я знаю только одного человека, который пытался это применить для написания оберточного кода - это я сам. Где-то с год назад или больше я открыл тему по этому поводу на форуме электроникса, которую так и назвал: кросскомпиляторный шаблон проекта на C++ для GCC и IAR, попытка правильного проектирования сверху. Мне удалось на практике самому найти инструментарий, который мог автоматизировать работу по созданию классов на UML2 и экспорту их в код, а также импорту обратно. Хотя это вроде даже практически работает, но не нашлось с тех пор ни одного человека, которого бы это заинтересовало, так как для этого нужно много дополнительных знаний, не говоря уж про C++, который мало используется на практике.

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

Я разбирал много чужого кода и никакой ни модульности, ни прочего, честно говоря не видел. Зачем далеко ходить, многие периферийные модули или протоколы всем известны. Я уже приводил имена: PetitFS, freemodbus, библиотеки для работы с индикаторами, v-usb. Исходники известны, можно добавить ещё что-то. Хотел бы я узнать какой паттерн и где там применялся. Я же не собираюсь всё это переписывать сам с нуля.

Что касается документирования алгоритмов, то могу сказать следующее, я работал автоматчиком в прокатном цехе двухниточного стана, который полностью автоматизирован и работает большей частью на 5-6 ПЛК от Сименс. Так вот, эти самые алгоритмы программ являются ноухау фирмы Даниелли и никто и не собирается и не собирался нам их давать. Автоматчикам дается общий курс и показываются некоторые места в коде, а дальше они могут лишь из отладчика наблюдать как работает стан и так постепенно его изучать. И это у европейцев считается нормой. На электрику вся документация есть, а на алгоритмы в ПЛК нет ничего, только описание вх и вых сигналов, всё. Так что это не глупость, а суровая реальность. Не хочет давать фирма алгоритмы и не даст, а всё сопровождение идёт при помощи отладчиков, которые могут в реальном времени смотреть на схемы внутри ПЛК. Либо при помощи анализаторов, но они имеют некоторые ограничения.