В объектно-ориентированном подходе к программированию выделены шабоны проектирования и программирования - это типовые схемы решения часто встречающиющихся задач.
почитать можно в книге Э.Гамма, Р.Хелм, Р.Джонсон, Дж.Влиссидес "Пирмемы объектно-ориентированного поектирования. паттерны проектирования" изд-во Питер. отзывы можно прочесть тут http://www.ozon.ru/context/detail/id/24573...type=4#comments

А теперь вопрос: есть ли подобная книга в отношении программирования для микроконтроллеров? Например , сборник шаблонов об измниерении промежутков времени на мк, ввод-вывод. ,многозадачность.
Про управление задачами и памятью можно читать Э.Таненбаума "Современные операционные системы" но хотелось бы с учетом ОСРВ и под мк.
Хотелось бы услышать ваше мнение по этому вопросу.

А теперь информация: Мой первый персональный компьютер IBM PC был с восьмибитовой памятью и работал на тактовой частоте 4,7MHz. Как это соотносится с нынешними микроконтроллераими? Специальные "чернила для 6 класса" не нужны. Просто учитесь программировать, а с шаблонным мышлением еще и бороться придется.

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

А в целом - перспективные подходы к программированию перспективны и на МК

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

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

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

Читайте Application Notes для данного семейства МК, читайте общую документацию по программированию / схемотехнике. Читайте специализированные форумы - очень много тонких мест и интересных решений обсуждаются.
В общем, единого пути нет - каждый выбирает его сам, исходя из возможностей, требований и желаемого результата

спасибо за ответы, так и делаю

Неделю назад была попытка обсудить подобную тему.
http://electronix.ru/forum/index.php?showtopic=71401
Все же паттерны - это средство высокоуровневого проектирования. Т.е. для начала в проекте такая необходимость должна присутствовать изначально, как минимум. Определенная часть паттернов из упомянутой книги вполне может быть применена и при проектировании встроенных систем. К примеру, если ваш проект должен поддерживать различные аппаратные платформы ( или к примеру симуляцию на вин/лин ), для разделения зависимых частей может быть использован паттерн мост. Ваши коллеги, понимающие паттерны, смогут легко распознать и повторно использовать независимую часть кода и добавлять новые платформенно (целе и вообще любые *зависимые) части кода как в текущий проект, так и в другие.
И разумеется, для применения паттернов необходима определенная мотивация. Отсутствие оной(к примеру зп платят за кол-во строк в проекте или 30-летний опыт проектирования подсказывает, что это ерунда :o) не значит, что "шеф, все пропало", девелопер сделает то же самое по другому.

=======================================================
Страдающим повышенной возбудимостью, аллюзиями и т.п.ч. сообщаю, что вышеизложенное есть мое личное мнение, базирующееся на личном опыте. Ни в коем случае не претендую на истину в последней инстанции.

нашел близкое к моему вопросу:
http://www.eventhelix.com/RealtimeMantra/Patterns/


to zltiqo: соглсен, нужно самому думать, но часто разработчики( да и не только они) занимаются изобретением велосипедов.
Я пришел к такой идее: думать самому, но обязательно смотреть по сторонам, смотреть как другие решают похожие задачи.

ИМХО, для оглашенных задач шаблоны не только не нужны, но и избыточны практически во всех отношениях.
Оверхед(как по времени CPU, так и по загрузке мозга программиста) от их использования для таких задач может быть сравним с самой задачей.
Вопрс: зачем ноутбуком забивать гвозди, когда есть молоток?

В теме, имхо, присутствует путаница. Автор, видимо, имеет в виду паттерны проектирования, если иметь в виду его ссылку на книгу по этим вещам. А термин шаблоны программирования используется тут некорректно. Шаблоны программирования есть в некоторых ЯП - например, в С++, но речь, видимо, не о них.

Что касается оверхеда, то все зависит от задачи. При правильном использовании всего этого хозяйства оверхеда либо нет, либо он приемлемо мал. Это касается и шаблонов того же С++, и паттернов проектирования. Например, если нужен по смыслу паттерн Singletion, то никуда от этого не уйти. И получается достаточно красиво. И оверхеда там нет по сравнению с реализацией этого иными способами (все они так или иначе похожи). Паттерны проектирования - это не какие-то языковые средства, а приемы реализации тех или иных типовых задач. Т.е. это по уровню абстракции стоит выше средств ЯП.

dxp уловил суть вопроса...

Сами то книжку читали? Издана в 2001 году. За такое время целые поколенния микроконтроллеров ставят и снимают с производства.
Чем автор книжки занят поняли?
Он узко заточенный профессионал.
Это как если б эмбеддер делающий только частотомеры написал о патернах разработки для всех встраиваемых систем.

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

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

вот нашел.. может кому пригодится
book of Michael J Pont "Patterns for Time-Triggered Embedded Systems"
скачать можно тут:
http://www.tte-systems.com/books/pttes

Офигеть, 1000 страниц только про одни I51-е.
А вы книжки те что предлагаете сами то читаете?



Она была издана в 2001 как раз на закате 51-х.
И кооперативные операционки того типа доживали последние дни.
Теперь ее смело можно фтопку.
Большая часть книги не актуальна даже для студентов.

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

Занялся вопросом со стартом топика. Всё, что удалось понять самому - MISRA-C - мне пришелся по душе запрет рекурсии, со ссылкой на C99 (C99 советует её избегать). Но это совсем не шаблон, а рекомендации кодерам. Две более абстрактные доки "MISRA Development Guidelines For Vehicle Based Software" и "CEI IEC 61508 3" я почти не понял, но выкладываю, потому как встретил много ссылок на них во всяких рекламных брошюрах, а выкачивались они много дней ослом.

Последнее издание 2009года. Построение простых осей (с одним аппаратным прерыванием) неплохо описано.
А 51-ые взяты только для демонстрации.
А Вы сами то что написали чтобы так сразу да в топку ?

Титан!
Только это имеет спорное отношение к паттернам, скорее просто ограничивает синтаксис.

Реалтаймовость большинства встроенных применений, причем чаще всего уникальная для каждого проекта, в сочетании и уникальными ресурсами в каждом проекте, делает применение паттернов весьма ограниченным.
Не стоит забывать наблюдаемое развитие систем с автоматическим конфигурированием и автоматической генерацией низкоуровневого кода (например, для Cypress PSoC3/x51 PSoC5/CortexM3 ).