Вообще-то правильным и логичным тоном в любой разработке считается применение встроенного в стенд такого источника питания, как и другой аппаратной части в виде уже существующих готовых модулей с требуемыми функциями и параметрами, которые в дальнейшем могут стать частью прототипа (репликация или как есть), при этом сегодня выбор таких готовых и выставленных на поток, как источников с в.у. характеристиками, так и других модулей, вполне позволяют вести их подбор в качестве универсальных компонентов к той архитектуре устройств, которые Вы разрабатываете сегодня или с идеями на завтра. Такой подход избавит Вас от дальнейших дополнительных затрат в создании прототипов или промышленных образцов.
Лучший интерфейс — тот, который делает жизнь проще, не заставляя задумываться, как он работает.
UX/UI - в свое время это для успеха был кусок работы чуть ли не самым главным в Data Sciense. Помню момент, когда клиенты просто визжали от удовольствия, когда в качестве интерфейса получали свой рабочий кабинет с видами столов и ящиками в которых они любили рыться, что-то находить, далее размещать в отдельные разноцветные папки и передавать их содержимое своим сотрудникам, те, в сою очередь принимали содержимое адресных папок к дальнейшим задачам, которые соответствовали их должности и инструкциям и т.д. и т.п. Ошибки исключались, т.к. в алгоритме были заложены запреты на ошибочные (человеческий фактор или нарушение последовательностей инструкций). Сейчас передо мной стоит более сложная задача - UX/UI IDE разработчика автоматики и робототехники где на ПК возлагаются задачи не только автоматизации процесса генерации исходного кода логического управления, но и функции логического контроллера под внешний I/O аппаратный интерфейс и здесь мне не совсем понятно, что в таком случае должен представлять из себя такой интерфейс(ы). Когда это кнопки с памятью вводимых состояний, дисплей часов для выставления там таймингов, селекторные кнопки для указания номеров USB портов и т.д. и т.п....
А еще практикуется такая фишка среди фрилансеров и всех их подопечных, когда они по договоренности с клиентами - крупными фирмами, демонстрируют другим потенциальным заказчикам "свои производственные площадки" которые по факту не являются ихними. Водят по цехам, IT отделам гостей как по зоопарку.
Почему бы и нет, спросите его, если это просто любопытство, а интерес к стороннему опыту все же продуктивней иметь из первоисточников, впрочем гигачат на данный момент дает вполне адекватное описание платформы и ее применение. :-
LV позволяет построить программную и аппаратную систему, которая выполняет те же функции, что и ОС, в условиях встраиваемых решений, промышленных контроллеров или систем реального времени. Это можно рассматривать как специализированную ОС-подобную среду, полностью разработанную в визуальной среде. Не полный перечень возможностей: Запуск кода на RT-контроллерах с детерминированным исполнением;
Управление потоками, приоритетами задач, прерываниями, синхронизацией и расписанием - то, что выполняет ядро RTOS;
Проектирование логического уровня "ядра" на уровне FPGA - реализация логики взаимодействия между устройствами, шин, интерфейсов; Разработка приложений с параллельными вычислениями, распределенной логикой и управлением событиями - по сути, имитация ядра ОС на прикладном уровне; Управление ресурсами, вводом/выводом, коммуникациями (Modbus, TCP/IP, CAN), памятью и задачами. Вы можете построить систему, где LabVIEW:
Управляет всеми задачами (как диспетчер процессов).
Имеет цикл реального времени с высоким приоритетом (как планировщик).
Реализует драйверы устройств (через FPGA или I/O Nodes).
Управляет прерываниями, вводом-выводом и хранением данных (как ядро).
Работает автономно на хардваре без традиционной ОС.
Важно понимать, что LabVIEW не создает ОС в классическом смысле, но позволяет построить программную и аппаратную систему, которая выполняет те же функции, что и ОС.
Как про "может быть сразу проверена на железе через стандартный USB GPIO.", думаю статья вышла бы не плохая.
здесь требуется конкретика, что проверять со стороны USB GPIO? Выше по ветке я дал описание решения которое применяется в программном контроллере, детали проекта обсуждаются здесь. Если у Вас возникнет желание выпустить авторскую публикацию на хабре с описанием платформы, окажу всяческое содействие. Я не писатель.
LabView это не ради "эмуляции ОС", а ради сокращения цикла "идея - исполнение" при разработке автономных логических систем.
Так что речь не про «берите любую IDE», а про осознанный выбор среды, в которой логика описывается так же наглядно, как монтируется схема — и может быть сразу проверена на железе через стандартный USB GPIO. Впрочем при желании на LV можно и OC создать, для чего, это уже другой вопрос.
Если вы имеете ввиду ПЛК, то с одной стороны мне абсолютно непонятно, как вы к этому внезапно пришли, а с другой стороны чем ПЛК принципиально отличается от микроконтроллера помимо того, что там зашит проприетарный софт ?
пришел не внезапно, а более чем 7 лет по озвученной Вами причине с уходом от проприетарности железа с его содержимым и того букета плюшек который он за собой тянет с клиента. Тема тянет не на одну статью, идея не из лучших отвлекать здесь кого либо на то, что здесь не предусмотрено к обсуждению. На данный момент это коробочное решение со всеми сопутствующими атрибутами и своим сообществом. Если интересно могу скинуть в личке.
Ваш подход тоже прекрасно эмулируется при наличии такого желания и точно так же при эмуляции потребует либо QMP либо решения подобного выше.
Любопытно узнать, возможна ли в QMP реализации или моделирования реального логического контроллера, исполняющего логику в потоке данных или по триггерам/флагам, как это делается в автоматных логических контроллерах? Насколько мне известно среда не дает таких средств разработки.
Логично, что эмуляторы вроде QEMU не моделируют экспандеры, в контексте статьи хотел лишь указать, что мой подход не заменяет эмуляцию, но показывает, что задачами управления можно заниматься на другом уровне абстракции — в зависимости от целей проекта.
Ни разу не встречал I2C GPIO расширителей интегрированных в SoC. И опять же если вы эмулируете в QEMU SBC с подключенным GPIO расширителем (неважно каким, главное, что вы его тоже эмулируете), перед вами встаёт та же самая проблема, что и с GPIO которые находятся непосредственно в SoC.
Как и Вы, в свое время я бился над такими задачами, у меня нет прямого ответа в плане - вот Вам SoC с интегрированным I2C GPIO-экспандером на базе PCF8574, MCP23017 и т.д., вместо этого я пришел к выводу - нет смысла искать I2C GPIO внутри SoC, когда можно построить работу ее логики вне SoC, взаимодействуя с периферией как в моем случае по USB + I2C, просто поменял стратегию когда это просто другой способ масштабирования ввода-вывода. Если интересно могу дать дисклеимер, но это выходит за рамки Вашей публикации.
некоторое время был одержим идеей «прозрачного» взаимодействия с устройствами внутри QEMU — использовать те же библиотеки
где в качестве host применили SBC + QEMU Я в нем не эмулировал ничего подобного, т.к. моя архитектурра CPUx86 и для подобных задач там больше пространства для творчества, вплоть до построения IDE. интеграция протокола I2C где для полноценной поддержки I²C GPIO-пины должны быть подключены к I²C-модулю внутри микроконтроллера (то есть быть назначены как SDA/SCL).
Это мой частный случай, в отличие от встроенных GPIO-контроллеров микроконтроллеров, в ПК-системах GPIOвозможныреализации через внешние модули, подключаемые по USB. Такие модули представляют собой интеллектуальные расширения, включающие в себя встроенные DAC/ADC, ARM-процессоры и интерфейсы связи (например, USB или RS-232, прочие конвертеры популярных протоколов). Управление осуществляется из основного программного обеспечения на ПК (хост) посредством программных микросервисов на базе FSM или API, обеспечивающие коммуникацию и логическое управление с каждым модулем. Если не понятно, конкретизируйте вопрос, как Вы указали x86, это не Ваш случай, отсюда и недопонимание.
Как то все сложно трактуется автором. По сути GPIO - это DAC или ADC с разведеными I/O пинами которые по дизайну могут быть как онбоард контроллере, так и виде его внешних расширений, соответственно с интерфейсом коммуникаций, к примеру в моем случае выходной USB GPIO это ADC который конвертирует частотный пакет сигналов со стороны контроллера в бинарные логические уровни в пределах 0,5 - 5V на 16 каналов с подтяжкой к земле. Что касается входного USB GPIO (у меня это целевой USB-RS232, отдельный модуль) ADC на 16 каналов который 12 bit обеспечивает счет напряжений в пределах от 0,001 - 3,300V. Оба модуля несут на себе ARM 32 и все управление ими происходит на внешних микросервисах. Как-то так.
Apple, как показатель, применяют очень строгие и высокотехнологичные методы очистки по требованиям IPC-TM-650, включая дозированный ультразвук, водную очистку при температурах 60–80С, в растворителях флюсов на основе н-пропилбромида, HFE-7100 и др.), совместимые с RoHS и REACH, так же присутствует редко и плазменная очистка. В финале обязательная проверка после мойки: ионная хроматография, спектроскопия, визуальный и X-ray контроль.
Мое мнение, эмоции ник чему. Система не должна проявлять сантименты, она должна служить во благо и процветание мирового сообщества, для решения мелких и крупных проблем, оказания помощи в научных исследованиях, не исключаю в т.ч. вопросы правосудия и контроля за его исполнением, вопросы административного управления городами и т.п.
Думаю эмоции - это следствие, а причина информация, которая повлияла на эмоциональное состояние. Если следовать такой логике, то на сегодня практически все текстовые платформы ИИ умеют определять эмоциональный стиль обрабатываемой текстовой информации и сам предлагает вариант стиля в котором можно составить ответ и т.п. Почему этот алгоритм не взять за отправную точку и заложить ее составляющие в динамике отображения эмоций на лицах виртуальных аватаров или антропоморфных роботизированных машин? Я больше чем уверен что это уже так и реализовано в прототипах тех, кто работает в этом направлении.
Не за что,как было сказано, в контекcте того, что Love Code, еще не для всех выглядит привычно. Особенно на классических IT-площадках, где правят бал pragmatic C++-чане и ментальные наследники Visual Studio.
Опрос неплохо показывает реакцию data science-ориентированной публики, с оговоркой что более чем 50% юзеров отмахнулись читать после прочтения заголовка. По ходу публикация не отражает ситуацию покрытия полного спектра задач. Как правило все упирается в веб разработку. Мне, например, не хватило позиций, связанных с автоматизацией кодирования в прототипировании, по взаимодействию с железом. Всё, что выходит за рамки анализа данных — как будто не в счёт.
Я уже просто плюнул и описал свой путь к собственной IDE (если что, блог на английском). Сейчас тестирую этот материал не вслепую, а среди профильных сообществ — инженеров, автоматчиков, разработчиков нестандартных систем. Там реакция куда продуктивнее, чем стрельба опросами по воробьям. Считаю это гораздо честнее и ближе к настоящему R&D.
Вообще-то правильным и логичным тоном в любой разработке считается применение встроенного в стенд такого источника питания, как и другой аппаратной части в виде уже существующих готовых модулей с требуемыми функциями и параметрами, которые в дальнейшем могут стать частью прототипа (репликация или как есть), при этом сегодня выбор таких готовых и выставленных на поток, как источников с в.у. характеристиками, так и других модулей, вполне позволяют вести их подбор в качестве универсальных компонентов к той архитектуре устройств, которые Вы разрабатываете сегодня или с идеями на завтра. Такой подход избавит Вас от дальнейших дополнительных затрат в создании прототипов или промышленных образцов.
UX/UI - в свое время это для успеха был кусок работы чуть ли не самым главным в Data Sciense. Помню момент, когда клиенты просто визжали от удовольствия, когда в качестве интерфейса получали свой рабочий кабинет с видами столов и ящиками в которых они любили рыться, что-то находить, далее размещать в отдельные разноцветные папки и передавать их содержимое своим сотрудникам, те, в сою очередь принимали содержимое адресных папок к дальнейшим задачам, которые соответствовали их должности и инструкциям и т.д. и т.п. Ошибки исключались, т.к. в алгоритме были заложены запреты на ошибочные (человеческий фактор или нарушение последовательностей инструкций).
Сейчас передо мной стоит более сложная задача - UX/UI IDE разработчика автоматики и робототехники где на ПК возлагаются задачи не только автоматизации процесса генерации исходного кода логического управления, но и функции логического контроллера под внешний I/O аппаратный интерфейс и здесь мне не совсем понятно, что в таком случае должен представлять из себя такой интерфейс(ы). Когда это кнопки с памятью вводимых состояний, дисплей часов для выставления там таймингов, селекторные кнопки для указания номеров USB портов и т.д. и т.п....
А еще практикуется такая фишка среди фрилансеров и всех их подопечных, когда они по договоренности с клиентами - крупными фирмами, демонстрируют другим потенциальным заказчикам "свои производственные площадки" которые по факту не являются ихними. Водят по цехам, IT отделам гостей как по зоопарку.
Почему бы и нет, спросите его, если это просто любопытство, а интерес к стороннему опыту все же продуктивней иметь из первоисточников, впрочем гигачат на данный момент дает вполне адекватное описание платформы и ее применение. :-
LV позволяет построить программную и аппаратную систему, которая выполняет те же функции, что и ОС, в условиях встраиваемых решений, промышленных контроллеров или систем реального времени. Это можно рассматривать как специализированную ОС-подобную среду, полностью разработанную в визуальной среде.
Не полный перечень возможностей:
Запуск кода на RT-контроллерах с детерминированным исполнением;
Управление потоками, приоритетами задач, прерываниями, синхронизацией и расписанием - то, что выполняет ядро RTOS;
Проектирование логического уровня "ядра" на уровне FPGA - реализация логики взаимодействия между устройствами, шин, интерфейсов;
Разработка приложений с параллельными вычислениями, распределенной логикой и управлением событиями - по сути, имитация ядра ОС на прикладном уровне;
Управление ресурсами, вводом/выводом, коммуникациями (Modbus, TCP/IP, CAN), памятью и задачами.
Вы можете построить систему, где LabVIEW:
Управляет всеми задачами (как диспетчер процессов).
Имеет цикл реального времени с высоким приоритетом (как планировщик).
Реализует драйверы устройств (через FPGA или I/O Nodes).
Управляет прерываниями, вводом-выводом и хранением данных (как ядро).
Работает автономно на хардваре без традиционной ОС.
Важно понимать, что LabVIEW не создает ОС в классическом смысле, но позволяет построить программную и аппаратную систему, которая выполняет те же функции, что и ОС.
здесь требуется конкретика, что проверять со стороны USB GPIO? Выше по ветке я дал описание решения которое применяется в программном контроллере, детали проекта обсуждаются здесь. Если у Вас возникнет желание выпустить авторскую публикацию на хабре с описанием платформы, окажу всяческое содействие. Я не писатель.
LabView это не ради "эмуляции ОС", а ради сокращения цикла "идея - исполнение" при разработке автономных логических систем.
Так что речь не про «берите любую IDE», а про осознанный выбор среды, в которой логика описывается так же наглядно, как монтируется схема — и может быть сразу проверена на железе через стандартный USB GPIO.
Впрочем при желании на LV можно и OC создать, для чего, это уже другой вопрос.
пришел не внезапно, а более чем 7 лет по озвученной Вами причине с уходом от проприетарности железа с его содержимым и того букета плюшек который он за собой тянет с клиента. Тема тянет не на одну статью, идея не из лучших отвлекать здесь кого либо на то, что здесь не предусмотрено к обсуждению. На данный момент это коробочное решение со всеми сопутствующими атрибутами и своим сообществом. Если интересно могу скинуть в личке.
Берите LabView, на нем можно делать всё.
Любопытно узнать, возможна ли в QMP реализации или моделирования реального логического контроллера, исполняющего логику в потоке данных или по триггерам/флагам, как это делается в автоматных логических контроллерах? Насколько мне известно среда не дает таких средств разработки.
Логично, что эмуляторы вроде QEMU не моделируют экспандеры, в контексте статьи хотел лишь указать, что мой подход не заменяет эмуляцию, но показывает, что задачами управления можно заниматься на другом уровне абстракции — в зависимости от целей проекта.
Как и Вы, в свое время я бился над такими задачами, у меня нет прямого ответа в плане - вот Вам SoC с интегрированным I2C GPIO-экспандером на базе PCF8574, MCP23017 и т.д., вместо этого я пришел к выводу - нет смысла искать I2C GPIO внутри SoC, когда можно построить работу ее логики вне SoC, взаимодействуя с периферией как в моем случае по USB + I2C, просто поменял стратегию когда это просто другой способ масштабирования ввода-вывода. Если интересно могу дать дисклеимер, но это выходит за рамки Вашей публикации.
Мне сразу в глаза ударило применение QEMU
где в качестве host применили SBC + QEMU
Я в нем не эмулировал ничего подобного, т.к. моя архитектурра CPUx86 и для подобных задач там больше пространства для творчества, вплоть до построения IDE.
интеграция протокола I2C где для полноценной поддержки I²C GPIO-пины должны быть подключены к I²C-модулю внутри микроконтроллера (то есть быть назначены как SDA/SCL).
Это мой частный случай, в отличие от встроенных GPIO-контроллеров микроконтроллеров, в ПК-системах GPIO возможны реализации через внешние модули, подключаемые по USB. Такие модули представляют собой интеллектуальные расширения, включающие в себя встроенные DAC/ADC, ARM-процессоры и интерфейсы связи (например, USB или RS-232, прочие конвертеры популярных протоколов). Управление осуществляется из основного программного обеспечения на ПК (хост) посредством программных микросервисов на базе FSM или API, обеспечивающие коммуникацию и логическое управление с каждым модулем.
Если не понятно, конкретизируйте вопрос, как Вы указали x86, это не Ваш случай, отсюда и недопонимание.
Как то все сложно трактуется автором. По сути GPIO - это DAC или ADC с разведеными I/O пинами которые по дизайну могут быть как онбоард контроллере, так и виде его внешних расширений, соответственно с интерфейсом коммуникаций, к примеру в моем случае выходной USB GPIO это ADC который конвертирует частотный пакет сигналов со стороны контроллера в бинарные логические уровни в пределах 0,5 - 5V на 16 каналов с подтяжкой к земле. Что касается входного USB GPIO (у меня это целевой USB-RS232, отдельный модуль) ADC на 16 каналов который 12 bit обеспечивает счет напряжений в пределах от 0,001 - 3,300V.
Оба модуля несут на себе ARM 32 и все управление ими происходит на внешних микросервисах.
Как-то так.
Существует статистика когда брак после сборки составляет 1%, надо безоговорочно менять сборщика, не важно по какой причине это происходит.
Apple, как показатель, применяют очень строгие и высокотехнологичные методы очистки по требованиям IPC-TM-650, включая дозированный ультразвук, водную очистку при температурах 60–80С, в растворителях флюсов на основе н-пропилбромида, HFE-7100 и др.), совместимые с RoHS и REACH, так же присутствует редко и плазменная очистка.
В финале обязательная проверка после мойки:
ионная хроматография, спектроскопия, визуальный и X-ray контроль.
Мое мнение, эмоции ник чему. Система не должна проявлять сантименты, она должна служить во благо и процветание мирового сообщества, для решения мелких и крупных проблем, оказания помощи в научных исследованиях, не исключаю в т.ч. вопросы правосудия и контроля за его исполнением, вопросы административного управления городами и т.п.
Думаю эмоции - это следствие, а причина информация, которая повлияла на эмоциональное состояние. Если следовать такой логике, то на сегодня практически все текстовые платформы ИИ умеют определять эмоциональный стиль обрабатываемой текстовой информации и сам предлагает вариант стиля в котором можно составить ответ и т.п. Почему этот алгоритм не взять за отправную точку и заложить ее составляющие в динамике отображения эмоций на лицах виртуальных аватаров или антропоморфных роботизированных машин? Я больше чем уверен что это уже так и реализовано в прототипах тех, кто работает в этом направлении.
Отправил в ЛС
Не за что,как было сказано, в контекcте того, что Love Code, еще не для всех выглядит привычно. Особенно на классических IT-площадках, где правят бал pragmatic C++-чане и ментальные наследники Visual Studio.
Опрос неплохо показывает реакцию data science-ориентированной публики, с оговоркой что более чем 50% юзеров отмахнулись читать после прочтения заголовка. По ходу публикация не отражает ситуацию покрытия полного спектра задач. Как правило все упирается в веб разработку. Мне, например, не хватило позиций, связанных с автоматизацией кодирования в прототипировании, по взаимодействию с железом. Всё, что выходит за рамки анализа данных — как будто не в счёт.
Я уже просто плюнул и описал свой путь к собственной IDE (если что, блог на английском). Сейчас тестирую этот материал не вслепую, а среди профильных сообществ — инженеров, автоматчиков, разработчиков нестандартных систем. Там реакция куда продуктивнее, чем стрельба опросами по воробьям. Считаю это гораздо честнее и ближе к настоящему R&D.