Comments 45
eMMC бы ещё вместо всех этих флешек...
Я пока не разбирался с этим вопросом, но в официальной документации на KC868-Server упоминается eMMC.
Официальный ответ от производителя (думаю перевод не требуется):
There is 8G eMMC on the Pi inside. on the board already, If want to use, use USB cable connect type-c USB of Pi to your computer. Set the jumper to "right", so that computer will have a removable disk. Then you can install software. Before use eMMC, need install USB driver of computer.
То есть eMMC присутствует на плате, размер — 8G.
Температурный диапазон работы. От минус 30 до плюс 60 градусов будет работать?
Или только комнатный вариант?
Это реальный диапазон Т для Нижнего Новгорода при работе устройства в установленном на улице шкафу.
Задал вопрос производителю - как только получу официальный ответ - отпишусь здесь.
Производитель пишет:
Рабочая температура: -20...+70 С
Влажность: 20%RH...80%RH
В Нижнем в шкафу с утеплением фольгированной теплоизоляцией и подогревателем будет норм.
по хорошему(если это не для себя), то оборудование в шкафу на улице в россии должно удовлетворять УХЛ1 (-60...+40) за редким исключением...
По хорошему, оборудование, которое содержит тепловыделяющие электронные компоненты, само по себе греется (тем более что разработчики стараются скомпоновать изделия покомпактнее). Поэтому в сторону минуса ему нужен, скорее, аппаратный контроллер холодного старта. Ибо большинство компонентов с высокой степенью интеграции рассчитаны на 0...+70С. А вот в сторону плюса - в любом шкафу без климат-контроля летом запросто может быть и 45, и 50, особенно если забыли поставить козырёк от солнца, благодаря чему многие компоненты на плате могут приблизиться к предельно допустимой температуре. Впрочем, интеловская мат.плата (с охлаждением процессора на корпус) проработала на крыше в герметичном ящике полтора года, и ничего. Как раз в 2010-м, жарком году.
На сайте производителя есть вся информация – https://www.kincony.com/home-automation-local-server.html
Когда я первый раз увидел этот контроллер, у меня просто не было слов — кажется, это воплощённая мечта любого «автоматизатора» и гика — чего там только нет: ESP32, Raspberry Pi и ARM Cortex M4 в одном флаконе…
… одних только модулей Wi-Fi на KC868-Server 3 штуки
по мне это не мечта, а трэш какой-то.
если esp и arm ещё как-то можно объяснить (на arm будет крутиться линукс, у которого с рилтаймовстью не очень хорошо; плюс у esp может быть больше интерфейсов), то наличие двух arm и трёх wifi вызывает полное непонимание.
Там много чего вызывает вопросы - со всем этим я и собираюсь разобраться в ближайших статьях - сначала с CM4, затем с ARM частью.
Поддерживаю. Выглядит как минимум странно. Странная комбинация вычислительных модулей и интерфейсов.
По моим наблюдениям, компания Kincony делает свои контроллеры исходя из своего внутреннего понимания этой проблематики - нам не всегда понятны её решения и я, например, многое сделал бы иначе.
Тут ещё важно понимать, что функционально это Server и все, что там наворочено - это не "обязанности", а "возможности", которые можно задействовать (или не задействовать) в соответствии с вашим конкретным проектом.
А где фонарик?
GD32F103 — не Cortex M4, а Cortex M3.
Да, «напихали» много чего и не всегда логично, с нашей точки зрения, но какие проблемы с применением? На мой взгляд, как главный сервер, например, «умного дома» или «умного чего угодно» — более чем.
Мы имеем в своём доступе все части этого контроллера (и в железном и в софтверном смысле) — любая «синергия» — это вопрос только нашей фантазии и нашей квалификации.
Вы когда-нибудь проектировали архитектуру сложных IoT систем? С сотнями распределённых сущностей, зависимостей, интерфейсов, протоколов передачи данных, шифрования и т. д.? — я думаю KC868-Server — это отличное решение для ядра любой «умной системы».
(Это не значит, что KC868-Server идеально спроектирован — там есть куча всего, что можно переделать, изменить и улучшить.)
любая «синергия» — это вопрос только нашей фантазии и нашей квалификации.
Я имею в виду, что если мне зачем-то нужно будет использовать ESP32 в связке с малиной, я лучше возьму отдельно столько модулей ESP32, сколько нужно, и соединю их с малиной любым нужным мне способом, чем ограничу себя девайсом с одним ESP32 и одной малиной, соединённых по RS 485. Потому как в реальной эксплуатации, а не при разработке, мне (да и вам) скорее всего и понадобится иметь ESP32 не в одном боксе с мозгами, а где-то непосредственно возле управляемого девайса. А под синергией я подразумевал какую-то дополнительную техническую выгоду от размещения блоков на одной плате. Например, более эффективную коммуникацию, чем по старому последовательному интерфейсу, совместное использование ресурсов и т.д.
Вы когда-нибудь проектировали архитектуру сложных IoT систем? С сотнями распределённых сущностей, зависимостей, интерфейсов, протоколов передачи данных, шифрования и т. д.?
Ну что такое «сложная IoT» система? Если мы говорим про IoT, это в первую очередь автоматизация дома. А это значит, это освещение, отопление/климат, управление котлом, домофон/безопасность, ну и всякие мелочи по вкусу вроде электрокарнизов. Наворотить при желании можно что угодно, но я абсолютно искренне считаю, что если у вас там сотни распределённых сущностей, зависимостей, интерфейсов и протоколов передачи данных, то так делать не надо было. Подобная автоматизация делается не для использования её результатов конечным потребителем, а скорее для развлечения собственно, кхм, автоматизатора. Развлечения самим процессом разработки/реализации.
Почему только «автоматизация дома»? Существуют ещё дачи, посёлки, склады, гаражные хозяйства, цеха, оранжереи, теплицы, курятники и т. д. и т. п., а также существует бесконечное число задач для IoT систем.
Уважаемый DrPass, мне кажется, что наша дискуссия несколько зашла в тупик. Предлагаю на этом пока остановиться, тем более, что и ваше и моё мнение выражено достаточно ясно.
Я автоматизацию дома привёл как самый сложный кейс для IoT
На каком-нибудь заводе с конвейерной линией автоматизация всё-же посложнее (и ответственней) , чем автоматизация дома.
ей такой трехголовый контроллер не понадобится
Ну блин, если такой штукой будет проще и быстрее всё автоматизировать, то почему нет? Кроме того, останется ещё и запас на будущие хотелки. Понятно, что эта штука - overkill , и не все функции такого монстра нужны, но и компьютеры покупают с запасом, а не чтобы тютелька-в-тютельку входило.
Плюс не всегда сразу заказчик может очень точно сказать, чего хочет на выходе, а если у тебя всё рассчитано до самого последнего датчика, то и расширяться будет проблематично. А такая штука будет хорошим твоим планом Б на случай если придётся добавлять новые очень разные устройства. Вместо ответа заказчику: "это невозможно", или "нужно всё переделывать" просто отвечаешь: "Подержи моё пиво"...
Золотые слова.
На каком-нибудь заводе с конвейерной линией автоматизация всё-же посложнее (и ответственней), чем автоматизация дома.
Я это прекрасно понимаю, но в принципе ничего подобного не упоминал просто потому, что этот контроллер никакого отношения к промышленной автоматизации не имеет. Это гаджет для гиков, а не промышленное устройство.
Ну блин, если такой штукой будет проще и быстрее всё автоматизировать, то почему нет?
Я абсолютно с вами согласен, что если проще и быстрее — то да. Это очевидно. Мои возражения были лишь про то, что я не могу придумать ни единой реальной задачи, которую было бы проще и быстрее автоматизировать таким странным Франкенштейном. Я даже спросил у автора статьи, может, он знает такие задачи. Но он тоже не знает. Т.е. мы имеем забавную навороченную хренотень, которая вроде бы интересная, но при этом куда и зачем её прикрутить, никто понятия не имеет. В моём понимании, малинка, ESP32 и контроллер на STM, не распаянные на одной плате, а в отдельных корпусах, обладают всеми преимуществами данного девайса, и в то же время обладают бесконечно большей гибкостью конфигурирования, нежели этот девайс.
Вот-вот, никто не будет ставить на завод эту вундер-ваффе, поставят ПЛК с Ethernet/wifi и будут уверены, что девайс пригоден для промышленных условий, сделан проверенным производителем, а также что произвольно взятый пусконаладчик/автоматизатор сумеет его запрограммировать и настроить через пару лет после покупки.
Ну например это можно рассматривать как полный модуль для управления станком с ЧПУ, наша стойка включает стандартный комп + Cortex M3 а тут все в одном.
Про ARM-часть вопрос пока открытый (можно ли какой-нибудь Marlin будет завести без секса с переназначением всех аппаратных возможностей на несколько месяцев), а вот комп без какого-либо экрана выглядит очень грустно: придётся добавлять панель с собственным контроллером.
На примере того же Marlin/smoothieware/GRBL это выглядит довольно грустно, serial-интерфейс тормозной и не годится для оперативного управления станком, включая внезапный Halt посреди операций по ручному перемещению (jog).
Так у него же есть выход на монитор судя по описаниям KC868-Server для блока под linux или я чего то не понял? А при ручном перемещении/управлении вполне достаточно 0,1 сек, все равно человек реагирует не быстрее 0,3-0,5 сек
Выход есть, но это HDMI, он отврательно годится для индустриальных применений (и торчит, либо вбок, либо вверх).
Про перемещение – там ещё проблема на уровне логики протокола. Условно, нельзя через Serial передавать постоянно актуальное состояние клавиши, это превращается в серию долгих нажатий. Для тяжёлых станков с ускорением это превращается в множество рывков вместо разгона и торможения. Решение, собственно, не управлять через UART.
Вот только из статьи следует, что Cortex M3 вам не дадут запрограммировать, а связь Rpi--cortex вам надо делать самому внешними компонентами(?!). Такое себе устройство, по-моему.
Ещё вопрос, заведется ли ваш софт для станка на ARM.
Есть ли хоть один готовый из коробки вариант использования данного сервера?
Например есть ИК управление. Есть реле , есть входы и т.д. Почему не сделали простое конфигурирование через веб интерфейс различных вариантов использования.
Если уж поставили мини комп с линуксом - то могли бы там разместить на флешке различные прошивки с различными вариантами использования, а пользователь выбрыв нужные функции - получил готовый к использованию девайс.
Но так не выйдет . Потому что как ни крути, получается паровоз Ардуино , с одной максимум двумя функциями, так как начнутся конфликты внутренних ресурсов. А пилить придется много.
Получилось что то непонятное: это и не ПЛК, и не контроллер для домашней автоматизации типа Crestron, и не контроллер имеющий сугубо практический функционал. А набор плат в одном корпусе , которые и так продаются по отдельности.
Насколько я понял, производитель сделал следующее: он закрыл схемотехнику ARM части и сделал готовую закрытую прошивку, которой комплектуется контроллер. ESP32 и CM4 части он сделал открытыми в плане схемотехники, а программирование этих частей оставил на откуп пользователя.
На мой взгляд это странное решение наполовину открыть контроллер, а наполовину — закрыть. Я специально их об этом спросил — их ответ есть в статье.
Лично мне это решение (категорически) не нравится — мне нужен полностью открытый контроллер, который я могу программировать как хочу. План по решению этой проблемы тоже есть в статье.
Трешь, угар, содомия.
Важный для понимания апдейт: этот котопёс стоит порядка $350.
Притом что остальные контроллеры у Kincony стоят несколько десятков, и за свою цену выглядят более интересным решением , чем возня с платками от принтеров.
Можете пояснить часть про RS485 на внешних компонентах? Rpi исходно никак не подключена к МК, хотя они разведены на одной плате, и если кто-то хочет использовать входы/выходы с Rpi (а судя по рисунку, собственные gpio rpi никуда не выведены), то должен вешать дополнительную лапшу между двумя чипами?
По задумке производителя, нужно внешними проводами соединить разъёмы RS485 RPi и ARM частей.
Почему так и насколько это вменяемое решение остаётся для меня большим вопросом.
Я бы скорее соединил GPIO RPi и ARM внутри контроллера и организовал связь по какому-нибудь протоколу, возможно самописному.
Но подробно я с этим пока не разбирался - нужно сначала провести эксперименты по вскрытию ARM части и написанию для неё собственной прошивки.
Независимо от того, насколько это вменяемое решение, по-моему это пример архитектурного идиотизма. По-сути, у Rpi отобрали возможность удобного GPIO, так что по возможностям взаимодействия с железом она близка к обычному десктопу или ноутбуку - можно подключить МК внешними проводами (USB или в данном случае, rs485).
Насколько я понял логику производителя:
- функционально это Server и RPi там нужен для решения соответствующих «тяжёлых» задач типа поддержки SQL базы данных системы, обслуживания логики верхнего архитектурного уровня (тысяч) датчиков, предоставления развитого веб-интерфейса и т. д.
- гребёнка GPIO RPi отдана на откуп пользователей — если вам это нужно — делайте соответствующую плату и цепляйте её к этой гребёнке. Но по идеологии производителя это опционально и носит только дополнительный характер к основной серверной функции RPi.
Насколько я понял логику производителя:
Это вот то, о чём мы спорили — я вообще не понял логику производителя. Здесь три никак не объединённых между собой устройства, прибитых гвоздями к одной плате. Функционально — никакой разницы между этим девайсом и тремя устройствами по-отдельности нет. По цене даже дороже, если не ошибаюсь. По гибкости конфигурирования три устройства по-отдельности удобнее (да и в реальной жизни вы скорее всего захотите разместить ESP32 не на рейке, а где-то поближе к управляемому им устройству (и их скорее всего будет несколько, а не один), а малинку вы установите там, где дисплей будет, а на рейке как раз и останутся мозги дома в одиночестве). Ну т.е. единственная логика, которую я вижу, это сделать убер-гаджет для гика, который продаётся на эмоциях, а не на здравом смысле. Косвенно это даже вы подтверждаете — глазки у вас от этого контроллера горят, а сформулировать, куда он такой нужен, не можете ;)
А вот я не люблю, когда методику продажи айфонов применяют к контроллерам…
Kincony KC868-Server: не контроллер, а просто атомная бомба. Часть 1