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/d84dccd5-bebd-4cc9-93a6-15c2fc4e0419n%40googlegroups.com.
