> > *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 documented. In the end, I get tired of wasting my time with projects, or libraries that go no where. Also, investing my time into learning such libraries, or projects, only to find that they're fundamentally broken, or really do not serve my needs. Tends to upset me. I do not write software to aggravate myself. I write software to achieve an end goal, and because I enjoy it. It also does not help that I am somewhat of a code snob. Meaning: It really bothers me when code is not well written, or readable. Well formed, simple, and easily readable code is how I prefer things. Short, concise . . . all that. Which is why when I hear people like Linus saying that a function should do one thing well, and only one thing, and should be less than 3-4 pages long . . . I tend to laugh to myself. Because if I'm doing one thing well, and that one well done thing takes 3-4 pages of code. . . Well let me just say that I'd have to find something else to do. Because I'm not very good at writing code. At least that is how I feel. Anyway, this all play a part in using a 3rd party library. In order to get to know a library well, you have to sift through the code line by line. When 90-95% of the code I've seen out there, I can not stand to read through. Do you know what ? I don't have to like it, or even use it. Which is where I wind up most of the time when looking at such libraries. Anyway, I do not expect you, or anyone else to agree with me. Which is fine. On Thu, Oct 8, 2015 at 11:21 PM, Rick Mann <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> wrote: > > > > > > Yeah wow, I already said that, hah ! Too much going on . . . > > > > > > On Thu, Oct 8, 2015 at 9:32 PM, William Hermans <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 > > > > [email protected] > > > > > > > > > > > > -- > > > > 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 [email protected]. > > > > 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 [email protected]. > > > > For more options, visit https://groups.google.com/d/optout. > > > > > > > > > -- > > > Rick Mann > > > [email protected] > > > > > > > > > -- > > > 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 [email protected]. > > > 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 [email protected]. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > Rick Mann > > [email protected] > > > > > > -- > > 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 [email protected]. > > 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 [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > > -- > Rick Mann > [email protected] > > > -- > 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
