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

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

[beagleboard] PRU to DMA DDR caching issues

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 modul

Re: [beagleboard] PRU to DMA DDR caching issues

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

[beagleboard] PRU to DMA DDR caching issues

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 scal

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

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

Re: [beagleboard] PRU to DMA DDR caching issues

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_coh

Re: [beagleboard] PRU to DMA DDR caching issues

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

Re: [beagleboard] PRU to DMA DDR caching issues

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 d

[beagleboard] Device Control Clock

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

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

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

Re: [beagleboard] PRU to DMA DDR caching issues

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

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

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 a