Я бы порекомендовал не автоматическую установку, а именно развертывание из образа т.к. это быстрее.
Запихивать все драйверы для множества устройств в систему действительно не выход, т.к. могут быть конфликты драйверов. Я не знаю стандартного бесплатного инструмента от МС, который позволяет устанавливать только те драйверы, которые нужны. Но, как и описано в статье, Вы можете сделать собственный скрипт или утилиту, которая по вендорам устройств определит какие именно драйверы нужны для оборудования.
В Вашей ситуации можно рассмотреть следующий вариант.
Чтобы после загрузки по сети WinPE могла работать с любой сетевой картой можно положить необходимые драйверы в boot.wim, который загружается по сети. Если таких драйверов мало и конфликтов не будет, то их можно запихнуть с помощью DISM’а. А если будут конфликты, то определив по вендору устройства какой именно драйвер нужен его можно подгрузить прямо в WinPE с помощью утилиты Drvload.
Когда WinPE сможет работать с сетевым адаптером можно подключить сетевую папку, где будут драйверы для контроллера диска, опять же придется определить по вендору оборудования какой именно драйвер нужен и подгрузить его чтобы WinPE увидела диск.
Хотя, можно попробовать вариант добавления пути в файл ответов автоматической установки, но опять же в Вашей ситуации в данной папке должны оказаться только подходящие драйверы, чтобы не было конфликтов. И опять их придется отсеивать по вендору устройства.
Собственно, здесь ответ и на второй вопрос, можно сделать свою единую базу драйверов, но для установки конкретных необходимых драйверов понадобится скрипт или утилита. Получить перечень вендоров устройств в текущей системе можно, например, с помощью WMIC.
WMIC PATH Win32_PnPSignedDriver where "DeviceID like 'ACPI%'" GET DeviceID /value
Если посмотрите в tx_thread_context_save.s и tx_thread_context_restore.s, там эти функции представляют собой заглушки, которые ничего не делают, с комментарием о том, что для этого порта (Cortex-M4) они не требуются.
Если хотите бОльшей портируемости, можно добавить этот вызов. Куда именно — зависит от порта, но общее правило — в самое начало обработчика, именно «ближе к аппаратному уровню».
Но не факт, что при портировании на другую архитектуру останется та же обработка прерываний (и те же обработчики), так что эту часть, возможно, все равно придется впоследствии переписывать, так что портируемость выходит немного спорная.
1. Исходники в данной IDE должны попадать в сборку по факту присутствия в дереве. Вы обновили дерево после их добавления? Middlewares (вместе с Core и Drivers) по умолчанию уже входит в дерево, соответственно попадание в нее threadx-master должно привести к их включению. Может, в дереве, внутри Middlewares они у вас исключены из компиляции? На всякий случай включу в материал проверку настроек на предмет Source Location, спасибо за замечание.
2. Действительно, из контекста может быть неочевидно. Спасибо, поправим.
По частоте переключения LED: проверьте в стартовом коде настройки SYSTEM_CLOCK, SYSTICK_CYCLES.
По прерыванию: поскольку у вас не та плата, для которой настраивается Cube, посмотрите, есть ли подтяжка вниз на плате, если нет, включите программную. Если подтяжка вверх, измените в Cube фронт прерывания. Убедитесь, что на линии, куда подключена кнопка, есть внешнее прерывание, и что у него нужный номер. Убедитесь с отладчиком, что срабатывает обработчик прерывания и выставляется событие, далее что оно обрабатывается. Где-то в этой цепочке что-то найдете.
Не стоит этого делать, const придуман не просто так. Если указатель «приводить» к чему-то со снятием const, то где-нибудь в недрах кода при попытке записи по этому адресу (компилятор это вполне пропустит, если вы сняли const) могут возникнуть неприятности.
Здесь дело не в самой версии (я работал с 6.0), а в коммите. За одну версию, в принципе, можно сделать несколько коммитов. Даже если переправить на новую версию — через некоторое время master опять может накопить изменения, и ситуация повторится. Уже сейчас изменена структура, добавлены порты под новые архитектуры (что очень хорошо!), и примеры кода для разных IDE (а это означает, что там есть уже готовые шаблоны проектов!). Думаю, мы это используем в следующей части.
Суть материала в том, что мы показываем сам процесс запуска ОС «с нуля», и если вы это все проделаете, то поймете сам принцип, что и как устроено.
По сути вопроса:
1) версию можно посмотреть в tx_api.h
2) если все же хотите работать с последним коммитом, то изменится структура директорий, а tx_initialize_low_level_sample.S, действительно, переименовали в tx_initialize_low_level.S, разместили по пути ports\cortex_m4\gnu\example_build (для CubeIDE). Частоту SYSCLK можно задать в нем же. Скопируете куда-то еще — ничего не порушится, главное, чтобы файл участвовал в сборке.
3) поскольку в master добавили новых файлов (это все-таки значительное изменение), придется думать, что включать в сборку, а что нет. Нужен порт под M4.
4) tx_vector_table_sample.S не требуется. Таблица векторов прерываний уже есть в стартовом коде от CubeIDE, мы лишь слегка адаптируем ее для ThreadX.
Вы правы. Чтобы поправить, лучше всего убрать const в объявлении структуры BoardLedsSettings. Поправил код. У меня, правда, код почему-то нормально собрался и с const, хотя не должен был.
По второму вопросу: возьмите тот же коммит, который указан в статье. Причина описана в комментарии выше.
Проблема в том, что за время от написания материала до его публикации ветка master ушла вперед, и структура директорий поменялась, поэтому теперь есть такие несовпадения. Чтобы все было точно как в статье, нужен определенный коммит. Добавил информацию в статью.
Каждой задаче — свой инструмент. Это как сравнивать PHP и ASP.Net: много факторов, влияющих на выбор. Иногда существенное влияние на выбор оказывает даже то, с чем вы больше знакомы/больше работали, или с чем принято работать в вашей организации.
По сути вопроса: в статье есть описание преимуществ Azure RTOS с технической стороны + ссылка на сравнение с FreeRTOS от инженера, который работает с обеими ОС (если вкратце, то там речь идет о том, что обе ОС хороши, но именно технически ThreadX по ряду причин выглядит несколько более совершенной).
Добавлю, что Azure RTOS сертифирована по нескольким стандартам безопасности. Впрочем, тем же (но в несколько меньшем наборе стандартов) может похвастаться SafeRTOS, но это уже не совсем FreeRTOS. Опять же, приходим к тому, что разных RTOS много, и каждая из них — это инструмент. Знание характеристик разных инструментов позволит подобрать лучший под конкретную задачу.
Графика, действительно, обычно не привязана к RTOS, но некоторые библиотеки могут быть оптимизированы под конкретную RTOS.
Насчет использования в один клик в CubeMX, я думаю, это дело времени. Надо написать обертку CMSIS-RTOS для ThreadX, и тогда процесс начальной настройки и перехода на систему будет гораздо проще. На данный момент все необходимые операции по интеграции ThreadX в проект (причем не обязательно именно в CubeIDE) достаточно проделать один раз, а потом можно использовать проект как шаблон.
По поводу обработки ошибок: в учебных примерах возвращаемые коды/ошибки обычно не проверяют (для краткости и чтобы сосредоточиться на сути изучаемого предмета) и упоминают, что код не для продакшена. В рассмотренном примере код довольно простой, и ломаться там особо нечему. Но в следующей части учтем замечание и проверку возвращаемых кодов сделаем.
Увы, для введения в какую-то тему всегда приходится брать какие-то очень простые, искусственные задачи, и это в общем-то не только в электронике. Если начинать сразу с задачи, в которой вот прямо реально не обойтись без RTOS, есть риск получить довольно громоздкую и малопонятную статью.
Без RTOS именно данная задача вполне решается, но сам прикладной код будет менее изящным. Например, так: делается один таймер, который отсчитывает временные интервалы. Время включения/выключения светодиода должно быть кратным одному временному интервалу. Для каждого светодиода подсчитывается количество интервалов, и в нужный момент светодиод гаснет/зажигается.
Когда мы рассматриваем микроконтроллеры, речь идет о том, что рано или поздно появится задача, где обойтись без RTOS будет как минимум затруднительно. Когда от «лампочек и кнопочек» вы перейдете к чему-то более масштабному, например, TCP/IP, поверх него FTP, и файлы по этому FTP будут записываться на USB флешку — вот тогда могут начаться сложности. Нельзя, конечно, сказать, что такие задачи без RTOS вообще не решаемы, но применение RTOS может очень сильно упростить процесс разработки.
Также RTOS дает некоторые, грубо говоря, архитектурные преимущества. Например, при вызове функции задержки в RTOS задача «усыпляется», и планировщик передает управление другим задачам, а не заставляет процессор крутится в пустом цикле. Т.е. пока задача «ждет», другие задачи могут сделать что-то еще полезное, при этом логика «ждущей» задачи не «разрывается».
Экономическая информация не собиралась, т.к. этого в пилотном проекте не требовалось, но реализовать это можно, технических ограничений в этом плане нет.
Что касается срока хранения данных: поскольку это SaaS, то мы так или иначе ограничены его возможностями, но ничто не мешает сделать экспорт данных (поддерживаются разные варианты) и хранить их, сколько нужно. Собственно, для этого экспорт и нужен.
Насчет «локального Azure» — есть такое понятие как Azure Stack, его продает МТС, например. Но функционально он очень сильно не дотягивает до «большого» Azure, поэтому смысла в его использовании для задач IoT нет. Разумеется, никто не мешает создать локальное решение, но это деньги и время.
Вообще, «локальное использование» противоречит самой концепции Azure, как сервиса, доступного в любой точке мира. А если ваш клиент в Беларуси или Украине, то ситуация становится ровно обратная — изоляция отключит их от вашего русского сервера. Если «отключат Интернет» — то да, в РФ работать перестанет. Но тогда перестанет много чего работать. Мне кажется, такие разговоры уже прекратились.
В случае, описанном в статье, речь шла именно о централизованном отслеживании, когда на одной панели мониторинга будет видно «сразу все». Киоски изначально имели подключение к Интернету по условию задачи, т.к. оттуда берутся данные для пользователя. Нет сети — киоск в принципе не работает, как надо (кстати, этот случай при централизованном мониторинге тоже можно отследить, в статье описано, как именно).
Если вопрос в том, что делать при временном пропадании сети, то можно добавить в решение IoT Edge, который прозрачно все закэширует и при появлении сети отправит данные в облако. Это вообще достаточно мощный продукт, который очень много может помимо собственно кэширования данных.
Если вопрос в том, что делать, если сети вообще нет, или она уж очень плохого качества, стоит подумать о резервном канале связи, либо отказаться от использования облака и думать о каком-то локальном решении.
Но тогда это решение уже не будет централизованным, да и в чем смысл локального решения? Локально вы и так видите, что с устройством происходит. Пожалуй, такое «локальное» решение подойдет только для каких-то очень крупных объектов (торговый центр без подключения к Интернету?..), в этом случае можете сделать его на IoT Edge, сделать что-то свое, или взять готовый продукт (например, www.quarta-embedded.ru/products/monitoring-management) и интегрировать в него свои процедуры мониторинга.
Многое зависит от ситуации. Навигация по сайту рассмотрена как пример, для демонстрации некоторых возможностей системы. Если рассматривать решение, которое нужно интегрировать в уже имеющуюся инфраструктуру заказчика, то интеграция решений на никсовых системах может стоить дороже, чем покупка более производительных устройств с лицензионной операционной системой.
Многое зависит от ситуации. Навигация по сайту рассмотрена как пример, для демонстрации некоторых возможностей системы. Если рассматривать решение, которое нужно интегрировать в уже имеющуюся инфраструктуру заказчика, то интеграция решений на никсовых системах может стоить дороже, чем покупка более производительных устройств с лицензионной операционной системой.
Спасибо за ваши вопросы. Отвечаю:
— IoT — Internet of Things — «Интернет Вещей». Своими словами — совокупность технологий для обеспечения сбора данных с устройств и передачи их в «облако» с целью более эффективного мониторинга, управления и аналитики.
— Операционная система Windows 10 Enterprise IoT, о которой говорится в статье, предназначена для создания «наземных» устройств Embedded (или «IoT» в новой терминологии) и является продолжением линейки продуктов Windows Embedded. К сожалению, Microsoft в очередной раз запутал пользователей новыми названиями и версиями. Это породило массу вопросов и в целом — неразбериху на рынке. Цель данной статьи — дать разъяснения по отличиям как в дистрибутивах, так и в лицензировании (в формате FAQ), что мы, как дистрибутор Windows Embedded/IoT-версий и сделали. Т.е. это — реальные вопросы, которые нам задают почти каждый день и ответы на них.
Добавлю — т.к. этим FAQ вопросы явно не ограничиваются, можно задавать новые в комментариях — постараемся оперативно ответить.
Надеемся, нам удалось донести мысль, что операционная система — сама может быть полноценным субъектом разработки аналогично прикладному или специализированному программному обеспечению. И средства для этого есть.
Я бы порекомендовал не автоматическую установку, а именно развертывание из образа т.к. это быстрее.
Запихивать все драйверы для множества устройств в систему действительно не выход, т.к. могут быть конфликты драйверов. Я не знаю стандартного бесплатного инструмента от МС, который позволяет устанавливать только те драйверы, которые нужны. Но, как и описано в статье, Вы можете сделать собственный скрипт или утилиту, которая по вендорам устройств определит какие именно драйверы нужны для оборудования.
В Вашей ситуации можно рассмотреть следующий вариант.
Чтобы после загрузки по сети WinPE могла работать с любой сетевой картой можно положить необходимые драйверы в boot.wim, который загружается по сети. Если таких драйверов мало и конфликтов не будет, то их можно запихнуть с помощью DISM’а. А если будут конфликты, то определив по вендору устройства какой именно драйвер нужен его можно подгрузить прямо в WinPE с помощью утилиты Drvload.
Когда WinPE сможет работать с сетевым адаптером можно подключить сетевую папку, где будут драйверы для контроллера диска, опять же придется определить по вендору оборудования какой именно драйвер нужен и подгрузить его чтобы WinPE увидела диск.
Хотя, можно попробовать вариант добавления пути в файл ответов автоматической установки, но опять же в Вашей ситуации в данной папке должны оказаться только подходящие драйверы, чтобы не было конфликтов. И опять их придется отсеивать по вендору устройства.
Собственно, здесь ответ и на второй вопрос, можно сделать свою единую базу драйверов, но для установки конкретных необходимых драйверов понадобится скрипт или утилита. Получить перечень вендоров устройств в текущей системе можно, например, с помощью WMIC.
Если хотите бОльшей портируемости, можно добавить этот вызов. Куда именно — зависит от порта, но общее правило — в самое начало обработчика, именно «ближе к аппаратному уровню».
Но не факт, что при портировании на другую архитектуру останется та же обработка прерываний (и те же обработчики), так что эту часть, возможно, все равно придется впоследствии переписывать, так что портируемость выходит немного спорная.
2. Действительно, из контекста может быть неочевидно. Спасибо, поправим.
По частоте переключения LED: проверьте в стартовом коде настройки SYSTEM_CLOCK, SYSTICK_CYCLES.
По прерыванию: поскольку у вас не та плата, для которой настраивается Cube, посмотрите, есть ли подтяжка вниз на плате, если нет, включите программную. Если подтяжка вверх, измените в Cube фронт прерывания. Убедитесь, что на линии, куда подключена кнопка, есть внешнее прерывание, и что у него нужный номер. Убедитесь с отладчиком, что срабатывает обработчик прерывания и выставляется событие, далее что оно обрабатывается. Где-то в этой цепочке что-то найдете.
Суть материала в том, что мы показываем сам процесс запуска ОС «с нуля», и если вы это все проделаете, то поймете сам принцип, что и как устроено.
По сути вопроса:
1) версию можно посмотреть в tx_api.h
2) если все же хотите работать с последним коммитом, то изменится структура директорий, а tx_initialize_low_level_sample.S, действительно, переименовали в tx_initialize_low_level.S, разместили по пути ports\cortex_m4\gnu\example_build (для CubeIDE). Частоту SYSCLK можно задать в нем же. Скопируете куда-то еще — ничего не порушится, главное, чтобы файл участвовал в сборке.
3) поскольку в master добавили новых файлов (это все-таки значительное изменение), придется думать, что включать в сборку, а что нет. Нужен порт под M4.
4) tx_vector_table_sample.S не требуется. Таблица векторов прерываний уже есть в стартовом коде от CubeIDE, мы лишь слегка адаптируем ее для ThreadX.
По второму вопросу: возьмите тот же коммит, который указан в статье. Причина описана в комментарии выше.
По сути вопроса: в статье есть описание преимуществ Azure RTOS с технической стороны + ссылка на сравнение с FreeRTOS от инженера, который работает с обеими ОС (если вкратце, то там речь идет о том, что обе ОС хороши, но именно технически ThreadX по ряду причин выглядит несколько более совершенной).
Добавлю, что Azure RTOS сертифирована по нескольким стандартам безопасности. Впрочем, тем же (но в несколько меньшем наборе стандартов) может похвастаться SafeRTOS, но это уже не совсем FreeRTOS. Опять же, приходим к тому, что разных RTOS много, и каждая из них — это инструмент. Знание характеристик разных инструментов позволит подобрать лучший под конкретную задачу.
Графика, действительно, обычно не привязана к RTOS, но некоторые библиотеки могут быть оптимизированы под конкретную RTOS.
Насчет использования в один клик в CubeMX, я думаю, это дело времени. Надо написать обертку CMSIS-RTOS для ThreadX, и тогда процесс начальной настройки и перехода на систему будет гораздо проще. На данный момент все необходимые операции по интеграции ThreadX в проект (причем не обязательно именно в CubeIDE) достаточно проделать один раз, а потом можно использовать проект как шаблон.
Как раз думаем над темой для следующей части.
По поводу обработки ошибок: в учебных примерах возвращаемые коды/ошибки обычно не проверяют (для краткости и чтобы сосредоточиться на сути изучаемого предмета) и упоминают, что код не для продакшена. В рассмотренном примере код довольно простой, и ломаться там особо нечему. Но в следующей части учтем замечание и проверку возвращаемых кодов сделаем.
Без RTOS именно данная задача вполне решается, но сам прикладной код будет менее изящным. Например, так: делается один таймер, который отсчитывает временные интервалы. Время включения/выключения светодиода должно быть кратным одному временному интервалу. Для каждого светодиода подсчитывается количество интервалов, и в нужный момент светодиод гаснет/зажигается.
Когда мы рассматриваем микроконтроллеры, речь идет о том, что рано или поздно появится задача, где обойтись без RTOS будет как минимум затруднительно. Когда от «лампочек и кнопочек» вы перейдете к чему-то более масштабному, например, TCP/IP, поверх него FTP, и файлы по этому FTP будут записываться на USB флешку — вот тогда могут начаться сложности. Нельзя, конечно, сказать, что такие задачи без RTOS вообще не решаемы, но применение RTOS может очень сильно упростить процесс разработки.
Также RTOS дает некоторые, грубо говоря, архитектурные преимущества. Например, при вызове функции задержки в RTOS задача «усыпляется», и планировщик передает управление другим задачам, а не заставляет процессор крутится в пустом цикле. Т.е. пока задача «ждет», другие задачи могут сделать что-то еще полезное, при этом логика «ждущей» задачи не «разрывается».
Windows 10 IoT Enterprise 2019 не будет работать на Raspberry. Действия выполнялись на x86.
Что касается срока хранения данных: поскольку это SaaS, то мы так или иначе ограничены его возможностями, но ничто не мешает сделать экспорт данных (поддерживаются разные варианты) и хранить их, сколько нужно. Собственно, для этого экспорт и нужен.
Вообще, «локальное использование» противоречит самой концепции Azure, как сервиса, доступного в любой точке мира. А если ваш клиент в Беларуси или Украине, то ситуация становится ровно обратная — изоляция отключит их от вашего русского сервера. Если «отключат Интернет» — то да, в РФ работать перестанет. Но тогда перестанет много чего работать. Мне кажется, такие разговоры уже прекратились.
Если вопрос в том, что делать при временном пропадании сети, то можно добавить в решение IoT Edge, который прозрачно все закэширует и при появлении сети отправит данные в облако. Это вообще достаточно мощный продукт, который очень много может помимо собственно кэширования данных.
Если вопрос в том, что делать, если сети вообще нет, или она уж очень плохого качества, стоит подумать о резервном канале связи, либо отказаться от использования облака и думать о каком-то локальном решении.
Но тогда это решение уже не будет централизованным, да и в чем смысл локального решения? Локально вы и так видите, что с устройством происходит. Пожалуй, такое «локальное» решение подойдет только для каких-то очень крупных объектов (торговый центр без подключения к Интернету?..), в этом случае можете сделать его на IoT Edge, сделать что-то свое, или взять готовый продукт (например, www.quarta-embedded.ru/products/monitoring-management) и интегрировать в него свои процедуры мониторинга.
Спасибо за ваши вопросы. Отвечаю:
— IoT — Internet of Things — «Интернет Вещей». Своими словами — совокупность технологий для обеспечения сбора данных с устройств и передачи их в «облако» с целью более эффективного мониторинга, управления и аналитики.
— Операционная система Windows 10 Enterprise IoT, о которой говорится в статье, предназначена для создания «наземных» устройств Embedded (или «IoT» в новой терминологии) и является продолжением линейки продуктов Windows Embedded. К сожалению, Microsoft в очередной раз запутал пользователей новыми названиями и версиями. Это породило массу вопросов и в целом — неразбериху на рынке. Цель данной статьи — дать разъяснения по отличиям как в дистрибутивах, так и в лицензировании (в формате FAQ), что мы, как дистрибутор Windows Embedded/IoT-версий и сделали. Т.е. это — реальные вопросы, которые нам задают почти каждый день и ответы на них.
Добавлю — т.к. этим FAQ вопросы явно не ограничиваются, можно задавать новые в комментариях — постараемся оперативно ответить.
Спасибо!