Re: [beagleboard] Re: Reading ADC with both PRUs

[Walter Cromer]

Mark - I think I waited a day or maybe two.  They've engaged and are 
answering my questions.  It's congruent with what is being shared here.

Walter

On Friday, June 11, 2021 at 5:28:54 PM UTC-4 lazarman wrote:

> Hello Walter
>
> Two ansychronous processor's it's entirely possible eventually ones 
> writing and other is reading and gets bad Data that's why they invented 
> hardware dual port ram.
>
> Ping pong circular buffer's work on one processor systems you disable 
> interrupts in critical regions or lock it with a mutex controlled by RTOS.
>
> Perhaps it's not critical
>
> How long have you been waiting on an answer just curious?
>
> Mark
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Fri, Jun 11, 2021 at 12:33 PM, Dennis Lee Bieber
>  wrote:
>
> On Fri, 11 Jun 2021 09:44:27 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  wrote:
>
> >I can have PRU1 do all the ADC configuration including setting up steps 
> 1, 
> >2 and 3 to read three analog lines in one-shot mode while steps 4 & are 
> set 
> >up to read the other two analog lines in continous mode.  I'll write data 
> >from steps 1, 2 and 3 into FIFO0 and 4 & 5 into FIFO1.  
> >
> >The question is can PRU0 read FIFO0 while PRU1 might try to read FIFO1 at 
> >the same time?  
>
> Given that each PRU is capable of accessing the other's data RAM (as I
> recall, each PRU sees its RAM at address 0, and sees the other's RAM at
> some fixed offset), I'd probably use a few words of PRU0's RAM and have
> PRU1 write into that space, along with a timestamp value -- PRU0 would look
> for a change in the timestamp, then grab the ADC values (allowing PRU1 to
> write new values while PRU0 processes the previous set -- Or PRU0 clears
> the timestamp [which is no longer a timestamp] which PRU1 sees as "okay to
> write new values", PRU1 then sets the timestamp byte to tell PRU0 "okay to
> read". Closest I can come to a shared semaphore/mutex (are there any
> synchronization primitives in the PRU runtime?).
>
>
> -- 
> 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+unsub...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/s377cghljsjo1uhfmsn4sbj7bi1206lcnq%404ax.com
> .
>
>

-- 
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/b8503d7a-30a7-4ef8-96b4-7bf6033dd3cen%40googlegroups.com.

Re: [beagleboard] Re: Reading ADC with both PRUs

[Walter Cromer]

Good info.  I'm going to set up some testing.   Thank you!

On Monday, June 14, 2021 at 3:23:29 AM UTC-4 lazarman wrote:

> #The question is can PRU0 read FIFO0 while PRU1 #might try to read FIFO1 
> at the same time?
>
> If these FIFOS are in  Data RAM it's recommended to use shared memory. 
> What's confusing is as I understood it there's a PRU shared RAM and another 
> larger shared memory so sample code must be inspected carefully if that's 
> true to understand exactly what's being referred to as Shared. I think the 
> larger RAM is called OCM.
>
> Below and following link  is the relavent blurb to support my comment I 
> found here
>
>
> https://elinux.org/Ti_AM33XX_PRUSSv2
>
>
>
> One PRU may access the memory of another for passing information but it is 
> recommend to use scratch pad or shared memory, see below.Open Core 
> Protocol  (OCP) master 
> portAccess to the data bus that interconnects all peripherals on the SoC, 
> including the ARM Cortex-A8, used for data transfer directly to and from 
> the PRU in Level 3 (L3) memory space.Shared Between PRUsScratch pad3 
> banks of 30 32-bit registers (total 90 32-bit registers).Single-cycle 
> access, can be accessed from either PRU for data sharing and signalling or 
> for individual use.12KB data memoryAccessed over the 32-but bus, not 
> single-cycle.
> Sent from Yahoo Mail on Android 
> 
>
> On Sun, Jun 13, 2021 at 10:38 AM, TJF
>  wrote:
>
>
> wal...@edenconceptsllc.com schrieb am Freitag, 11. Juni 2021 um 18:44:27 
> UTC+2:
>
> ... setting up steps 1, 2 and 3 to read three analog lines in one-shot 
> mode while steps 4 & are set up to read the other two analog lines in 
> continous mode.  I'll write data from steps 1, 2 and 3 into FIFO0 and 4 & 5 
> into FIFO1.
>
> Yes. You can use the FIFO_select bit (26) in the STEPCONFIGx registers to 
> spread the samples. And when the Mode bits (1-0) are cleared (one-shot) the 
> sequencer will disable that step after operation (in STEPENABLE register). 
> Next turn  the sequencer will again consider only enabled steps.
>
> The question is can PRU0 read FIFO0 while PRU1 might try to read FIFO1 at 
> the same time?
>
> Not at the same time, but one after the other (L3 access control). AFAIR 
> PRU-1 waits until PRU-0 is done. And both PRUSS are waiting until ARM is 
> done.
>
>
> -- 
> 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/f4f5965c-6350-442a-b91a-47b7535d9cecn%40googlegroups.com
>  
> 
> .
>
>

-- 
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/05e4f1e0-f0e1-4e62-9652-7a696e58e1e3n%40googlegroups.com.

[beagleboard] Re: Reading ADC with both PRUs

[Walter Cromer]

I am thinking that I'll have PRU0 do all the configuration and enabling of 
the TSC and have the values for the two sensors that I want PRU1 to monitor 
put in FIFO1.  I'll have PRU0 only read from FIFO0 and let PRU1 only read 
from FIFO1.  
I will set up the three I want to read in one-shot mode and have PRU0 
enable them to be read again.   the other two will be in continuous mode so 
PRU0 won't have to do anything as long as it doesn't change their 
configuration.   
If PRU-1 waits until PRU-0 is done then it can read FIFO1 as needed to get 
the data.  I only need it to read these possibly as little as once per 
second so that alone will reduce the number of potential conflicts with 
PRU0.

If this will work it will eliminate having PRU0 read FIFO1 and write the 
data into shared memory space where PRU1 could read it.  That in itself 
would have a potential conflict on PRU0 write/PRU1 read.
On Sunday, June 13, 2021 at 11:38:06 AM UTC-4 TJF wrote:

>
> wal...@edenconceptsllc.com schrieb am Freitag, 11. Juni 2021 um 18:44:27 
> UTC+2:
>
>> ... setting up steps 1, 2 and 3 to read three analog lines in one-shot 
>> mode while steps 4 & are set up to read the other two analog lines in 
>> continous mode.  I'll write data from steps 1, 2 and 3 into FIFO0 and 4 & 5 
>> into FIFO1.
>>
> Yes. You can use the FIFO_select bit (26) in the STEPCONFIGx registers to 
> spread the samples. And when the Mode bits (1-0) are cleared (one-shot) the 
> sequencer will disable that step after operation (in STEPENABLE register). 
> Next turn  the sequencer will again consider only enabled steps.
>
> The question is can PRU0 read FIFO0 while PRU1 might try to read FIFO1 at 
>> the same time?
>>
> Not at the same time, but one after the other (L3 access control). AFAIR 
> PRU-1 waits until PRU-0 is done. And both PRUSS are waiting until ARM is 
> done.
>
>

-- 
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/fc828903-9075-412a-9f1a-ca8aec37eb1an%40googlegroups.com.

[beagleboard] Re: Reading ADC with both PRUs

[Walter Cromer]

I'm going to hold on to this as a backup option.   I'm already using the 
shared memory space so that's another option but writing to PRU0's local 
RAM may be faster.  I don't know.   The monitor/control that PRU1 is doing 
doesn't would be just fine with a 1-second read interval I think.  The 
three lines that PRU0 is already reading in this application require at 
least 3ms intervals or better.   

Thanks for the good idea on this.

Walter

On Friday, June 11, 2021 at 1:33:05 PM UTC-4 Dennis Bieber wrote:

> On Fri, 11 Jun 2021 09:44:27 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  wrote:
>
> >I can have PRU1 do all the ADC configuration including setting up steps 
> 1, 
> >2 and 3 to read three analog lines in one-shot mode while steps 4 & are 
> set 
> >up to read the other two analog lines in continous mode. I'll write data 
> >from steps 1, 2 and 3 into FIFO0 and 4 & 5 into FIFO1. 
> >
> >The question is can PRU0 read FIFO0 while PRU1 might try to read FIFO1 at 
> >the same time? 
>
> Given that each PRU is capable of accessing the other's data RAM (as I
> recall, each PRU sees its RAM at address 0, and sees the other's RAM at
> some fixed offset), I'd probably use a few words of PRU0's RAM and have
> PRU1 write into that space, along with a timestamp value -- PRU0 would look
> for a change in the timestamp, then grab the ADC values (allowing PRU1 to
> write new values while PRU0 processes the previous set -- Or PRU0 clears
> the timestamp [which is no longer a timestamp] which PRU1 sees as "okay to
> write new values", PRU1 then sets the timestamp byte to tell PRU0 "okay to
> read". Closest I can come to a shared semaphore/mutex (are there any
> synchronization primitives in the PRU runtime?).
>
>
> -- 
> 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/78f2bd55-726a-4b03-9cf4-345d6486ec59n%40googlegroups.com.

[beagleboard] Reading ADC with both PRUs

[Walter Cromer]

I have asked this of TI but haven't really gotten a firm answer and I can't 
seem to find a clear discussion in the Technical Reference Manual.

I would like to set up PRU1 to monitor two analog input lines and take an 
action on two GPIOs depending on the values it reads.  It would just be 
started by either the host program through remoteproc or by PRU0.  

Simultaneously, I need PRU0 to read three other analog lines and do more 
complex control work with those.  

I can have PRU1 do all the ADC configuration including setting up steps 1, 
2 and 3 to read three analog lines in one-shot mode while steps 4 & are set 
up to read the other two analog lines in continous mode.  I'll write data 
from steps 1, 2 and 3 into FIFO0 and 4 & 5 into FIFO1.  

The question is can PRU0 read FIFO0 while PRU1 might try to read FIFO1 at 
the same time?  

-- 
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/525d424f-91dc-4f3a-9be6-f714e1f62bf2n%40googlegroups.com.

[beagleboard] Re: Weird C problem: PRU doesn't respond to host if two variables aren't initialized in loop

[Walter Cromer]

Dennis, 

Thanks again for pointing out the redundancy.   Now that I have this very 
strange problem figured out I'm going to do some work on that and clean it 
up.

Walter

On Tuesday, May 18, 2021 at 8:14:18 PM UTC-4 Dennis Bieber wrote:

> On Tue, 18 May 2021 11:22:20 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  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 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 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/c8ad6b9c-dff0-4595-ae96-8e31f8e02856n%40googlegroups.com.

Re: [beagleboard] Re: Weird C problem: PRU doesn't respond to host if two variables aren't initialized in loop

[Walter Cromer]

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 robert.sty...@gmail.com 
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 wal...@edenconceptsllc.com 
> 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  
>> wrote:
>>
>>> On Tue, 18 May 2021 11:22:20 -0700 (PDT), in
>>> gmane.comp.hardware.beagleboard.user Walter Cromer
>>>  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;
>>> >
>&

Re: [beagleboard] Re: Weird C problem: PRU doesn't respond to host if two variables aren't initialized in loop

[Walter Cromer]

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 
wrote:

> On Tue, 18 May 2021 11:22:20 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  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 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 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.

Re: [beagleboard] Weird C problem: PRU doesn't respond to host if two variables aren't initialized in loop

[Walter Cromer]

I renamed the variables start_of_pulse and end_of_pulse to just PulseStart 
and PulseEnd and it works now.  I haven't seen anything in the PRU Compiler 
manual about these being restricted names or symbols but I suppose they 
were.
Weird.


On Tuesday, May 18, 2021 at 3:54:50 PM UTC-4 Walter Cromer wrote:

> I could never get the PRUDebug tool to compile and run.  I'll give it 
> another try.
>
> What's really weird is that if I set these two variables to values like 
> this for example.
>
> start_of_pulse = 5;
> end_of_pulse = 15; 
>
> Then it runs just fine.  I actually send the data back through RPMSG and 
> it's good. 
>
> It doesn't matter what the actual numbers are.  It can be -1, 0, 
> anything.  But if I try something like this.
>
> start_of_pulse = start_of_pulse + 5;
> start_of_pulse = start_of_pulse - 5; // this is sort of a no change change.
>
> It just doesn't send anything back.  No response from the PRU at all.
>
>
>
> On Tuesday, May 18, 2021 at 2:39:38 PM UTC-4 lazarman wrote:
>
>> Hi Walter 
>>
>> Probally unrelated but I wanted to share I saw if  the linker command 
>> files didn't include startup code to initialize variables or zero them like 
>> the ARM does.
>> A huge uncleaned index intyo an array wouldn't  be good.
>> Perhaps this PRUDebug tool can speed up your debugging have not tried it.
>>
>> Mark
>>
>>
>>
>> Sent from Yahoo Mail on Android 
>> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>>
>> On Tue, May 18, 2021 at 1:30 PM, Walter Cromer
>>  wrote:
>>
>> I've been pulling my hair out over a really weird problem and after 
>> trying everything I know to try, I'm posting it here in hopes of someone 
>> seeing the problem.
>>
>>  I am running a Beaglebone Black.  The output of version.sh is at the end 
>> of this post.
>>
>> Linux beaglebone 4.19.94-ti-r61 #1buster SMP PREEMPT Wed Mar 31 15:23:20 
>> UTC 2021 armv7l GNU/Linux
>>
>> I boot from an SD card.
>>
>> I'm using remoteproc to communicate between a host program and the PRU 
>> code.
>>
>> The program is long and includes stuff that I don't think is important 
>> here like configured the ADC and IEP counter.
>>
>>  
>>
>> The host program lets the user choose from a menu what they want the PRU 
>> to do.  Then using RPMSG, the command is sent to the PRU.  It receives the 
>> message, determines what it is and executes the appropriate action in the 
>> PRU code.  This is done by reading the message and using an "if-else 
>> if-else".  One of the actions is to read three analog inputs and return the 
>> values read through RPMSG.   Each analog value is stored in a ring 
>> buffer-type array, type unsigned int, that is allocated in the PRU Shared 
>> memory space.   
>>
>>  
>>
>> So once the host sends the message to do the analog input read, it starts 
>> to listen for responses from the PRU.
>>
>>  
>>
>> This all works great.  I get data from the PRU and the host program puts 
>> it in a CSV file that I can analyze with other tools.  
>>
>> Now, though we need to do some basic math on the data in the PRU.  I only 
>> need to do this on a subset of the data in the arrays and the start and end 
>> points in the array can vary.  So I have two integer variables that I use 
>> to store the start and end points. So, the routine that reads the 
>> analog data sets the values of these two variables as voltage thresholds 
>> are met.  The code compiles just fine.
>>
>>  
>>
>> However, if these two variables are not set to a constant within the 
>> loop, the host never gets a message from the PRU code.  They are set to 
>> initial values before the loop (that code is not included below.) 
>>
>> It's the craziest thing I've ever run into I think.   I have declared 
>> these variables as local and global and nothing seems to matter.  If they 
>> are set to a constant in the loop, the host doesn't get a message from the 
>> PRU program. 
>>
>>  
>>
>> 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.
>>
>>  
>>
>> 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))

Re: [beagleboard] Weird C problem: PRU doesn't respond to host if two variables aren't initialized in loop

[Walter Cromer]

I could never get the PRUDebug tool to compile and run.  I'll give it 
another try.

What's really weird is that if I set these two variables to values like 
this for example.

start_of_pulse = 5;
end_of_pulse = 15; 

Then it runs just fine.  I actually send the data back through RPMSG and 
it's good. 

It doesn't matter what the actual numbers are.  It can be -1, 0, anything.  
But if I try something like this.

start_of_pulse = start_of_pulse + 5;
start_of_pulse = start_of_pulse - 5; // this is sort of a no change change.

It just doesn't send anything back.  No response from the PRU at all.



On Tuesday, May 18, 2021 at 2:39:38 PM UTC-4 lazarman wrote:

> Hi Walter 
>
> Probally unrelated but I wanted to share I saw if  the linker command 
> files didn't include startup code to initialize variables or zero them like 
> the ARM does.
> A huge uncleaned index intyo an array wouldn't  be good.
> Perhaps this PRUDebug tool can speed up your debugging have not tried it.
>
> Mark
>
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Tue, May 18, 2021 at 1:30 PM, Walter Cromer
>  wrote:
>
> I've been pulling my hair out over a really weird problem and after trying 
> everything I know to try, I'm posting it here in hopes of someone seeing 
> the problem.
>
>  I am running a Beaglebone Black.  The output of version.sh is at the end 
> of this post.
>
> Linux beaglebone 4.19.94-ti-r61 #1buster SMP PREEMPT Wed Mar 31 15:23:20 
> UTC 2021 armv7l GNU/Linux
>
> I boot from an SD card.
>
> I'm using remoteproc to communicate between a host program and the PRU 
> code.
>
> The program is long and includes stuff that I don't think is important 
> here like configured the ADC and IEP counter.
>
>  
>
> The host program lets the user choose from a menu what they want the PRU 
> to do.  Then using RPMSG, the command is sent to the PRU.  It receives the 
> message, determines what it is and executes the appropriate action in the 
> PRU code.  This is done by reading the message and using an "if-else 
> if-else".  One of the actions is to read three analog inputs and return the 
> values read through RPMSG.   Each analog value is stored in a ring 
> buffer-type array, type unsigned int, that is allocated in the PRU Shared 
> memory space.   
>
>  
>
> So once the host sends the message to do the analog input read, it starts 
> to listen for responses from the PRU.
>
>  
>
> This all works great.  I get data from the PRU and the host program puts 
> it in a CSV file that I can analyze with other tools.  
>
> Now, though we need to do some basic math on the data in the PRU.  I only 
> need to do this on a subset of the data in the arrays and the start and end 
> points in the array can vary.  So I have two integer variables that I use 
> to store the start and end points. So, the routine that reads the 
> analog data sets the values of these two variables as voltage thresholds 
> are met.  The code compiles just fine.
>
>  
>
> However, if these two variables are not set to a constant within the loop, 
> the host never gets a message from the PRU code.  They are set to initial 
> values before the loop (that code is not included below.) 
>
> It's the craziest thing I've ever run into I think.   I have declared 
> these variables as local and global and nothing seems to matter.  If they 
> are set to a constant in the loop, the host doesn't get a message from the 
> PRU program. 
>
>  
>
> 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.
>
>  
>
> 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;*
>
>  
>
> DetBSampleSet[pnr]=RawAnalog;
>
> if ((pnr == end_of_pulse) && (in_pulse == E_YES)) // seen a pulse and at 
> end of it analyze signal
>
> {
>
> DetBSignalAverage= AnalyzeSignal(start_of_pulse, pnr);
>
> start_of_pulse = -1;
>
> end_of_pulse = -1;
>
> samples_in_pulse = 0;
>
> in_pulse = E_NO;
>
> }
>
> else
>
> {
>
> DetBSignalAv

Re: [beagleboard] Re: Shared PRU Memory and beyond

[Walter Cromer]

Regardless of the timing, you want to store 20,000 values but I think 
you've calculated correctly that you can only store 7,168 values in the 28k 
of combined PRU memory and that would only be true if some of the PRU 
memory wasn't used by your PRU program when it's loaded.

So are you trying to find a way to store the data back in the main host 
memory instead?  

Remoteproc/RPMSG can send the data back but I don't think it's fast enough 
for you. I'm doing that now with code written in C.  (It was a bear to 
learn and get going but I'm a rusty guy too. ) I am reading 12-bit AD with 
the onboard ADC (Touchscreen controller in general-purpose mode).I saw 
one post on the TI E2E forum that indicated that Remoteproc/RPMSG is not 
intended to be a fast data transfer mechanism.   That was by a TI engineer 
I think.

The only alternative I can think of is declaring variables in your PRU code 
whose address is actually in the main host memory (Linux) space.   I've 
tried to do this using the example in Mark Yoder's PRU Cookbook but I could 
not get it to work.  I decided that I didn't really need that and went 
another route.

@TJF on this forum promotes a solution called libpruio that might work.  I 
don't know if it's fast enough though.

This is a good group so keep the discussion going and maybe we can figure 
something out.



On Monday, May 17, 2021 at 8:26:49 PM UTC-4 lazarman wrote:

> Hello 
>
> Google Am335x  PRU Support package it's got 6 labs and examples including 
> ADC.
>
> It's written for the SDK Linux  Dennis mentioned but people have gotten 
> these examples to work with Linux supported in this group
>
> There's also a Support package tar  containing step by step HTML of all 
> the labs above preserved from the old wiki.
>
> There's several PDF files supporting all this some are application notes
>
> Getting started with RPMSg on Linux is one 
>
> If you start with these HTML files it's really well written it's a how-to
>
> Labs 1 to 3 require CCS JTAG
>
> The other labs deal with Linux
>
> The ADC example passes samples back to Linux.
>
> For a full blown PID loop using both PRU there's a example code also on 
> GitHub preserved from TI support expert Nick.
>
> The PRU support package 5.8 code on GitHub or wherever get it in the 
> examples shows linker commands for using shared RAM.
>
> The concept in any book of accessing these has more to do with pragma or 
> compliler specific linker commands in gcc should not change 
>
> Every book or cookbook or tutorial ever written was all this data I 
> pointed you to explained by an experienced engineer's using TI wiki Data
>
> That my opinion.
>
> Remember this  stuff will talk about building code from command line in 
> the 4G SDK which requires a native Ubuntu box or a virtual box Ubuntu on 
> windows 7. Officially vbox support isn't suppored anymore but I got it 
> working recently only tested windows 7
>
> All this discussion can be found by googling " PRU ADC beaglebone" 
> also many discussion on E2E forum replace Beaglebone with 2E
>
> I'd suggest reading that getting started first
>
>
> Or use Mark Yoder's cookbook which is web-based compilation on the board 
> itself. I have not tried that
>
> Lastly if you take the Apple's and Oranges approach which is taking the 
> source code I mentioned and trying to follow the cookbook web based 
> compilation. Most people seem to fail trying this I don't recommend it 
>
> Pick one approach
>
>
> Good luck
> Mark
>
>
>
>
>
>
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Mon, May 17, 2021 at 6:32 PM, Dennis Lee Bieber
>  wrote:
>
> On Mon, 17 May 2021 13:00:04 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Bruce Chidester
>  wrote:
>
> >  Not sure I am replying properly to preserve the format desired for this 
> >page, but your (Dennis B) response definitely deserves a response from me.
>
> Difficult -- somehow your added comments are formatted as quoted text
> (ie, my comments).
>
> >
> >On Monday, May 17, 2021 at 12:39:53 PM UTC-5 Dennis Bieber wrote:
> >
>
> >> 80 samples/msec... or 8 per second. If I converted properly, about 
> >> 0.0125msec per sample. 
> >>
> >> I will be sampling from an ADC up to 1MHz maybe. 
>
> The PRU itself only runs at 200MHz, and you have to account for how
> many instructions are needed to run your ADC-start, read, store, notify
> host logic.
>
> >> Does the second addition contain the updates to the remote proc process?
> >
> It uses Remote Proc for the examples -- but does NOT have ADC examples.
> It does warn that Remote Proc/rpmsg is fairly new (at the time of the book)
> and that things might change. Unfortunately TI has changed its document
> access, so the links in the 2nd edition book don't work. Most of the
> documentation seems to be at
>
> 

[beagleboard] Weird C problem: PRU doesn't respond to host if two variables aren't initialized in loop

[Walter Cromer]

I've been pulling my hair out over a really weird problem and after trying 
everything I know to try, I'm posting it here in hopes of someone seeing 
the problem.

 I am running a Beaglebone Black.  The output of version.sh is at the end 
of this post.

Linux beaglebone 4.19.94-ti-r61 #1buster SMP PREEMPT Wed Mar 31 15:23:20 
UTC 2021 armv7l GNU/Linux

I boot from an SD card.

I'm using remoteproc to communicate between a host program and the PRU code.

The program is long and includes stuff that I don't think is important here 
like configured the ADC and IEP counter.

 

The host program lets the user choose from a menu what they want the PRU to 
do.  Then using RPMSG, the command is sent to the PRU.  It receives the 
message, determines what it is and executes the appropriate action in the 
PRU code.  This is done by reading the message and using an "if-else 
if-else".  One of the actions is to read three analog inputs and return the 
values read through RPMSG.   Each analog value is stored in a ring 
buffer-type array, type unsigned int, that is allocated in the PRU Shared 
memory space.   

 

So once the host sends the message to do the analog input read, it starts 
to listen for responses from the PRU.

 

This all works great.  I get data from the PRU and the host program puts it 
in a CSV file that I can analyze with other tools.  

Now, though we need to do some basic math on the data in the PRU.  I only 
need to do this on a subset of the data in the arrays and the start and end 
points in the array can vary.  So I have two integer variables that I use 
to store the start and end points. So, the routine that reads the 
analog data sets the values of these two variables as voltage thresholds 
are met.  The code compiles just fine.

 

However, if these two variables are not set to a constant within the loop, 
the host never gets a message from the PRU code.  They are set to initial 
values before the loop (that code is not included below.) 

It's the craziest thing I've ever run into I think.   I have declared these 
variables as local and global and nothing seems to matter.  If they are set 
to a constant in the loop, the host doesn't get a message from the PRU 
program. 

 

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.

 

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;*

 

DetBSampleSet[pnr]=RawAnalog;

if ((pnr == end_of_pulse) && (in_pulse == E_YES)) // seen a pulse and at 
end of it analyze signal

{

DetBSignalAverage= AnalyzeSignal(start_of_pulse, pnr);

start_of_pulse = -1;

end_of_pulse = -1;

samples_in_pulse = 0;

in_pulse = E_NO;

}

else

{

DetBSignalAverage = 0;

}

if (RawAnalog > 0xB54)

{

__R30 |= PanelYellowLED; // turn yellow LED on; at the sampling rate we're 
using this may result in just a flicker

in_pulse = E_YES; // once the leading edge of the pulse passes set this

samples_in_pulse++; // count the number of samples in the pulse

DetBSignalAverage = 999; // samples_in_pulse;//just using for debugging

//

// here we will check for a max # of samples in pulse while in a pulse to 
throw out start of fluid or end of fluid or pulses larger than a seed

//

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

}

else if ((RawAnalog <= 0xAC8) && (in_pulse == E_YES))

{

__R30 &= ~CAValve;  // turn compressed air off; stop fluid flow because the 
pulse has cleared the bottom detector

in_pulse = E_NO; // pulse is over

DetBSignalAverage = 1999; //samples_in_pulse;//just using for debugging

//

// this is an alternative place to check the number of samples in the pulse 
to throw out start / end of fluid but we would never stop because Rawanalog

// will never drop while there is no fluid in the tube

//

if (end_of_pulse < 0) end_of_pulse = pnr;  // capture where we are in the 
ring buffer at the end of the pulse

 

__R30 |= VacValve; // turn vacuum on to hold fluid in place; ultimately 
this would read the pressure and attempt to hold it there

__delay_cycles(4000);  // put this delay cycle here for now.  will be 
replaced with a routine to analyze pulse & maintain slight vacuum later

__R30 &= ~VacValve;

__delay_cycles(4000);  // put this delay cycle here for now.  will be 
replaced with a routine to analyze pulse later

__R30 |= CAValve;

}

else__R30 &= ~PanelYellowLED; // turn yellow LED off

 

StepRead = RawAnalog;

RawAnalog = DetBSignalAverage;

break;

case 2:

Pressure  = RawAnalog;

if (pnr == E_RING_BUFFER_SIZE-1)

{

pnr = 0;

}

else

{

pnr++;

Re: [beagleboard] TI PRU_ADC_onChip example

[Walter Cromer]

Mark makes some excellent points.  I started developing C on the ARM side
under Linux before needing to start using PRUs.  I had not spent much time
in the TRM while working on the host side because I didn't need to.  It
really bit me until I did.  Once I really dug into the TRM and started to
understand the SOC at a hardware level, things began to progress much
better and faster.  And, going through the PRU Optimizing C/C++ Compiler
manual and PRU-ICSS/PRU_ICSSG Getting Started Guide on Linux helped too.
 What DID NOT HELP was that TI has not finished moving the wiki pages over
to a new resource but at least they made them available for download.

And, finally, this group of people have been awesome to help!


<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sat, May 8, 2021 at 7:52 PM 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Hello Cheng
>
> I learned a few things this weekend I thought I would share
>
> The PRU  Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows
> 10
>
> You can even debug both PRU0 and PRU1 at the same time examine memory and
> use HW  uart debug to speed up development
>
> The RPMSG example LAB  must be loaded by the linux or TI RTOS drivers
> running on ARM side
>
> I have win 7 and Windows 10 CCS/JTAG installations working one  a
> Beaglebone White and the other AM335X SK
> BBB is also supported
>
> My Last step is building the SDK  linux kernel from scratch  with rproc
> kernel modules loaded  from a VirtualBox Ubuntu VM on Win 7
>
> The Linux  SDK has binaries for the ARM side *so a  Native Linux BOX is
> NOT REQUIRED(but recommended )*
>
> *CCS DOES NOT require linux to load and debug PRU *
>
> For those that want to learn ARM TI RTOS Win 10 is required to build
>
> The SDK documents I saved as the wiki is disappearing are awesome I found
> some very detailed PRU documentation that talks about everything from
> running TI PRU firmware On PRU ICCS for complex Industrial protocols as
> well a custom PRU code
>
> The facts about clock cycles also were discussed. All of it in can be
> found by following the documentation tar ball I sent I you.
>
> I think too many people panic dont want to run SDK Linux or use CCS /JTAG
> dont read through all the documents as they dont want to go that route.
>
> Thats fine but the basic fundamentals of the whole SOC are then missed
> leading to confusion
>
> The SDK has done an excellent job of documenting this unfortunately unless
> your actually using the SDK all of this is hidden and I guess they are
> taking down some wikis so kind of sad this data will be lost.
>
> The approach in this group is wonderful especially for Linux App types
> that don't care about details
>  they just want a working kernel and actually making one script to build
> linux makes sense as supporting keystroke errors and inability to read docs
> in a chronological orderly way would be a nightmare.
>
> So in summary In my humble Opinion if your goal is writing Linux apps on a
> open source board the SDK probally is NOT for you.
>
> If your goal is barebones, TI  RTOS , board bring up, custom hardware ,
> DSP programming Cortex M4 programming , advanced PRU apps or learning or
> adding Linux Device drivers the SDK is a great asset.
>
> Mark
>
>
>
> On Thursday, May 6, 2021, 05:28:39 PM CDT, Cheng Chen 
> wrote:
>
>
> Hi Walter,
>
> Sorry for the late reply.
> The most important part I modified for TI's makefile is to make sure that
> the firmware is loaded into remoteproc1. I basically replaced the loading
> procedure in the shell script with Molly's version which I attached below.
> I also added the entire include file and modified some of the constants and
> variable names in the c code because compiler reports errors of
> unrecognized header file and variables. But except those, it runs pretty
> well.
>
> start:
> ifneq ($(PRU_DIR),)
> @echo write_init_pins.sh
> @$(COMMON)/write_init_pins.sh /lib/firmware/$(CHIP)-pru$(PRUN)-fw
> @echo "-Starting PRU $(PRUN)"
> @echo start > $(PRU_DIR)/state
> else ifeq ($(PROC),tidl)
> ti-mct-heap-check -c
> sudo mjpg_streamer -i "input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v
> vpe /sys/class/video4linux/video*/name | perl -ne '/\/(video\d+)\/name/ &&
> print $$1') \
> --filter ./$(TARGET)$(EXE)" -o "output_http.so -p 8090 -w
> /usr/share/mjpg-streamer/www"
> else
> ./$(TARGET)$(EXE)
> endif
>
>
>

[beagleboard] Re: Placing integer arrays in PRU Shared memory

[Walter Cromer]

Remoteproc is working fine in our application. I made a stupid mistake that 
was causing my problem.  It's fixed and working fine now.   I'm sure it 
won't be the last issue I have because I'm human and I make mistakes.   

My stupid mistake was that I had declared another variable in the same 
exact space at one point and had forgotten to remove that declaration.   It 
was causing a conflict.



On Thursday, May 6, 2021 at 3:14:40 AM UTC-4 TJF wrote:

> wal...@edenconceptsllc.com schrieb am Dienstag, 4. Mai 2021 um 18:16:53 
> UTC+2:
>
>> What am I doing wrong and/or what could I do differently?
>
>
> You could follow experienced councelors. A month ago I told you that 
> libpruio provides that ADC ring buffer. 
>

-- 
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/32265537-c184-4479-a3d2-8908945ad5f0n%40googlegroups.com.

Re: [beagleboard] Placing integer arrays in PRU Shared memory

[Walter Cromer]

Vinicius..

Thanks for looking from your phone!  

Are you saying that SHARE_MEM is incorrect?  I took that directly from 
Molloy's examples in Exploring BeagleBone.   

Maybe it looks incorrect on your phone?

Walter

On Tuesday, May 4, 2021 at 1:09:35 PM UTC-4 vinicius...@gmail.com wrote:

> Hi Walter,
>
> I’m on the cellphone and that is a little hard to read your code? But I 
> did find the offset of the pru memory , because you need allocate the 
> memory inside the pru memory address and you is allocating at the 1000 
> address 
>
> Sent from my iPhone
>
>
> Em 4 de mai. de 2021, à(s) 13:16, Walter Cromer <
> wal...@edenconceptsllc.com> escreveu:
>
> I'm on a BBB Wireless running
>
>
> Linux beaglebone 4.19.94-ti-r61 #1buster SMP PREEMPT Wed Mar 31 15:23:20 
> UTC 2021 armv7l GNU/Linux
>
> The version.sh output is at the end of this post.
>
> I need to put readings from two analog inputs into two arrays so I can do 
> some calculations on them.   Basically, when one of the inputs exceeds a 
> threshold, I'll do these calculations on the values in the arrays.  
> Essentially these will be two ring buffers.
> I don't have a lot of variables or a lot of code really but it doesn't 
> take much to overflow the default stack and heap or 8k of RAM local to each 
> PRU.  So, I'm thinking the solution is to force these two arrays into the 
> 12k shared RAM since I'm only using PRU0 in this application.  
>
> I've been trying to follow Molloy's example and Mark Yoder's PRUCookbook 
> example but when I compile the PRU code it freezes the whole system which I 
> suspect is because of a stack or heap overflow.  
>
> Here are the code snippets.  What am I doing wrong and/or what could I do 
> differently?
>
> #define SHARE_MEM  0x0001
>
> // declaring int arrays to go in PRU Shared memory space
>
> #define E_RING_BUFFER_SIZE 5  // each array will have 5 elements; 
> ultimately need 50 each
>
> volatile unsigned int *DetTSampleSet = (unsigned int *) SHARE_MEM;
> volatile unsigned int *DetBSampleSet = (unsigned int *) (SHARE_MEM + 
> (E_RING_BUFFER_SIZE * sizeof(unsigned int))); ;
> .
> .
> .
> .
> // putting data from analog sensor read into array element
> Data = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0));
> StepRead = (Data >> 16) & 0xF;
> RawAnalog = Data & 0xFFF;
> switch (StepRead)
> {
> case 0:
> DetTSample = RawAnalog;
> //DetTSampleSet[pnr]=RawAnalog;
> break;
> case 1:
> DetBSample = RawAnalog;
> DetBSampleSet[0]=RawAnalog;
> .
> .
> .
> .
>
>
> debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/version.sh
> git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
> eeprom:[A335BNLTBWA52027BBWG0227]
> model:[TI_AM335x_BeagleBone_Black_Wireless]
> dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-g07d5700e21]:[location: dd MBR]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2018.03-2-gac9cce7c6a]:[location: dd MBR]
> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
> UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
> UBOOT: Loaded Overlay:[BB-ADC-00A0]
> UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]
> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
> UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
> UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
> kernel:[4.19.94-ti-r61]
> nodejs:[v10.15.2]
> /boot/uEnv.txt Settings:
> debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/version.sh
> [sudo] password for debian:
> git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
> eeprom:[A335BNLTBWA52027BBWG0227]
> model:[TI_AM335x_BeagleBone_Black_Wireless]
> dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-g07d5700e21]:[location: dd MBR]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2018.03-2-gac9cce7c6a]:[location: dd MBR]
> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
> UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
> UBOOT: Loaded Overlay:[BB-ADC-00A0]
> UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]
> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
> UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
> UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
> kernel:[4.19.94-ti-r61]
> nodejs:[v10.15.2]
> /boot/uEnv.txt Settings:
> uboot_overlay_options:[enable_uboot_overlays=1]
>
> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]
> uboot_overlay_options:[disable_uboot_overlay_video=1]
> uboot_overlay_options:[disable_uboot_overlay_audio=1]
>
> uboot_overlay_options:[uboot_overlay_pru=/li

Re: [beagleboard] TI PRU_ADC_onChip example

[Walter Cromer]

I am glad to have helped a little bit.   Stick with it.  When it clicks and 
you start really moving forward I think you'll be pleased.

Can you share the changes to the Makefile that you made?  I'm curious if it 
might help me.

Right now I am reading the ADC every 2.7ms.  I'm reading three channels.  I 
include the step id too and check that.  I am using switch-case to check 
the step and put the analog input into the right variable in my code.   It 
might be slighter faster with an if-elseif but I like the neatness of the 
switch-case and until it causes me timing problems, I'm sticking with it.

I am also fairly certain the ADC can be read faster.  I have the ADC in 
one-shot mode and delay before I kick it off again.   I've also run this 
with no averaging, 4 averages, and 16 averages and it makes very little 
difference in timing for me.

Walter

On Tuesday, May 4, 2021 at 11:33:51 AM UTC-4 chen...@gmail.com wrote:

> Hi Walter, 
>
> Thank you so much for the reply. I think my setup is exactly the same as 
> what you have (win10 and BBB wireless). That really motivated me to see 
> somebody else successfully run the system with the same setup. 
> I actually made some preliminary progress after two nights brooding and I 
> am able to read out ADC data through rpmsg. Thanks a lot for your tips. 
>
> I think the problem is still in the makefile and environment. As you 
> mentioned, you are using makefile from PRUcookbook while I started off with 
> TI's built-in makefile.  I believe there is a couple of slight difference 
> between Debian system and TI SDK environment which turns out to be critical 
> in compiling. I carefully compared the difference between two makefiles and 
> created one which is close to the makefile in the PRUcookbook. That works 
> like a charm. 
>
> Next step I also want to explore precise timing and see how fast the adc 
> can run. May I ask what is the speed you are reading out from ADC? 
>
> Regards,
> Cheng
>
> 在2021年5月3日星期一 UTC-4 上午11:24:23 写道：
>
>> I just went through this pain and the people in this group were awesome 
>> help.
>>
>> I needed to read three analog inputs and it was a bear but once I got it, 
>> it has been going well.
>>
>> You don't mention the OS of your development platform or I may have 
>> missed it.  I'm on a Windows 10 box and using a BBB Wireless.  TI's entire 
>> learning system for this expects a Linux development platform so it's not 
>> as useful as it could be if you are on Windows.  I didn't want to go to the 
>> trouble of even bringing up a virtual Linux on my Windows box for this.  I 
>> did install Code Composer Studio (CCS) from TI, but gave up on it.  There's 
>> no easy way to transfer your compiled firmware to the BBB from within it 
>> according to TI.   So I just do everything on the Beagle and it meets my 
>> needs.
>>
>> I use the cloud9 IDE that ships with the BeagleBones for coding both the 
>> ARM and PRU code.  This environment compiles the ARM-side code and executes 
>> it just like any normal host (aka Linux, aka ARM) program just fine.  
>>  However, to compile the PRU code and load it I go over to a PUTTY session 
>> and use the make files from Mark Yoders' PRU Cookbook (
>> https://markayoder.github.io/PRUCookbook/) .  My process is clunky but 
>> my programs aren't huge or extremely complex (yet) and this works for me.  
>> I don't have and don't want to invest in a debug probe so debugging the PRU 
>> code can be a pain and slow.  The only option really is to use RPMsg almost 
>> like printf to send messages back at key points in the PRU code to let me 
>> know where it is executing and what's happening.  (Purists and more 
>> advanced developers are barfing and laughing at me right now I am sure.)  
>>
>> I strongly encourage you to get the Technical Reference Manual for the TI 
>> ARM335x and specifically spend time with the Touchscreen Controller 
>> chapter.  If you need precise timing, you'll want to spend time in the 
>> Industrial Ethernet Peripheral chapter too.   These are powerful tools once 
>> you understand them.
>>
>> Also, get the PRU Optimizing C/C++ Compiler manual from TI and go through 
>> it.  One thing that really tripped me up was their implementation of the 
>> __far keyword.   GCC doesn't recognize that and I didn't understand what 
>> was going on at first.  
>>
>> As Mark commented, some people encourage using remoteproc, some encourage 
>> using libpruio and some still use the uio. TI supports remoteproc and I 
>> expect them to be around so I went with remoteproc.  It may have its 
>> drawbacks but it is working just fine for me.  I can't comment on the other 
>> two as I have not tried them.   Also, I've found the TI E2E forum's 
>> moderators to be patient with me as a neophyte.   But the Google group's 
>> members do have wider experience.
>>
>> FYI - watch out for how TI puts some register settings that cross nibble 
>> or byte boundaries.  It can really bite you!  Take a look at the 

[beagleboard] Placing integer arrays in PRU Shared memory

[Walter Cromer]

I'm on a BBB Wireless running

Linux beaglebone 4.19.94-ti-r61 #1buster SMP PREEMPT Wed Mar 31 15:23:20 
UTC 2021 armv7l GNU/Linux

The version.sh output is at the end of this post.

I need to put readings from two analog inputs into two arrays so I can do 
some calculations on them.   Basically, when one of the inputs exceeds a 
threshold, I'll do these calculations on the values in the arrays.  
Essentially these will be two ring buffers.
I don't have a lot of variables or a lot of code really but it doesn't take 
much to overflow the default stack and heap or 8k of RAM local to each 
PRU.  So, I'm thinking the solution is to force these two arrays into the 
12k shared RAM since I'm only using PRU0 in this application.  

I've been trying to follow Molloy's example and Mark Yoder's PRUCookbook 
example but when I compile the PRU code it freezes the whole system which I 
suspect is because of a stack or heap overflow.  

Here are the code snippets.  What am I doing wrong and/or what could I do 
differently?

#define SHARE_MEM  0x0001

// declaring int arrays to go in PRU Shared memory space

#define E_RING_BUFFER_SIZE 5  // each array will have 5 elements; 
ultimately need 50 each

volatile unsigned int *DetTSampleSet = (unsigned int *) SHARE_MEM;
volatile unsigned int *DetBSampleSet = (unsigned int *) (SHARE_MEM + 
(E_RING_BUFFER_SIZE * sizeof(unsigned int))); ;
.
.
.
.
// putting data from analog sensor read into array element
Data = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0));
StepRead = (Data >> 16) & 0xF;
RawAnalog = Data & 0xFFF;
switch (StepRead)
{
case 0:
DetTSample = RawAnalog;
//DetTSampleSet[pnr]=RawAnalog;
break;
case 1:
DetBSample = RawAnalog;
DetBSampleSet[0]=RawAnalog;
.
.
.
.


debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/version.sh
git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
eeprom:[A335BNLTBWA52027BBWG0227]
model:[TI_AM335x_BeagleBone_Black_Wireless]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2019.04-2-g07d5700e21]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.03-2-gac9cce7c6a]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
kernel:[4.19.94-ti-r61]
nodejs:[v10.15.2]
/boot/uEnv.txt Settings:
debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/version.sh
[sudo] password for debian:
git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
eeprom:[A335BNLTBWA52027BBWG0227]
model:[TI_AM335x_BeagleBone_Black_Wireless]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2019.04-2-g07d5700e21]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.03-2-gac9cce7c6a]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
kernel:[4.19.94-ti-r61]
nodejs:[v10.15.2]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]
pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc 
admin spi iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[   69.919456] remoteproc remoteproc0: wkup_m3 is available
[   70.232036] remoteproc remoteproc0: powering up wkup_m3
[   70.232072] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217148
[   70.232362] remoteproc remoteproc0: remote processor wkup_m3 

Re: [beagleboard] Re: wl18xx warning - any resolution?

[Walter Cromer]

I'm getting this same message on a BBB Wireless now and I agree its 
annoying.  Any suggestions to get this fixed would be greatly appreciated.

I've recently upgraded and here's the output of version.sh

debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/version.sh
git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
eeprom:[A335BNLTBWA52027BBWG0227]
model:[TI_AM335x_BeagleBone_Black_Wireless]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2019.04-2-g07d5700e21]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.03-2-gac9cce7c6a]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
kernel:[4.19.94-ti-r61]
nodejs:[v10.15.2]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]
pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc 
admin spi iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[   70.651413] remoteproc remoteproc0: wkup_m3 is available
[   70.697391] remoteproc remoteproc0: powering up wkup_m3
[   70.697422] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217148
[   70.697706] remoteproc remoteproc0: remote processor wkup_m3 is now up
[   72.927878] remoteproc remoteproc1: 4a334000.pru is available
[   72.940691] remoteproc remoteproc2: 4a338000.pru is available
dmesg | grep pru
[   72.927878] remoteproc remoteproc1: 4a334000.pru is available
[   72.928077] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed 
successfully
[   72.940691] remoteproc remoteproc2: 4a338000.pru is available
[   72.940850] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed 
successfully
dmesg | grep pinctrl-single
[0.951037] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[0.964485] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

On Thursday, January 14, 2021 at 12:56:54 PM UTC-5 Ren W wrote:

> Alfred:
> Were you able to resolve this issue? It seems harmless, but the message is 
> annoying.
>
> This means that the peer is trying to start BA sessions more than what the 
> device can support and we are rejecting it. I think you can ignore the 
> warning or downgrade it to DEBUG (per TI E2E support forums 
> 
> .)
>
> [   60.933343] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
> [   61.555139] wlcore: PHY firmware version: Rev 8.2.0.0.242
> [   61.608600] wlcore: firmware booted (Rev 8.9.0.0.79)
>
> Linux beaglebone 4.19.94-ti-r57 #1buster SMP PREEMPT Thu Nov 19 23:44:09 
> UTC 2020 armv7l GNU/Linux
>
>
> On Mon, Dec 14, 2020 at 7:31 AM jose...@gmail.com  
> wrote:
>
>> I would go a setp further from Robert's sugestion and manually upgrade 
>> the firmware file, using the one at:
>>
>> https://git.ti.com/cgit/wilink8-wlan/wl18xx_fw/tree/
>>
>> That FW should be retro-compatible with older drivers...
>>
>> A segunda-feira, 14 de dezembro de 2020 à(s) 15:10:36 UTC, RobertCNelson 
>> escreveu:
>>
>>> On Mon, Dec 14, 2020 at 9:03 AM ags  wrote: 
>>> > 
>>> > Does that mean that everyone running 4.14.x had these problems? I 
>>> didn't find an outpouring of posts about this problem (although possibly 
>>> simply a benign log entry) so thought it was a rarer problem that few 
>>> others had. 
>>> > 
>>> > Is it reasonable to update just the radio firmware(s), or would that 
>>> pose a risk (greater than the upgrade)? 
>>>
>>> pkg check: to individually upgrade run: [sudo apt 

Re: [beagleboard] TI PRU_ADC_onChip example

[Walter Cromer]

I haven't posted the question about this code to the E2E forum as I think 
it must have something to do with permissions.

I don't know if they support Cloud9 on E2E.  I haven't asked any questions 
specific to Cloud9.

And, I don't do any kernel development.  It's above me right now.  I'm 
grateful for all those who do work in this space!
But I write all my code directly on the BBB using cloud9.  I guess until 
recently I didn't look for any other way to do it. 

Walter

On Monday, May 3, 2021 at 8:29:03 PM UTC-4 lazarman wrote:

> Walter
>
> This below code you posted in another thread was what I was referring to. 
> Does the E2E forum support cloud 9 dev on BBB??? 
>
>
> I'm also curious how you actually build/modify your Linux kernel with no 
> Linux box.
>
> Walter Cromer
>  wrote:
> changed the code to this and get the same error.
>
> fd = open ("/dev/mem", O_RDONLY | O_SYNC);   // not sure O_SYNC is 
> necessary since this is a read-only open situation
>
> Servo tester!!!
> ERROR: could not open /dev/mem.
>
> make: *** [/var/lib/cloud9/common/Makefile:173: start] Error 1
> rm /tmp/cloud9-examples/pwm-test.o
>
>
>
>
> Show more
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Mon, May 3, 2021 at 3:02 PM, Walter Cromer
>  wrote:
>
> I'm using Debian and Cloud9 running on the Beagle.  The Windows 10 box is 
> really just providing a browser 'terminal' to the Beagle.
>
> What compiler errors?  Do you mean __far?   I don't think I asked about 
> that on E2E.  I just realized my mistake and did some reading to understand 
> it.  It's not an issue anymore.
>
>
> On Monday, May 3, 2021 at 3:44:10 PM UTC-4 lazarman wrote:
>
> Walter
>
> Yes I remember everything about your application including the Debian  ARM 
> Linux application delays nobody seemed to have answers on fixing.
>
> Your running windows 10 not using the SDK using cloud 9 and Debian  as I 
> understand. What is E2E saying about your compiler errors your asking about 
> in this group???
>
> Mark
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Mon, May 3, 2021 at 2:35 PM, Walter Cromer
>  wrote:
>
> It was disappointing, to say the least that they said there wasn't an easy 
> way to transfer the firmware but I believe that's what they meant.   
>
> I had my application running on the ARM side just fine but we just 
> couldn't get the deterministic timing we require for our application.  
> That's why I went to the PRUs.We're getting awesome results on the 
> timing now and RPMsg is fast enough on the transfer to get us the data for 
> analysis that we need.  Right now my problem is that I need to put 10 to 15 
> samples in an array and do some basic slope and standard deviation 
> calculations on the values in the array but when I add that, I'm getting 
> that my program won't fit into memory.  I'm working now to learn how to 
> initialize all my variables in the shared memory space.  That's locking up 
> the BBB every time right now.   I'm following Molloy's book but it's not 
> getting me there so far. 
>
>
> On Monday, May 3, 2021 at 1:53:50 PM UTC-4 lazarman wrote:
>
> #  I did install Code Composer Studio (CCS) from #TI, but gave up on it.  
> There's no easy way to #transfer your compiled firmware to the BBB from 
> #within it according to TI.   
>
> Hi Walter
>
> This doesn't look correct or sound like TI.
> JTAG loads code extremely fast especially on the ARM. If you're referring 
> to PRU code I've also done that as well.
>
> Your overall  approach is fine imo just slow and a work in progress and 
> yes they are helpful in E2E .
>
> CCS/ JTAG is for barebones/ RTOS ARM it will speed up PRU development.
>
>  unfortunately again in  my opinion a complex control loop would run on a 
> DSP this PRU is too resource limited.
>
> It's purpose is offloading 
>
> Glad to see your making progress 
>
> I don't know if you saw a comment I completed your project all on the ARM 
> side barebones very quickly unfortunately I don't recommend this for a 
> beginner. To attempt this  you really need a low level understanding of ARM 
> so your current approach is probably your best choice
>
>
>
>
>
>
>
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Int

Re: [beagleboard] TI PRU_ADC_onChip example

[Walter Cromer]

I'm using Debian and Cloud9 running on the Beagle.  The Windows 10 box is 
really just providing a browser 'terminal' to the Beagle.

What compiler errors?  Do you mean __far?   I don't think I asked about 
that on E2E.  I just realized my mistake and did some reading to understand 
it.  It's not an issue anymore.


On Monday, May 3, 2021 at 3:44:10 PM UTC-4 lazarman wrote:

> Walter
>
> Yes I remember everything about your application including the Debian  ARM 
> Linux application delays nobody seemed to have answers on fixing.
>
> Your running windows 10 not using the SDK using cloud 9 and Debian  as I 
> understand. What is E2E saying about your compiler errors your asking about 
> in this group???
>
> Mark
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Mon, May 3, 2021 at 2:35 PM, Walter Cromer
>  wrote:
>
> It was disappointing, to say the least that they said there wasn't an easy 
> way to transfer the firmware but I believe that's what they meant.   
>
> I had my application running on the ARM side just fine but we just 
> couldn't get the deterministic timing we require for our application.  
> That's why I went to the PRUs.We're getting awesome results on the 
> timing now and RPMsg is fast enough on the transfer to get us the data for 
> analysis that we need.  Right now my problem is that I need to put 10 to 15 
> samples in an array and do some basic slope and standard deviation 
> calculations on the values in the array but when I add that, I'm getting 
> that my program won't fit into memory.  I'm working now to learn how to 
> initialize all my variables in the shared memory space.  That's locking up 
> the BBB every time right now.   I'm following Molloy's book but it's not 
> getting me there so far. 
>
>
> On Monday, May 3, 2021 at 1:53:50 PM UTC-4 lazarman wrote:
>
> #  I did install Code Composer Studio (CCS) from #TI, but gave up on it.  
> There's no easy way to #transfer your compiled firmware to the BBB from 
> #within it according to TI.   
>
> Hi Walter
>
> This doesn't look correct or sound like TI.
> JTAG loads code extremely fast especially on the ARM. If you're referring 
> to PRU code I've also done that as well.
>
> Your overall  approach is fine imo just slow and a work in progress and 
> yes they are helpful in E2E .
>
> CCS/ JTAG is for barebones/ RTOS ARM it will speed up PRU development.
>
>  unfortunately again in  my opinion a complex control loop would run on a 
> DSP this PRU is too resource limited.
>
> It's purpose is offloading 
>
> Glad to see your making progress 
>
> I don't know if you saw a comment I completed your project all on the ARM 
> side barebones very quickly unfortunately I don't recommend this for a 
> beginner. To attempt this  you really need a low level understanding of ARM 
> so your current approach is probably your best choice
>
>
>
>
>
>
>
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Mon, May 3, 2021 at 10:24 AM, Walter Cromer
>  wrote:
>
> I just went through this pain and the people in this group were awesome 
> help.
>
> I needed to read three analog inputs and it was a bear but once I got it, 
> it has been going well.
>
> You don't mention the OS of your development platform or I may have missed 
> it.  I'm on a Windows 10 box and using a BBB Wireless.  TI's entire 
> learning system for this expects a Linux development platform so it's not 
> as useful as it could be if you are on Windows.  I didn't want to go to the 
> trouble of even bringing up a virtual Linux on my Windows box for this.  I 
> did install Code Composer Studio (CCS) from TI, but gave up on it.  There's 
> no easy way to transfer your compiled firmware to the BBB from within it 
> according to TI.   So I just do everything on the Beagle and it meets my 
> needs.
>
> I use the cloud9 IDE that ships with the BeagleBones for coding both the 
> ARM and PRU code.  This environment compiles the ARM-side code and executes 
> it just like any normal host (aka Linux, aka ARM) program just fine.  
>  However, to compile the PRU code and load it I go over to a PUTTY session 
> and use the make files from Mark Yoders' PRU Cookbook (
> https://markayoder.github.io/PRUCookbook/) .  My process is clunky but my 
> programs aren't huge or extremely complex (yet) and this works for me.  I 
> don't have and don't want to invest in a debug probe s

Re: [beagleboard] TI PRU_ADC_onChip example

[Walter Cromer]

It was disappointing, to say the least that they said there wasn't an easy 
way to transfer the firmware but I believe that's what they meant.   

I had my application running on the ARM side just fine but we just couldn't 
get the deterministic timing we require for our application.  That's why I 
went to the PRUs.We're getting awesome results on the timing now and 
RPMsg is fast enough on the transfer to get us the data for analysis that 
we need.  Right now my problem is that I need to put 10 to 15 samples in an 
array and do some basic slope and standard deviation calculations on the 
values in the array but when I add that, I'm getting that my program won't 
fit into memory.  I'm working now to learn how to initialize all my 
variables in the shared memory space.  That's locking up the BBB every time 
right now.   I'm following Molloy's book but it's not getting me there so 
far. 


On Monday, May 3, 2021 at 1:53:50 PM UTC-4 lazarman wrote:

> #  I did install Code Composer Studio (CCS) from #TI, but gave up on it.  
> There's no easy way to #transfer your compiled firmware to the BBB from 
> #within it according to TI.   
>
> Hi Walter
>
> This doesn't look correct or sound like TI.
> JTAG loads code extremely fast especially on the ARM. If you're referring 
> to PRU code I've also done that as well.
>
> Your overall  approach is fine imo just slow and a work in progress and 
> yes they are helpful in E2E .
>
> CCS/ JTAG is for barebones/ RTOS ARM it will speed up PRU development.
>
>  unfortunately again in  my opinion a complex control loop would run on a 
> DSP this PRU is too resource limited.
>
> It's purpose is offloading 
>
> Glad to see your making progress 
>
> I don't know if you saw a comment I completed your project all on the ARM 
> side barebones very quickly unfortunately I don't recommend this for a 
> beginner. To attempt this  you really need a low level understanding of ARM 
> so your current approach is probably your best choice
>
>
>
>
>
>
>
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Mon, May 3, 2021 at 10:24 AM, Walter Cromer
>  wrote:
>
> I just went through this pain and the people in this group were awesome 
> help.
>
> I needed to read three analog inputs and it was a bear but once I got it, 
> it has been going well.
>
> You don't mention the OS of your development platform or I may have missed 
> it.  I'm on a Windows 10 box and using a BBB Wireless.  TI's entire 
> learning system for this expects a Linux development platform so it's not 
> as useful as it could be if you are on Windows.  I didn't want to go to the 
> trouble of even bringing up a virtual Linux on my Windows box for this.  I 
> did install Code Composer Studio (CCS) from TI, but gave up on it.  There's 
> no easy way to transfer your compiled firmware to the BBB from within it 
> according to TI.   So I just do everything on the Beagle and it meets my 
> needs.
>
> I use the cloud9 IDE that ships with the BeagleBones for coding both the 
> ARM and PRU code.  This environment compiles the ARM-side code and executes 
> it just like any normal host (aka Linux, aka ARM) program just fine.  
>  However, to compile the PRU code and load it I go over to a PUTTY session 
> and use the make files from Mark Yoders' PRU Cookbook (
> https://markayoder.github.io/PRUCookbook/) .  My process is clunky but my 
> programs aren't huge or extremely complex (yet) and this works for me.  I 
> don't have and don't want to invest in a debug probe so debugging the PRU 
> code can be a pain and slow.  The only option really is to use RPMsg almost 
> like printf to send messages back at key points in the PRU code to let me 
> know where it is executing and what's happening.  (Purists and more 
> advanced developers are barfing and laughing at me right now I am sure.)  
>
> I strongly encourage you to get the Technical Reference Manual for the TI 
> ARM335x and specifically spend time with the Touchscreen Controller 
> chapter.  If you need precise timing, you'll want to spend time in the 
> Industrial Ethernet Peripheral chapter too.   These are powerful tools once 
> you understand them.
>
> Also, get the PRU Optimizing C/C++ Compiler manual from TI and go through 
> it.  One thing that really tripped me up was their implementation of the 
> __far keyword.   GCC doesn't recognize that and I didn't understand what 
> was going on at first.  
>
> As Mark commented, some people encourage using remoteproc, some encourage 
> using libpruio and some still use the uio. TI supports remoteproc and I 
> expect the

[beagleboard] Re: Beaglebone Black [BBB] Read Shared memory from PRU

[Walter Cromer]

I changed the code to this and get the same error.

fd = open ("/dev/mem", O_RDONLY | O_SYNC);   // not sure O_SYNC is 
necessary since this is a read-only open situation

Servo tester!!!
ERROR: could not open /dev/mem.

make: *** [/var/lib/cloud9/common/Makefile:173: start] Error 1
rm /tmp/cloud9-examples/pwm-test.o


Here's some info about my specific owner/group & permissions.

debian@beaglebone:/var/lib/cloud9$ ls -ls /dev/mem
0 crw-r- 1 root kmem 1, 1 Apr 30 20:30 /dev/mem
debian@beaglebone:/var/lib/cloud9$ groups
debian adm kmem dialout cdrom floppy audio dip video plugdev users 
systemd-journal bluetooth netdev i2c cloud9ide xenomai weston-launch tisdk 
docker iio spi admin remoteproc eqep pwm gpio
debian@beaglebone:/var/lib/cloud9$ whoami
debian
debian@beaglebone:/var/lib/cloud9$

On Friday, April 30, 2021 at 12:23:43 PM UTC-4 Dennis Bieber wrote:

> On Fri, 30 Apr 2021 08:22:10 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  wrote:
>
>
> >I checked with ls -ls /dev/mem logged in as debian and it's there.
> >
> debian@beaglebone:~$ ls -ls /dev/mem
> 0 crw-r- 1 root kmem 1, 1 Apr 30 12:06 /dev/mem
> debian@beaglebone:~$
> debian@beaglebone:~$ groups
> debian adm kmem dialout cdrom floppy audio dip video plugdev users
> systemd-journal input bluetooth netdev i2c remoteproc eqep pwm cloud9ide
> xenomai weston-launch tisdk docker iio spi admin gpio
> debian@beaglebone:~$
>
>
> That is what my BBB shows.
>
> Owner (root) has R/W permission
> Group (kmem) has Read-Only permission.
>
> The debian account has kmem group access.
>
> From your earlier post...
>
> > fd = open ("/dev/mem", O_RDWR | O_SYNC);
>
> ... you are asking for R/W access -- which is not set for members of the
> kmem group. What happens if you attempt to open /dev/mem for read-only
> access?
>
>
> -- 
> 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/9f6f9ffc-22ec-4958-b781-c140b329d30en%40googlegroups.com.

Re: [beagleboard] TI PRU_ADC_onChip example

[Walter Cromer]

I just went through this pain and the people in this group were awesome 
help.

I needed to read three analog inputs and it was a bear but once I got it, 
it has been going well.

You don't mention the OS of your development platform or I may have missed 
it.  I'm on a Windows 10 box and using a BBB Wireless.  TI's entire 
learning system for this expects a Linux development platform so it's not 
as useful as it could be if you are on Windows.  I didn't want to go to the 
trouble of even bringing up a virtual Linux on my Windows box for this.  I 
did install Code Composer Studio (CCS) from TI, but gave up on it.  There's 
no easy way to transfer your compiled firmware to the BBB from within it 
according to TI.   So I just do everything on the Beagle and it meets my 
needs.

I use the cloud9 IDE that ships with the BeagleBones for coding both the 
ARM and PRU code.  This environment compiles the ARM-side code and executes 
it just like any normal host (aka Linux, aka ARM) program just fine.  
 However, to compile the PRU code and load it I go over to a PUTTY session 
and use the make files from Mark Yoders' PRU Cookbook 
(https://markayoder.github.io/PRUCookbook/) .  My process is clunky but my 
programs aren't huge or extremely complex (yet) and this works for me.  I 
don't have and don't want to invest in a debug probe so debugging the PRU 
code can be a pain and slow.  The only option really is to use RPMsg almost 
like printf to send messages back at key points in the PRU code to let me 
know where it is executing and what's happening.  (Purists and more 
advanced developers are barfing and laughing at me right now I am sure.)  

I strongly encourage you to get the Technical Reference Manual for the TI 
ARM335x and specifically spend time with the Touchscreen Controller 
chapter.  If you need precise timing, you'll want to spend time in the 
Industrial Ethernet Peripheral chapter too.   These are powerful tools once 
you understand them.

Also, get the PRU Optimizing C/C++ Compiler manual from TI and go through 
it.  One thing that really tripped me up was their implementation of the 
__far keyword.   GCC doesn't recognize that and I didn't understand what 
was going on at first.  

As Mark commented, some people encourage using remoteproc, some encourage 
using libpruio and some still use the uio. TI supports remoteproc and I 
expect them to be around so I went with remoteproc.  It may have its 
drawbacks but it is working just fine for me.  I can't comment on the other 
two as I have not tried them.   Also, I've found the TI E2E forum's 
moderators to be patient with me as a neophyte.   But the Google group's 
members do have wider experience.
   
FYI - watch out for how TI puts some register settings that cross nibble or 
byte boundaries.  It can really bite you!  Take a look at the STEPCONFIGn 
registers implementation of averaging to see what I mean.

I hope this helps!

On Saturday, May 1, 2021 at 12:46:03 PM UTC-4 lazarman wrote:

> << , but it requires a company email to do so. 
>
> Hello Cheng 
>
> I want to Help you  but it appears my message is lost in translation
>
> What it sounds like to me  is TI pays these engineers $$ to answer 
> questions and does not want to waste time and $$$ with users that dont 
> follow their well written instructions *which say use SDK Yocto Linux on 
> the ARM for this example.*
>
> For me I start with a working example with instructions and documentation 
> then modifyit
>
> If I undertsand correctly you have *never* had an example working
>
> If you like breaking examples and working on projects that ONLY works from 
> a unix script and hides all the details then this is the correct group to 
> to ask questions (-:
>
> I suggest you try the example *you found*  following the intructions 
> exactly.  if you cant or wont do that switch to DEbian/Cookbook
>
> But if you do the latter I suggest don't change things follow the 
> instructions
>
> What is interesting is a Linux C application program should work correctly 
> if it was coded generic especially when both Linux variants are for the 
> same chip. Trying to figure out what is different between Linux variants to 
> me is not productive its not my focus for you maybe it is.
>
> Perhaps the Linux in the SDK was configured differently which implies it 
> handle PRU slightly different Im not surprised by this.
>
> Perhaps you can find what's different that may be a valid approach that 
> works for you and maybe someone can help. I think Dennis gave you a good 
> clue.
>
> I will watch the thread hopefully I can be of help should you choose to 
> follow the path E2E and the SDK layed out for you
>
> Cheers
>
> On Friday, April 30, 2021, 07:52:09 PM CDT, Cheng Chen  
> wrote: 
>
>
> Hey Mark, 
>
> Thanks for spending time for replying. I really appreciate it. 
> I totally agree with you that one should spend time investigating first. I 
> apologize if they are dumb questions, but I have 

[beagleboard] Re: Beaglebone Black [BBB] Read Shared memory from PRU

[Walter Cromer]

Mark ,

pwm4.pru0.c compiles fine from a command line in PUTTY using make 
TARGET=pwm4.pru0

When I try to run pwm_test.c within the cloud9 IDE I get this message from 
the program.  

Compiling /var/lib/cloud9/PRUCookbook/docs/05blocks/code/pwm-test.c ...
/var/lib/cloud9/common/Makefile:28: 
MODEL=TI_AM335x_BeagleBone_Black_Wireless,TARGET=,COMMON=/var/lib/cloud9/common
make: 'pwm-test' is up to date.
Servo tester
ERROR: could not open /dev/mem.

I checked with ls -ls /dev/mem logged in as debian and it's there.

Any ideas?




On Friday, April 30, 2021 at 10:06:42 AM UTC-4 Walter Cromer wrote:

> Well, yes indeed, it is there this morning.  I'll retry the code later and 
> get back to you.
>
>
> On Thursday, April 29, 2021 at 4:04:42 PM UTC-4 Mark A. Yoder wrote:
>
>> Are you sure /dev/mem isn't there?  I think it's required.
>>
>> bone$ *ls -ls /dev/mem*
>> 0 crw-r- 1 root kmem 1, 1 Apr 14 09:11 /dev/mem
>> bone$ *groups*
>> debian adm *kmem* dialout cdrom floppy audio dip video plugdev users 
>> systemd-journal input bluetooth netdev i2c remoteproc eqep pwm cloud9ide 
>> xenomai weston-launch tisdk docker iio spi admin gpio
>>
>> You should be in the kmem group by default so sudo isn't needed.
>>
>> --Mark
>>
>> On Thursday, April 29, 2021 at 3:17:16 PM UTC-4 
>> wal...@edenconceptsllc.com wrote:
>>
>>> Here's the code too.   Sorry, should have included it.
>>>
>>> int fd;
>>> printf("Setting up pru0 memory access.\n");
>>>
>>> fd = open ("/dev/mem", O_RDWR | O_SYNC);
>>> if (fd == -1) {
>>> printf ("ERROR: could not open /dev/mem.\n\n");
>>> return 1;
>>> }
>>>
>>>
>>> When I look for /dev/mem it doesn't exist whether logged in as debian or 
>>> root
>>>
>>>
>>>
>>> On Thursday, April 29, 2021 at 3:15:10 PM UTC-4 Walter Cromer wrote:
>>>
>>>> Mark - I'm integrating the concepts from the PRUCookbook so I can send 
>>>> some control parameters entered by the user in the host side program and 
>>>> pass them over to the PRU0 firmware.
>>>>
>>>> I'm getting this error when I try to compile the code.
>>>>
>>>> Setting up pru0 memory access.
>>>> ERROR: could not open /dev/mem.
>>>>
>>>> Any ideas?
>>>>
>>>> I'm running a BBB Wireless with video and audio disabled.
>>>>
>>>> Here's the output of version.sh
>>>>
>>>> debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/version.sh
>>>> [sudo] password for debian:
>>>> git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
>>>> eeprom:[A335BNLTBWA52027BBWG0227]
>>>> model:[TI_AM335x_BeagleBone_Black_Wireless]
>>>> dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
>>>> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>>>> 2019.04-2-g07d5700e21]:[location: dd MBR]
>>>> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
>>>> 2018.03-2-gac9cce7c6a]:[location: dd MBR]
>>>> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
>>>> UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
>>>> UBOOT: Loaded Overlay:[BB-ADC-00A0]
>>>> UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]
>>>> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
>>>> UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
>>>> UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
>>>> kernel:[4.19.94-ti-r61]
>>>> nodejs:[v10.15.2]
>>>> /boot/uEnv.txt Settings:
>>>> uboot_overlay_options:[enable_uboot_overlays=1]
>>>>
>>>> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]
>>>> uboot_overlay_options:[disable_uboot_overlay_video=1]
>>>> uboot_overlay_options:[disable_uboot_overlay_audio=1]
>>>>
>>>> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
>>>> uboot_overlay_options:[enable_uboot_cape_universal=1]
>>>>
>>>> uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
>>>> pkg check: to individually upgrade run: [sudo apt install 
>>>> --only-upgrade ]
>>>> pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]
>>>> pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
>>>> pkg:[kmod]:[26-1]
>>>> pkg:[librobotcontrol]:[1.0.4-git201902

[beagleboard] Re: Beaglebone Black [BBB] Read Shared memory from PRU

[Walter Cromer]

Well, yes indeed, it is there this morning.  I'll retry the code later and 
get back to you.


On Thursday, April 29, 2021 at 4:04:42 PM UTC-4 Mark A. Yoder wrote:

> Are you sure /dev/mem isn't there?  I think it's required.
>
> bone$ *ls -ls /dev/mem*
> 0 crw-r- 1 root kmem 1, 1 Apr 14 09:11 /dev/mem
> bone$ *groups*
> debian adm *kmem* dialout cdrom floppy audio dip video plugdev users 
> systemd-journal input bluetooth netdev i2c remoteproc eqep pwm cloud9ide 
> xenomai weston-launch tisdk docker iio spi admin gpio
>
> You should be in the kmem group by default so sudo isn't needed.
>
> --Mark
>
> On Thursday, April 29, 2021 at 3:17:16 PM UTC-4 wal...@edenconceptsllc.com 
> wrote:
>
>> Here's the code too.   Sorry, should have included it.
>>
>> int fd;
>> printf("Setting up pru0 memory access.\n");
>>
>> fd = open ("/dev/mem", O_RDWR | O_SYNC);
>> if (fd == -1) {
>> printf ("ERROR: could not open /dev/mem.\n\n");
>> return 1;
>> }
>>
>>
>> When I look for /dev/mem it doesn't exist whether logged in as debian or 
>> root
>>
>>
>>
>> On Thursday, April 29, 2021 at 3:15:10 PM UTC-4 Walter Cromer wrote:
>>
>>> Mark - I'm integrating the concepts from the PRUCookbook so I can send 
>>> some control parameters entered by the user in the host side program and 
>>> pass them over to the PRU0 firmware.
>>>
>>> I'm getting this error when I try to compile the code.
>>>
>>> Setting up pru0 memory access.
>>> ERROR: could not open /dev/mem.
>>>
>>> Any ideas?
>>>
>>> I'm running a BBB Wireless with video and audio disabled.
>>>
>>> Here's the output of version.sh
>>>
>>> debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/version.sh
>>> [sudo] password for debian:
>>> git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
>>> eeprom:[A335BNLTBWA52027BBWG0227]
>>> model:[TI_AM335x_BeagleBone_Black_Wireless]
>>> dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
>>> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>>> 2019.04-2-g07d5700e21]:[location: dd MBR]
>>> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
>>> 2018.03-2-gac9cce7c6a]:[location: dd MBR]
>>> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
>>> UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
>>> UBOOT: Loaded Overlay:[BB-ADC-00A0]
>>> UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]
>>> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
>>> UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
>>> UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
>>> kernel:[4.19.94-ti-r61]
>>> nodejs:[v10.15.2]
>>> /boot/uEnv.txt Settings:
>>> uboot_overlay_options:[enable_uboot_overlays=1]
>>>
>>> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]
>>> uboot_overlay_options:[disable_uboot_overlay_video=1]
>>> uboot_overlay_options:[disable_uboot_overlay_audio=1]
>>>
>>> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
>>> uboot_overlay_options:[enable_uboot_cape_universal=1]
>>> uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
>>> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
>>> ]
>>> pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]
>>> pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
>>> pkg:[kmod]:[26-1]
>>> pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
>>> pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
>>> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
>>> plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc 
>>> admin spi iio docker tisdk weston-launch xenomai cloud9ide]
>>> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
>>> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
>>> net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
>>> dmesg | grep remote
>>> [   69.927418] remoteproc remoteproc0: wkup_m3 is available
>>> [   70.105672] remoteproc remoteproc0: powering up wkup_m3
>>> [   70.105706] remoteproc remoteproc0: Booting fw image 
>>> am335x-pm-firmware.elf, size 217148
>>> [   70.106000] remoteproc remoteproc0: remote processor wkup_m3 is now up
>>> [ 

[beagleboard] Re: Beaglebone Black [BBB] Read Shared memory from PRU

[Walter Cromer]

Here's the code too.   Sorry, should have included it.

int fd;
printf("Setting up pru0 memory access.\n");

fd = open ("/dev/mem", O_RDWR | O_SYNC);
if (fd == -1) {
printf ("ERROR: could not open /dev/mem.\n\n");
return 1;
}


When I look for /dev/mem it doesn't exist whether logged in as debian or 
root



On Thursday, April 29, 2021 at 3:15:10 PM UTC-4 Walter Cromer wrote:

> Mark - I'm integrating the concepts from the PRUCookbook so I can send 
> some control parameters entered by the user in the host side program and 
> pass them over to the PRU0 firmware.
>
> I'm getting this error when I try to compile the code.
>
> Setting up pru0 memory access.
> ERROR: could not open /dev/mem.
>
> Any ideas?
>
> I'm running a BBB Wireless with video and audio disabled.
>
> Here's the output of version.sh
>
> debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/version.sh
> [sudo] password for debian:
> git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
> eeprom:[A335BNLTBWA52027BBWG0227]
> model:[TI_AM335x_BeagleBone_Black_Wireless]
> dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-g07d5700e21]:[location: dd MBR]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2018.03-2-gac9cce7c6a]:[location: dd MBR]
> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
> UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
> UBOOT: Loaded Overlay:[BB-ADC-00A0]
> UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]
> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
> UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
> UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
> kernel:[4.19.94-ti-r61]
> nodejs:[v10.15.2]
> /boot/uEnv.txt Settings:
> uboot_overlay_options:[enable_uboot_overlays=1]
>
> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]
> uboot_overlay_options:[disable_uboot_overlay_video=1]
> uboot_overlay_options:[disable_uboot_overlay_audio=1]
>
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ]
> pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]
> pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
> pkg:[kmod]:[26-1]
> pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
> pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc 
> admin spi iio docker tisdk weston-launch xenomai cloud9ide]
> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
> dmesg | grep remote
> [   69.927418] remoteproc remoteproc0: wkup_m3 is available
> [   70.105672] remoteproc remoteproc0: powering up wkup_m3
> [   70.105706] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217148
> [   70.106000] remoteproc remoteproc0: remote processor wkup_m3 is now up
> [   72.319951] remoteproc remoteproc1: 4a334000.pru is available
> [   72.335870] remoteproc remoteproc2: 4a338000.pru is available
> [  564.302719] remoteproc remoteproc1: powering up 4a334000.pru
> [  564.303391] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
> size 118908
> [  564.316303] remoteproc remoteproc1: registered virtio0 (type 7)
> [  564.316324] remoteproc remoteproc1: remote processor 4a334000.pru is 
> now up
> [  590.322924] remoteproc remoteproc1: stopped remote processor 
> 4a334000.pru
> [  594.762821] remoteproc remoteproc1: powering up 4a334000.pru
> [  594.763533] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
> size 11
> [  594.777049] remoteproc remoteproc1: registered virtio0 (type 7)
> [  594.777060] remoteproc remoteproc1: remote processor 4a334000.pru is 
> now up
> dmesg | grep pru
> [   72.319951] remoteproc remoteproc1: 4a334000.pru is available
> [   72.320135] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed 
> successfully
> [   72.335870] remoteproc remoteproc2: 4a338000.pru is available
> [   72.336020] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed 
> successfully
> [  564.302719] remoteproc remoteproc1: powering up 4a334000.pru
> [  564.303391] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
> size 118908
> [  564.304236] prus

[beagleboard] Re: Beaglebone Black [BBB] Read Shared memory from PRU

[Walter Cromer]

Mark - I'm integrating the concepts from the PRUCookbook so I can send some 
control parameters entered by the user in the host side program and pass 
them over to the PRU0 firmware.

I'm getting this error when I try to compile the code.

Setting up pru0 memory access.
ERROR: could not open /dev/mem.

Any ideas?

I'm running a BBB Wireless with video and audio disabled.

Here's the output of version.sh

debian@beaglebone:/var/lib/cloud9$ sudo /opt/scripts/tools/version.sh
[sudo] password for debian:
git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
eeprom:[A335BNLTBWA52027BBWG0227]
model:[TI_AM335x_BeagleBone_Black_Wireless]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2019.04-2-g07d5700e21]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.03-2-gac9cce7c6a]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
kernel:[4.19.94-ti-r61]
nodejs:[v10.15.2]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]
pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc 
admin spi iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[   69.927418] remoteproc remoteproc0: wkup_m3 is available
[   70.105672] remoteproc remoteproc0: powering up wkup_m3
[   70.105706] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217148
[   70.106000] remoteproc remoteproc0: remote processor wkup_m3 is now up
[   72.319951] remoteproc remoteproc1: 4a334000.pru is available
[   72.335870] remoteproc remoteproc2: 4a338000.pru is available
[  564.302719] remoteproc remoteproc1: powering up 4a334000.pru
[  564.303391] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 118908
[  564.316303] remoteproc remoteproc1: registered virtio0 (type 7)
[  564.316324] remoteproc remoteproc1: remote processor 4a334000.pru is now 
up
[  590.322924] remoteproc remoteproc1: stopped remote processor 4a334000.pru
[  594.762821] remoteproc remoteproc1: powering up 4a334000.pru
[  594.763533] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 11
[  594.777049] remoteproc remoteproc1: registered virtio0 (type 7)
[  594.777060] remoteproc remoteproc1: remote processor 4a334000.pru is now 
up
dmesg | grep pru
[   72.319951] remoteproc remoteproc1: 4a334000.pru is available
[   72.320135] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed 
successfully
[   72.335870] remoteproc remoteproc2: 4a338000.pru is available
[   72.336020] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed 
successfully
[  564.302719] remoteproc remoteproc1: powering up 4a334000.pru
[  564.303391] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 118908
[  564.304236] pruss 4a30.pruss: configured system_events[63-0] = 
,0003
[  564.304251] pruss 4a30.pruss: configured intr_channels = 0x0005 
host_intr = 0x0005
[  564.316324] remoteproc remoteproc1: remote processor 4a334000.pru is now 
up
[  564.391508] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 
0x1e
[  564.467856] rpmsg_pru virtio0.rpmsg-pru.-1.30: new rpmsg_pru device: 
/dev/rpmsg_pru30
[  590.322860] pruss 4a30.pruss: unconfigured system_events[63-0] = 
,0003
[  590.322880] pruss 4a30.pruss: unconfigured host_intr = 0x0005
[  590.322924] remoteproc remoteproc1: stopped remote processor 4a334000.pru
[  594.762821] remoteproc remoteproc1: powering up 4a334000.pru
[  594.763533] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 11
[  594.764695] pruss 4a30.pruss: configured system_events[63-0] = 

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

[Walter Cromer]

You are correct to mention this TJF.  In production, I won't bother to do 
convert it to a human-readable number.   It helps with debugging right now 
though.


On Thursday, April 22, 2021 at 3:26:12 AM UTC-4 TJF wrote:

> For all who want to learn:
>
> Walter is formating a human readable number in the PRUSS code (function 
> ltoa).
>
> How much PRU cycles does a four digit number need? And how much are 
> necessary for a one digit number?
>
> Note: The PRUSS are fine for realtime solutions (if your code allows that).
>
> @Walter
> Welcome to rproc/rpmsg - you completely lost track.
>

-- 
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/4b2a19f7-00eb-418d-9c45-8e0fc6c23673n%40googlegroups.com.

Re: [beagleboard] Re: PRU cycle counter overflow

[Walter Cromer]

This isn't directly from TI but I found essentially the same code on in a 
TI lab or online somewhere.  

https://www.element14.com/community/community/designcenter/single-board-computers/next-genbeaglebone/blog/2019/08/12/beaglebone-pru-timer-functionality



On Wednesday, April 21, 2021 at 4:07:31 PM UTC-4 lazarman wrote:

> Hello Walter 
>
> Which TI  PRU examples are you using I've seen so many examples I've lost 
> track. I've seen the archive that contains  the labs1 to labs 6. 
>
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Wed, Apr 21, 2021 at 2:55 PM, Walter Cromer
>  wrote:
>
> Well the solution to the overflow was actually simple.   I had used some 
> example code from TI where they use the value 0x to clear the IEP's 
> counter.  That didn't really make sense to me except of course if your very 
> next instruction was to start the timer which would cause it to overflow 
> immediately and start counting in the main processing sequence at 0.   In 
> my case, my next step, also borrowed from their examples, was to reset the 
> overflow event flag.  Which, of course was immediately set back high 
> because the counter incremented AFTER this reset instruction and not 
> before.   So when I issued the overflow event reset, the counter was still 
> at 0x which caused an immediate overflow event. 
>
> Ugh.  Live and learn.
>
> On Wednesday, April 21, 2021 at 12:28:14 PM UTC-4 Walter Cromer wrote:
>
> I'm attempting something very similar to what you were working on.  If you 
> are willing, please share how you eventually did this.  Did you use the IEP 
> clock or the PRU's cycle counter?  I have IEP working with the iep_clk 
> (although I'm having terrible RPMSG problems right now).
>
> Also, I can't seem to correctly check the overflow bit in 
> IEP_TMR_GLB_STS.  I would bit 0 would be 1 if there has been an overflow 
> but even at startup, when the counter only has maybe 1000 counts in it, the 
> bit is 1 when I read it.  Maybe I'm not reading it correctly?
>
>
> On Monday, January 9, 2017 at 12:45:08 AM UTC-5 justin@gmail.com 
> wrote:
>
> On Thu, Jan 5, 2017 at 5:30 PM, Justin Pearson  
> wrote:
>
> Thanks Charles, that's very helpful. I didn't know about the IEP timer. 
> TRM section 4.4.3.1 says I can hook up the IEP clock source to 
> either iep_clk or ocp_clk. Which one of those clocks drives the PRU cycle 
> counter? 
>
>
>
> Maybe a better question is: Can the PRU read the IEP clock as 
> deterministically as it reads its own cycle counter (always 1 cycle)? Or 
> does it access the IEP clock over some bus that introduces 
> non-deterministic delays due to contention issues (like accessing the 512MB 
> RAM)? I'm concerned because I'm using the cycle counter for time-stamping 
> sensor and actuator measurements. If I switch to the IEP clock, I'd like to 
> know I'll have the same timing guarantees.
>
> Thanks,
> Justin
>
>  
>
>
> Thanks,
> Justin
>
>
>
> On Thu, Dec 22, 2016 at 1:43 PM, Charles Steinkuehler <
> cha...@steinkuehler.net> wrote:
>
> On 12/22/2016 10:45 AM, Justin Pearson wrote:
> > I have the same question.
> >
> > I'm using the PRU's 200 MHz cycle counter to timestamp sensor 
> measurements. At
> > 200 MHz, this 32-bit counter overflows in 20 seconds. I would like to 
> notify a C
> > program running on the 1GHz host ARM processor as soon as it overflows.
> >
> > *Is it possible to configure the PRU cycle counter to trigger an 
> interrupt in
> > the host ARM when it overflows?*
>
> Do you mean the Cycle register (offset 0x0C in the PRU_ICSS_PRU_CTRL
> register bank)?  If so, this counter doesn't even wrap around (it
> automatically stops when it hits 0x) much less generate an
> interrupt.
>
> > I know how to write PRU code to make the PRU trigger an interrupt in the 
> host,
> > but that's not quite what I want, since my PRU will be busy doing other 
> things.
> > I would like the cycle counter to trigger an interrupt automatically, 
> without
> > the PRU having to check if it has overflowed.
>
> Try using the IEP timer.  It will wrap automatically, and you can even
> setup a configurable period by using compare register zero and setting
> the CMP0_RST_CNT_EN bit.  You can also route an IEP timer event
> (pr1_iep_tim_cap_cmp_pend) to the ARM core to generate an interrupt.
>
> --
> Charles Steinkuehler
> cha...@steinkuehler.net
>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You

Re: [beagleboard] Re: PRU cycle counter overflow

[Walter Cromer]

Well the solution to the overflow was actually simple.   I had used some 
example code from TI where they use the value 0x to clear the IEP's 
counter.  That didn't really make sense to me except of course if your very 
next instruction was to start the timer which would cause it to overflow 
immediately and start counting in the main processing sequence at 0.   In 
my case, my next step, also borrowed from their examples, was to reset the 
overflow event flag.  Which, of course was immediately set back high 
because the counter incremented AFTER this reset instruction and not 
before.   So when I issued the overflow event reset, the counter was still 
at 0x which caused an immediate overflow event. 

Ugh.  Live and learn.

On Wednesday, April 21, 2021 at 12:28:14 PM UTC-4 Walter Cromer wrote:

> I'm attempting something very similar to what you were working on.  If you 
> are willing, please share how you eventually did this.  Did you use the IEP 
> clock or the PRU's cycle counter?  I have IEP working with the iep_clk 
> (although I'm having terrible RPMSG problems right now).
>
> Also, I can't seem to correctly check the overflow bit in 
> IEP_TMR_GLB_STS.  I would bit 0 would be 1 if there has been an overflow 
> but even at startup, when the counter only has maybe 1000 counts in it, the 
> bit is 1 when I read it.  Maybe I'm not reading it correctly?
>
>
> On Monday, January 9, 2017 at 12:45:08 AM UTC-5 justin@gmail.com 
> wrote:
>
>> On Thu, Jan 5, 2017 at 5:30 PM, Justin Pearson  
>> wrote:
>>
>>> Thanks Charles, that's very helpful. I didn't know about the IEP timer. 
>>> TRM section 4.4.3.1 says I can hook up the IEP clock source to 
>>> either iep_clk or ocp_clk. Which one of those clocks drives the PRU cycle 
>>> counter? 
>>>
>>
>>
>> Maybe a better question is: Can the PRU read the IEP clock as 
>> deterministically as it reads its own cycle counter (always 1 cycle)? Or 
>> does it access the IEP clock over some bus that introduces 
>> non-deterministic delays due to contention issues (like accessing the 512MB 
>> RAM)? I'm concerned because I'm using the cycle counter for time-stamping 
>> sensor and actuator measurements. If I switch to the IEP clock, I'd like to 
>> know I'll have the same timing guarantees.
>>
>> Thanks,
>> Justin
>>
>  
>>
>>
>>> Thanks,
>>> Justin
>>>
>>>
>>>
>>> On Thu, Dec 22, 2016 at 1:43 PM, Charles Steinkuehler <
>>> cha...@steinkuehler.net> wrote:
>>>
>> On 12/22/2016 10:45 AM, Justin Pearson wrote:
>>>> > I have the same question.
>>>> >
>>>> > I'm using the PRU's 200 MHz cycle counter to timestamp sensor 
>>>> measurements. At
>>>> > 200 MHz, this 32-bit counter overflows in 20 seconds. I would like to 
>>>> notify a C
>>>> > program running on the 1GHz host ARM processor as soon as it 
>>>> overflows.
>>>> >
>>>> > *Is it possible to configure the PRU cycle counter to trigger an 
>>>> interrupt in
>>>> > the host ARM when it overflows?*
>>>>
>>>> Do you mean the Cycle register (offset 0x0C in the PRU_ICSS_PRU_CTRL
>>>> register bank)?  If so, this counter doesn't even wrap around (it
>>>> automatically stops when it hits 0x) much less generate an
>>>> interrupt.
>>>>
>>>> > I know how to write PRU code to make the PRU trigger an interrupt in 
>>>> the host,
>>>> > but that's not quite what I want, since my PRU will be busy doing 
>>>> other things.
>>>> > I would like the cycle counter to trigger an interrupt automatically, 
>>>> without
>>>> > the PRU having to check if it has overflowed.
>>>>
>>>> Try using the IEP timer.  It will wrap automatically, and you can even
>>>> setup a configurable period by using compare register zero and setting
>>>> the CMP0_RST_CNT_EN bit.  You can also route an IEP timer event
>>>> (pr1_iep_tim_cap_cmp_pend) to the ARM core to generate an interrupt.
>>>>
>>>> --
>>>> Charles Steinkuehler
>>>> cha...@steinkuehler.net
>>>>
>>>
>>>> --
>>>> 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/3e1b910f-6ec3-06d1-ab1c-fd10dd3c7856%40steinkuehler.net
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>

-- 
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/fc0c68cb-7308-44ce-bef6-8f476f4b6b78n%40googlegroups.com.

Re: [beagleboard] Re: PRU cycle counter overflow

[Walter Cromer]

I'm attempting something very similar to what you were working on.  If you 
are willing, please share how you eventually did this.  Did you use the IEP 
clock or the PRU's cycle counter?  I have IEP working with the iep_clk 
(although I'm having terrible RPMSG problems right now).

Also, I can't seem to correctly check the overflow bit in IEP_TMR_GLB_STS.  
I would bit 0 would be 1 if there has been an overflow but even at startup, 
when the counter only has maybe 1000 counts in it, the bit is 1 when I read 
it.  Maybe I'm not reading it correctly?


On Monday, January 9, 2017 at 12:45:08 AM UTC-5 justin@gmail.com wrote:

> On Thu, Jan 5, 2017 at 5:30 PM, Justin Pearson  
> wrote:
>
>> Thanks Charles, that's very helpful. I didn't know about the IEP timer. 
>> TRM section 4.4.3.1 says I can hook up the IEP clock source to 
>> either iep_clk or ocp_clk. Which one of those clocks drives the PRU cycle 
>> counter? 
>>
>
>
> Maybe a better question is: Can the PRU read the IEP clock as 
> deterministically as it reads its own cycle counter (always 1 cycle)? Or 
> does it access the IEP clock over some bus that introduces 
> non-deterministic delays due to contention issues (like accessing the 512MB 
> RAM)? I'm concerned because I'm using the cycle counter for time-stamping 
> sensor and actuator measurements. If I switch to the IEP clock, I'd like to 
> know I'll have the same timing guarantees.
>
> Thanks,
> Justin
>  
>
>
>> Thanks,
>> Justin
>>
>>
>>
>> On Thu, Dec 22, 2016 at 1:43 PM, Charles Steinkuehler <
>> cha...@steinkuehler.net> wrote:
>>
>>> On 12/22/2016 10:45 AM, Justin Pearson wrote:
>>> > I have the same question.
>>> >
>>> > I'm using the PRU's 200 MHz cycle counter to timestamp sensor 
>>> measurements. At
>>> > 200 MHz, this 32-bit counter overflows in 20 seconds. I would like to 
>>> notify a C
>>> > program running on the 1GHz host ARM processor as soon as it overflows.
>>> >
>>> > *Is it possible to configure the PRU cycle counter to trigger an 
>>> interrupt in
>>> > the host ARM when it overflows?*
>>>
>>> Do you mean the Cycle register (offset 0x0C in the PRU_ICSS_PRU_CTRL
>>> register bank)?  If so, this counter doesn't even wrap around (it
>>> automatically stops when it hits 0x) much less generate an
>>> interrupt.
>>>
>>> > I know how to write PRU code to make the PRU trigger an interrupt in 
>>> the host,
>>> > but that's not quite what I want, since my PRU will be busy doing 
>>> other things.
>>> > I would like the cycle counter to trigger an interrupt automatically, 
>>> without
>>> > the PRU having to check if it has overflowed.
>>>
>>> Try using the IEP timer.  It will wrap automatically, and you can even
>>> setup a configurable period by using compare register zero and setting
>>> the CMP0_RST_CNT_EN bit.  You can also route an IEP timer event
>>> (pr1_iep_tim_cap_cmp_pend) to the ARM core to generate an interrupt.
>>>
>>> --
>>> Charles Steinkuehler
>>> cha...@steinkuehler.net
>>>
>>> --
>>> 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/3e1b910f-6ec3-06d1-ab1c-fd10dd3c7856%40steinkuehler.net
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
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/5fb26840-0eed-47ba-9b21-3fa5ddd52ae4n%40googlegroups.com.

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

[Walter Cromer]

I'm working on that very thing.  I fairly certain what is printing is an 
address although it doesn't seem to correspond to anything I'd expect.

On Tuesday, April 20, 2021 at 9:35:54 PM UTC-4 gbcs...@comcast.net wrote:

> Try changing the %n in the print statement to print out a 32 bit value. I 
> think you will see that it is an address in the PRU address space.
>
>  
>
> Graham 
>
>  
>
> *From:* beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] *On 
> Behalf Of *Walter Cromer
> *Sent:* Tuesday, April 20, 2021 10:34 AM
> *To:* BeagleBoard 
> *Subject:* [beagleboard] Strange behavior of value returned from PRU with 
> RPMSG
>
>  
>
> I am using a Beaglebone Black and C to read analog inputs with PRU0 and 
> return the data to a host program using RPMSG.
>
>  
>
> Basically, I read the data from FIFO0 fine, strip the step id from it and 
> copy it into an element of a character array in the PRU code.  
>
>  
>
> 
>
>  
>
> Data = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0));
>
>   
>   
>
>
> 
>
> if ((Data & 0x000F) == 0)  {  // checking the step id tag for step 0
>
> // if step == 0, strip off the step and put the data in array DetBSample
>
> DetBSample[sampleno] = Data & 0xFFF;
>
>  
>
> memcpy(payload, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 24); 
> // this came from TI's sample code, best I can tell it just preloads and 
> end of string character in the whole string.
>
> ltoa((long)DetBSample[sampleno], payload);  // put the value in  
> DetBSample[sampleno] in the character string payload
>
> // now send the payload to the host
>
>   
>   
> pru_rpmsg_send(, dst, src, payload, 24);   
>
>  
>
> This code compiles and runs fine.
>
>  
>
> On the host side, I do this when I'm kicked by the PRU.  (This is a 
> snippet so brackets may not match!)
>
>  
>
> /* Poll until we receive a message from the PRU and then print it */
>
> result = read(pollfds[0].fd, readBuf, MAX_BUFFER_SIZE);
>
> if (result > 0)
>
> {
>
> Volts = 
> atof(readBuf)*ADC_Res;
>
> printf("Message %d 
> received from PRU:%s or %x\n", i, readBuf, readBuf);
>
> printf("Volts read: 
> %.3f\n",Volts);
>
>  
>
> The output is strange though (snippet below).   The message #, string 
> value of readBuf and Volts are all correct. But when I output readBug as 
> hex, it never changes.  I thought it might be the address of readBuf but it 
> doesn't appear to be.  
>
>  
>
> The voltage matches the input we're providing from a bench power supply 
> and the decimal value is correct.  It's just that this hex value doesn't 
> change.
>
>  
>
> Message 97 received from PRU:3742 or 4b50b0
>
> Volts read: 1.644
>
> Message 98: Sent to PRU
>
> Message 98 received from PRU:3744 or 4b50b0
>
> Volts read: 1.645
>
> Message 99: Sent to PRU
>
> Message 99 received from PRU:3743 or 4b50b0
>
> Volts read: 1.645
>
> Received 100 messages, closing /dev/rpmsg_pru30
>
>  
>
>  
>
> -- 
>
> 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/784129ee-1cf5-4438-881e-7ac6621e7aben%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/784129ee-1cf5-4438-881e-7ac6621e7aben%40googlegroups.com?utm_medium=email_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/e1e0cd85-ed1d-4de8-983f-c787d4edfb7dn%40googlegroups.com.

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

[Walter Cromer]

Here is the definition

char readBuf[MAX_BUFFER_SIZE];

MAX_BUFFER_SIZE = 512

I think I may have just realized why this is occurring.   When %s refers to 
readBuf it will output the value in the character array.  But %x is 
outputting the address of it.  

Duh...not the first dumb mistake I've made today.



On Tuesday, April 20, 2021 at 4:59:35 PM UTC-4 lazarman wrote:

> Hello Walter
>
> I didn't see your definition of readBuf.
> why you expecting an address to change? 
> I am glad you found the TI examples helpful.
>
> Mark
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Tue, Apr 20, 2021 at 12:33 PM, Walter Cromer
>  wrote:
>
> I am using a Beaglebone Black and C to read analog inputs with PRU0 and 
> return the data to a host program using RPMSG.
>
> Basically, I read the data from FIFO0 fine, strip the step id from it and 
> copy it into an element of a character array in the PRU code.  
>
> 
>
> Data = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0));
> 
> if ((Data & 0x000F) == 0)  {  // checking the step id tag for step 0
> // if step == 0, strip off the step and put the data in array DetBSample
> DetBSample[sampleno] = Data & 0xFFF;
>
> memcpy(payload, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 24); 
> // this came from TI's sample code, best I can tell it just preloads and 
> end of string character in the whole string.
> ltoa((long)DetBSample[sampleno], payload);  // put the value in  
> DetBSample[sampleno] in the character string payload
> // now send the payload to the host
> pru_rpmsg_send(, dst, src, payload, 24);   
>
> This code compiles and runs fine.
>
> On the host side, I do this when I'm kicked by the PRU.  (This is a 
> snippet so brackets may not match!)
>
> /* Poll until we receive a message from the PRU and then print it */
> result = read(pollfds[0].fd, readBuf, MAX_BUFFER_SIZE);
>if (result > 0)
> {
>Volts = atof(readBuf)*ADC_Res;
> printf("Message %d received from PRU:%s or %x\n", i, 
> readBuf, readBuf);
> printf("Volts read: %.3f\n",Volts);
>
> The output is strange though (snippet below).   The message #, string 
> value of readBuf and Volts are all correct. But when I output readBug as 
> hex, it never changes.  I thought it might be the address of readBuf but it 
> doesn't appear to be.  
>
> The voltage matches the input we're providing from a bench power supply 
> and the decimal value is correct.  It's just that this hex value doesn't 
> change.
>
> Message 97 received from PRU:3742 or 4b50b0
> Volts read: 1.644
> Message 98: Sent to PRU
> Message 98 received from PRU:3744 or 4b50b0
> Volts read: 1.645
> Message 99: Sent to PRU
> Message 99 received from PRU:3743 or 4b50b0
> Volts read: 1.645
> Received 100 messages, closing /dev/rpmsg_pru30
>
>
> -- 
> 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/784129ee-1cf5-4438-881e-7ac6621e7aben%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/784129ee-1cf5-4438-881e-7ac6621e7aben%40googlegroups.com?utm_medium=email_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/34361932-cafb-46a7-b31c-c962fe3bda89n%40googlegroups.com.

[beagleboard] Strange behavior of value returned from PRU with RPMSG

[Walter Cromer]

I am using a Beaglebone Black and C to read analog inputs with PRU0 and 
return the data to a host program using RPMSG.

Basically, I read the data from FIFO0 fine, strip the step id from it and 
copy it into an element of a character array in the PRU code.  



Data = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0));

if ((Data & 0x000F) == 0)  {  // checking the step id tag for step 0
// if step == 0, strip off the step and put the data in array DetBSample
DetBSample[sampleno] = Data & 0xFFF;

memcpy(payload, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 24); // 
this came from TI's sample code, best I can tell it just preloads and end 
of string character in the whole string.
ltoa((long)DetBSample[sampleno], payload);  // put the value in  
DetBSample[sampleno] in the character string payload
// now send the payload to the host
pru_rpmsg_send(, dst, src, payload, 24);   

This code compiles and runs fine.

On the host side, I do this when I'm kicked by the PRU.  (This is a snippet 
so brackets may not match!)

/* Poll until we receive a message from the PRU and then print it */
result = read(pollfds[0].fd, readBuf, MAX_BUFFER_SIZE);
   if (result > 0)
{
   Volts = atof(readBuf)*ADC_Res;
printf("Message %d received from PRU:%s or %x\n", i, 
readBuf, readBuf);
printf("Volts read: %.3f\n",Volts);

The output is strange though (snippet below).   The message #, string value 
of readBuf and Volts are all correct. But when I output readBug as hex, it 
never changes.  I thought it might be the address of readBuf but it doesn't 
appear to be.  

The voltage matches the input we're providing from a bench power supply and 
the decimal value is correct.  It's just that this hex value doesn't change.

Message 97 received from PRU:3742 or 4b50b0
Volts read: 1.644
Message 98: Sent to PRU
Message 98 received from PRU:3744 or 4b50b0
Volts read: 1.645
Message 99: Sent to PRU
Message 99 received from PRU:3743 or 4b50b0
Volts read: 1.645
Received 100 messages, closing /dev/rpmsg_pru30


-- 
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/784129ee-1cf5-4438-881e-7ac6621e7aben%40googlegroups.com.

[beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

Dennis - It was just an example that, for me, made it clearer to me the 
relationship between A/D channels and steps.  This isn't something we're 
doing in this application.

WC

On Friday, April 16, 2021 at 1:36:16 PM UTC-4 Dennis Bieber wrote:

> On Thu, 15 Apr 2021 09:35:20 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  wrote:
>
>
> >So if I had an application that had a sensor A that needs to be read 
> every 
> >10ms and sensor B that only needs to be read every minute, I could wire 
> >channel 1 to sensor A and assign it to step 1 and wire channel 2 to 
> sensor 
> >B and assign it to step 2. 
> >
> >Then at startup, when I want to read both sensors, I enable steps 1 and 2 
> >but not 3-16. This saves time on the read as channels 3-7 aren't needed 
> >and steps 3-16 aren't needed so I don't use them. Then after the initial 
> >read when I don't need to read sensor B until a minute passes, I can 
> change 
> >STEPENABLE so only step 1 is enabled and execute a read every 10 ms. Only 
> >sensor A would be read. Then at one minute intervals, I change STEPENABLE 
> >so steps 1 & 2 are enabled and when read is triggered, sensors A and B 
> are 
> >read. 
> >
>
> Seems like a lot of fiddling around with step enables, and assumes ADC
> reading is a one-shot operation. I'd likely just create a process loop with
> major frame of 1 minute, minor frame of 10ms (use a "frame counter" that
> you increment after every read), and read both sources each time -- but
> only report the one-minute source at top of major frame; counter at 6
> if my calculations are right).
>
> The ADC configurations supports continuous mode in which, after all
> enabled steps are processed, it loops back to the top and restarts the step
> sequence. Note:
>
> "
> 12.3.4 One-Shot (Single) or Continuous Mode
>
> When the sequencer finishes cycling through all the enabled steps, the
> user can decide if the sequencer should stop (one-shot), or loop back and
> schedule the step again (continuous).
>
> If one-shot mode is selected, the sequencer will take care of disabling
> the step enable bit after the conversion. If continuous mode is selected,
> it is the software’s responsibility to turn off the step enable bit.
> "
> ... if doing one-shot, you don't have to turn off the second step enable...
> You have to, instead, turn ON the steps you want active before doing the
> reads -- every time.
>
> Also pertinent -- as soon as any step is enabled, the ADC goes out of
> IDLE to handle enabled steps. There is a master Enable in the CTRL register
> -- to synchronize the reads, you'd likely have to set it to 0, program the
> steps, then set it to 1 to start the ADC. 
>
>
>
>
> -- 
> 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/b2cf59f7-435c-4f35-a765-d959193ec798n%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

I'm 100% sure it wasn't doing this before because I worked through the 
exercises in Mark Yodre's PRUCookbook and this command

config-pin P9_31 pruout 

worked before

Now it gives

debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/05blocks/code$ 
config-pin P9_31 pruout
ERROR: open() for /sys/devices/platform/ocp/ocp:P9_31_pinmux/state failed, 
No such file or directory

I get the same error when I execute this as root.


On Friday, April 16, 2021 at 6:43:46 AM UTC-4 Walter Cromer wrote:

> Yes.  It’s throwing an error when I do that. I don’t think it was before 
> but I could be mistaken.  I can’t even query the options with 
> configure-pin.  It makes me wonder if the pins I’m choosing are in use by 
> something else like video or audio.  I will check this today. 
>
>
> On Thu, Apr 15, 2021 at 4:00 PM Darren Freed  wrote:
>
>> Have you set the pins with config-pin to pruout or pruin?  This caught me 
>> out a few times when I was learning PRU.
>>
>>
>> On Thu, Apr 15, 2021 at 7:15 AM Walter Cromer  
>> wrote:
>>
>>> I'm sticking with remoteproc for now.  I spent most of yesterday reading 
>>> TI's documentation and the Beaglebone Black SRM in detail and believe I 
>>> have a much better handle on how this works now.  
>>> My plan is to allocate memory space in pru0's RAM for the data storage 
>>> and then have an ARM program read it from there.Our production solution 
>>> does not need to share this data with the ARM side.  We only need this 
>>> during R so I'm not worried about the two sides clobbering each other on 
>>> the production system.
>>>
>>> But, now, of course, nothing that used to work is working!  I had 
>>> started out with the PRUCookbook and had P9_11 blinking an LED.  Now, 
>>> nothing.  dmesg shows the PRU starting and stopping and the firmware file 
>>> in /lib/firmware is new based on ls -l output so I'm fairly certain that 
>>> the code got compiled and copied over to the right directory.  The 
>>> PRUCookbook example that blinks USR3 works and I can change the blinking 
>>> frequency and change it to blink USR2 instead and all that works.  But the 
>>> example to blink P9_11 won't and neither will another one to blink P9_27.  
>>>  The only thing I know I changed is that the PRUCookbook directories were 
>>> all owned by root and group root.  They weren't originally like that but 
>>> got changed somehow.  Yesterday I did a *chown -R debian:debian* on 
>>> PRUCookbook to change them so Debian could edit files in those 
>>> directories.  I wouldn't think this would matter since all the real 
>>> remoteproc action happens in other directories.  
>>>
>>> I also started working with CCS some and trying to get it going.  
>>>  Somewhere along the way, something deleted all the files and folders in my 
>>> local WIndows machine's Documents folder.  I'm running anti-virus and 
>>> anti-malware on the WIndows box.
>>>
>>> Just when I thought I was going to start really moving forward!!!
>>>
>>> On Thursday, April 15, 2021 at 2:24:55 AM UTC-4 TJF wrote:
>>>
>>>> lazarman schrieb am Donnerstag, 15. April 2021 um 07:55:39 UTC+2:
>>>>
>>>>> I thought he had an unacceptable delay reading ADC from ARM?
>>>>> Just trying to understand how libpruio fixes this and if it did why 
>>>>> even bother with PRU?
>>>>>
>>>>
>>>> In RB mode libpruio fetches ADC data at accurate timing (no delays) in 
>>>> to a ring buffer. The ARM can read/evaluate the data later.
>>>>
>>>> @Walter
>>>> Inspired by lazarman, just another thought: perhaps you don't need a 
>>>> PRU mainloop at all. Perhaps you can meet your needs by ARM code using the 
>>>> libpruio trigger features in MM mode.
>>>>
>>>>1. Configure your trigger event (up to four events can get chained 
>>>>up).
>>>>2. Open valves.
>>>>3. Start MM mode, synchronously waiting for trigger.
>>>>4. Close valves.
>>>>5. ?Perhaps evaluate pre-trigger values?
>>>>6. Repeat from step 2.
>>>>
>>>> -- 
>>> 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.
>

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

As I get a better understanding and experience this may change, but right 
now I don't think it can handle the volume of data we need to move between 
systems.  And, that volume is only needed during R  The production 
system will not need to keep that data.

So, my plan is to instance arrays on the ARM side and use RPMSG to pass the 
addresses to the PRU.  The PRU code will translate that to ARM addresses.  
 As the data is collected it will be stored in arrays local to the PRUs (in 
the 8k or 12k memory spaces).  When the time-sensitive data collection is 
completed, the PRU array will contain the data.  Then we'll just copy it 
over the ARM addresses.

My assumption is that since the ARM instances the arrays in memory, Linux 
will not overwrite those locations so they'll be 'safe'.  I'll probably use 
RPMSG to alert ARM that the data is going to be transferred and wait on an 
'ack' from the ARM before copying it over. 

Seems like it should work.



On Friday, April 16, 2021 at 3:01:56 AM UTC-4 lazarman wrote:

> Hello TJF
>
> Looks very powerful and code is very generic and well thought out. I 
> thought you couldn't code?藍
>
> I'm on tablet forgive my laziness where are the ADC examples located in c 
> language if possible 
>
> Looks like you support multiple languages nice.
>
>
> I'm guessing  below reference you mentioned is the am335x TRM or are you 
> referring to the ARM intellectual property for ADC?
>
> It's also possible to directly write to the step configuration in 
> AdcSet::St_p 
> 
>  by 
> writing to the member variables Confg and Delay. See ARM Reference Guide, 
> chapter 12  for details on ADC 
> configurations.
>
> Thanks. Did you write this library? It's quite a bit to wrap ones mind 
> around. How long dis this take to develop. 
>
> I've got a basic  understanding of how RPMSG works I'd like to understand 
> how libpruio handles the data exchange. 
>
> I'm wondering why Walter isn't using RPMSG  he's talking about using the 
> other unused  PRU memory to store data and have ARM read it. I'm trying to 
> see if that's doable for my own understanding. Certainly would not be good 
> if that PRU loaded code from ARM. The Linux part I'm unfamiliar with. From 
> my reading it sounds like starting PRU is manually done from linux command 
> line. 
>
> Loading and debugging PRU code seems to me to be slow and time consuming 
> compared to jtag.
>
> Lastly in the unlikely event a modified libpruio example crashes what is 
> the debug mechanisms beyond dmsg saying dude you crashed go recompile and 
> reload. Are console output echoed back.
>
> Thanks in advance also any data sharing examples in libpruio?
> Mark
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Fri, Apr 16, 2021 at 12:47 AM, TJF
>  wrote:
>
>
> wal...@edenconceptsllc.com schrieb am Donnerstag, 15. April 2021 um 
> 18:35:20 UTC+2:
>
> So, STEPENABLE lets me enable the steps that I want to be executed.  (I 
> missed that concept before.)
>
> So if I had an application that had a sensor A that needs to be read every 
> 10ms and sensor B that only needs to be read every minute, I could wire 
> channel 1 to sensor A and assign it to step 1 and wire channel 2 to sensor 
> B and assign it to step 2. 
>
> Then at startup, when I want to read both sensors, I enable steps 1 and 2 
> but not 3-16.  This saves time on the read as channels 3-7 aren't needed 
> and steps 3-16 aren't needed so I don't use them.  Then after the initial 
> read when I don't need to read sensor B until a minute passes, I can change 
> STEPENABLE so only step 1 is enabled and execute a read every 10 ms.  Only 
> sensor A would be read.  Then at one minute intervals, I change STEPENABLE 
> so steps 1 & 2 are enabled and when read is triggered, sensors A and B are 
> read. 
>
> There're 17 steps, one charge step and 16 sample steps. Each step 
> configures not only the multiplexer (chanel 0-7), but also an open delay 
> and a sample delay, as well as an avaraging number. That's explained at 
> AdcUdt::setStep() 
> ,
>  
> including a hint where to find further information in the ARM TRM.
>
> In order to write to the STEPENABLE register you've to stop the sequencer, 
> write the new value and restart the sequencer again. This is 3 times L3 
> operation, which need at least 3 PRU cycles each (perhaps more in case of 
> heavy travel). How do you what to ensure accurate ADC timing?
>
> The outnumber of step registers isn't thought of macroscopic asymmetry (in 
> your case sample channel A and B at 10 ms and ignore the B value for a 
> minute). 

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

Yes.  It’s throwing an error when I do that. I don’t think it was before
but I could be mistaken.  I can’t even query the options with
configure-pin.  It makes me wonder if the pins I’m choosing are in use by
something else like video or audio.  I will check this today.


On Thu, Apr 15, 2021 at 4:00 PM Darren Freed  wrote:

> Have you set the pins with config-pin to pruout or pruin?  This caught me
> out a few times when I was learning PRU.
>
>
> On Thu, Apr 15, 2021 at 7:15 AM Walter Cromer 
> wrote:
>
>> I'm sticking with remoteproc for now.  I spent most of yesterday reading
>> TI's documentation and the Beaglebone Black SRM in detail and believe I
>> have a much better handle on how this works now.
>> My plan is to allocate memory space in pru0's RAM for the data storage
>> and then have an ARM program read it from there.Our production solution
>> does not need to share this data with the ARM side.  We only need this
>> during R so I'm not worried about the two sides clobbering each other on
>> the production system.
>>
>> But, now, of course, nothing that used to work is working!  I had started
>> out with the PRUCookbook and had P9_11 blinking an LED.  Now, nothing.
>> dmesg shows the PRU starting and stopping and the firmware file in
>> /lib/firmware is new based on ls -l output so I'm fairly certain that the
>> code got compiled and copied over to the right directory.  The PRUCookbook
>> example that blinks USR3 works and I can change the blinking frequency and
>> change it to blink USR2 instead and all that works.  But the example to
>> blink P9_11 won't and neither will another one to blink P9_27.   The only
>> thing I know I changed is that the PRUCookbook directories were all owned
>> by root and group root.  They weren't originally like that but got changed
>> somehow.  Yesterday I did a *chown -R debian:debian* on PRUCookbook to
>> change them so Debian could edit files in those directories.  I wouldn't
>> think this would matter since all the real remoteproc action happens in
>> other directories.
>>
>> I also started working with CCS some and trying to get it going.
>>  Somewhere along the way, something deleted all the files and folders in my
>> local WIndows machine's Documents folder.  I'm running anti-virus and
>> anti-malware on the WIndows box.
>>
>> Just when I thought I was going to start really moving forward!!!
>>
>> On Thursday, April 15, 2021 at 2:24:55 AM UTC-4 TJF wrote:
>>
>>> lazarman schrieb am Donnerstag, 15. April 2021 um 07:55:39 UTC+2:
>>>
>>>> I thought he had an unacceptable delay reading ADC from ARM?
>>>> Just trying to understand how libpruio fixes this and if it did why
>>>> even bother with PRU?
>>>>
>>>
>>> In RB mode libpruio fetches ADC data at accurate timing (no delays) in
>>> to a ring buffer. The ARM can read/evaluate the data later.
>>>
>>> @Walter
>>> Inspired by lazarman, just another thought: perhaps you don't need a PRU
>>> mainloop at all. Perhaps you can meet your needs by ARM code using the
>>> libpruio trigger features in MM mode.
>>>
>>>1. Configure your trigger event (up to four events can get chained
>>>up).
>>>2. Open valves.
>>>3. Start MM mode, synchronously waiting for trigger.
>>>4. Close valves.
>>>5. ?Perhaps evaluate pre-trigger values?
>>>6. Repeat from step 2.
>>>
>>> --
>> 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/11c39bb9-4891-4271-8374-ae76f00f9e17n%40googlegroups.com
>> <https://groups.google.com/d/msgid/beagleboard/11c39bb9-4891-4271-8374-ae76f00f9e17n%40googlegroups.com?utm_medium=email_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/CAMRnUvDf16iYJoqN_xZo%2BJMKF%2Bso6oUdLPKXKEwaqrCjK4a8Ng%40mail.gmail.com
> <https://groups.google.co

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

Just to close the loop on this question, I learned from TI's E2E forum how 
the A/D channels and steps relate.  
Basically, the steps allow the configuration of how the channels are read.  
There are only 8 channels but you can create a sequence of up to 16 steps 
to read them.

Here's my explanation.

So, STEPENABLE lets me enable the steps that I want to be executed.  (I 
missed that concept before.)

So if I had an application that had a sensor A that needs to be read every 
10ms and sensor B that only needs to be read every minute, I could wire 
channel 1 to sensor A and assign it to step 1 and wire channel 2 to sensor 
B and assign it to step 2. 

Then at startup, when I want to read both sensors, I enable steps 1 and 2 
but not 3-16.  This saves time on the read as channels 3-7 aren't needed 
and steps 3-16 aren't needed so I don't use them.  Then after the initial 
read when I don't need to read sensor B until a minute passes, I can change 
STEPENABLE so only step 1 is enabled and execute a read every 10 ms.  Only 
sensor A would be read.  Then at one minute intervals, I change STEPENABLE 
so steps 1 & 2 are enabled and when read is triggered, sensors A and B are 
read. 

BTW - I don't have a real-world application like this but I guess someday I 
could.
This is a very flexible system!
On Wednesday, April 14, 2021 at 11:03:30 AM UTC-4 Walter Cromer wrote:

>  The TSC_ADC only has 8 channels.  So why are there 16 STEP registers? 
>
> On Wednesday, April 14, 2021 at 11:02:56 AM UTC-4 Walter Cromer wrote:
>
>> My setup is a Windows 10 PC with a Black connected via USB or a Black 
>> wireless connected via wi-fi.   So far I have done all the C development on 
>> the ARM side with Cloud9 and only occasionally use Nano.  It's met my needs 
>> just fine so far but this is getting more complex.  I installed TI's CCS 
>> but it (or TI)  prefers to be on a Linux box apparently.
>>
>>
>>
>> On Wednesday, April 14, 2021 at 1:39:56 AM UTC-4 TJF wrote:
>>
>>> Nano isn't best choice for polyglot applications. I'm using Geany (on PC 
>>> exchanging source files via virtual file system), while I compile and test 
>>> under LINUX on the BB.
>>>
>>> wal...@edenconceptsllc.com schrieb am Dienstag, 13. April 2021 um 
>>> 20:25:06 UTC+2:
>>>
>>>> Here's one more thing I am struggling with though.  It's a mental block 
>>>> I think.  I'm used to controlling GPIOs on the ARM side using sysfs.   It 
>>>> appears that on the PRU, we use __R30 instead but I don't understand how 
>>>> that works.  I read through it this morning and it still isn't sinking in. 
>>>>  
>>>> If anyone can help make this clearer, I'd appreciate it.
>>>
>>>
>>> Check out example pruss_toggle 
>>> <https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html#sSecExaPruToggle>
>>> .
>>>
>>

-- 
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/04dbe2ba-1c09-43a7-9f7c-5707456bdd06n%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

I think this is a better version.   Than what I posted a few minutes ago ( 
Ideleted that post).

https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual



On Thursday, April 15, 2021 at 9:55:41 AM UTC-4 lazarman wrote:

> Beaglebone Black SRM
>
> Have not seen this can you share a link
>
> Thanks
>
> Mark
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Thu, Apr 15, 2021 at 8:15 AM, Walter Cromer
>  wrote:
>
> I'm sticking with remoteproc for now.  I spent most of yesterday reading 
> TI's documentation and the Beaglebone Black SRM in detail and believe I 
> have a much better handle on how this works now.  
> My plan is to allocate memory space in pru0's RAM for the data storage and 
> then have an ARM program read it from there.Our production solution 
> does not need to share this data with the ARM side.  We only need this 
> during R so I'm not worried about the two sides clobbering each other on 
> the production system.
>
> But, now, of course, nothing that used to work is working!  I had started 
> out with the PRUCookbook and had P9_11 blinking an LED.  Now, nothing.  
> dmesg shows the PRU starting and stopping and the firmware file in 
> /lib/firmware is new based on ls -l output so I'm fairly certain that the 
> code got compiled and copied over to the right directory.  The PRUCookbook 
> example that blinks USR3 works and I can change the blinking frequency and 
> change it to blink USR2 instead and all that works.  But the example to 
> blink P9_11 won't and neither will another one to blink P9_27.   The only 
> thing I know I changed is that the PRUCookbook directories were all owned 
> by root and group root.  They weren't originally like that but got changed 
> somehow.  Yesterday I did a *chown -R debian:debian* on PRUCookbook to 
> change them so Debian could edit files in those directories.  I wouldn't 
> think this would matter since all the real remoteproc action happens in 
> other directories.  
>
> I also started working with CCS some and trying to get it going.  
>  Somewhere along the way, something deleted all the files and folders in my 
> local WIndows machine's Documents folder.  I'm running anti-virus and 
> anti-malware on the WIndows box.
>
> Just when I thought I was going to start really moving forward!!!
>
> On Thursday, April 15, 2021 at 2:24:55 AM UTC-4 TJF wrote:
>
> lazarman schrieb am Donnerstag, 15. April 2021 um 07:55:39 UTC+2:
>
> I thought he had an unacceptable delay reading ADC from ARM?
> Just trying to understand how libpruio fixes this and if it did why even 
> bother with PRU?
>
>
> In RB mode libpruio fetches ADC data at accurate timing (no delays) in to 
> a ring buffer. The ARM can read/evaluate the data later.
>
> @Walter
> Inspired by lazarman, just another thought: perhaps you don't need a PRU 
> mainloop at all. Perhaps you can meet your needs by ARM code using the 
> libpruio trigger features in MM mode.
>
>1. Configure your trigger event (up to four events can get chained up).
>2. Open valves.
>3. Start MM mode, synchronously waiting for trigger.
>4. Close valves.
>5. ?Perhaps evaluate pre-trigger values?
>6. Repeat from step 2.
>
> -- 
>
> 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/11c39bb9-4891-4271-8374-ae76f00f9e17n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/11c39bb9-4891-4271-8374-ae76f00f9e17n%40googlegroups.com?utm_medium=email_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/ec7ec08b-1c81-4764-8d41-aafe88aa9028n%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

It's on the web in a few places.  Here's a link.

https://cdn-shop.adafruit.com/datasheets/BBB_SRM.pdf

WC

On Thursday, April 15, 2021 at 9:55:41 AM UTC-4 lazarman wrote:

> Beaglebone Black SRM
>
> Have not seen this can you share a link
>
> Thanks
>
> Mark
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Thu, Apr 15, 2021 at 8:15 AM, Walter Cromer
>  wrote:
>
> I'm sticking with remoteproc for now.  I spent most of yesterday reading 
> TI's documentation and the Beaglebone Black SRM in detail and believe I 
> have a much better handle on how this works now.  
> My plan is to allocate memory space in pru0's RAM for the data storage and 
> then have an ARM program read it from there.Our production solution 
> does not need to share this data with the ARM side.  We only need this 
> during R so I'm not worried about the two sides clobbering each other on 
> the production system.
>
> But, now, of course, nothing that used to work is working!  I had started 
> out with the PRUCookbook and had P9_11 blinking an LED.  Now, nothing.  
> dmesg shows the PRU starting and stopping and the firmware file in 
> /lib/firmware is new based on ls -l output so I'm fairly certain that the 
> code got compiled and copied over to the right directory.  The PRUCookbook 
> example that blinks USR3 works and I can change the blinking frequency and 
> change it to blink USR2 instead and all that works.  But the example to 
> blink P9_11 won't and neither will another one to blink P9_27.   The only 
> thing I know I changed is that the PRUCookbook directories were all owned 
> by root and group root.  They weren't originally like that but got changed 
> somehow.  Yesterday I did a *chown -R debian:debian* on PRUCookbook to 
> change them so Debian could edit files in those directories.  I wouldn't 
> think this would matter since all the real remoteproc action happens in 
> other directories.  
>
> I also started working with CCS some and trying to get it going.  
>  Somewhere along the way, something deleted all the files and folders in my 
> local WIndows machine's Documents folder.  I'm running anti-virus and 
> anti-malware on the WIndows box.
>
> Just when I thought I was going to start really moving forward!!!
>
> On Thursday, April 15, 2021 at 2:24:55 AM UTC-4 TJF wrote:
>
> lazarman schrieb am Donnerstag, 15. April 2021 um 07:55:39 UTC+2:
>
> I thought he had an unacceptable delay reading ADC from ARM?
> Just trying to understand how libpruio fixes this and if it did why even 
> bother with PRU?
>
>
> In RB mode libpruio fetches ADC data at accurate timing (no delays) in to 
> a ring buffer. The ARM can read/evaluate the data later.
>
> @Walter
> Inspired by lazarman, just another thought: perhaps you don't need a PRU 
> mainloop at all. Perhaps you can meet your needs by ARM code using the 
> libpruio trigger features in MM mode.
>
>1. Configure your trigger event (up to four events can get chained up).
>2. Open valves.
>3. Start MM mode, synchronously waiting for trigger.
>4. Close valves.
>5. ?Perhaps evaluate pre-trigger values?
>6. Repeat from step 2.
>
> -- 
>
> 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/11c39bb9-4891-4271-8374-ae76f00f9e17n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/11c39bb9-4891-4271-8374-ae76f00f9e17n%40googlegroups.com?utm_medium=email_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/d1bce786-71d9-462d-aaf2-81fbbc71b751n%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

I'm sticking with remoteproc for now.  I spent most of yesterday reading 
TI's documentation and the Beaglebone Black SRM in detail and believe I 
have a much better handle on how this works now.  
My plan is to allocate memory space in pru0's RAM for the data storage and 
then have an ARM program read it from there.Our production solution 
does not need to share this data with the ARM side.  We only need this 
during R so I'm not worried about the two sides clobbering each other on 
the production system.

But, now, of course, nothing that used to work is working!  I had started 
out with the PRUCookbook and had P9_11 blinking an LED.  Now, nothing.  
dmesg shows the PRU starting and stopping and the firmware file in 
/lib/firmware is new based on ls -l output so I'm fairly certain that the 
code got compiled and copied over to the right directory.  The PRUCookbook 
example that blinks USR3 works and I can change the blinking frequency and 
change it to blink USR2 instead and all that works.  But the example to 
blink P9_11 won't and neither will another one to blink P9_27.   The only 
thing I know I changed is that the PRUCookbook directories were all owned 
by root and group root.  They weren't originally like that but got changed 
somehow.  Yesterday I did a *chown -R debian:debian* on PRUCookbook to 
change them so Debian could edit files in those directories.  I wouldn't 
think this would matter since all the real remoteproc action happens in 
other directories.  

I also started working with CCS some and trying to get it going.  
 Somewhere along the way, something deleted all the files and folders in my 
local WIndows machine's Documents folder.  I'm running anti-virus and 
anti-malware on the WIndows box.

Just when I thought I was going to start really moving forward!!!

On Thursday, April 15, 2021 at 2:24:55 AM UTC-4 TJF wrote:

> lazarman schrieb am Donnerstag, 15. April 2021 um 07:55:39 UTC+2:
>
>> I thought he had an unacceptable delay reading ADC from ARM?
>> Just trying to understand how libpruio fixes this and if it did why even 
>> bother with PRU?
>>
>
> In RB mode libpruio fetches ADC data at accurate timing (no delays) in to 
> a ring buffer. The ARM can read/evaluate the data later.
>
> @Walter
> Inspired by lazarman, just another thought: perhaps you don't need a PRU 
> mainloop at all. Perhaps you can meet your needs by ARM code using the 
> libpruio trigger features in MM mode.
>
>1. Configure your trigger event (up to four events can get chained up).
>2. Open valves.
>3. Start MM mode, synchronously waiting for trigger.
>4. Close valves.
>5. ?Perhaps evaluate pre-trigger values?
>6. Repeat from step 2.
>
>

-- 
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/11c39bb9-4891-4271-8374-ae76f00f9e17n%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

Definitely agree.  My head is spinning.  I am very appreciative of all the 
help and suggestions!

On Wednesday, April 14, 2021 at 1:13:25 PM UTC-4 lazarman wrote:

> Walter
>
> Just trying to be a guiding light. Why not get the control loop working on 
> PRU first.?
>
> Your being pulled into to many directions. I know how that feels I've been 
> there.
>
> Once the ADC and output works worry about getting Data over to ARM.
>
> Too many new things will kill you. Master the PRU coding first and on 
> second thought forget the CCS JTAG suggestions I gave.
>
> I'm getting dizzy reading all the suggestions you received. 
>
> What's working what's the architecture?
>
> Too many chef's the soup will boil away.
>
> Thanks 
>
> Mark
>
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Wed, Apr 14, 2021 at 10:58 AM, Walter Cromer
>  wrote:
>
> So I looked over the libpruio page and it looks great.  My head's spinning 
> a bit between remoteproc, uio, and libpruio options but I'd like to try 
> libpruio.  
> I don't want to break remoteproc if I set up to use libpruio.  Will that 
> happen?
>
> Also, I'm running Buster (version.sh) at the bottom of this post 
> The instructions refer to Jessie.  Are the Debian packages referred to 
> compatible with Buster?  Here's what I am referring to.
>
> The easy way to benefit from *libpruio* is to install the Debian 
> packages. They're not in mainline, yet. So you have to add a PPA (Personal 
> Package Archive) to your package management sources. On the default Debian 
> operating system, edit the file sudo nano /etc/apt/sources.list and add the 
> lines:
> deb http://beagle.tuks.nl/debian jessie/ deb-src 
> http://beagle.tuks.nl/debian jessie/ 
>
> Then grep the keyring by (mind the '-' character at the end)
> wget -qO - http://beagle.tuks.nl/debian/pubring.gpg | sudo apt-key add - 
>
> Once prepared, you can update your package manager database
> sudo apt-get update
>
> debian@beaglebone:/$ sudo opt/scripts/tools/version.sh
> git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
> eeprom:[A335BNLT00C04417BBBK1847]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-g07d5700e21]:[location: dd MBR]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2018.03-2-gac9cce7c6a]:[location: dd MBR]
> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
> UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
> UBOOT: Loaded Overlay:[BB-ADC-00A0]
> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
> UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
> UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
> UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
> kernel:[4.19.94-ti-r61]
> nodejs:[v10.15.2]
> /boot/uEnv.txt Settings:
> uboot_overlay_options:[enable_uboot_overlays=1]
>
> uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]
>
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ]
> pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]
> pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
> pkg:[kmod]:[26-1]
> pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
> pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc 
> admin spi iio docker tisdk weston-launch xenomai cloud9ide]
> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
> dmesg | grep remote
> [   66.835497] remoteproc remoteproc0: wkup_m3 is available
> [   67.240120] remoteproc remoteproc0: powering up wkup_m3
> [   67.240151] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217148
> [   67.240404] remoteproc remoteproc0: remote processor wkup_m3 is now up
> [   69.894313] remoteproc remoteproc1: 4a334000.pru is available
> [   69.907897] remoteproc remoteproc2: 4a338000.pru is available
> [15549.657580] remoteproc remoteproc1: powering up 4a334000.pru
> [15549.665009] remoteproc remoteproc1: Bo

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

So I looked over the libpruio page and it looks great.  My head's spinning 
a bit between remoteproc, uio, and libpruio options but I'd like to try 
libpruio.  
I don't want to break remoteproc if I set up to use libpruio.  Will that 
happen?

Also, I'm running Buster (version.sh) at the bottom of this post 
The instructions refer to Jessie.  Are the Debian packages referred to 
compatible with Buster?  Here's what I am referring to.

The easy way to benefit from *libpruio* is to install the Debian packages. 
They're not in mainline, yet. So you have to add a PPA (Personal Package 
Archive) to your package management sources. On the default Debian 
operating system, edit the file sudo nano /etc/apt/sources.list and add the 
lines:
deb http://beagle.tuks.nl/debian jessie/ deb-src 
http://beagle.tuks.nl/debian jessie/ 

Then grep the keyring by (mind the '-' character at the end)
wget -qO - http://beagle.tuks.nl/debian/pubring.gpg | sudo apt-key add - 

Once prepared, you can update your package manager database
sudo apt-get update

debian@beaglebone:/$ sudo opt/scripts/tools/version.sh
git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]
eeprom:[A335BNLT00C04417BBBK1847]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2019.04-2-g07d5700e21]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.03-2-gac9cce7c6a]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]
UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]
kernel:[4.19.94-ti-r61]
nodejs:[v10.15.2]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.14.20210401.0-0~buster+20210401]
pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc 
admin spi iio docker tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[   66.835497] remoteproc remoteproc0: wkup_m3 is available
[   67.240120] remoteproc remoteproc0: powering up wkup_m3
[   67.240151] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217148
[   67.240404] remoteproc remoteproc0: remote processor wkup_m3 is now up
[   69.894313] remoteproc remoteproc1: 4a334000.pru is available
[   69.907897] remoteproc remoteproc2: 4a338000.pru is available
[15549.657580] remoteproc remoteproc1: powering up 4a334000.pru
[15549.665009] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 30880
[15549.665035] remoteproc remoteproc1: header-less resource table
[15549.675909] remoteproc remoteproc1: Boot failed: -22
[15602.811891] remoteproc remoteproc1: powering up 4a334000.pru
[15602.812184] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 30880
[15602.812202] remoteproc remoteproc1: header-less resource table
[15602.823804] remoteproc remoteproc1: Boot failed: -22
[15801.464252] remoteproc remoteproc1: powering up 4a334000.pru
[15801.464540] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 30880
[15801.464559] remoteproc remoteproc1: header-less resource table
[15801.475947] remoteproc remoteproc1: Boot failed: -22
[15835.561165] remoteproc remoteproc1: powering up 4a334000.pru
[15835.561459] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 30880
[15835.561478] remoteproc remoteproc1: header-less resource table
[15835.575362] remoteproc remoteproc1: Boot failed: -22
[15973.384568] remoteproc remoteproc1: powering up 4a334000.pru
[15973.384866] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 30880
[15973.384884] remoteproc remoteproc1: header-less resource table
[15973.395805] remoteproc remoteproc1: Boot failed: -22
[15996.157221] remoteproc remoteproc1: powering up 4a334000.pru
[15996.157504] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
size 30880
[15996.157523] remoteproc remoteproc1: header-less resource table

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

 The TSC_ADC only has 8 channels.  So why are there 16 STEP registers? 

On Wednesday, April 14, 2021 at 11:02:56 AM UTC-4 Walter Cromer wrote:

> My setup is a Windows 10 PC with a Black connected via USB or a Black 
> wireless connected via wi-fi.   So far I have done all the C development on 
> the ARM side with Cloud9 and only occasionally use Nano.  It's met my needs 
> just fine so far but this is getting more complex.  I installed TI's CCS 
> but it (or TI)  prefers to be on a Linux box apparently.
>
>
>
> On Wednesday, April 14, 2021 at 1:39:56 AM UTC-4 TJF wrote:
>
>> Nano isn't best choice for polyglot applications. I'm using Geany (on PC 
>> exchanging source files via virtual file system), while I compile and test 
>> under LINUX on the BB.
>>
>> wal...@edenconceptsllc.com schrieb am Dienstag, 13. April 2021 um 
>> 20:25:06 UTC+2:
>>
>>> Here's one more thing I am struggling with though.  It's a mental block 
>>> I think.  I'm used to controlling GPIOs on the ARM side using sysfs.   It 
>>> appears that on the PRU, we use __R30 instead but I don't understand how 
>>> that works.  I read through it this morning and it still isn't sinking in.  
>>> If anyone can help make this clearer, I'd appreciate it.
>>
>>
>> Check out example pruss_toggle 
>> <https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html#sSecExaPruToggle>
>> .
>>
>

-- 
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/17f5daf7-9271-4e90-a4f3-309b1ce20510n%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

My setup is a Windows 10 PC with a Black connected via USB or a Black 
wireless connected via wi-fi.   So far I have done all the C development on 
the ARM side with Cloud9 and only occasionally use Nano.  It's met my needs 
just fine so far but this is getting more complex.  I installed TI's CCS 
but it (or TI)  prefers to be on a Linux box apparently.



On Wednesday, April 14, 2021 at 1:39:56 AM UTC-4 TJF wrote:

> Nano isn't best choice for polyglot applications. I'm using Geany (on PC 
> exchanging source files via virtual file system), while I compile and test 
> under LINUX on the BB.
>
> wal...@edenconceptsllc.com schrieb am Dienstag, 13. April 2021 um 
> 20:25:06 UTC+2:
>
>> Here's one more thing I am struggling with though.  It's a mental block I 
>> think.  I'm used to controlling GPIOs on the ARM side using sysfs.   It 
>> appears that on the PRU, we use __R30 instead but I don't understand how 
>> that works.  I read through it this morning and it still isn't sinking in.  
>> If anyone can help make this clearer, I'd appreciate it.
>
>
> Check out example pruss_toggle 
> 
> .
>

-- 
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/f1f8bf49-4f8c-4d7c-9c0e-5b886f246960n%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

We're designing it the way you suggested.  The nice thing is that basically 
the control logic has already been written in C on the ARM side.  Now, I 
just need to get it ported to the PRUs and create the communications 
between the PRUs and a new ARM app that supervises everything from the 
user's point of view.  Meaning, taking inputs like start, stop and giving 
feedback by turning LEDs on and off.  And it needs to take in some basic 
system configuration data from the cloud periodically that the PRU will 
consume to adjust it's operation.  

I am making progress.  Part of my problem was using Cloud9 for 
development.  That's where all my ARM development has been so far.  I have 
CCS installed on my Windows 10 machine and started working through TI's PRU 
Hands On Labs.  Unfortunately, the very first one doesn't work because 
their document is written for CCS running on Linux.   Step 6 says to delete 
the linker file and add it back with Project->Add Files but that's grayed 
out.  I've asked TI about that.   But I got it to compile by writing on the 
Beagle using nano and compiling it there.   I've ready a lot of TI 
documentation today and learned a lot. 

Here's one more thing I am struggling with though.  It's a mental block I 
think.  I'm used to controlling GPIOs on the ARM side using sysfs.   It 
appears that on the PRU, we use __R30 instead but I don't understand how 
that works.  I read through it this morning and it still isn't sinking in.  
If anyone can help make this clearer, I'd appreciate it.

On Tuesday, April 13, 2021 at 11:25:08 AM UTC-4 lazarman wrote:

> Walter
>
> Your best bet.
>
> Run your whole control loop on the PRU that's as realtime as you get. Use 
> a foreground background loop. Use the ARM like a PC with Linux to access 
> the system via ethernet.
>
> You could also run control on ARM without linux but this way you have all 
> the resources of Linux to access the system.
>
> This assumes your output's from control loop are accessable from PRU.
>
> The point is Linux can only run slow control loops and this way you don't 
> have to debug the delay.
>
> This wasn't obvious to me before as all the hard realtime systems I work 
> on run an RTOS on ARM it has all the resources of Linux but cost $.
>
> In our system we did that on the DSP the PID did the math on a fast DSP.
>
> ARM is just a gateway to outside world.
>
> Myself I'd debug the PRU with JTAG and CCS you can see exactly what's 
> going on and dump these registers from CCS.
>
> Some people like printf but with a PRU based system you are essentially 
> doing barebones.
>
> There's videos on PRU development doing this online.
>
> Loading code via rproc and using  printf is like burning and erasing an 
> eeprom to test your changes. You wait 45 minutes for it to erase try your 
> code and do it again.
>
> Not for me.
>
> Mark
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Tue, Apr 13, 2021 at 9:54 AM, Dennis Lee Bieber
>  wrote:
>
> On Mon, 12 Apr 2021 13:08:48 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  wrote:
>
> >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!?
> >
>
> Why? Take into account the ()s.
>
> From what I can tell, this is adding the ADC register offset to the
> base address of the (?) wakeup register block, which is passed as parameter
> to HWREG (no doubt some macro that sets up actual access to the SoC
> registers and returns a pointer or some such), and then assigns 0x02 into
> the register so indicated.
>
>
> -- 
> 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+unsub...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/44cb7gtf6pl4d4j3e6oqo57g5n0hobi29c%404ax.com
> .
>
>

-- 
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/768e7840-c4d7-49c5-9b91-6a2b07020ff0n%40googlegroups.com.

[beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

Yeah, I woke up realizing what a dunce I was reading it the way I was.  
HWREG equates to (*((volatile unsigned int *) (x)))


On Tuesday, April 13, 2021 at 10:54:36 AM UTC-4 Dennis Bieber wrote:

> On Mon, 12 Apr 2021 13:08:48 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  wrote:
>
> >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!?
> >
>
> Why? Take into account the ()s.
>
> From what I can tell, this is adding the ADC register offset to the
> base address of the (?) wakeup register block, which is passed as parameter
> to HWREG (no doubt some macro that sets up actual access to the SoC
> registers and returns a pointer or some such), and then assigns 0x02 into
> the register so indicated.
>
>
> -- 
> 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/e8bac78b-4ba0-4fa2-853b-d5e81eeb7597n%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

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=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>>>>
>>>> On Mon, Apr 12, 2021 at 3:08 PM, Walter Cromer
>>>>  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=Global_Internal_YGr

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

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=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Mon, Apr 12, 2021 at 3:08 PM, Walter Cromer
>  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=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Sat, Apr 10, 2021 at 4:47 AM, TJF
>  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 

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

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=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>>
>> On Sat, Apr 10, 2021 at 4:47 AM, TJF
>>  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_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/90e0f287-b0b3-41af-9f1e-36fcd06f8dc2n%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

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 
> 
>
> On Sat, Apr 10, 2021 at 4:47 AM, TJF
>  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
>  
> 
> .
>
>

-- 
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/3394d742-038e-4945-babe-cad6812da6d2n%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

Thanks, TJF!  This sounds like good advice but tough tricks to learn!   The 
more I think through the architecture of my solution, the more I realize 
the PRU code needs to do. In our lab evaluation setup, I need the voltages 
measured by the ADC for analysis to develop base algorithms for detecting 
the events from the sensors properly.  But once we have that developed, in 
a production system, the PRU code will apply the logic to the data it is 
reading and probably should control the valves directly through with the 
GPIOs.   Otherwise, if we pass the data to the ARM side, Linux could go off 
and service something else and leave the valves running when they shouldn't 
be or not running when they should be.But startup parameters will be 
selected by the user, so I'm thinking the UI is on ARM and once it has the 
start-up information, it just passes key info to the PRU code and lets it 
go do its thing.   

So what is the long-term support for the different options?  I thought 
remoteproc was the way of the future and uio_pruss drivers were phasing 
out.   We are on the front end of a new product/solution design and need to 
pay attention to 'end of life' type issues.   (Of course, the solution must 
work too!) 

Good to know about the EM interference.  Theoretically, we should be in a 
low external EM noise environment, however, we are using the BBB Wireless!  
 I had painful experiences with RF wreaking havoc on a system in graduate 
school.



On Saturday, April 10, 2021 at 5:47:41 AM UTC-4 TJF 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6a1cbbb4-6e14-4b5c-b5ff-25dcfd07d753n%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

I would not be nearly as far along if I did not have Mark Yoder's PRU 
Cookbook!   I'll take a look at the TI documentation.   

Right now, I'm working with some examples from GA Tech and the compiler 
running in Cloud9 IDE is balking at a __far definition in pru_cfg.h.  I'm 
searching the GCC documentation and web for some fix for this.  I suspect 
there must be a compiler switch to cause it to accept these but I don't 
know what it is or if that's even the solution. Any help would be 
appreciated!

Walter

On Friday, April 9, 2021 at 3:49:59 PM UTC-4 darre...@gmail.com wrote:

> For my project that used a PRU to sample the onboard ADC, I relied very 
> heavily on the TI PRU_ADC_onChip 
> <https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/am335x/PRU_ADC_onChip?h=master>
>  
> example code, along with Mark Yoder's most excellent PRU cookbook 
> <https://markayoder.github.io/PRUCookbook/#_pru_cookbook>.  With those 
> two resources, you should be able to do what you're hoping to do.
>
> Good luck!
> df
>
> On Fri, Apr 9, 2021 at 1:00 PM Walter Cromer  
> wrote:
>
>> It's a fairly simple application really and that's what makes it 
>> frustrating!   We'll get there!  I learn something every day and that's 
>> just fine with me.
>>
>> On Friday, April 9, 2021 at 2:54:55 PM UTC-4 lazarman wrote:
>>
>>> Plenty of data Walter thanks.
>>>
>>> You could write some linux code that reads Data from from PRU ram( I'm 
>>> not sure if there's several ways to get Data beyond remote messaging and 
>>> reading the shared ram directly) factor in delay for new sample's to be 
>>> updated from ADC  at least you could ensure that works in your time frame.
>>>
>>> If that seems OK
>>>
>>> Then use examples for PRU I'm skeptical about needing to use assembler 
>>> it's not the PRU read time that's a bottleneck.
>>>
>>> I'd be interested in seeing that PRU to ARM transfer rate it should not 
>>> take alot of time but if Linux is still interfering beyond your needed 
>>> specific time period you will only have one choice but to find what's 
>>> exactly doing this  delay and mitigation of that will be your only hope. 
>>>
>>> Typically a proof of concept fesigh verification like this is always 
>>> wise.
>>>
>>> If using this  chip is your only option you'd have one option left but I 
>>> don't think you would like it.
>>>
>>> And I'm already well known for suggestioning that option on ARM so I'm 
>>> not going to mention it.
>>>
>>> I do understand the value of having a feature rich OS on ARM that's 
>>> royalty free but I've been lucky on the 50 or so projects I've worked on 
>>> this wasn't the issue.
>>>
>>> Another project was a Diesel engine controller they did a DVT phase 
>>> first. Design verification Test
>>>
>>> I wish I could help on Linux side but I can't there's plenty of people 
>>> in here using Linux so I think you can get more ideas and help.
>>>
>>> Not Sure how many have used Linux in actual hard realtime systems.
>>>
>>> Your application doesn't sound extremely hard realtime so be interested 
>>> in seeing this have a happy ending.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Sent from Yahoo Mail on Android 
>>> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>>>
>>> On Fri, Apr 9, 2021 at 1:16 PM, Walter Cromer
>>>  wrote:
>>>
>>> Thanks Dennis.  That is in sync with my research.
>>>
>>> On Friday, April 9, 2021 at 2:00:07 PM UTC-4 Dennis Bieber wrote:
>>>
>>> On Fri, 9 Apr 2021 09:30:53 -0700 (PDT), in 
>>> gmane.comp.hardware.beagleboard.user Walter Cromer 
>>>  wrote: 
>>>
>>>
>>> >We are still experimenting but our preliminary calculations lead us to 
>>> >believe a reading every 50 microseconds will be sufficient. We can 
>>> probably 
>>> >get by with 100 microseconds if we have to but I think the BBBw can 
>>> easily 
>>> >sample at this rate, right? 
>>>
>>> Well, the SoC reference (SPRS717J) indicates that the ADC should be 
>>> capable of 200K samples per second. If I haven't flubbed the math, that 
>>> appears to come down to one sample every 5us. 
>>>
>>> As I recall,

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

It's a fairly simple application really and that's what makes it 
frustrating!   We'll get there!  I learn something every day and that's 
just fine with me.

On Friday, April 9, 2021 at 2:54:55 PM UTC-4 lazarman wrote:

> Plenty of data Walter thanks.
>
> You could write some linux code that reads Data from from PRU ram( I'm not 
> sure if there's several ways to get Data beyond remote messaging and 
> reading the shared ram directly) factor in delay for new sample's to be 
> updated from ADC  at least you could ensure that works in your time frame.
>
> If that seems OK
>
> Then use examples for PRU I'm skeptical about needing to use assembler 
> it's not the PRU read time that's a bottleneck.
>
> I'd be interested in seeing that PRU to ARM transfer rate it should not 
> take alot of time but if Linux is still interfering beyond your needed 
> specific time period you will only have one choice but to find what's 
> exactly doing this  delay and mitigation of that will be your only hope. 
>
> Typically a proof of concept fesigh verification like this is always wise.
>
> If using this  chip is your only option you'd have one option left but I 
> don't think you would like it.
>
> And I'm already well known for suggestioning that option on ARM so I'm not 
> going to mention it.
>
> I do understand the value of having a feature rich OS on ARM that's 
> royalty free but I've been lucky on the 50 or so projects I've worked on 
> this wasn't the issue.
>
> Another project was a Diesel engine controller they did a DVT phase first. 
> Design verification Test
>
> I wish I could help on Linux side but I can't there's plenty of people in 
> here using Linux so I think you can get more ideas and help.
>
> Not Sure how many have used Linux in actual hard realtime systems.
>
> Your application doesn't sound extremely hard realtime so be interested in 
> seeing this have a happy ending.
>
>
>
>
>
>
>
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Fri, Apr 9, 2021 at 1:16 PM, Walter Cromer
>  wrote:
>
> Thanks Dennis.  That is in sync with my research.
>
> On Friday, April 9, 2021 at 2:00:07 PM UTC-4 Dennis Bieber wrote:
>
> On Fri, 9 Apr 2021 09:30:53 -0700 (PDT), in 
> gmane.comp.hardware.beagleboard.user Walter Cromer 
>  wrote: 
>
>
> >We are still experimenting but our preliminary calculations lead us to 
> >believe a reading every 50 microseconds will be sufficient. We can 
> probably 
> >get by with 100 microseconds if we have to but I think the BBBw can 
> easily 
> >sample at this rate, right? 
>
> Well, the SoC reference (SPRS717J) indicates that the ADC should be 
> capable of 200K samples per second. If I haven't flubbed the math, that 
> appears to come down to one sample every 5us. 
>
> As I recall, the PRU runs on a 200MHz clock, and PRU instructions, for 
> the most, run in one clock cycle. Should be enough cycles per sample to 
> handle processing  
>
> Of course, it may matter how you have the ADC programmed. 
>
>
>
> -- 
> 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...@googlegroups.com.
> To view this discussion on the web visit 
>
>
> https://groups.google.com/d/msgid/beagleboard/44d5f47f-973d-4b08-bcdb-d93e0e6c3f70n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/44d5f47f-973d-4b08-bcdb-d93e0e6c3f70n%40googlegroups.com?utm_medium=email_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/1c1af0c5-207f-47fe-9c47-e97b563bbcecn%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

When I try to run this in Cloud9, I'm getting this error.  I'm not sure 
where type __far is defined but apparently I'm missing that definition.  I 
have to copy pru_cfg.h over to /usr/include manually to get this far.  
Maybe there are other include files that are missing that it hasn't warned 
me about?  Sorry be such as neophyte!

/usr/include/pru_cfg.h:242:10: error: unknown type name ‘__far’
 volatile __far pruCfg CT_CFG __attribute__((cregister("PRU_CFG", near), 
peripheral));
  ^
/usr/include/pru_cfg.h:242:23: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or 
‘__attribute__’ before ‘CT_CFG’
 volatile __far pruCfg CT_CFG __attribute__((cregister("PRU_CFG", near), 
peripheral));
   ^~
PRU_AnalogReadfromGT.c:15:10: fatal error: pru_intc.h: No such file or 
directory
 #include 
  ^~~~
compilation terminated.
make: *** [/var/lib/cloud9/common/Makefile:215: 
/tmp/cloud9-examples/PRU_AnalogReadfromGT.o] Error 1

On Friday, April 9, 2021 at 11:19:47 AM UTC-4 pierric...@gadz.org wrote:

> Hi, 
> I believe there are some simple ADC-read example directly in the image 
> under /var/lib/cloud9/Techlab/.challenges, or here: 
> https://github.com/beagleboard/cloud9-examples/blob/master/PocketBeagle/TechLab/.challenges/analogIn.pru0.c
> They are labeled for PocketBeagle but it's the same ti-am335x chip so they 
> should work easily on the BBB. 
> Hope it helps! 
> Pierrick 
>
> Le vendredi 9 avril 2021 à 10:57:32 UTC-4, wal...@edenconceptsllc.com a 
> écrit :
>
>> Understood.  Our application won't require FAA or FDA approval but it 
>> definitely needs the more deterministic performance of a bare bones app so 
>> I'm heading in the direction of the ADC being read by a PRU program and 
>> communicating back to the ARM for other processes (UI, reading other 
>> non-time-sensitive inputs, etc.).   
>>
>> On Friday, April 9, 2021 at 10:23:26 AM UTC-4 lazarman wrote:
>>
>>> 1) 
>>> *Linux* is not a real-time operating system (OS) in and of itself. ... 
>>> “The idea is to run critical applications like the control loop on VxWorks 
>>> and then run non-*deterministic* analytics on *Linux*.
>>>
>>> Hard realtime apps like closed loop positioning used in pressing 
>>> plants,automation,fighter planes etc etc don't use Linux. Determinism 
>>> required by safety critical systems certified by FAA would require you 
>>> found delay measured it to calculate worst case as well as validated 
>>> software.
>>>
>>>
>>> https://www.automationworld.com/products/control/blog/13318614/clarifying-the-linux-real-time-issue#:~:text=Linux%20is%20not%20a%20real,OS)%20in%20and%20of%20itself.=%E2%80%9CThe%20idea%20is%20to%20run,non%2Ddeterministic%20analytics%20on%20Linux.
>>>
>>>
>>>
>>> What makes the Linux scheduler seem unpredictable? 
>>> 
>>> What makes the Linux scheduler seem unpredictable? 
>>>
>>> The question refers to the output of a multi-threaded application, where 
>>> each thread merely prints its ID (user assigned number) on the standard 
>>> output. Here all threads have equal priority and com...
>>>
>>> 
>>>  
>>>
>>>
>>> 2) I say no depends on how much delay is acceptable there are buses 
>>> between shared memory etc it will improve over using ARM.
>>>
>>> Ideal situation is a barebone app designed with minimal interrupt 
>>> latency followed by an RTOS that's guaranteed to meet latency specs 
>>> especially one certified by FAA or FDA  of course these are expensive 
>>>
>>>
>>>
>>>
>>> Sent from Yahoo Mail on Android 
>>> 
>>>
>>> On Fri, Apr 9, 2021 at 8:23 AM, TJF
>>>  wrote:
>>>
>>>
>>> wal...@edenconceptsllc.com schrieb am Freitag, 9. April 2021 um 
>>> 14:41:00 UTC+2:
>>>
>>> I'm looking at some example code and there references to ADC_TSC.  I 
>>> realize this is a reference to the Touchscreen controller which provides 
>>> the ADC functionality.  And I suspect this refers to the base memory 
>>> address of the chip but I cannot find where that is defined in any header 
>>> files anywhere.  It would help me to follow these examples if I knew where 
>>> that reference was.
>>>
>>>
>>> Find high-level code (FreeBASIC) in files src/pruio/pruio_adc.[bas|bi] 
>>> and low level code (assembler) in file src/pruio/pruio_adc.p.
>>>
>>>
>>> Unfortunately, too, the examples are Python and I'm not a Python 
>>> programmer.I work in C.  So I'm having to dig through this and learn 
>>> some Python at the same time.  Not a bad thing but time consuming!
>>>
>>>
>>> Python examples are in folder src/python. FreeBASIC examples are in 
>>> folder src/examples. And C examples are in folder src/c_examples. Find 
>>> an overview at
>>>

[beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

Thanks Dennis.  That is in sync with my research.

On Friday, April 9, 2021 at 2:00:07 PM UTC-4 Dennis Bieber wrote:

> On Fri, 9 Apr 2021 09:30:53 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  wrote:
>
> >We are still experimenting but our preliminary calculations lead us to 
> >believe a reading every 50 microseconds will be sufficient. We can 
> probably 
> >get by with 100 microseconds if we have to but I think the BBBw can 
> easily 
> >sample at this rate, right?
>
> Well, the SoC reference (SPRS717J) indicates that the ADC should be
> capable of 200K samples per second. If I haven't flubbed the math, that
> appears to come down to one sample every 5us.
>
> As I recall, the PRU runs on a 200MHz clock, and PRU instructions, for
> the most, run in one clock cycle. Should be enough cycles per sample to
> handle processing 
>
> Of course, it may matter how you have the ADC programmed.
>
>
>
> -- 
> 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/44d5f47f-973d-4b08-bcdb-d93e0e6c3f70n%40googlegroups.com.

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

We are controlling fluid flow by controlling two valves.  (I am being a bit 
obscure because there are some proprietary processes involved.)

We start the flow and then read two sensors that are 'watching' the fluid 
for an event.   There is an event 'start' in the fluid and then a following 
event 'end' that we determine by watching the values from the sensors.   I 
believe this 'watch' part will be handled by the PRU firmware.  When the 
event is over, the valves are turned off.  We believe that the ARM will 
handle the valve control and UI.The C code running under Linux has 
completely missed events because of its non-deterministic operation.
The communication between ARM and PRU programs should consist of 

1 - start / stop reading the sensors - considering just flipping a bit in a 
memory location both can access for this.  ARM will have write access, PRU 
will just monitor it.  (I don't really know how to do this yet. Still 
learning.)
2 - raw data collected about the event by the PRU doesn't really have to be 
accessed by the ARM in normal operation.  (For R, we'd probably like to 
have it though.)  Every sensor reading has to have its corresponding 
timestamp but all this data can be tossed once it is consumed.   The PRU 
will need to be able to do some statistics on it like mean, mode, std. dev. 
3 - if conditions are met, the PRU needs to tell the ARM.  considering just 
flipping a bit in a memory location the PRU can write to and the ARM can 
only read from for this.

The valve on/off can handle delays of 50 ms with no issue at all.

(I'm an old dog learning new tricks.  Years ago my hands-on experience was 
with Motorola 68xx and 68xxx series processors so I was comfortable writing 
directly to memory locations, registers, etc.  It took me a while on 
returning to this to get comfortable with sysfs but I definitely see the 
limitations in projects like this one!   Thanks for your patience and help!)
On Friday, April 9, 2021 at 1:38:37 PM UTC-4 lazarman wrote:

> Hi
>
> ??but I think the BBBw can easily sample at this rate, right?
>
> Asking about ARM/linux side ? or 
>
> PRU side 
>
> Polling or Interrupt?
>
> Explain you delay details at least delay duration  and what your app does 
> with data would help.
>
> The calculation I mentioned seeing people reply about were on the PRU.
>
> Keep in mind there's overhead to get Data from PRU to ARM.
>
> The timing becomes critical when you need to react from the  data you  
> read  quickly. If that's not the case your just talking about how many 
> sample's you use to control right? That's why I would expand a bit on your 
> application.
>
> I've worked on  stuff that read and reacted in 10 microseconds closed loop 
> plastic pressing for example that was easily achieved in 1988 
> microprocessor speeds 
>
> I've also worked on control loops that ran faster than 1  micro second on 
> a similar processor OMAP L138 in that case the code ran on the DSP I forget 
> the clock speed. In this case the motor control ran every 100 nanosecond I 
> believe but it's used TI RTOS. 
>
> If the delay on Linux isn't acceptable add some details I mentioned 
> hopefully the two guys who calculated PRU latencies will reply or I will 
> find that post if possible.
>
> Again it's probably highly  likely even a polled PRU app can read Data 
> quickly dependant on conversation rates time I'm assuming you need the ARM 
> to get Data in 100 microseconds?
>
> I'm not sure the transfer rate between PRU and ARM us determistic if linux 
> is used .
>
> Hopefully this makes sense if not ask but I'd follow up with more detail
>
> Mark
>
>
> *From: *"beagl...@googlegroups.com"  on behalf 
> of Walter Cromer 
> *Reply-To: *"beagl...@googlegroups.com" 
> *Date: *Friday, April 9, 2021 at 12:29 PM
> *To: *BeagleBoard 
> *Subject: *Re: [beagleboard] Re: Periodic delay reading analog inputs 
> with C, will PRUs solve it and is it worth it?
>
>  
>
> Thanks, I'll check that out!
>
> On Friday, April 9, 2021 at 11:19:47 AM UTC-4 pierric...@gadz.org wrote:
>
> Hi, 
>
> I believe there are some simple ADC-read example directly in the image 
> under /var/lib/cloud9/Techlab/.challenges, or here: 
> https://github.com/beagleboard/cloud9-examples/blob/master/PocketBeagle/TechLab/.challenges/analogIn.pru0.c
>
> They are labeled for PocketBeagle but it's the same ti-am335x chip so they 
> should work easily on the BBB. 
>
> Hope it helps! 
>
> Pierrick 
>
> Le vendredi 9 avril 2021 à 10:57:32 UTC-4, wal...@edenconceptsllc.com a 
> écrit :
>
> Understood.  Our application won't require FAA or FDA approval but it 
> definitely needs the more deterministic performance of a bare bones app so 
> I'm heading in the direction of the AD

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

We are still experimenting but our preliminary calculations lead us to 
believe a reading every 50 microseconds will be sufficient. We can probably 
get by with 100 microseconds if we have to but I think the BBBw can easily 
sample at this rate, right?

WC

On Friday, April 9, 2021 at 11:58:29 AM UTC-4 lazarman wrote:

> I'd share your timing requirement needs I've seen people get help in here 
> before after doing this. search group. That way you don't spend time trying 
> to meet a goal not attainable on PRU.
>
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Fri, Apr 9, 2021 at 10:19 AM, pierric...@gadz.org
>  wrote:
>
> Hi, 
> I believe there are some simple ADC-read example directly in the image 
> under /var/lib/cloud9/Techlab/.challenges, or here: 
> https://github.com/beagleboard/cloud9-examples/blob/master/PocketBeagle/TechLab/.challenges/analogIn.pru0.c
> They are labeled for PocketBeagle but it's the same ti-am335x chip so they 
> should work easily on the BBB. 
> Hope it helps! 
> Pierrick 
>
> Le vendredi 9 avril 2021 à 10:57:32 UTC-4, wal...@edenconceptsllc.com a 
> écrit :
>
> Understood.  Our application won't require FAA or FDA approval but it 
> definitely needs the more deterministic performance of a bare bones app so 
> I'm heading in the direction of the ADC being read by a PRU program and 
> communicating back to the ARM for other processes (UI, reading other 
> non-time-sensitive inputs, etc.).   
>
> On Friday, April 9, 2021 at 10:23:26 AM UTC-4 lazarman wrote:
>
> 1) 
> *Linux* is not a real-time operating system (OS) in and of itself. ... 
> “The idea is to run critical applications like the control loop on VxWorks 
> and then run non-*deterministic* analytics on *Linux*.
>
> Hard realtime apps like closed loop positioning used in pressing 
> plants,automation,fighter planes etc etc don't use Linux. Determinism 
> required by safety critical systems certified by FAA would require you 
> found delay measured it to calculate worst case as well as validated 
> software.
>
>
> https://www.automationworld.com/products/control/blog/13318614/clarifying-the-linux-real-time-issue#:~:text=Linux%20is%20not%20a%20real,OS)%20in%20and%20of%20itself.=%E2%80%9CThe%20idea%20is%20to%20run,non%2Ddeterministic%20analytics%20on%20Linux.
>
>
>
> What makes the Linux scheduler seem unpredictable? 
> 
> What makes the Linux scheduler seem unpredictable? 
>
> The question refers to the output of a multi-threaded application, where 
> each thread merely prints its ID (user assigned number) on the standard 
> output. Here all threads have equal priority and com...
>
> 
>  
>
>
> 2) I say no depends on how much delay is acceptable there are buses 
> between shared memory etc it will improve over using ARM.
>
> Ideal situation is a barebone app designed with minimal interrupt latency 
> followed by an RTOS that's guaranteed to meet latency specs especially one 
> certified by FAA or FDA  of course these are expensive 
>
>
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Fri, Apr 9, 2021 at 8:23 AM, TJF
>  wrote:
>
>
> wal...@edenconceptsllc.com schrieb am Freitag, 9. April 2021 um 14:41:00 
> UTC+2:
>
> I'm looking at some example code and there references to ADC_TSC.  I 
> realize this is a reference to the Touchscreen controller which provides 
> the ADC functionality.  And I suspect this refers to the base memory 
> address of the chip but I cannot find where that is defined in any header 
> files anywhere.  It would help me to follow these examples if I knew where 
> that reference was.
>
>
> Find high-level code (FreeBASIC) in files src/pruio/pruio_adc.[bas|bi] 
> and low level code (assembler) in file src/pruio/pruio_adc.p.
>
>
> Unfortunately, too, the examples are Python and I'm not a Python 
> programmer.I work in C.  So I'm having to dig through this and learn 
> some Python at the same time.  Not a bad thing but time consuming!
>
>
> Python examples are in folder src/python. FreeBASIC examples are in 
> folder src/examples. And C examples are in folder src/c_examples. Find an 
> overview at
>
>
> https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html
>
> 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 

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

Thanks, I'll check that out!

On Friday, April 9, 2021 at 11:19:47 AM UTC-4 pierric...@gadz.org wrote:

> Hi, 
> I believe there are some simple ADC-read example directly in the image 
> under /var/lib/cloud9/Techlab/.challenges, or here: 
> https://github.com/beagleboard/cloud9-examples/blob/master/PocketBeagle/TechLab/.challenges/analogIn.pru0.c
> They are labeled for PocketBeagle but it's the same ti-am335x chip so they 
> should work easily on the BBB. 
> Hope it helps! 
> Pierrick 
>
> Le vendredi 9 avril 2021 à 10:57:32 UTC-4, wal...@edenconceptsllc.com a 
> écrit :
>
>> Understood.  Our application won't require FAA or FDA approval but it 
>> definitely needs the more deterministic performance of a bare bones app so 
>> I'm heading in the direction of the ADC being read by a PRU program and 
>> communicating back to the ARM for other processes (UI, reading other 
>> non-time-sensitive inputs, etc.).   
>>
>> On Friday, April 9, 2021 at 10:23:26 AM UTC-4 lazarman wrote:
>>
>>> 1) 
>>> *Linux* is not a real-time operating system (OS) in and of itself. ... 
>>> “The idea is to run critical applications like the control loop on VxWorks 
>>> and then run non-*deterministic* analytics on *Linux*.
>>>
>>> Hard realtime apps like closed loop positioning used in pressing 
>>> plants,automation,fighter planes etc etc don't use Linux. Determinism 
>>> required by safety critical systems certified by FAA would require you 
>>> found delay measured it to calculate worst case as well as validated 
>>> software.
>>>
>>>
>>> https://www.automationworld.com/products/control/blog/13318614/clarifying-the-linux-real-time-issue#:~:text=Linux%20is%20not%20a%20real,OS)%20in%20and%20of%20itself.=%E2%80%9CThe%20idea%20is%20to%20run,non%2Ddeterministic%20analytics%20on%20Linux.
>>>
>>>
>>>
>>> What makes the Linux scheduler seem unpredictable? 
>>> 
>>> What makes the Linux scheduler seem unpredictable? 
>>>
>>> The question refers to the output of a multi-threaded application, where 
>>> each thread merely prints its ID (user assigned number) on the standard 
>>> output. Here all threads have equal priority and com...
>>>
>>> 
>>>  
>>>
>>>
>>> 2) I say no depends on how much delay is acceptable there are buses 
>>> between shared memory etc it will improve over using ARM.
>>>
>>> Ideal situation is a barebone app designed with minimal interrupt 
>>> latency followed by an RTOS that's guaranteed to meet latency specs 
>>> especially one certified by FAA or FDA  of course these are expensive 
>>>
>>>
>>>
>>>
>>> Sent from Yahoo Mail on Android 
>>> 
>>>
>>> On Fri, Apr 9, 2021 at 8:23 AM, TJF
>>>  wrote:
>>>
>>>
>>> wal...@edenconceptsllc.com schrieb am Freitag, 9. April 2021 um 
>>> 14:41:00 UTC+2:
>>>
>>> I'm looking at some example code and there references to ADC_TSC.  I 
>>> realize this is a reference to the Touchscreen controller which provides 
>>> the ADC functionality.  And I suspect this refers to the base memory 
>>> address of the chip but I cannot find where that is defined in any header 
>>> files anywhere.  It would help me to follow these examples if I knew where 
>>> that reference was.
>>>
>>>
>>> Find high-level code (FreeBASIC) in files src/pruio/pruio_adc.[bas|bi] 
>>> and low level code (assembler) in file src/pruio/pruio_adc.p.
>>>
>>>
>>> Unfortunately, too, the examples are Python and I'm not a Python 
>>> programmer.I work in C.  So I'm having to dig through this and learn 
>>> some Python at the same time.  Not a bad thing but time consuming!
>>>
>>>
>>> Python examples are in folder src/python. FreeBASIC examples are in 
>>> folder src/examples. And C examples are in folder src/c_examples. Find 
>>> an overview at
>>>
>>>
>>> https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html
>>>
>>> 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/04caf3a3-cd8c-449e-9fd7-9ed6df33f99en%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>>

-- 
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 

Re: [beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

Understood.  Our application won't require FAA or FDA approval but it 
definitely needs the more deterministic performance of a bare bones app so 
I'm heading in the direction of the ADC being read by a PRU program and 
communicating back to the ARM for other processes (UI, reading other 
non-time-sensitive inputs, etc.).   

On Friday, April 9, 2021 at 10:23:26 AM UTC-4 lazarman wrote:

> 1) 
> *Linux* is not a real-time operating system (OS) in and of itself. ... 
> “The idea is to run critical applications like the control loop on VxWorks 
> and then run non-*deterministic* analytics on *Linux*.
>
> Hard realtime apps like closed loop positioning used in pressing 
> plants,automation,fighter planes etc etc don't use Linux. Determinism 
> required by safety critical systems certified by FAA would require you 
> found delay measured it to calculate worst case as well as validated 
> software.
>
>
> https://www.automationworld.com/products/control/blog/13318614/clarifying-the-linux-real-time-issue#:~:text=Linux%20is%20not%20a%20real,OS)%20in%20and%20of%20itself.=%E2%80%9CThe%20idea%20is%20to%20run,non%2Ddeterministic%20analytics%20on%20Linux.
>
>
>
> What makes the Linux scheduler seem unpredictable? 
> 
> What makes the Linux scheduler seem unpredictable? 
>
> The question refers to the output of a multi-threaded application, where 
> each thread merely prints its ID (user assigned number) on the standard 
> output. Here all threads have equal priority and com...
>
> 
>  
>
>
> 2) I say no depends on how much delay is acceptable there are buses 
> between shared memory etc it will improve over using ARM.
>
> Ideal situation is a barebone app designed with minimal interrupt latency 
> followed by an RTOS that's guaranteed to meet latency specs especially one 
> certified by FAA or FDA  of course these are expensive 
>
>
>
>
> Sent from Yahoo Mail on Android 
> 
>
> On Fri, Apr 9, 2021 at 8:23 AM, TJF
>  wrote:
>
>
> wal...@edenconceptsllc.com schrieb am Freitag, 9. April 2021 um 14:41:00 
> UTC+2:
>
> I'm looking at some example code and there references to ADC_TSC.  I 
> realize this is a reference to the Touchscreen controller which provides 
> the ADC functionality.  And I suspect this refers to the base memory 
> address of the chip but I cannot find where that is defined in any header 
> files anywhere.  It would help me to follow these examples if I knew where 
> that reference was.
>
>
> Find high-level code (FreeBASIC) in files src/pruio/pruio_adc.[bas|bi] 
> and low level code (assembler) in file src/pruio/pruio_adc.p.
>
>
> Unfortunately, too, the examples are Python and I'm not a Python 
> programmer.I work in C.  So I'm having to dig through this and learn 
> some Python at the same time.  Not a bad thing but time consuming!
>
>
> Python examples are in folder src/python. FreeBASIC examples are in 
> folder src/examples. And C examples are in folder src/c_examples. Find an 
> overview at
>
>
> https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html
>
> 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/04caf3a3-cd8c-449e-9fd7-9ed6df33f99en%40googlegroups.com
>  
> 
> .
>
>

-- 
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/1524641d-541b-42ad-970e-3b1930271f74n%40googlegroups.com.

[beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

Thanks!  I believe you are right and I've already started working with 
this.   I will check out libpruio.   I'm starting to believe it isn't quite 
as difficult as a I thought it might be.  

Maybe you can answer a quick, related question.  

I'm looking at some example code and there references to ADC_TSC.  I 
realize this is a reference to the Touchscreen controller which provides 
the ADC functionality.  And I suspect this refers to the base memory 
address of the chip but I cannot find where that is defined in any header 
files anywhere.  It would help me to follow these examples if I knew where 
that reference was.

Unfortunately, too, the examples are Python and I'm not a Python 
programmer.I work in C.  So I'm having to dig through this and learn 
some Python at the same time.  Not a bad thing but time consuming!

Walter

On Thursday, April 8, 2021 at 6:12:41 PM UTC-4 TJF wrote:

> Hi!
>
> Check out libpruio  for easy and 
> reliable ADC measurements with accurate timing. I guess RB (ring buffer) 
> mode is your way to go.
>
> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6d517e9d-2240-4b70-ae37-06bb3247b822n%40googlegroups.com.

[beagleboard] Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Walter Cromer]

I'm running a BBB Wireless.  The OS version, version.sh output, etc. are 
below.

We're sensor outputs on AIN4 and AIN0 with C using the code below.  The 
intervals between readings is fairly constant at about 350 uS but there is 
periodically, about every 25 readings, a reading interval of between 4000 
and 4800 uS.   Our application can't accept this.  

1) Is there some process the OS is doing periodically to cause this delay 
and can we eliminate it?

2) Would the PRUs solve this problem and is it worth the effort to learn 
and apply them?

Thanks for your insights, advice, and help!

Code is in C...and we run it from the Cloud9 IDE.

 void ReadDetectors(long TimeToRead, int CycleNo)

{





// initialize local variables

char Det1Volts_str[1024][6];

char Det2Volts_str[1024][6];

long elapsed_us;

int index;

index = 0;

struct timeval tv_start; //start time hack

struct timeval tv_now; // current time hack

long total_elapsed_time_us[1024];

long start_secs;

long last_secs;

long last_usecs;



int KeepReading = 1;



FILE* fDet1 = fopen("/sys/bus/iio/devices/iio:device0/in_voltage4_raw", 
"r");  // top sensor, blue wire

FILE* fDet2 = fopen("/sys/bus/iio/devices/iio:device0/in_voltage0_raw", 
"r");  // bottom sensor, purple wire

 

// get time at entry into the routine



gettimeofday(_now,NULL);

start_secs = tv_now.tv_sec;

last_usecs = tv_now.tv_usec;

elapsed_us = 0;

total_elapsed_time_us[index] = 0;

  

   while (KeepReading)

   

{



  // update elapsed time

  

  gettimeofday(_now,NULL);



  if (tv_now.tv_sec >= last_usecs)

  {

  elapsed_us = tv_now.tv_usec - last_usecs;

  }

  else

  {

  elapsed_us = (100 - last_usecs) + tv_now.tv_usec;

  }

   

  total_elapsed_time_us[index] = (tv_now.tv_sec - 
start_secs)*100 + elapsed_us;

  if (total_elapsed_time_us[index] > TimeToRead) KeepReading = 0;// 
read detectors



  fread(_str[index], 5, 1, fDet1);

  fread(_str[index], 5, 1, fDet2);

  

  rewind(fDet1);

  rewind(fDet2);

  index += 1;

  if (index >1024) KeepReading = 0;

}

}

 

debian@beaglebone:/var/lib/cloud9$ uname --a

Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 
UTC 2020 armv7l GNU/Linux

 

debian@beaglebone:/$ sudo opt/scripts/tools/version.sh

git:/opt/scripts/:[b39ec679648a6be8f25f48bd1c9784c1fc5a0c46]

eeprom:[A335BNLTBWA52027BBWG0227]

model:[TI_AM335x_BeagleBone_Black_Wireless]

dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]

bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2019.04-2-g07d5700e21]:[location: dd MBR]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.03-2-gac9cce7c6a]:[location: dd MBR]

UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]

UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]

UBOOT: Loaded Overlay:[BB-ADC-00A0]

UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]

UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]

UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]

UBOOT: Loaded Overlay:[BB-I2C2-RTC-DS3231]

UBOOT: Loaded Overlay:[BB-W1-P9.12-00A2]

kernel:[4.19.94-ti-r42]

nodejs:[v10.15.2]

/boot/uEnv.txt Settings:

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/BB-W1-P9.12-00A0.dtbo]

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]

uboot_overlay_options:[enable_uboot_cape_universal=1]

uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-I2C2-RTC-DS3231.dtbo]

pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]

pkg:[bb-cape-overlays]:[4.14.20200403.0-0rcnee0~buster+20200403]

pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]

pkg:[kmod]:[26-1]

pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]

pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]

groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc 
admin spi iio docker tisdk weston-launch xenomai cloud9ide]

cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]

dmesg | grep remote

[   11.374832] remoteproc remoteproc0: 4a334000.pru is available

[   11.397684] remoteproc remoteproc1: 4a338000.pru is available

[   58.421621] remoteproc remoteproc2: wkup_m3 is available

[   58.879676] remoteproc remoteproc2: powering up wkup_m3

[   58.879705] remoteproc remoteproc2: Booting fw image 
am335x-pm-firmware.elf, size 217168

[   58.879995] remoteproc remoteproc2: remote processor wkup_m3 is now up

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

I have a solution that seems to work for our purposes.   

Thanks for all the suggestions and help.  I am going to keep learning the 
PRUs because I think we'll need them in a more sophisticated version of the 
product.

This is a great community and I appreciate the patience with this neophyte 
to BB.

Here's the C code with some parts eliminated for simplicity.  

// *  ReadDetectors **

 

void ReadDetectors(int TimeToRead)

{

 

// initialize local variables

struct timeval tv_start; //start time

struct timeval tv_now; // current time 

long total_elapsed_time_us;

long start_secs;

long last_secs;

long last_usecs;

long elapsed_us;

 int KeepReading = 1;

gettimeofday(_now,NULL);

start_secs = tv_now.tv_sec;

last_usecs = tv_now.tv_usec;

elapsed_us = 0;

total_elapsed_time_us = 0;

while (KeepReading)

   

{



  // READ SENSORS CODE IS HERE.  REMOVED FOR SIMPLICITY IN THE POST

  

  // update elapsed time

  

  gettimeofday(_now,NULL);



  if (tv_now.tv_sec >= last_usecs)  // this if/else code handles 
the situation where the microsecond value crosses over zero between reads.

  {

  elapsed_us = tv_now.tv_usec - last_usecs;

  }

  else

  {

  elapsed_us = (100 - last_usecs) + tv_now.tv_usec;   

  }

   

  total_elapsed_time_us = (tv_now.tv_sec - start_secs)*100 + 
elapsed_us;   // this code adds microseconds for every second that has 
elapsed since the routine started.  In our case, we won't be in the routine 
more than 5 seconds ever.

  if (total_elapsed_time_us > TimeToRead) KeepReading = 0;

  

}


}


}
On Thursday, February 18, 2021 at 2:36:45 PM UTC-5 Walter Cromer wrote:

> Yes I did and it did not work on my system.   I don't remember why now. 
>
> On Thursday, February 18, 2021 at 1:47:29 PM UTC-5 Dennis Bieber wrote:
>
>> On Thu, 18 Feb 2021 08:27:48 -0800 (PST), in
>> gmane.comp.hardware.beagleboard.user Walter Cromer
>>  wrote:
>>
>> >I think if I could just find how to read the clock on the PRU with C, I 
>> can 
>> >probably take it from here. And of course, it needs to be giving me 
>> >milliseconds. From what I read the main clock functions don't work below 
>> >seconds.
>>
>> Have you even looked at the link I posted some hours ago? Duplicated
>> below.
>>
>> >On Wed, 17 Feb 2021 10:45:49 -0800 (PST), in
>> >gmane.comp.hardware.beagleboard.user Walter Cromer
>> > wrote:
>> >
>> >>You are correct that this application does not need to know the actual 
>> real 
>> >>time but only the relative (elapsed) time since the subroutine began. 
>> I'm 
>> >>familiar with clock_gettime but didn't think it could give me subsecond 
>> >>information. I'll explore it!
>> >>
>> >
>> >https://www.tutorialspoint.com/c_standard_library/c_function_clock.htm
>> >
>> > The worst you may have to handle is the wrap-around in a long-running
>> >program.
>>
>> According to the documentation, that function returns clock TICKS
>> (whatever the tick rate is for the system in question). If you know the
>> CLOCKS_PER_SECOND you should be able to compute the clocks per
>> millisecond...
>>
>> https://linux.die.net/man/3/clock
>>
>> or use
>>
>> https://linux.die.net/man/2/times
>>
>> or better
>>
>> https://linux.die.net/man/2/clock_gettime in which the return structure 
>> is
>> seconds AND NANOSECONDS
>>
>>
>> -- 
>> 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/2230dd99-125e-4d58-a5c5-2faf54e9f2b1n%40googlegroups.com.

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

Yes I did and it did not work on my system.   I don't remember why now. 

On Thursday, February 18, 2021 at 1:47:29 PM UTC-5 Dennis Bieber wrote:

> On Thu, 18 Feb 2021 08:27:48 -0800 (PST), in
> gmane.comp.hardware.beagleboard.user Walter Cromer
>  wrote:
>
> >I think if I could just find how to read the clock on the PRU with C, I 
> can 
> >probably take it from here. And of course, it needs to be giving me 
> >milliseconds. From what I read the main clock functions don't work below 
> >seconds.
>
> Have you even looked at the link I posted some hours ago? Duplicated
> below.
>
> >On Wed, 17 Feb 2021 10:45:49 -0800 (PST), in
> >gmane.comp.hardware.beagleboard.user Walter Cromer
> > wrote:
> >
> >>You are correct that this application does not need to know the actual 
> real 
> >>time but only the relative (elapsed) time since the subroutine began. 
> I'm 
> >>familiar with clock_gettime but didn't think it could give me subsecond 
> >>information. I'll explore it!
> >>
> >
> >https://www.tutorialspoint.com/c_standard_library/c_function_clock.htm
> >
> > The worst you may have to handle is the wrap-around in a long-running
> >program.
>
> According to the documentation, that function returns clock TICKS
> (whatever the tick rate is for the system in question). If you know the
> CLOCKS_PER_SECOND you should be able to compute the clocks per
> millisecond...
>
> https://linux.die.net/man/3/clock
>
> or use
>
> https://linux.die.net/man/2/times
>
> or better
>
> https://linux.die.net/man/2/clock_gettime in which the return structure is
> seconds AND NANOSECONDS
>
>
> -- 
> 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/7daba9f3-4d28-4094-89d5-04226fdb9733n%40googlegroups.com.

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

I'll look into the pthread tutorials.   

So is there no way to just read the clock on the PRU to get elapsed time?

Also,  I've booted my BBB Wireless with the SD card with the OS that you 
recommended and the access point doesn't come up.  It doesn't appear to be 
disabled in uEnv.txt.  Any ideas on this?

Walter

On Thursday, February 18, 2021 at 11:45:52 AM UTC-5 Mark A. Yoder wrote:

> I use *__delay_cycles()* on the PRU to get accurate timing. Each cycle is 
> 5 ns.  
>
> Here [1] is an example of passing data between the PRU and the ARM.
>
> Try googling *pthread tutorial,* there appear to be many examples.
>
> I'm still voting for pthreads.
>
> --Mark
>
> [1] 
> https://markayoder.github.io/PRUCookbook/05blocks/blocks.html#_controlling_neopixels_through_a_kernel_driver
>  
>
> On Thursday, February 18, 2021 at 11:27:48 AM UTC-5 
> wal...@edenconceptsllc.com wrote:
>
>> I think if I could just find how to read the clock on the PRU with C, I 
>> can probably take it from here.   And of course, it needs to be giving me 
>> milliseconds.  From what I read the main clock functions don't work below 
>> seconds.
>>
>>
>> On Thursday, February 18, 2021 at 10:37:59 AM UTC-5 Mark A. Yoder wrote:
>>
>>> Have you tried starting a pthread that sleeps for 20 ms and then it 
>>> stops the read?
>>>
>>> On Thursday, February 18, 2021 at 10:35:04 AM UTC-5 
>>> wal...@edenconceptsllc.com wrote:
>>>
>>>> Mark, 
>>>>
>>>> I use usleep a lot but in this case I don't want to pause.  I want to 
>>>> keep reading the sensors for N milliseconds.   I do pause between reads 
>>>> using usleep(2) to create a 20ms delay between sensor reads.   I 
>>>> started with a routine that essentially counts up the amount of time by 
>>>> estimating how long the sensor read routine takes plus the fixed delay 
>>>> time 
>>>> between sensor reads and accumulating this value in a while loop until it 
>>>> reaches the 'stop value' that is approximately the time the valve needs to 
>>>> stay on.  But this is sketchy and I don't like it.  Lots could go wrong.   
>>>>
>>>> In essence, I'm looking to interrupt the sensor read procedure after N 
>>>> milliseconds pass.   
>>>>
>>>> Walter
>>>>
>>>>
>>>> On Thursday, February 18, 2021 at 10:29:44 AM UTC-5 Mark A. Yoder wrote:
>>>>
>>>>> Walter:
>>>>>   It's good to hear you have the PRUs working.  I still think if all 
>>>>> you need is millisecond timing the PRUs are over kill.
>>>>>
>>>>> In C you can use *usleep()* and pass it the number of microseconds 
>>>>> you want to pause.
>>>>>
>>>>> --Mark
>>>>> On Thursday, February 18, 2021 at 10:00:10 AM UTC-5 
>>>>> wal...@edenconceptsllc.com wrote:
>>>>>
>>>>>> I've gone through the cookbook and it's very helpful. 
>>>>>>
>>>>>> I'm still fuzzy on how to do what I need to do.  
>>>>>>
>>>>>> My main code for controlling the valves, getting user input, etc. is 
>>>>>> in C.  
>>>>>>
>>>>>> I need to call a procedure in C that reads sensors.  I will pass this 
>>>>>> procedure the number of milliseconds it should read the sensors and then 
>>>>>> return to the main program and turn the valves off.   The number of 
>>>>>> milliseconds can, and will likely, change depending on what we are 
>>>>>> processing with these valves.   I get that input at the start of the 
>>>>>> main 
>>>>>> program.
>>>>>>
>>>>>> My thought is that in the procedure that reads the sensors, it will 
>>>>>> grab a start time (doesn't have to be actual time) value from the PRU, 
>>>>>> read 
>>>>>> the sensors, and loop until the current time-start time equals the 
>>>>>> amount 
>>>>>> of time it should read the sensors.  Then it will return to the main 
>>>>>> program.
>>>>>>
>>>>>> I just don't know how to read the PRU's clock to get the time 
>>>>>> values.   I don't think I saw an example in the cookbook for 'branching' 
>>>>>> out from a main program to use the PRUs for this type of processing.  
>>>>>> Just 
>>>

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

I think if I could just find how to read the clock on the PRU with C, I can 
probably take it from here.   And of course, it needs to be giving me 
milliseconds.  From what I read the main clock functions don't work below 
seconds.


On Thursday, February 18, 2021 at 10:37:59 AM UTC-5 Mark A. Yoder wrote:

> Have you tried starting a pthread that sleeps for 20 ms and then it stops 
> the read?
>
> On Thursday, February 18, 2021 at 10:35:04 AM UTC-5 
> wal...@edenconceptsllc.com wrote:
>
>> Mark, 
>>
>> I use usleep a lot but in this case I don't want to pause.  I want to 
>> keep reading the sensors for N milliseconds.   I do pause between reads 
>> using usleep(2) to create a 20ms delay between sensor reads.   I 
>> started with a routine that essentially counts up the amount of time by 
>> estimating how long the sensor read routine takes plus the fixed delay time 
>> between sensor reads and accumulating this value in a while loop until it 
>> reaches the 'stop value' that is approximately the time the valve needs to 
>> stay on.  But this is sketchy and I don't like it.  Lots could go wrong.   
>>
>> In essence, I'm looking to interrupt the sensor read procedure after N 
>> milliseconds pass.   
>>
>> Walter
>>
>>
>> On Thursday, February 18, 2021 at 10:29:44 AM UTC-5 Mark A. Yoder wrote:
>>
>>> Walter:
>>>   It's good to hear you have the PRUs working.  I still think if all you 
>>> need is millisecond timing the PRUs are over kill.
>>>
>>> In C you can use *usleep()* and pass it the number of microseconds you 
>>> want to pause.
>>>
>>> --Mark
>>> On Thursday, February 18, 2021 at 10:00:10 AM UTC-5 
>>> wal...@edenconceptsllc.com wrote:
>>>
>>>> I've gone through the cookbook and it's very helpful. 
>>>>
>>>> I'm still fuzzy on how to do what I need to do.  
>>>>
>>>> My main code for controlling the valves, getting user input, etc. is in 
>>>> C.  
>>>>
>>>> I need to call a procedure in C that reads sensors.  I will pass this 
>>>> procedure the number of milliseconds it should read the sensors and then 
>>>> return to the main program and turn the valves off.   The number of 
>>>> milliseconds can, and will likely, change depending on what we are 
>>>> processing with these valves.   I get that input at the start of the main 
>>>> program.
>>>>
>>>> My thought is that in the procedure that reads the sensors, it will 
>>>> grab a start time (doesn't have to be actual time) value from the PRU, 
>>>> read 
>>>> the sensors, and loop until the current time-start time equals the amount 
>>>> of time it should read the sensors.  Then it will return to the main 
>>>> program.
>>>>
>>>> I just don't know how to read the PRU's clock to get the time values.  
>>>>  I don't think I saw an example in the cookbook for 'branching' out from a 
>>>> main program to use the PRUs for this type of processing.  Just point me 
>>>> in 
>>>> the right direction, please.
>>>>
>>>> Walter
>>>>
>>>>
>>>> On Thursday, February 18, 2021 at 9:27:34 AM UTC-5 Walter Cromer wrote:
>>>>
>>>>> Mark ,
>>>>>
>>>>> It is working with the updated OS.  Thanks so much!   
>>>>>
>>>>> Now I will explore how to get the simple timing that I need using the 
>>>>> PRU.
>>>>>
>>>>> On Thursday, February 18, 2021 at 8:54:10 AM UTC-5 Walter Cromer wrote:
>>>>>
>>>>>> Mark, 
>>>>>>
>>>>>> With the current OS there isn't a /dev/remoteproc even.   
>>>>>>
>>>>>> I'm going to try the updated OS build this morning.  
>>>>>>
>>>>>> Walter
>>>>>>
>>>>>> On Wednesday, February 17, 2021 at 5:34:37 PM UTC-5 Mark A. Yoder 
>>>>>> wrote:
>>>>>>
>>>>>>> I fired up the Beagle at home it the PRU works out of the box.
>>>>>>>
>>>>>>> What do you get running
>>>>>>> *ls /dev/remoteproc*
>>>>>>>
>>>>>>> I get:
>>>>>>> *ls -ls /dev/remoteproc*
>>>>>>> total 0
>>>>>>> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core0 -> 
>>&

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

No. I am not familiar with that, Mark.  I found Strawson's reference to it 
online but it doesn't explain what it is or what it does.   Is there a 
better reference somewhere? Google didn't bring up anything that looked 
useful.


On Thursday, February 18, 2021 at 10:37:59 AM UTC-5 Mark A. Yoder wrote:

> Have you tried starting a pthread that sleeps for 20 ms and then it stops 
> the read?
>
> On Thursday, February 18, 2021 at 10:35:04 AM UTC-5 
> wal...@edenconceptsllc.com wrote:
>
>> Mark, 
>>
>> I use usleep a lot but in this case I don't want to pause.  I want to 
>> keep reading the sensors for N milliseconds.   I do pause between reads 
>> using usleep(2) to create a 20ms delay between sensor reads.   I 
>> started with a routine that essentially counts up the amount of time by 
>> estimating how long the sensor read routine takes plus the fixed delay time 
>> between sensor reads and accumulating this value in a while loop until it 
>> reaches the 'stop value' that is approximately the time the valve needs to 
>> stay on.  But this is sketchy and I don't like it.  Lots could go wrong.   
>>
>> In essence, I'm looking to interrupt the sensor read procedure after N 
>> milliseconds pass.   
>>
>> Walter
>>
>>
>> On Thursday, February 18, 2021 at 10:29:44 AM UTC-5 Mark A. Yoder wrote:
>>
>>> Walter:
>>>   It's good to hear you have the PRUs working.  I still think if all you 
>>> need is millisecond timing the PRUs are over kill.
>>>
>>> In C you can use *usleep()* and pass it the number of microseconds you 
>>> want to pause.
>>>
>>> --Mark
>>> On Thursday, February 18, 2021 at 10:00:10 AM UTC-5 
>>> wal...@edenconceptsllc.com wrote:
>>>
>>>> I've gone through the cookbook and it's very helpful. 
>>>>
>>>> I'm still fuzzy on how to do what I need to do.  
>>>>
>>>> My main code for controlling the valves, getting user input, etc. is in 
>>>> C.  
>>>>
>>>> I need to call a procedure in C that reads sensors.  I will pass this 
>>>> procedure the number of milliseconds it should read the sensors and then 
>>>> return to the main program and turn the valves off.   The number of 
>>>> milliseconds can, and will likely, change depending on what we are 
>>>> processing with these valves.   I get that input at the start of the main 
>>>> program.
>>>>
>>>> My thought is that in the procedure that reads the sensors, it will 
>>>> grab a start time (doesn't have to be actual time) value from the PRU, 
>>>> read 
>>>> the sensors, and loop until the current time-start time equals the amount 
>>>> of time it should read the sensors.  Then it will return to the main 
>>>> program.
>>>>
>>>> I just don't know how to read the PRU's clock to get the time values.  
>>>>  I don't think I saw an example in the cookbook for 'branching' out from a 
>>>> main program to use the PRUs for this type of processing.  Just point me 
>>>> in 
>>>> the right direction, please.
>>>>
>>>> Walter
>>>>
>>>>
>>>> On Thursday, February 18, 2021 at 9:27:34 AM UTC-5 Walter Cromer wrote:
>>>>
>>>>> Mark ,
>>>>>
>>>>> It is working with the updated OS.  Thanks so much!   
>>>>>
>>>>> Now I will explore how to get the simple timing that I need using the 
>>>>> PRU.
>>>>>
>>>>> On Thursday, February 18, 2021 at 8:54:10 AM UTC-5 Walter Cromer wrote:
>>>>>
>>>>>> Mark, 
>>>>>>
>>>>>> With the current OS there isn't a /dev/remoteproc even.   
>>>>>>
>>>>>> I'm going to try the updated OS build this morning.  
>>>>>>
>>>>>> Walter
>>>>>>
>>>>>> On Wednesday, February 17, 2021 at 5:34:37 PM UTC-5 Mark A. Yoder 
>>>>>> wrote:
>>>>>>
>>>>>>> I fired up the Beagle at home it the PRU works out of the box.
>>>>>>>
>>>>>>> What do you get running
>>>>>>> *ls /dev/remoteproc*
>>>>>>>
>>>>>>> I get:
>>>>>>> *ls -ls /dev/remoteproc*
>>>>>>> total 0
>>>>>>> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core0 -> 
>>&

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

Mark, 

I use usleep a lot but in this case I don't want to pause.  I want to keep 
reading the sensors for N milliseconds.   I do pause between reads using 
usleep(2) to create a 20ms delay between sensor reads.   I started with 
a routine that essentially counts up the amount of time by estimating how 
long the sensor read routine takes plus the fixed delay time between sensor 
reads and accumulating this value in a while loop until it reaches the 
'stop value' that is approximately the time the valve needs to stay on.  
But this is sketchy and I don't like it.  Lots could go wrong.   

In essence, I'm looking to interrupt the sensor read procedure after N 
milliseconds pass.   

Walter


On Thursday, February 18, 2021 at 10:29:44 AM UTC-5 Mark A. Yoder wrote:

> Walter:
>   It's good to hear you have the PRUs working.  I still think if all you 
> need is millisecond timing the PRUs are over kill.
>
> In C you can use *usleep()* and pass it the number of microseconds you 
> want to pause.
>
> --Mark
> On Thursday, February 18, 2021 at 10:00:10 AM UTC-5 
> wal...@edenconceptsllc.com wrote:
>
>> I've gone through the cookbook and it's very helpful. 
>>
>> I'm still fuzzy on how to do what I need to do.  
>>
>> My main code for controlling the valves, getting user input, etc. is in 
>> C.  
>>
>> I need to call a procedure in C that reads sensors.  I will pass this 
>> procedure the number of milliseconds it should read the sensors and then 
>> return to the main program and turn the valves off.   The number of 
>> milliseconds can, and will likely, change depending on what we are 
>> processing with these valves.   I get that input at the start of the main 
>> program.
>>
>> My thought is that in the procedure that reads the sensors, it will grab 
>> a start time (doesn't have to be actual time) value from the PRU, read the 
>> sensors, and loop until the current time-start time equals the amount of 
>> time it should read the sensors.  Then it will return to the main program.
>>
>> I just don't know how to read the PRU's clock to get the time values.   I 
>> don't think I saw an example in the cookbook for 'branching' out from a 
>> main program to use the PRUs for this type of processing.  Just point me in 
>> the right direction, please.
>>
>> Walter
>>
>>
>> On Thursday, February 18, 2021 at 9:27:34 AM UTC-5 Walter Cromer wrote:
>>
>>> Mark ,
>>>
>>> It is working with the updated OS.  Thanks so much!   
>>>
>>> Now I will explore how to get the simple timing that I need using the 
>>> PRU.
>>>
>>> On Thursday, February 18, 2021 at 8:54:10 AM UTC-5 Walter Cromer wrote:
>>>
>>>> Mark, 
>>>>
>>>> With the current OS there isn't a /dev/remoteproc even.   
>>>>
>>>> I'm going to try the updated OS build this morning.  
>>>>
>>>> Walter
>>>>
>>>> On Wednesday, February 17, 2021 at 5:34:37 PM UTC-5 Mark A. Yoder wrote:
>>>>
>>>>> I fired up the Beagle at home it the PRU works out of the box.
>>>>>
>>>>> What do you get running
>>>>> *ls /dev/remoteproc*
>>>>>
>>>>> I get:
>>>>> *ls -ls /dev/remoteproc*
>>>>> total 0
>>>>> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core0 -> 
>>>>> /sys/class/remoteproc/remoteproc1
>>>>> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core1 -> 
>>>>> /sys/class/remoteproc/remoteproc2
>>>>>
>>>>> If you are missing pruss-core0 and pruss-core1 you could try adding 
>>>>> the links by hand and see what happens.
>>>>>
>>>>> *cd /dev/remoteproc*
>>>>>
>>>>> *sudo ln -s /sys/class/remoteproc/remoteproc1 pruss-core0*
>>>>> *sudo ln -s /sys/class/remoteproc/remoteproc2 pruss-core1*
>>>>> On Wednesday, February 17, 2021 at 3:56:21 PM UTC-5 
>>>>> wal...@edenconceptsllc.com wrote:
>>>>>
>>>>>> I'll get this one onto an SD card and give it a try.   If I can just 
>>>>>> get this configured I think I can make quick work of this problem!  
>>>>>>
>>>>>> On Wednesday, February 17, 2021 at 3:47:04 PM UTC-5 Mark A. Yoder 
>>>>>> wrote:
>>>>>>
>>>>>>> Good point, it should work  I'm running a newer test image[1], 
>>>>>>> but I took my Beagle home so I can't do a quick check on it 

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

I've gone through the cookbook and it's very helpful. 

I'm still fuzzy on how to do what I need to do.  

My main code for controlling the valves, getting user input, etc. is in C.  

I need to call a procedure in C that reads sensors.  I will pass this 
procedure the number of milliseconds it should read the sensors and then 
return to the main program and turn the valves off.   The number of 
milliseconds can, and will likely, change depending on what we are 
processing with these valves.   I get that input at the start of the main 
program.

My thought is that in the procedure that reads the sensors, it will grab a 
start time (doesn't have to be actual time) value from the PRU, read the 
sensors, and loop until the current time-start time equals the amount of 
time it should read the sensors.  Then it will return to the main program.

I just don't know how to read the PRU's clock to get the time values.   I 
don't think I saw an example in the cookbook for 'branching' out from a 
main program to use the PRUs for this type of processing.  Just point me in 
the right direction, please.

Walter


On Thursday, February 18, 2021 at 9:27:34 AM UTC-5 Walter Cromer wrote:

> Mark ,
>
> It is working with the updated OS.  Thanks so much!   
>
> Now I will explore how to get the simple timing that I need using the PRU.
>
> On Thursday, February 18, 2021 at 8:54:10 AM UTC-5 Walter Cromer wrote:
>
>> Mark, 
>>
>> With the current OS there isn't a /dev/remoteproc even.   
>>
>> I'm going to try the updated OS build this morning.  
>>
>> Walter
>>
>> On Wednesday, February 17, 2021 at 5:34:37 PM UTC-5 Mark A. Yoder wrote:
>>
>>> I fired up the Beagle at home it the PRU works out of the box.
>>>
>>> What do you get running
>>> *ls /dev/remoteproc*
>>>
>>> I get:
>>> *ls -ls /dev/remoteproc*
>>> total 0
>>> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core0 -> 
>>> /sys/class/remoteproc/remoteproc1
>>> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core1 -> 
>>> /sys/class/remoteproc/remoteproc2
>>>
>>> If you are missing pruss-core0 and pruss-core1 you could try adding the 
>>> links by hand and see what happens.
>>>
>>> *cd /dev/remoteproc*
>>>
>>> *sudo ln -s /sys/class/remoteproc/remoteproc1 pruss-core0*
>>> *sudo ln -s /sys/class/remoteproc/remoteproc2 pruss-core1*
>>> On Wednesday, February 17, 2021 at 3:56:21 PM UTC-5 
>>> wal...@edenconceptsllc.com wrote:
>>>
>>>> I'll get this one onto an SD card and give it a try.   If I can just 
>>>> get this configured I think I can make quick work of this problem!  
>>>>
>>>> On Wednesday, February 17, 2021 at 3:47:04 PM UTC-5 Mark A. Yoder wrote:
>>>>
>>>>> Good point, it should work  I'm running a newer test image[1], but 
>>>>> I took my Beagle home so I can't do a quick check on it until later.
>>>>>
>>>>>
>>>>> --Mark
>>>>> [1]
>>>>> https://rcn-ee.com/rootfs/bb.org/testing/2021-02-15/buster-iot/bone-debian-10.8-iot-armhf-2021-02-15-4gb.img.xz
>>>>>  
>>>>>
>>>>> On Wednesday, February 17, 2021 at 2:46:35 PM UTC-5 
>>>>> wal...@edenconceptsllc.com wrote:
>>>>>
>>>>>> I asked because the ones on the page @ the link are older than the 
>>>>>> one I have installed.
>>>>>>
>>>>>>
>>>>>> On Wednesday, February 17, 2021 at 2:30:58 PM UTC-5 Mark A. Yoder 
>>>>>> wrote:
>>>>>>
>>>>>>> On newer versions of the SD card image /var/lib/cloud9 is a git repo 
>>>>>>> which you can do a git pull to update.  Your version is too old.
>>>>>>>
>>>>>>> Follow the instructions at: 
>>>>>>> https://markayoder.github.io/PRUCookbook/02start/start.html#_installing_the_latest_os_on_your_bone
>>>>>>>  
>>>>>>> to download and install an updated version of the SD card image.
>>>>>>>
>>>>>>> --Mark
>>>>>>>
>>>>>>> On Wednesday, February 17, 2021 at 2:25:40 PM UTC-5 
>>>>>>> wal...@edenconceptsllc.com wrote:
>>>>>>>
>>>>>>>> Mark, 
>>>>>>>>
>>>>>>>> git pull on /var/lib/cloud9 fails with 'fatal: Not a git repository 
>>>>>>>> (or any of the parent directories): .git 
>

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

Mark ,

It is working with the updated OS.  Thanks so much!   

Now I will explore how to get the simple timing that I need using the PRU.

On Thursday, February 18, 2021 at 8:54:10 AM UTC-5 Walter Cromer wrote:

> Mark, 
>
> With the current OS there isn't a /dev/remoteproc even.   
>
> I'm going to try the updated OS build this morning.  
>
> Walter
>
> On Wednesday, February 17, 2021 at 5:34:37 PM UTC-5 Mark A. Yoder wrote:
>
>> I fired up the Beagle at home it the PRU works out of the box.
>>
>> What do you get running
>> *ls /dev/remoteproc*
>>
>> I get:
>> *ls -ls /dev/remoteproc*
>> total 0
>> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core0 -> 
>> /sys/class/remoteproc/remoteproc1
>> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core1 -> 
>> /sys/class/remoteproc/remoteproc2
>>
>> If you are missing pruss-core0 and pruss-core1 you could try adding the 
>> links by hand and see what happens.
>>
>> *cd /dev/remoteproc*
>>
>> *sudo ln -s /sys/class/remoteproc/remoteproc1 pruss-core0*
>> *sudo ln -s /sys/class/remoteproc/remoteproc2 pruss-core1*
>> On Wednesday, February 17, 2021 at 3:56:21 PM UTC-5 
>> wal...@edenconceptsllc.com wrote:
>>
>>> I'll get this one onto an SD card and give it a try.   If I can just get 
>>> this configured I think I can make quick work of this problem!  
>>>
>>> On Wednesday, February 17, 2021 at 3:47:04 PM UTC-5 Mark A. Yoder wrote:
>>>
>>>> Good point, it should work  I'm running a newer test image[1], but 
>>>> I took my Beagle home so I can't do a quick check on it until later.
>>>>
>>>>
>>>> --Mark
>>>> [1]
>>>> https://rcn-ee.com/rootfs/bb.org/testing/2021-02-15/buster-iot/bone-debian-10.8-iot-armhf-2021-02-15-4gb.img.xz
>>>>  
>>>>
>>>> On Wednesday, February 17, 2021 at 2:46:35 PM UTC-5 
>>>> wal...@edenconceptsllc.com wrote:
>>>>
>>>>> I asked because the ones on the page @ the link are older than the one 
>>>>> I have installed.
>>>>>
>>>>>
>>>>> On Wednesday, February 17, 2021 at 2:30:58 PM UTC-5 Mark A. Yoder 
>>>>> wrote:
>>>>>
>>>>>> On newer versions of the SD card image /var/lib/cloud9 is a git repo 
>>>>>> which you can do a git pull to update.  Your version is too old.
>>>>>>
>>>>>> Follow the instructions at: 
>>>>>> https://markayoder.github.io/PRUCookbook/02start/start.html#_installing_the_latest_os_on_your_bone
>>>>>>  
>>>>>> to download and install an updated version of the SD card image.
>>>>>>
>>>>>> --Mark
>>>>>>
>>>>>> On Wednesday, February 17, 2021 at 2:25:40 PM UTC-5 
>>>>>> wal...@edenconceptsllc.com wrote:
>>>>>>
>>>>>>> Mark, 
>>>>>>>
>>>>>>> git pull on /var/lib/cloud9 fails with 'fatal: Not a git repository 
>>>>>>> (or any of the parent directories): .git 
>>>>>>>
>>>>>>> I'm such a neophyte on git.  What do I need to do?
>>>>>>>
>>>>>>> And, what do you mean by updating to a new version of the SD card? 
>>>>>>> The OS is booting from the SD card and the version.sh information 
>>>>>>> posted 
>>>>>>> earlier is based on that.
>>>>>>>
>>>>>>>
>>>>>>> On Wednesday, February 17, 2021 at 2:02:55 PM UTC-5 Mark A. Yoder 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I suggest updating to a new version of the SD card.  It looks like 
>>>>>>>> the PRUs are getting started at boot time, but the path isn't setup 
>>>>>>>> right. 
>>>>>>>> I think we setup some links so the path* 
>>>>>>>> /dev/remoteproc/pruss-core0/state  
>>>>>>>> *points to the right place.
>>>>>>>>
>>>>>>>> You could also try:
>>>>>>>> *cd */var/lib/cloud9
>>>>>>>> *git* pull
>>>>>>>> to update cloud9 folders.
>>>>>>>>
>>>>>>>> --Mark
>>>>>>>>
>>>>>>>> On Wednesday, February 17, 2021 at 1:53:35 PM UT

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

Mark, 

With the current OS there isn't a /dev/remoteproc even.   

I'm going to try the updated OS build this morning.  

Walter

On Wednesday, February 17, 2021 at 5:34:37 PM UTC-5 Mark A. Yoder wrote:

> I fired up the Beagle at home it the PRU works out of the box.
>
> What do you get running
> *ls /dev/remoteproc*
>
> I get:
> *ls -ls /dev/remoteproc*
> total 0
> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core0 -> 
> /sys/class/remoteproc/remoteproc1
> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core1 -> 
> /sys/class/remoteproc/remoteproc2
>
> If you are missing pruss-core0 and pruss-core1 you could try adding the 
> links by hand and see what happens.
>
> *cd /dev/remoteproc*
>
> *sudo ln -s /sys/class/remoteproc/remoteproc1 pruss-core0*
> *sudo ln -s /sys/class/remoteproc/remoteproc2 pruss-core1*
> On Wednesday, February 17, 2021 at 3:56:21 PM UTC-5 
> wal...@edenconceptsllc.com wrote:
>
>> I'll get this one onto an SD card and give it a try.   If I can just get 
>> this configured I think I can make quick work of this problem!  
>>
>> On Wednesday, February 17, 2021 at 3:47:04 PM UTC-5 Mark A. Yoder wrote:
>>
>>> Good point, it should work  I'm running a newer test image[1], but I 
>>> took my Beagle home so I can't do a quick check on it until later.
>>>
>>>
>>> --Mark
>>> [1]
>>> https://rcn-ee.com/rootfs/bb.org/testing/2021-02-15/buster-iot/bone-debian-10.8-iot-armhf-2021-02-15-4gb.img.xz
>>>  
>>>
>>> On Wednesday, February 17, 2021 at 2:46:35 PM UTC-5 
>>> wal...@edenconceptsllc.com wrote:
>>>
 I asked because the ones on the page @ the link are older than the one 
 I have installed.


 On Wednesday, February 17, 2021 at 2:30:58 PM UTC-5 Mark A. Yoder wrote:

> On newer versions of the SD card image /var/lib/cloud9 is a git repo 
> which you can do a git pull to update.  Your version is too old.
>
> Follow the instructions at: 
> https://markayoder.github.io/PRUCookbook/02start/start.html#_installing_the_latest_os_on_your_bone
>  
> to download and install an updated version of the SD card image.
>
> --Mark
>
> On Wednesday, February 17, 2021 at 2:25:40 PM UTC-5 
> wal...@edenconceptsllc.com wrote:
>
>> Mark, 
>>
>> git pull on /var/lib/cloud9 fails with 'fatal: Not a git repository 
>> (or any of the parent directories): .git 
>>
>> I'm such a neophyte on git.  What do I need to do?
>>
>> And, what do you mean by updating to a new version of the SD card? 
>> The OS is booting from the SD card and the version.sh information posted 
>> earlier is based on that.
>>
>>
>> On Wednesday, February 17, 2021 at 2:02:55 PM UTC-5 Mark A. Yoder 
>> wrote:
>>
>>> I suggest updating to a new version of the SD card.  It looks like 
>>> the PRUs are getting started at boot time, but the path isn't setup 
>>> right. 
>>> I think we setup some links so the path* 
>>> /dev/remoteproc/pruss-core0/state  
>>> *points to the right place.
>>>
>>> You could also try:
>>> *cd */var/lib/cloud9
>>> *git* pull
>>> to update cloud9 folders.
>>>
>>> --Mark
>>>
>>> On Wednesday, February 17, 2021 at 1:53:35 PM UTC-5 
>>> wal...@edenconceptsllc.com wrote:
>>>
 Mark, 

 I got the latest PRUCookbook downloaded and when trying to make the 
 hello.pru0.c program in 1.6, I got this error.  

 *debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/02start/code$ 
 make TARGET=hello.pru0*
 */var/lib/cloud9/common/Makefile:29: 
 MODEL=TI_AM335x_BeagleBone_Black,TARGET=hello.pru0*
 *-Stopping PRU 0*
 */bin/sh: 1: cannot create /dev/remoteproc/pruss-core0/state: 
 Directory nonexistent*
 *Cannot stop 0*
 *CC  hello.pru0.c*
 *"/var/lib/cloud9/common/prugpio.h", line 53: warning #1181-D: 
 #warning directive: "Found am335x"*
 *LD  /tmp/cloud9-examples/hello.pru0.o*
 *-   copying firmware file /tmp/cloud9-examples/hello.pru0.out 
 to /lib/firmware/am335x-pru0-fw*
 *cp: cannot create regular file '/lib/firmware/am335x-pru0-fw': 
 Permission denied*
 */var/lib/cloud9/common/Makefile:180: recipe for target 'install' 
 failed*
 *make: *** [install] Error 1*
 *rm /tmp/cloud9-examples/hello.pru0.o*

  Initially, I did not have a folder called /var/lib/cloud9/common.  
 To remedy this I copied the contents of 
 /var/lib/cloud9/PRUCookbook/docs/common to /var/lib/cloud9/common.  
 Maybe 
 this created a problem?Nevertheless,  I found some other discussions 
 that 
 suggested updating the scripts and kernels from 
 beagleboard.org/upgrade which I did.  I am now running...

 Linux beaglebone 4.14.108-ti-r137 #1stretch SMP PREEMPT Tue Aug 

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

I'll get this one onto an SD card and give it a try.   If I can just get 
this configured I think I can make quick work of this problem!  

On Wednesday, February 17, 2021 at 3:47:04 PM UTC-5 Mark A. Yoder wrote:

> Good point, it should work  I'm running a newer test image[1], but I 
> took my Beagle home so I can't do a quick check on it until later.
>
>
> --Mark
> [1]
> https://rcn-ee.com/rootfs/bb.org/testing/2021-02-15/buster-iot/bone-debian-10.8-iot-armhf-2021-02-15-4gb.img.xz
>  
>
> On Wednesday, February 17, 2021 at 2:46:35 PM UTC-5 
> wal...@edenconceptsllc.com wrote:
>
>> I asked because the ones on the page @ the link are older than the one I 
>> have installed.
>>
>>
>> On Wednesday, February 17, 2021 at 2:30:58 PM UTC-5 Mark A. Yoder wrote:
>>
>>> On newer versions of the SD card image /var/lib/cloud9 is a git repo 
>>> which you can do a git pull to update.  Your version is too old.
>>>
>>> Follow the instructions at: 
>>> https://markayoder.github.io/PRUCookbook/02start/start.html#_installing_the_latest_os_on_your_bone
>>>  
>>> to download and install an updated version of the SD card image.
>>>
>>> --Mark
>>>
>>> On Wednesday, February 17, 2021 at 2:25:40 PM UTC-5 
>>> wal...@edenconceptsllc.com wrote:
>>>
 Mark, 

 git pull on /var/lib/cloud9 fails with 'fatal: Not a git repository (or 
 any of the parent directories): .git 

 I'm such a neophyte on git.  What do I need to do?

 And, what do you mean by updating to a new version of the SD card? The 
 OS is booting from the SD card and the version.sh information posted 
 earlier is based on that.


 On Wednesday, February 17, 2021 at 2:02:55 PM UTC-5 Mark A. Yoder wrote:

> I suggest updating to a new version of the SD card.  It looks like the 
> PRUs are getting started at boot time, but the path isn't setup right. I 
> think we setup some links so the path* /dev/remoteproc/pruss-core0/state  
> *points to the right place.
>
> You could also try:
> *cd */var/lib/cloud9
> *git* pull
> to update cloud9 folders.
>
> --Mark
>
> On Wednesday, February 17, 2021 at 1:53:35 PM UTC-5 
> wal...@edenconceptsllc.com wrote:
>
>> Mark, 
>>
>> I got the latest PRUCookbook downloaded and when trying to make the 
>> hello.pru0.c program in 1.6, I got this error.  
>>
>> *debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/02start/code$ 
>> make TARGET=hello.pru0*
>> */var/lib/cloud9/common/Makefile:29: 
>> MODEL=TI_AM335x_BeagleBone_Black,TARGET=hello.pru0*
>> *-Stopping PRU 0*
>> */bin/sh: 1: cannot create /dev/remoteproc/pruss-core0/state: 
>> Directory nonexistent*
>> *Cannot stop 0*
>> *CC  hello.pru0.c*
>> *"/var/lib/cloud9/common/prugpio.h", line 53: warning #1181-D: 
>> #warning directive: "Found am335x"*
>> *LD  /tmp/cloud9-examples/hello.pru0.o*
>> *-   copying firmware file /tmp/cloud9-examples/hello.pru0.out to 
>> /lib/firmware/am335x-pru0-fw*
>> *cp: cannot create regular file '/lib/firmware/am335x-pru0-fw': 
>> Permission denied*
>> */var/lib/cloud9/common/Makefile:180: recipe for target 'install' 
>> failed*
>> *make: *** [install] Error 1*
>> *rm /tmp/cloud9-examples/hello.pru0.o*
>>
>>  Initially, I did not have a folder called /var/lib/cloud9/common.  
>> To remedy this I copied the contents of 
>> /var/lib/cloud9/PRUCookbook/docs/common to /var/lib/cloud9/common.  
>> Maybe 
>> this created a problem?Nevertheless,  I found some other discussions 
>> that 
>> suggested updating the scripts and kernels from 
>> beagleboard.org/upgrade which I did.  I am now running...
>>
>> Linux beaglebone 4.14.108-ti-r137 #1stretch SMP PREEMPT Tue Aug 25 
>> 01:48:39 UTC 2020 armv7l GNU/Linux
>>
>> And the output of version.sh is 
>>
>> *debian@beaglebone:/$ sudo opt/scripts/tools/version.sh*
>> *[sudo] password for debian:*
>> *git:/opt/scripts/:[e4e4854ef8ff9ada5c85553376043ee7679167ca]*
>> *eeprom:[A335BNLT00C04417BBBK1847]*
>> *model:[TI_AM335x_BeagleBone_Black]*
>> *dogtag:[BeagleBoard.org Debian Image 2018-10-07]*
>> *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 
>> 2018.09-2-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)]:[location: dd 
>> MBR]*
>> *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>> 2018.09-2-g0b54a51eee]:[location: dd MBR]*
>> *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 
>> 2018.03-2-gac9cce7c6a (Apr 05 2018 - 13:07:46 -0500)]:[location: dd 
>> MBR]*
>> *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
>> 2018.03-2-gac9cce7c6a]:[location: dd MBR]*
>> *UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]*
>> *kernel:[4.14.108-ti-r137]*
>> *nodejs:[v6.14.4]*
>> */boot/uEnv.txt Settings:*
>> 

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

I asked because the ones on the page @ the link are older than the one I 
have installed.


On Wednesday, February 17, 2021 at 2:30:58 PM UTC-5 Mark A. Yoder wrote:

> On newer versions of the SD card image /var/lib/cloud9 is a git repo which 
> you can do a git pull to update.  Your version is too old.
>
> Follow the instructions at: 
> https://markayoder.github.io/PRUCookbook/02start/start.html#_installing_the_latest_os_on_your_bone
>  
> to download and install an updated version of the SD card image.
>
> --Mark
>
> On Wednesday, February 17, 2021 at 2:25:40 PM UTC-5 
> wal...@edenconceptsllc.com wrote:
>
>> Mark, 
>>
>> git pull on /var/lib/cloud9 fails with 'fatal: Not a git repository (or 
>> any of the parent directories): .git 
>>
>> I'm such a neophyte on git.  What do I need to do?
>>
>> And, what do you mean by updating to a new version of the SD card? The OS 
>> is booting from the SD card and the version.sh information posted earlier 
>> is based on that.
>>
>>
>> On Wednesday, February 17, 2021 at 2:02:55 PM UTC-5 Mark A. Yoder wrote:
>>
>>> I suggest updating to a new version of the SD card.  It looks like the 
>>> PRUs are getting started at boot time, but the path isn't setup right. I 
>>> think we setup some links so the path* /dev/remoteproc/pruss-core0/state  
>>> *points to the right place.
>>>
>>> You could also try:
>>> *cd */var/lib/cloud9
>>> *git* pull
>>> to update cloud9 folders.
>>>
>>> --Mark
>>>
>>> On Wednesday, February 17, 2021 at 1:53:35 PM UTC-5 
>>> wal...@edenconceptsllc.com wrote:
>>>
 Mark, 

 I got the latest PRUCookbook downloaded and when trying to make the 
 hello.pru0.c program in 1.6, I got this error.  

 *debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/02start/code$ make 
 TARGET=hello.pru0*
 */var/lib/cloud9/common/Makefile:29: 
 MODEL=TI_AM335x_BeagleBone_Black,TARGET=hello.pru0*
 *-Stopping PRU 0*
 */bin/sh: 1: cannot create /dev/remoteproc/pruss-core0/state: Directory 
 nonexistent*
 *Cannot stop 0*
 *CC  hello.pru0.c*
 *"/var/lib/cloud9/common/prugpio.h", line 53: warning #1181-D: #warning 
 directive: "Found am335x"*
 *LD  /tmp/cloud9-examples/hello.pru0.o*
 *-   copying firmware file /tmp/cloud9-examples/hello.pru0.out to 
 /lib/firmware/am335x-pru0-fw*
 *cp: cannot create regular file '/lib/firmware/am335x-pru0-fw': 
 Permission denied*
 */var/lib/cloud9/common/Makefile:180: recipe for target 'install' 
 failed*
 *make: *** [install] Error 1*
 *rm /tmp/cloud9-examples/hello.pru0.o*

  Initially, I did not have a folder called /var/lib/cloud9/common.  To 
 remedy this I copied the contents of 
 /var/lib/cloud9/PRUCookbook/docs/common to /var/lib/cloud9/common.  Maybe 
 this created a problem?Nevertheless,  I found some other discussions that 
 suggested updating the scripts and kernels from beagleboard.org/upgrade 
 which I did.  I am now running...

 Linux beaglebone 4.14.108-ti-r137 #1stretch SMP PREEMPT Tue Aug 25 
 01:48:39 UTC 2020 armv7l GNU/Linux

 And the output of version.sh is 

 *debian@beaglebone:/$ sudo opt/scripts/tools/version.sh*
 *[sudo] password for debian:*
 *git:/opt/scripts/:[e4e4854ef8ff9ada5c85553376043ee7679167ca]*
 *eeprom:[A335BNLT00C04417BBBK1847]*
 *model:[TI_AM335x_BeagleBone_Black]*
 *dogtag:[BeagleBoard.org Debian Image 2018-10-07]*
 *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 
 2018.09-2-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)]:[location: dd 
 MBR]*
 *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
 2018.09-2-g0b54a51eee]:[location: dd MBR]*
 *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 
 2018.03-2-gac9cce7c6a (Apr 05 2018 - 13:07:46 -0500)]:[location: dd 
 MBR]*
 *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
 2018.03-2-gac9cce7c6a]:[location: dd MBR]*
 *UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]*
 *kernel:[4.14.108-ti-r137]*
 *nodejs:[v6.14.4]*
 */boot/uEnv.txt Settings:*
 *uboot_overlay_options:[enable_uboot_overlays=1]*

 *uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/BB-W1-P9.12-00A0.dtbo]*
 *uboot_overlay_options:[disable_uboot_overlay_video=1]*

 *uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]*
 *uboot_overlay_options:[enable_uboot_cape_universal=1]*
 *pkg check: to individually upgrade run: [sudo apt install 
 --only-upgrade ]*
 *pkg:[bb-cape-overlays]:[4.4.20180928.0-0rcnee0~stretch+20180928]*
 *pkg:[bb-customizations]:[1.20180815-0rcnee0~stretch+20180815]*
 *WARNING:pkg:[bb-usb-gadgets]:[NOT_INSTALLED]*
 *pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]*
 *pkg:[kmod]:[23-2rcnee1~stretch+20171005]*
 

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

So you are saying that this version is too old?

Linux beaglebone 4.14.108-ti-r137 #1stretch SMP PREEMPT *Tue Aug 25 
01:48:39 UTC 2020* armv7l GNU/Linux



On Wednesday, February 17, 2021 at 2:30:58 PM UTC-5 Mark A. Yoder wrote:

> On newer versions of the SD card image /var/lib/cloud9 is a git repo which 
> you can do a git pull to update.  Your version is too old.
>
> Follow the instructions at: 
> https://markayoder.github.io/PRUCookbook/02start/start.html#_installing_the_latest_os_on_your_bone
>  
> to download and install an updated version of the SD card image.
>
> --Mark
>
> On Wednesday, February 17, 2021 at 2:25:40 PM UTC-5 
> wal...@edenconceptsllc.com wrote:
>
>> Mark, 
>>
>> git pull on /var/lib/cloud9 fails with 'fatal: Not a git repository (or 
>> any of the parent directories): .git 
>>
>> I'm such a neophyte on git.  What do I need to do?
>>
>> And, what do you mean by updating to a new version of the SD card? The OS 
>> is booting from the SD card and the version.sh information posted earlier 
>> is based on that.
>>
>>
>> On Wednesday, February 17, 2021 at 2:02:55 PM UTC-5 Mark A. Yoder wrote:
>>
>>> I suggest updating to a new version of the SD card.  It looks like the 
>>> PRUs are getting started at boot time, but the path isn't setup right. I 
>>> think we setup some links so the path* /dev/remoteproc/pruss-core0/state  
>>> *points to the right place.
>>>
>>> You could also try:
>>> *cd */var/lib/cloud9
>>> *git* pull
>>> to update cloud9 folders.
>>>
>>> --Mark
>>>
>>> On Wednesday, February 17, 2021 at 1:53:35 PM UTC-5 
>>> wal...@edenconceptsllc.com wrote:
>>>
 Mark, 

 I got the latest PRUCookbook downloaded and when trying to make the 
 hello.pru0.c program in 1.6, I got this error.  

 *debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/02start/code$ make 
 TARGET=hello.pru0*
 */var/lib/cloud9/common/Makefile:29: 
 MODEL=TI_AM335x_BeagleBone_Black,TARGET=hello.pru0*
 *-Stopping PRU 0*
 */bin/sh: 1: cannot create /dev/remoteproc/pruss-core0/state: Directory 
 nonexistent*
 *Cannot stop 0*
 *CC  hello.pru0.c*
 *"/var/lib/cloud9/common/prugpio.h", line 53: warning #1181-D: #warning 
 directive: "Found am335x"*
 *LD  /tmp/cloud9-examples/hello.pru0.o*
 *-   copying firmware file /tmp/cloud9-examples/hello.pru0.out to 
 /lib/firmware/am335x-pru0-fw*
 *cp: cannot create regular file '/lib/firmware/am335x-pru0-fw': 
 Permission denied*
 */var/lib/cloud9/common/Makefile:180: recipe for target 'install' 
 failed*
 *make: *** [install] Error 1*
 *rm /tmp/cloud9-examples/hello.pru0.o*

  Initially, I did not have a folder called /var/lib/cloud9/common.  To 
 remedy this I copied the contents of 
 /var/lib/cloud9/PRUCookbook/docs/common to /var/lib/cloud9/common.  Maybe 
 this created a problem?Nevertheless,  I found some other discussions that 
 suggested updating the scripts and kernels from beagleboard.org/upgrade 
 which I did.  I am now running...

 Linux beaglebone 4.14.108-ti-r137 #1stretch SMP PREEMPT Tue Aug 25 
 01:48:39 UTC 2020 armv7l GNU/Linux

 And the output of version.sh is 

 *debian@beaglebone:/$ sudo opt/scripts/tools/version.sh*
 *[sudo] password for debian:*
 *git:/opt/scripts/:[e4e4854ef8ff9ada5c85553376043ee7679167ca]*
 *eeprom:[A335BNLT00C04417BBBK1847]*
 *model:[TI_AM335x_BeagleBone_Black]*
 *dogtag:[BeagleBoard.org Debian Image 2018-10-07]*
 *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 
 2018.09-2-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)]:[location: dd 
 MBR]*
 *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
 2018.09-2-g0b54a51eee]:[location: dd MBR]*
 *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 
 2018.03-2-gac9cce7c6a (Apr 05 2018 - 13:07:46 -0500)]:[location: dd 
 MBR]*
 *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
 2018.03-2-gac9cce7c6a]:[location: dd MBR]*
 *UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]*
 *kernel:[4.14.108-ti-r137]*
 *nodejs:[v6.14.4]*
 */boot/uEnv.txt Settings:*
 *uboot_overlay_options:[enable_uboot_overlays=1]*

 *uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/BB-W1-P9.12-00A0.dtbo]*
 *uboot_overlay_options:[disable_uboot_overlay_video=1]*

 *uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]*
 *uboot_overlay_options:[enable_uboot_cape_universal=1]*
 *pkg check: to individually upgrade run: [sudo apt install 
 --only-upgrade ]*
 *pkg:[bb-cape-overlays]:[4.4.20180928.0-0rcnee0~stretch+20180928]*
 *pkg:[bb-customizations]:[1.20180815-0rcnee0~stretch+20180815]*
 *WARNING:pkg:[bb-usb-gadgets]:[NOT_INSTALLED]*
 *pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]*
 

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

Mark, 

git pull on /var/lib/cloud9 fails with 'fatal: Not a git repository (or any 
of the parent directories): .git 

I'm such a neophyte on git.  What do I need to do?

And, what do you mean by updating to a new version of the SD card? The OS 
is booting from the SD card and the version.sh information posted earlier 
is based on that.


On Wednesday, February 17, 2021 at 2:02:55 PM UTC-5 Mark A. Yoder wrote:

> I suggest updating to a new version of the SD card.  It looks like the 
> PRUs are getting started at boot time, but the path isn't setup right. I 
> think we setup some links so the path* /dev/remoteproc/pruss-core0/state  
> *points to the right place.
>
> You could also try:
> *cd */var/lib/cloud9
> *git* pull
> to update cloud9 folders.
>
> --Mark
>
> On Wednesday, February 17, 2021 at 1:53:35 PM UTC-5 
> wal...@edenconceptsllc.com wrote:
>
>> Mark, 
>>
>> I got the latest PRUCookbook downloaded and when trying to make the 
>> hello.pru0.c program in 1.6, I got this error.  
>>
>> *debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/02start/code$ make 
>> TARGET=hello.pru0*
>> */var/lib/cloud9/common/Makefile:29: 
>> MODEL=TI_AM335x_BeagleBone_Black,TARGET=hello.pru0*
>> *-Stopping PRU 0*
>> */bin/sh: 1: cannot create /dev/remoteproc/pruss-core0/state: Directory 
>> nonexistent*
>> *Cannot stop 0*
>> *CC  hello.pru0.c*
>> *"/var/lib/cloud9/common/prugpio.h", line 53: warning #1181-D: #warning 
>> directive: "Found am335x"*
>> *LD  /tmp/cloud9-examples/hello.pru0.o*
>> *-   copying firmware file /tmp/cloud9-examples/hello.pru0.out to 
>> /lib/firmware/am335x-pru0-fw*
>> *cp: cannot create regular file '/lib/firmware/am335x-pru0-fw': 
>> Permission denied*
>> */var/lib/cloud9/common/Makefile:180: recipe for target 'install' failed*
>> *make: *** [install] Error 1*
>> *rm /tmp/cloud9-examples/hello.pru0.o*
>>
>>  Initially, I did not have a folder called /var/lib/cloud9/common.  To 
>> remedy this I copied the contents of 
>> /var/lib/cloud9/PRUCookbook/docs/common to /var/lib/cloud9/common.  Maybe 
>> this created a problem?Nevertheless,  I found some other discussions that 
>> suggested updating the scripts and kernels from beagleboard.org/upgrade 
>> which I did.  I am now running...
>>
>> Linux beaglebone 4.14.108-ti-r137 #1stretch SMP PREEMPT Tue Aug 25 
>> 01:48:39 UTC 2020 armv7l GNU/Linux
>>
>> And the output of version.sh is 
>>
>> *debian@beaglebone:/$ sudo opt/scripts/tools/version.sh*
>> *[sudo] password for debian:*
>> *git:/opt/scripts/:[e4e4854ef8ff9ada5c85553376043ee7679167ca]*
>> *eeprom:[A335BNLT00C04417BBBK1847]*
>> *model:[TI_AM335x_BeagleBone_Black]*
>> *dogtag:[BeagleBoard.org Debian Image 2018-10-07]*
>> *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 
>> 2018.09-2-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)]:[location: dd 
>> MBR]*
>> *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>> 2018.09-2-g0b54a51eee]:[location: dd MBR]*
>> *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 
>> 2018.03-2-gac9cce7c6a (Apr 05 2018 - 13:07:46 -0500)]:[location: dd 
>> MBR]*
>> *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
>> 2018.03-2-gac9cce7c6a]:[location: dd MBR]*
>> *UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]*
>> *kernel:[4.14.108-ti-r137]*
>> *nodejs:[v6.14.4]*
>> */boot/uEnv.txt Settings:*
>> *uboot_overlay_options:[enable_uboot_overlays=1]*
>>
>> *uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/BB-W1-P9.12-00A0.dtbo]*
>> *uboot_overlay_options:[disable_uboot_overlay_video=1]*
>>
>> *uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]*
>> *uboot_overlay_options:[enable_uboot_cape_universal=1]*
>> *pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
>> ]*
>> *pkg:[bb-cape-overlays]:[4.4.20180928.0-0rcnee0~stretch+20180928]*
>> *pkg:[bb-customizations]:[1.20180815-0rcnee0~stretch+20180815]*
>> *WARNING:pkg:[bb-usb-gadgets]:[NOT_INSTALLED]*
>> *pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]*
>> *pkg:[kmod]:[23-2rcnee1~stretch+20171005]*
>> *pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]*
>> *pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]*
>> *groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
>> plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
>> admin spi tisdk weston-launch xenomai]*
>> *cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
>> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
>> net.ifnames=0 quiet]*
>> *dmesg | grep remote*
>> *[1.147260] remoteproc remoteproc0: wkup_m3 is available*
>> *[1.231303] remoteproc remoteproc0: powering up wkup_m3*
>> *[1.231426] remoteproc remoteproc0: Booting fw image 
>> am335x-pm-firmware.elf, size 217168*
>> *[1.233981] remoteproc remoteproc0: remote processor wkup_m3 is now 
>> up*
>> *[  108.634522] remoteproc remoteproc1: 

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

Mark, 

I got the latest PRUCookbook downloaded and when trying to make the 
hello.pru0.c program in 1.6, I got this error.  

*debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/02start/code$ make 
TARGET=hello.pru0*
*/var/lib/cloud9/common/Makefile:29: 
MODEL=TI_AM335x_BeagleBone_Black,TARGET=hello.pru0*
*-Stopping PRU 0*
*/bin/sh: 1: cannot create /dev/remoteproc/pruss-core0/state: Directory 
nonexistent*
*Cannot stop 0*
*CC  hello.pru0.c*
*"/var/lib/cloud9/common/prugpio.h", line 53: warning #1181-D: #warning 
directive: "Found am335x"*
*LD  /tmp/cloud9-examples/hello.pru0.o*
*-   copying firmware file /tmp/cloud9-examples/hello.pru0.out to 
/lib/firmware/am335x-pru0-fw*
*cp: cannot create regular file '/lib/firmware/am335x-pru0-fw': Permission 
denied*
*/var/lib/cloud9/common/Makefile:180: recipe for target 'install' failed*
*make: *** [install] Error 1*
*rm /tmp/cloud9-examples/hello.pru0.o*

 Initially, I did not have a folder called /var/lib/cloud9/common.  To 
remedy this I copied the contents of 
/var/lib/cloud9/PRUCookbook/docs/common to /var/lib/cloud9/common.  Maybe 
this created a problem?Nevertheless,  I found some other discussions that 
suggested updating the scripts and kernels from beagleboard.org/upgrade 
which I did.  I am now running...

Linux beaglebone 4.14.108-ti-r137 #1stretch SMP PREEMPT Tue Aug 25 01:48:39 
UTC 2020 armv7l GNU/Linux

And the output of version.sh is 

*debian@beaglebone:/$ sudo opt/scripts/tools/version.sh*
*[sudo] password for debian:*
*git:/opt/scripts/:[e4e4854ef8ff9ada5c85553376043ee7679167ca]*
*eeprom:[A335BNLT00C04417BBBK1847]*
*model:[TI_AM335x_BeagleBone_Black]*
*dogtag:[BeagleBoard.org Debian Image 2018-10-07]*
*bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 
2018.09-2-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)]:[location: dd 
MBR]*
*bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2018.09-2-g0b54a51eee]:[location: dd MBR]*
*bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 
2018.03-2-gac9cce7c6a (Apr 05 2018 - 13:07:46 -0500)]:[location: dd 
MBR]*
*bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
2018.03-2-gac9cce7c6a]:[location: dd MBR]*
*UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]*
*kernel:[4.14.108-ti-r137]*
*nodejs:[v6.14.4]*
*/boot/uEnv.txt Settings:*
*uboot_overlay_options:[enable_uboot_overlays=1]*
*uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/BB-W1-P9.12-00A0.dtbo]*
*uboot_overlay_options:[disable_uboot_overlay_video=1]*
*uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]*
*uboot_overlay_options:[enable_uboot_cape_universal=1]*
*pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]*
*pkg:[bb-cape-overlays]:[4.4.20180928.0-0rcnee0~stretch+20180928]*
*pkg:[bb-customizations]:[1.20180815-0rcnee0~stretch+20180815]*
*WARNING:pkg:[bb-usb-gadgets]:[NOT_INSTALLED]*
*pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]*
*pkg:[kmod]:[23-2rcnee1~stretch+20171005]*
*pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]*
*pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]*
*groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
admin spi tisdk weston-launch xenomai]*
*cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 quiet]*
*dmesg | grep remote*
*[1.147260] remoteproc remoteproc0: wkup_m3 is available*
*[1.231303] remoteproc remoteproc0: powering up wkup_m3*
*[1.231426] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217168*
*[1.233981] remoteproc remoteproc0: remote processor wkup_m3 is now up*
*[  108.634522] remoteproc remoteproc1: 4a334000.pru is available*
*[  108.656634] remoteproc remoteproc2: 4a338000.pru is available*
*dmesg | grep pru*
*[  108.019424] pruss 4a30.pruss: creating PRU cores and other child 
platform devices*
*[  108.634522] remoteproc remoteproc1: 4a334000.pru is available*
*[  108.634642] pru-rproc 4a334000.pru: PRU rproc node 
/ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully*
*[  108.656634] remoteproc remoteproc2: 4a338000.pru is available*
*[  108.656808] pru-rproc 4a338000.pru: PRU rproc node 
/ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully*
*dmesg | grep pinctrl-single*
*[0.783913] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
size 568*
*dmesg | grep gpio-of-helper*
*[0.796624] gpio-of-helper ocp:cape-universal: ready*
*lsusb*
*Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub*
*END*

Any ideas?

On Wednesday, February 17, 2021 at 10:10:53 AM UTC-5 Mark A. Yoder wrote:

> The PRUs can give you 10's of ns timing, which is more than good enough 
> for milliseconds, but might be over kill.
>
> I'd think using C on the ARM processor should be 

Re: [beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

You are correct that this application does not need to know the actual real 
time but only the relative (elapsed) time since the subroutine began.  I'm 
familiar with clock_gettime but didn't think it could give me subsecond 
information.  I'll explore it!

Thanks,!

Walter

On Wednesday, February 17, 2021 at 12:42:35 PM UTC-5 m.xilo...@gmail.com 
wrote:

> Hi Walter, 
>
> I don't think you need an RTC for relative time. clock_gettime should do 
> the job (https://linux.die.net/man/3/clock_gettime)
> There are also more intuitive ways to manipulate timespec structs in the 
> RCL (http://strawsondesign.com/docs/librobotcontrol/group__time.html). 
>
> Best, 
> Michele
>
> On Wed, Feb 17, 2021 at 6:25 PM Walter Cromer  
> wrote:
>
>> I really don't need ns.  The valve 'on time' is going to be in the range 
>> of 500 ms to 2 seconds probably.  
>>
>> I will review the PRUCookbook!  Thanks!
>>
>> Walter
>> On Wednesday, February 17, 2021 at 10:10:53 AM UTC-5 Mark A. Yoder wrote:
>>
>>> The PRUs can give you 10's of ns timing, which is more than good enough 
>>> for milliseconds, but might be over kill.
>>>
>>> I'd think using C on the ARM processor should be fast enough.  I'd use 
>>> gpiod[1].
>>>
>>> If you really want the ns timing of the PRUs, check out the PRU 
>>> Cookbook[2]
>>>
>>> --Mark
>>>
>>> [1] https://github.com/starnight/libgpiod-example
>>> [2] https://github.com/MarkAYoder/PRUCookbook
>>>
>>> On Tuesday, February 16, 2021 at 10:51:11 AM UTC-5 pierric...@gadz.org 
>>> wrote:
>>>
>>>> Depending on how precise you need to be, I would go for the PRU-ICSS. 
>>>> They can control the GPIOs pretty easily. 
>>>>
>>>> Le mardi 16 février 2021 à 10:03:47 UTC-5, wal...@edenconceptsllc.com 
>>>> a écrit :
>>>>
>>>>> I have a BBB Wireless running Linux beaglebone 4.14.108-ti-r106 #1 SMP 
>>>>> PREEMPT Fri May 24 22:12:34 UTC 2019 armv7l GNU/Linux
>>>>>
>>>>> I am writing in C.
>>>>>
>>>>> I turn a valve on and then need to read some sensors for N 
>>>>> milliseconds and then turn the valve off.
>>>>>
>>>>> What's the best way to read milliseconds on the BBBw?  I don't have a 
>>>>> RTC on this particular unit but could add one using I2C.  I have an 
>>>>> Adafruit 4282 with a DS3231 RTC on it on another BBBw that I could use 
>>>>> temporarily to prove it works.  What other options are available?
>>>>>
>>>>>
>>>>> -- 
>> 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/fc16c0ce-4895-4bfd-93a4-245fe6b0d59cn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/fc16c0ce-4895-4bfd-93a4-245fe6b0d59cn%40googlegroups.com?utm_medium=email_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/2ee9976d-daf9-479c-b8a2-e17ef0c75cbbn%40googlegroups.com.

[beagleboard] Re: Best way to get elapsed milliseconds

[Walter Cromer]

I really don't need ns.  The valve 'on time' is going to be in the range of 
500 ms to 2 seconds probably.  

I will review the PRUCookbook!  Thanks!

Walter
On Wednesday, February 17, 2021 at 10:10:53 AM UTC-5 Mark A. Yoder wrote:

> The PRUs can give you 10's of ns timing, which is more than good enough 
> for milliseconds, but might be over kill.
>
> I'd think using C on the ARM processor should be fast enough.  I'd use 
> gpiod[1].
>
> If you really want the ns timing of the PRUs, check out the PRU Cookbook[2]
>
> --Mark
>
> [1] https://github.com/starnight/libgpiod-example
> [2] https://github.com/MarkAYoder/PRUCookbook
>
> On Tuesday, February 16, 2021 at 10:51:11 AM UTC-5 pierric...@gadz.org 
> wrote:
>
>> Depending on how precise you need to be, I would go for the PRU-ICSS. 
>> They can control the GPIOs pretty easily. 
>>
>> Le mardi 16 février 2021 à 10:03:47 UTC-5, wal...@edenconceptsllc.com a 
>> écrit :
>>
>>> I have a BBB Wireless running Linux beaglebone 4.14.108-ti-r106 #1 SMP 
>>> PREEMPT Fri May 24 22:12:34 UTC 2019 armv7l GNU/Linux
>>>
>>> I am writing in C.
>>>
>>> I turn a valve on and then need to read some sensors for N milliseconds 
>>> and then turn the valve off.
>>>
>>> What's the best way to read milliseconds on the BBBw?  I don't have a 
>>> RTC on this particular unit but could add one using I2C.  I have an 
>>> Adafruit 4282 with a DS3231 RTC on it on another BBBw that I could use 
>>> temporarily to prove it works.  What other options are available?
>>>
>>>
>>>

-- 
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/fc16c0ce-4895-4bfd-93a4-245fe6b0d59cn%40googlegroups.com.

[beagleboard] Best way to get elapsed milliseconds

[Walter Cromer]

I have a BBB Wireless running Linux beaglebone 4.14.108-ti-r106 #1 SMP 
PREEMPT Fri May 24 22:12:34 UTC 2019 armv7l GNU/Linux

I am writing in C.

I turn a valve on and then need to read some sensors for N milliseconds and 
then turn the valve off.

What's the best way to read milliseconds on the BBBw?  I don't have a RTC 
on this particular unit but could add one using I2C.  I have an Adafruit 
4282 with a DS3231 RTC on it on another BBBw that I could use temporarily 
to prove it works.  What other options are available?


-- 
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/dc0a3903-0ffa-445d-ae91-a809483c2720n%40googlegroups.com.

Re: [beagleboard] Re: Beaglebone black connect to Web

[Walter Cromer]

John Dyson - did you ever get this to work?  I have had the same problem 
and can't get it to work...

On Friday, October 16, 2020 at 3:18:40 AM UTC-4 jonn...@gmail.com wrote:

> Typically, Windows disables the response to ping. I would leave it that 
> way.
>
> To get the Beaglebone to talk to the Internet through the Windows internet 
> connection you should not have to change anything with the firewall; I did 
> not have to do this.
> I would go back through the steps and see what is missing.
>
> Jon 
>
> On Thu, Oct 15, 2020 at 11:57 PM John Dyson  wrote:
>
>> Hi,
>>
>> You are right disabling the windows firewall allowed the beaglebone to 
>> ping the windows PC. I disabled the PC wifi in order that there were no 
>> issues. Any idea how I can configure the firewall in order that the 
>> beaglebone over the usb cable is allowed through?
>>
>> Thanks 
>>
>> On Wednesday, 14 October 2020 at 16:16:49 UTC+1 Dennis Bieber wrote:
>>
>>> On Wed, 14 Oct 2020 01:01:42 -0700 (PDT), in 
>>> gmane.comp.hardware.beagleboard.user John Dyson 
>>>  wrote: 
>>>
>>> >Hi, 
>>> > 
>>> >Following these instructions: 
>>> > 
>>> >I have connected the USB Cable and nothing else from the beaglebone to 
>>> the 
>>> >PC. All of thwe windows 64 bit drivers have been successfully 
>>> installed. 
>>> > 
>>>
>>> Just to follow along on this part, I've pulled the CAT-5 from my BBB. 
>>>
>>> debian@beaglebone:~$ ifconfig 
>>> eth0: flags=-28669 mtu 1500 
>>> ether d0:39:72:18:3e:e5 txqueuelen 1000 (Ethernet) 
>>> RX packets 164 bytes 13701 (13.3 KiB) 
>>> RX errors 0 dropped 0 overruns 0 frame 0 
>>> TX packets 95 bytes 15719 (15.3 KiB) 
>>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 
>>> device interrupt 55 
>>>
>>> lo: flags=73 mtu 65536 
>>> inet 127.0.0.1 netmask 255.0.0.0 
>>> inet6 ::1 prefixlen 128 scopeid 0x10 
>>> loop txqueuelen 1000 (Local Loopback) 
>>> RX packets 153 bytes 11380 (11.1 KiB) 
>>> RX errors 0 dropped 0 overruns 0 frame 0 
>>> TX packets 153 bytes 11380 (11.1 KiB) 
>>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 
>>>
>>> usb0: flags=4163 mtu 1500 
>>> inet 192.168.7.2 netmask 255.255.255.0 broadcast 192.168.7.255 
>>> inet6 fe80::d239:72ff:fe18:3ee7 prefixlen 64 scopeid 0x20 
>>> ether d0:39:72:18:3e:e7 txqueuelen 1000 (Ethernet) 
>>> RX packets 193 bytes 35656 (34.8 KiB) 
>>> RX errors 0 dropped 4 overruns 0 frame 0 
>>> TX packets 84 bytes 18613 (18.1 KiB) 
>>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 
>>>
>>> usb1: flags=4099 mtu 1500 
>>> inet 192.168.6.2 netmask 255.255.255.0 broadcast 192.168.6.255 
>>> ether d0:39:72:18:3e:eb txqueuelen 1000 (Ethernet) 
>>> RX packets 0 bytes 0 (0.0 B) 
>>> RX errors 0 dropped 0 overruns 0 frame 0 
>>> TX packets 0 bytes 0 (0.0 B) 
>>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 
>>>
>>> No IP address on eth0, expected address on usb0. 
>>>
>>> > 
>>> >The initial ping to the gateway 192.168.7.1 fails when I SSH into the 
>>> >beaglebone (Figure 3) 
>>> > 
>>> WHY a screen grab? You are using a text console, aren't you -- just 
>>> select/copy/paste the TEXT... 
>>>
>>> debian@beaglebone:~$ route 
>>> Kernel IP routing table 
>>> Destination Gateway Genmask Flags Metric Ref Use 
>>> Iface 
>>> 192.168.6.0 0.0.0.0 255.255.255.0 U 0 0 0 
>>> usb1 
>>> 192.168.7.0 0.0.0.0 255.255.255.0 U 0 0 0 
>>> usb0 
>>> debian@beaglebone:~$ ping 192.168.7.1 
>>> PING 192.168.7.1 (192.168.7.1) 56(84) bytes of data. 
>>> 64 bytes from 192.168.7.1: icmp_seq=1 ttl=128 time=0.368 ms 
>>> 64 bytes from 192.168.7.1: icmp_seq=2 ttl=128 time=0.475 ms 
>>> 64 bytes from 192.168.7.1: icmp_seq=3 ttl=128 time=0.501 ms 
>>> 64 bytes from 192.168.7.1: icmp_seq=4 ttl=128 time=0.491 ms 
>>> ^C 
>>> --- 192.168.7.1 ping statistics --- 
>>> 4 packets transmitted, 4 received, 0% packet loss, time 9ms 
>>> rtt min/avg/max/mdev = 0.368/0.458/0.501/0.059 ms 
>>> debian@beaglebone:~$ 
>>>
>>> Pinging the host computer works, even without a gateway setting (since 
>>> 192.168.7.1 and 192.168.7.2 are the same network, and likely it is 
>>> presumed 
>>> that all hosts on that network can be reached using the adapter [usb0] 
>>> that 
>>> is itself on the network). 
>>>
>>>
>>>
>>> If that simple step is failing, you might have to check whatever 
>>> firewall you have running on Windows. 
>>>
>>>
>>>
>>> NEXT action I tried was opening the Windows "Network Connections" 
>>> control panel. BRIDGING "Ethernet" (remember -- My systems are normally 
>>> cable connection) and "Ethernet 2" (the RNDIS gadget) is not the correct 
>>> action, as it kills the Internet access on "Ethernet" (and there is an 
>>> advisory that one cannot bridge an ICS adapter). 
>>>
>>> So... remove bridge, open "Ethernet" and enable Sharing, specifying 
>>> "Ethernet 2" as the private network side. 
>>>
>>> With ICS active, Windows assigned 192.168.137.1 to the RNDIS adapter! I 
>>> just edited that to use a manual IP address 192.168.7.1, length 24, and 
>>> gateway is set to my 

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

[Walter Cromer]

I plan to write the code in C since I'm most familiar with it (although 
very rusty, but it's coming back) and I have considered learning Python and 
using it.

By the way, thanks to all for your patience with me on this!  It has been a 
long time since I worked in this space and a lot has changed and improved!

On Friday, May 17, 2019 at 9:17:24 AM UTC-4, Hugh Frater wrote:
>
> If you can live with using the universal-cape and just configuring the 
> pins once booted using the config-pin utility, that's a good way to go. 
> What programming language are you wanting to use to write your temperature 
> sensor software? If you are doing it from the PRU then you can just code up 
> your own i2c read function and access the registers directly though the 
> memory map, just like any standard MCU. 
>
> On Thursday, 16 May 2019 20:34:58 UTC+1, Walter Cromer wrote:
>>
>> Hugh - I'll dig around in the UBoot section.  Thanks for suggesting 
>> that.  I'm such a newbie on here!
>>
>> As for how I compiled the custom device tree overlay, I followed the 
>> instructions posted at this location and it worked fine - no errors after I 
>> corrected the typos, etc. that were posted in the comments.
>>
>>
>> http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/
>>
>> I'd really like to get this temperature sensor working but all the 
>> instructions are pre-Uboot.   I can make a lot of progress with my 
>> prototype once I get this working but liquid temperature is a critical 
>> input so without it I can't move forward!
>>
>>
>>
>> On Thursday, May 16, 2019 at 5:53:38 AM UTC-4, Hugh Frater wrote:
>>>
>>> Hi Walter, I'm afraid I can't help with your custom device overlay 
>>> issue, it us really a topic for a new thread in the uBoot section I would 
>>> have thought?
>>>
>>> I would be interested in hearing how you compiled a custom device tree 
>>> overlay though. We have our BBB on a custom card that uses a bunch of gpio, 
>>> an eqep module, a bunch of uarts and some pru_ecap pwm - it's a lot of work 
>>> for config-pin to setup at boot time and I'd like to trim this 13 seconds 
>>> of work out of my bootup if possible. Perhaps you could make a post in the 
>>> uBoot section?
>>>
>>> Hugh
>>>
>>> On Thursday, 16 May 2019 01:27:36 UTC+1, Walter Cromer wrote:
>>>>
>>>> Hugh - I'm a real newbie.  I compiled a device tree overlay with not 
>>>> errors and have a dtbo file now.  I just don't know how to get it into the 
>>>> boot process.  Where do I put it, do I need to change a file like env.txt 
>>>> somewhere to get it to load and if so what syntax do i use?  Where did you 
>>>> find these instructions?  I'm so lost and need to keep moving forward.  it 
>>>> was going so well...
>>>>
>>>> I'm on 4.4.14 
>>>>
>>>> On Thursday, May 9, 2019 at 7:31:27 AM UTC-4, Hugh Frater wrote:
>>>>>
>>>>> I have the same problem as this user: 
>>>>> https://groups.google.com/forum/#!category-topic/beagleboard/pru/g2NcW2sUX-4
>>>>>  
>>>>> in that remoteproc only detects the wkup_m3 coprocessor (whatever that 
>>>>> is) 
>>>>> and doesn't seem to detect the PRUs on boot.
>>>>>
>>>>> This is a fresh install of Sretch IOT from beagleboard.org, with the 
>>>>> kernel and cape-overlays updated through the tools/scripts...
>>>>>
>>>>> version.sh shows:
>>>>>
>>>>> git:/opt/scripts/:[c2a5ae96746d10d711c60bc84ba244f4cd7b75c3]
>>>>> eeprom:[A335BNLT00C03816BBBK190D]
>>>>> model:[TI_AM335x_BeagleBone_Black]
>>>>> dogtag:[BeagleBoard.org Debian Image 2018-10-07]
>>>>> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>>>>> 2018.09-2-g0b54a51eee]:[location: dd MBR]
>>>>> kernel:[4.14.108-ti-r104]
>>>>> nodejs:[v6.14.4]
>>>>> uboot_overlay_options:[enable_uboot_overlays=1]
>>>>> uboot_overlay_options:[disable_uboot_overlay_emmc=1]
>>>>> uboot_overlay_options:[disable_uboot_overlay_video=1]
>>>>> uboot_overlay_options:[disable_uboot_overlay_audio=1]
>>>>> uboot_overlay_options:[disable_uboot_overlay_wireless=1]
>>>>> uboot_overlay_options:[disable_uboot_overlay_adc=1]
>>>>>
>>>>> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtb

[beagleboard] Re: How to Write Device Trees?

[Walter Cromer]

I would really appreciate this information too.  I see examples of device 
trees online and in books but nothing so far explains what any of the 
syntax really means and without understanding that I'm just copying 
something without learning anything.  I could really use some help here, 
please!

On Thursday, May 16, 2019 at 9:52:16 PM UTC-4, sacan...@gmail.com wrote:
>
>
> Could anyone point me to some resources that explain how to write device 
> tree files for the BBB?
>
> To clarify, the OS running on my BeagleBone is a custom Linux distro (not 
> one of the more common Debian or Angstrom ones). The current configuration 
> only enables one of the SPI ports and none of the PWM pins. I want to 
> modify the .dts file used in building the OS so that it correctly enables 
> and muxes the SPI and PWM pins that I select. I also want to avoid using 
> device tree overlays, so I'm dealing with just the device trees. Any help 
> would be appreciated, thanks.
>

-- 
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/08afc945-a72c-4c0b-b867-e26644f5f85f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Pocketbeagle Techlab

[Walter Cromer]

Thanks.   Now if I can just get my BBB connecting to the internet again!!!
it stopped two days ago and nothing I try corrects it!  It won't boot from
eMMC either.

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, May 16, 2019 at 6:50 PM Robert Nelson 
wrote:

> On Thu, May 16, 2019 at 2:37 PM Walter Cromer
>  wrote:
> >
> > Thanks, Robert!  This is for the x15 though, right?  I'm running a BB
> Black.   I'm assuming that this isn't compatible with the Black, right?
>
> The "--ti-channel" is for all am35xx and am57xx based BeagleBoard.org
> products.
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>


-- 
Thanks,

Walter Cromer
Chief Idea Officer & Founder
Eden Concepts LLC
m: 865-719-8881
http://edenconceptsllc.com

Live. Grow. Harmonize.

The information contained in this e-mail message may be privileged and
confidential. If the reader of this transmission is not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received
this communication in error or are not sure whether it is privileged,
please immediately notify us by return e-mail and delete or destroy any
copies, electronic, paper or otherwise, which you may have of this
communication and any attachments.

-- 
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/CAGNysGYytqLa2%2BbyK9Nj6x2R%3D91B1Bvkhk-8trmEFCLNHg856w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Won't boot from eMMC

[Walter Cromer]

My BBB used to boot just fine from the eMMC but most of the time I held the 
user button down and booted from the SD card.  All that was working great.  
I'd never (to my knowledge) flashed the eMMC either.  I started to not be 
able to get to the internet via USB so I thought I'd go back and just boot 
from eMMC but it won't boot from that now.  Any ideas?

Is something on the eMMC required to get to the Internet after I boot from 
the Sd card?  Coudl these two things be related?

Thanks!

-- 
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/422e4c7e-daa1-496a-a2db-cfdb280280f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Pocketbeagle Techlab

[Walter Cromer]

Thanks, Robert!  This is for the x15 though, right?  I'm running a BB 
Black.   I'm assuming that this isn't compatible with the Black, right?

Walter

On Thursday, May 16, 2019 at 3:26:45 PM UTC-4, RobertCNelson wrote:
>
> On Thu, May 16, 2019 at 2:11 PM Walter Cromer 
> > wrote: 
> > 
> > Jim - Where did you find 4.19?  I haven't found it anywhere so far! 
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian 
>
> sudo /opt/scripts/tools/update_kernel.sh --ti-channel --lts-4_19 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
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/378e2578-347d-4077-a846-c17616c279ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

[Walter Cromer]

Hugh - I'll dig around in the UBoot section.  Thanks for suggesting that.  
I'm such a newbie on here!

As for how I compiled the custom device tree overlay, I followed the 
instructions posted at this location and it worked fine - no errors after I 
corrected the typos, etc. that were posted in the comments.

http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/

I'd really like to get this temperature sensor working but all the 
instructions are pre-Uboot.   I can make a lot of progress with my 
prototype once I get this working but liquid temperature is a critical 
input so without it I can't move forward!



On Thursday, May 16, 2019 at 5:53:38 AM UTC-4, Hugh Frater wrote:
>
> Hi Walter, I'm afraid I can't help with your custom device overlay issue, 
> it us really a topic for a new thread in the uBoot section I would have 
> thought?
>
> I would be interested in hearing how you compiled a custom device tree 
> overlay though. We have our BBB on a custom card that uses a bunch of gpio, 
> an eqep module, a bunch of uarts and some pru_ecap pwm - it's a lot of work 
> for config-pin to setup at boot time and I'd like to trim this 13 seconds 
> of work out of my bootup if possible. Perhaps you could make a post in the 
> uBoot section?
>
> Hugh
>
> On Thursday, 16 May 2019 01:27:36 UTC+1, Walter Cromer wrote:
>>
>> Hugh - I'm a real newbie.  I compiled a device tree overlay with not 
>> errors and have a dtbo file now.  I just don't know how to get it into the 
>> boot process.  Where do I put it, do I need to change a file like env.txt 
>> somewhere to get it to load and if so what syntax do i use?  Where did you 
>> find these instructions?  I'm so lost and need to keep moving forward.  it 
>> was going so well...
>>
>> I'm on 4.4.14 
>>
>> On Thursday, May 9, 2019 at 7:31:27 AM UTC-4, Hugh Frater wrote:
>>>
>>> I have the same problem as this user: 
>>> https://groups.google.com/forum/#!category-topic/beagleboard/pru/g2NcW2sUX-4
>>>  
>>> in that remoteproc only detects the wkup_m3 coprocessor (whatever that is) 
>>> and doesn't seem to detect the PRUs on boot.
>>>
>>> This is a fresh install of Sretch IOT from beagleboard.org, with the 
>>> kernel and cape-overlays updated through the tools/scripts...
>>>
>>> version.sh shows:
>>>
>>> git:/opt/scripts/:[c2a5ae96746d10d711c60bc84ba244f4cd7b75c3]
>>> eeprom:[A335BNLT00C03816BBBK190D]
>>> model:[TI_AM335x_BeagleBone_Black]
>>> dogtag:[BeagleBoard.org Debian Image 2018-10-07]
>>> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>>> 2018.09-2-g0b54a51eee]:[location: dd MBR]
>>> kernel:[4.14.108-ti-r104]
>>> nodejs:[v6.14.4]
>>> uboot_overlay_options:[enable_uboot_overlays=1]
>>> uboot_overlay_options:[disable_uboot_overlay_emmc=1]
>>> uboot_overlay_options:[disable_uboot_overlay_video=1]
>>> uboot_overlay_options:[disable_uboot_overlay_audio=1]
>>> uboot_overlay_options:[disable_uboot_overlay_wireless=1]
>>> uboot_overlay_options:[disable_uboot_overlay_adc=1]
>>>
>>> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
>>> uboot_overlay_options:[enable_uboot_cape_universal=1]
>>> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
>>> ]
>>> pkg:[bb-cape-overlays]:[4.4.20190429.0-0rcnee0~stretch+20190429]
>>> pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
>>> pkg:[kmod]:[23-2rcnee1~stretch+20171005]
>>> pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]
>>> pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
>>> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
>>> plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
>>> admin spi tisdk weston-launch xenomai]
>>> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
>>> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
>>> net.ifnames=0 quiet]
>>> dmesg | grep remote
>>> [1.302485] remoteproc remoteproc0: wkup_m3 is available
>>> [1.389525] remoteproc remoteproc0: powering up wkup_m3
>>> [1.389661] remoteproc remoteproc0: Booting fw image 
>>> am335x-pm-firmware.elf, size 217168
>>> [1.393097] remoteproc remoteproc0: remote processor wkup_m3 is now up
>>> dmesg | grep pru
>>> dmesg | grep pinctrl-single
>>> [0.971911] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
>>> size 568

Re: [beagleboard] Re: Pocketbeagle Techlab

[Walter Cromer]

Jim - Where did you find 4.19?  I haven't found it anywhere so far!

On Wednesday, May 15, 2019 at 9:30:39 PM UTC-4, Jim F wrote:
>
> We upgraded to 4.19, loaded the 1W dtb from /lib/firmware and things just 
> work. I think it's looking for the 1 W interface to be on P9. 12 which 
> works out to Gpio 1-28 which is also known as gpio 60. At this point it 
> shows up under /sys/bus and "just works". Couldn't say that for 4.14 and 
> I've no idea why.
>
> Or there's a PRU-based approach which TJF can tell you about. Not sure 
> what the difference between the two is, though we only use it for a single 
> sensor. Maybe I'll try that out tomorrow.
>
> Jim
>
> On Wed, May 15, 2019, 8:13 PM Walter Cromer   wrote:
>
>> I've made a lot of progress thanks to the Exploring Beaglebone book.  I 
>> am turning AC pumps and motors on with relays that I control from the 
>> digital outputs through opto-isolators.  But when I needed to read a water 
>> proof temperature probe, I got stuck.  I bought the DS18B20 and didn't 
>> comprehend it was Dallas single-wire interface.  I thought it was just a 
>> waterproof TMP36 which I was already reading successfully.
>>
>> The examples for the DS18B20 are all pre-UBoot.(I'm running 4.4.14 now).  
>> I compiled a device tree overlay but don't know how to get it loaded, where 
>> to put it so it gets loaded, what file to change and what the command 
>> should be to have it load on boot.  Is this all in the book somewhere?  If 
>> not, could you share a resource that would help me?
>>
>> On Wednesday, May 15, 2019 at 1:42:40 PM UTC-4, TJF wrote:
>>>
>>>
>>>
>>> Am Mittwoch, 15. Mai 2019 15:41:06 UTC+2 schrieb P B:
>>>>
>>>> Does anyone have any tips or any recommendations for learning resources 
>>>> to get over this hurdle?
>>>>
>>>
>>> Check out libpruio <https://github.com/DTJF/libpruio> and its online 
>>> documentation 
>>> <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/index.html>.
>>>  
>>> No device tree trouble, all settings in your code (single sourced).
>>>
>>> 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 beagl...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/90814ecc-368c-46b5-9ade-d10e88d3d919%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/90814ecc-368c-46b5-9ade-d10e88d3d919%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/c5cb3b46-3f69-4487-92c0-b19d673fadcc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Pocketbeagle Techlab

[Walter Cromer]

Jim - do you mean that using 4.4.19 took care of our one wire interfacing 
problem?   I'm going to give that a try!  

On Wednesday, May 15, 2019 at 9:30:39 PM UTC-4, Jim F wrote:
>
> We upgraded to 4.19, loaded the 1W dtb from /lib/firmware and things just 
> work. I think it's looking for the 1 W interface to be on P9. 12 which 
> works out to Gpio 1-28 which is also known as gpio 60. At this point it 
> shows up under /sys/bus and "just works". Couldn't say that for 4.14 and 
> I've no idea why.
>
> Or there's a PRU-based approach which TJF can tell you about. Not sure 
> what the difference between the two is, though we only use it for a single 
> sensor. Maybe I'll try that out tomorrow.
>
> Jim
>
> On Wed, May 15, 2019, 8:13 PM Walter Cromer   wrote:
>
>> I've made a lot of progress thanks to the Exploring Beaglebone book.  I 
>> am turning AC pumps and motors on with relays that I control from the 
>> digital outputs through opto-isolators.  But when I needed to read a water 
>> proof temperature probe, I got stuck.  I bought the DS18B20 and didn't 
>> comprehend it was Dallas single-wire interface.  I thought it was just a 
>> waterproof TMP36 which I was already reading successfully.
>>
>> The examples for the DS18B20 are all pre-UBoot.(I'm running 4.4.14 now).  
>> I compiled a device tree overlay but don't know how to get it loaded, where 
>> to put it so it gets loaded, what file to change and what the command 
>> should be to have it load on boot.  Is this all in the book somewhere?  If 
>> not, could you share a resource that would help me?
>>
>> On Wednesday, May 15, 2019 at 1:42:40 PM UTC-4, TJF wrote:
>>>
>>>
>>>
>>> Am Mittwoch, 15. Mai 2019 15:41:06 UTC+2 schrieb P B:
>>>>
>>>> Does anyone have any tips or any recommendations for learning resources 
>>>> to get over this hurdle?
>>>>
>>>
>>> Check out libpruio <https://github.com/DTJF/libpruio> and its online 
>>> documentation 
>>> <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/index.html>.
>>>  
>>> No device tree trouble, all settings in your code (single sourced).
>>>
>>> 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 beagl...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/90814ecc-368c-46b5-9ade-d10e88d3d919%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/90814ecc-368c-46b5-9ade-d10e88d3d919%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/2f604469-5af8-4e3d-a15c-721b22789ecb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

[Walter Cromer]

Hugh - I'm a real newbie.  I compiled a device tree overlay with not errors 
and have a dtbo file now.  I just don't know how to get it into the boot 
process.  Where do I put it, do I need to change a file like env.txt 
somewhere to get it to load and if so what syntax do i use?  Where did you 
find these instructions?  I'm so lost and need to keep moving forward.  it 
was going so well...

I'm on 4.4.14 

On Thursday, May 9, 2019 at 7:31:27 AM UTC-4, Hugh Frater wrote:
>
> I have the same problem as this user: 
> https://groups.google.com/forum/#!category-topic/beagleboard/pru/g2NcW2sUX-4 
> in that remoteproc only detects the wkup_m3 coprocessor (whatever that is) 
> and doesn't seem to detect the PRUs on boot.
>
> This is a fresh install of Sretch IOT from beagleboard.org, with the 
> kernel and cape-overlays updated through the tools/scripts...
>
> version.sh shows:
>
> git:/opt/scripts/:[c2a5ae96746d10d711c60bc84ba244f4cd7b75c3]
> eeprom:[A335BNLT00C03816BBBK190D]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Image 2018-10-07]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2018.09-2-g0b54a51eee]:[location: dd MBR]
> kernel:[4.14.108-ti-r104]
> nodejs:[v6.14.4]
> uboot_overlay_options:[enable_uboot_overlays=1]
> uboot_overlay_options:[disable_uboot_overlay_emmc=1]
> uboot_overlay_options:[disable_uboot_overlay_video=1]
> uboot_overlay_options:[disable_uboot_overlay_audio=1]
> uboot_overlay_options:[disable_uboot_overlay_wireless=1]
> uboot_overlay_options:[disable_uboot_overlay_adc=1]
>
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ]
> pkg:[bb-cape-overlays]:[4.4.20190429.0-0rcnee0~stretch+20190429]
> pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
> pkg:[kmod]:[23-2rcnee1~stretch+20171005]
> pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]
> pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
> admin spi tisdk weston-launch xenomai]
> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 quiet]
> dmesg | grep remote
> [1.302485] remoteproc remoteproc0: wkup_m3 is available
> [1.389525] remoteproc remoteproc0: powering up wkup_m3
> [1.389661] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217168
> [1.393097] remoteproc remoteproc0: remote processor wkup_m3 is now up
> dmesg | grep pru
> dmesg | grep pinctrl-single
> [0.971911] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
> size 568
> dmesg | grep gpio-of-helper
> [0.984114] gpio-of-helper ocp:cape-universal: ready
> lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> END
>
> What am I doing wrong here? Surely PRU support is one of those things that 
> should be working out of the box with the correct u-boot overlay applied?
>
>
>
>
>
>

-- 
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/205e5464-ada4-4a7b-9133-7461c75adb14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Pocketbeagle Techlab

[Walter Cromer]

I've made a lot of progress thanks to the Exploring Beaglebone book.  I am 
turning AC pumps and motors on with relays that I control from the digital 
outputs through opto-isolators.  But when I needed to read a water proof 
temperature probe, I got stuck.  I bought the DS18B20 and didn't comprehend 
it was Dallas single-wire interface.  I thought it was just a waterproof 
TMP36 which I was already reading successfully.

The examples for the DS18B20 are all pre-UBoot.(I'm running 4.4.14 now).  I 
compiled a device tree overlay but don't know how to get it loaded, where 
to put it so it gets loaded, what file to change and what the command 
should be to have it load on boot.  Is this all in the book somewhere?  If 
not, could you share a resource that would help me?

On Wednesday, May 15, 2019 at 1:42:40 PM UTC-4, TJF wrote:
>
>
>
> Am Mittwoch, 15. Mai 2019 15:41:06 UTC+2 schrieb P B:
>>
>> Does anyone have any tips or any recommendations for learning resources 
>> to get over this hurdle?
>>
>
> Check out libpruio  and its online 
> documentation 
> . 
> No device tree trouble, all settings in your code (single sourced).
>
> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/90814ecc-368c-46b5-9ade-d10e88d3d919%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Pocketbeagle Techlab

[Walter Cromer]

I bought my copy as a Kindle book from Amazon.  It shows a publlication 
date of December 2018 and says Second Edition on the cover. But  I have the 
same learning curve and problem.   And, I can't seem to find the 
information about using UBoot in the book.  Would you be so kind as to 
share where that information is found?

On Wednesday, May 15, 2019 at 11:41:28 AM UTC-4, Dennis Lee Bieber wrote:
>
> On Wed, 15 May 2019 06:41:06 -0700 (PDT), P B 
> > declaimed the 
> following: 
>
> >Good morning, 
> > 
> >For the past two months I've been trying to learn how to use the BBB & PB 
> >using Derek Molloy's book. 
> > 
>
> Which edition? The 2nd Edition has a January 2019 copyright, and 
> should 
> have updated the device tree information for the newer u-Boot scheme. 
>
> Just skimmed through my copy and it looks like it is u-Boot DTB 
> based 
> (and has actual PocketBeagle examples) 
>
>
> -- 
> Wulfraed Dennis Lee Bieber AF6VN 
> wlf...@ix.netcom.com  
>
>

-- 
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/b77fe274-02d9-4dbc-9435-a463431c4def%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.