I'll look at that. I thought remoteproc was the way of the future so I was heading down that path. And if in production I don't need to do a lot of data transfer, does it make sense to use uio_pruss/libpruio ( I don't know much about these, it's probably evident that I don't know much about remoteproc either) ?
On Saturday, April 10, 2021 at 2:17:26 PM UTC-4 lazarman wrote: > Hello TJF > > Drop rproc, and use uio_pruss driver instead. Then data exchange is pretty > easy. Ie use DRam[0,1] for PRU-writing and SRam for ARM-writing. A simple > and effective concept to avoid writing collisions (and pretty fast as > well). uio_pruss driver provides pointers to that memory, while using rproc > you've to find a solution by yourself. > > > > > Sent from Yahoo Mail on Android > <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature> > > On Sat, Apr 10, 2021 at 4:47 AM, TJF > <jeli.f...@gmail.com> wrote: > > Hi Walter! > > A further "old dog" here. Sometimes I'm still working on my old Hades > computer with 68060 CPU (loving that box). > > In my house I'm using a BBB for a solar system running 24/7. It also > controlls two valves (on/off, and four AC pumps in 16 power levels), > connected to WLAN by an external USB-Stick. Most temperatures are comming > from 1-wire sensors, but ADC is used to fetch samples from a > high-temperature sensor on the roof/collector. > > You should know that the onboard TSC_ADC_SS sometimes hangs, due to > electromagnetical noice. In that case it allways measures/serves the same > voltage, regardless of the changing input. There's a way to unblock the > subsystem by software. But the better solution is to spend some effort in a > decoupled input circruitry. > > In a new project I start the controller development on ARM, doing > measurements by libpruio. Once the prove of concept is done, I migrate the > controller loop to the other PRU for hard real-time capability. libpruio is > perfect for that concept, since the measurements are available from both > sides, ARM and PRU. All setup is coded only once (on ARM), and only the > inner controller loop needs adaption (from ARM to PRU). In that adaption > the controller usually gets much better, since you won't repeat the bugs > and pitfalls from the POC phase. > > The most important initial decision is concerning the kernel driver to > use. Drop rproc, and use uio_pruss driver instead. Then data exchange is > pretty easy. Ie use DRam[0,1] for PRU-writing and SRam for ARM-writing. A > simple and effective concept to avoid writing collisions (and pretty fast > as well). uio_pruss driver provides pointers to that memory, while using > rproc you've to find a solution by yourself. > > Regards > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard...@googlegroups.com. > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/beagleboard/d715b191-d95b-4b86-8fae-eb618c74ddc5n%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/d715b191-d95b-4b86-8fae-eb618c74ddc5n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/3394d742-038e-4945-babe-cad6812da6d2n%40googlegroups.com.
