Микрокомпьютер и микроконтроллер, в чем разница?

Сегодня при общении с коллегой раскритиковал некоторых специалистов всеми любимой торговой сети компьютерной техники и прочего товара.

Зацепились за определения микрокомпьютера и микроконтроллера.
Я считаю, что назвать плату с микроконтроллером микрокомпьютером может только тот, кто не имеет к этим устройствам никакого отношения.

Как же этот специалист, с таким уровнем знаний, может подбирать качественный товар на полки своего магазина?
Ведь коллега меня заверял, что главная цель этой компании - качество товара!

Хотя на Вики говорят ровно в этом же ключе https://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80

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


Я не вижу ни одной разумной области применения, где эти устройства были бы близки друг к другу.

Общим является только то, что оба имеют общие компоненты типа процессора, памяти и прочего.
Но если основываться на этом, то супер ЭВМ это тот-же микроконтроллер, так можно и дедку с бабкой сравнить.

Более того, цена, размеры, наборы интерфейсов и прочее обычно достаточно сильно отличаются.

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

Итак, по областям применения, которые мне пришли в голову:
- задачи требующие вычислений, в том числе и мультимедия уровня 'вполне приемлемо для просмотра фильмов' или прослушивание качественной музыки - выполняются на микрокомпьютерах, так как микроконтроллеры не имеют достаточных ресурсов для этого.
- задачи среднестатистического пользователя - выполняются также на микрокомпьютерах, а не на микроконтроллерах, по аналогичным причинам. Вы также не сможете на микроконтроллере просматривать современные веб страницы.
- задачи коммутации узлов сетей, типа маршрутизаторы, Wi-Fi точки доступа и прочее - тоже выполняются в основном на микрокомпьютерах (или на специализированных микроконтроллерах), на микроконтроллерах широкого функционала такие задачи не выполняются все по той-же причине - недостаточно ресурсов.
- опрос датчиков, работающих по специализированным шинам и протоколам, опрос кнопок, управление примитивными устройствами типа светодиода, лампы, бипера, двигателя в игрушке, передача и прием небольших радио сообщений с помощью различных модулей - здесь хорошо справится микроконтроллер, однако его зачастую можно заменить микрокомпьютером, но микрокомпьютер обычно стоит на порядки дороже.

Конечно здесь нет точных границ, например USB порт и I2C шина может быть и на микроконтроллере и на микрокомпьютере.
Но на микроконтроллере ресурсов сильно меньше, например на многих микроконтроллерах оперативная память размером всего лишь несколько килобайт а то и меньше. Микрокомпьютеры зачастую оснащены сотнями мегабайт или даже гигабайтами оперативной памяти, это же касается и о дисковом/flash пространстве и частотах и количества ядер процессора.

Т.е. категорически не верно считать, что микроконтроллер и микрокомпьютер однозначные определения.
Они предназначены совершенно для разных целей и имеют сильные различия в цене.

Оффтоп, накипело.

В чем причина холивара между Си программистами и почти вымершими программистами на ассемблере?

На мой взгляд, причина очевидная.

На ассемблере среднестатистические веб страницы не пишутся.

Также как и не пишутся широко востребованные нативные приложения.
Широко востребованные нативные приложения пишутся чаще всего на Си а то и на СиШарп или даже на Джава.
Но для быстрой разработки приложения на Си, Си программист должен взять огромное количество чужих разработок (это ведь основной плюс? Наличие данных наработок).
Однако, очень часто качество этих сторонних разработок вызывает сомнения, например Си библиотеки Ардуино. Какого-же качества продукт получаем в итоге? А да, ведь количество перерастает в качество? Точно?

Для того, чтобы взять кучу чужих наработок и выдать результат за свой продукт, чаще всего большого труда не нужно. Это же и есть основное преимущество языка Си?

И наоборот, никто в здравом уме не будет писать еще один HTTP сервер на ассемблере? Зачем такой тяжелый труд? Или боже упаси написать 1С.

Ассемблер не нужен там, где вы пишете 110-ую версию всем известного приложения, например для опроса датчика температуры. Вы это можете, и можете себя смело называть программистом.

Но ваши труды основаны на трудах тех, кто создает технологии, процессоры и подобное. Тестирует это все в машинных кодах и на ассемблерах. А потом вы берете их труды и называете их недалекими, потому что думаете, что они не способны писать на Си.

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

А я и дальше продолжу создавать решения не зависящие ни от кого.

P.S. Хотите большой и чистой автоматизации без Си и Веб извращений? Постараюсь помочь!

Документация

Я приступил к разработке документации.

Процесс будет долгим, документ только начат, но все же я решил его выложить.
Это черновой вариант, который обязательно будет не раз редактироваться.

Проект 5277, руководство интегратора v0.1.pdf

Вся документация будет распологаться здесь https://5277.ru/docs/

P.S. теперь сайт доступен по HTTPS.

Срез по текущим делам проекта

У меня появился некоторый рабочий настрой и стимул, для продолжения работ по моему проекту.
Хочу здесь зафиксировать некоторый результат проделанной работы.

1) Как я уже писал, было создано ядро на ассемблере(для некоторой разновидности Atmel ATMega микроконтроллеров) с дополнительными утилитами, что по сути является уже не ядром, а операционкой(пока без поддержки файловых систем)
2) На базе этой операционки был создан фундамент и несколько прошивок для моих шлюзов и устройств.
3) Наконец, я добрался до вопроса обновления конечных устройств. Был разработан бутлоадер(пока в стадии тестирования и багфиксинга) с возможностью расшифровки данных - дабы защитить прошивку от копирования.
4) Была создана и реализована функциональная модель, позволяющая прошивать изначальной прошивкой новые устройства. Которая дала уникальный идентификатор каждому устройству и индивидуальный ключ для расшифровки данных новой прошивки. Т.е. по сути реализован функционал позволяющий автоматизировать процесс прошивки новых устройств.
5) Обновлены PCB большинства устройств - добавлен унифицированный порт для удобной и быстрой прошивки устройств, заменен линейный стабилизатор напряжения на импульсный стабилизатор(что дало возможность питать устройства даже от 5 и 36 вольт), устранены многие мелкие недочеты. Появились порты расширения и платы расширения.
6) Постоянно выполняется мелкая доработка основных компонентов, например, появилась возможность конфигурировать не только устройства, но и шлюзы.
7) Есть интерес у определенного заказчика на реализацию библиотек оборудования для гидропоники, в теории следующая неделя будет посвящена этим задачам.
8) Есть возможность выполнить легкую автоматизацию многоквартирного дома, как минимум поставить датчики на двери служебных помещений, снимать температуру стояков отопления, сигнализировать о протечках и прочее. На данный момент все упирается в конечные устройства.
9) Возможно летом проект будет задействован в теплицах, есть интерес у знакомых.

Сейчас я подготавливаю спецификацию для заказа нескольких PCB, вероятно часть и них окажется последними прототипами. Далее Будем двигаться в сторону небольшой партии со сборкой на стороне фабрики.

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

P.S. minicom не идеален, получив мусор на входе он может полностью перестать выводить корректный поток данных, кто бы знал...

FOTA

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

Изначально я смотрел в сторону поддержки алгоритмов типа AES, и конечно же на не дорогих МК ее нет.
Но я нашел решение.

FOTA будет, и это здорово.

Гидропоника

Допустим, я занялся гидропоникой и хочу использовать свой проект для автоматизации процессов.

Здесь я опишу возмодности проекта и что именно я буду делать на первых шагах.



И так, у меня есть модули для различных датчиков качества воды, типа такого:

Еще есть дозаторы типа (или даже проще, один двигатель, без логики):

Ну и нужен свет.




Казалось бы что проще? Берем ардуино, качаем с сайта производителя https://atlas-scientific.com документацию по протоколу, реализуем его на ардуино (либо даже берем готовую библиотеку, наверное она где-то есть)
И все делаем сами, т.е. сценарии, информирование, удаленный доступ, сбор статистики и прочее, прочее, прочее.

Но я же все эти вопросы уже решил в своем проекте.
Проект представляет из себя три ключевых узла - Java контроллер, сервер, клиент. Также есть различные собственные конечные устройства и различные шлюзы.

Для работы конкретно с вышеописанными устройствами я могу использовать мини компьютер с шиной I2C, либо любой другой компьютер с большим набором UART (например USB-UART устройства).
На этом компьютере будет работать Java контроллер, он будет выполнять все взаимодействие с устройствами, в том числе и выполнять различные сценарии. Данные контроллер будет передавать серверу, а тот их отдавать клиентам и агрегировать.

Мне незачем знать API/протокол EZO устройств, они уже реализованы в проекте (кроме дозатора, об этом позже).

Точно также обстоят дела и с другими устройствами, например управление светом, датчик открытия двери и прочее.
Теоретически я их всех могу подключить к мини компьютеру через GPIO. Но что делать с обычными компьютерами?
Можно прикупить китайских железяк и подключить их по USB к примеру.

Но я пойду другим путем. Жаль, сейчас нет железок под рукой, фото будут позже.
Я возьму решение от Dipex. Мы разработали множество различных модулей.
Среди них есть модули специально для EZO модулей, есть USB шлюз с шиной DipexBus, есть мини компьютер с платой расширения DipexBus, есть специальный модуль для диммирования светодиодных ламп со стабилизацией по току. У нас много железяк, и некоторые специально разрабатывались для данной задачи.

Да, DipexBus проприетарная, но и ее протокол мне не нужен, все в проекте. Мне не за чем работать с DIpex модулями напрямую, так же как и с EZO модулями напрямую.

В итоге, я подключаю USB-DipexBus шлюз в любой компьютер или использую мини компьютер с платой расширения I2C-DipexBus. К нему подключаю EZO Dipex модули (в любом количестве) вставляю в них EZO модули и подключаю датчики. Также на шину подключаю Dipex LED диммер, DIpex IO модули и прочее.

Вот в качестве примера (только здесь другие модули и без корпуса):
photo_2020-05-20_18-30-39.jpg

Таким образом я объединяю DipexBus'ом все свои датчики и исполнительные устройства. Шина реализована на RS485 с поддержкой до 128 устройств.

По поводу дозатора. Мы не стали использовать дозаторы от atlas-scientific, у нас обычные дозаторы (двигатель на 18 вольт) которые управляются отдельным многоканальным модулем Dipex. Библиотеки дозатора atlas-scientific в проекте нет, но его можно добавить при желании.

Теперь программная часть.

Как минимум мне нужен Java контроллер. Он будет выполнять сбор данных, управление и обработку сценариев (логика), передачу данных и событий на сервер для дальнейшей передачи этих данных клиентам, агрегации, информирования, и прочее.

Клиент - отображение показаний, управление устройствами и настройка сценариев и проекта.
Он может работать через сервер или напрямую (если клиент и контроллер находятся в локальной сети)

Т.е. регистрируюсь и описываю проект через клиента.
Здесь все достаточно просто. Dipex устройства умные, автоматически распознаются и прописываются в системе.

TODO: позже добавлю здесь видео.


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

Либо можем работать через сервер, и здесь варианты:
В данном случае нам нужен итоговый результат. Т.е. показания устройств, статистика, возможность изменять налету проект и сценарии.
Все это можно сделать через аналогичный API (также использует клиент).
Сервер поддерживает несколько подключений, через которые можно использовать API:
- внутренний бинарный протокол (можно предоставить Java библиотеку с его реализацией)
- голый TCP с JSON
- HTTP с JSON
- WebSocket c JSON
Документация будет доступна после написания.

Кроме этого, управлять и собирать показания можно через так называемые точки входа - Telegram, Алиса, email, HTTP и прочее. Методы работы специфичны для каждой точки доступа. Документация также будет доступна после написания.



В общем самый тру подход на мой взгляд - это использовать Dipex модули, и три основных компонента проекта.
В этом случае будет доступен максимальный функционал почти полностью покрывающий все мои пожелания.
А если чего-то нет, то можно и доработать.

Пока все, буду обновлять по необходимости.

P.S. По поводу пожеланий, я постараюсь найти время и выполнить ваше пожелание (например написать документацию по API). Но при одном условии - Вам действительно нужна эта документация (чтобы я не писал ее в пустую сейчас)

Update 03.01.2021

Я благодарен пользователям, которые оставляют мне комментарии. Благодаря им я вижу о чем забыл сказать или о чем стоило бы повторить.

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

Клиент, который я предоставляю, является основным инструментом для интегратора. Пользователь тоже может им пользоваться, но для пользователя он будет слишком громоздким и не совсем удобным.
Зачем пользователю такой клиент, если ему нужно просто включать свет в паре комнат?

Конкретно для пользователя я сделал точки входа. Например точку входа Телеграмм или Алиса, где пользователь может управлять устройствами гораздо удобнее. Также были созданы виджеты под Android, которыми я сам пользуюсь очень часто (моя жена пользуется телеграмом и ее вполне это устраивает). Возможно в этом году я стану разработчиком под ios и у нас появится клиент и виджеты под iphone.

Но, в рамках данной задачи (гидропоники), для специалистов я бы создал специальный веб проект, где были бы выведены многочисленные графики, сгруппированы показания, выведены специальные элементы модификации проекта (параметров устройств и сценариев).
API открытое, этим проектом может заняться сторонняя компания, а можно обратиться в Dipex Group - они могут разработать дизайн, WEB портал и разместить его в своем ЦОД'е.

Умная розетка от 'Xiaomi'

После полугода использования (очень редко и ненадолго включал через нее лампу дневного света).




Выбило пакетник на десятки ампер. Благо пакетник был не 'Xiaomi' с Wi-Fi.

В общем очееень умная розетка.
Это же надо додуматься в каждое устройство всунуть блок питания.
Да еще и Wi-Fi модуль, который сам по себе не плохо кушает.
И главное реле на 12 вольт поставить, с отдельным блоком 'питания' в виде резистора с конденсатором, который в итоге и коротнул.

Хотя главное то что? Главное чтобы пипл хавал!