Доброго вечера. Предстоит проектирование довольно сложной системы, блок управление в который встраиваются различные модули (NB-IoT, LoRa, GSM, RS-485, Ethernet и т.д.) + разные датчики с которых нужно будет получать данные. Прежде чем ввязываться проектировать платы и организовывать написание кода, хочется получше проработать структуру комплекса и методику взаимодействия всего этого добра. С каждым модулем до этого так или иначе работал, а вот всё вместе в одном проекте применять не приходилось. Буду благодарен, если посоветуете умные книжки, которые помогут понять, как лучше проектировать подобные системы и каких паттернов программирование лучше придерживаться.
Комментарии: 32
Linxuil
А как вы это прогать будете? На основе голого железа или с операционной системой?
Fait
Пока выбор пал на FreeRTOS.
Thorn
как все это выглядит конструктивно? шина + дочерние платы? или что значит "модули" — готовые с али, что ли?
Fait
Корпус, внутри назовём условно материнская плата с "жирным" микроконтроллером, NAND Flash памятью, BLE и резервным аккумулятором. В этой плате разъёмы для подключения модулей, модули проектируются под эту плату.
Andrey
Вы щас про raspberry?
Thorn
> разъёмы для подключения модулей универсальные или для каждого свои?
Andrey
Под нее вполне себе проектируются навесные платы
Fait
Нет, raspberry там избыточна, плюс устройство планируется как автономное, хоть и с достаточно ёмким аккумулятором. Планируется что да, разъёмы в мат. плате для подключения модулей универсальные.
Linxuil
Ну и кстати, отладка и тестирование с posix будет куда проще в итоге делать
Andrey
Pi Zero достаточно компактен, а избыточность его вычислительной мощности - это упрощение разработки пользовательской части софта
Thorn
хотя бы какой-нибудь SoM в SO-DIMM формате посоветовали, а не это ардуино... и еще с температурным диапазоном, какой нужен в данном случае
Fait
Спасибо рассмотрю этот вариант. На первый взгляд выглядит интересно. С подозреваю, что pi-zero или Compute Module будут слишком много кушать.
Linxuil
У compute module есть большие требования к питанию, минимум 1.5 -2.0 ампера блок питания, если меньше будет, то не стабильно работает и иногда перезагружается) Особенно это выражается при раьоте его беспроводного модуля
Thorn
блин, если так нужен линукс, есть же ebmedded SoC типа mp1 или am33xx
Linxuil
Но штука удобная
Thorn
зачем пихать туда мультимедиа процессор?
Andrey
Можно тактовую придавить для экономии...
Fait
Всё-равно со спящим микроконтроллером raspberry тягаться не сможет. Для другого создавалась.
Thorn
короче, на каждой дочерней плате у вас будет микроконтроллер. нужно спроектировать стандартную шину, протокол совместного доступа к ней, enumeration протокол
Linxuil
Есть ос реального времени posix совместимые, тот же nuttx. Или легкую версию линукса поставить. Вы так себе кучу времени и нервов сэкономите и сможете таскать примеры и структуру драйверов
Fait
Спасибо за совет, почитаю об этой ОС. Только насчёт энергопотребления не уверен. Устройство будет кушать аккумулятор, сетевой блок питания не всегда доступен.
Linxuil
Nuttx может и будет съедать немного больше энергии и ресурсов, но вопрос еще во времени разраьотки по и возмодности его написания на обычном пк и потом переноса на мк. В случае простых устройств этотне критично, светодиодом там помигать или двигателем поуправлять, пакеты попередавать. Но если писать кучу софта и кастомизировать драйвера, то подход с posix мне кажется более выигрышным даже если устройство бцдет работать 5, а не 6 часов, зато код будет написан быстрее и качественее. Плюс можно будет при сьорке выбирать в настройках какой драйвер вы хотите соьрать. Там сборка удоьная жутко, плбс под nuttx хоть это и posix есть порты на многие мк и есть куча драйверов уже написаных. Возможно вам и писать меньше прийдется.
Kaktys
страшные слова : Requirement engineering, SysML, архитектура аппарата и проекта
Fait
Спасибо за совет.
Serg
Главная ошибка, которую можно тут совершить - делать это все на С, тут только C++, объектная модель и много-много автоматических тестов
Fait
Спасибо за совет, в сторону Си даже не смотрел, как вы и сказали, только С++, хотя чаще всего прошивки писал на Си.
Thorn
простите, если что не так, но я такие сообщения читаю всегда как "я не знаю, как это сделать на С, поэтому и ты ни в коем случае не делай на С!"
Serg
Я знаю как на том и другом, но возможностей создания нормальной модели в С++ намного больше
Serg
Работа с железом обычно это небольшая часть проекта, да, абстрагировать в HAL и будет все ок. А чего вы так боитесь C++?
Serg
Ну это во первых удорожание, во вторых не каждый DC/DC справится с такой емкостнеой нагрузкой А чем продиктована именно модульность? Как это будет выглядеть в реальности - под каждый заказ будет собираться своя плата из нужных модулей?
Fait
Сам чаще всего пишу на Си, но тут действительно проще на С++, упаковать всё в классы и рулить через них. Вспоминаются времена, когда писал моды для игры Half-Life, исходники основных библиотек (client.dll, hl.dll) были под сотню мегабайт (может быть больше), но благодаря С++ и понятной структуре, можно было довольно быстро разобраться и через небольшое время уже добавлять новых существ, оружие, энтити, менять AI и эффекты. Под разные задачи своя плата, при необходимости расширения возможностей, и наличия свободных слотов можно будет добавить новый модуль.
Serg
Ну да, в большом проекте из-за недостатка абстракции в C все лезет наружу как тесто из кастрюли. И начинается изобретение на C структур, хендлов и прочего чтобы все было это хоть как-то управляемо.