Hardella IDE

[Владимир Ситников]

Сделал новым подходом программу, мигающую двумя выходами, залил в ПЛК -- работает.

Надо будет проверить обмен данными, входы и можно выпускать обновление Hardella.

Обмен проверил -- работает. Выходы мигают, обмен данными между HOST и PRU идёт.
Входы как-нибудь потом, на свежую голову, проверю, ибо не хочется сдуру спалить ПЛК.

PRU берёт BOOL из основной программы и записывает его в другую переменную.
Снимок экрана 2016-10-26 в 0.30.41.png

В КДС замыкаем через NOT и получаем цветомузыку.
Снимок экрана 2016-10-26 в 0.31.37.png

Интервал мигания я сделал за счёт "0.25сек цикла PRU".
Снимок экрана 2016-10-26 в 0.32.07.png


Результат:
BzjkL7Mp4V.gif

PS. Как же блок питания пищит адски. Если его каким-нибудь клеем залить, то поможет?

[Филоненко Владислав]

Смотрю тут собрался клуб самоубийц-затейников. Прямой доступ из PRU в программу нельзя так делать.

БП можно просто нагрузить по линии 24В.

[Владимир Ситников]

потому что выше у вас написано >>>> "PRU берёт BOOL из основной программы и записывает его в другую переменную."

но смысл поста Владислава в том, что нужно, как минимум понимать, что будет с алгоритмом, если ему из другого потока значение переменных менять, а в общем случае - проклясть и не использовать сей "метод"

Я не использую подход "поменять у другого потока переменную на ходу".
Я использую подход "обмена сообщениями". Т.е. передаём в другой поток информацию, что "новые значения готовы" -- он читает/пишет когда у него есть время и когда у него ничего не сломается.

Слова "PRU берёт BOOL из основной программы" выражают сущность происходящего, а не детали реализации. Сам факт обмена данными "скрыт" от пользователя в компиляторе.

Т.е. ни о каком "изменении переменных прямо посреди вычислений" речи не идёт.

На стороне PRU обменом занимается такой код:
Снимок экрана 2016-10-26 в 16.42.21.png

Т.е. PRU работает исключительно с локальной памятью, и исключительно со своими переменными.
Само по себе PRU читает/пишет только, если видит, что sys_transferState = PRU_RAM_TRANSFER_STATE.PRU_READWRITE

На КДС стороне выглядит так:
Снимок экрана 2016-10-26 в 16.45.36.png

И, да, я тестировал word tearing (т.е. ситуацию, когда PRU поочерёдно пишет 0xFFFFFFFF и 0x00000000, а КДС читает). В КДС палёных, полузаписанных и т.п. значений (0xffff0000) не приходило.


Т.е. мой подход опирается на следующее:
1) Чтение/запись DWORD атомарны (всегда читается/записывается полное значение)
2) Чтение/запись упорядочены. Например, если мы в PRU выполнили x=1; y=42, а потом на HOST стороне прочитали 42 из ячейки y, то чтение x должно вернуть 1. Иначе говоря, PRU/HOST не переупорядочивает чтение/запись PRU DRAM.

К сожалению, по вопросам "атомарности" и "семантики модели памяти" в спецификации на AM1808 ничего не нашёл. Да и у самого PRU ядра нет ни операций "compare and set", ни операций "LL/SC". Т.е. под "нормальную" многопоточность оно не рассчитано, и я решил, что там модель памяти простая, без хитростей. Иначе как вообще можно какой-то код написать, если возможны произвольные перестановки обращений к памяти, а команд для упорядочивания нет?

[Вольд]

Владимир Ситников объясните, пожалуйста, по простому из-за чего разгорелся очередной сыр-бор.

Возможно ли решение обозначенной проблемы в рамках вашей концепции PRU-программирования ?

[Владимир Ситников]

Хорошо будет если В.Ситников пояснит чего не надо делать при разработке программ для PRU чтобы не вляпаться в то, о чем писал В.Филоненко.

Владислав пишет, что в коде КДС программы и в коде PRU программы не надо использовать указатели.
Если сейчас попытаться использовать указатели в Hardella в PRU программе, то возникнет ошибка на этапе компиляции.
В КДС программе же каждый знает, что указатели это мощный, но опасный инструмент.

При использовании Hardella, в прикладном коде указатели вообще не нужны. Обмен данными происходит через обычные "PROGRAM" КДС блоки.

Еще интересно знать какими ресурсами PRU располагает программист при написании программ. Или придется все таки погружаться в архитектуру PRU.

Да, надо написать.
В большинстве случаев, Hardella просто не даст написать нерабочий код.

Сейчас реализован "PRU цикл" фиксированной длительности. Кто знает, что такое "ПЛК цикл" и что "запись выходов происходит после отработки пользовательского кода", тому не нужно учить ничего нового. В Hardella PRU всё точно так же.
Есть одна задача, и она выполняется циклично. В промежутках между вызовами программы идёт обмен данными с основным циклом, и обмен входов/выходов

Из текущих ограничений самого PRU компилятора (это можно будет исправить в будущем, но пока для упрощения возможности не реализованы):
1) Не поддерживаются сложные выражения. Т.е. чтобы записать d := a+b-c нужно делать промежуточную переменную и записывать как u := b-c; d:= a+b; В условных операторах (if/while/repeat) составные AND/OR работают, но тоже не в любых комбинациях. Если скомпилировалось, то норм. Если "не поддерживается", то будет ошибка компиляции.
2) Не поддерживаются структуры
3) Не поддерживаются массивы
4) Пока только unsigned типы: BOOL/BYTE/WORD/DWORD и ENUM'ы
5) Не поддерживается PRU1. Т.е. пока "теряются" 2 быстрых выхода, которые подключены к этому самому PRU1.

[Владимир Ситников]

Красота, товарищи.
Взялось и удалилось моё сообщение о том, как составлять PRU программы в Hardella.

При этом, ни в почте, ни в личных сообщениях ничего не образовалось.

Интересно, это просто временный глюк форума, или модераторы так скрытно действуют, что просто удаляют сообщения и даже не просят "не писать больше такого"?
Если что, то ко мне ни разу никто не обращался с просьбами/требованиями "не распространяться про Hardella, PRU и т.п."

Что ответят, если обратиться к администрации с вопросом "пропало сообщение"?

В целом, могу повторить. Все картинки у меня остались.
Хотя надёжнее будет на сайте Hardell'ы начать документацию выкладывать -- там надёжнее будет, и теряться записи не будут.

Напомню кратко последний статус: в Hardella 1.5.0 любой желающий может составить PRU программу и управлять быстрыми входами-выходами на частотах порядка 100кГц...1МГц. Всё абсолютно законно и не требует специальных прошивок.

[Вольд]

Нормальный ход событий.

Новации всегда трудно пробивают себе дорогу.

Надо все основные материалы размещать на сайте Hardella.

[Вольд]

Уважаемые господа из фирмы "ОВЕН", у вас есть прекрасная возможность на деле доказать, что концепция В.Ситникова является порочной. Попробуйте при помощи Hardella IDE написать ФБ для PRU и покажите всем, что он работает не корректно.

[Владимир Ситников]

Уважаемые господа из фирмы "ОВЕН", у вас есть прекрасная возможность на деле доказать, что концепция В.Ситникова является порочной. Попробуйте при помощи Hardella написать ФБ для PRU и покажите всем, что он работает не корректно.

Рассмотрим вопрос "надёжности", "тестирования", "чёрного ящика" и всего такого.
Вот в текущем "owenlogic" есть проблема: неясно что со схемой сделал компилятор. Неясно как сработали макросы и какая связь стала "неявной обратной блуждающей связью".

Посмотрим как с этим обстоит дело в Hardella IDE.
Если в двух словах, то хорошо всё обстоит.

Возмьём простую программу:
Снимок экрана 2016-10-28 в 14.34.23.png

Результат компиляции выглядит так:
Снимок экрана 2016-10-28 в 14.36.15.png

Что? Всё ясно, как на ладони? =)
Ну, само наличие бинарного кода это уже хоть что-то, ведь его можно анализировать.
Но, разумеется, для анализа это непригодно.

В Hardella есть более простой и понятный инструмент.
Для его активации нужно в меню включить сохранение "промежуточных результатов" (поставить галочку "save transient models"):
Снимок экрана 2016-10-28 в 14.39.33.png

Потом перекомпилируем проект:
Снимок экрана 2016-10-28 в 14.40.45.png


И видим как в нижней левой части экрана добавились эти самые промежуточные представления:
Снимок экрана 2016-10-28 в 14.41.11.png

Например, в начале добавляется ФБ для обработки входов.
В PRU configuration мы указывали 0.5мкс фильтрацию 1-го входа, и это как раз и есть 100 тактов:
Снимок экрана 2016-10-28 в 14.42.34.png

Одновременно с этим создаётся и каркас будущей программы (WHILE цикл PRU и т.п.)
Снимок экрана 2016-10-28 в 14.44.02.png

Можно проследить куда именно в этот цикл встраивается пользовательский код:
Снимок экрана 2016-10-28 в 14.45.01.png

Видно как компилируется код:
Снимок экрана 2016-10-28 в 14.47.01.png

И можно посмотреть в каких регистрах что хранится:
Снимок экрана 2016-10-28 в 14.48.01.png


Кто-то мог бы возразить, что, мол, "тестировать нужно каждый блок отдельно и всё такое".
И?
Кто мешает тестировать каждый блок отдельно?
Правильно, никто не мешает.

Возьмём, например, блок фильтрации: PRU_DEBOUNCE.
В конце концов для конкретно этого блока создаётся java класс
Снимок экрана 2016-10-28 в 14.50.50.png



Этот java класс можно тестировать обычными java средствами.
Вот пример тестов для блока ABZ энкодера: https://github.com/vlsi/pru-emulator...zTest.java#L19
В тесте нет никакой шелухи, а просто идут вызовы нашего блока и проверяются значения на выходах.

Точно так же можно тестировать и целиковую программу (с фильтрацией и всем таким).
Конечно, для тестирования "программы целиком" нужно побольше обвязочного кода, т.к. нужно в том числе эмулировать и "цикл ПЛК, который раз в 1мс опрашивает PRU".
Тем не менее, вот код, тестирующий программу "отмерки нужной длины с помощью энкодера": https://github.com/vlsi/pru-emulator...Test.java#L105. Там просто эмуляция опроса из ПЛК цикла и вывод значений на экран. Можно добавить assert'ов, чтобы тест падал, если поведение отличается от желаемого или просто проверять совпадает ли вся выводимая простыня "эталонной простыне значений".

Что мы только что увидели?

1) В Hardella в один щелчок мышкой можно увидеть все промежуточные стадии компиляции кода. Понятное дело, что для понимания "последних стадий" нужно понимание ассемблера PRU. Но первые фазы будут понятны и тому, кто не разбирается в деталях PRU архитектуры.

2) В Hardella можно легко делать автоматические тесты как для отдельных блоков, так и для программы в целом. "Тестирование схем ОЛ" тихо плачет в сторонке. Не исключаю, что в недрах ОВЕН и есть инструмент для автотестирования программ ОЛ, но обывателю он явно недоступен.

3) Всё вышеперечисленное может сделать рядовой программист. Детального понимания PRU архитектуры не требуется.

4) В "тестах ФБ" можно проверять не только правильность работы, но и длительность выполнения. Т.е. можно узнать сколько тактов требует блок на тех или иных входных значениях.

5) В тестах "программы в целом", можно проверять "как часто осуществляется опрос входов"

[Владимир Ситников]

Объясните Вольду лучше различие, между порочностью концепции и у ОВЕНа денег не хватит, а то парень не в курсе

Вольд-то давно понял, что ни о какой "порочности" концепции речи не идёт.
Нормальная, рабочая концепция.

Если "вдруг" окажется, что "DWORD'ами передавать нельзя, а только байтами", то достаточно лишь будет поправить компилятор и перекомпилировать проект. Концепция "отмечаем флажком @Export те переменные, которые нужно передавать в host" остаётся. Концепция составлять программы на ST,а не на ASM тоже хорошая.
В общем, "порочность" это гнусное слово, которое используют без приведения каких-то разумных аргументов/доводов.


Слова Владислава/Дмитрия про "необходимость фиксированной длительности выполнения ФБ" для PRU не имеют никакого смысла. Да, звучит громко, но именно так это и есть.

Я уже говорил почему именно, но без проблем повторюсь: обмен данными между PRU и HOST является "непредсказуемым" с точки зрения PRU.
1) Поэтому, даже если весь остальной PRU код сделан супер-пупер по фиксированной длительности выполнения, то внезапно пришедший запрос на обмен данными сорвёт весь ритм.
Можно, конечно, "потратить" одно из PRU ядер на обмен с host'ом, но есть ли в этом смысл, если и без "траты ядра" (см №2) прекрасно работает?

2) С другой стороны, у PRU есть "счётчик выполненных тактов", поэтому совершенно без проблем делается "PRU цикл заданной длительности". Например, если цикл 1мкс, то сначала выполняем пользовательский код, а потом просто "ждём". Иными словами, выходы переключаются раз в цикл и там нет никаких плавающих задержек.