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've written on the BBB can't be used on any other computer (the sysfs paths aren't consistent, for starters). A good abstraction would support very high-speed I/O on a wide variety of devices without having to know specifics, like sample size or padding, or configuration steps. It could provide safe callback mechanisms for asynchronous use, too. Even with libiio, you'd still have to build that stuff. I certainly don't want to.
What I envision is something like ALSA, but for ADC (and GPIO). IIO may not be the way to get there, but it seems to have a lot of support already. It probably needs significant additional enhancement to do what I want, but I'd at least like to try using it first. > On Oct 8, 2015, at 22:55 , William Hermans <yyrk...@gmail.com> wrote: > > 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. Sometimes, it > can be though . . . > > > On Thu, Oct 8, 2015 at 10:24 PM, William Hermans <yyrk...@gmail.com> wrote: > 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: > > • It is already written. > • It is very probably well thought out. > • It *is* yet another abstraction layer - Pluses, and minus. > • It is possibly supported. Good if so, bad if not. > • built into or can be built into the kernel if supported. > • Does use interrupts apparently, so will incur some kind of penalty. > > Do I think it would be a cool / good thing to have in the kernel( optionally > ) ? No doubt - Yes. But would I use it ? I'm still not convinced. But of > course I see most, many or potentially all abstraction layers as initially > bad. Bad in that it is something else to learn / understand. Bad that you get > a lot of extra stuff typically built in that you do not need. Which leads to > bloat, and potential performance issues. Also bad that sometimes it's more > convenient to just use such an abstraction layer, than fully understand it, > which can lead to many, many frustrating problems to solve. Very few > abstraction layers convince me otherwise, but I would guess that iio would be > one to do so. If not, well it is an interesting idea in of it's self to merit > a second look, or four. In fact, I already had thought iio was worth > revisiting later, after learning about it a few days ago - While exploring > the BBB's ADC's. > > > On Thu, Oct 8, 2015 at 9:57 PM, Rick Mann <rm...@latencyzero.com> wrote: > 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 what I envision a proper user-space API should look like, but it's > much closer. I'm hoping I can write one on top of it, perhaps expanding iio. > But when I refer to libiio, I'm also including the necessary updates to the > iio driver system. > > > On Oct 8, 2015, at 21:33 , William Hermans <yyrk...@gmail.com> wrote: > > > > Yeah wow, I already said that, hah ! Too much going on . . . > > > > On Thu, Oct 8, 2015 at 9:32 PM, William Hermans <yyrk...@gmail.com> 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. > > > > On Thu, Oct 8, 2015 at 9:30 PM, William Hermans <yyrk...@gmail.com> wrote: > > 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 the > > things mentioned on that landing page you pasted a link to . . . it seems > > that he steps are very straight forward to get working, and indeed laid out > > on that exact page. > > > > What are you wanting to do with iio ? The idea of the library does intrigue > > me too. But I'm, not exactly sure I have the time to learn > > yet-another-abstraction-layer . . . > > > > On Thu, Oct 8, 2015 at 8:37 PM, Rick Mann <rm...@latencyzero.com> wrote: > > 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 <yyrk...@gmail.com> wrote: > > > > > > 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-black-adc/ > > > > > > With that said, I do not purport to know very much about it. Just that it > > > exists. > > > > > > On Thu, Oct 8, 2015 at 7:06 PM, Rick Mann <rm...@latencyzero.com> 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. > > > > > > > > > -- > > > 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. > > > > > > -- > > 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. > > > -- > 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. -- 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.
