Что такое модуль dpio
Перестал работать PCI-девайс 🙁
Написал простенькую прогу, обмен проиходит по известному алгоритму, скопированному из досовской проги, из «железных» функций использую только in_p, out_p, iopl(). Всё работало зашибись.
Потом, когда делал к проге всякие навороты, плата вдруг работать перестала. Причём не работают даже первые примитивные варианты проги, которые раньше работали.
Кроме того, теперь при загрузке комп выдаёт (можно потом посмотреть с помощью dmesg):
Пробовал презагружаться, пихать плату в другой pci-слот, загружаться через recovery mode. Не помогает, все порты остаются disabled:( При этом в DOS’е всё работает окей, и на другой машине в Xubuntu всё окей.
В самой плате, вроде, ничего нет, что можно было бы сломать экспериментами с ПО. Неужели механически, что-то треснуло? Глазами повреждений не нашёл, контакты протирал. Да и в ДОСе всё работает.
Что тут можно сделать в принципе? Может в самой Убунте можно как-то обнулить записи про эту плату, сделать так, чтоб порты не были disabled?
BIOS пробовал сбрасывать? Еще может в платке прошивка своя сырая.
а на той же машинке, но с лайв убунты работает? кстати если в досе работает, то просто не может быть такого что с платой что-то нарушено, кстати другие девайсы в pci там звуковая или сеть работают?
BIOS пробовал сбрасывать? Еще может в платке прошивка своя сырая.
Пока не пробовал, завтра попробую. Может ещё стоит поэкспериментировать с номерами прерываний?
а на той же машинке, но с лайв убунты работает?
Не, и с лайва не работает 🙁 Не могу понять, что может быть такого, что в ДОСе работает, а в убунте блокируется(
кстати если в досе работает, то просто не может быть такого что с платой что-то нарушено, кстати другие девайсы в pci там звуковая или сеть работают?
Всё остальное работает. Но есть один момент. на старом компе, на котором Xubuntu, если эту плату ткнуть в определённый слот, то видюха не работает) а если в другой слот, то всё как надо) ну это наверно уже к вопросу об архитектуре современных PC, тут мне кажется проблема с портами не при чём:)
Твое это устройство поддерживает Plug and Play? Не рассматривал вариант, что у него конфликт прерываний с чем-то из оборудования?
Возможно, твоя плата хочет использовать смежные ресурсы с какой-то из железяк, установленных в компьютер. А работает в ДОСе по причине того, что в ДОСе не подгружается драйвер под конфликтующую железяку и она не активна.
Твое это устройство поддерживает Plug and Play?
хз.. плату сделали на работе, по сути это АЦП, который общается по PCI с компом с помощью PLX9050. Попробую узнать. Если нет, то это очень плохо?:)
Не рассматривал вариант, что у него конфликт прерываний с чем-то из оборудования?
Была такая мысль, сейчас думаю как бы отследить, где именно конфликт.
Возможно, твоя плата хочет использовать смежные ресурсы с какой-то из железяк, установленных в компьютер. А работает в ДОСе по причине того, что в ДОСе не подгружается драйвер под конфликтующую железяку и она не активна.
Толковая идея, буду пробовать разобраться. Спасибо!
хз.. плату сделали на работе, по сути это АЦП, который общается по PCI с компом с помощью PLX9050. Попробую узнать. Если нет, то это очень плохо?:)
Это не плохо, просто означает, что ОС не знает какие параметры нужны устройству для корректного функционирования, и эти параметры как-то надо задать руками.
Была такая мысль, сейчас думаю как бы отследить, где именно конфликт.
Отключи всю периферию и максимум интегрированных устройств
>Всё остальное работает. Но есть один момент. на старом компе, на котором Xubuntu, если эту плату ткнуть в определённый слот, то видюха не работает) а если в другой слот, то всё как надо) ну это наверно уже к вопросу об архитектуре современных PC, тут мне кажется проблема с портами не при чём
Если на компе той эпохи распаяны все пять разъёмов PCI, то первый и пятый делят между собой ресурсы.
ARM MBED OS. Работа с произвольным МК STM32 под PlatformIO
Когда в январе сего года я писал материал о файловой системе LittleFS (интегрированной в состав arm mbed os), то обещал в скорейшем времени описать создание проекта с arm mbed os для произвольного микроконтроллера STM32. Как известно, онлайн IDE от ARM (а точнее, выделенного подразделения Arm mbed) поддерживает, во-первых, строго определенное число отладочных плат, и число их невелико; во-вторых, экспортирует онлайн-примеры, на базе которых можно строить какие-то свои проекты, только для наиболее известных IDE: ARM, uVision KEIL и IAR. Более того, некоторые примеры не экспортируются вовсе. То есть, доступны для экспорта или только варианты для IAR, или только для KEIL, и так далее. Так что, как в то время показалось, научиться “прикручивать” arm mbed os к любому МК было бы не лишним вовсе.
Однако, жизнь вносит свои коррективы в любые планы, и работать в этом направлении длительное время не получалось. Но вопрос оставался открытым, и теперь, по прошествии значительного времени, я возвращаюсь к тематике.
Так или иначе, оставался неразрешенным один немаловажный вопрос. Мы все используем различные IDE и различные тулчейны. Процесс портирования довольно непрост, и требует определенных танцев с бубном. К примеру, ассемблер для GCC не поддерживает синтаксис x86 (там AT&T), поэтому самая первая и элементарная проблема, с которой тут столкнется программист – это ругань того же GCC-шного компилятора на ассемблерные вставки в исходных кодаx операционной системы Arm mbed.
Кто-то пользуется IAR, кто-то uVision, кто-то пишет в Sublime Text, а кто-то (как и я) – в Code::Blocks. Кто-то использует Windows, а кто-то – Linux. Объять необъятное и охватить неохватываемое мы не в силах, и при этом оставить один из вариантов без рассмотрения – значит оставить за бортом какую-то часть аудитории.
Решение пришло внезапно и оказалось весьма простым и универсальным.
PlatformIO IDE.
PlatformIO – кроссплатформенный тулчейн, написанный на python, наличие которого на машине пользователя является, пожалуй, единственным обязательным условием (не ниже версии 2.7).
По своему исполнению и использованному инструментарию PlatformIO мне напомнил несколько лет назад вышедшую IDE MicroEJ Studio, в которой можно было писать код для микроконтроллеров на Java. В дальнейшем в МК заливалась MicroJVM (написанная на С), и код исполнялся в ней. Широкого распространения, впрочем, среда не получила, и в массы не пошла.
PlatformIO может использоваться в составе ряда широко распространенных IDE и редакторов кода:
Основными элементами являются PlatformIO IDE и PlatformIO Core.
В довольно-таки уже далеком 2016 году PlatformIO была кандидатом на награждение в номинации “Best IoT Software&Tools” в конкурсе 2016 IoT Awards.
Это в общих чертах. Подробную документацию можно изучить на сайте проекта platformio.org и в разделе Документация.
Наша же задача – установить требуемые средства разработки, создать проект, и что-то в нем сделать.
Atom vs. VS Code
На домашней странице к загрузке предлагаются два редактора: Atom и VS Code. Я попробовал оба, и сразу скажу: VS Code удобнее. Хотя бы потому, что в нем элементарно присутствует переход по коду. Забегая вперед, скажу: в проекте библиотек и исходников arm mbed os вы не увидите, они все сидят в локальном репозитории, поэтому в дереве проекта будут только ваши main.cpp и всё прочее, что создадите вы сами. Поэтому смотреть какие-то объявления, классы и их объекты, интерфейсы классов, придется сто процентов. А Atom такой возможности… не представляет! И при использовании Atom довольствоваться нужно будет только документацией mbed os. Согласитесь, это неудобно.
Итак, дальнейшее рассмотрение процесса я провожу в применении к VS Code. Нам необходимо проделать следующие шаги:
После установки запускаем редактор, открываем панель расширений (Extensions), и вводим в поиске “platformio”. Первым же вариантом выскочит “PlatformIO IDE”. Нажимаем “Install”, дожидаемся окончания установки, перезагружаем редактор.
Пользователям Linux можно сразу установить udev rules для адекватной работы отладчика. В принципе, этот шаг можно опустить, и вернуться к нему в том случае, если при старте отладчика терминал выдаст сообщение вроде “Remote communication error. Target disconnected.: Connection reset by peer.”
Открываем терминал и пишем в нем:
Если терминал выдаст “Permission denied”, то скачиваем файл “99-platformio-udev.rules” по ссылке, и принудительно копируем файл в etc/udev:
где $USER – это имя вашего пользователя. К примеру, у меня это subdia.
После этого все проблемы с отладчиком, если они могли возникнуть, должны решиться.
Окружение и локальный репозиторий arm mbed os
После установки окружения не будет лишним понять, где находится локальный репозиторий arm mbed os (как я уже говорил, в дереве проекта вы его не увидите), где находятся все исходники mbed os, и куда сохраняется скомпилированный проект.
Файлы прошивки и прекомпилированные исходники находятся непосредственно в папке проекта.
Это всё, что нам нужно знать о том, что где хранится. Перейдем непосредственно к созданию проекта.
Создание проекта.
Вкратце о создаваемом проекте. По очевидным причинам, я принял решение создать проект для платы, которая не включена в состав поддерживаемых ARM online IDE, а именно STM32F4DISCOVERY.
В мире встраиваемых систем принято создавать демонстрационные проекты с миганием светодиодов. Мы этого делать не будем – это уже просто и неинтересно. PlatformIO подразумевает несколько типов проектов: cmsis, hal, rtos, и так далее. Так как речь сейчас идет об arm mbed os, то есть об операционной системе, создадим проект именно для rtos.
В проекте мы создадим и запустим три задачи (Task): первая будет выполнять перемножение массивов типа float (у нас же процессор Cortex-M4F, так воспользуемся FPU), вторая задача… ну ладно — мигать светодиодами (=)), а третья – определять степень загруженности процессора.
Открываем VS Code. Первым делом откроется окошко PIO Home. Выбираем “New Project”.
В окне “Project Wizard” указываем название проекта (у нас пусть это будет “armmbed_F407_CPU_usage”), и выбираем плату в выпадающем списке “Board”. Для читателей, планирующих использовать материал при написании софта для своих авторских плат: да, привязка к конкретной плате, но все ноги и периферию можно перенастраивать. Далее я пару слов об этом скажу, не спешите расстраиваться. Итак, Board.
Выбираем STM32F4DISCOVERY, и переходим в окно “Framework”. Тут у нас несколько вариантов.
Так как мы условились использовать arm mbed os, то очевидно, что здесь выбираем вариант “mbed”. Жмем “finish” — готово. Мастер маленько подумает, и откроет свежесозданную болванку проекта. Взглянем на это.
Как я уже упоминал выше, в проекте всего две папки по умолчанию: lib (пустая) и src, содержащая единственный файл main.cpp. Всего исходного кода, напомню, здесь мы не увидим. Но тем не менее, мы имеем возможность использовать весь функционал arm mbed os. Чтобы использовать rtos, мы должны добавить флаг сборки в файл “platformio.ini”:
Вообще, конфигурационный файл заслуживает отдельного рассмотрения. Мне этот подход напомнил TIRTOS/SYSBIOS от Texas Instruments с их конфиг-файлом .cfg, хоть в arm mbed все и проще намного. В конфигурационном файле можно декларировать многое — от аппаратных ресурсов до флагов сборки и отладки. К примеру, вот состав простейшего конфигурационного файла:
А это — конфиг-файл нашего примера в окончательном его виде:
Так что здесь есть что осваивать на досуге.
Итак, начинаем приводить проект в тот вид, который нам необходим.
Я буду приводить код блоками, и пояснять, что в нем происходит. Для начала, мы должны включить в исходник заголовочные файлы “mbed.h” и “rtos.h”. Думаю, понятно, зачем.
Функция “main” примет следующий вид:
Сначала мы создаем объекты класса “Thread”, то есть по сути, наши задачи (Task, Thread), которые будут нам обеспечивать определенный функционал.
Если кто-то обратил внимание, то следующей строкой значится
Это задача “idle” — то есть задача с пониженным приоритетом, которой отводится только то время, которое остается у процессора после выполнения задач с нормальным и повышенным приоритетами. Ну, в нашем случае эта задача останется голодной, так как у процессора не останется на нее времени. Я привел это здесь просто для примера.
Далее мы запускаем задачи по очереди методом “start”, передавая ему ссылки на функции задач, а именно на то, что будет выполняться в процессе. Это “ledblink” — шморгалка, “cpu_usage” — подсчет загрузки CPU, и самая тяжелая — “math_thread”, выполняющая перемножение массивов.
Посмотрим по очереди на каждую из задач. С “ledblink” все просто.
Мы поочередно меняем состояние вывода со светодиодом на противоположное, и вызываем задержку в 500 мс. Кстати, декларация “myled1” выглядит так:
Обратим теперь свое внимание на задачу “cpu_usage”.
Здесь уже все несколько сложнее. Вообще, дабы не выдумывать велосипед, я использовал готовую библиотеку, написанную одним веселым парнем еще в 2014 году для arm mbed, которая так и называется: CPU_Usage. Взять ее можно по ссылке, там же приводится краткое ее описание. Библиотека использует таймер (мы видим объект класса Timer tim). Сначала вызывается конструктор класса “cpu”, затем поочередно методы “working” (начало работы), и “update” — вычисление загрузки процессора в процентах.
Пожалуй, сейчас самый подходящий момент для демонстрации. Покажу скрин из режима отладки.
Слева вверху видим значение “value” = 95. Значит, процессор в тот момент был загружен на 95%. Вообще, по результатам эксперимента это значение при выполнении одних и тех же задач варьировалось от 87 до 98%.
Кстати, почему я демонстрирую скриншоты из дебаггера, а не из терминала? Все просто, у меня под рукой нет переходника UART-USB, поэтому я не могу использовать UART терминал (вот эта функция “pc.printf()” — это как раз вывод по UART, pc — объект класса Serial).
И последняя, и самая прожорливая для процессора – задача “math_thread”. Посмотрим на нее – сначала в “голом” виде, затем немножко дополним плюшками arm mbed.
Когда я придумывал, чем поднагрузить процессор, перемножение массивов сразу пришло мне на ум. И я вспомнил ситуацию, как заказчик, для которого я кое-что делал удаленно (и отлаживал тоже удаленно, через полмира), кричал мне в скайп: “Вы же программист, так загрузите процессор! Он же совсем холодный, сделайте так, чтобы он нагрелся!”. Давайте теперь уже таки сделаем так, чтобы наш MCU нагрелся. =)
И я решил перемножать массивы не последовательно, а генерировать их индексы с помощью генератора случайных чисел. И тут мне снова на помощь пришла одна замечательная математическая библиотека: alglib. Она охватывает огромный пласт математического функционала, и взять ее можно здесь. Весь огромный пласт функционала мы использовать, конечно же, не будем, а воспользуемся небольшим кусочком.
Если посмотреть на задачу-вычислитель произведения, то мы увидим там два вызова “RandomMassIndex()”. Это как раз функция, возвращающая значение в диапазоне (у нас диапазон ограничен числом элементов массивов).
Итак, что мы здесь делаем. Сначала инициализируем структуру “ae_state” (она используется для внутренних нужд), а затем – просто вызываем метод “ae_randominteger”, которому передаем ссылку на нашу структуру, и диапазон, в котором мы хотим получить сгенерированное случайное число (у нас это 0..18). Эта цифра должна быть меньше максимально генерируемого значения. Число элементов массива у нас – 20 (0..19), и максимальное число равно 19. Так что нам в качестве граничного аргумента 18 подойдет как нельзя лучше.
Кстати, можно посмотреть на результаты вызова этой функции.
Вверху слева – сгенерированные случайные индексы массивов, “rand_num_dmassi1” и “rand_num_dmassi2”. 13 и 12.
Прогоним еще один цикл, посмотрим – изменятся ли.
11 и 17. Изменились. Значит, все работает.
Раз уж мы заговорили об анализе ресурсов (в частности, об использовании процессорного времени), то немного уделим времени памяти и приоритетам задач. В arm mbed os реализован целый класс rtos::Thread для этих нужд.
Прямо в задачу “math_thread” добавим следующие строки:
Здесь (и выше) я использовал ключевое слово volatile – чтобы переменную можно было отслеживать.
Итак, сначала мы получаем ID задачи для дальнейшего использования. Затем вызываем методы для определения стека задачи и ее приоритета. Приоритет можно менять на ходу – в некоторых применениях это востребовано.
Смотрим.
Видим, что размер стека задачи равен 4096 байт, а приоритет – osPriorityNormal. Нормальный, в общем, приоритет.
Кроме этого, мы можем оценить степень используемости, размер неиспользованного и использованного стека. Прямо в main добавляем:
И после запуска задач:
Здесь вызываются четыре метода. “Stack_size()” возвращает размер стека задачи (аналогично тому, что мы оценивали чуть ранее), “max_stack()” возвращает размер максимально использованного в процессе выполнения, “free_stack()” возвращает размер свободного места, а “used_stack()” — размер использованного. Возвращаемые значения – в байтах. Для всех трех наших задач эти величины будут одинаковыми.
Посмотрим, что нам покажут по телевизору в дебаггере.
Как видим, от 4096 байт мы откушали совсем немного – всего 64 байта, и имеем в запасе еще аж 4032 байта.
Пожалуй, на этом с экспериментами и анализом мы закончим – я и так заигрался.
Да, что еще хотел сказать по поводу авторских плат. Сейчас кто-то может сказать, мол, вот – взял F4Discovery, на ней поигрался в свое удовольствие, а у меня вообще плата самодельная, и светодиоды вообще висят на других ногах, и в целом, я хочу SPI на ней поднять. Так вот, в репозитории armbed, в папке “targets” (выбираем дальше уже свои вполне конкретные MCU – их там тьма), в директориях каждого микроконтроллера, есть чудесные хидеры с названиями “PinNames.h”, “PeripheralPins.h” и “PeripheralNames.h”. Редактируя эти файлы, можно добавлять/редактировать/удалять периферию.
На этом, пожалуй, я остановлюсь. Больше примеров для различных применений arm mbed (в том числе и не-rtos, а просто bare metal) можно клонировать или скачать архивом здесь.
Ссылку на архив (Google диск) с нашим созданным примером прикрепляю к материалу, а полный исходный код размещаю ниже под спойлером — для полноты охвата всей картины. Если что – добро пожаловать на почту subdia.subdia@gmail.com.
Спасибо за внимание, всем удачного дня и хорошего настроения.
Модули ввода-вывода ADAM-6200
Модули удаленного ввода-вывода предназначены для связи с периферийными устройствами различных типов. Это важнейший элемент построения промышленных систем. Они могут как принимать сигналы от других устройств, так и посылать управляющие сигналы на устройства, интегрируясь с центральными системами управления SCADA по протоколам MODBUS TCP, MQTT, HTTP, и т.д.
Устройства ввода-вывода предыдущих поколений, используемые в промышленности, обычно подключались с помощью последовательных интерфейсов RS-232/485, что затрудняло масштабируемость таких систем. Серия модулей ADAM-6200 отличается возможностью подключения по Ethernet, а также встроенным коммутаторов на 2 Ethernet-порта, что позволяет подключать устройства последовательно в цепочку.
Кроме передачи сигналов модули ADAM-6200 могут выполнять роль программируемых логических контроллеров, для решения простых задач автоматизации. Благодаря поддержке языка условно-графической логики, программировать их можно даже без знания языков программирования.
В статье разбираются характеристики устройств, сферы применения и дополнительные функции защиты от сбоев.
Технические характеристики
Серия ADAM-6200 представлена различными моделями под любые промышленные нужды. Устройства могут соединяться для совместной автономной работы (peer-to-peer), что позволяет получить любую комбинацию необходимых портов.
Поддерживаемые протоколы
HTTP REST API
Универсальность HTTP API позволяет легко интегрировать устройства ADAM-6200 в любую существующую платформу, без необходимости поддержки специфических промышленных протоколов.
Для примера разберем запрос получения состояния аналогового входа:
Запрос значений аналогового входа
Можно видеть текущее значение тока, равное 7mA
Программирование с помощью условно-графической логики
Простые задачи автоматизации, где не требуется большая вычислительная мощность, можно запрограммировать прямо на контроллерах ADAM, с помощью условно-графической логики (Graphic Condition Logic). Например, активировать сирену в случае аварии, перекрыть вентиль в случае срабатывания датчика, и т.д. Среда GCL почти не требует навыков программирования и позволяет создать полноценный скрипт автоматизации с помощью курсора мышки.
Среда разработки условно-графической логики
Последовательное подключение (Daisy Chain)
Устройства серии ADAM-6200 имеют на борту два ethernet-порта, что позволяет подключать их последовательно, «гирляндой». Это значительно упрощает топологию сети и позволяет обойтись без дополнительных коммутаторов при построении удаленных участков сети.
В отличие от соединения с помощью интерфейсов RS-232/485, подключение по ethernet позволяет легко интегрировать контроллеры в любые IP-сети, а также соединять удаленные объекты через интернет с помощью VPN-тоннелей, без необходимости использовать дополнительные конвертеры интерфейсов.
Защита от обрыва питания (Auto-Bypass)
Функция Auto-Bypass автоматически активируется при потере питания на промежуточном устройстве в цепочке. В этом режиме устройство выступает в роли пассивного соединения, как если бы кабель был соединен напрямую. В этом случае действуют ограничения для UTP-соединений, поэтому важно учитывать общую длину кабеля между двух соседних точек и не превышать 50 метров с каждой из сторон, так как максимальная длина пассивного соединения — 100 метров. Время автономной работы функции составляет до 4 дней.
Благодаря Auto-Bypass, связь не обрывается даже при обесточивании промежуточного устройства
Заключения
Универсальные модули ввода-вывода ADAM-6200 имеют широкую поддержку протоколов: Modbus TCP, MQTT, HTTP REST, и могут легко интегрироваться как в классические SCADA системы, так и в любые современные программные продукты.
Поддержка программ на языке GCL позволяет решать простые задачи автоматизации без использования дополнительных устройств. Возможность Peer-to-peer-взаимодействия обеспечивает обмен данными напрямую между устройствами, без использования промежуточных серверов обработки данных.
Возможность последовательного соединения устройств в цепочку позволяет легко строить большие отрезки сети без дополнительного оборудования, а функция Auto-Bypass защищает от обрыва линии из-за выхода из строя устройств в цепи.
Приглашаем на партнерский форум Advantech
Форум Advantech станет уникальной площадкой для обсуждения локальных и глобальных тенденций в области Интернета вещей. Здесь вы сможете обменяться опытом использования новых технологических решений и продуктов, найти новых клиентов и партнеров. У вас будет шанс увидеть продукцию, которую мы описывали в статьях и не только. У нас выступят лидеры отрасли и представители ключевых партнеров – NVidia, Intel и другие компании, которые принимают активное участие в развитии промышленного Интернета вещей на ближайшие годы.
Мы будем рады увидеть на мероприятии всех специалистов в сфере промышленной автоматизации и Интернета вещей. Успейте зарегистрироваться.