tonyk_av

В ПЛК от Мицубиси и Дельты существуют обработчики прерываний. У Мицубиси их относительно Дельты немного, а вот у Дельт, ориентированных на управление перемещением, очень даже много. Даже время входа в обработчик указывается, кстати. Подозреваю, что и события у Сименса тоже могут возбуждаться аппаратно, например, изменениями сигналов DI или таймерами. Странно слышать, что Сименсов нет прерываний. Должны быть, иначе как ПЛК будет реагировать на аварийные ситуации, когда каждый такт процессора на счету? Я уже упоминал про двойную буферизацию в своей реализации ПЛК. Она сделана как раз для того, чтобы драйверы протоколов жили своей жизнью, а задачи в ПЛК- своей, но доступ к регистрам ПЛК должен быть синхронизирован и атомарен. Вот фрагмент настройки мастера шины I2C, работающего с расширителем дискретного ввода-вывода MCP23008. Здесь два запроса: один на чтение DI, другой на запись DO. Мастер шины I2C работает отдельной задачей. Из программы пользователя он получает настройки откуда-что читать, и куда-что записывать. Можно из программы пользователя инициировать выполнение одного запроса, можно поставить запрос на постоянное выполнение. Никакой жёсткой привязки к адресам нет, куда пользователь сказал, например, класть данные, туда они и будут положены. Модбас-мастер реализован аналогично. Модбас-слэйв вообще даже задачи не имеет, полностью обрабатывается в прерываниях. Если встать на любую шину осциллографом, то там идёт практический сплошной поток, без пауз, никто никого не ждёт, спросили- сразу ответили. И пофиг сколько задач, какое у них время сканирования.

Подраздел 4.3: Ессно, что при использовании других языков используется терминология, принятая в используемых языках. Почему не вынести его в рантайм? Ждать конца сканирования, ИМХО, как-то примитивно. Из-за одного ПЛК, долго отвечающего на запрос, будет тупить весь сегмент сети. Ужас.

Так и я о них же. Прерывания могут быть по изменению сигнала на выводе ПЛК или по срабатыванию таймера, например. Кстати, на картинке это показано. Ещё нюанс, тоже показанный на картинке: по прерыванию запускается аж целая задача, хотя это может быть и не оформленный в виде отдельной задачи код. Что значит "работающие на мэк уровне"? Или здесь с формулировкой напутано, или глупость. Если драйвер протокола Модбас работает на прерывании, то он принципиально не_может работать последовательно с чем-то. Например, время цикла сканирования 1 секунда. И чё, через секунду начнём обрабатывать пришедший запрос? Ха-ха три раза. Поэтому приходится использовать двойную буферизацию данных при общении с внешними устройствами, плюс задействовать объекты синхронизации доступа к данным ПЛК. Чисто технически нет проблемы запускать каждую задачу на отдельном ядре. Проблема в пользователях, многие из которых просто не в состоянии осознать механизмы параллельной работы задач, поэтому будут допускать трудно выявляемые ошибки.

Не совсем так. Забыли указать обработчики прерываний.

Естественно. Вот её-то и надо сделать. Это зависит от того, как разработчик их сгруппирует. Видимо, ты имел дело с простейшими вариантами, когда это всё склеивалось разом. Она разная для разных программ пользователя. Если ты её так сделаешь, то- да. Сам matiec не накладывает ограничений на то, когда в память ПЛК загружаются функции поддержки его кода, при изготовлении ПЛК или пользоватедем вместе с его программой. Достаточно посмотреть его выхлоп.

Фрагмент из документации на ПЛК "Нуклерон": Сие означает, что в ПЛК уже находится рантайм, связывающийся со средой программирования, принимающий от неё программу и обеспечивающий эту программу всеми необходимыми ей сервисами.

Вот как раз интерпретатор ничего не знает о "железе"! Совсем ничего! И не должен знать, кстати, если подумать. Ты, наверно, не в курсе, но да даже у Мицубиси две среды программирования их FX2N, плюс у китайцев есть своя. Более того, почти весь протокол доступа к ПЛК от Мицубиси описан в их официальной документации, которую можно свободно взять на их сайте и реализовать свою среду программирования. Кстати, видел несколько российских ОРС-серверов для доступа к памяти ПЛК Мицубиси через порт программирования. Улавливаешь намёк? От нас ничего не скроешь. :))) Ну, всё знаешь, но не понял чё-куда. Зачем таймер, что должен делать обработчик прерывания от таймера? Что за отладочный код? Не тот ли, который обеспечивает взаимодействие с отладчиком? По какому интерфейсу, UART или CAN? И далее по списку. Вот и ищу документацию, в которой описаны требования к тому, что нужно для полноценной работы сгенерированного matiec кода на целевом МК.

В том то и дело, что есть. Посмотри код, который делает matiec: там и вызовы функций для доступа к периферии, и поддержка отладки. Неужели ты думал, что в среде для ПЛК нет отладки? Если ты запускал примеры, то должен был видеть работу отладчика МЭК-программы. Если ты не прилинковал к результату работы matiec библиотеку с этими функциями, то, ессно, кроме голого кода ничего не увидишь. Даже интересно стало: если у тебя работали DI и DO, то должны были быть определены хотя бы функции доступа к выводам целевого МК. А если ты не видел работу отладчика, то, пардон, без реализации функций работы с отладочным интерфейсом ты ничего и быть не могло. Я с загрузкой не разбирался, но она должна быть. Технических сложностей нет, нужно, скорей всего, реализовать функции загрузки программы в ПЗУ и, возможно, указать линковщику начальный адрес размещения программы.

Уже давал: Любим zaёбывать людей?

Зачем пересказывать то, что написано и нарисовано? Кому-то впадлу почитать? Приятней отвлекать людей?

При чём тут отладка matiec? Мы говорим про IEC 61131-3 так-то. И отладка программ на этих языках, вообще-то, идёт их среды программирования ПЛК.

На МК ставится среда исполнения. Так для того и делается Си-файл, чтоб получить прогу в кодах целевого процессора! Может, всё-таки для начала почитать доступные доки, а не сыпать мусор в тему?

Без библиотек или линковки объектных файлов с поддержкой доступа к периферии- не соберётся. Выход matiec был "заточен" под сборку GCC. Об этом в доках на matiec было писано.

А что собирать-то? Настроить сборку- это другая я пьянка. Для сборки нужна библиотека для целевого МК с реализацией доступа из рантайма к периферии. Со списком этих функций и описание того как они должны работать и есть вопрос. То, что я вижу в исходниках Нуклерона, вызывает сомнения в правильности реализации и особенно в производительности реализации. Нет доков, на основании которых можно делать выводы.

Странно. У меня заработал без шаманства.

Почитай что там, тогда и вопросы не нужно будет задавать кроме одного единственного.

Зачем? Лишь бы открылся и собрался. И посмотреть, что тебе прислали для поддержки AVR. Для начала понять бы масштаб задачи. Если правильно помню, то часть генерации кода под целевой МК делается скриптами на Питоне. Ну и понять что и как много нужно написать для рантайма со стороны МК. А открыть и посмотреть слабО? https://openplcproject.com/

Уже сказали как и даже показали. Для сложить 10 значений и поделить сумму на 10 тоже нужен пример? :))) А какая разница? Принцип показан. Дальше смотри АЦП в своём и МК и DMA. Может, теорию измерений для начала изучить? Кстати, в примере не показана настройка таймера для запуска АЦП. Если делать по-умному, то брать отсчёты нужно каждые 2мс, после чего усреднять.

Выкладывай. AVR достаточно простой МК, будет проще раскуривать что и как. Сам Beremiz основывается на проекте OpenPLC, с которым они, похоже, переплелись. Но опять же, нет доков. Можно попробовать раскурить исходники от Нуклерон, но нет понимания, что они сделали всё так, как нужно для ПЛК вообще и для matiec в частности. Беглый просмотр не дал понимая этого.

Берёшь массив из 20 значений. АЦП в кольцевом режиме непрерывно измеряет. Настраиваешь 2 прерывания от АЦП: по половине буфера и по окончании измерений. В итоге каждые 10 замеров получаешь прерывания. В зависимости от того, какое получил, используешь в расчётах либо первые 10, либо вторую десятку. Ессно, всё через DMA.

Можешь показать?

Это хороший тон. Понадобилась переменная, создал её и сразу присвоил значение. Не все компиляторы могут отслеживать использование переменной, которой не было присвоено значение.

Правильный. Доков только нет, а без них вся серьёзность подхода херится на корню. Да, есть примеры по портированию, но только два сделаны самой командой Беремиц, остальные сторонними разработчиками методом изучения примеров. Почему сами создатели Беремиц и matiec не описали этот процесс? Столько лет уже проектам, а воз и ныне там. Не понятно. Или это я не вижу?

Сколько не искал, так и не смог найти руководство по адаптации рантайма для matiec под целевой контроллер. Плюс руководство по написанию скриптов для настройки целевого контроллера и его модулей из Беремиц. Они вообще есть или я их не вижу? Вариант с Беремиц считаю самым правильным подходом реализации ПЛК, но отсутствие доков напрочь убивает желание ковыряться с ним. Будь доки- занялся бы им.

Вот я с коллегой-единомышленником по нему и пошли, повторив рантайм Мицубиси FX2N.