Robert, By the way, there is only one remoteproc / rpmsg example there. The rest is either uio based, or completely non relevant( demonstrating some “new” gcc feature ).
I actually think remoteproc / rpmsg is usefu for multi core systems. Say a
dual core ARM processor where one core is running Linux, and the other is
running bare metal for <whatever> deterministic purpose. I am however still
unconvinced how it is useful when you have multiple cores on die that are
not all application based processors. Such as the PRUs, or on die M4 / IPU
on the X15's processor. DSP . . . yeah I do not know enough about those to
make that call.
Atmel has made a processor (Xmega E series) that has some programmable
logic built in. The idea is that by turning over some simple tasks to
the hardware, you get very low latency, very fast response times, and
do not have to deal with the time penalties imposed by an operating
system. The rest of the Xmega chips already have an event system that
with DMA, could take the A/D outputs and automatically put them in an
array for you, giving you a periodic interrupt when done. All this
without the processor doing anything other than a setup.
Even running bare metal, it is likely that a hardware system (such as
the Xmega or the PRU) will give you faster response times and higher
data rates.
Now tools to use that, well, that's the rub. Currently, for some
designs, I would have to rely on an FPGA with hardwired logic for fast
data acquisition and (some) processing.
DSP? Think a processor with extra instructions for multiply/divide
and such that runs fast enough to do FFT (Fast Fourier Transforms) on
a waveform. Those will result in a spectrum produced from the data.
You can do things with that spectrum (filtering, for instance) that
you cannot easily do with the waveform in the time (waveform on an
oscilloscope) domain.
Harvey
interesting. Looks like the latest beaglebone stable image (2015-11-12 jessie) has the “ti” kernel, not a “bone” kernel. This explains why so many things don’t load for me.
`
root@beaglebone:~# uname -r
4.1.12-ti-r29
root@beaglebone:/sys/class/uio# cat /etc/dogtag
BeagleBoard.org Debian Image 2015-11-12
`
root@beaglebone:~# echo enable-pru > /sys/devices/platform/bone_capemgr/slots
root@beaglebone:~# cat /sys/devices/platform/bone_capemgr/slots
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 0 Override Board Name,00A0,Override Manuf,enable-pru
root@beaglebone:/sys/class/uio# ls
//nothing here//
This leaves me in a bit of a pickle as I’ve managed to make my publicly distributed code install and run on the past two beaglebone images and would like to keep supporting each new image. The ti prussdrv.so shared library still comes compiled and installed in /usr/lib in this new jessie image (source: https://github.com/beagleboard/am335x_pru_package/tree/master/pru_sw/app_loader/interface). However it uses /sys/class/uio.
Is there a new branch of the am335x_pru_package using remoteproc that I’ve missed? alternatively does anyone know what i would have to include to get uio back up and running again without changing kernels? I’m trying to keep my software package as a fairly simple install that runs on all stable “latest-images.” It’s already a bit of a fuss having to modify and recompile the am335x-boneblack.dtb file for each image just to tweak i2c speeds.
thank you for any and all help!
William, you are over thinking this. It isn’t that complicated. If you don’t want to take the time to learn something new, then don’t, but don’t bad mouth something you don’t understand. There are enough examples and documentation out there if you only take the time to look, which is the advise you give all the time. RemoteProc/Virtio/RPMSG are a standardized way to load code into a remote processor, start/stop that code and exchange events/messages between processors. Once you understand that, you can create code that can do almost anything, including the examples you listed.
Regards,
John
Is there a new branch of the am335x_pru_package using remoteproc that I’ve missed? alternatively does anyone know what i would have to include to get uio back up and running again without changing kernels? I’m trying to keep my software package as a fairly simple install that runs on all stable “latest-images.” It’s already a bit of a fuss having to modify and recompile the am335x-boneblack.dtb file for each image just to tweak i2c speeds.
thank you for any and all help!
You have to change kernels. You may be able to recompile a TI kernel to do the same thing as I’ve shown above, but I know for a fact a *bone image will work. I recall someone saying previously that TI’s kernel can no longer be made to use uio_pruss, but perhaps that’s within the context of .config options ?
Another thing. version numbers between these kernels means nothing. There are a few things the TI kernel does thatthe bone kernel does not. But unless you’re using thee features, who cares ?
John, make your own post and post there.