Вопросы использования Intel Atom для embedded realtime задач

    После того, как архитектура Atom проявила себя в нетбуках, некоторые компании стали использовать Atom для Embedded Realtime применений. Делают промышленные контроллеры, гоняют на них PLC код.

    Те же чипы, что и в нетбуке обычно на заводах не используют. Есть специальный платформы. Сначала был Crown Beach, сейчас начинает использоваться в дизайнах Queens Bay. Для IVI (автомобильный компьютер) есть своя платформа.

    Естественно, удовлетворение realtime требований — необходимое условие. Об этом подробнее под катом.

    Что такое «realtime», применительно к x86? Есть много критериев. Чаще всего самое первое требование — чтобы между срабатыванием прерывания и началом исполнения кода его обработчика(ISR) должно проходить гарантированое время. Для кого-то это 2 микросекунды, для кого-то 10, некоторые готовы мириться даже с 20 микросекундной задержкой. Со 100 микросекундной задержкой, пусть и случающейся раз в неделю, мало кто готов работать.

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

    Процессоры семейства Atom работают достаточно шустро, есть SIMD. В отличие от обычных десктопных/нетбучных вариантов, чипы, включенные Intel в Embedded Roadmap поддерживаются и производятся долго (от 7 до 10 лет). На x86 разрабатывать софт или использовать готовый сравнительно просто — все-таки самая распространенная архитектура. Еще полезна VT — аппаратная поддержка виртуализации. Например, только на x86 можно достаточно шустро гонять одновременно RTOS для контроля оборудования и Windows XP для GUI. Кстати, в этой отрасли модно называть пользовательский интерфейс не GUI, а HMI (Human Machine Interface). А раньше было MMI. Типа, раньше со станками работали мужчины, а теперь — человеские существа.

    Если уж я написал — «задержка прерывания», то надо определить — какого именно. legacy, MSI, local? Два самых важных случая — local APIC timer, и MSI-X прерывания от периферии.

    Какие ОС используются? VxWorks, Integrity, QNX, Windows СЕ, сильно допиленный Linux. Бывает, используется Windows Embedded и даже обычная Windows XP SP3. В последних случаях realtime код исполняется исключительно в ISR.

    Как измерять? Это зависит от ОС. На Windows можно использовать DPC analyzer от Microsoft. Если есть проблема с задержкой ISR, то задержки DPC тоже будут. Но не наоборот. Поэтому это неплохой индикатор, но не на 100% точный. Я иногда пользуюсь Beckhoff Twincat. (Кстати, Beckhoff как раз умеют делать hard realtime промышленные контроллеры на обычной Windows XP) С сайта можно скачать ознакомительную версию, запустить пустой проект, и смотреть задержки прерывания от local APIC timer. Самый простой и точный способ под Windows. Так не сложно проверить, подойдет ли ваш нетбук в роли контроллера для современного фрезеровочного станка или промышленного робота. Если подойдет, то есть шанс, что даже дополнительного железа не понадобится — если вдруг у станка есть дырка для управления через EtherCAT.

    Аналогичный драйвер, измеряющий время до обработчика прерывания для Linux из 100 строчек пишется за полдня, или можно просто попатчить 20 строчек в drivers/rtc/rtc-cmos.c, чтобы выводил среднюю задержку.

    Почему на Atom вообще возможна задержка прерывания более чем на 5 микросекунд? Например, на всех X86 процессорах есть SMI — очень большое зло с точки зрения промышленного контроллера. Также есть полезная инструкция — WBINV. Выполнит ее какой-нибудь драйвер — и придется обработчику прерывания сначала долго тащить данные из памяти. Есть еще несколько возможных причин. Со всем этим можно бороться.

    Кроме предсказуемости времени запуска обработчика прерывания, код в ISR тоже должен работать с постоянной производительностью. Два основных фактора, которые могут уменьшать предсказуемость — общий кэш и гипертрединг. К сожалению, наиболее энергоэффективные процессоры Atom — одноядерные. Гипертрединг помогает получить несколько лучшую производительность, но сказывается на предсказуемости исполнения кода в RTOS, если на hyperthread одновременно работает GPOS. Об этом можно написать отдельную статью, если это было бы кому-нибудь интересно.
    Intel
    166,00
    Компания
    Поделиться публикацией

    Комментарии 18

      +2
      поток сознания
        +1
        Тема интересная, но читать такое очень сложно — постоянно возникает ощущение, что переводили автоматическим переводчиком или русский язык для автора не родной. Много ошибок. Пожалуйста, пишите еще на такие темы, но по возможности воспользуйтесь услугами редактора/корректора.
          +1
          Согласен с критикой, действительно очень редко пишу по-русски. Отсюда ошибки (что-то не так с пунктуацией? орфографию вроде-бы редактор проверил), и печатаю медленно. Единственный способ не разучиться — писать такие топики, наверное.

          Было любопытно, интересно ли вообще кому-то читать про то, на сколько микросекунд может задержаться прерывание, чтобы станок не сломался, и как это измерить. Кто этим занимается — и так все знают, а большинству разработчиков, которые занимаются Веб, базами данных, эта информация бесполезна.
          0
          Интересно, но не хватает примеров, особенно уровня «Вася сделал себе для дома realtime и у него всё стало хорошо» ;)
            +1
            В том-то и дело что _такой_ риалтайм себе для дома делать абсолютно незачем. Так что статья в чистом виде о бесполезном знании.

            Если область любопытна, можно, например, скачать по ссылке из поста Twincat и сделать 2 вещи.
            1. Измерить, можно ли использовать текущее железо, если вдруг найдется доступ к станкам. Если все ок, можно гордиться.
            2. Попробовать написать и запустить какую-нибудь PLC программу, которая правда все равно ничего полезного делать не может, т.к. комп ни к чему не подключен.
            +2
            Ваше определение RealTime потрясает новизной!!! А уж «применительно к x86»…
            Это не RealTime! Определение RealTime вообще от платформы не зависит. Что х86, что ARM, что RISC…
            То что Вы написали кое как тянет на latency. Но это лишь один из параметров. И вовсе не всегда самый важный, имхо.
            Существует много систем, где 100 микросекунд задержки вполне допустимы, правда не «раз в неделю»…
              0
              Отлично, первый коммент по сути статьи, спасибо.

              Согласен с Вашим комментом: 1. определение realtime не имеет ничего общего с latency прерывания.
              Специально в самом начале написал, что realtime — это «удовлетворение многим критериям». Если брать готовое приложение — то это в трех словах «гарантия времени реакции». 2. Есть много систем, где задержка прерывания в 100 микросекунд допустима.

              Но пост о железе E-линейки Атомов, поэтому я взял самую первую latency, которая, если может иногда быть больше некоторого предела, гарантирует бесполезность платформы, вне зависимости от ОС и приложения. Пост был о том, как это измерять, и немного коснулся того, как с этим бороться.

                0
                Насчет «interrupt latency — вовсе не всегда самый важный, параметр.»

                Мы смотрим с разных сторон — для меня это часто самый важный параметр, т.к. если есть проблема, клиент может выбрать не Intel железо. Поэтому если вдруг кто-то жалуется, что на платформе, которую я поддерживаю, возможно в каких-то условиях непредсказуемое увеличение interrupt latency, то моя самая срочная задача — найти причину и фикс.
                +1
                а QNX — где?
                  0
                  Сорри, давно лично не сталкивался. Скорее всего, должна быть. Вписать?
                    0
                    Статья Ваша.
                    Но написав о ОС реального времени не упомянуть QNX…
                    я же не говорю про возможность в ядре OpenBSD — это как раз таки не существенно.
                      0
                      Спасибо, добавил. Слишком зациклился на своем опыте.
                        0
                        Я толком тоже не трогал, она стоит неприлично дорого да и не нужна.
                        Но ее используют повсюду, например — мозги автомобилей, ядерные реакторы, да даже Cisco
                        +1
                        Да померла уже QNX. Упоминать в одном предложении QNX и Realtime — это просто традиция уже.
                          0
                          ЖД и ещё много используют во всю. У QNX много разных сертификатов и лицензий. Больше ни у кого такого нет.
                            0
                            Там где было — там оставили конечно. Но нового ничего не встречал.
                    +1
                    Интересно бы было бы услушать слово Stellarton в этом контексте, а особенно комментарии к этому
                      +1
                      Сорри, пока о SoC с FPGA на борту не могу сказать ничего, сверх того, что было на IDF.

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

                    Самое читаемое