Владимир Ситников объясните, пожалуйста, по простому из-за чего разгорелся очередной сыр-бор.
Возможно ли решение обозначенной проблемы в рамках вашей концепции PRU-программирования ?
Владимир Ситников объясните, пожалуйста, по простому из-за чего разгорелся очередной сыр-бор.
Возможно ли решение обозначенной проблемы в рамках вашей концепции PRU-программирования ?
Владислав пишет, что в коде КДС программы и в коде PRU программы не надо использовать указатели.
Если сейчас попытаться использовать указатели в Hardella в PRU программе, то возникнет ошибка на этапе компиляции.
В КДС программе же каждый знает, что указатели это мощный, но опасный инструмент.
При использовании Hardella, в прикладном коде указатели вообще не нужны. Обмен данными происходит через обычные "PROGRAM" КДС блоки.
Да, надо написать.
В большинстве случаев, 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.
Последний раз редактировалось Владимир Ситников; 27.10.2016 в 17:57.
Красота, товарищи.
Взялось и удалилось моё сообщение о том, как составлять PRU программы в Hardella.
При этом, ни в почте, ни в личных сообщениях ничего не образовалось.
Интересно, это просто временный глюк форума, или модераторы так скрытно действуют, что просто удаляют сообщения и даже не просят "не писать больше такого"?
Если что, то ко мне ни разу никто не обращался с просьбами/требованиями "не распространяться про Hardella, PRU и т.п."
Что ответят, если обратиться к администрации с вопросом "пропало сообщение"?
В целом, могу повторить. Все картинки у меня остались.
Хотя надёжнее будет на сайте Hardell'ы начать документацию выкладывать -- там надёжнее будет, и теряться записи не будут.
Напомню кратко последний статус: в Hardella 1.5.0 любой желающий может составить PRU программу и управлять быстрыми входами-выходами на частотах порядка 100кГц...1МГц. Всё абсолютно законно и не требует специальных прошивок.
Нормальный ход событий.
Новации всегда трудно пробивают себе дорогу.
Надо все основные материалы размещать на сайте Hardella.
Последний раз редактировалось Вольд; 28.10.2016 в 11:49.
Уважаемые господа из фирмы "ОВЕН", у вас есть прекрасная возможность на деле доказать, что концепция В.Ситникова является порочной. Попробуйте при помощи Hardella IDE написать ФБ для PRU и покажите всем, что он работает не корректно.
Последний раз редактировалось Вольд; 28.10.2016 в 16:43.
Рассмотрим вопрос "надёжности", "тестирования", "чёрного ящика" и всего такого.
Вот в текущем "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) В тестах "программы в целом", можно проверять "как часто осуществляется опрос входов"
Последний раз редактировалось Владимир Ситников; 29.10.2016 в 00:16. Причина: опечатки
Вольд-то давно понял, что ни о какой "порочности" концепции речи не идёт.
Нормальная, рабочая концепция.
Если "вдруг" окажется, что "DWORD'ами передавать нельзя, а только байтами", то достаточно лишь будет поправить компилятор и перекомпилировать проект. Концепция "отмечаем флажком @Export те переменные, которые нужно передавать в host" остаётся. Концепция составлять программы на ST,а не на ASM тоже хорошая.
В общем, "порочность" это гнусное слово, которое используют без приведения каких-то разумных аргументов/доводов.
Слова Владислава/Дмитрия про "необходимость фиксированной длительности выполнения ФБ" для PRU не имеют никакого смысла. Да, звучит громко, но именно так это и есть.
Я уже говорил почему именно, но без проблем повторюсь: обмен данными между PRU и HOST является "непредсказуемым" с точки зрения PRU.
1) Поэтому, даже если весь остальной PRU код сделан супер-пупер по фиксированной длительности выполнения, то внезапно пришедший запрос на обмен данными сорвёт весь ритм.
Можно, конечно, "потратить" одно из PRU ядер на обмен с host'ом, но есть ли в этом смысл, если и без "траты ядра" (см №2) прекрасно работает?
2) С другой стороны, у PRU есть "счётчик выполненных тактов", поэтому совершенно без проблем делается "PRU цикл заданной длительности". Например, если цикл 1мкс, то сначала выполняем пользовательский код, а потом просто "ждём". Иными словами, выходы переключаются раз в цикл и там нет никаких плавающих задержек.
Последний раз редактировалось Владимир Ситников; 28.10.2016 в 16:45.
Без Hardella-никак. Есть, конечно, способ "от Владислава", описанный в первом сообщении, но называть это способом язык не поворачивается, т.к. Слишком уж тяжело им пользоваться.
Ещё есть инструмент от TI, но он слишком сложен для рядового пользователя. Я в нем даже пустой проект создать не смог. Как там обрабатывать входы/выходы - вопрос. Как обмениваться данными с КДС тоже вопрос. Для экспертов, возможно подходит, но простым людям инструмент TI не подойдет.
А черепаха как раз и находится посредине. И проект создаётся в два счета, и сразу получается готовая к использованию в КДС библиотека.
Да, я пользуюсь тем, что альтернатив черепахе для PRU программирования нет.
Но и сама черепаха не лыком шита. Это не просто "лучшее из имеющегося" (в контексте обычных задач энкодеров/шд), а вполне удобная среда с хорошими возможностями по расширению.
Я показывал, что там можно и FBD язык добавить. И займёт это не годы, а недели-месяцы. Например модуль PRU занял менее двух месяцев. И им уже можно с успехом пользоваться, чего не скажешь о бета инструменте Овен. Понятно, что у бета инструмента не было цели "создавать боевые проекты", но все же.
И, да, как я исходно говорил, мне было интересно не "составлять PRU программу из овеновских блоков, а создавать свои блоки".
Эту цель я достиг. С помощью hardella рядовой асутп программист может сделать программу для PRU, которая нужна ему, при этом алгоритм не ограничен списком блоков, которые представил Владислав.
Последний раз редактировалось Владимир Ситников; 28.10.2016 в 19:50.
Последний раз редактировалось rovki; 28.10.2016 в 19:59.
электронщик до мозга костей и не только