After posting this, I realized this was a macro and that it was passing the sum of the two values. That seemed weird to me. Thanks for the confirmations! It is coming back slowly!
On Tuesday, April 13, 2021 at 9:40:59 AM UTC-4 pierric...@gadz.org wrote: > To complete on TJF answer, you can find the address defined > by CM_WKUP_ADC_TSC_CLKCTRL in *hw_cm_wkup.h *line 101value (0xbc) and in > *soc_AM335x.h > * line 139. > > > Le mardi 13 avril 2021 à 05:16:58 UTC-4, TJF a écrit : > >> I'm not a C guy (but prefering FreeBASIC for ligh-level and ASM for PRU >> code). Just guessing: >> >> As lazarman mentioned HWREG is a preprocessor macro (perhaps using ARM in >> supervisor mode?) >> SOC_CM_WKUP_REGS is the base adress of the wakeup registers in the >> control module >> CM_WKUP_ADC_TSC_CLKCTRL is the offset for the TSC_ADC_SS clock control >> register >> >> In oder to enable the TSC_ADC_SS the value 0x02 needs to be writen to >> that register. Afterwards you can read or write the subsystems registers. >> (libpruio additionally checks read acces to the ID register in order to >> validate that the subsystem is ready.) >> >> wal...@edenconceptsllc.com schrieb am Dienstag, 13. April 2021 um >> 00:44:09 UTC+2: >> >>> 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 >>>> <wal...@edenconceptsllc.com> 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 >>>> <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...@googlegroups.com. >>>> 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/806a2648-8fb6-4cdc-b4b4-f1aa4c136a29n%40googlegroups.com.
