Re: [beagleboard] Re: AM335x Beaglebone Black Python Programming Scripts

['Mark Lazarewicz' via BeagleBoard]

Hi Chris Many of the RF SoC can be Initialized via UART by sending AT commands  
if that's what you are asking ??? I have used a windows python script to send 
the AT commands to get the Soc eval board running If that's what you are asking 
the script itself will run from the BB command prompt and shouldn't be any 
different from windows . How to execute python in Linux tutorials are online If 
your trying to load firmware into the SoC using a BB that doesn't make sense 
and really is off  subject of would ask in the group. That chip uses IAR or 
code Composer studio as a programming enviroments I believe you build the code 
load into the ARM processor over JTAG.Once its programmed the chip can be put 
in various modes using AT commands  
 I have a simple link 2650 board from TI if you have any firmware question 
email me

  From: "chris.yor...@gmail.com" 
 To: BeagleBoard  
Cc: chris.yor...@gmail.com
 Sent: Tuesday, December 22, 2015 11:35 AM
 Subject: [beagleboard] Re: AM335x Beaglebone Black Python Programming Scripts
   
You guys are a tough crowd!  We'll take this offline with the customer. -Chris 
On Thursday, December 3, 2015 at 8:25:51 AM UTC-5, chris@gmail.com wrote:
Team,Our customer is trying to utilize the Beaglebone Black, running Python 
scripts, to program the SimpleLink CC3200.Can you answer a question at the 
bottom of the attached reference document? (“We could not find documentation on 
how to run python scripts on beaglebone-black (Linux) like it has mentioned for 
Windows.  It would be helpful if we can get this information.”)  In other 
words, what is the command line to run the script on BBB (like 
“ImageProgramming.exe -p 2 -i hib.bin” on Windows)?Regards,Chris-
Questionsregarding Embedded Programming 1.  We are able to program the 
evaluation board byconnecting it to PC via USB. Results are as follows. 




  2.  But when we tried to program the evaluation board byusing RS232 to 
TTL converter, we were unsuccessful, screen shot of CommandPrompt and Snap shot 
of the setup are as below. 


  3.  We could not find documentation on how to run pythonscripts on 
beaglebone-black (Linux) like it has mentioned for Windows. It wouldbe helpful 
if we can get those information. 
-- 
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.
For more options, visit https://groups.google.com/d/optout.


  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Recommended way to start a graphical application at boot.

[Peter Gregory]

I used LXDE and modify the autostart to operate in kiosk mode.
Comment out the lxpanel and pcmanfm.
create a shell script (startmyapp.sh) in the home directory that will set up 
any environment variables you need and launch your application:

sudo nano /etc/xdg/lxsession/LXDE/autostart

And make the contents look like:

#@lxpanel --profile LXDE
#@pcmanfm --desktop --profile LXDE
@xset s off
@xset -dpms
@xset s nonblank
# Turn off the blinking lights
sudo sh -c "echo none > /sys/class/leds/lcd4\:green\:usr0/trigger"
sudo sh -c "echo none > /sys/class/leds/beaglebone\:green\:usr0/trigger"
sudo sh -c "echo none > /sys/class/leds/beaglebone\:green\:usr1/trigger"
sudo sh -c "echo none > /sys/class/leds/beaglebone\:green\:usr2/trigger"
sudo sh -c "echo none > /sys/class/leds/beaglebone\:green\:usr3/trigger"
# Start your application
sudo sh -c "./startmyapp.sh > myapp.log"

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Replacing cape overlays

[Richard Weinberger]

Am 23.12.2015 um 00:03 schrieb Robert Nelson:
> On Tue, Dec 22, 2015 at 4:59 PM, Richard Weinberger  wrote:
>> Am 22.12.2015 um 23:48 schrieb Robert Nelson:
>>> On Tue, Dec 22, 2015 at 4:40 PM, Richard Weinberger
>>>  wrote:
 Hi!

 I own a BB-VIEW-43 cape:
 http://at.farnell.com/element14/bb-view-43/4-3inch-lcd-display-cape-for-beaglebone/dp/2364756#

 By requesting "BB-BONE-LCD4-01" the cape manager loads the dtbo from
 the cape's eeprom.
>>>
>>> It's actually worse then that, "BB-BONE-LCD4-01" = 16bit lcd display,
>>> while the "BB-VIEW-43" is a 24bit..
> 
> The eeprom only contains the "BB-BONE-LCD4-01" identifer...  The
> device tree overlay is built-into the kernel binary..

Ahhh, it is in the kernel binary. Thanks for pointing this out.
I was about to ask why it works even when the file is not present in 
/lib/firmware/

> The BB-View-43, swapped the red/blue color channels, so there's a hack
> for 3.8 to fix that..
> 
> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.8/patches/bb_view_lcd/0002-sitara_red_blue_swap_workaround.patch

Yeah, but setting to 24bits depth in xorg.conf also does the trick, no kernel 
patching needed.

Thanks,
//richard

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Replacing cape overlays

[Richard Weinberger]

Am 22.12.2015 um 23:48 schrieb Robert Nelson:
> On Tue, Dec 22, 2015 at 4:40 PM, Richard Weinberger
>  wrote:
>> Hi!
>>
>> I own a BB-VIEW-43 cape:
>> http://at.farnell.com/element14/bb-view-43/4-3inch-lcd-display-cape-for-beaglebone/dp/2364756#
>>
>> By requesting "BB-BONE-LCD4-01" the cape manager loads the dtbo from
>> the cape's eeprom.
> 
> It's actually worse then that, "BB-BONE-LCD4-01" = 16bit lcd display,
> while the "BB-VIEW-43" is a 24bit..

Hmmm, does this mean that the BB-VIEW-43's eeprom contains a completely
broken devicetree overlay? :(

Thanks,
//richard

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BeagleBone Black PRUs & Matlab

[gianluca . giorgini]

Hi, I'm an engineering student and for my final project I'm working with 
sensor fusion and computer vision algorithms for pose estimation. I would 
like to use the PRUs on my BeagleBone Black for the sensor fusion part, 
given the strict realtime requirements of my application but I find it to 
be an enormous effort to develop the algorithm using assembly or even c. I 
need to implement i2c protocol, pwm modulation and of course all the math 
routines necessary to work with matrices. My only option right now is to 
use another board (STM32F4 Discovery) but I would love to be able to 
condense everything on the BeagleBone because it would be much more 
efficient and simply elegant. Is there any way to access the PRUs with 
Matlab/Simulink? The documentation I found is pretty experimental and it 
would be a standalone project only to create the basic blocks for my 
application.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU Clocks phase shifting with respect to each other??

[Bill Gray]

Hi,

I am trying to debug a weird behavior.

I have code running on PRU 1 that creates a specific waveform on 8 pru 
output pins (pru1_0 - pru1_7).

I am trying to confirm the accuracy of my PRU 1 code by running code on PRU 
0 that watches the pins on PRU 1 (physically linked) and measures their 
period, duty, etc. against the CYCLE counter in the PRU0 control register.

All is well and good except that some of my measurements are off by +-1 
instruction... so where I hope to see 1280 instructions in a period, I am 
seeing 1279 or 1281.

Interestingly this changes... apparently regularly?  If I take the same 
measurement over and over I will get measurements for about 2 seconds 
 where the result is -1 and then 2 seconds of measurements where the result 
is +1... then back to -1, etc.

One explanation for this is that there is a slight phase shift between the 
PRU1 and PRU0 clocks. 

...But that goes against my understanding that the PRU clocks are both 
derived directly from the main CPU clock.

Still, the phase shift explanation fits the data really really nicely.

Is a phase shift between the PRU clocks even possible?

Thanks,

Bill


-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU Clocks phase shifting with respect to each other??

[Graham]

You should really have your test equipment running in a different clock 
domain than your device under test, and then trigger off your unit under 
test.
Very small phase or time differences between the unit under test and the 
test equipment can lead to major data differences.
You are trying to generate and measure on the same clock edges.  Very tiny 
time shifts can move you a whole clock cycle.
--- Graham

==


On Wednesday, December 23, 2015 at 1:27:22 PM UTC-6, Bill Gray wrote:
>
> Hi,
>
> I am trying to debug a weird behavior.
>
> I have code running on PRU 1 that creates a specific waveform on 8 pru 
> output pins (pru1_0 - pru1_7).
>
> I am trying to confirm the accuracy of my PRU 1 code by running code on 
> PRU 0 that watches the pins on PRU 1 (physically linked) and measures their 
> period, duty, etc. against the CYCLE counter in the PRU0 control register.
>
> All is well and good except that some of my measurements are off by +-1 
> instruction... so where I hope to see 1280 instructions in a period, I am 
> seeing 1279 or 1281.
>
> Interestingly this changes... apparently regularly?  If I take the same 
> measurement over and over I will get measurements for about 2 seconds 
>  where the result is -1 and then 2 seconds of measurements where the result 
> is +1... then back to -1, etc.
>
> One explanation for this is that there is a slight phase shift between the 
> PRU1 and PRU0 clocks. 
>
> ...But that goes against my understanding that the PRU clocks are both 
> derived directly from the main CPU clock.
>
> Still, the phase shift explanation fits the data really really nicely.
>
> Is a phase shift between the PRU clocks even possible?
>
> Thanks,
>
> Bill
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU Clocks phase shifting with respect to each other??

[Bill Gray]

Thanks Graham.

Yeah, I know.  The thing is that having the two share the same chip makes 
things really fast.  In my app I need to make about 125M different 
measurements, so the difference between a 1ms test and a 10ms makes a huge 
difference.

In fact, I don't need accuracy down to a single instruction.  The +-1 thing 
is not going to be a problem from an application perspective, I just want 
to know what is going on so that I can properly account for it.

There are a number of things that it could be, but a phase shift seems like 
the best fit at this point.

I thought about the notion that we are on the same clock edge, but that 
doesn't fit quite right in my mind.  If things were truly on the same clock 
edge... or even 2ps off, then given that everything is running in the same 
way every time, that 2ps should hit and get registered the same way each 
time.  It just doesn't make sense that it is dancing this way and that... 
or at least that doesn't make sense given what I know about how 
microcontrollers work.  Perhaps there is more to the story than I am aware 
of.

B


On Wednesday, December 23, 2015 at 1:44:00 PM UTC-8, Graham wrote:
>
> You should really have your test equipment running in a different clock 
> domain than your device under test, and then trigger off your unit under 
> test.
> Very small phase or time differences between the unit under test and the 
> test equipment can lead to major data differences.
> You are trying to generate and measure on the same clock edges.  Very tiny 
> time shifts can move you a whole clock cycle.
> --- Graham
>
> ==
>
>
> On Wednesday, December 23, 2015 at 1:27:22 PM UTC-6, Bill Gray wrote:
>>
>> Hi,
>>
>> I am trying to debug a weird behavior.
>>
>> I have code running on PRU 1 that creates a specific waveform on 8 pru 
>> output pins (pru1_0 - pru1_7).
>>
>> I am trying to confirm the accuracy of my PRU 1 code by running code on 
>> PRU 0 that watches the pins on PRU 1 (physically linked) and measures their 
>> period, duty, etc. against the CYCLE counter in the PRU0 control register.
>>
>> All is well and good except that some of my measurements are off by +-1 
>> instruction... so where I hope to see 1280 instructions in a period, I am 
>> seeing 1279 or 1281.
>>
>> Interestingly this changes... apparently regularly?  If I take the same 
>> measurement over and over I will get measurements for about 2 seconds 
>>  where the result is -1 and then 2 seconds of measurements where the result 
>> is +1... then back to -1, etc.
>>
>> One explanation for this is that there is a slight phase shift between 
>> the PRU1 and PRU0 clocks. 
>>
>> ...But that goes against my understanding that the PRU clocks are both 
>> derived directly from the main CPU clock.
>>
>> Still, the phase shift explanation fits the data really really nicely.
>>
>> Is a phase shift between the PRU clocks even possible?
>>
>> Thanks,
>>
>> Bill
>>
>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU Clocks phase shifting with respect to each other??

[Bill Gray]

Thanks so much guys.

The suggestion of using two BBB is great for getting the test program off
the same clock domain.  The issue there for me is speed.  The easy way to
get two BBBs working together would be to have them talk via ethernet.
This would be quite slow compared to my current setup which swaps all info
through PRU shared memory... perhaps an order of magnitude slower, perhaps
2?  I really need the speed in order to keep this test in the realm of
hours rather than days or weeks.

It is possible that I could speed things up using SPI or some such?  If I
find myself needing that last drop of accuracy I'll go for it.

For the time being I think you all have my weird behavior... ehm, my
program's weird behavior... pretty well explained, and so I will just live
with the +-1 instruction wiggle in my frequency calculations.

Thanks so much for the help.  I learned a lot.

Best,

Bill



On Wed, Dec 23, 2015 at 4:39 PM, Graham Haddock 
wrote:

> Bill:
>
> I don't think the PRU clocks are externally available.
>
> I don't know what your interface looks like, but if there was a clock line
> involved in the data transfer, or marking when data is valid, I would look
> at inverting or adding some delay in that line going to the receiving PRU.
> If your interface does not look like that, then I don't have a suggestion,
> other than using a second BBB for monitoring.
>
> --- Graham
>
> ==
>
> On Wed, Dec 23, 2015 at 5:21 PM, WZ9V  wrote:
>
>> Could you use a second BBB as the capture device instead?  That would
>> isolate the PRUs from each other and possibly allow for the HW capture that
>> was mentioned.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/zhCplP-SEok/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/zhCplP-SEok/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Bill Gray
Velkess
415 407 7356

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU Clocks phase shifting with respect to each other??

[Graham Haddock]

Bill:

I don't think the PRU clocks are externally available.

I don't know what your interface looks like, but if there was a clock line
involved in the data transfer, or marking when data is valid, I would look
at inverting or adding some delay in that line going to the receiving PRU.
If your interface does not look like that, then I don't have a suggestion,
other than using a second BBB for monitoring.

--- Graham

==

On Wed, Dec 23, 2015 at 5:21 PM, WZ9V  wrote:

> Could you use a second BBB as the capture device instead?  That would
> isolate the PRUs from each other and possibly allow for the HW capture that
> was mentioned.
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/zhCplP-SEok/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] PRU Clocks phase shifting with respect to each other??

[ybeagle3]

A few other bits of information is needed to get to the bottom of this.
- When you run the code on PRU0, what is running on PRU1? Do you put it in 
reset or at least have it doing something that cannot interfere?

- Is everything in the local memory to the PRU in use or in the shared memory?

- Is there any access outside of the PRUSS (i.e. DRAM, non PRUSS peripherals)?

- Is the ARM side also reading/probing the memory belonging to the PRU in use?

- Does the STALL register indicate that is occurring for some reason and 
enough to account for the difference?

On Wednesday, December 23, 2015 11:27:22 Bill Gray wrote:
> Hi,
> 
> I am trying to debug a weird behavior.
> 
> I have code running on PRU 1 that creates a specific waveform on 8 pru
> output pins (pru1_0 - pru1_7).
> 
> I am trying to confirm the accuracy of my PRU 1 code by running code on PRU
> 0 that watches the pins on PRU 1 (physically linked) and measures their
> period, duty, etc. against the CYCLE counter in the PRU0 control register.
> 
> All is well and good except that some of my measurements are off by +-1
> instruction... so where I hope to see 1280 instructions in a period, I am
> seeing 1279 or 1281.
> 
> Interestingly this changes... apparently regularly?  If I take the same
> measurement over and over I will get measurements for about 2 seconds
>  where the result is -1 and then 2 seconds of measurements where the result
> is +1... then back to -1, etc.
> 
> One explanation for this is that there is a slight phase shift between the
> PRU1 and PRU0 clocks.
> 
> ...But that goes against my understanding that the PRU clocks are both
> derived directly from the main CPU clock.
> 
> Still, the phase shift explanation fits the data really really nicely.
> 
> Is a phase shift between the PRU clocks even possible?
> 
> Thanks,
> 
> Bill

-- 
Hunyue Yau
http://www.hy-research.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU Clocks phase shifting with respect to each other??

[Charles Steinkuehler]

On 12/23/2015 5:17 PM, Bill Gray wrote:
> Fascinating!  Thanks guys.
> 
> Graham, 
> Frequency counting is exactly what I am trying to here, and +-1 is exactly 
> what I am seeing, so that makes perfect sense. I was not aware that the PRU 
> clocks were physically available on the BBB!  What fun! Where can I find 
> the leads to mess with?  Perhaps I could overclock them?  Oh the 
> possibilities!

The PRU clock is not available outside the chip.  It is driven by an
internal PLL (see the TRM sections 8 and 15 for details).

> Charles,
> I'm not sure that I am understanding your suggestions correctly.  
> 
> I think that the hardware timers present a couple of problems.  Please 
> correct me where I am wrong. First, I think they run at max 25Mhz, so they 
> have a resolution of 40nS, this is 4x worse than the +-5nS resolution I'm 
> currently getting using my CYCLE clock scheme... clock edge problems 
> included.  Also, and perhaps more importantly, I need to measure the phase 
> shift between the waveform on various pins and so I would need to start and 
> stop the hardware timer with 2 different signals.  Is this possible? 
>  Simple?  My uniformed instinct is hard and slow.

The eCAP timers are in the PD_PER_L4LS_GCLK domain, which typically
runs at 100 MHz.  So you should have the same or better timing
granularity as with the PRU.  Yes, the PRU runs at 200 MHz, but you
need at least a 2 instruction inner loop, which has a maximum
effective frequency of 100 MHz.

To use the hardware timers, refer to section 15.3 of the AM335x
Technical Reference Manual (TRM), which shows how you can configure
the eCAP timer to measure pulse timings.  I suspect one of the methods
shown in section 15.3.3.x will do what you need.

Also note that in addition to the "standard" eCAP modules connected to
the ARM core (referred to above), there is a dedicated eCAP module in
the PRU domain which you might find easier to deal with (since you're
writing PRU code for this already).  The documentation is a bit fuzzy
on the clock for the PRU eCAP module (or I didn't find the correct
page/section).  But it should be at least 100 MHz, and might even run
at the 200 MHz PRU clock rate.

Regardless, it's a *LOT* easier to measure pulse timing using hardware
designed for that purpose vs. writing code and dedicating an entire
PRU core to just measuring edges.  And fortunately, the AM3358 is
aimed at industrial control so it has several fancy timers (and
capture/compare units, and quadrature encoder inputs, and PWM outputs,
and other great stuff!) ready for you to use!  :)

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] How to setup a cross-toolchain of BBB with proper sysroot on CentOS or Windows?

[darklightwu]

Hi, Everyone:

I'm going to setup a cross-toolchain of BBB for developers using CentOS or 
Windows. 

I have read the Cross *Toolchain* for Debian Wheezy 
,
 
which told about creating the cross-toolchain. But it did not find a way to 
generate the sysroot. The sysroot should include all the libraries and 
headers that I need to distribute. I think it has to be created in some 
way. Anyone can share something useful to build the sysroot? 

Thanks!
dlw

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PRU Clocks phase shifting with respect to each other??

[Bill Gray]

Fascinating!  Thanks guys.

Graham, 
Frequency counting is exactly what I am trying to here, and +-1 is exactly 
what I am seeing, so that makes perfect sense. I was not aware that the PRU 
clocks were physically available on the BBB!  What fun! Where can I find 
the leads to mess with?  Perhaps I could overclock them?  Oh the 
possibilities!

Charles,
I'm not sure that I am understanding your suggestions correctly.  

I think that the hardware timers present a couple of problems.  Please 
correct me where I am wrong. First, I think they run at max 25Mhz, so they 
have a resolution of 40nS, this is 4x worse than the +-5nS resolution I'm 
currently getting using my CYCLE clock scheme... clock edge problems 
included.  Also, and perhaps more importantly, I need to measure the phase 
shift between the waveform on various pins and so I would need to start and 
stop the hardware timer with 2 different signals.  Is this possible? 
 Simple?  My uniformed instinct is hard and slow.

I'm also interested in the Ethernet "wall clock" idea.  I just read up on 
it, and it seems to be another 200Mhz clock, just like the CYCLE counter. 
 I'm under the impression that the CYCLE counter does not stall (that is 
what the STALL counter is for) and so I'm not sure what the ethernet 
counter would provide... if I needed a second counter it would be super 
great, but for this app one is enough.

Thanks again,

Bill


On Wednesday, December 23, 2015 at 2:37:43 PM UTC-8, Charles Steinkuehler 
wrote:
>
> Have you looked at the wall clock differences, or just the number of 
> instructions executed as a proxy for the time taken?  It's possible 
> for PRU instructions to stall (accessing resources outside the PRU 
> domain, or when both PRU cores try to access the same resource).  So 
> you might be seeing a timing effect (real-world signal propagation 
> time between the two PRU cores moving forward/backward a clock edge), 
> or you may be running a different number of instructions in the same 
> amount of time.  Or both. 
>
> You can use the Ethernet timer in the PRU as a "wall clock" that is 
> unaffected by any PRU instruction stalls, but if you're wanting to 
> rapidly and accurately measure time periods, use the hardware timers 
> in capture mode.  That's what they're for, and you'll have single 
> clock cycle accuracy.  The PRU will always have at least a few 
> instructions of uncertainty since it takes more than one instruction 
> to sample the value and capture the current "time". 
>
> On 12/23/2015 4:02 PM, Bill Gray wrote: 
> > Thanks Graham. 
> > 
> > Yeah, I know.  The thing is that having the two share the same chip 
> makes 
> > things really fast.  In my app I need to make about 125M different 
> > measurements, so the difference between a 1ms test and a 10ms makes a 
> huge 
> > difference. 
> > 
> > In fact, I don't need accuracy down to a single instruction.  The +-1 
> thing 
> > is not going to be a problem from an application perspective, I just 
> want 
> > to know what is going on so that I can properly account for it. 
> > 
> > There are a number of things that it could be, but a phase shift seems 
> like 
> > the best fit at this point. 
> > 
> > I thought about the notion that we are on the same clock edge, but that 
> > doesn't fit quite right in my mind.  If things were truly on the same 
> clock 
> > edge... or even 2ps off, then given that everything is running in the 
> same 
> > way every time, that 2ps should hit and get registered the same way each 
> > time.  It just doesn't make sense that it is dancing this way and 
> that... 
> > or at least that doesn't make sense given what I know about how 
> > microcontrollers work.  Perhaps there is more to the story than I am 
> aware 
> > of. 
> > 
> > B 
> > 
> > 
> > On Wednesday, December 23, 2015 at 1:44:00 PM UTC-8, Graham wrote: 
> >> 
> >> You should really have your test equipment running in a different clock 
> >> domain than your device under test, and then trigger off your unit 
> under 
> >> test. 
> >> Very small phase or time differences between the unit under test and 
> the 
> >> test equipment can lead to major data differences. 
> >> You are trying to generate and measure on the same clock edges.  Very 
> tiny 
> >> time shifts can move you a whole clock cycle. 
> >> --- Graham 
> >> 
> >> == 
> >> 
> >> 
> >> On Wednesday, December 23, 2015 at 1:27:22 PM UTC-6, Bill Gray wrote: 
> >>> 
> >>> Hi, 
> >>> 
> >>> I am trying to debug a weird behavior. 
> >>> 
> >>> I have code running on PRU 1 that creates a specific waveform on 8 pru 
> >>> output pins (pru1_0 - pru1_7). 
> >>> 
> >>> I am trying to confirm the accuracy of my PRU 1 code by running code 
> on 
> >>> PRU 0 that watches the pins on PRU 1 (physically linked) and measures 
> their 
> >>> period, duty, etc. against the CYCLE counter in the PRU0 control 
> register. 
> >>> 
> >>> All is well and good except that some of my measurements are off by 
> +-1 
> >>> instruction... so 

[beagleboard] ubuntu 14.04 ubuntu/temppwd not working

[Ian Downard]

I just flashed a beaglebone black with this prebuilt ubuntu 14.04 image:
https://rcn-ee.com/rootfs/2015-12-11/flasher/BBB-eMMC-flasher-ubuntu-14.04.3-console-armhf-2015-12-11-2gb.img.xz

However the default ubuntu / temppwd username and password are not 
working.  Do I have the wrong username and/or password?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] ubuntu 14.04 ubuntu/temppwd not working

[Robert Nelson]

On Wed, Dec 23, 2015 at 2:49 PM, Ian Downard  wrote:
> I just flashed a beaglebone black with this prebuilt ubuntu 14.04 image:
> https://rcn-ee.com/rootfs/2015-12-11/flasher/BBB-eMMC-flasher-ubuntu-14.04.3-console-armhf-2015-12-11-2gb.img.xz
>
> However the default ubuntu / temppwd username and password are not working.
> Do I have the wrong username and/or password?

That's the correct one. ;) double check your serial/keyboard/etc..

Ubuntu 14.04.3 LTS arm ttyO0

rcn-ee.net console Ubuntu Image 2015-12-11

Support/FAQ: http://elinux.org/BeagleBoardUbuntu

default username:password is [ubuntu:temppwd]

arm login: ubuntu
Password:

ubuntu@arm:~$

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to setup a cross-toolchain of BBB with proper sysroot on CentOS or Windows?

[Robert Nelson]

On Wed, Dec 23, 2015 at 1:46 PM,   wrote:
> Hi, Everyone:
>
> I'm going to setup a cross-toolchain of BBB for developers using CentOS or
> Windows.
>
> I have read the Cross Toolchain for Debian Wheezy, which told about creating
> the cross-toolchain. But it did not find a way to generate the sysroot. The
> sysroot should include all the libraries and headers that I need to
> distribute. I think it has to be created in some way. Anyone can share
> something useful to build the sysroot?

One of the big issues with wheezy, it had fairly old libc, so any of
the pre-built linaro toolchains are just going to cause issues..

So for 'wheezy' it's just best to build on an armhf machine..

Now if you switch to jessie on the bbb. Jessie's multi-arch was much
better, so you can install debian jessie on your x86 and install all
the *armhf* libraries via apt..

here are the jessie cross toolchains:

http://www.emdebian.org/News/2014/20141025.html

In stretch it'll even be easier to cross..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU Clocks phase shifting with respect to each other??

[WZ9V]

Could you use a second BBB as the capture device instead?  That would isolate 
the PRUs from each other and possibly allow for the HW capture that was 
mentioned.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to setup a cross-toolchain of BBB with proper sysroot on CentOS or Windows?

[darklight wu]

2015/12/24/ 03:54，"Robert Nelson" wrote：
>
> On Wed, Dec 23, 2015 at 1:46 PM,   wrote:
> > Hi, Everyone:
> >
> > I'm going to setup a cross-toolchain of BBB for developers using CentOS
or
> > Windows.
> >
> > I have read the Cross Toolchain for Debian Wheezy, which told about
creating
> > the cross-toolchain. But it did not find a way to generate the sysroot.
The
> > sysroot should include all the libraries and headers that I need to
> > distribute. I think it has to be created in some way. Anyone can share
> > something useful to build the sysroot?
>
> One of the big issues with wheezy, it had fairly old libc, so any of
> the pre-built linaro toolchains are just going to cause issues..
Yes, that's why i am trying to build such a toolchain. I have not looked
into your script for wheezy. Is that workable?

>
> So for 'wheezy' it's just best to build on an armhf machine..
>
> Now if you switch to jessie on the bbb. Jessie's multi-arch was much
> better, so you can install debian jessie on your x86 and install all
> the *armhf* libraries via apt..
Since my customers insisted to use windows or CentOS as their dev env, how
can I make a tarball of the toolchain and sysroot and run it on CentOS and
Windows, no matter Wheezy or Jessie? For sysroot, how can i select
necessary libs and headers? I did not find any useful information or
discussion on creating sysroot that needs some customization.

>
> here are the jessie cross toolchains:
>
> http://www.emdebian.org/News/2014/20141025.html
>
> In stretch it'll even be easier to cross..
I am new for BBB. How stable is Jessie comparing with Wheezy? I am building
commercial product so stability is the most important thing. But anyway, we
will do evaluation.

Thanks!
dlw

>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.