Кто знает литературу по профессиональному программированию микроконтроллеров?

Довольно давно имею дело с микроконтроллерами. Начинал с ардуино, после на голый avr и stm32. В stm32f103 уже имел дело почти со всей периферией, разве что не трогал usb и flash. Решая крупные задачи очень часто не знаю как лучше подойти к проблемам. После делаю все на костылях и при необходимости расширения функционала приходится все переделывать. Всегда есть желание делать код(библиотеки или модули) универсальными, что бы потом это можно было легко перенести на другой проект или платформу, но, опять же, не всегда есть идеи как это сделать. Может кто знает литературу по подходам проектирования приложений для МК или что-то в этом роде. Просто слабо верится что все всегда пилять с нуля и в лоб(ибо как по мне у современных МК хватает ресурсов крутить универсальный код в большинстве задач).

UPD
Могу описать текущую проблему. Есть задача организовать коммуникацию через RS485(полудуплексный). В сети есть один мастер, который делает запросы слейвам. После запроса слейв с соответствующим ID разбирает запрос, генерить ответ и отвечает его мастеру. В плане настройки переферии все сделал и отладил. Оформил как либу. Но есть один ньюанс. Обработчик запросов и генератор ответов. Для каждого устройство это должно быть что-то свое. Как это красиво оформить? Что бы не ломать код уже существующей либы? Просто хотелось бы увидеть пример решения такой проблемы от ПАПКИ программинга микрух. Я могу неправильно выражаться, но мене кажется что это проблема выстраивания архитектуры приложения. Помимо таких проблем иногда сталкиваюсь с такой проблемой что не знаю чем лучше воспользоваться: все повесить на прерывания или цикличный обработчик и руками прописывать последовательную обработку(задача решалась в реальном времени не на RTOS(до нее еще руки не дошли))
  • Вопрос задан
  • 3215 просмотров
Решения вопроса 1
@rustler2000
погромист сикраш
Знатный апдейт. Разрывает вопрос на две проблеммы не связанны с uC. Вообще программирования uC это просто обычное программирования с дополнительными ограничениями по памяти, хипу, стэку и производительности. Ну да какбэ чтото особенное изза того что нужно знать хоть немного микроэлектронику. Но реально - ничего особенного. Конечно не мешает знать во что превращяется твой код.

Книжно по архитектуре - любые. Хоть блин design patterns :D
Тяжело абстрактные книжки читать - читай код u-boot/netbsd/linux - смотри как там сделанно. Применительно к твоей проблеме с шиной 485 - там полно пробинга и детектов всякой переферии. Ближайший аналог естественно будет USB. Простейшие стэки для USB есть в природе на посмотреть. API стэка можешь скопировать, чтоб либа похожа была.

Про прерывания vs poll - это cам разбирайся с требованиями - soft rt у тебя или hard rt. Может у тебя по требованиями вообще лупы нельзя будет делать и надо линейно отрабатывать с ресетом в конце. И конечно посмотри FreeRTOS - хотябы сколько чипов он поддерживает :D
Ответ написан
Пригласить эксперта
Ответы на вопрос 5
longclaps
@longclaps
Боже мой: 17 часов прошло, 16 чел. подписались на вопрос, и ни одного ответа.
Моё сердце разрывается от сострадания.
Возьмите.
Ответ написан
bullitufa
@bullitufa
электронщик программист (микроконтроллеры и PC)
По основной теме вопроса: сам мучаюсь, но мучаюсь только по тому что "не умею" программировать. То что нужно продумывать архитектуру с самого нала - это в некоторых случаях крайне рекомендательно. У нас разрабатывается несколько устройств - приходится писать общие библиотеки. Приходится писать достаточно гибкие библиотеки - иначе переписывать приходится!
Как показала практика очень часто встречаются указатели на функции, стейт машины, операционки (freertos, chibios и т.д.) и т.д. Отличным подходом (имхо) буде написание низкоуровневых (HAL от stm32) и высокоуровневых функций (modbus, canopen и т.д.). Вот эти вещи посмотрите как делают.

По вопросу реализации коммуникации по рс485: если протокол отличный от модбаса, но похож - посмотрите на библиотеку freemodbus.

Сейчас тихонько пытаемся внедрить тесты. Есть отличная книжка на английском (переводов не встречал): we.easyelectronics.ru/Nemo/tdd-dlya-embedded.html - там же ссылка на эту книгу.
Чем хорошо писать "под тесты"? Тем что писать каждую функцию приходится думая, а бы как не напишешь. Короче видим плюсы в этом!
Удачи!
Ответ написан
peacefulatom
@peacefulatom
День добрый!
Код мастера и слейва пишете Вы? Тогда организуйте между ними обмен по протоколу Modbus - специально созданному для таких систем и широко применяемому в SCADA. Он предполагает регистровую организацию данных в датчике.
Могу посоветовать ещё лёгкий вводный курс в планировщики RTOS:
https://www.coursera.org/learn/real-time-systems
Книжку порекомендую такую: Руководство по микропрограммному обеспечению, Дж. Ганссл. Прочитал несколько глав, на мой взгляд, толковая.
dmkpress.com/catalog/computer/programming/978-5-97...
Ответ написан
Комментировать
@apro
Обработчик запросов и генератор ответов. Для каждого устройство это должно быть что-то свое. Как это красиво оформить? Что бы не ломать код уже существующей либы?
но мене кажется что это проблема выстраивания архитектуры приложения.


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

В вашем случае принято делить код отвечающий за связь на слои(
По-моему очевидное решение слещующее принципу открытый/закрытый и
реализовано в куче протоколов и framework):

Слой абстракции от железа / Слой передачи "байтиков" (включая ID устройств,
т.е. запаковку массива байт в пакеты с ID, возможно полем длина и контрольная сумма) / Слой умеющий как-то сообщать о приходе новых данных (например callbacks).

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


Помимо таких проблем иногда сталкиваюсь с такой проблемой что не знаю чем лучше воспользоваться: все повесить на прерывания или цикличный обработчик и руками прописывать последовательную обработку(задача решалась в реальном времени не на RTOS(до нее еще руки не дошли))


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

Войдите, чтобы написать ответ

Похожие вопросы