**** BEGIN LOGGING AT Thu Mar 13 02:59:58 2014 Mar 13 05:19:06 jkridner|work, could I message you regarding a listed project idea? Mar 13 05:19:24 not message me, but you can talk about it here. Mar 13 05:20:27 I'm interested in packaging npm packages and integrating the support libraries Mar 13 05:20:51 i realize they deal with mostly creating the make files(bitbake recipes) and meeting dependencies Mar 13 05:20:55 would they qualify as code? Mar 13 05:21:11 jkridner, ^ Mar 13 05:21:32 which libraries? Mar 13 05:21:39 with something like node-ffi? Mar 13 05:21:49 oh... Mar 13 05:21:51 bonelib, pybbio, beaglebone-ruby Mar 13 05:21:51 into Angstrom! Mar 13 05:21:58 and the node-serialport Mar 13 05:22:05 actually, I'm looking into both the projects Mar 13 05:22:29 I'm not sure who would mentor the bitbake recipes anymore.... Mar 13 05:22:34 that was kind of a koen thing. Mar 13 05:22:34 I got the angstrom source and I'm building it. Read up on creating bitbake recipes Mar 13 05:22:46 oh, both listed you as possible mentors Mar 13 05:22:52 what happened to koen? Mar 13 05:22:57 we are doing a bit more focus on Debian these days. Mar 13 05:23:16 he went to work for Linaro and isn't doing *quite* as much on BeagleBone... Mar 13 05:23:32 ah Mar 13 05:23:33 though he has still been putting out the releases and might be willing to mentor. Mar 13 05:23:44 are there any libraries which you are trying to package for debian? Mar 13 05:24:02 I'm more familiar with the usual cmake tool chain Mar 13 05:24:05 This was a project idea left over from last year that I left up because it is still valid, but it really doesn't have much focus. Mar 13 05:24:18 I see Mar 13 05:24:24 we've been putting makefiles around a handful of packages to create Debian packages. Mar 13 05:24:32 Cloud9 still needs to be done I believe. Mar 13 05:24:38 I think libsoc is done. Mar 13 05:24:52 are both the projects relics from last year? Mar 13 05:25:07 the npm and support libraries Mar 13 05:25:08 ? Mar 13 05:26:09 yes. do you *know* bitbake? Mar 13 05:26:18 could you write an npm class? Mar 13 05:26:32 it would still be a rather cool thing to have for Open Embedded. Mar 13 05:26:37 jkridner, I've been learning it Mar 13 05:26:47 * jkridner deleted the idea for now. Mar 13 05:27:17 ohh Mar 13 05:27:24 Is the support library project still up? Mar 13 05:27:45 yeah, I just changed it to Debian and added rcn-ee and vagrantc as possible mentors. Mar 13 05:28:04 I think we need to brainstorm with those two what really needs to be packaged up still. Mar 13 05:28:12 http://www.openembedded.org/wiki/How_to_create_a_bitbake_recipe_for_dummies Mar 13 05:28:16 I'm not sure there is enough meat to it to stand on its own. Mar 13 05:28:16 I've been going through this Mar 13 05:28:22 have you succeeded? Mar 13 05:28:27 I'm going to try out a recipe for a basic program Mar 13 05:28:50 I understand what the file specifies Mar 13 05:29:07 k. building a more complex project can be rather tricking and creating a new bbclass even trickier. Mar 13 05:29:12 I'm building oe from source to learn more about workings Mar 13 05:29:33 I understand that. I've worked with GSoC before Mar 13 05:29:39 looking in the room, I don't see any real OE people. Mar 13 05:30:35 jkridner, would debian require bitbake recipes?? Mar 13 05:30:42 o.0 Mar 13 05:30:51 Debian has its own packaging. Mar 13 05:31:02 yeah. you might want to change that Mar 13 05:31:09 It has a somewhat similar issue with npm. Mar 13 05:32:18 k, updated. to say "packaging scripts". Mar 13 05:32:41 Debian doesn't generally package up stuff like node-serialport, etc. Mar 13 05:32:51 with Angstrom/OE, everything was cross-compiled. Mar 13 05:33:14 i understand Mar 13 05:33:22 with Debian, we just add 'npm install -g bonescript' to the image build script and run in on an ARM platform. Mar 13 05:33:32 what was the issue with npm? Mar 13 05:34:06 " It has a somewhat similar issue with npm." Mar 13 05:34:41 hmmm.... https://www.npmjs.org/package/npm2debian Mar 13 05:35:05 always amazing what a little googling will turn up. Mar 13 05:35:22 the issue is that most modules don't get packaged. Mar 13 05:35:37 they are just installed using an 'alien' package manager called 'npm'. Mar 13 05:36:05 okay.. you mean people don't package it and put it upstream on the official debian repos Mar 13 05:36:12 I say it is alien, because 'apt-get remove node-serialport' would never work because apt-get/dpkg know nothing about the files installed by 'npm install -g node-serialport'. Mar 13 05:36:24 and it's easier to just pull it from npm because it's easier to get it accepted in their repo Mar 13 05:36:37 okay :) Mar 13 05:36:53 right.... they don't package it and put it in Debian. I would call that downstream since I consider the project source upstream, but yes, they don't make the packages. Mar 13 05:37:06 yeah... virtually no barrier to get on npmjs.org. Mar 13 05:37:12 i understand Mar 13 05:37:30 creating an module that did 'rm -rf /' would be trivial with npmjs.org. Mar 13 05:37:39 But is there any way to expand this beyond just the 3 libraries? I don't think that would be sufficient for a whole summer Mar 13 05:37:48 lol Mar 13 05:38:06 and they'll accept it too! Mar 13 05:38:27 right, right, I think we need to go fishing a bit for packages that people would want to use on BeagleBone that aren't commonly known or simply aren't in Debian Wheezy. Mar 13 05:38:58 Rob Rittman has been helping us with the Debian packaging, but he's not so familiar with what people are doing with BeagleBone.... Mar 13 05:39:05 how would go about compiling the list? can i ask on #beagle? Mar 13 05:39:23 Robert Nelson probably deals more with kernel-related issues. Mar 13 05:39:55 okay Mar 13 05:40:02 you can ask there a few times, but I think you'd need to do a bit of scouring the web for BeagleBone-related libraries.... even libraries made for the Pi, etc. that could be useful on BeagleBone. Mar 13 05:40:26 I'm thinking the current three libraries would take probably 3/4 weeks maximum provided there are no hiccups in accepting the repo Mar 13 05:40:39 scanning http://beagleboard.org/project might be slightly helpful... Mar 13 05:40:55 wouldn't we have to rewrite the RPi libraries for use in BBB? Can I include that under scope of project? Mar 13 05:40:57 I've been trying to put a flag on there such that people could request their code be integrated into the distro. Mar 13 05:41:10 still, a huge chunk of the projects are abandonware. Mar 13 05:41:26 not maintained.. i understand Mar 13 05:41:37 wiznerd: yes, if there are any useful open source chunks of code. Mar 13 05:41:42 * jkridner isn't familiar enough. Mar 13 05:42:08 okay Mar 13 05:42:19 is Mr. Rittman on IRC? Mar 13 05:42:28 but, if you helped get a good list of libraries in various programming languages that could be useful on BeagleBone.... perhaps some that required some editing... I can definitely see supporting you on such a project. Mar 13 05:42:41 Rittman is 'vagrantc' on IRC, but I don't see him on all that often. Mar 13 05:43:02 and nelson is ecn-ee? Mar 13 05:43:16 okay. I'll start compiling a list Mar 13 05:43:31 on an average, how much time do you think it'll take to package each library? Mar 13 05:43:47 I think the first few would take a while. And then it would take only like a few days Mar 13 05:44:03 I would like to expand it to some actual I/O coding too if that's okay :) Mar 13 05:44:42 And how would I share this list with you? Mar 13 05:44:46 google spreadsheet? Mar 13 05:47:09 jkridner, ^ Mar 13 05:47:20 rcn-ee Mar 13 05:47:51 okay Mar 13 05:48:06 I'm Feroz btw Mar 13 05:48:57 I believe the ideal place for the list (if you see a use for having something in the BeagleBone package feed or ported to BeagleBone) is to add it to http://bugs.elinux.org/projects/debian-image-releases Mar 13 05:49:22 Executing the project by checking things off in that bug tracker would be excellent. Mar 13 05:51:20 okay Mar 13 05:51:44 jkridner, shall i draw up a timeline and put up a proposal on melange? Mar 13 05:52:55 Apart from debian packaging, would you have any feature/program request that could be completed in say around 3 weeks or so? Mar 13 05:53:03 yes, but try to make sure you can get a good list of components first. If you are unsure of the usefulness, I'd suggest asking on beagleboard@googlegroups.com. Mar 13 05:53:09 Something which is often requested but cannot be used as a standalone GSoC project? Mar 13 05:54:08 There only seem to be 6 open issues in http://bugs.elinux.org/projects/debian-image-releases/issues?set_filter=1 Mar 13 05:54:44 Not sure if it is really just 3 weeks and there are some other projects being looked at for GSoC this year that have some need for it (and a GSoC project from last year did a great start on it), but we really need a USB-based flasher. As I'm saying this though, it really doesn't fit into what you are doing. Mar 13 05:54:53 I need some code work on BoneScript.... Mar 13 05:55:10 yeah, there aren't a lot of open issues on the image yet. Mar 13 05:55:21 And is http://bugs.elinux.org/issues/49 a packaging issue per se? Mar 13 05:55:36 all of the PRU stuff is likely pretty involved (over 3 weeks). Mar 13 05:55:49 no... that one is a kernel issue. Mar 13 05:56:28 It'll take make quite a while to get upto speed with PRU alone Mar 13 05:57:26 BoneScript web pages with live-running examples and documentation --> This one? Mar 13 05:57:39 just lots of small features.... Mar 13 05:58:08 I realize this would make it easier to start using BBB right away Mar 13 05:58:17 but isn't this project already taken by somebody here? Mar 13 05:58:22 I want to move from doing attachInterrupt using epoll/POLLPRI to building a device tree overlay for gpio-keys and creating a real input event. Mar 13 05:58:31 I went through the google group and quite a few were interested Mar 13 05:58:55 I'm the developer for the BoneScript library itself. yes, the web page stuff has a lot of interested people, but they won't necessarily be working on the library itself. Mar 13 05:58:57 okay.. the generic device tree Mar 13 05:59:10 the device tree generator is another one.... Mar 13 05:59:43 oops Mar 13 05:59:50 My BoneScript library just uses a collection of templates to generate device tree overlays and isn't generic. the GSoC project would be to create a generic generator. Mar 13 05:59:55 could you elaborate a bit more on that? Mar 13 06:00:24 I mean I want to move from doing attachInterrupt using epoll/POLLPRI to building a device tree overlay for gpio-keys and creating a real input event." a different project? Mar 13 06:00:31 could you elaborate on that one please? Mar 13 06:00:31 the device tree source files have a certain text format that is parsed by the device tree compiler to generate some binaries read by the kernel. Mar 13 06:00:37 oh.... Mar 13 06:01:44 I have a template for the pinmux helper and I'd want to replace it with a template for gpio-keys such that when someone attempted to attachInterrupt a pin, the gpio-keys driver would get loaded. Mar 13 06:02:17 the issue with using the standard gpio driver (and the pinmux helper to set the specific pin mode) is that it doesn't generate full input events... Mar 13 06:02:33 a Linux input event is time stamped and placed in a buffer. Mar 13 06:04:20 jkridner, is it related to https://groups.google.com/forum/#!topic/beagleboard/Nrn0G52Rs6M ? Mar 13 06:04:22 http://www.linuxjournal.com/article/6396 Mar 13 06:04:29 I need to lookup the docs and get a clearer picture first Mar 13 06:05:30 yes.... the epoll library works around the issue by being buildable with newer node versions, but it still uses the gpio-sysfs entries and POLLPRI. Mar 13 06:06:40 okay Mar 13 06:07:06 and you want to use gpio-keys and make it generate the full list Mar 13 06:07:26 but the generic gpio-keys doesn't do that and I would have to look into it and fix it? in layman terms? Mar 13 06:08:32 oh. so it is compatible with older node versions? Mar 13 06:08:37 jkridner, Mar 13 06:09:48 it avoids needing to do the epoll at all. Mar 13 06:10:22 epoll is needed to make the node.js event loop wake up when an event occurs on a gpio-sysfs entry. Mar 13 06:11:05 with gpio-keys, the gpio toggles are turned into keypress events. Mar 13 06:12:16 I really need to look into the source before I can comment on this Mar 13 06:12:34 I will keep you posted Mar 13 06:12:53 Can I create a "work in progress" proposal for now? Mar 13 06:15:28 this post shows how simple it could be to read a gpio-keys driver in node.js: http://hackaday.com/2012/08/04/node-js-for-linux-joysticks/ Mar 13 06:16:01 wiznerd: sure, I'll avoid getting it ignored or anything like that until you've had a chance to go back and forth on it a few times. Mar 13 06:16:21 I worked on QtScript last GSoC. It uses the same semantics as JS if that helps :) Mar 13 06:16:35 okay :) Mar 13 06:27:47 jkridner, I have to go now. I'll update other details by weekend and will keep you posted. Good talking to you Mr. Kridner Mar 13 06:27:56 good night! Mar 13 10:31:07 Morning Mar 13 12:07:00 hi there Mar 13 12:07:15 +1 Mar 13 12:07:22 Abhishek_ : maybe you saw in #sigrok that I've already started down the black LA path Mar 13 12:07:43 Yes I did Mar 13 12:08:04 How is the progress? Mar 13 12:08:17 the design is pretty trivial Mar 13 12:08:55 the make or break research point for me is to see how much bandwidth can be gotten from PRU inbound to ARM Mar 13 12:09:13 and how much the ARM can sustain while doing something meaningful with the data Mar 13 12:09:28 it's actually the same idea that I had :) Mar 13 12:09:41 theoretical max approaches 200Mbyte/s Mar 13 12:09:58 indeed, but then how to do it is the challenge Mar 13 12:10:06 which is of course too much for passing it out through ethernet Mar 13 12:10:38 It's okay, the idea was also to use the A8 for post-processing Mar 13 12:11:36 I think 2Gbps is a lot of data also for the A8 Mar 13 12:12:23 getting it in will just use two of the three PRU DRAMs and ping-pong between the buffers Mar 13 12:12:54 code for writing to the buffers will be repetitive and has to be hand-written Mar 13 12:13:08 okay, have you written any code I might try and test? Mar 13 12:13:30 no Mar 13 12:13:57 I've used the PRU for another project where I used events in both PRU->ARM and ARM->PRU directions Mar 13 12:14:04 and the shared memory Mar 13 12:14:11 I see Mar 13 12:14:16 it's not really much more than the example code does Mar 13 12:14:20 just the events weren't in there Mar 13 12:14:28 and the example code looks like crap Mar 13 12:14:53 I've been working on the other end, getting the pru package usable in libsigrok Mar 13 12:15:08 Which is what I planned to do when I begin Mar 13 12:15:10 the PRU code will, again, be trivial and pretty stupid Mar 13 12:15:22 all in all it's a project for a weekend Mar 13 12:16:29 I have other ideas too, however, which concern more on the front - end than on the backend Mar 13 12:17:06 So if the PRU code would indeed be trivial, I could try and focus more on that part Mar 13 12:17:15 those would be sigrok gsoc projects then Mar 13 12:17:46 Sigrok would be used only for the backend, there would be a different frontend Mar 13 12:19:11 Something web-based, for example Mar 13 12:19:46 BTW, I think I know you, from the OpenOCD mailing list Mar 13 12:20:56 I think a sigrok frontend for web would be cool Mar 13 12:20:59 yes, OpenOCd Mar 13 12:21:01 OpenOCD Mar 13 12:21:13 though I have given up on that project long ago to be honest Mar 13 12:25:13 In previous discussions on this thread, kernel developers did point out possible arbitration issues and stuff which could mess up things when done in real time. Mar 13 12:25:39 when I was discussing about the PRU and tapping data from it. Mar 13 12:25:49 are you familiar with double buffering? Mar 13 12:27:21 Double buffering, as in, reading into one buffer while accessing another? Mar 13 12:27:45 well googled Mar 13 12:29:01 the buffer size determines how much time the ARM can spend copying the previous buffer Mar 13 12:29:22 indeed Mar 13 12:29:40 one buffer 8kb another 12kb Mar 13 12:29:51 how long does it take for PRU to fill 8kb at 200Mbyte/s ? Mar 13 12:30:28 41us. Mar 13 12:31:34 ? Mar 13 12:31:38 I think 40 Mar 13 12:31:44 dunno where you got the 1 from :) Mar 13 12:32:09 If you take 8KB= 8192 bytes, then it is 40.96 us :) Mar 13 12:32:17 which I rounded off to 41 Mar 13 12:32:23 oh yes all right Mar 13 12:32:44 I don't think Linux can do anything useful in that short time Mar 13 12:33:05 so performance will never approach theoretical max Mar 13 12:33:15 question becomes, how good will it actually be Mar 13 12:33:33 how about using the EDMA then? Mar 13 12:34:03 what's the math? Mar 13 12:34:37 and can it be driven from the PRU? Mar 13 12:35:44 (of course it can be, everything can) Mar 13 12:35:54 indeed Mar 13 12:36:02 but how fast can it be? Mar 13 12:37:30 Lemme check in the ref manual Mar 13 12:41:56 The DMA runs at 200 MHz, if I am not wrong Mar 13 12:43:01 did that answer your question? Mar 13 12:43:05 no Mar 13 12:43:34 the question is how long it takes to move the 12kb buffer off PRU Mar 13 12:43:53 or perhaps it will only be 8kb Mar 13 12:43:57 for uniformity Mar 13 12:47:36 well, that would take the same time I suppose Mar 13 12:50:57 but how long? Mar 13 12:51:22 I did mention 41us, given the DMA too runs at 200 MHz Mar 13 12:51:37 does the DMA use an 8 bit word size? Mar 13 12:52:42 ah yes, so 10.24us . Mar 13 12:54:35 does that mean 200MHz is out of question? Mar 13 12:55:17 you tell me? Mar 13 12:56:34 and tell me why Mar 13 12:56:57 (or why not) Mar 13 13:00:37 av500: ping Mar 13 13:01:00 vvu|Log, ping Mar 13 13:02:57 CareBear\ : Sure, let me get back to you in a few hours. Looking forward to see you again. Mar 13 13:03:07 I want to use starterware with RTOS. Mar 13 13:03:34 praveendath92: will be back in a couple of minutes Mar 13 13:03:40 Okiee Mar 13 13:11:42 praveendath92_: pongo Mar 13 13:13:20 I have gone through ADK and other methods in detail Mar 13 13:13:28 Have a few questions Mar 13 13:13:31 sure Mar 13 13:14:36 From what i found out, the ADK project from TI for BB is derived from Google ADK and uses same protocol AOA... Mar 13 13:15:21 well yes Mar 13 13:15:27 to be ADK is has to do ADK Mar 13 13:15:51 Since the guys at TI have made most of that communition part Mar 13 13:16:13 ..so is it fine if we build thia project upon that ? Mar 13 13:16:19 hmm Mar 13 13:16:21 no Mar 13 13:16:38 Still couldn't figure out the reason. Mar 13 13:16:40 we need ADK running on a Linux USB host Mar 13 13:16:46 so, it's a kernel USB Driver Mar 13 13:16:53 Yeah I got that. Mar 13 13:17:11 most ADK projects use some small microcontroller as the host Mar 13 13:17:18 Okiee. Running on a RTOS won't do ? Mar 13 13:17:19 and the phone on the other end Mar 13 13:17:25 praveendath92_: no Mar 13 13:17:36 because what UI would you transfer for your RTOS? Mar 13 13:17:46 BBB is about running linux Mar 13 13:18:00 really, the first part of the project is to get ADK host running on Linux Mar 13 13:18:13 so that Linux on the BBB can talk to Android Mar 13 13:18:19 using the ADK protocol Mar 13 13:18:42 The way I thougtt about it is... ADK host runs on a linux OS running on BBB Mar 13 13:18:48 As an application Mar 13 13:19:12 no Mar 13 13:19:16 not an application, as a kernel usb driver Mar 13 13:19:19 as an app it cannot transfer the screen content Mar 13 13:19:30 its a way to do it, but not universal enough to be reused Mar 13 13:19:40 you dont want to add this user space ADK to every app Mar 13 13:19:45 * vvu|Log did it with taking multiple screenshots :) Mar 13 13:20:00 Okiee. Mar 13 13:20:07 vvu|Log: right Mar 13 13:20:11 but no :) Mar 13 13:20:25 So, this has to be done at kernel level ? Mar 13 13:20:33 yeah, anyway it is super slow Mar 13 13:20:54 I guess it would be. Mar 13 13:21:37 takes like 0.5s to take a screenshot Mar 13 13:22:02 Abhishek_ : very well Mar 13 13:22:06 praveendath92_: yes at kernel level Mar 13 13:22:19 but as I said, we can use DisplayLink as an example Mar 13 13:22:23 it does exactly the same Mar 13 13:22:25 thta framerate is just bad Mar 13 13:22:37 we might even reuse their protocol (if it makes sense) Mar 13 13:23:34 I'm kind of new to working at kernel level stuff. Is it possible that I can reuse the libraries from TI project to do this ? Mar 13 13:24:23 those are not compatible with the kernel code *i think* Mar 13 13:24:39 but what libraries? Mar 13 13:24:55 can you point me to these libraries? Mar 13 13:25:22 They have libraries to handle AOA communication. Mar 13 13:25:51 can you point me to them? Mar 13 13:26:05 There are others too, like Device Abstraction Layer but we can write them. Aure Mar 13 13:26:10 Sure* Mar 13 13:26:16 you dont need a Device Abstraction Layer Mar 13 13:26:24 Just a min. On my mobile rigjt now Mar 13 13:26:26 it's called Linux for BBB Mar 13 13:26:30 no hurry Mar 13 13:26:36 can be later Mar 13 13:26:44 Yeah. We wont need DAL Mar 13 13:26:45 so we have a Device Abstraction Layer already :) Mar 13 13:27:28 Yeah. Mar 13 13:28:06 So, it has to be at linux kernal level using AOA protocol Mar 13 13:28:23 no HALs Mar 13 13:28:27 no DALs Mar 13 13:28:31 stop. Mar 13 13:28:53 ^ for me ? Mar 13 13:28:58 yes, we stopped :) Mar 13 13:29:09 yes Mar 13 13:29:29 use native services Mar 13 13:29:50 yes yes Mar 13 13:29:54 I am telling him Mar 13 13:30:29 * panto sends in the bears^Wav500 Mar 13 13:31:35 Gotcha Mar 13 13:37:11 praveendath92: there are a lot of usb kernel drivers tutorials on the internet and with details there. Mar 13 13:38:15 ^ So, if I get the drivers right. Then it would be all about proper implementation of the protocol ? Mar 13 13:38:30 yes Mar 13 13:38:46 in more exact steps: Mar 13 13:38:59 1) make BBB behave as ADK host so that phone recognizes it Mar 13 13:39:10 2) make BBB use ADK protocol and talk to phone Mar 13 13:39:44 3) make virtual framebuffer on BBB side (see e.g. displaylink) Mar 13 13:39:51 4) send framebuffer data over ADK to phone Mar 13 13:40:18 5) write (small) android app that talks ADK and receives framebuffer data Mar 13 13:40:30 if we achieve this, I would be very happy Mar 13 13:41:26 This part was clear earlier. Just had a confusion about reusing TI code. Mar 13 13:41:37 Now it is cleared. Mar 13 13:42:03 * vvu|Log hates his internet connection...receiving messages with a big delay Mar 13 13:42:45 And about the libraries, the source isn't online for viewing Mar 13 13:43:11 It is available for dowload from ADK site. Mar 13 13:43:20 ^ The source code is available on http://developer.android.com/tools/adk/adk2.html Mar 13 13:43:59 well, sure you can reuse some of the code Mar 13 13:44:13 Okiee. And one last thing.. Mar 13 13:45:16 Do you have any specific recommendations to learn about kernel level programming ? I'm comfortable with C. Mar 13 13:47:46 I mean resources or links ? Mar 13 14:03:26 praveendath92: there are plenty of resources Mar 13 14:03:32 like the Linux device drivers book Mar 13 14:03:49 I would look into 2 things primarily: Mar 13 14:03:59 1) what is it on the host side to be "ADK" Mar 13 14:04:04 2) Displaylink Mar 13 14:05:57 I will look into these. Thanks a lot. Mar 13 14:06:15 np Mar 13 14:13:21 jkridner, hey! Mar 13 14:13:30 what time zone are you on? when do you usually come online? Mar 13 14:15:44 _av500_: are there any applicants for the multi boot project ? Mar 13 14:22:24 praveendath92: if you are interested, please register and start filling in the application Mar 13 14:22:40 it does not have to be all complete, it can be a work in progress until the deadline Mar 13 14:22:47 but its a good way to capture the "state" Mar 13 14:31:01 I started the process. I will update with my application link by today night. Mar 13 14:38:47 praveendath92: great Mar 13 18:24:28 There is no camera library for bbb right? could that be a gsoc project? Mar 13 18:24:39 for what camera? Mar 13 18:28:15 candid camera Mar 13 18:29:08 like cameras supported by the UVD driver? Mar 13 18:29:18 sorry UVC Mar 13 18:32:19 I did a project on the Logitech C920 using quite a bit of code from Derek Molly's BoneCV but I've been streaming it via an ethernet cable onto VLC media player. Mar 13 18:33:23 It would be great to stream it online maybe be integrating it with PyBBIO or bone script. Mar 13 19:34:35 hello Mar 13 19:36:10 monday, i have been said that the PRU firmware loader was no more available because the dev had already been done Mar 13 19:36:44 So, are the other projects related with the kernel still available ? Mar 13 19:43:53 chocko: it isn't upstream for one Mar 13 19:49:41 ds2: ping Mar 13 19:49:49 <_av500_> rseethamraju: I am sorry, I dont understadn the scope of the project Mar 13 19:51:14 ya I don't mean I want to do only that. But no one mentioned it at all so I wanted to. Mar 13 19:51:52 <_av500_> did you look at the proposed projects? Mar 13 19:51:56 <_av500_> on the wiki? Mar 13 19:52:02 Derek Molly's bonecv code almost does it all anyway but streaming it online hasn't been done at all Mar 13 19:52:30 ds2: I am now quite interested in the project "IIO debugging tools" from here : http://elinux.org/BeagleBoard/GSoC/Ideas#IIO_debugging_tools Mar 13 19:52:37 yes I've been talking to Alexander Hiam about PyBBIO so I'll probably apply for that Mar 13 19:53:35 but he said he doesn't have any idea about cameras so I just wanted to know if anyone's interested Mar 13 19:55:04 especially about streaming video from a remote bbb to anywhere with internet. Mar 13 19:58:52 I've worked on streaming video but right now it streams onto VLC media player. The BBIOserver can already be used to control the BBB so it would be really cool to have a camera at the remote location and control the bbb based on the camera feed Mar 13 20:01:27 <_av500_> streaming video is a solved issue mostly Mar 13 20:01:33 <_av500_> vlc, gstreamer etc Mar 13 20:01:42 <_av500_> what would be novel here? Mar 13 20:08:01 yes but its not online. Mar 13 20:08:24 <_av500_> ? Mar 13 20:08:43 oh wait I got what you're saying Mar 13 20:08:46 ya Mar 13 20:09:26 I was thinking more playing it on the browser kind Mar 13 20:11:56 <_av500_> thats is a solved issue too Mar 13 20:12:22 can you give me a link please? Mar 13 20:12:28 <_av500_> to what? Mar 13 20:12:53 to the code to play it in the browser Mar 13 20:13:23 <_av500_> browsers support to play video Mar 13 20:13:27 <_av500_> I have seen it Mar 13 20:15:15 ok I'll look at it then thanks Mar 13 20:16:07 another problem I had was that the camera and wi-fi modem had to be interfaced from the same usb jack Mar 13 20:16:20 <_av500_> there is hubs for that Mar 13 20:16:32 it keeps crashing because it can power both of then together Mar 13 20:16:38 *them Mar 13 20:16:47 <_av500_> there are powered hubs for that Mar 13 20:16:52 <_av500_> no SW will help here Mar 13 20:17:13 oh ok thanks Mar 13 20:18:24 Have to go! Its 2 am here. Thnak you! Mar 13 20:35:40 Where can we access the instruction encoding on the PRU? It seems not to be mentioned in the ref manual Mar 13 20:59:12 CareBear\ : How about using both the PRUs together, and let one access the GPIO, and write to shared memory and then use the other one to transfer to DDR? That was one of the ideas that had been discussed. Mar 13 21:22:33 Hmmm Mar 13 21:24:33 The PRU seems to be too much of an unexplored territory Mar 13 21:24:45 indeed Mar 13 21:25:52 Where can we access the instruction encoding that the PRU uses? Mar 13 21:26:21 I mean, trying to disassemble PRU firmware, for example. Mar 13 21:26:42 ds2: hi Mar 13 21:27:27 hi chocko Mar 13 21:27:29 ds2 : I am now quite interested in the project "IIO debugging tools" from here : http://elinux.org/BeagleBoard/GSoC/Ideas#IIO_debugging_tools Mar 13 21:27:53 is it stiil available ? Mar 13 21:27:55 Abhishek_: I don't think it is documented Mar 13 21:28:10 chocko: nothing is set til after the acceptance date Mar 13 21:28:23 are you familiar with what IIO is? Mar 13 21:28:24 hmm, somewhere I read that it has actually been *removed* from the datasheets by TI Mar 13 21:28:46 evtest you mean ? Mar 13 21:28:51