[beagleboard] Re: 8 ADC input @20 KHz

[Lenny]

here is a thread talking about it, in which you can also find my code 
example among other info.

https://groups.google.com/forum/#!searchin/beagleboard/fast$20ADC/beagleboard/3AFiCNtxGis/RiWxHDiOWnMJ

On Saturday, October 3, 2015 at 5:01:26 PM UTC+2, Lenny wrote:
>
> Hi Rathin, 
> just to let you know: The BBB ADC's can sample at 1.6 MHz. That is, if you 
> multiplex the ADC on 8 inputs, each one of them can sample at 200kHz. I am 
> not familiar with user-friendly libraries like libpruio, so I cannot tell 
> you where they lose the time. But technically (e.g. by writing the 
> assembler instructions), 200 kHz is definitely possible, so you could 
> upgrade your project at a later moment without changing the hardware. The 
> price to pay (at the moment) is a little more customized code. But seeing 
> that people struggle already at 20kHz just hurts my eyes ;)
> Lenny
>
>

-- 
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: 8 ADC input @20 KHz

[Lenny]

Hi Rathin, 
just to let you know: The BBB ADC's can sample at 1.6 MHz. That is, if you 
multiplex the ADC on 8 inputs, each one of them can sample at 200kHz. I am 
not familiar with user-friendly libraries like libpruio, so I cannot tell 
you where they lose the time. But technically (e.g. by writing the 
assembler instructions), 200 kHz is definitely possible, so you could 
upgrade your project at a later moment without changing the hardware. The 
price to pay (at the moment) is a little more customized code. But seeing 
that people struggle already at 20kHz just hurts my eyes ;)
Lenny

-- 
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] Kernel 4.1.3-bone15 and 4.1.4-bone15 Cant load device overlay (I2C1, UART1, etc.)

[Lenny Baker]

Hi Robert,

I did some experimentation and got the overlays to load. I'm not an expert,
so admittedly I was grasping at differences I see on another, older SD card
I have working. On that card there is no initrd image. I renamed
initrd.img-4.1.4-bone15 to lmbinitrd.img-4.1.4-bone15 to remove it from the
uEnv load and now the overlays works.

Does this make any sense to you?

ubuntu@riptide-uuuv:/boot$ ls -l
total 20768
drwxr-xr-x 4 root root4096 Aug  7 12:05 dtbs
-rw-r--r-- 1 root root  133175 Aug  5 00:42 lmbconfig-4.1.4-bone15
-rw-r--r-- 1 root root 4246230 Aug  8 05:06 lmbinitrd.img-4.1.4-bone15
-rw-r--r-- 1 root root 3036293 Aug  5 00:42 lmbSystem.map-4.1.4-bone15
drwxr-xr-x 2 root root4096 Jun  9 13:52 uboot
-rw-r--r-- 1 root root 223 Aug  7 13:30 uEnv.txt
-rw-r--r-- 1 root root1022 Aug  8 05:20 uEnv.txt~
-rw-r--r-- 1 root root1032 Aug  8 05:26 uEnv.txt.test
-rwxr-xr-x 1 root root 6914656 Aug  7 10:33 vmlinuz-4.1.3-bone15
-rwxr-xr-x 1 root root 6903632 Aug  5 00:42 vmlinuz-4.1.4-bone15


ubuntu@riptide-uuuv:~$ i2cdetect -l
i2c-0   i2c OMAP I2C adapterI2C adapter
i2c-1   i2c OMAP I2C adapterI2C adapter
i2c-2   i2c OMAP I2C adapterI2C adapter


ubuntu@riptide-uuuv:/boot$ dmesg | grep i2c
[2.709984] omap_i2c 44e0b000.i2c: could not find pctldev for node
/ocp/l4_wkup@44c0/scm@21/pinmux@800/pinmux_i2c0_pins, deferring
probe
[2.710026] omap_i2c 4819c000.i2c: could not find pctldev for node
/ocp/l4_wkup@44c0/scm@21/pinmux@800/pinmux_i2c2_pins, deferring
probe
[3.718269] i2c /dev entries driver
[3.935362] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[3.970656] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
[5.391143] omap_i2c 4802a000.i2c: bus 1 rev0.11 at 100 kHz


ubuntu@riptide-uuuv:/boot$ dmesg | grep cape
[0.00] Kernel command line: console=ttyO0,115200n8
bone_capemgr.enable_partno=BB-I2C1,BB-UART1 root=/dev/mmcblk0p1 ro
rootfstype=ext4 rootwait fixrtc
[3.982669] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,414BBBK1610\x'
[3.989937] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[4.052219] bone_capemgr bone_capemgr: slot #0: No cape found
[4.112220] bone_capemgr bone_capemgr: slot #1: No cape found
[4.172216] bone_capemgr bone_capemgr: slot #2: No cape found
[4.232213] bone_capemgr bone_capemgr: slot #3: No cape found
[4.238001] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-I2C1'
VER 'N/A' PR '0'
[4.246084] bone_capemgr bone_capemgr: slot #4: override
[4.251436] bone_capemgr bone_capemgr: Using override eeprom data at
slot 4
[4.258445] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,BB-I2C1'
[4.267467] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-UART1'
VER 'N/A' PR '0'
[4.275639] bone_capemgr bone_capemgr: slot #5: override
[4.280989] bone_capemgr bone_capemgr: Using override eeprom data at
slot 5
[4.287995] bone_capemgr bone_capemgr: slot #5: 'Override Board
Name,00A0,Override Manuf,BB-UART1'
[4.297372] bone_capemgr bone_capemgr: initialized OK.
[5.403659] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-I2C1-00A0.dtbo'
loaded; overlay id #1
[5.418457] bone_capemgr bone_capemgr: slot #5: dtbo
'BB-UART1-00A0.dtbo' loaded; overlay id #0




On Sat, Aug 8, 2015 at 1:09 AM Lenny Baker  wrote:

> Hi Robert,
>
> I did the git pull and reran install.sh. After that I still had the same
> cape manager load errors. The output of dmesg | grep i2c and dmesg | grep
> cape, remains the same as before.
>
> Thanks  for your time with this. If there's anything else useful I can
> send from my setup, please let me know.
> Lenny
>
> ubuntu@riptide-uuuv:~$ cd bb.org-overlays/
> ubuntu@riptide-uuuv:~/bb.org-overlays$ git pull
> remote: Counting objects: 2, done.
> remote: Compressing objects: 100% (2/2), done.
> remote: Total 2 (delta 0), reused 0 (delta 0), pack-reused 0
> Unpacking objects: 100% (2/2), done.
> From https://github.com/beagleboard/bb.org-overlays
>1827367..99d7893  master -> origin/master
> Updating 1827367..99d7893
> Fast-forward
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> On Fri, Aug 7, 2015 at 11:24 AM Robert Nelson 
> wrote:
>
>> On Fri, Aug 7, 2015 at 10:19 AM, Lenny Baker 
>> wrote:
>> > Hi Robert , I see:
>> >
>> > ubuntu@arm:~$ echo $PATH
>> >
>> /home/ubuntu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
>>
>> Okay, even stranger, then it should have worked..
>>
>> So on Debian testing (stretch

Re: [beagleboard] Kernel 4.1.3-bone15 and 4.1.4-bone15 Cant load device overlay (I2C1, UART1, etc.)

[Lenny Baker]

Hi Robert,

I did the git pull and reran install.sh. After that I still had the same
cape manager load errors. The output of dmesg | grep i2c and dmesg | grep
cape, remains the same as before.

Thanks  for your time with this. If there's anything else useful I can send
from my setup, please let me know.
Lenny

ubuntu@riptide-uuuv:~$ cd bb.org-overlays/
ubuntu@riptide-uuuv:~/bb.org-overlays$ git pull
remote: Counting objects: 2, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 2 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (2/2), done.
>From https://github.com/beagleboard/bb.org-overlays
   1827367..99d7893  master -> origin/master
Updating 1827367..99d7893
Fast-forward
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


On Fri, Aug 7, 2015 at 11:24 AM Robert Nelson 
wrote:

> On Fri, Aug 7, 2015 at 10:19 AM, Lenny Baker 
> wrote:
> > Hi Robert , I see:
> >
> > ubuntu@arm:~$ echo $PATH
> >
> /home/ubuntu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
>
> Okay, even stranger, then it should have worked..
>
> So on Debian testing (stretch), bin, usr/bin was moved infront of
> usr/local/bin
>
> echo $PATH
> /bin:/usr/bin:/usr/local/bin
>
> But, give this a shot..
>
>
> https://github.com/beagleboard/bb.org-overlays/commit/99d789309dd0eb164776c98de8cd070e18fab99c
>
> (git pull ; ./install.sh)
>
> 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] Kernel 4.1.3-bone15 and 4.1.4-bone15 Cant load device overlay (I2C1, UART1, etc.)

[Lenny Baker]

Hi Robert , I see:

ubuntu@arm:~$ echo $PATH
/home/ubuntu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

On Fri, Aug 7, 2015 at 10:38 AM Robert Nelson 
wrote:

> On Fri, Aug 7, 2015 at 8:53 AM,   wrote:
> > Hi Folks,
> >
> > I created a fresh Ubuntu SD card for my BBB using the directions at:
> > https://eewiki.net/display/linuxonarm/BeagleBone+Black# and the end
> result
> > is I get failed loads from the cape manager. After the install I modified
> > /etc/network/interfaces to use wlan0. Anything else I modified was in
> line
> > with the wiki page (setting up the serial console, etc.) I'm interested
> in
> > using the overlays, so I followed the directions for the 4.1.x cape
> manager.
> > I have a feeling I'm doing something stupid, but based on searching
> around
> > here and the wiki page, I think I did it all per instruction. Any help is
> > appreciated if its clear what I'm screwing up
>
> I "think" i finally figured this out for ubuntu...
>
> What does:
> echo $PATH
>
> show?
>
> 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] Kernel 4.1.3-bone15 and 4.1.4-bone15 Cant load device overlay (I2C1, UART1, etc.)

[lenny . m . baker]

Hi Folks,

I created a fresh Ubuntu SD card for my BBB using the directions at: 
https://eewiki.net/display/linuxonarm/BeagleBone+Black# and the end result 
is I get failed loads from the cape manager. After the install I modified 
/etc/network/interfaces to use wlan0. Anything else I modified was in line 
with the wiki page (setting up the serial console, etc.) I'm interested in 
using the overlays, so I followed the directions for the 4.1.x cape 
manager. I have a feeling I'm doing something stupid, but based on 
searching around here and the wiki page, I think I did it all per 
instruction. Any help is appreciated if its clear what I'm screwing up

 My uEnv.txt is at /boot/uEnv.txt and contains the following text:

uname_r=4.1.4-bone15

> dtb=am335x-boneblack-overlay.dtb

> ##Disable HDMI

> ##cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

> ##Enable interfaces
cape_enable=bone_capemgr.enable_partno=BB-I2C1,BB-UART1


I also used ./dtc-overlay.sh and ./install.sh to ensure dtc was updated and 
the overlays were installed. Here's some relevant output (I think):


ubuntu@arm:~$ dmesg | grep cape
[0.00] Kernel command line: console=ttyO0,115200n8 
bone_capemgr.enable_partno=BB-I2C1,BB-UART1 root=/dev/mmcblk0p1 ro 
rootfstype=ext4 rootwait fixrtc
[4.278322] bone_capemgr bone_capemgr: Baseboard: 
'A335BNLT,00C0,414BBBK1610\x'
[4.285647] bone_capemgr bone_capemgr: 
compatible-baseboard=ti,beaglebone-black - #slots=4
[4.352231] bone_capemgr bone_capemgr: slot #0: No cape found
[4.412246] bone_capemgr bone_capemgr: slot #1: No cape found
[4.472227] bone_capemgr bone_capemgr: slot #2: No cape found
[4.542251] bone_capemgr bone_capemgr: slot #3: No cape found
[4.548040] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-I2C1' 
VER 'N/A' PR '0'
[4.556091] bone_capemgr bone_capemgr: slot #4: override
[4.561428] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 4
[4.568434] bone_capemgr bone_capemgr: slot #4: 'Override Board 
Name,00A0,Override Manuf,BB-I2C1'
[4.577416] bone_capemgr bone_capemgr: enabled_partno PARTNO 'BB-UART1' 
VER 'N/A' PR '0'
[4.585554] bone_capemgr bone_capemgr: slot #5: override
[4.590888] bone_capemgr bone_capemgr: Using override eeprom data at 
slot 5
[4.597891] bone_capemgr bone_capemgr: slot #5: 'Override Board 
Name,00A0,Override Manuf,BB-UART1'
[4.607175] bone_capemgr bone_capemgr: initialized OK.
[5.632329] bone_capemgr bone_capemgr: loader: failed to load slot-5 
BB-UART1:00A0 (prio 0)
[5.642292] bone_capemgr bone_capemgr: loader: failed to load slot-4 
BB-I2C1:00A0 (prio 0)

ubuntu@arm:~$ dmesg | grep i2c
[2.710001] omap_i2c 44e0b000.i2c: could not find pctldev for node 
/ocp/l4_wkup@44c0/scm@21/pinmux@800/pinmux_i2c0_pins, deferring 
probe
[2.710043] omap_i2c 4819c000.i2c: could not find pctldev for node 
/ocp/l4_wkup@44c0/scm@21/pinmux@800/pinmux_i2c2_pins, deferring 
probe
[3.972735] i2c /dev entries driver
[4.230841] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[4.266307] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
ubuntu@arm:~$


ubuntu@arm:~$ cat /proc/cmdline
console=ttyO0,115200n8 bone_capemgr.enable_partno=BB-I2C1,BB-UART1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait fixrtc


ubuntu@arm:~$ uname -r
4.1.4-bone15

ubuntu@arm:~$ i2cdetect -l
i2c-0   i2c OMAP I2C adapterI2C adapter
i2c-2   i2c OMAP I2C adapterI2C adapter

ubuntu@arm:~$ sudo cat /dev/ttyS1
cat: /dev/ttyS1: Input/output error






-- 
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] Equivalent of PRU on main CPU

[Lenny]

Hehe, a beast indeed :)

I downloaded the StarterWare software and I like it. I'll summarize my 
current understanding, and if someone wants to correct me in case its 
necessary, I'll be glad:
As far as I understand, StarterWare does not use an OS overhead, so you get 
to execute your code directly in the MPU - bare metal access so to say. I 
imagine the same can be accomplished by properly embedding your compiled 
file into a bootloader at the right place. The provided examples are 
reasonably clear, for example to set a GPIO pin, you find the instruction

GPIOPinWrite(GPIO_INSTANCE_ADDRESS,
 GPIO_INSTANCE_PIN_NUMBER,
 GPIO_PIN_LOW);

Checking what is behind is really a simple instruction
HWREG(baseAdd + GPIO_CLEARDATAOUT) = (1 << pinNumber);
where the macro HWREG only provides a properly shaped pointer to the 
address in brackets. Using these examples is equivalent to a painful and 
time-consuming study of the TRM, where you can find the addresses of all 
those registers. 

So as far as I understand, this operation should also only take the 
equivalent of one single assembler instruction after compilation. Two 
questions now remain:
1) how many cycles does it take the MPU to execute this instruction (or any 
other one - this is not specified in the TRM but I am sure it is somewhere 
in the ARM documention)
2) how long does it take until the value arrives at the output pin

The second question aims at Charles concern. Again, from the TRM i deduce 
that for example the GPIO modules are connected to the MPU through the L4 
interconnect. The interface clock rate is specified in the GPIO chapter of 
the TRM to be 100 MHz. Now I do not understand how this bus works in 
detail, but the fact that it can handle several sources and destinations 
simultaneously raises the concern that there is a buffer involved that 
comes with some extra latency. But I would assume that by running only the 
one code snippet that I define, and no OS processes in the background, that 
all other devices are disabled, and therefore the bus is really only used 
when my program does so. So there should be top prority handling for my 
packets and therefore they should arrive with minimal, and up to clock 
missynchronization, deterministic delay. So I would just estimate a delay 
of a few interface clock cycles, so a latency less than - say - 1/20MHz. Is 
my reasoning correct here or do I forget something?

I guess my next steps will be reading on the MPU itself, as to whether one 
can hope to implement really fast algorithms on a very low level here. If 
Im not mistaken, this 

 
is the document to read. A first glance tells me that maybe I'll understand 
what the A in Cortex-A9 actually means on a low level :)

If there is a catch that I am not aware of - thanks for letting me know! 

-- 
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] Equivalent of PRU on main CPU

[Lenny]

Thanks for your post William, 
the idea to start an executable from uboot sounds very close to what I want 
i guess. My question here would be which document is equivalent to the 
PruReferenceGuide, such that I can find out how to talk to the various 
hardware pieces such as memory and inputs/outputs and the NEON core etc., 
and which compiler I would have to use (in the best case a C compiler with 
inline assembler support). And if available, a library with some useful 
functions such as a accessing serial port (USB) and maybe even Ethernet 
(though i guess that would require interrupts and all sorts of other 
overhead) would be just perfect! 

But actually I have just now looked into starterware (
http://processors.wiki.ti.com/index.php/StarterWare_02.00.01.01_User_Guide#Serial_Peripherals),
 
and it really looks amazingly close to what I had in mind. There are lots 
of examples and I guess i'll start testing some of them. 

@Charles: Thanks for the warning :) Im still still a noob when it comes to 
processor architecture. The application I have in mind (FIR filter) is 
computationally intensive, but does not need a huge data throughput (few 
MSps would be enough, which I know I can delegate to the PRU if necessary). 
I found the idea of using the main processor appealing as I read somewhere 
about its SIMD capability (doing 16 or 32 multiplications and accumulates 
simultaneously, which would theoretically allow something like 16-32Gflops, 
right?), and floating point arithmetics. 

So if you confirm that all those advantages are lost somewhere in the 
communication between core and dedicated modules, that would be a pity but 
indeed save me a lot of time :) 

And for curiosity/ease of later implementation/number of available 
input-output ports: What delay and number of necessary instructions can I 
expect for exchanging one or multiple bits between the main processor and a 
GPIO port? More than 10 cycles?

Thanks so much for your suggestins and help! 




-- 
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] Equivalent of PRU on main CPU

[Lenny]

Thanks Robert, 

that rt linux project seems very interesting, but as you say, it is still 
too high-level / multitasking in order to beat the PRU. So one would have 
to remove basically all the remaining functionality from rt linux to arrive 
at something fast and deterministic at the ns timescale i guess..

Thanks anyways!

On Wednesday, August 5, 2015 at 7:00:50 PM UTC+2, RobertCNelson wrote:
>
> On Wed, Aug 5, 2015 at 11:56 AM, Lenny  > wrote: 
> > Hello everyone, 
> > 
> > I find it a pity that the PRU runs only at 200 MHz and not at the full 1 
> > GHz. I was wondering if there exist any linux distributions (or not 
> linux at 
> > all) which allow to run real-time code on the main CPU. Of course, this 
> > would have to disable all linux features that are not explicitly 
> implemented 
> > in the code, but in many cases I think that could be desirable. Has 
> anyone 
> > ever done something like that? I guess it boils down to using an 
> extremely 
> > minimized kernel / completely removing the OS and only running the 
> necessary 
> > stuff, but I am by no means an expert in low-level linux programming and 
> was 
> > wondering if there exists some code out there which would make it easier 
> for 
> > me to start with. 
> > In the end, I would like to use more powerful instructions of the main 
> CPU 
> > such as floating point arithmetics and the higher speed to implement 
> > PRU-like functionality for DSP in real-time. 
>
>
> rt linux: https://rt.wiki.kernel.org/index.php/Main_Page 
>
> sudo apt-get update 
> sudo apt-get install linux-image-4.1.3-ti-rt-r7 
> sudo reboot 
>
> but your going to find, the pru is just faster and more deterministic... 
>
> 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] Equivalent of PRU on main CPU

[Lenny]

Hello everyone, 

I find it a pity that the PRU runs only at 200 MHz and not at the full 1 
GHz. I was wondering if there exist any linux distributions (or not linux 
at all) which allow to run real-time code on the main CPU. Of course, this 
would have to disable all linux features that are not explicitly 
implemented in the code, but in many cases I think that could be desirable. 
Has anyone ever done something like that? I guess it boils down to using an 
extremely minimized kernel / completely removing the OS and only running 
the necessary stuff, but I am by no means an expert in low-level linux 
programming and was wondering if there exists some code out there which 
would make it easier for me to start with. 
In the end, I would like to use more powerful instructions of the main CPU 
such as floating point arithmetics and the higher speed to implement 
PRU-like functionality for DSP in real-time.

Thanks in advance! 


-- 
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: What happens on read/write conflict on the PRU scrartchpad?

[Lenny]

Cool, thanks for the update Carlos! I thought a little about your problem 
and was wondering whether you are really at the limit of the PRUs 
capability:
You say you have roughly 20kSps with 10bit resolution for four outputs, so 
roughly 200k updates of the output pins per second. That means you need 
roughly 10 instructions for changing the PWM outputs to their next value. 
What do you think of the following implementation? Is it not optimal but I 
think its performance should be comparable to yours but roughly 10x faster:

START:
XIN 10,r0,120 //fetches data from scratchpad0 - each register holds 
8x4bits, where bit 0,4,8,12 defines four consecutive values for output 0, 
bit 1,5,9,13 for output 1 and so on. 
AND R30.b0, r0.b0, 0x0F  //move the bits 0:3 of r0.b0 to r30.b0 (the other 
bits of R30.b0 are set to zero by the AND) - here it is assumed that your 
output pins correspond to r30[0:3]. That can easily be adapted to any other 
consecutive 4 bits by using a LSL instruction
LSR R30.b0,r0.b0,4  //move the bits 4:7 of r0.b0 to r30.b0 (the other 
bits of R30.b0 are set to zero by the LSR)
AND R30.b0, r0.b1, 15  //same for r0.b1
LSR R30.b0,r0.b1,4  
//repeat this instruction for all other bytes up to...
AND R30.b0, r29.b3, 15  
LSR R30.b0,r29.b3,4  
//up to here, 30*8=240 sets of 4 bits were written to the output
XIN 11,r0,120 //fetches data from scratchpad1
//repeat the write operations
XIN 12,r0,120 //fetches data from scratchpad2
//repeat the write operations
XIN 14,r0,120 //fetches data from other PRU
//repeat the write operations
JMP START
//here a total of 4*240=960 writes on 4 digital outputs r30[0:3] has been 
executed. So we have already about 9.9 bits resolution and - given an 
overhead of 5 cycles - an update rate of 200MHz*960/965 = roughly 199MHz. 
That is the actual output will be roughly 200kSps. 

The 960 cycles leave plenty of time for PRU1 to perform 4 LBBO operations 
that are 120byte wide: Typically each one should take less than 80 cyccles. 
So the code will look sth like
LBBO from DRAM filling all registers r0:r29
XOUT 10,r0,120
LBBO from DRAM filling all registers r0:r29
XOUT 11,r0,120
LBBO from DRAM filling all registers r0:r29
XOUT 12,r0,120
LBBO from DRAM filling all registers r0:r29
XOUT 14,r0,120
//here the code will stall until PRU0 requests the data with the 
corresponding XIN operation. 

This is the simplest implementation. You can make it more sophisticated by 
inserting some logic into PRU1 code that modulates the output data over 
several cycles to get a higher output resolution. But even in this 
implementation, the only irregularity comes from the XIN's and the final 
jump operation in PRU0, which should be taken into account in the algorithm 
that generates the data which fills all of the registers (the value of 
register r29[28:31] counts twice if its in the scratchpad, and threefold if 
its in PRU1). This is a complication, but actually leads to a neat trick: 
If you want to invest some of the gained speed into higher resolution, you 
can increase the weight of any 4bit datapoint by inserting a loop after it 
that just holds that particular output value for that number of cycles (you 
need to reserve a register for the counter in that case, but you will still 
gain in resolution). If one loop of the PRU0 code takes much more than 1024 
cycles, you should also insert a loop of similar length into PRU1 code in 
order to not have PRU1 stall more than 1024cycles for PRU0's XIN command. 

-- 
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: What happens on read/write conflict on the PRU scrartchpad?

[Lenny]

Oh sorry, I didn't see your PS ;)

In case that one PRU reads from the scratchpad and in the same cycle the 
other PRU writes to it, I am pretty sure that there will be no conflicts. 
It is the standard behaviour when you program sequential logic with a 
hardware description language. However, the read operation will yield the 
"old" data from the scratchpad, that is the ones from before the write 
operation. 

But as you have lots of time to waste on one PRU, it might be a better idea 
to use direct PRU transfer (XIN/XOUT with device 14), without the 
scratchpad in between. Lets say your PRU0 (the time-critical one) executes 
N instructions per loop. Then just let PRU1 make an update of the important 
registers every M cycles (with M
> Hi Carlos, 
>
> have you looked at the PruReferenceGuide section 5.2.4.2 (p.34-35)? Let me 
> copy paste here:
>
>
> A collision occurs when two XOUT commands simultaneously access the same 
> asset or device ID.
> Table 20 shows the priority assigned to each operation when a collision 
> occurs. In direct connect mode
> (device ID 14), any PRU transaction will be terminated if the stall is 
> greater than 1024 cycles. This will
> generate the event pr<1/0>_xfr_timeout that is connected to INTC.
>
> Table 20. Scratch Pad XFR Collision Conditions
>
> Operation Collision Handling
> PRU XOUT (→) bank[j] 
> If both PRU cores access the same bank simultaneously, PRU0
> is given priority. PRU1 will temporarily stall until the PRU0
> operation completes.
>
> PRU XOUT (→) PRU If PRU 
> executes XOUT before PRU executes XIN, then
> PRU will stall until either PRU executes XIN or the stall
> is greater than 1024 cycles.
>
> PRU XIN (←) PRU If PRU executes XIN before PRU executes XOUT, 
> then
> PRU will stall until either PRU executes XIN or the stall
> is greater than 1024 cycles.
>
>
> I used the direct XOUT / XIN with device ID=14 to synchronize the two 
> PRU's. There were no unexpected problems, everything like described in the 
> manual.
>
> Let me know if this wasnt your problem. Bests, Lenny
>
>
>

-- 
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: What happens on read/write conflict on the PRU scrartchpad?

[Lenny]

Hi Carlos, 

have you looked at the PruReferenceGuide section 5.2.4.2 (p.34-35)? Let me 
copy paste here:


A collision occurs when two XOUT commands simultaneously access the same 
asset or device ID.
Table 20 shows the priority assigned to each operation when a collision 
occurs. In direct connect mode
(device ID 14), any PRU transaction will be terminated if the stall is 
greater than 1024 cycles. This will
generate the event pr<1/0>_xfr_timeout that is connected to INTC.

Table 20. Scratch Pad XFR Collision Conditions

Operation Collision Handling
PRU XOUT (→) bank[j] 
If both PRU cores access the same bank simultaneously, PRU0
is given priority. PRU1 will temporarily stall until the PRU0
operation completes.

PRU XOUT (→) PRU If PRU 
executes XOUT before PRU executes XIN, then
PRU will stall until either PRU executes XIN or the stall
is greater than 1024 cycles.

PRU XIN (←) PRU If PRU executes XIN before PRU executes XOUT, 
then
PRU will stall until either PRU executes XIN or the stall
is greater than 1024 cycles.


I used the direct XOUT / XIN with device ID=14 to synchronize the two 
PRU's. There were no unexpected problems, everything like described in the 
manual.

Let me know if this wasnt your problem. Bests, Lenny


-- 
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: How fast/reliable is ADC sampling from the PRU

[Lenny]

The ADC can definitely sample at 1.6 MHz, that is four channels could go up 
to 400 kHz each (sequentially). The 1.6 MHz correspond to the minimal 15 
steps for one sample when setting the ADC clock to 24 MHz, that is, setting 
the CLKDIV register to zero, and not to 7 as it is set by default (which 
explains your 200kHz theoretical sampling rate). I have my own assembler 
code which works, but as it is a bit older, it is not in line with newer 
things like libpruio. If you want to have a look at my code to get it 
working let me know and I'll send it to you. 

-- 
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: How to synchronize ADC sampling clock ？

[Lenny]

Hi, 
I never tried to read several ADC channels "simultaneously", but as far as 
I understand the TRM section on this, there is really only one hardware ADC 
witht multiplexer to make 8 channels. One acquisition takes at least 15 ADC 
clock cycles (625ns), that is for 6 channels, you would have to read one 
value after the other, giving you a 625 ns delay between subsequent values 
and a maximum 6-channel-samling rate of 1/3750ns = roughly 250kHz. As said 
above, jitter won't be too much of a problem here. Since the readout of the 
FIFO buffer also induces some delay, you should more realistically consider 
200-250 kHz. 
So if you can tolerate the delay of digitalization of the different analog 
inputs, the integrated ADC will work, otherwise you should consider using 
an external ADC. 


On Wednesday, July 23, 2014 9:07:52 PM UTC+2, sun19...@gmail.com wrote:
>
> Hello, Lenny,
> your solution is good, thanks. Here is another question : is it capable of 
> synchronizing "multiple" ADC channels at one time ?
>
> I have read ADC driver limitation from TI :
>
> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver%27s_Guide#ADC_Driver_Limitations
>
> and you said that I can use the ADC in single-acquisition mode. -> Is it 
> capable of synchronizing "multiple channels" at one time? (because I need 
> to sample three-phase current and voltage signal, so the sum of them are 6 
> channels.)
>
> I am not sure "single-acquisition" is limitation of hardware (ADC) 
> naturally or just limitation of driver function? 
> If I use single-acquisition mode, then I need to consider the effect of 
> conversion time between one channel and another channel.
>
>
> Finally, If I could, please send your sample code for me to my gmail.  
> Thanks!
>
>

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

[beagleboard] Re: How to synchronize ADC sampling clock ？

[Lenny]

Hi, 

if you control the ADC from the PRU, you can use the ADC in 
single-acquisition mode and perform a new acquisition every 200 PRU cycles 
(every microsecond) for example (or whatever repetition rate you want), and 
therefore use the 200 MHz PRU clock as a low-jitter timer. This way you can 
have jitter values well below one microsecond. You should also be able to 
synchronize the PRU with an external clock on one of its input pins leading 
to the r31 register if that is still needed. 

There should probably be a residual timing jitter of maximally 1/24MHz (ca. 
42ns) because (as far as i know, but im not sure) the 24 MHz ADC sampling 
clock is not intrinsically synchronized with the 200 MHz PRU clock, so once 
the PRU launches a new acquisition, it won't take place before the ADC 
clock starts a new cycle. I did not find any documentation on how the PRU 
and ADC clock signals are derived in the hardware, that is if they come 
from the master clock or not, but i did experimentally observe a jitter of 
a few percent of a microsecond. 

If you want I can send you some code examples.

Lenny
 


On Tuesday, July 22, 2014 8:08:39 AM UTC+2, sun19...@gmail.com wrote:
>
> Hi, 
> how to synchronize ADC sampling clock (CLK_M_OSC, in AM335x manual, page 
> 3731) with external 1PPS source or others?
> I used PTP to synchronize system clock in the kernel before, however, the 
> jitter is about 30us （but I need a jitter with accuracy under 1us.）.
> So I want to synchronize ADC sampling clock(24MHz),  Is there any way to 
> synchronize it ? Is the clock of CLK_M_OSC be adjustable?
> Thanks.
>

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

[beagleboard] Re: Dude, where's my BeagleBone Black?

[Lenny]

Hi, 

the fact that you try to meet the incredible demand by allowing the 
element14 clones of the Beaglebone Black sounds good. In Europe, I have 
seen some of those boards in stock (at farnell) around April 8, but they 
seem to be all gone by now. Does anyone have an idea if there will be some 
new boards available in the near future (next few weeks)? Has anyone 
experienced significant differences with the clones? How about buying from 
China?

Thanks 

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

[beagleboard] Re: PRU Multiply and accumulate - how many cycles?

[Lenny]

Thanks for the help Bas!

I guess i found the problem: 

In my code, I used PRU0 simply as a timer with the code

LOOP:
WAIT(250 cycles)
XOUT 14,r5,4 //transfer register r5 from PRU0 to PRU1
JMP LOOP

In the meantime, PRU1 did some tasks, including multiplication using 
XOUT/XIN 0,r25,1 and similar instructions, and finally should have stalled 
at the instruction
XIN 14,r5,4 
in order to synchronize with PRU0. 

However, if the timing is initially not right, it can happen that PRU0 
waits for the other PRU while blocking the XCHG port with its XOUT 14,... 
command. If now PRU1 wants to retrieve the result of a multiplication, e.g. 
execute XIN 0,r26,4, then it will wait until the XCHG port is liberated by 
PRU0, which itself will wait for maximally 1024 cycles if PRU1 accepts its 
XOUT request while keeping the port blocked, such that PRU1 can never get 
to that section in the code in time. In this case the two PRU's block each 
other and the programs runs about 1000 times slower! 

Also, the controls which are run to ensure a proper transfer through the 
XCHG port are quite basic: It seems to me that for a successful transfer 
between two PRUs, one only needs one PRU that is willing to write 
(launching XOUT 14,... ) and the other willing to read (XIN 14,...). The 
actual registers which are to be read or written, or the amount of data 
does not have to match between the two commands. If they dont match, I dont 
know what data is actually written, but at least none of the PRUs stalls 
for 1024 cycles.  

-- 
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: Device tree overlay does not load pruss fragment but loads others

[Lenny]

Sorry: I compile with what I wrote above. I load just as you do with 


echo lockbox:00A1 > $SLOTS


-- 
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: Device tree overlay does not load pruss fragment but loads others

[Lenny]

Hi, 
I am definitely not an expert in device tree overlays, but I somehow got 
most of the PRU output pins to work. I load and compile with the following 
command: 

#!/bin/bash
NAME=lockbox

echo "Compiling the overlay from .dts to .dtbo"

dtc -O dtb -o $NAME-00A0.dtbo -b 0 -@ ./$NAME.dts

cp $NAME-00A0.dtbo /lib/firmware

My file lockbox.dts contains the following code: 
/*  
* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Purpose License Version 2 as
* published by the Free Software Foundation
*
* Original from: 
github.com/jadonk/validation-scripts/blob/master/test-capemgr/ 
*
* Modified by Derek Molloy for the example on www.derekmolloy.ie
* that maps GPIO pins for the example
*/

/dts-v1/;
/plugin/;

/{
   compatible = "ti,beaglebone", "ti,beaglebone-black";
   part-number = "lockbox";
   version = "00A0";

   fragment@0 {
 target = <&am33xx_pinmux>;

 __overlay__ {
  pru_pru_pins: pinmux_pru_pru_pins {
pinctrl-single,pins = <
/* INPUTS PRU0 */
//0x190 0x2E  /* P9_31 = PRU0_r31_0 */
//0x194 0x2E  /* P9_29 = PRU0_r31_1 */
//0x198 0x2E  /* P9_30 = PRU0_r31_2 */
//0x19C 0x2E  /* P9_28 = PRU0_r31_3 */
//0x1A0 0x2E  /* P9_42.1 = PRU0_r31_4 */
//0x1A4 0x2E  /* P9_27 = PRU0_r31_5 */
//0x1A8 0x2E  /* P9_41.1 = PRU0_r31_6 */
//0x1AC 0x2E  /* P9_25 = PRU0_r31_7 */
//0x038 0x2E  /* P8_16 = PRU0_r31_14 */
//0x03C 0x2E  /* P8_15 = PRU0_r31_15 */

/*unclear pins, even more available*/
/*0x184 0x2E*/  /* P9_24 = PRU0_r31_16 */
/*0x180 0x2E*/  /* P9_26 = PRU0_r31_16 */

/* OUTPUTS PRU0 */
//0x034 0x06  /* P8_11 = PRU0_r30_15 */
//0x030 0x06  /* P8_12 = PRU0_r30_14 */

/* OUTPUTS PRU1 */
0x0A0 0x05  /* P8_45 = PRU1_r30_0 */
0x0A4 0x05  /* P8_46 = PRU1_r30_1 */
0x0A8 0x05  /* P8_43 = PRU1_r30_2 */
0x0AC 0x05  /* P8_44 = PRU1_r30_3 */
0x0B0 0x05  /* P8_41 = PRU1_r30_4 */
0x0B4 0x05  /* P8_42 = PRU1_r30_5 */
0x0B8 0x05  /* P8_39 = PRU1_r30_6 */
0x0BC 0x05  /* P8_40 = PRU1_r30_7 */
0x0E0 0x05  /* P8_27 = PRU1_r30_8 */
0x0E4 0x05  /* P8_29 = PRU1_r30_9 */
0x0E8 0x05  /* P8_28 = PRU1_r30_10 */
0x0EC 0x05  /* P8_30 = PRU1_r30_11 */
0x084 0x05  /* P8_22 = PRU1_r30_12 */
0x080 0x05  /* P8_21 = PRU1_r30_13 */

/* INPUTS PRU1 */
/* NONE */

   
   /* OUTPUT  GPIO(mode7) 0x07 pulldown, 0x17 pullup, 0x?f 
no pullup/down */
   /* INPUT   GPIO(mode7) 0x27 pulldown, 0x37 pullup, 0x?f 
no pullup/down */

>;
  };
 };
   };

   fragment@1 {
target = <&ocp>;
__overlay__ {
test_helper: helper {
compatible = "bone-pinmux-helper";
pinctrl-names = "default";
pinctrl-0 = <&pru_pru_pins>;
status = "okay";
};
};
};


fragment@2 {
target = <&pruss>;
__overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&pru_pru_pins>;
};
};
};



However, I dont even know what all these lines mean, but it works for me. 

All pins which are not in out-commented work properly for data output, and 
when your command
cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep 9a4
gives the output you would expect. I dont remember if all of the other pins 
(in comments) work properly, but I think I tested most of them. 

One issue that I had in the beginning, was that many of the PRU pins are 
used either by the eMMC or by the hdmi module, so that I had to set the line
optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G 

in the uEnv.txt file, and boot the linux from an SD card. 

Hope this helps, 
Lenny

-- 
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 Multiply and accumulate - how many cycles?

[Lenny]

Hi, 

I started using the Multiply-and-Accumulate module of the PRU of my 
Beaglebone Black to construct a real-time digital filter. But as soon as I 
insert an instruction of the type, with any data or any of the MAC 
registers (r25-r29) in the code, I induce some non-negligeable latency. 
MOV r25,0x
XOUT 0,r25,1

I would estimate that the XOUT or XIN instructions cost about 5 
microseconds, that is something near 1024 PRU clock cycles. I have observed 
other awkward behaviour of the Multiplier module, for example it only 
properly multiplied the values in registers r28 and r29 when I did a XOUT 
0,r28,8 instruction before reading the result. Does someone have experience 
with this module? Is it possible that I am using it wrong, that it has to 
be activated properly before being usable, or that the hardware is not 
working correctly? 

Thanks for any help!
Lenny

-- 
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 Multiply and accumulate - how many cycles?

[Lenny]

-- 
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: using beaglebone black to control an valve

[Lenny]

Hi, 

can you give more information on your sensor, such as what kind of signal 
(digital/analog, what resolution is needed, really 500MHz signal 
bandwidth)? I am using the BBB PRU for some realtime feedback application. 
In principle, the PRU works at 200 MHz, so with one PRU, you can change the 
signal at the 15 available digital output pins once every 5 nanoseconds (or 
equivalently read them out that fast), but you would need to reserve some 
cycles for signal input. In my application, I used the integrated analog 
input of the beaglebone black, which drastically limits the input sampling 
frequency to slighly above 1MHz. If sampling at 1 MHz is enough for you 
(which i believe it should be, as I can hardly imagine a valve which can 
react within 1 microsecond), then the PRU can solve your problem. Of 
course, you would probably have to amplify the output from the Beaglebone 
as the output pins deliver only a few milliamperes of current. 

-- 
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/groups/opt_out.

Re: [beagleboard] How many PRU clock cycles does a LBBO instruction take?

[Lenny]

Thanks a lot. These delays are quite disappointing. Is it possible to 
shorten these delays by using e.g. DMA to transfer data from a peripheral 
(in my case the TSC_ADC) directly to PRU memory? 

-- 
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/groups/opt_out.

[beagleboard] How many PRU clock cycles does a LBBO instruction take?

[Lenny]

Hello, 

I am using a Beaglebone Black. When i measured the number of PRU clock 
cycles needed for the execution of various assembler instructions, I found 
surprisingly large values for memory access. Here follows a list, in which 
one cycle corresponds to a delay of 5ns as expected:

Most operations, such as ADD,SUB,QBxx,MOV,JMP etc.: 1 cycle

LBBO 1,2,4 Bytes from PRU DRAM: 3 cycles
LBBO 8 Bytes from PRU DRAM: 4 cycles
LBBO 12 Bytes from PRU DRAM: 5 cycles
LBBO 16 Bytes from PRU DRAM: 6 cycles

LBCO 4 Bytes from DDR: 43 cycles
LBCO 8 Bytes from DDR: 44 cycles
LBCO 12 Bytes from DDR: 45 cycles
LBCO 16 Bytes from DDR: 46 cycles

With PRU DRAM, i mean any addresses between 0x and 0x4000 and 
the shared PRU RAM (12 kB starting from 0x0001). Any other address i 
tried had the delay stated for "DDR".

Can anybody confirm the long DDR (and other delays if possible) readout 
times that I have measured? Does anybody have an explanation for these 
large delays?

Thanks in advance! Lenny

-- 
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/groups/opt_out.

[beagleboard] Re: Beaglebone connection failures

[Lenny]

I have the same problem. I dont have a serial to usb cable to debug the 
problem. I finally switched to Ubuntu and the issue never appeared again. 
.

-- 
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/groups/opt_out.