А "target.trg для PRU1" будет?Сообщение от Филоненко Владислав
А "target.trg для PRU1" будет?
Вы же не используете архитектуру ОВЕН? Зачем тогда таргет?
Тролль-наседка, добрый, нежный и ласковый
Что вы понимаете под словами "не используете архитектуру ОВЕН"?
Ещё раз поясню как я получил PRU0.prg:
1) Создал бинарный код для PRU в Hardella -- pru_pulse.bin. Тут целиком моя работа. На всякий случай, я скомпилировал ассемблер через pasm.exe -- результат совпал полностью.
2) Создал пустой файл pru_pulse.asm, применил к нему "секретный инструмент", и получил PRU_PULSE.fb с моим кодом
3) Создал pulse.p с одним единственным вызовом моего блока, и вызовом Compilator.exe pulse.p PRU_PULSE.fb PRU0.prg получил PRU0.prg
Мне, конечно, не нравится, что сейчас нет возможности пропустить шаги 2 и 3 с "секретным инструментом, обрабатывающим пустой файл".
Более того, сама необходимость шага №2 + подписанный "договор о неразглашении" запрещают встраивать вызов "секретного инструмента" в Hardella IDE.
Да, я агитирую всех, кому нужно 100кГц писать/звонить в ОВЕН и (прилично!) спрашивать "появился/изменился ли ответ на сообщение #196?".
Но, при этом, чтобы создавать программы, мне нужно понимать как входы-выходы PRU соотносятся с регистрами. Будет ли это target файл или словесное описание -- не так важно.
Последний раз редактировалось Владимир Ситников; 21.09.2016 в 17:43.
Можно, конечно, о такого типа PRU программирования помечтать pru_fbd.png
Но:
1) Сначала я хотел бы хоть несколько реальных программ увидеть, чтобы понять какие по сути функции требуются от PRU
Переводя с русского на русский, сначала ШД с разгоном, а потом уже FBD и т.п.
2) Кучу времени потратили на выяснение "можно ли из Hardella генерировать PRU0.prg и PRU1.prg". Это прямо реально вопрос тысячелетия. Сначала заставляют договор о неразглашении подписывать, а потом удивление, что я его добросовестно соблюдаю.
3) Пока неясно ясно как на FBD скрещивать "два блока ШД, которые разгоняют каждый свой выход, и каждый хочет разный интервал цикла".
Простой вариант, конечно, просто сделать фиксированную гранулярность цикла с делителями
Что-нибудь в духе "PRU цикл по 1мкс". Но на частотах 100кГц гранулярность "каждую микросекунду" может быть маловато.
4) Очень может оказаться, что ШД это единственное для чего нужен PRU. Ну, возможно, что-нибудь с энкодерами будет. Для ШД, как уже было видно, достаточно просто сделать PRU0.prg и соответствующую библиотеку. Народ будет просто заливать PRU0.prg и всего делов. Т.е. блок ШД как блок никому не нужен. Нужна законченная программа.
Кстати, тут вопрос про обновление прошивки самого ПЛК.
Если я правильно понимаю, то мою PRU программу (ШД) можно встроить в прошивку ПЛК, и прямо в КДС конфигураторе вместо fast output выбирать "stepper motor". Ну, по крайней мере, наверняка технически есть такая возможность, и вопрос переходит в организационную плоскость.
Последний раз редактировалось Владимир Ситников; 21.09.2016 в 16:53.
На данный момент меня интересует возможность работы PRU0 и PRU1 вместе.
С одинаковыми программами, чтобы работали независимо друг от друга.
Без этой возможности придется возвращаться к Arduino.
Пробовал,
Оставлял один PRU1.prg
И pru_num менял.
ПЛК в ребут уходит при запуске программы.
Одна PRU1.prg сама по себе работать не будет.
Пробовали одновременно и PRU0.prg и PRU1.prg?
Последний раз редактировалось Владимир Ситников; 21.09.2016 в 18:53.
Можно еще ФБ BLINK сделать. Штатный более 500 Гц не выдает.
Что там программисты "ОВЕН" говорят о дальнейших перспективах ?
ФБ для обработки сигналов энкодера то же надо сделать. На форуме кто-то выкладывал отлаженный код на ST, вызываемой по таймеру 20 мкс.
Переживать не надо, работа по написанию ФБ для PRU найдется. Надо программистов "ОВЕН" расшевелить. Пусть дадут добро на разработку нормальной среды для написания ФБ для PRU.
Последний раз редактировалось Newcomer; 21.09.2016 в 19:01.
Чем не подходит штатный PWM режим для быстрых выходов?
Там на выходе меандр, а у BLINK можно отдельно задавать длительность импульса и паузы.
Ваши права
Ответить с цитированием