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/79c1469b-dc46-4bb6-b0b4-000134979df1n%40googlegroups.com.
