What's really throwing me is the + between what looks like two macro values. Normally, we see the + on the right sign of the equals, right? Or am I forgetting something I used to know!?
On Monday, April 12, 2021 at 4:51:52 PM UTC-4 lazarman wrote: > 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 > <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 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 > <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 > <[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 > > <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 [email protected]. > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/beagleboard/90e0f287-b0b3-41af-9f1e-36fcd06f8dc2n%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/90e0f287-b0b3-41af-9f1e-36fcd06f8dc2n%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/98e41d8b-aaec-4205-b105-22885c2f2dfcn%40googlegroups.com.
