Comments 36
я так понимаю от Расбери-пиАй отличается тем что штатное подключение к монитору не предусмотрено, HDMI-я нет.
Я думаю многих бы заинтересовал результат такого сравнения, еще до того как вы прилепили туда STM-контроллер. Я думаю это бы послужило хорошей рекламой. По моему нет ничего плохого залезть на плечи раскрученному названию.
С наилучшими пожеланиями и успехов вам!
я так понимаю от Расбери-пиАй отличается тем что штатное подключение к монитору не предусмотрено, HDMI-я нет.
HDMI будет в 8й версии.
Я думаю многих бы заинтересовал результат такого сравнения, еще до того как вы прилепили туда STM-контроллер. Я думаю это бы послужило хорошей рекламой. По моему нет ничего плохого залезть на плечи раскрученному названию.
На вскидку отличия, важны они для вас лично или нет — решать вам:
Мы используем память, процессор и eMMC, изготовленные по индустриальному техпроцессу, что сильно повышает надёжность.
Выходной контроль 100 % устройств на производстве, о нём мы писали тут.
У нас готовое устройство в корпусе с кучей интерфейсов и предустановленным софтом собственной разработки, который позволяет решить почти любую задачу автоматизации.
Экосистема периферийных устройств, которая благодаря софту контроллера удобно настраивается и быстро работает. Например, драйвер из коробки умеет наше расширение Быстрый Modbus, а для сторонних устройств есть десятки готовых шаблонов: шторы, конционеры, частотники и т.п.
Мы сами разрабатываем и производим устройства, но его вид и возможности продиктованы потребностями пользователей. Многие из них перешли на наши контроллеры в том числе и с малинок.
Наш софт открыт, его можно дорабатывать под свои нужны. Этим иногда пользуются компании, которые заказывают OEM-версии контроллеров, чтобы потом сделать своё собственное нишевое решение. Также мы помогаем собрать преднастроенный образ софта для контроллера, что уменьшает стоимость развёртывания системы в разы.
С недавних пор у нас появился сервис удалённого администрирования Wiren Board Cloud, который можно использовать «как есть» и установить к себе на сервер.
У нас нет цели конкурировать с малинками, более того, наша периферия отлично с ними работает. Мы просто делаем то, что хорошо умеем и чего ждут от нас пользователи.
Приходите к нам в гости в апреле и сами всё увидите, пообщаетесь с пользователями и разработчиками устройств, посмотрите на решения на базе нашего оборудования и оборудование некоторых конкурентов по рынку.
А что за процессор, на котором крутится Линукс?
А что за процессор,
Сейчас у нас Allwinner A40i 4 ядра 1.2 ГГц Industrial Grade, в новом Wiren Board 8 будет Allwinner T507 4 ядра 1.5 ГГц 64 бита Automotive Grade.
Мы стараемся выбирать процессоры по доступности на рынке, а также по балансу производительности, качества и стоимости.
Всегда думал, что Allwinner не достать. Процессоры сами по себе. А эти оба есть на стоках. Спасибо. Процессорный модуль готовый используете, если не секрет, или с нуля плату под проц разводите?
Более того, в РФ есть целый дистрибьютор со складом, отладками и документацией.
Процессорные модули свои, но готовые тоже существуют, у Стартеркита, например, их много.
Так же интересно сравнение с JetHome D1+
подключение к монитору не предусмотрено, HDMI-я нет
это удобно начинающим для первого старта без "дополнительного" оборудования, но с учетом применения Wiren где нибуть на щите это довольно излишне.
У малин софт наработан заметно более широко и полно всяких шляп на все случаи жизни, и кстати коробочка на din рейку тоже есть, карточки micrro sd бывают industrial grade. У малин много софта так или иначе связанного с именно типовой промышленной автоматизацией (там все так сказать, немного по другому)
Т.е. в целом на любой вкус, прекрасно можно пользоваться малинками, пользоваться очень-очень гибко... но наступает момент когда колхоз из платок и релюшек начинает надоедать.. или вот недавно же в топике были уже разговоры про одноплатник "без всяких наворотов"
Wiren - вещь достаточно промежуточная между классическими промышленными контроллерами со довольно специфичными языками программирования и, так сказать,компьютерами общего применения, с "традиционными" языками, чтобы не переучиваться. И ниша не очень четкая, но востребованная, есть другие ПЛК заточенные под эти самые традиционные языки. А есть, например, JetHome который хоть и на din рейку, но по сути такой же одноплатник для home assistant
Мне почему то кажется в статье что то не так с форматированием:
сначала идёт заголовок "Задачи", который состоит из одного абзаца,
потом на этом же уровне по тексту размазаны -видимо- сами задачи.
Из за чем сложно понять о чём идёт речь.
Бодрого дня, да)
сначала идёт заголовок "Задачи", который состоит из одного абзаца,
потом на этом же уровне по тексту размазаны -видимо- сами задачи.
К сожалению, таковы стили Хабра :( Задачи сделаны h2 заголовком, а Power Sequencer и далее до самого «Как устроен» h3.
Приветствую)
Может тогда стоило перечислением указать - какие именно функции покрываются?
Тогда возможно было бы лучше понять, почему был выбран именно такой микроконтроллер?
Может тогда стоило перечислением указать - какие именно функции покрываются?
Спасибо за идею добавил перечень задач и правда стало лучше.
Боброго дня,
немного ещё побуду " душнилой" который не видел контроллера и не сильно понимает о чём речь :
Задачи, которые решает EC:
Power Sequencer или управление входным питанием;
Реализация сторожевого таймера Watchdog;
RTC и будильник:
обслуживание кнопки ON/OFF:
Измерение температуры базовой платы:
Управление аналоговым выходом Vout:
Измерение показаний АЦП на аналоговых входах A1-A4:
Отладочный вывод до включения процессора.
Слежу за вашим контроллером давно, не сказать чтобы пристально, но стараюсь быть вкурсе. Внедрение в архитектуру ПЛК "супервайзера" на базе stm32 - очень годное и разумное решение. Но что насчёт входов и надёжности? Насколько я помню, гальваническую развязку входов/выходов и сетевых интерфейсов не завезли? Это очень важный аспект для того, чтобы ваш продукт занимал разные ниши в автоматизации. Ещё хочу спросить, думаете ли в сторону архитектуры ПЛК с использованием внешнего домена ОЗУ с питанием от литиевой батареи, в котором хранится текущий образ "пользовательской" или рабочей программы, вместе с трендами и конфигурационными данными? Очень хорошее решение, используемое не скажу где)), позволяет сильно повысить надёжность ПЛК не как собственно устройства , а как функционального оборудования на нижнем уровне автоматизации в составе АСУ ТП. Лучше иметь на борту три контроллера: cortex-a + 2 cortex-m: первый отвечает за работу с сетевыми интерфейсами, за работу с сетью и долговременным хранением данных(тренды, журналы), а также за реализацию верхнего уровня автоматизации(web-сервер, БД, и прочий верхний уровень), а два младших кортекса отвечают за функции "супервизора" для периферии, и второй cortex-m отвечает за реализацию"plc-core": он взаимодействует с энергонезависимым доменом ОЗУ, в котором хранится пользовательская программа, он выполняет арбитраж доступа к ней со стороны cortex-a процессора, постоянно считает CRC образа процесса, лежащего в этом ОЗУ, а также собственно управляет входами/выходами, осуществляя реализацию безопасного состояния выходов. Даже если cortex-a зависает, падает Linux, что угодно, супервизор перезагружает cortex-a без прерывания выполнения основной программы. Сценариев много, на самом деле, но рынок требует отказоустойчивых, надёжных и функциональных ПЛК.
В ПЛК Panasonic как раз используется ОЗУ с батарейкой. Всегда поражался этому бреду. Иногда пользователи не видят сигнал о необходимости заменить батарейку - память стирается и дорогостоящее оборудование превращается в кирпич. Исходников программы производитель при поставке оборудования не дал, а к моменту факапа их уже и физически нет.
Из вашего рассказа, про это чудо инженерной мысли, не понятно, как оно надежность-то повышает. Можете по подробнее пояснить?
Литиевая батарея для сохранения образа программы используется почти во всех серьезных ПЛК, почти у всех вендоров. Это не бред уважаемый, а обычная практика. У ПЛК никаких пользователей не бывает: на верхнем уровне есть операторы и диспетчера, которые точно узнают о низком напряжении такой батареи с помощью аларма, который сначала нужно будет подтвердить, потом сбросить. Образ программы загружается из ПЗУ в эту энергонезависимую ОЗУ, и потеря питания не гарантирует потери работоспособности ПЛК и программы - просто он будет работать с ошибкой, без возможности сохранять журналы и тренды. А это чудо инженерной мысли повышает надёжность не ПЛК, а именно устройства как компонента нижнего уровня автоматизации таким образом: при пропадании питания CPU или понижении его ниже некоторого уровня супервайзер питания выключает питание или перезагружает систему, при этом образ работающей программы остаётся в nvram. Если это предусмотрено логикой работы программы, то в таких случаях либо выполнение программы приостанавливается (замораживается) для не критичной автоматики, либо задаётся безопасное состояние входов, в случае критической инфраструктуры. После того, как питание восстановится, загружается ядро ОС ПЛК и проверяется состояние образа программы в nvram: проверяется контрольная сумма образа, журнал ошибок и тренды сохраняются в ПЗУ, если было прервано выполнение не критичной программы - выполнение продолжается, что верно даже для больших систем с ответственной инфраструктурой, остановка одного ПЛК может быть убыточным для всей технологической линии.Подробно?
ПЛК используются, например, в станках. Да и на линиях панель HMI это, часто, самый верхний уровень, куда аларм о батарейке может и не выводиться. Лампочка внутри шкафа автоматики под станком, например, куда редко кто заглядывает. А уж если станок выключен длительное время, обесточен, так и не проверить состояние батарейки. Батарейка, конечно, долго живет, может и 10 лет продержаться и это притупляет бдительность. ПЗУ - опция, дополнительная плата, которая далеко не всегда ставится. Розовые единороги это прекрасно, но я сталкивался с суровой реальностью, которую описал. Программа хранящаяся в ОЗУ с батарейкой это жизнь на измене)
А что мешает сохранять тренды и параметры на флеш память? Не обязательно же каждую секунду туда писать. При пропадании питания есть время, чтобы переписать состояние из ОЗУ во флеш.
немножко спутано тут все получается, сложно понять мысль. я вот вообще не понял: почему вообще пропадет возможность сохранять журналы - это выглядит как искусственное ограничение. Если потеря питания краткосрочная (бросок) то эффективнее оставлять питание всей системы - не сколько батареи, сколь аккумуляторы или даже просто ионисторы хорошие - просто работать дальше. В случае долговременного сбоя - определяем, сохраняемся во флеш нужное, культурно выключаемся. Хранить программу в батарейной оперативке вообще смысла нет, тем более ее там верифицировать - поступило питание, загрузили, восстановили состояние, пользуемся.. В общем скорее гибернация, а не спящий режим (а с линуксами это еще и вопрос, так то она инициализуирует память при старте, надо допиливать под такой режим)
Батарейка нужна в первую очередь для часов, но поскольку в RTC есть еще память то какие то настройки довольно удобно хранить там. Для данных ее применяют не от хорошей жизни, когда с флешем те или иные проблемы. И это архитектурное решение
Спасибо, интересно. Не подскажете
что висит на РА4?
откуда берете опорное напряжение для Vref+? встроенного опорника не хватает?
Не думали взять более многоногий мк, чтобы дать ему и Vref-, и внутренний опорник наружу вывести?
1) на PA4 выводится сигнал 1 Гц с RTC. Включается через карту регистров и используется в стенде тестирования для калибровки часового кварца. Калибровочное значение сохраняется в EMMC и применяется при загрузке линукса
2) Vref+ соединён с Vdd МК через LC-фильтр. Для измерения напряжений как раз используется встроенный опорник, точности его оказалось достаточно
3) а зачем внутренний опорник наружу? Не понял вашу мысль
Не надо внутренний опорник наружу!
Помех по Vref наловите.
Несколько озадачило использование STM32 в качестве аппаратного WDT.
Да и вообще 32-битника вместо 8-битного MCU (хотя... найти даже 8-битник на технологии 65/90 нм и выше в современном мире, наверное, крайне сложно. Тогда вынужденно соглашусь).
Но вообще - перечисленные задачи гораздо правильнее решать на FPGA, реализуя жесткую логику. Да, не так изящно - зато действительно надёжно, в индустриальном стиле.
Для перепрошивки придется чуть больше нагородить, плюс уровень вхождения выше, вопрос цены - интересен
Да, в части цены - согласен, погорячился (простые FPGA стоят соизмеримо с STM32, а сколь-нибудь серьезные значительно дороже даже с учетом 24 года и китайского происхождения). А более высокий уровень вхождения в ПЛИС компенсируется однозначностью их поведения и более высокой надежности функционала.
P.S.
Но ваш EC заставил задуматься "а нафига нужен Padauc и прочие Attiny" :)
задуматься "а нафига нужен Padauc и прочие Attiny"
Кому - что. STM32 применяют в подобном качестве в некоторых открытых проектах: ноут вроде был такой, или одноплатник...
А еще круче вкорячить отечественный 32-битник для контроля питания монитора, и использовать у него буквально 1 ножку... (пардон за оффтоп).
Вообще в эпоху MCU по тенологиям 90/130 нм это было весьма оправдано - они стойки к наводкам от пром.помех. А вот с переходом производителей на 28 нм (не помню, были ли микроконтроллеры на 45 нм, пропустил эту эпоху) началась "развлекуха" и гарантийные возвраты: столь тонкие нанометры ударно зависали, будучи установлены в общем цеху с импульсным или ВЧ оборудованием (лазерная резка, индукционный нагрев, ВЧ-сварка и т.п.), невзирая на качественно заземлённые металлические шкафы и экранированные кабели.
От вашего контроллера работы в таких условиях ожидать, конечно, глупо (ARM сдуется от куда меньших воздействий, в пластиковом-то корпусе)... Но все же хочется, чтоб монитор питания превосходил по стойкости к помехам основной камень хотя бы на порядок.
"Board temperature is below ...
WBEC_MINIMUM_WORKING_TEMPERATURE_C_X100
Поправьте вывод в лог
Как мы сделали Embedded Controller для ПЛК на Linux