Re: [beagleboard] PRU to DMA DDR caching issues

[John Syne]

This training material from free-electron explains the cache effects and how to 
deal with them. Starting at slide 440 

http://free-electrons.com/doc/training/linux-kernel/linux-kernel-slides.pdf 


Regards,
John




> On Jan 3, 2016, at 8:58 AM, Thomas Köhler  wrote:
> 
> Hello and thank you for the fast help. Here my answers for your comments:
> 
> 
> Unless you carefully write kernel code to treat your DDR memory buffer 
> as DMA memory, you are almost certainly encountering caching effects. 
> 
> I thought to have this done by getting the memory space from 
> dma_alloc_coherent(). I will research if there is more needed to disable the 
> caching but my understanding was that a DMA flagged space will never be 
> cached because the ARM core can not know if something has changed.
> 
> > I recommend instead of using a buffer in DDR memory, use the PRU data 
> > memories.
> 
> As to my tests, writing from the PRU to the DDR memory only requires 3 cycles 
> on the PRU and not more on a few million tries (L3 fast interconnect). 
> However I do not know how long it takes for this memory to be available at 
> the ARM...
> 
> I can not do all work in the PRU code because I need to tag the rising edge 
> with the Linux Kernel time. Therefore I need to find out the most 
> deterministic way to get the counter value into the Kernel.
> 
> I will do further tests. Maybe there is someone here who experienced the same 
> road. I think tagging an event with the PRU (5ns) and set it into relation to 
> Linux Kernel Time without losing to much nanoseconds should be one of the 
> great PRU benefits.
> 
> Thanks all
> 
> 
> 
> -- 
> 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.

Re: [beagleboard] About generic_buffer.c fail to write the current_trigger

[William Hermans]

OK, this is what you want to read and understand then:
http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User's_Guide#Continuous_Mode

Read everything carefully. The buffer, whatever size you make it is located
at /dev/iio:device0 but passed this, im not 100% sure of the buffer layout.
I was able to read a single first value from the buffer, but was unable to
figure out how to read passed the first value. Simply incrementing 32bits
further into the buffer did not work. At this point, I got bored with using
the iio adc driver, and decided to experiment with /dev/mem/ instead.

Typically though, the values read out are 32bit, but only the first 12 bits
are the actual ADC reading, and then the next 4 or 5 bits is the ADC
channel index value. Which is a value of 0-7, *if* this feature is enabled.
>From what I've seen, in continuous mode, iio always has the channel index
"feature" enabled - By default. The remaining bits passed the bits used by
channel index, are unused / reserved.

You can read more on this in the AM335x TRM under the touchscreen
controller section which if I remember right is chapter 14.

On Sun, Jan 3, 2016 at 9:35 AM, ThanapatMax  wrote:

> I want to use continuous sir.
>
> --
> 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.

Re: [beagleboard] Errors reading multiple Analog Inputs from Beaglebone Black using C++

[Rick Mann]

> On Jan 2, 2016, at 06:57 , William Hermans  wrote:
> 
> The ints and floats inside the loop are not a problem. Only one of each is 
> allocated on the stack when the function is entered, and then they're 
> assigned each time through the loop. Perfectly fine (and good practice for 
> limiting the scope of variables).
> 
> This would assume you know which compiler is being used, and you've actually 
> disassembled the executable to see what the compiler does. Generally, it is a 
> bad idea to assume you know what is happening. Because of this ambiguity, it 
> is considered bad form. 
> 
> A while statement has no concept of scope. So main() has scope whether inside 
> the while statement, or not.

I'm not sure what you think is going on in that code. A while loop most 
certainly has a scope, in that the variables declared within the while block 
are not visible before nor after the loop. Any compiler that accepts the syntax 
(i.e. any modern C or C++ compiler) will treat that exactly the same as if the 
variables were declared at the top of the function, except that the name will 
only be visible within the loop.

-- 
Rick Mann
rm...@latencyzero.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] PRU to DMA DDR caching issues

[Charles Steinkuehler]

On 1/3/2016 7:53 AM, Thomas Köhler wrote:
> 
> Any help? So many thanks... I hope the problem can be understood.

Unless you carefully write kernel code to treat your DDR memory buffer
as DMA memory, you are almost certainly encountering caching effects.
 The ARM core reads the memory location once, and will not do so again
as long as the data remains in the cache.  The more often you read the
DDR memory location, the more likely the data is to stay in the cache.

I recommend instead of using a buffer in DDR memory, use the PRU data
memories.  They are accessible by both the ARM and PRU cores, and have
the proper memory flags setup so the ARM core will not cache reads.

-- 
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] PRU to DMA DDR caching issues

[Luiz Chamon]

Tom,

I had a hard time understanding exactly what your problem is, so I really don't 
have an answer for you. I'll just try to address the "what you are trying to do 
part", because it seems you may be making things harder on yourself.

Firstly, I am taking that what you mean by "a nanosecond scale" is actually "on 
the order of nanoseconds". A PRU instruction takes 5ns to execute and I'm 
counting at least 4 or 5 instructions in that loop.

A solution for you to completely avoid the issues you have by using another pin 
(polled by the linux kernel, which will give you some non deterministic timing) 
is to do everything in the PRU. First, use the dedicated RAM in the PRUs. The 
bridge to the rest of the ARM core (OCP) is not in the real-time domain of the 
PRUs and has to deal with clashes and resources being occupied by the kernel. 
Second, use the PRU to ARM interrupt to signal that there was an edge. You'll 
get less latency and lower jitter, although you really can't do much better 
than lower here. Also, PRUs have two RAM banks so you can do a ping pong buffer 
too.

If your problem requires you to do some action on the rising edges (and any 
delay or jitter is unacceptable in your application), I would suggest you do 
everything in the PRUs (if it is not too complicated, after all there's some 
code size limitations).

Sorry I couldn't be of more help. If you give me more details on your 
applications, I can try again... ;)

Cheers!

-- 
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 to DMA DDR caching issues

[Thomas Köhler]

Hello,

I encounter a caching issue with my application. I will describe what I 
want to do, how I planned to do it and what goes wrong:

*WHAT:*

By using the PRU on my BBB, I want to timestamp a periodic rising edge on 
one input pin in *a nanosecond scale *and signal it to a Linux Kernel 
module on the ARM.


*HOW:*

To receive an interrupt in my kernel module, I bridged the pin with the 
rising edge to a second one (timer4 interrupt).
This interrupt fires a few microseconds after the event happened.

To read values from the PRU with best determinism and lowest latency, I 
allocated some DDR memory with dma_alloc_coherent() in my kernel module and 
handout the address via debugfs to the PRU.


The PRU is in endless loop:  

wait for rising edge, read out the PRU cycle counter and write the cycle 
counter to the DDR memory address. 
*This works like a charm and I got the event's cycle counter snapshot in my 
kernel module!*


The kernel module interrupt is firing a few microseconds after the event 
and has some jitter I want to avoid.

So I decided it would be best to burst the actual cycle counter to a second 
ram address for a ten thousand times by the PRU so when the Kernel module 
reads this ddr location, It knows the difference from the event's cycle 
counter and the cycle counter now.

*This does not work!*


*WRONG:*

Initially everything appered to be working. I was reading out for example:

event cycles: 1000
now cycles: 4300

great!


But to test the "now cycles" counter, I added to the kernel module to read 
it thousand times in a loop. Guess what?* It is thousand times the same.*

I tried a few options. For example to write and read two alternating 
memaddresses for this "now counter" by kernel and pru but nothing gives the 
results I expected.
It seems like anyone caches the results.



Any help? So many thanks... I hope the problem can be understood.
Tom

-- 
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] Device Control Clock

[Ray Madigan]

I have done some searching and I know I need to do more investigation.  I 
am working on the design of an embedded system that talks to a custom 
interface on an exiting peripheral.  I am trying to sort out a bunch of 
issues, at this point I am overwhelmed with choices so i figured I could 
maybe shortcut a point that might reduce the investigation effort, at least 
for a short period.

I am looking to figure out if the beaglebone black brings out a clock pin 
that would synchronize the pru with the external device?  I have read that 
if this functionality is needed then one of the pru processor has to be 
used to generate the clock thereby reducing the application to use a single 
pru for it's functionality.

The question is:  Does the beaglebone black output a clock on any of the 
output pins?

if it does, can you point me to a place to understand how to use it?

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

Re: [beagleboard] Errors reading multiple Analog Inputs from Beaglebone Black using C++

[William Hermans]

>
> *I'm not sure what you think is going on in that code. A while loop most
> certainly has a scope, in that the variables declared within the while
> block are not visible before nor after the loop. Any compiler that accepts
> the syntax (i.e. any modern C or C++ compiler) will treat that exactly the
> same as if the variables were declared at the top of the function, except
> that the name will only be visible within the loop.*


You are absolutely correct, and I do not know what the hell I was thinking.
Generally I always declare variables outside of loops, because I think it
is clearer. But what should have made it clear to me is that anything
inside of curly brackets is limited in scope to that set of brackets. You
do not even need a function or loop, etc to limit scope in this manner.




On Sun, Jan 3, 2016 at 2:06 AM, Rick Mann  wrote:

>
> > On Jan 2, 2016, at 06:57 , William Hermans  wrote:
> >
> > The ints and floats inside the loop are not a problem. Only one of each
> is allocated on the stack when the function is entered, and then they're
> assigned each time through the loop. Perfectly fine (and good practice for
> limiting the scope of variables).
> >
> > This would assume you know which compiler is being used, and you've
> actually disassembled the executable to see what the compiler does.
> Generally, it is a bad idea to assume you know what is happening. Because
> of this ambiguity, it is considered bad form.
> >
> > A while statement has no concept of scope. So main() has scope whether
> inside the while statement, or not.
>
> I'm not sure what you think is going on in that code. A while loop most
> certainly has a scope, in that the variables declared within the while
> block are not visible before nor after the loop. Any compiler that accepts
> the syntax (i.e. any modern C or C++ compiler) will treat that exactly the
> same as if the variables were declared at the top of the function, except
> that the name will only be visible within the loop.
>
> --
> Rick Mann
> rm...@latencyzero.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.
>

-- 
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] About generic_buffer.c fail to write the current_trigger

[ThanapatMax]

I want to use continuous sir.

-- 
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 to DMA DDR caching issues

[Thomas Köhler]

I tracked down the issue a bit more:

If I insert something between two reads of the DDR memory in my kernel 
module (I inserted a pr_info("test")), the value is refreshed.

Maybe there is a possiblity to invalidate the cache? I will investigate 
more.

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.

Re: [beagleboard] PRU to DMA DDR caching issues

[Thomas Köhler]

Hello and thank you for the fast help. Here my answers for your comments:


Unless you carefully write kernel code to treat your DDR memory buffer 
> as DMA memory, you are almost certainly encountering caching effects. 
>

I thought to have this done by getting the memory space from 
dma_alloc_coherent(). 
I will research if there is more needed to disable the caching but my 
understanding was that a DMA flagged space will never be cached because the 
ARM core can not know if something has changed.

> I recommend instead of using a buffer in DDR memory, use the PRU data 
memories.

As to my tests, writing from the PRU to the DDR memory only requires 3 
cycles on the PRU and not more on a few million tries (L3 fast 
interconnect). However I do not know how long it takes for this memory to 
be available at the ARM...

I can not do all work in the PRU code because I need to tag the rising edge 
with the Linux Kernel time. Therefore I need to find out the most 
deterministic way to get the counter value into the Kernel.

I will do further tests. Maybe there is someone here who experienced the 
same road. I think tagging an event with the PRU (5ns) and set it into 
relation to Linux Kernel Time without losing to much nanoseconds should be 
one of the great PRU benefits.

Thanks all


-- 
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 to DMA DDR caching issues

[Charles Steinkuehler]

On 1/3/2016 10:58 AM, Thomas Köhler wrote:
> Hello and thank you for the fast help. Here my answers for your comments:
> 
> Unless you carefully write kernel code to treat your DDR memory buffer 
>> as DMA memory, you are almost certainly encountering caching effects. 
> 
> I thought to have this done by getting the memory space from 
> dma_alloc_coherent(). 
> I will research if there is more needed to disable the caching but my 
> understanding was that a DMA flagged space will never be cached because the 
> ARM core can not know if something has changed.

There's more than just allocating the memory to successfully use it
for DMA (which is basically what's happening here, the PRU is an
independent mechanism that modifies memory outside the context of the
ARM core).  This is very non-trivial to implement correctly, and
drastic overkill for what you need to do unless you're moving very
large amounts of data (more than will fit in the PRU data memories).

>> I recommend instead of using a buffer in DDR memory, use the PRU data 
> memories.
> 
> As to my tests, writing from the PRU to the DDR memory only requires 3 
> cycles on the PRU and not more on a few million tries (L3 fast 
> interconnect). However I do not know how long it takes for this memory to 
> be available at the ARM...

Several hundred nS at the very least.  It looks like the transaction
only takes three cycles on the PRU because the write is posted.  To
get a better idea of the actual transaction time, try doing a read on
the PRU side!

> I can not do all work in the PRU code because I need to tag the rising edge 
> with the Linux Kernel time. Therefore I need to find out the most 
> deterministic way to get the counter value into the Kernel.
> 
> I will do further tests. Maybe there is someone here who experienced the 
> same road. I think tagging an event with the PRU (5ns) and set it into 
> relation to Linux Kernel Time without losing to much nanoseconds should be 
> one of the great PRU benefits.

Have the PRU sample the pin and record the data you want into the
shared data memory.  Then have the PRU send an interrupt to the ARM
core indicating the data is available.

An alternate method that should produce similar quality results
without needing the PRU is to use the capture timers.  You can
configure the hardware timers to capture on the rising and/or falling
edge of a signal, and have the timer interrupt the ARM core.  This
provides cycle-level accuracy for timing, and you should be able to
implement everything using the exiting Linux kernel drivers for the
timer hardware.

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