Look for a registrer similar name to ADC clk Ctrl in TRM under the ADC section. That's looks like a C macro and it's writing 0x02 to that register. Macro Probably defined in a header file. the registers will have different offsets depending on ARM or PRU access
Perhaps revisit init code on ARM you had working and document every bit that's important in ADC set-up and compare that to this PRU code. Remember getting the Data out of PRU to ARM timings are important. I see you asked me about rproc that I don't use Linux that was TJ comments. I'm afraid the PRU was marketed to you as the answer by people that don't understand your timing requirement. Lot's of script kiddies and cookbook reader's in this group few system engineer that actually read your intial post Good luck Sent from Yahoo Mail on Android On Mon, Apr 12, 2021 at 3:08 PM, Walter Cromer<[email protected]> wrote: I'm working through this and learning a lot. But also realizing how much I have either forgotten or just never knew. So, can I get a quick primer on what this line of C code is doing? HWREG(SOC_CM_WKUP_REGS + CM_WKUP_ADC_TSC_CLKCTRL) = 0x02; Thanks! On Monday, April 12, 2021 at 10:53:22 AM UTC-4 Walter Cromer wrote: 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 On Sat, Apr 10, 2021 at 4:47 AM, TJF<[email protected]> 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/d715b191-d95b-4b86-8fae-eb618c74ddc5n%40googlegroups.com. -- 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/90e0f287-b0b3-41af-9f1e-36fcd06f8dc2n%40googlegroups.com. -- 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/2012620474.714576.1618260693179%40mail.yahoo.com.
