Цитата(aaarrr @ Sep 14 2015, 20:08)

Кстати, не приходилось их где-нибудь использовать?
Ну естественно сразу использовал PRU0 стандартно - для запуска ARM-ядра.
Позже хотел использовать для организации низкоуровневого драйвера обмена с кучкой SPI-АЦП. В текущей реализации чтение потока данных с 3-х 8-канальных SPI-АЦП осуществляется через McASP (на McASP эмулирую SPI). На этом же McASP кроме 3-х АЦП висит ещё аудио-ЦАП с I2S-интерфейсом.
Всё это работает одновременно на связке McASP+EDMA3, обслуживается ARM-ядром. Но при такой связке, не получилось по сигналам организовать обратный поток на АЦП (во время потока по обратному каналу (MOSI) этими АЦП можно управлять, например - считывать или записывая некоторые регистры АЦП не прерывая непрерывного потока сэмплов (между кадрами), но сериализаторами McASP это не получается сделать по сигналам).
Так вот, в дальнейшем, при наращивании функционала устройства, я планировал всю задачу обмена с АЦП перенести со связки McASP+DMA на одно из PRU-ядер, программно сэмулировав 3 отдельных SPI-канала на PRU-ядре. Грузить такой задачей одно из основных ядер не хотелось.
Я проработал это направление: разобрался в ассемблере PRU, написал простое ПО на него (эмуляция UART и работа по нему со взаимодействием с ARM-ядром). Но потом заказчик решил, что он доволен текущим функционалом устройства и решил не продолжать дальнейшее развитие

((
Но всё-таки хоть и тестовое, но ПО на PRUSS у меня работало.

Цитата(aaarrr @ Sep 14 2015, 23:20)

Учитывая примитивность "ядер", едва ли в том была необходимость. Подозреваю, что PRU выросли из пожеланий кого-то из ключевых заказчиков, которые затем перешли в массовые изделия.
Не согласен.
PRU-ядра очень удобны для организации отсутствующей нестандартной периферии, где нужно например делать что-то очень простое с пинами GPIO (или другими интерфейсами), но очень быстро и не грузить простой задачей основные ядра.
Либо если нужно выполнять простую, но интенсивную обработку каких-то больших объёмов данных, которая слишком сложна, чтобы сделать её на EDMA3, но на PRUSS хоть на ассемблере нетрудно реализовать.
Например - принимая с какого интерфейса поток данных, необходимо преобразовать его в более удобную для обработки форму (переставив какие-то данные, поменив порядок байт или бит и т.п.).
Можно было-бы конечно вместо них поставить полнофункциональные ядра, но на них думаю потребовалось-бы гораздо больше вентилей и может не хватило-бы, или не хватило на два ядра.
Я считаю такую организацию: ARM + DSP + два субъядра очень удачной и удобной. Жаль только отладчик не цеплялся к PRU-ядрам.