I had a similar thought and tried declaring them as volatile. No change in behavior. I also tried making them global vs. local. No change. It was very strange.
What finally worked was changing their names entirely. start_of_pulse became PulseStart end_or_pulse became PulseEnd Now the code works without the two lines of code marked with the '*'. So very, very strange. On Wednesday, May 19, 2021 at 4:42:11 AM UTC-4 [email protected] wrote: > Were the variables declared as `volatile`? May be the compiler optimized > them out of the loop and you might get different behaviour between DEBUG > build and RELEASE build. > > I am guessing the ADC data register is volatile, and this triggers. > > I am guessing the compiler optimization sees two variables set but never > used, so there is no need to include code to set the variables. If declared > as volatile, the compiler knows the variables may be set or read elsewhere. > > On Wednesday, 19 May 2021 at 02:09:19 UTC+1 [email protected] > wrote: > >> i’m replying from an email client but I lost the original and most of my >> replies using Chrome and directly access the group through it. I thought >> it might not present well but I actually highlighted with the client. If >> you’ll tell me what I should use instead I will start using it for future >> posts. I want to make them as easy to read as possible. >> >> I left all the declarations off but mentioned they are declared as >> unsigned int or int. >> >> Yes, this version likely does have some redundancy with >> samples_in_pulse. It is a work in progress that wasn’t making much >> progress because of this weird problem. >> >> It appears now that the names start_of_pulse and end_of_pulse were the >> problem for some reason. I changed them to PulseStart and PulseEnd and >> the PRU responds now. I have no idea what the problem with those names >> is. >> >> Walter >> >> On Tue, May 18, 2021 at 8:14 PM Dennis Lee Bieber <[email protected]> >> wrote: >> >>> On Tue, 18 May 2021 11:22:20 -0700 (PDT), in >>> gmane.comp.hardware.beagleboard.user Walter Cromer >>> <walterc-2dFtBuzUeF/[email protected]> wrote: >>> >>> >>> >Here's the code snippet with the two variables in bold. If those lines >>> of >>> >code do not exist, the host doesn't hear from the PRU. >>> >>> Such formatting does not get through the gmane list<>newsgroup >>> interface. I'm going to presume you mean the lines with * markers. >>> Posting >>> with a client that keeps indentation would also help... hard to keep >>> track >>> of what is nested into what when everything is left justified with excess >>> blank lines. >>> >>> Normal recommendation is to condense the code down to the >>> minimum that >>> still reproduces the problem, and to post the minimized files completely >>> (probably need both PRU and ARM programs). That allows others to attempt >>> to >>> run/compare/debug. >>> >>> > >>> > >>> > >>> >count = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFOCOUNT(0)); >>> > >>> > >>> > >>> >for (i = 0; i < count; i++) >>> > >>> >{ >>> > >>> >Data = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0)); >>> > >>> >StepRead = (Data >> 16) & 0xF; >>> > >>> >RawAnalog = Data & 0xFFF; >>> > >>> > >>> > >>> >switch (StepRead) >>> > >>> >{ >>> > >>> >case 0: >>> > >>> > >>> > >>> >DetTSampleSet[pnr]=RawAnalog; >>> > >>> >break; >>> > >>> >case 1: >>> > >>> > >>> > >>> >*start_of_pulse = 0;* >>> > >>> >*end_of_pulse = 0;* >>> >>> Where were these declared? >>> > >>> > >>> > >>> >DetBSampleSet[pnr]=RawAnalog; >>> > >>> >if ((pnr == end_of_pulse) && (in_pulse == E_YES)) // seen a pulse and >>> at >>> >end of it analyze signal >>> >>> Where is pnr defined/initialized? Same for in_pulse. >>> > >>> >{ >>> > >>> >DetBSignalAverage= AnalyzeSignal(start_of_pulse, pnr); >>> > >>> >start_of_pulse = -1; >>> > >>> >end_of_pulse = -1; >>> > >>> >>> If pnr is an index into some buffer, I'd probably use -1 to >>> signal NO >>> DATA, and use the pnr values active at the time the pulse is detected for >>> start_of_pulse and the when the pulse ended for end_of_pulse >>> >>> >samples_in_pulse = 0; >>> > >>> >in_pulse = E_NO; >>> >>> In a way, all these seem redundant: start&end at -1 indicates no >>> data, >>> no samples, and not in a pulse. Samples_in_pulse at 0 indicates no data, >>> no >>> samples, and likely not in a pulse. in_pulse at E_NO implies no data, no >>> samples. >>> >>> So, start&end are set to the appropriate pnr values... >>> "in_pulse" is >>> indicated by start_of_pulse > -1 AND end_of_pulse = -1; "not in_pulse" is >>> indicated by (start_of_pulse > -1 AND end_of_pulse > -1) OR >>> (start_of_pulse >>> = -1) //presumes you set both start/end to -1 at the same time >>> >>> > >>> >if (start_of_pulse < 0) start_of_pulse = pnr; // set start pointer in >>> ring >>> >buffer if it hasn't already been set for this pulse >>> > >>> >>> Okay, you do set start/end to the instantaneous pnr value... Just >>> emphasizes that samples_in_pulse and in_pulse are logically redundant and >>> hence a potential source of error (samples_in_pulse should be end - start >>> (maybe with a +1; do the math with a sample buffer). Note: if this is a >>> circular buffer you'll need to account for wrap-around. >>> >>> >>> -- >>> Dennis L Bieber >>> >>> -- >>> 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/bmk8ag1h4l4qsl9enn0ri3spm326qtbpdj%404ax.com >>> . >>> >> -- >> Thanks, >> >> Walter Cromer, MS, PMP, PMI-ACP, CSM >> Chief Idea Officer and Founder >> Eden Concepts LLC >> w: http://edenconceptsllc.com >> m: 865-719-8881 <(865)%20719-8881> >> > -- 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/4f18575e-107d-4db8-989e-79a70a2828afn%40googlegroups.com.
