Hardella IDE

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

Уважаемые господа из фирмы "ОВЕН", у вас есть прекрасная возможность на деле доказать, что концепция В.Ситникова является порочной. Попробуйте при помощи 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) В тестах "программы в целом", можно проверять "как часто осуществляется опрос входов"