Я не вижу в этом смысла. Если хочется делать монолитный код - метод известен, озвучен и даже использован.
Идея использования монолитного кода порочна в своей сути именно из-за проблем с тестированием. И использовать её как рабочую (промрешение) нет никакого желания.
Не зря контроллеры с программированием на C не получили распространения среди обычных потребителей.
Когда мы объявляли бета-тестирование - там чётко описывались задачи бета-тестеров. Задачи "перевернуть всё и поменять архитектуру ПО, а потом её ещё и поддержать" не было.
Тролль-наседка, добрый, нежный и ласковый
1) "Известный" метод не позволяет сделать мне законченное решение на базе Hardella.
Да, я могу генерировать промежуточный ассемблер, потом подсовывать его TI компилятору, потом ОВЕН линкеру, но тут мир рушится. Получившийся PRU0.prg файл невозможно ни отлаживать, ни тестировать. Его разве что в ПЛК заливать и с осциллографом анализировать.
2) Вы постоянно говорите о "порочности", но при этом игнорируете тот факт, что:
2.1) Есть механизм построчной отладки полученных программ. Надёжность на порядок выше того, что в том же самом ОЛ.
Какой код генерирует ОЛ никому неизвестно, а тут можно посмотреть, понять, и детально проверить.
Назовите реальную, а не мифическую проблему с тестированием.
2.2) У того же самого TI есть C компилятор, отладчик и т.п. Говорить "монолитный код порочен" и игноировать опыт индустрии крайне странно
Надеюсь, вы понимаете, что я на C и не предлагаю программировать?
Зачем тогда говорите?
Наконец-то! Хоть какой-то ответ.
Т.е. я останавливаю работы по PRU.
Спасибо за внимание.
Тем, кому-таки нужен блок ШД или подобные блоки работы с быстрыми входами-выходами: пишите/звоните в ОВЕН или используйте другие контроллеры.
Как вариант, можно меня подрядить на доработку Hardella IDE, но, сначала нужно согласие ОВЕН.
Последний раз редактировалось Владимир Ситников; 15.09.2016 в 13:55.
Скорее всего - реальная проблема тестирования бинарника в ее принципиальной невозможности ))) Исполняемый код загружается в чип и стартует по окончании загрузки - управлять процессом исполнения (ставить точки останова, смотреть регистры, память) нет возможности. Существуют, конечно, аппаратные отладчики для подобных систем, но интегрировать их в контроллер никто не будет.
Тестируйте введенную пользователем программу в текстве, полагаясь на "божественную непогрешимость" предлагаемого компилятора и линкера (которую кстати никто вроде не оспаривает) )))
У меня еще одна простенькая задачка по управлению ШД. Бывает нужно разогнать ШД до требуемой частоты с заданным темпом (за определенное время). В связи с этим требуется такой ФБ для PRU (смотри вложения).
При установке ENABLE в TRUE частота на выходе OUT линейно (возможно по S-кривой) увеличивается до 1/PERIOD за время ACCSEL_TIME. По достижению заданной частоты READY устанавливается в TRUE. Если ENABLE переходит в FALSE, то OUT и READY устанавливаются в FALSE.
Последний раз редактировалось Newcomer; 15.09.2016 в 14:55.
Итоги какие то есть?
Еще вчера нужен был ФБ управления сервопроводом.
Сейчас все делаю на Arduino и через RS485 отправляю в него команды.
Но это настолько некрасивое решение (на фоне заявлений ОВЕН о 100кГц на выходе), что я ночами ворочаться начинаю.
Альтернатива есть\будет?
Владимир, если Ваше решение рабочее и работает - готов протестить на оборудовании.
Готов предоставить фото\видео отчет по работе.
Объясню почему невозможно использовать "линкер".
Жизненный цикл кода (жирным я выделил, собственно, "секретный инструмент"; всё остальное -- общедоступно):
Я без проблем могу из Hardella сгенерировать всю программу под видом одного ФБ (и, соответственно, program.p будет состоять из одного гордого вызова этого самого ФБ), но это всё равно не позволит мне создавать PRU0.prg из Hardella.Код:assember + СЕКРЕТНЫЙ ИНСТРУМЕНТ ==> FB_ARRAY.bin КДС_CFC.EXP + target.trg + editor.exe ==> program.p program.p + FB_ARRAY.bin + compilator.exe ==> PRU0.prg КДС_CFC.EXP -- это программа из PRU блоков, составленная в КДС program.p -- это по сути описание того, какие ФБ вызывать и как они соединены между собой FB_ARRAY.bin -- содержит код самих блоков и ещё что-то
Дело в том, что мой ФБ нужно каким-то образом завернуть в FB_ARRAY.bin файл, а инструмент, который это делает секретный.
Иными словами:
1) Я могу генерировать и публиковать PRU0.prg для законченных программ. Например, я могу опубликовать PRU0.prg для работы с ШД.
2) Я не могу встроить механизм генерации PRU0.prg в Hardella, т.к. для этого придётся публиковать "секретный инструмент создания FB_ARRAY.bin"
3) Если все эти песни пляски вокруг FB_ARRAY.bin сводятся только к тому, чтобы ублажить линкер, подсовывая ему программу из одного-единственного ФБ, то зачем такая сложность? Для повышения надёжности мы в цепочку добавляем 2 лишних звена под названиями FB_ARRAY.bin и program.p?
4) Ещё раз подчеркну, что я работаю в macos, и для меня секретный_инструмент.exe, editor.exe, compilator.exe создают проблему даже сами по себе -- на macos непросто запускать windows программы. Есть желающие проспонсировать развитие Hardella IDE? Подобные же "хоть чучелом, но без *.exe никак" весьма удручают.
Мне очень нужны два ФБ управления ШД для PRU, про которые я писал в этой теме. Владислав Филоненко ответил, что он очень сильно занят и у него в обозримом будущем не будет возможности это сделать. Владимир Ситников готов все сделать (один ФБ уже вроде сделал) и даже представить понятный инструментарий для разработки ФБ для PRU, но ему по непонятным причинам не дают это сделать.
Может обратиться к высшему руководству фирмы "ОВЕН" для разрешения этого конфликта ?
Последний раз редактировалось Newcomer; 18.09.2016 в 19:12.
Дмитрий, поменьше слов, побольше дела.
Дмитрий, как вы из этой темы заключили, что у меня нет контроллера-то?
Вот контроллер: http://www.owen.ru/forum/showthread....l=1#post194290
Что, сфотографировать вам модули ввода-вывода, AC4, блок питания, осциллограф?
Или будете говорить, что всё равно, это чужой контроллер и постановочная фотография?
Что ошиблись?
Теперь вернитесь к предыдущему пункту и хорошенько подумайте: "а что, если и в словах 'не сделает' тоже ошибка?".
Вы правы, знание глюков исполнительных механизмов бесценно.
Но каким боком это относится к PRU программированию?
Правильно, никаким.
Мне не нужно знать детали конкретного исполнительного механизма, чтобы сделать хорошую среду программирования.
Равно как и не нужно знать деталей исполнительного механизма, чтобы сделать блок ШД.
Прошу провести натурные испытания.
pru_pulse_v1.zip
Порядок работы:
1) Заливаем PRU0.prg (как-то)
2) Подключаем ШД на fast output 3
2) Используем блок pru_pulse.lib для работы с ШД
CYCLE_LENGTH задаёт длительность единичного и нулевого значения на выходе. Оно указывается в тактах PRU. Вроде как PRU работает на частоте 150МГц, т.е. значение cycle_length=150 это импульсы по 1мкс.
Параметр CYCLE_LENGTH сейчас WORD, т.е. максимальное значение 65535, и, значит, возможна генерация частот в пределах 1кГц...1МГц
Если нужны более низкие частоты, то придётся перекомпилировать программу, а мне было немного лень, т.к. для этого нужно перезапускать bat'ники.
В pru_pulse один блок:
Код:FUNCTION_BLOCK PRU_PULSE (* Output will be generated to FAST OUTPUT 3 *) VAR_INPUT ENABLE: BOOL; CYCLE_LENGTH: WORD; (* PRU cycles *) QUANTITY: DWORD; END_VAR VAR_OUTPUT READY : BOOL; QUANTITY_LEFT: DWORD; (* for debugging *) END_VAR
Вышеобозначенное получено "официальным линкером".
Я ему скормил всю-всю программу как один ФБ.
Для примера, вот так выглядит pulse.p -- т.е. просто вызов одного моего ФБ.
А так выглядит "ассемблерный код" моего ФБ:Код:;include "target.trg" FBDECL #defFB PRU_PULSE PRU_PULSE /FBDECL SYNCLIST IN=R25 IN=R26 IN=R27 OUT=R28 OUT=R29 /SYNCLIST PROGRAMM PRU_PULSE /PROGRAMM
Да, да. Код целиком и полностью сгенерирован в Hardella, а линкеру я скормил пустой файл. Вроде, тот не подавился, и ладно.Код:.origin 0 .entrypoint __INIT_PROGRAM ;FB_WORKTIME=40 ;FB_NAME=PRU_PULSE __INIT_PROGRAM:
Обмен с PRU я сделал так. Тут, к сожалению, сделано наугад в надежде на то, что PRU_FB_GetParameter/PRU_FB_SetParameter будут читать/писать по нужным адресам в PRU памяти.
Код:TMP : DWORD; ... PRU_FB_GetParameter(pru_num:=0, index:=28, value:=ADR(TMP)); READY := TMP <> 0; PRU_FB_GetParameter(pru_num:=0, index:=29, value:=ADR(QUANTITY_LEFT)); PRU_FB_SetParameter(pru_num:=0, index:=25, value:=ADR(QUANTITY)); TMP := WORD_TO_DWORD(CYCLE_LENGTH); PRU_FB_SetParameter(pru_num:=0, index:=26, value:=ADR(TMP)); TMP := SEL(ENABLE, 0, 1); PRU_FB_SetParameter(pru_num:=0, index:=27, value:=ADR(TMP));
Последний раз редактировалось Владимир Ситников; 19.09.2016 в 13:10. Причина: fast output 1 -> fast output 3