Re: [beagleboard] libiio on BBB?

2015-10-10 Thread William Hermans
I just built libiio, and tested iio_readdev iio:device0, and the sample rate is terrible. Just above 1ksps. Just for perspective, this 4-5 times slower than using sysfs with one-shot mode. Continuous mode through sysfs, I've gotten up to around 15ksps. Using mmap() on /dev/mem/ . . . well lets jus

Re: [beagleboard] libiio on BBB?

2015-10-10 Thread William Hermans
Hi Nuno, Yeah, Rick and I both know about libiio. We've actually been talking back and forth by direct email yesterday. I've been attempting to find more information on how the sample etc are stored in the buffer. I have been successful reading the buffer one sample at a time however. But the data

Re: [beagleboard] libiio on BBB?

2015-10-10 Thread Nuno Sucena Almeida
On 10/08/2015 10:06 PM, Rick Mann wrote: > What would it take to get libiio: > > https://wiki.analog.com/resources/tools-software/linux-software/libiio > > Into the BBB kernels? I think this would be amazing. Hi Rick, the linux kernel supports IIO (industrial input output) for quite some

Re: [beagleboard] libiio on BBB?

2015-10-09 Thread William Hermans
There is also another aspect to all of this. I like to solve complicated problems. Using the third library can solve complex problems. But the problems I'm usually interested in, is the problem that library has solved. I often wonder how I could solve the same problem, only better. This is not to s

Re: [beagleboard] libiio on BBB?

2015-10-09 Thread William Hermans
> > *This must be a fundamentally different philosophy.* > Indeed. I believe in a minimalist approach where possible. But at some point, I believe this could be considered "splitting hairs" on my behalf. As I do use Linux, and POSIX API calls, etc. But all those are standardized and very well doc

Re: [beagleboard] libiio on BBB?

2015-10-08 Thread Rick Mann
This must be a fundamentally different philosophy. I come from OS X (and earlier) development, where abstractions are the key to app development. Even libiio isn't nearly abstract enough for my tastes. It still exposes (or requires) knowledge about sysfs and the connected devices. The ADC code I

Re: [beagleboard] libiio on BBB?

2015-10-08 Thread William Hermans
I should probably make it clearer as to what I mean by "bad" in the context of learning. I love to learn, I think learning is a very good thing. What I really meant is that something like this is something else you have to know, before using it. Which is not always convenient of efficient. Sometime

Re: [beagleboard] libiio on BBB?

2015-10-08 Thread William Hermans
I do not see where it says mmap() is not so great. I do see where they imply that mmap() is slower than mmap() + DMA. Which does, can, or otherwise makes sense. The block copy idea is also pretty cool, but not unique to iio. Here is my take on that set of slides: 1. It is already written.

Re: [beagleboard] libiio on BBB?

2015-10-08 Thread Rick Mann
There's a good slide presentation on why mmap() isn't so great, and they talk about the changes they made to the underlying driver and the ioctl() calls they added. libiio wraps those ioctl calls. http://events.linuxfoundation.org/sites/events/files/slides/iio_high_speed.pdf It's not w

Re: [beagleboard] libiio on BBB?

2015-10-08 Thread William Hermans
Yeah wow, I already said that, hah ! Too much going on . . . On Thu, Oct 8, 2015 at 9:32 PM, William Hermans wrote: > Rick, also for what it's worth. Getting it compiled and working on a > system does seem very straight forward and is shown step by step on that > landing page you linked to. > >

Re: [beagleboard] libiio on BBB?

2015-10-08 Thread William Hermans
Rick, also for what it's worth. Getting it compiled and working on a system does seem very straight forward and is shown step by step on that landing page you linked to. On Thu, Oct 8, 2015 at 9:30 PM, William Hermans wrote: > Not sure I understand what you're getting at, but I've read that iio

Re: [beagleboard] libiio on BBB?

2015-10-08 Thread William Hermans
Not sure I understand what you're getting at, but I've read that iio has at least two methods of access. Slow( sysfs ), and fast( mmap()). I'm not sure that the "fast" method driver exists for our board here in the context of the ADC's but certainly the slow sysfs method does. As for the rest of th

Re: [beagleboard] libiio on BBB?

2015-10-08 Thread Rick Mann
libiio (along with additional stuff in the kernel that doesn't appear to be in 4.1.x-ti) provides for fast ADC access, rather than getting at it through sysfs. > On Oct 8, 2015, at 20:07 , William Hermans wrote: > > I believe the ADC already uses a libiio "driver". Assuming it is the same > th

Re: [beagleboard] libiio on BBB?

2015-10-08 Thread William Hermans
I believe the ADC already uses a libiio "driver". Assuming it is the same thing I'm thinking of. But for instance when you load the ADC device tree file, it in turn loaded the iio:device0 object for the ADC. Like demonstrated on my blog post here: http://www.embeddedhobbyist.com/2015/10/beaglebone

[beagleboard] libiio on BBB?

2015-10-08 Thread Rick Mann
What would it take to get libiio: https://wiki.analog.com/resources/tools-software/linux-software/libiio Into the BBB kernels? I think this would be amazing. -- Rick Mann rm...@latencyzero.com -- For more options, visit http://beagleboard.org/discuss --- You received this message b