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 say I go out there reinventing all the software out there. But it is me realizing that I *can* do the same things, a lot of the interesting problems already do. The truly interesting problems, to me, I tend to jump into for months on end. Or at least a couple weeks :)
On Fri, Oct 9, 2015 at 1:04 AM, William Hermans <yyrk...@gmail.com> wrote: > *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 <rm...@latencyzero.com> 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 <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. >> > > -- 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.
