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

К чему это я все? У меня есть практика программирования как для ПК так и для МК. Я 6,5 лет отсидел на студенческой скамье. И я себя считаю не плохим программистом. Я задался целью найти литературу или статьи по архитектуре ПО для МК. Согласитесь программирование под МК имеет свою специфику. В результате поисков я ничего не смог найти, даже малейших намеков.

Мне кажется это серьезная проблема. В данный момент я набираю людей в отдел. И на вопрос: "Что такое архитектура ПО?" я в 100% собеседований слышу мычание.

Уважаемые коллеги, скажите может я ошибаюсь и эта архитектура вовсе не нужна (ведь оно и так все работает)? А может кто чего-нибудь подскажет?

Скажите, а как оператор goto (кстати, вполне легальный, чего никак не могут понять составители школьных программ, исповедующие метод copy-paste) может помешать правильному проектированию ПО? Несколько другой уровень "проблемы".

Проектирование ПО - это точно не наука.
Из него пытались сделать ремесло, но что-то явных успехов на этом пути не видно.
Так что пока считается искусством.

PS. А наш народ, который садится за клавиатуру и начинает писать код - на самом деле следует самым модным, самым современным путём - это же так называемое XP, Extreme Programming в чистом виде!
А потом начинается TDD - Test Driven Development, когда всё это тестируют, тестируют, тестируют, тестируют, а оно всё не работает и не работает. Очень современая технология, какие могут быть сомнения?
PPS. Если набрать XP на русском получится ЧЗ - Чёрт Знает что [однако, ©!] или психбольница в руках пациентов.

Оператор GOTO делает программу не читаемой и тяжолой для внесения изменений. В 100% случаях можно обойтись без него (опыт программирования на С под МК 4 года, на С++ под Windows 8 лет и не разу не использовал оператор GOTO).
А разговоры о том что GOTO позволяет код сделать меньшего размера и повысить скорость программы считаю не актуальными. Если вы радиолюбитель, то може для Вас конечно дорогова-то выбрать контроллер с большей производительностью или большим количеством памяти, но в случае серийного производства это не проблема. Цена остается абсолютно не изменной из-за объемов. Так же считаю, что выиграшь от повышения производительности при использование GOTO не соизмерим с потерями читаемости кода.

И вообще вопрос не в этом. Вы можете использовать GOTO, но делать нужно это с умом. Если у Вас продуманная и четко просматриваемая структура программы, то ни кто Вас не у прекнет за использование этого опператора.




Слава богу я не один задумываюсь над этой темой.

Проектирование ПО - это точно не наука. Не согласен. За "бугром" это наука. У моей знакомой (учется в Гамбурге) был даже такой курс.
А как же "SWEBOK: Руководство к своду знаний по программной инженерии"?

Понятно. Очередной флудняк наметилсо

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

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


Ну так пятница, вечер...

Дык, "Great mind thinks alike".
Вот и Д. Кнут с нами согласен:
Structured Programming with go to Statement.
Donald E. Knuth, Computing Surveys, Vol. 6, No. 4, December 1974

Вы собираетесь стандартизировать процесс творчества. Ведь задание на программу может быть любое, и алгоритм тоже может быть любой. Пытаться стандартизировать процесс написания читабельной, удобной для модификации и неглючной программы, причем сразу на все случаи жизни, по моему, тоже самое, что пытаться написать пособие для авторов фантастики. Типа "Как написать клевый рассказ и заработать кучу денег". И тогда любой посредственный писака берет чудо пособие и через два дня сдает в редакцию бестселлер. Ну а раз задача стоит в стандартизации процесса работы мозгов. Думаю от них и надо плясать. Поставьте задачу для программиста. А затем... напишите программу, которая сама напишет программу вместо программиста. Вот тогда думаю, сразу станет ясно, как именно работают мозги любого программиста и останется только переложить все выводы на бумагу.
Искуственный интелект, значит создаем... А японцы идиоты, десятки лет рубятся на этом деле.
Все оказывается просто, главное отдел набрать и вперед. Блин.

Тут сложность в том, что сложно передать свой опыт проектирования. Он приходит с годами.

Каждый кто тянется к клавиатуре уже в мыслях строит что нужно написать примерно.

Более того даже хорошо спроектированный софт не будет легко модифицироваться из "танка в самолет" как автор упомянул в первом посте.

Такчто XP рулит О_о

Присоединяйтесь!

The Tao Of Programming

vvvvv, +1
ИМХО, больше всего о том КАК написана программа зудят люди, уже бессильные что-либо делать сами.

Ну придерайтесь вы к архитектуре софта, ради бога. А ещё лучше - не придерайтесь, а предлагайте другие решения. Раз вы умнее, научите чему-нибудь вместо тыканья в goto и высоких слов о проектировании ПО. Но чем вам не угодил оператор goto? Крутейшая отмазка - "я в твоей проге ни черта не могу понять!"... Так и хочется ответить: "а должен?" Делают же библиотеки на асме, части программ - тоже. По логике автора темы таких надо тупо увольнять...

Очень порочная практика. Знаю по своему горькому опыту. Работал на фирме, где престарелый конструктор, который давно не работал по специальности, обожал давать мне ЦУ. Теперь я там не работаю. Именно по вышеназванным причинам.
Считаю, что каждый должен заниматься своим делом. А критерий оценки работы - результат. Талант руководителя, заключается в том, что бы собрать толковых людей, и организовать работу. Талант программиста, в создании эффективного и безглючного кода. А использовать оператор GOTO или нет, это личное дело программиста.

Мне кажется, что бодание вокруг goto сродни религиозным войнам средних веков. На самом деле, если посмотреть, как обрабатываются исключения в ЯВУ (хоть в том же C++), станет ясно, что неявно там goto присутствует, только запрятан в стандартные процедуры обработчика. И никого это, вроде бы, не напрягает... Так что, если для существенного упрощения и уменьшения кода надо сделать пару-тройку прямых переходов - да кто же будет против? Чаще всего это применяют для обработки ошибок оборудования, а возможность ошибки или сбоя оборудования ДОЛЖНА предусматриваться в любой промышленной системе. И, соответственно, учитываться в ПО. Другое дело, что стиль Фортрана на сегодняшний день врядли кого вдохновит. А значит, и основная программа, и обработчики особых ситуаций должны писаться структурно - хотя бы для удобства чтения/модификации программы.
Что касается особенностей программирования микроконтроллеров - да, тут есть проблемы уровня реализации - как правило, приходится программировать многозадачную систему реального времени с контролем сбоев и отказов оборудования в условиях недостатка памяти (цена процессора!) и тактовой частоты (потребление!). Почти всегда такая система должна быть самовосстанавливающейся при сбоях, да еще и вести журналы данных, событий и ошибок. Но для проектирования ПО таких систем разработаны технические приемы программирования (обработчик реального времени, switch-программирование и т.д.). Насчет утверждения автора темы, что проще взять более мощный процессор для облегчения программирования при серийном производстве - тут большой вопрос, на самом деле автор занимался серийным выпуском? Мой личный опыт говорит, что заказчик готов выкручивать руки за доли цента, а за 10 лишних центов готов убить разработчика... И действительно, при выпуске 20..100 тысяч изделий эти центы выливаются в большие затраты.

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

По поводу XP (экстремального программирования). Очень ошибочное представление о этом методе. В этом методе как ни в каком другом присутствует проектирование ПО. Как я понял большинство считает, что это один программер садится за комп и начинает "педалить", перед этим получив задание. Но кто так считает, тот очень сильно ошибается. XP подразумевает командное программирование. И очень большая нагрузка ложится на project manager'a. Он составляет структурную схему приложения, дробит ее на модули и подмодули, планирует сроки и раздает задания программистам.

Почему этот метод называется экстремальным? Потому что главная цель выполннить задачу в самые крайчайшие сроки.

Любители экстремального программирования, почитайте хотя бы на http://ru.wikipedia.org что это такое.

Я заметил, что большинство программистов считает что код это их интелектуальная собственность и очень неадекватно реагируют на какие-либо попытки проникновения в него. Ребята, Вы очень заблуждаетесь!!! Код принадлежит не только Вам. По мимо Вас код принадлежит еще и Вашему начальнику. Начальнику, которого будут драть, а не Вас, за Ваши bag'i.


По поводу фразы: "На самом деле столь глобального изменения размеров и скорости исполнения в грамотно построенной программе не будет." Проверено лично. Мне пришлось переписывать программу товарища который очень любил GOTO (по этому-то и пришлось переписовать - внести изменения туда было не реально).В итоге мой код весит (hex) 32 567кБ а его 48 752 кБ. Есть разница? При этом я еще модернизировал протокол обмена с ПК и немного его "навернул".

Есть ли у меня опыт серийного производства? Есть. Серии от 100 изд в месяц до 10000 изд в месяц.
Что я имел по поводу стоимости контроллера? Если вы покупаете на базаре 10 контроллеров, то это одна цена, а если вы покупаете у официального поставщика 10000 контроллеров, то это совсем другая цена. Встречал разницу в 3-4 раза.

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

Поясню по поводу цен на комплектующие. Я. естественно, имел в виду оптовые цены производителей. Однако в своей практике что-то не встречал, чтобы цена на процессор с 16 КБ программной памяти равнялась цене процессора с 32 КБ. Как правило, они весьма отличаются. И выход за границы существующей памяти программы болезненно воспринимается заказчиком. А при разработке серийного прибора переход с OTP процессора ценой $0.5 на процессор ценой $0.6 вызывает вообще панику...

Это две большие разницы. Нельзя сравнить инфузорию с кольчатым червем по уровню IQ


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

когда пишу код для МК, стараюсь следовать принципам все-таки экстремального программирования. так, как Кент Бек нас учит http://www.books.ru/shop/books/27070 . В своё время работал в компании, где следуют этим принципам, нашел что все весьма разумно устроено. Это идеология программирования, ориентированная на клиента, конечного потребителя.
К сожелению, не все эти принципы можно легко реализовать для микроконтроллеров: в частности, мне не встречалось еще приложения для unit testing кода микроконтроллеров. Опять же, трудно следовать этим рекомендациям, когда в изделии используется МК, все ресурсы которого полностью задействованы.
А слышать от программиста "это сложно" и "этого в тз не было" - действительно весьма печально...

Этап проектирования при разработке ПО должен обязательно включаться при разработке довольно "сложного" программного обеспечения (определения "сложный" это понятие очень растяжимое), а так же при разработке ПО группой разработчиков. Для программы выводящей на экран слово "Hello world" и программы для управления одним светодиодом этап проектирования можно опустить))))

грустный какой-то топик (((

я надеялся узнать из него что-то новое...

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

Эта привычка, имхо, выработалась из-за нехватки времени на проектирование в современных условиях: контракты заключаются, как правило, на год, и разбивать проектирование на этапы с оформлением по каждому этапу (эскизный проект, технический, рабочий) документации - непозволительная трата времени. Поэтому, проектирование - в один этап: техно-рабочий проект. Программы должны иметь достаточное количество комментариев, а их текст - документ (или даже этого не имеете).
Это - жадность собственников предприятия, желающих один раз заплатить и пользоваться, пользоваться, пользоваться... Если программа написана для "изделия А", это не значит, что можно без зазрения совести использовать её в "изделии Б"!
Ну, мне бы Ваши проблемы... Если это - криптографическая защита, то заказчик серьёзный, и он (заказчик) проплатит и эскизный проект, и технический, и выпуск документации, которую у Вас и примет. В остальных случаях: сертификация ПО - дело добровольное (ну, за исключением игровых автоматов ).

если предприятие выпускает изделия A, B, C, D, E, F, в каждом из которых присутствует один-два-три ATmega, которые обмениваются данными с использованием протокола FOO, а также есть программисты R, S, X, Y, Z, которые из-за вышеозначенной причины каждый сам выдумывает свою реализацию протокола FOO; это называет не жадность, а пустая трата времени каждого из программистов.
И если программа была написана для изделия "А", и полностью является собственностью предприятия, то она _должна_ быть использована в изделии "Б", если условия позволяют.



не все так радужно...

Во читайте и просвещайтесь
Embedded_systems_architecture.pdf

Архитектуру к коде на 40 Кб действительно найти трудно.
Это термин для техники посложнее с применением осей и строннего middleware.
Нынче для 32-х разрядных микроконтроллеров почти каждый разработчик IDE предлагает элементы собственной архитектуры.
Более того в разделе про ARM-ы большинство серьезных тредов затрагивают архитектуру, потому что это сверхважный вопрос.
Ошибешься в архитектуре и можешь потерять год а то и больше.

Просто архитектурой там это не называют, ну не знает народ что это так называется.

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

...еще сложнее с людьми которые застряли на Ассемблере и мотивируют это исключительностью Ассемблера.




На самом деле может повлиять. Дело в том что владение определенным языком накладывает отпечаток на логику мышления и соответственно способы и подходы к решению задачи. Это из личного опыта. Впрочем замечу что лингвисты говорят о том же. И потом применение goto во всем мире считается плохим тоном. При использовании языков высокого уровня пратически в любом случае можно избежать применения goto. А вот что касается Ассемблера, увы без goto он же jmp ни как. Но опять же Ассемблер не совсем язык.

Ясно как. Оператор goto может заменить все операторы цикла (for, do, while), а также множество вызовов функций. Если начать заниматься такими заменами, то структурированность программы пострадает, мягко говоря.
Я вижу только одно приличное применение для goto: выход из глубоко вложенного цикла. Кстати, кажется в Java специально для этого несколько расширили функцию оператора break по сравнению с Си.

Ну почему же.
За goto в С-и прочно закрепилась одна утилитарная функция - это переход к exit point в функциях с обязательным эпилогом, например с освобождением памяти.
Большинство юзают это часто и с удовольствием.

Еще одна - в protothread под GCC. Замена switch(pc) на

Да и вообще при мультитредовом программировании без идина goto - никуда

Проектирование ПО для микроконтроллеров: RUP + UML. И это работает

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

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

Да точно, в кооперативных механизмах многозадачности без goto невозможно обойтись ибо нельзя трогать стек.

Если говорить об первоначальной теме топика, не углубляясь в личные предпочтения каждого программиста (кому-то удобнее писать используя одни функции языка, другому - другие, программы обоих могут быть одинаково эффективны). Я так понимаю, автора интересовал вопрос о грамотном написании встраиваемого ПО. Чтож, о том, что эта область не затрагивается - убеждение ошибочное, просто она не столь широко освещается. В общем и целом проектирование ПО для МК аналогично тому же для ПК, с некоторыми исключениями, например необходимостью учитывать особенности аппаратной платформы и т.п. Есть и литература по данному вопросу, первое что пришло на ум - Ален И. Голуб, у него есть несколько работ по данной тематике, но к топику наиболее подходит его книга "Веревка достаточной длинны, чтобы... выстрелить себе в ногу" (и название говорящее...).
Тут кто-то сказал, что печально слышать от программиста: "это очень сложно" и "этого в ТЗ небыло", а программисту по-вашему приятно слышать "о а давай-ка мы тут новую штуку добавим" или "ну мы думали что будет нормально, а нам не подходит - надо переделать". Вот строите вы дом, а к вам подходит заказчик и говорит: "Гм... что-то не то... а давайте мы вот тут на первом этаже дырку в стене прорубим и поставим большое окно!" сделать можно что угодно, вот только дом потом развалится. Тогда уже вопрос не в проектировании ПО а в управлении проектом в целом.
Возвращаясь к теме: сложно дать конкретную доктрину по проектированию ПО для МК, тем более не ясно какой именно аспект этого проектирования Вас интересует. Единственное что можно посоветовать: ищите, ищите и еще раз ищите. А лучше поучится у тех у кого большой опыт ведения проектов по разработке встраиваемых систем.

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

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

Прочитал весь топик (типа читал пэйджер - много думал). Как то грустно и смешно (простите).
Народ, а чего Вы повелись то? Автор топика возможно неплохой программист, но как организатор - в начале пути.
Речь свелась к технике. И ещё круче к несчастному оператору (не буду тут его в суе) При чём тут вообще это то?
Лично знаю более 10 языков, из них только азмы вызывают теплоту в душе. Наверное благодаря принципу - что сделано, сам дурак. И как то филолетово
кол-во чего то там. Есть красивые решения в технике программирования - вот их и применять нужно.
И КАЖДЫЙ язык имеет свои СИЛЬНЫЕ стороны и КРАСИВЫЕ решения.
И из каждого можно сделать на несколько метров портянки блевотной массы. И чего?

А по теме:
Автор - не там ищите.
Я более того скажу - Вы задали вопрос который можно сформулировать немного по другому:
где взять технологию перехода(оптимального, менее затратного в ресурсах и т.д.) от пользовательской задачи к коду.
И так как это _технология_ то согласитесь - тут говорить о языке(оси, железе), мягко говоря - глупо.
какая технология - читайте популярную литературу. как говорится - всё придумано до нас

автору удачи - она Вам потребуется
(круглый)

Вообще-то на эту тему есть даже международные и отраслевые стандарты (поэтому это не наука, а технология производства), например прогуглите "ISO Standart for software life-cycle proces" или "DOD-STD-2167"

Эта штука хорошо сделана у буржуев, некий конвеер, которому все равно, чего разрабатывать. Для понимания, зачем надо и что получается, можно почитать "Совершенный код", Стив Мак-Коннел. Или поработать в конторе с CMMI-3 и выше

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

100%

to Dog Pawlowa: наверное здесь "КРАСИВЫЕ" = "НЕСТАНДАРТНЫЕ", "ЭФФЕКТИВНЫЕ"
P.S. Иногда гвозди затупляют именно для ЭФФЕКТИВНОГО забивания

Тут все зависит от количества гвоздей. Если задача хорошо продумано и найдено красивое решение, то "гвоздей" много меньше понадобится. И опять же, если всегда просто "тупо забивать гвозди", то красивые решения можно искать очень долго. Но если постоянно стремится к поиску красивых решений, то они находятся достаточно быстро. Мозги постоянно тренировать нужно. Или нет?