Thanks, TJF! This sounds like good advice but tough tricks to learn! The more I think through the architecture of my solution, the more I realize the PRU code needs to do. In our lab evaluation setup, I need the voltages measured by the ADC for analysis to develop base algorithms for detecting the events from the sensors properly. But once we have that developed, in a production system, the PRU code will apply the logic to the data it is reading and probably should control the valves directly through with the GPIOs. Otherwise, if we pass the data to the ARM side, Linux could go off and service something else and leave the valves running when they shouldn't be or not running when they should be. But startup parameters will be selected by the user, so I'm thinking the UI is on ARM and once it has the start-up information, it just passes key info to the PRU code and lets it go do its thing.
So what is the long-term support for the different options? I thought remoteproc was the way of the future and uio_pruss drivers were phasing out. We are on the front end of a new product/solution design and need to pay attention to 'end of life' type issues. (Of course, the solution must work too!) Good to know about the EM interference. Theoretically, we should be in a low external EM noise environment, however, we are using the BBB Wireless! I had painful experiences with RF wreaking havoc on a system in graduate school. On Saturday, April 10, 2021 at 5:47:41 AM UTC-4 TJF 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/6a1cbbb4-6e14-4b5c-b5ff-25dcfd07d753n%40googlegroups.com.
