Comments 26
Когда вместо Arduino Nano берут целое Raspberry - вызывает искреннее удивление.
Электрическая принципиальная схема проекта
Подключение по i2c без подтяжки?
Подтяжка, скорее всего, внутри датчика.
Это фиговое решение. Подтяжка всегда должна быть внешней.
А если устройств несколько? Это же шина. В автомобилях CAN последних лет так же организован, правда не подтяжка в каждом устройстве, а терминатор убрали. И это привело к тому, что с надёжностью стало очень плохо. И использовать её полноценно как шину стало практически невозможно, что частично нивелировано наличием хаба. Т.е. CAN придумали, чтобы избавить автомобили от километров проводов и разъёмов размером с кулак, но к тому и вернулись. В новой итерации решили перейти на Ethernet. Но и его найдут как испоганить.
Сейчас на многих микроконтроллерах и тем более на серьёзных микропроцессорах для всех портов ввода-вывода, как для I/O и тем более для более высокоуровневых интерфейсов типа I2C, в т.ч. использующих дифференциальные пары, обязательно реализуется внутренняя подтяжка в самом. Более того, в портах I/O для комплексных интерфейсов (GPIO) для уровней напряжения задаются програмно явно или используются значения по умолчанию логических значений 0 (Pull-Down) и 1 (Pull-Up). Есть, конечно, порты у которых есть третье значение - на низком уровне для управления через регистры это GPIO_PuPd_NOPULL — значение, которое означает «нет подтяжки», то есть нет ни pull-up, ни pull-down, это бывает по какой то причине нужно по замыслу разработчика, особенно если как раз реализуется своя схема с большими токами или с разными уровнями напряжений логических значений и нужно делать свои подтяжки и преобразования уровней или ещё какой то хитрый замысел разработчиков проекта. Но это и не на всех портах есть и нужно смотреть значения по умолчанию для конкретных портов и на то, как реализовано в используемых библиотеках в момент их инициализации и установки состояния портов перед началом работы.
Т.е. в современной цифровой электронике, особенно именно микропроцессорной, т.е. на одноплатных компьютерах, данный уровень абстракции давно выделяется отдельно на уровне реализации контроллеров портов как IP-блоков процессора/контроллера или на уровне реализации драйверов и/или библиотек, предоставляющих API для взаимодействия с портами и интерфейсами. Задача цифровой электроники - предоставить возможность сосредоточится на решении высокоуровневых задач, компоновке и логике алгоритмов работы, а не схемотехнических решениях на уровне электротехники. Вот если Вы поставите задачу написать статью и обучать разработке на уровне транзисторной логики (ТТЛ), показать как делать логические элементы на транзисторах или на логических элементах, создавай свои порты ввода-вывода и реализуя для них обвязку в т.ч. с подтяжками, то тогда да, нужно про это рассказывать и показывать на схемах, но это задача другая и она или про базу или про сложные гибридные проекты, где логика частично реализуется на своих аппаратных схемах и только уже принятые ей решения передаются портам контроллеров и процессоров. И это уже точно не про embedded разработку, а про схемотехнику. Данный же материал а) про mbedded-программирование и б) для старта и изучения разработки встроенных решений с упором на программную часть реализации. Так что если бы Вы выразили замечания по структуре и полноте материала в части программной реализации - с Вами можно и нужно было бы согласиться, так как вижу, что эта часть материала тяжеловата и не достаточно чётко структурирована и для новичков вообще нужно добавить кое какие справочные данные и дополнительные инструкции. И это будет сделано в формате редактирования и расширения материала, но сейчас как есть, хотелось к выходным успеть опубликовать, может кто то задумает провести выходные с познавательным проектом сам или вместе с детьми.
Правильный ответ - читайте datasheet. Там есть и про значение подтяжек в зависимости от скорости, и про величину встроенных подтяжек.
Всё верно, плюсую!
Читайте datasheet на матчасть и документацию на используемые библиотеки. Кстати, в документации к Repka Pi это всё есть, в т.ч. со схемами и ссылками на datasheet процессора и всего что в этом одноплатнике ещё применяется.
Только встроенная подтяжка не всегда соответствует той, что должна быть по стандарту
Прелесть современной электроники - она, сцуко, выносливая.
Как выше уже сказал @randomsimplenumber читайте datasheet и проверяйте, если не будет как нужно, то не пользуйтесь этими процессорами и контроллерами :-) или тогда уже делайте свою подтяжку, а если соответствует, то Ок, в данном случае соответствует и потому схема в проекте статье тоже нормальная и потому, собственно, всё работает без нареканий. Но в целом то маслом каши не испортить :-)
Спасибо за проделанную работу! Как статья так и проект собраны на интуитивном уровне с идеальной последовательностью, приятно и удобно изучать. Будем попробовать. :)
Спасибо Вам за отзыв по существу :-) Вы верно подметили - в таких материалах важно правильно выстроить структуру и подачу. Не всё идеально пока по части программной реализации, но для самостоятельного повторения, изучения и расширения уже достаточно. В ближайшее время доработаю эту часть статьи, чтобы было ещё удобнее и понятнее. Очень хотелось сделать материал понятным и хотя бы кому то полезным или для самообразования или для интересного проведения времени или для занятий с детьми.
Во-первых, это проект для микроконтроллеров, а не для одноплатников. Ну а самое главное, что перейдя с микроконтроллера на одноплатник вы забыли сделать самое главное без чего проект никогда не станет законченным - разработка и генерация системы. На микроконтроллере система встроена в ваше приложение и есть много библиотек которые позволяют настроить IP адрес, сделать примитивный WEB интерфейс для управления, сделать обновление и в конце получить законченное устройство которое реально будет работать годами. Есть даже системы типа ESPHome которые позволяют забыть об этом и сосредоточится только на функционале. А на одноплатнике система отдельно, приложение отдельно. Для законченного устройства нужно чтобы основная система была только для чтения (иначе вы убъете любой накопитель), если нужна сеть то требуется сделать систему управления по WEB и возможность настройки IP адреса, далее нужно удалить все не нужные сервисы и запустить свое приложение как сервис, ну и наконец продумать систему генерации образов и обновления. Без всего этого ваш проект на одноплатнике так и останется глючной недоделкой, требующей постоянного обслуживания по SSH. При этом не существует ни одной открытой реализации всего вышеописанного для одноплатников.
У контроллеров и у процессорных систем есть свои достоинства и недостатки. Выбор стека может быть разный в разных задачах. В любом роутере сейчас стоит процессорная система с Linux на борту, работает годами и законченное устройство. При этом качественно другой уровень возможностей. Другое дело, что энергопотребление повыше и это не везде подходит, а так же у процессорных систем и у контроллеров всё же разные итоговые стоимости в продукте. И это не Хорошо и не плохо, это разные инструменты и работать нужно уметь и с тем и с тем. И этот материал для старту обучения работе с процессорными системами. Что касается Linux для embedded систем - да вот хотя бы Вам пример российского проекта NapiLinux вот сайт проекта
загружается за три секунды, поставьте на EMMC, настраивайте через Веб или через API, из коробки система обновлений. Цитата: «NapiLinux — минималистичная и отказоустойчивая Linux‑среда, оптимизированная под встраиваемые устройства с ограниченными ресурсами и длительным сроком эксплуатации.» И есть другие варианты, просто этот Российский и портирован на Repka Pi.
Я не газую только за одноплатники или только за контроллеры. И то и то прекрасно может решать свои задачи. Тут вопрос скорее погруженности и как ручки из плеч растут и каким местом инженеры думают. Реально хороший embedded разработчик должен одинаково успешно уметь работать и с тем и с другим. Просто с контроллерами порог вхождения ниже и потому тема изъезженная и хорошо раскрытая, а вот с процессорными системами уделяется меньше внимания и потому с автоматикой и робототехникой есть вопросы в промышленности в стране, нужно это исправлять и обучать, для этого данный материал и создан.
Так что как когда то говорили на одном известном радио - "если Вы не любите кошек, то значит Вы просто не умеете их готовить". Так что что тут спорить и холиварить. Нужно и на том и на том делать больше материалов и проектов, а где уместно, там вообще гибридные решения строить.
А ещё есть информация, что команда проекта Repka Pi собирается портировать на свои одноплдатники FreeRTOS, вот это будет пушка для встраиваемых проектов с потребностями и амбициями - разработка как на контроллеры, а производительность и возможности одноплатников с многоядерностью и реальной многопоточностью только с настоящим real-time и плюшками в виде сети, большой оперативной памяти, хранилищем, мониторами, мышками и прочими клавиатурами из коробки. Но это уже другая история, будем посмотреть.
Я совершенно не против одноплатников, а даже наоборот я начал свой путь в embedded именно с первого raspberry pi и активно учавствовал в доведении до ума его драйверов USB, SD и т.п. Мои претензии были именно к статье потому что проект, хоть и демо, выбран не правильно и рассказ идет как будто бы автор программирует микроконтроллер, а не делает систему на полноценном Linux. Автор заявляет что сделал примитивный, но полноценный проект метеостанции, а на деле оказалось что это какой то обрубок обучающих скриптов для ручной демонстрации студентам в доме пионеров. Метиостанция - это устройство, которое пользователь воткнул в розетку и оно работает, а не набор скриптов, которые надо запускать на Linux по SSH или через консоль.
Ну и метеостанция должна как то обрабатывать показания датчиков. Иначе это термометр с линуксом на борту.
Строго говоря вот что ИИ поисковика выдал на запрос "что такое домашняя метеостанция"
Домашняя метеостанция — это устройство для мониторинга микроклимата в доме и окружающей среды, помогающее предсказывать погодные условия. Оно совмещает функции термометра, гигрометра, барометра, а иногда — датчика качества воздуха. Современные метеостанции оснащают сенсорами, которые собирают информацию, и дисплеем или мобильным приложением для удобного отображения данных.
Т.е. в этом минимальном объёме пример и показан - есть датчики базовых показателей и есть монитор для вывода информации.
Остальное конечно прикольно сделать - отправка информации, расширенный набор датчиков (особенно если добавить датчики газа, горючего и угарного, например), добавит сигнализирование о выходе параметров за заданные граница и т.д. Но это уже, наверное, то что можно фантазировать почти до бесконечности и то, что можно делать по аналогии самостоятельно, расширяя и улучшая базовый пример.
Тогда понятно о чём вы говорите - чтобы сделать полноценный продукт, т.е. что то типа домашней SCADA на одноплатнике или корпусной вариант метеостанции на контроллере. Тогда это будет не статья, а учебник и не для старта, а уже как профи-мастер класс для студетов старших курсов технических вузов или практика начинающих карьеру специалистов. В данной статье ставил задачу немного иную - когда уровень проекта начального среднего уровня, когда можно самому или с ребёнком позаниматься и есть поле для самостоятельного творческого развития - добавить вебку для вывода данных, добавить отправку данных по смс или в телеграм, добавить исполнительные механизмы и т.п.
А тут странное дело получается - пришёл после работы в пятницу и до глубокой ночи писал статью на базе ранее имевшихся образовательных наработок, чтобы сделать кому то может быть полезный материал на выходные. И потом налетают профессиональные комментаторы и критики, причём больше всего критикуют те, кто сам ни одной статьи не написал почему то.
В целом если среди этой критики выбрать конструктивные предложения и пожелания, то они вот такие, видимо - показать интеграцию с Веб интерфейсом для вывода дынных, добавить систему оповещения по СМС и через телеграм-бота, показать аналогичную реализацию на контроллере, корпусизировать исполнение на контроллере для получение законченного устройства, связать контроллер с одноплатником, сделать на одноплатнике сервер приложения для настройки и вывода данных, добавить датчиков и исполнительных механизмов, добавить помимо "метеостанции" ещё устройств разного назначения и связать всё это в единый центр управления "умным домом" на базе одноплатника.
Рекомендации и пожелания в таком виде понятны, попробуем сделать такой цикл в качестве продолжения к данному материалу. Понятно, что это изобретение велосипеда, так как есть прекрасные готовые решения типа Home Assistent со шлюзами и датчиками и энергосберегающем протоколе Zigbee , но тут обучающая задача чтобы делать своими руками и осваивать технологии, в т.ч. сквозные. Если интересно такое продолжение - пишите! Хотелось бы понять, нужно ли и интересно ли это кому то, чтобы понять, стоит ли тратить на это время и силы.
Не так.. target group непонятна. Кто, по вашему, читатель статьи? Чувак, который зачем-то купил одноплатник, но не знает что с ним делать ?
больше всего критикуют те, кто сам ни одной статьи не написал почему то.
Чтобы критиковать яичницу, не обязательно быть курицей ;)
Вы зря передергиваете и истерите. Вам сделали замечание по сути. Эмбиддед это система в целом, а не отдельный ее модуль. Ее результатом должна быть сборка прошивки. И раз уж изучение эмбиддед, то необходимо уделить и внимание сборке системы. Не надо сразу с крутыми вэбинтерфейсами и интеграциями. Должна быть самодостаточная сборка с возможностью минимального необходимого конфигурирования.
Ну и да, хотелось сразу написать о стрельбе из пушки по воробьям, но по сути для обучения решаемая задача не важна, а важно показать весь процесс ее решения. А вот этого как раз нету.
Надеюсь Вы адекватно примите конструктивную критику, а не начнете оправдываться. Возможно нужно было не до поздна в пятницу после работы писать пост, а спокойно в течении недели доработать материал и выпустить качественную, полную статью или цикл.
Сударь, извольте перестать разговаривать в таком тоне, скрывая за высокоменрными плохо прикрытыми оскорблениями свои поучения. Иначе я вызову вас на дуэль :-) Наверное так ответ бы звучал двести лет назад. Сейчас же нужно говорить иначе :-) Но я против бранных слов. Так что так - зря вы в таких выражениях и в таком духе пытаетесь донести свою мысль, вы ошибаетесь в своих предположениях. По существу же вопроса ваша мысль понятна.
Сборка системы никому ничего не должна, специально узнавал ;-) а кому была должна, всем всё простила.
По существу же Ваших предложений - обучение сборке системы штука хорошая, спору нет, но, на мой взгляд, не для базового уровня и не для домашних проектов, это, скорее, более профессиональная задача и предмет отдельного материала и даже, возможно, без привязки к конкретным проектам (только если это не пример, когда для работы проекта нужно своё уникальное дерево устройств и/или специфичный загрузчик). В начале данной статьи специально сделан акцент на базовый уровень и на то, что это конкретный учебный пример функционала. Возможно используемый термин "embedded-разработка" создаёт ожидания в т.ч. про подготовку прошивки. Понятие embedded-разработка понятие широкое и многоуровневое. Задача оптимизации кода по производительности в соответствующем разделе затронута, кстати говоря.
Тоже давно думал про создание отдельных статей по DT (в т.ч. с оверлеями) и примерами настройки под конкретные устройства и, что важно, с заходом в тему создания драйверов как модулей ядра для своих периферийных устройств. План написать такую статью есть, материалы с примерами есть. А может и Вы предложите свой вариант раньше, раз видите такой недостаток в имеющихся статьях, было бы на самом деле очень здорово.
Что касается более четкого обозначения целевой аудитории и очерчивания круга затрагиваемых вопросов и задач - с этим понятно, такое замечание принято, будем учитывать. Но стоит ли вообще подобные материалы готовить и публиковать или это ненужная трата времени подобные материалы не имеют ценности на Ваш взгляд?
Обучающий проект на одноплатнике — изучение embedded-программирования. Проект первый — простая метеостанция