Языки высокого уровня, среды разработки, всякие красочные выделения синтаксиса цветом - это конечно прикольно и впечатляет неокрепшие разумы и вселяет в них надежду ))) но поймите - за это платят размером кода, быстродействием и "глюками"... когда код пишется для работы на компах с гигами памяти и встроенной яве - это весьма расширяет круг пользователей ! )))
.. но обсуждаемая тема про другое! жесточайший лимит памяти, суровые команды с не очевидным синтаксисом, ориентированные на максимальное быстродействие - вот что такое PRU. Здесь место "голого ассемблера", даже чистый С будет неэффективно расходовать регистры и постоянно срываться на использование медленной памяти, а уж самописный транслятор...... Поэтому я считаю что тема пошла по неправильному курсу - хочется людям "красивостей", да за ради бога, но лично я не вижу применения этому. Имеющийся материал ужасть какой сырой и нужно прежде всего его обкатывать - три дня на элементарный проброс данных через PRU с помощью существующих блоков - при наличии вроде как рабочего примера - за гранью добра и зла )))
Я пошел по другому пути - ФБ PRU_DIMAS и в нем голый ассемблер с минимальным использованием описателей, лишь бы удовлетворить транслятор, в котором требуемый мне алгоритм не отягощен требованиями на совместимость блоков и выделением регистров на хранение промежуточных результатов... ну и START END по краям, вроде как обязательные... и вот они импульсы в 50 кГц.... как оказалось чуть позже - импульсы в 500 кГц были просто не видны из-за емкости щупов и установленной подтяжки ))
а вывод PRU -> "кино не для всех" и овеновцы правы в том что тратят основное время на что-нить другое, согласитесь проблем хватает...
кстати, то что "быстрые ВЫХОДЫ" поделены между 2 процессорами по 2 я уже вычитал, а входы как заведены? все 4 в каждое ядро, параллельно???
Ответить с цитированием