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 <dennis.l.bie...@gmail.com>
wrote:
> On Tue, 18 May 2021 11:22:20 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
> <walterc-2dFtBuzUeF/tpnmuczy8bueocmrvl...@public.gmane.org> 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 beagleboard+unsubscr...@googlegroups.com.
> 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
--
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/CAGNysGahxhkBwMeP4hjWREFyc1n5S9K_t5ynNgdcrzGReDJfTQ%40mail.gmail.com.
