[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(&tv_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(&tv_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

[Dennis Lee Bieber]

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/vsct2gpnn5bt691c6kfggvoe6p2miehf4u%404ax.com.

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

There is a cycle count register[1]

I'm not using wireless, so I don't know it's current status.

--Mark

[1] 
https://markayoder.github.io/PRUCookbook/07more/more.html#_using_the_built_in_counter_for_timing

On Thursday, February 18, 2021 at 12:38:24 PM UTC-5 
wal...@edenconceptsllc.com wrote:

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

[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 
>> 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 -> 
> /s

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

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 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...@edenconcepts

[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 -> 
>>> /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-deb

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

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

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

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

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

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

[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 

 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 

[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 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/PRUCookb

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

[beagleboard] Re: Best way to get elapsed milliseconds

[Dennis Lee Bieber]

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.


-- 
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/el0s2glcs6ma6r30cphm9jr2kksotlksk5%404ax.com.

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

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

[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:*
>> *uboot

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

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:*
> *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_unive

[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]*
 *pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch

[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]*
 *pkg:[kmod]:[23-2rcnee1~stretch+20171005]*

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

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]*
>>> *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]*
>>> *cmdl

[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: 4a

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

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

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

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

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

[Michele Xiloyannis]

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

-- 
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/CANC2S_F6SN3Bz05U6pwrD6LA8DFkDOBGbLbpah%3D%2B%3DH6bChfo6g%40mail.gmail.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] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

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/3d57e46f-1a11-4635-9150-4fefaf3e76edn%40googlegroups.com.

[beagleboard] Re: Best way to get elapsed milliseconds

[pierric...@gadz.org]

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/50e0d922-4d56-48e5-a9a2-abf6da73c6f9n%40googlegroups.com.