Это две большие разницы. Нельзя сравнить инфузорию с кольчатым червем по уровню 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 невозможно обойтись ибо нельзя трогать стек.