...чуть-чуть по-занудствуюDr. Alex писал(а):Я про код AVR Studio на Сях говрю, как-то более элегантно компилятор ассемблирует....
... данный термин скорее всего ИМХО является аналогом фраз читаемость , удобство сопровождения и т.п...Kavka писал(а):Термин элегантно, относиться, скорей, к искусству, нежели к программированию.
... а кто запрещает сделать ручками то же самое?Vov123 писал(а):В CVAVR есть удобная "фишечка"...
Код: Выделить всё
Delay_ms(int cnt){
while(cnt--){delay_us 1000;}
}
Довольно сомнительное и загадочное утверждение. Оновным критерием чего становится отладка?uni писал(а):Когда проект вырастает из штанишек, то основным критерием становится отладка.
Как раз те, кто говорят, что все едино, часто и оправдывают этим свою лень и нежелание учиться. : )есть довольно распространенное заблуждение, что программирование контроллеров принципиально отличается от остального программирования, но оно несостоятельно и служит лишь оправданием лени и нежелания учиться
100% ...YS писал(а):Как раз те, кто говорят, что все едино, часто и оправдывают этим свою лень и нежелание учиться. : )есть довольно распространенное заблуждение, что программирование контроллеров принципиально отличается от остального программирования, но оно несостоятельно и служит лишь оправданием лени и нежелания учиться
Что и следовало ожидать...uni писал(а):Но подход его в массы не пошёл.
Пока по этой статье всё выглядит так как будто всеобъемлющее автоматизированное тестирование — это какая-то серебреная пуля, позволяющая отловить, если не все, то почти все дефекты в разрабатываемой программе. В реальной жизни это далеко не так. Во первых если просто наклепать каких-никаких тестов для уже написанной программы, то это не даст ровным счетом ничего. Такие тесты будут просто показывать, что программа работает именно так, как она работает и будут пригодны только для проверки, что новые изменения не сломали старую функциональность (уже полезно, впринципе). Во-вторых далеко не всякий код можно и нужно тестировать независимо от всей остальной системы. Например, драйвера различных специфичных внешних устройств, которые нельзя симулировать, очевидно можно тестировать только на реальном оборудовании. Проще говоря для того чтобы протестировать фрагмент кода (модуль) нужно в тестовом окружении воспроизвести все его исходящие зависимости.
Альтернативно одаренных можно найти в любой области. Вы найдете немало и обратных примеров, - тех, уто уверен, что главное в эмбеддинге - это выбор правильной температуры жала паяльника, а код вполне можно писать задней левой ногой, и неплохо получится. Причем далеко ходить не придется.YS писал(а):Мне лично приходилось просвещать в эмбеде нескольких людей, до того писавших исключительно под ПК, и вследствие сего привыкших к гигабайтам оперативной памяти, гигагерцам тактовой частоты а также возможностям стандартного вывода.
С такой аргументацией лучше в тему "Мяу - православие". Таки все пришедшие и таки везде?YS писал(а):пришедшие с ПК склонны пихать float везде. Особенно, если пришли с чего-то типа Python.
О-о-о, printf - это вообще песня.5. Пришедшие с ПК склонны в прерывания вставлять вывод в uart (с функцией sprintf()) и потом удивляться, что всё как-то не так работает.
Сколько шаблонов было разорвано тем фактом, что для мелкого-мелкого контроллера printf - страшный монстр, которого лучше не использовать...К сожалению, да. Но это уже не эмбед, это дилетантство. Эмбеддер - человек, который разбирается и в схемотехнике, и в программировании. Этим он и ценен.Вы найдете немало и обратных примеров, - тех, уто уверен, что главное в эмбеддинге - это выбор правильной температуры жала паяльника, а код вполне можно писать задней левой ногой
Общаюсь с большим удовольствием. С ними приятно говорить, поскольку они свободны от всех перечисленных ляпов. Более того, у них можно многому поучиться.Пообщайтесь лучше с теми, кто пишет драйверы и/или любой код в режиме ядра для ПК (ну и вообще решает задачи реального времени на этой платформе).
Таки не все, да. Мой друг-программист, специалист по распределенным вычислениям и поклонник Хаскеля, исследователь вирусов на досуге, неплохо разбирается в схемотехнике и пишет кристалльно ясный код на любом из знакомых ему языков. Но таких единицы.Таки все пришедшие и таки везде?
А вот это мейнстрим, именно то, что в среднем значит сейчас слово "программист". Естесственно, я ориентируюсь на большинство и под "программированием на ПК" понимаю именно это. С этим и боремся.Начсет Питона - ну несерьезно же. Вы бы еще взяли для себя ориентиром тех, кто программирует в 1С-Бухгалтерии или раскрашивают веб-странички.
Если действительно интересно - извольте для начала:uni писал(а):Я соглашусь с вами, Goldsmith, если вы мне покажите реальный проект для встраиваемых систем, где эта TDD использовалась. Не теоретическая возможность, а нечто осязаемое, что можно потрогать, перенять, вставить в свой проект. Мне просто интересно как это может выглядеть для микроконтроллерных проектов.
Судя по статье, подход довольно наивный и для влияния на массы явно слабоват. Я даже опускаю придирку, что человеку, не владеющему родным языком и не знающему, как пишется слово "серебряный", явно противопоказано писать статьи до прокачки скилла в великом и могучем. В наше время повальной профанации это уже печальная норма. Хотя есть там и явно здравая мысль (хоть и заимствованная у классиков, но тем не менее):uni писал(а):Лет за 12 я видел всего одного человека, который пытался что-то такое делать и может быть у него даже что-то и получалось: Немного о тестировании программ для МК. Но подход его в массы не пошёл.
Но, поскольку эта мысль не подкреплена конкретными рекомендациями, она легко теряется в общем белом шуме пустословия.Отсюда вывод: программы изначально нужно разрабатывать с учётом потребности в тестировании.
Ну и зря. Отладчик нужен для отладки (прошу прощения за банальность), т. е. обнаружения точного местоположения ошибки, само наличие которой уже обнаружено тестами (или жалобами пользователей, оказавшихся в роли невольных бета-тестеров, если разработчики сами не удосужились протестировать собственный продукт). Отладчик сам по себе интерактивен, поэтому обнаружение ошибок с его помощью - чистое разбазаривание времени разработчика. Я искренне завидую тем, чьи заказчики столь щедры, что оплачивают такие забавы из своего кармана.uni писал(а):Остальные люди пользуются отладчиком для всего: отлов ошибок, изучение периферии, экспериментирование, доводка и т.д.
А для бабушек из бухгалтерии "программист" - это тот, кто втыкает обратно вырванные уборщицей провода и меняет бумагу в факсе. Не доводилось встречать такую точку зрения? Если нет, Вам очень повезло.YS писал(а):вот это мейнстрим, именно то, что в среднем значит сейчас слово "программист".
За ссылки спасибо, один проект тестовый я у них взял, посмотрю. Отладчик для эмбеддера - это такой же точно инструмент как осциллограф. Если бы у местного народа был нормальный отладчик, то большая часть вопросов у них просто бы отпала сама собой, а если бы был и осциллограф, то многие даже и не думали писать здесь свои вопросы, так как ошибку или недочёт они могли увидеть прямо на экране.Ну и зря. Отладчик нужен для отладки (прошу прощения за банальность), т. е. обнаружения точного местоположения ошибки, само наличие которой уже обнаружено тестами (или жалобами пользователей, оказавшихся в роли невольных бета-тестеров, если разработчики сами не удосужились протестировать собственный продукт). Отладчик сам по себе интерактивен, поэтому обнаружение ошибок с его помощью - чистое разбазаривание времени разработчика. Я искренне завидую тем, чьи заказчики столь щедры, что оплачивают такие забавы из своего кармана.
Телепаты начинают работу. А что могло бы быть, имей человек хотя бы какое подобие отладчика? Он мог бы набирать программу не целиком, а частями и постепенно двигаться к цели - кусочек за кусочком, проверяя работу в отладчике. Написал одну строчку - проверил, ещё одну - проверил... и так далее, пока не дойдёт до нужного результата. Если же код работает как-то не так, то он смотрит состояние отладчика и думает почему так. Такой подход используется для самообучения. Чем плох такой вариант? И чем он отличается от подхода при программировании в той же Delphi, Visual Studio? Да ни чем не отличается. Там точно также пишешь код, компилируешь и смотришь под отладчиком, причём, делаешь это постоянно и итеративно. Если заинтересуетесь, у меня в запасе еще есть подобные. Я пристально слежу за этой темой, поскольку пока материалов негусто, мало кто охотно делится своими наработками.uni писал(а):За ссылки спасибо, один проект тестовый я у них взял, посмотрю.
IMHO Вы все же несколько преувеличиваете роль и того, и другого. И отладчик, и осциллограф вполне доступны даже для любителей. Вот только они далеко не всемогущи и должны сочетаться с другими инструментами. Логический анализатор сразу покажет полную картину там, где двухлучевым осциллографом придется долго и нудно тыкать по контактам; аналогично система автоматизированного модульного тестирования за секунду выявит ошибку, поиск которой в интерактивном отладчике может отнять изрядное время.uni писал(а):Отладчик для эмбеддера - это такой же точно инструмент как осциллограф.
Мне искренне непонятен ваш с YS подход - выбирать какие-то маргинальные примеры и на их основе делать глубокие выводы. Один выбирает программистов-неумех и на этом основании делает вывод о плачевном состоянии отрасли в целом; другой наблюдает за горе-эмбеддерами и рисует столь же безрадостную картину. Неудивительно, что отсюда следует вывод: "гуанокодинг" на "больших" системах и "коекакерство" в эмбеддинге не имеют ничего общего (хотя с моей точки зрения это как раз одно и то же - халтура, она и есть халтура).uni писал(а):Вот что тут чаще всего, насколько я заметил, народ делает? Пишет на скорую руку программку, при этом из разных частей, прошивает кое-как (программатор-то у всех есть), она с первого раза не работает и далее идёт процесс поиска ошибки. Большая часть ошибок, насколько я замечал, от недопонимания самого предмета - мк, следующая часть от недопонимания Си, далее - собственно, используемого алгоритма в программе.
Опять маргинальный пример. В "большом" программировании довольно давно и успешно применяется нотация UML, которая для кода является примерно тем же, чем принципиальная схема и прочая документация - для оборудования. Ее вполне успешно адаптировали для приложений реального времени (один из участников этого процесса даже написал очень неплохую книгу).uni писал(а):Сидит человек, думу думает и спрашивает главного программиста, а как это вообще работает? И что, он будет схемы алгоритмов рисовать что-ли? Кто-нить их видел когда в чужом проекте? Я лично нет.
А если использовать паттерн проектирования MCH (это эмбеддерский аналог паттернов MVC и MVP из мира "больших" программ, найдете его описание в статьях по моим ссылкам), который отделяет бизнес-логику программы от оборудования, то совместно с системой модульного тестирования и генератором мок-объектов точно так же сможете большую часть кода отладить без "железа" и даже без симулятора, и к тому же в качестве бонуса получить хорошую архитектуру, а также возможность применять регрессионное тестирование, что довольно накладно с использованием отладчика.uni писал(а):Я бы вообще рекомендовал всем местным товарищам освоить связку: AVR Studio 4.xx + Proteus VSM + виртуальный нуль модем + терминал. ... При этом можно не иметь пока реального железа, но большую часть кода можно проверить виртуально, общаясь с мк через терминал и отладчик Студии.
А если всё так легко и просто, почему всё так хреново с прогами на "большом сером брате"... глюк на глюке, тормоз на тормозе???Goldsmith писал(а):А если использовать паттерн проектирования MCH (это эмбеддерский аналог паттернов MVC и MVP из мира "больших" программ, найдете его описание в статьях по моим ссылкам), который отделяет бизнес-логику программы от оборудования, то совместно с системой модульного тестирования и генератором мок-объектов точно так же сможете большую часть кода отладить без "железа" и даже без симулятора, и к тому же в качестве бонуса получить хорошую архитектуру, а также возможность применять регрессионное тестирование, что довольно накладно с использованием отладчика.