109
Karma
17
Global rating
Анатолий @RyabovA
User
Information
- Rating
- 433-rd
- Location
- Саратов, Саратовская обл., Россия
- Registered
- Activity
Specialization
Chief Product Officer (CPO), Systems Analyst
Lead
Project management
Development management
Agile
Optimization of business processes
Negotiation
Automation of processes
Presentations
Project planning
Information Technology
Strategic planning
Да уж :-) наверное это тот случай, где лучше англоязычные аббревиатуры применять.
Хотя может это и есть цифровая радио-электроника и просто радио-электроника? Есть радиотехника, есть цифровая техника и электроника, а вот когда они начали совмещаться, то появилась цифровая радиотехника и SDR это просто один из вариантов модульного решения для создания устройств цифровой радиотехники. Есть ощущение, что так, если поднимать вопрос используемой терминологии :-)
Сайт проекта Repka Pi https://repka-pi.ru/
Каталог доступных моделей тут, для подготовки статьи вот эту модель применяли, добавив к ней EMMC модуль там же в каталоге, с EMMC быстрее чтение/запись, да и просто надёжнее, на малинах нет EMMC на самой плате, только через дополнительные шилды или переходники.
В теории да, но это не точно, всё нужно проверять. Т.е. могут быть специфичные вопросы установки, ответы на которые Вам придётся самому искать, если Вы опытный линуксоид и в разных дистрибутивах, в т.ч. для малины, ориентируетесь, то всё ок. Как в целом и любой компьютер, десктоп или ноутбук, но могут быть ньюансы и большие вопросы с помехами, это может помешать на первых порах, пока опыта не наберётесь. Первые шаги лучше начать на одноплатнике с русскоязычной поддержкой и сообществом, у Репки оно есть и достаточно зрелое на сегодня, смогут помочь с вопросами и точно эксперименты будут успешными. Если тема Вам зайдёт и захотите развиваться в ней, то сами уже будете пробовать и разные одноплатники и SDR модули.
В принципе ДА. На практике это будет зависеть от SDR приёмника - от чувствительности его радиочастотного контура и, конечно же, и от разрядности АЦП. Тут же нужно понимать, что доплеровский эффект для изменения длин волн на скорости звука это одно, а на скорости распространения радиоволн (т.е. на скорости света, ну точнее почти, ещё и нужно учесть её изменение в атмосфере) это другое. И конечно нужно знать базовую частоту/период, от которой определяем смещение. А в целом да, принципиально это возможно и так можно много чего программно придумать чтобы измерять.
Что касается Старлинка, то просто нужно понимать, что спутниковая связь это всегда СВЧ, так как именно такие высокие частоты не отражаются от ионосферы. Вот справка по их частотам - по состоянию на 2025 год спутники Starlink работают на трёх частотах:
Ka-диапазон с сантиметровыми длинами волн — от 26,5 до 40 ГГц.
Ku-диапазон с сантиметровыми длинами волн — от 12 до 18 ГГц.
E-диапазон с миллиметровыми длинами волн — 71–76 ГГц (в прямом направлении) и 81–86 ГГц (в обратном направлении).
Т.е. это потребует соответствующих по диапазоном приёмников. А в принципе по такой же технологии SDR сам старлинк и работает, скорее всего.
Продолжение будет :-) в т.ч. с учётом поступивших предложений.
Вроде не противоречит. Насчёт верности и логичности такого позиционирования принято, нужно подумать и осмыслить ещё раз. По раскрытию тем с DT и драйверами - обязательно сделаем такой материал, собравшись с силами, есть прекрасные материалы об этом по отдельности, а вот связку полезно показать тем кто только переходит на этот уровень. Спасибо за поднятые вопросы и замечания.
Сударь, извольте перестать разговаривать в таком тоне, скрывая за высокоменрными плохо прикрытыми оскорблениями свои поучения. Иначе я вызову вас на дуэль :-) Наверное так ответ бы звучал двести лет назад. Сейчас же нужно говорить иначе :-) Но я против бранных слов. Так что так - зря вы в таких выражениях и в таком духе пытаетесь донести свою мысль, вы ошибаетесь в своих предположениях. По существу же вопроса ваша мысль понятна.
Сборка системы никому ничего не должна, специально узнавал ;-) а кому была должна, всем всё простила.
По существу же Ваших предложений - обучение сборке системы штука хорошая, спору нет, но, на мой взгляд, не для базового уровня и не для домашних проектов, это, скорее, более профессиональная задача и предмет отдельного материала и даже, возможно, без привязки к конкретным проектам (только если это не пример, когда для работы проекта нужно своё уникальное дерево устройств и/или специфичный загрузчик). В начале данной статьи специально сделан акцент на базовый уровень и на то, что это конкретный учебный пример функционала. Возможно используемый термин "embedded-разработка" создаёт ожидания в т.ч. про подготовку прошивки. Понятие embedded-разработка понятие широкое и многоуровневое. Задача оптимизации кода по производительности в соответствующем разделе затронута, кстати говоря.
Тоже давно думал про создание отдельных статей по DT (в т.ч. с оверлеями) и примерами настройки под конкретные устройства и, что важно, с заходом в тему создания драйверов как модулей ядра для своих периферийных устройств. План написать такую статью есть, материалы с примерами есть. А может и Вы предложите свой вариант раньше, раз видите такой недостаток в имеющихся статьях, было бы на самом деле очень здорово.
Что касается более четкого обозначения целевой аудитории и очерчивания круга затрагиваемых вопросов и задач - с этим понятно, такое замечание принято, будем учитывать. Но стоит ли вообще подобные материалы готовить и публиковать или это ненужная трата времени подобные материалы не имеют ценности на Ваш взгляд?
Принято, и подумаем и будем работать в этом направлении.
Строго говоря вот что ИИ поисковика выдал на запрос "что такое домашняя метеостанция"
Домашняя метеостанция — это устройство для мониторинга микроклимата в доме и окружающей среды, помогающее предсказывать погодные условия. Оно совмещает функции термометра, гигрометра, барометра, а иногда — датчика качества воздуха. Современные метеостанции оснащают сенсорами, которые собирают информацию, и дисплеем или мобильным приложением для удобного отображения данных.
Т.е. в этом минимальном объёме пример и показан - есть датчики базовых показателей и есть монитор для вывода информации.
Остальное конечно прикольно сделать - отправка информации, расширенный набор датчиков (особенно если добавить датчики газа, горючего и угарного, например), добавит сигнализирование о выходе параметров за заданные граница и т.д. Но это уже, наверное, то что можно фантазировать почти до бесконечности и то, что можно делать по аналогии самостоятельно, расширяя и улучшая базовый пример.
Тогда понятно о чём вы говорите - чтобы сделать полноценный продукт, т.е. что то типа домашней SCADA на одноплатнике или корпусной вариант метеостанции на контроллере. Тогда это будет не статья, а учебник и не для старта, а уже как профи-мастер класс для студетов старших курсов технических вузов или практика начинающих карьеру специалистов. В данной статье ставил задачу немного иную - когда уровень проекта начального среднего уровня, когда можно самому или с ребёнком позаниматься и есть поле для самостоятельного творческого развития - добавить вебку для вывода данных, добавить отправку данных по смс или в телеграм, добавить исполнительные механизмы и т.п.
А тут странное дело получается - пришёл после работы в пятницу и до глубокой ночи писал статью на базе ранее имевшихся образовательных наработок, чтобы сделать кому то может быть полезный материал на выходные. И потом налетают профессиональные комментаторы и критики, причём больше всего критикуют те, кто сам ни одной статьи не написал почему то.
В целом если среди этой критики выбрать конструктивные предложения и пожелания, то они вот такие, видимо - показать интеграцию с Веб интерфейсом для вывода дынных, добавить систему оповещения по СМС и через телеграм-бота, показать аналогичную реализацию на контроллере, корпусизировать исполнение на контроллере для получение законченного устройства, связать контроллер с одноплатником, сделать на одноплатнике сервер приложения для настройки и вывода данных, добавить датчиков и исполнительных механизмов, добавить помимо "метеостанции" ещё устройств разного назначения и связать всё это в единый центр управления "умным домом" на базе одноплатника.
Рекомендации и пожелания в таком виде понятны, попробуем сделать такой цикл в качестве продолжения к данному материалу. Понятно, что это изобретение велосипеда, так как есть прекрасные готовые решения типа Home Assistent со шлюзами и датчиками и энергосберегающем протоколе Zigbee , но тут обучающая задача чтобы делать своими руками и осваивать технологии, в т.ч. сквозные. Если интересно такое продолжение - пишите! Хотелось бы понять, нужно ли и интересно ли это кому то, чтобы понять, стоит ли тратить на это время и силы.
Как выше уже сказал @randomsimplenumber читайте datasheet и проверяйте, если не будет как нужно, то не пользуйтесь этими процессорами и контроллерами :-) или тогда уже делайте свою подтяжку, а если соответствует, то Ок, в данном случае соответствует и потому схема в проекте статье тоже нормальная и потому, собственно, всё работает без нареканий. Но в целом то маслом каши не испортить :-)
У контроллеров и у процессорных систем есть свои достоинства и недостатки. Выбор стека может быть разный в разных задачах. В любом роутере сейчас стоит процессорная система с Linux на борту, работает годами и законченное устройство. При этом качественно другой уровень возможностей. Другое дело, что энергопотребление повыше и это не везде подходит, а так же у процессорных систем и у контроллеров всё же разные итоговые стоимости в продукте. И это не Хорошо и не плохо, это разные инструменты и работать нужно уметь и с тем и с тем. И этот материал для старту обучения работе с процессорными системами. Что касается Linux для embedded систем - да вот хотя бы Вам пример российского проекта NapiLinux вот сайт проекта
https://napilinux.ru/
загружается за три секунды, поставьте на EMMC, настраивайте через Веб или через API, из коробки система обновлений. Цитата: «NapiLinux — минималистичная и отказоустойчивая Linux‑среда, оптимизированная под встраиваемые устройства с ограниченными ресурсами и длительным сроком эксплуатации.» И есть другие варианты, просто этот Российский и портирован на Repka Pi.
Я не газую только за одноплатники или только за контроллеры. И то и то прекрасно может решать свои задачи. Тут вопрос скорее погруженности и как ручки из плеч растут и каким местом инженеры думают. Реально хороший embedded разработчик должен одинаково успешно уметь работать и с тем и с другим. Просто с контроллерами порог вхождения ниже и потому тема изъезженная и хорошо раскрытая, а вот с процессорными системами уделяется меньше внимания и потому с автоматикой и робототехникой есть вопросы в промышленности в стране, нужно это исправлять и обучать, для этого данный материал и создан.
Так что как когда то говорили на одном известном радио - "если Вы не любите кошек, то значит Вы просто не умеете их готовить". Так что что тут спорить и холиварить. Нужно и на том и на том делать больше материалов и проектов, а где уместно, там вообще гибридные решения строить.
А ещё есть информация, что команда проекта Repka Pi собирается портировать на свои одноплдатники FreeRTOS, вот это будет пушка для встраиваемых проектов с потребностями и амбициями - разработка как на контроллеры, а производительность и возможности одноплатников с многоядерностью и реальной многопоточностью только с настоящим real-time и плюшками в виде сети, большой оперативной памяти, хранилищем, мониторами, мышками и прочими клавиатурами из коробки. Но это уже другая история, будем посмотреть.
Всё верно, плюсую!
Читайте datasheet на матчасть и документацию на используемые библиотеки. Кстати, в документации к Repka Pi это всё есть, в т.ч. со схемами и ссылками на datasheet процессора и всего что в этом одноплатнике ещё применяется.
Спасибо Вам за отзыв по существу :-) Вы верно подметили - в таких материалах важно правильно выстроить структуру и подачу. Не всё идеально пока по части программной реализации, но для самостоятельного повторения, изучения и расширения уже достаточно. В ближайшее время доработаю эту часть статьи, чтобы было ещё удобнее и понятнее. Очень хотелось сделать материал понятным и хотя бы кому то полезным или для самообразования или для интересного проведения времени или для занятий с детьми.
Сейчас на многих микроконтроллерах и тем более на серьёзных микропроцессорах для всех портов ввода-вывода, как для I/O и тем более для более высокоуровневых интерфейсов типа I2C, в т.ч. использующих дифференциальные пары, обязательно реализуется внутренняя подтяжка в самом. Более того, в портах I/O для комплексных интерфейсов (GPIO) для уровней напряжения задаются програмно явно или используются значения по умолчанию логических значений 0 (Pull-Down) и 1 (Pull-Up). Есть, конечно, порты у которых есть третье значение - на низком уровне для управления через регистры это GPIO_PuPd_NOPULL — значение, которое означает «нет подтяжки», то есть нет ни pull-up, ни pull-down, это бывает по какой то причине нужно по замыслу разработчика, особенно если как раз реализуется своя схема с большими токами или с разными уровнями напряжений логических значений и нужно делать свои подтяжки и преобразования уровней или ещё какой то хитрый замысел разработчиков проекта. Но это и не на всех портах есть и нужно смотреть значения по умолчанию для конкретных портов и на то, как реализовано в используемых библиотеках в момент их инициализации и установки состояния портов перед началом работы.
Т.е. в современной цифровой электронике, особенно именно микропроцессорной, т.е. на одноплатных компьютерах, данный уровень абстракции давно выделяется отдельно на уровне реализации контроллеров портов как IP-блоков процессора/контроллера или на уровне реализации драйверов и/или библиотек, предоставляющих API для взаимодействия с портами и интерфейсами. Задача цифровой электроники - предоставить возможность сосредоточится на решении высокоуровневых задач, компоновке и логике алгоритмов работы, а не схемотехнических решениях на уровне электротехники. Вот если Вы поставите задачу написать статью и обучать разработке на уровне транзисторной логики (ТТЛ), показать как делать логические элементы на транзисторах или на логических элементах, создавай свои порты ввода-вывода и реализуя для них обвязку в т.ч. с подтяжками, то тогда да, нужно про это рассказывать и показывать на схемах, но это задача другая и она или про базу или про сложные гибридные проекты, где логика частично реализуется на своих аппаратных схемах и только уже принятые ей решения передаются портам контроллеров и процессоров. И это уже точно не про embedded разработку, а про схемотехнику. Данный же материал а) про mbedded-программирование и б) для старта и изучения разработки встроенных решений с упором на программную часть реализации. Так что если бы Вы выразили замечания по структуре и полноте материала в части программной реализации - с Вами можно и нужно было бы согласиться, так как вижу, что эта часть материала тяжеловата и не достаточно чётко структурирована и для новичков вообще нужно добавить кое какие справочные данные и дополнительные инструкции. И это будет сделано в формате редактирования и расширения материала, но сейчас как есть, хотелось к выходным успеть опубликовать, может кто то задумает провести выходные с познавательным проектом сам или вместе с детьми.
На такую задачу лучше взять не Repka Pi 3, а Repka Pi 4, она не греется и в корпусе без охлаждения с такой задачей будет работать долго и счастливо как отдельное устройство на дальней полке :-)
В РФ Репку применяют два производителя в своих ПЛК и ещё один применяет Малину (это Овен). Видимо есть на них испытания в т.ч. на одноплатники в их составе.
Так что для начального сегмента ПЛК такой подход не просто подходит, а уже несколько лет активно применяется и показал свою эффективность, сделав возможным заполнить сегмент базовых ПЛК с доступной стоимостью и профессиональным функционалом.
Конечно на объекты критической инфраструктуры ставят другие ПЛК - понятно, что более специализированные решения строятся и на специальных платах, но это уже и другой бюджет и другая стоимость.
У каждой задачи свои требования по надёжности, безопасности и т.д. и свои инструменты и способы для решения и свои бюджеты. Так что предлагаемый подход вполне рабочий, просто для определённого сегмента задач.
В РФ Репку применяют два производителя в своих ПЛК и ещё один применяет Малину. Видимо есть на них испытания в т.ч. на одноплатники в их составе. Понятно, что более специализированные решения строятся и на специальных платах, но это уже и другой бюджет и другая стоимость.
На Хабре почему то часто комментарии уходят совсем в другую сторону от сути материала статей.