**** BEGIN LOGGING AT Wed Jul 09 02:59:58 2014 Jul 09 03:15:32 everyone back from the holiday? Jul 09 03:38:16 got enough corn? Jul 09 05:32:25 morning **** BEGIN LOGGING AT Wed Jul 09 08:43:13 2014 Jul 09 11:41:25 morning Jul 09 11:53:42 gm jkridner Jul 09 13:30:33 karki: howdy. any updates on instruction set definition? also, only 3 operations still? (DIO, WAIT, GOTO)? Jul 09 14:29:08 alexanderhiam: can you try the opencv code I sent you today? Jul 09 15:20:51 rseethamraju: didn't work Jul 09 15:21:03 really? Jul 09 15:21:13 aww this is bad! Jul 09 15:21:37 I found ffserver that takes the ffmepg as a source and streams it via rtp Jul 09 15:21:58 have you looked at avconv? Jul 09 15:22:02 It worked for me! Jul 09 15:22:17 ya kindof Jul 09 15:22:24 when I ran ffmpeg it said "This program is only provided for compatibility and will be removed in a future release. Please use avconv instead." Jul 09 15:22:28 but that didn’t work for me Jul 09 15:22:53 it didn’t say that for me Jul 09 15:23:50 rseethamraju: http://pastebin.com/ynVnaF3P Jul 09 15:24:01 did the openCV work? Jul 09 15:24:23 ah, no, it's the opencv part that doesn't work Jul 09 15:24:48 when I just run capture.py it keeps printing "select timeout" Jul 09 15:25:24 so there wasn’t a file Jul 09 15:25:28 ? Jul 09 15:25:41 it said the same thing for me but I got a foo.avi Jul 09 15:25:57 I got the file, but it's just a second of nothing Jul 09 15:26:49 it's cv.GrabFrame() that's timing out Jul 09 15:27:07 and the tostring() looks weird too Jul 09 15:27:37 shouldn’t it be something encoded? Jul 09 15:27:56 and btw won’t audio be an even bigger issue on openCV? Jul 09 15:29:12 perhaps Jul 09 15:31:01 alexanderhiam: I’m going to start from scratch Jul 09 15:31:35 reread everything and then do it. This is scattered Jul 09 15:32:32 rseethamraju: at this point I think it would make the most sense to just do it the way that works for the C920 and not worry about other webcams Jul 09 15:32:52 then gstreamer would be best Jul 09 15:33:02 because I can easily do the audio Jul 09 15:33:18 yeah Jul 09 15:33:42 either way I’ll read gstreamer’s documentation from scratch tomorrow and figure it out by the meeting Jul 09 15:33:59 as in today and tomorrow Jul 09 15:34:40 ok Jul 09 15:44:37 checking off status reports 15 minutes before the meeting.... Jul 09 15:46:23 Victor's was first... https://groups.google.com/d/msg/beagleboard-gsoc/BISQ3fJj3P4/LemnP-Muim0J Jul 09 15:46:47 Then karki: https://groups.google.com/d/msg/beagleboard-gsoc/wCj6xtYMT0c/m1siecDlFI8J Jul 09 15:47:22 er https://groups.google.com/d/msg/beagleboard-gsoc/wCj6xtYMT0c/q9HI7FftvQkJ Jul 09 15:47:56 then rseethamraju: https://groups.google.com/d/msg/beagleboard-gsoc/i4VLmPyWFAI/M7RlJ746_GsJ Jul 09 15:48:41 rseethamraju: I just merged the eqep and spi branches together into the experimental branch, if you can sync up with that and just add some docs to the encoder library and example then I think we'll be about ready to upload a package to PyPi Jul 09 15:49:01 Praveen was next: https://groups.google.com/d/msg/beagleboard-gsoc/FvT9XR3P5Ow/013m8piXUA0J Jul 09 15:49:56 DiegoTc provided: https://groups.google.com/d/msg/beagleboard-gsoc/mPa69fBjkmg/T8yQQKCWW2gJ Jul 09 15:52:50 just missing Abhishek_? Jul 09 15:53:07 in a few minutes Jul 09 15:53:25 (typing out issues) Jul 09 15:55:47 what just happened o.O? Jul 09 15:56:52 av500: ping Jul 09 15:58:02 <_av500_> praveendath92: pong Jul 09 15:58:41 Any thoughts on what could be the format of a frame data ? Jul 09 15:59:40 PPM? Jul 09 15:59:56 <_av500_> er no Jul 09 15:59:59 jkridner: I redid mine. Sorry! Jul 09 16:00:00 <_av500_> raw RGB Jul 09 16:00:25 <_av500_> 32 bit Jul 09 16:00:27 <_av500_> or 24bitr Jul 09 16:00:28 jkridner: done Jul 09 16:00:35 <_av500_> actually fbset or so should tell you Jul 09 16:00:50 <_av500_> praveendath92: look at the size of the framebuffer Jul 09 16:01:08 Let me check the size. Jul 09 16:01:17 rseethamraju: I just confirmed that attachInterrupt is broken, the temp sensor code isn't the issue Jul 09 16:01:26 hi all Jul 09 16:01:31 hello! Jul 09 16:01:41 hello all Jul 09 16:01:45 ahoy Jul 09 16:01:58 yee haw Jul 09 16:01:59 I see rseethamraju's update at https://groups.google.com/d/msg/beagleboard-gsoc/i4VLmPyWFAI/SP5nXE_gMvMJ Jul 09 16:02:01 alexanderhiam: oh ! Jul 09 16:02:04 av500: By size of framebuffer as in the size of the data sent to android on xstart? Jul 09 16:02:11 Hello :) Jul 09 16:02:21 and I see Abhishek_'s update at https://groups.google.com/d/msg/beagleboard-gsoc/R0sCsWK-8JQ/RkYsopeL80oJ Jul 09 16:02:27 <_av500_> praveendath92: well, what size do you get? Jul 09 16:02:28 let's begin! Jul 09 16:02:39 <_av500_> praveendath92: you should have 10245x768x3 bytes or so Jul 09 16:02:51 any additional business besides the updates or anyone that MUST leave early? Jul 09 16:02:52 <_av500_> x4 if its 24bit RGB in 32 bit Jul 09 16:03:02 Anyone seen Victor? Jul 09 16:03:20 I was able to sync with him on Monday, so not a huge deal if not here. Jul 09 16:03:22 av500: So, it's the data size right? Jul 09 16:03:31 <_av500_> praveendath92: what size do you get? Jul 09 16:03:38 The Monday-stupid-early meetings are happening. Jul 09 16:03:49 av500: There is compression. That affects the size? Jul 09 16:03:56 <_av500_> compression? Jul 09 16:04:09 Yep. Jul 09 16:04:14 karki_: got your next tasks and no blocking issues? Jul 09 16:04:19 I think RLE. Jul 09 16:04:35 karki_: how is the list of command op codes going? Jul 09 16:04:37 jkridner : you will have a lot more commands supported by the end of this week. Jul 09 16:04:41 :) Jul 09 16:04:54 I'm documenting as we type Jul 09 16:05:01 paper? :-/ Jul 09 16:05:13 <_av500_> praveendath92: what function of udlfb gets the data? Jul 09 16:05:17 going into git soon? Jul 09 16:05:24 hello! Jul 09 16:05:26 jkridner : yeah. I'm putting is on an .md file soon Jul 09 16:05:28 README.md seems like a good place. Jul 09 16:05:30 <_av500_> world! Jul 09 16:05:50 The framebuffer data? Jul 09 16:05:57 blinkLed Jul 09 16:06:02 <_av500_> praveendath92: yes Jul 09 16:06:09 <_av500_> praveendath92: we have the fb working now Jul 09 16:06:13 the flow-control and variables portion doesn't seem to be in your plan. Jul 09 16:06:14 <_av500_> now its time to send the data Jul 09 16:06:27 <_av500_> so you need to understand how a fb driver works Jul 09 16:06:32 <_av500_> and what function to hook into Jul 09 16:06:43 also, the PWM integration on the 2nd PRU doesn't seem to be there either. Jul 09 16:06:46 <_av500_> in the end, you can just take the whole buffer and copy it over Jul 09 16:06:47 just "PWM libraries" Jul 09 16:07:00 av500: dlfb_submit_urb Jul 09 16:07:01 <_av500_> praveendath92: you should have access to that buffer from the driver Jul 09 16:07:10 <_av500_> praveendath92: gimme the github url pls Jul 09 16:07:15 <_av500_> (home pc) Jul 09 16:07:27 karki_: I see that all your interface stuff is one-way, don't forget that you need to send return values from every command Jul 09 16:07:34 karki_: will you be using the StarterWare code to help speed the development of the ADC and DIO portions using the other peripherals? Jul 09 16:07:48 av500: https://github.com/praveendath92/udlfb Jul 09 16:07:56 praveendath92: the fb uses double buffer procedure, and it acts like a char driver. it exports read/write to userspace Jul 09 16:08:16 karki_: did I lose you? Jul 09 16:08:18 jkridner : by libraries I meant code on the 2nd PRU which will take care of PWM Jul 09 16:08:30 praveendath92: you write in the fb and when fb buffer is ready it swaps the pending buffer with the old one so screen does not change constantly Jul 09 16:08:41 k. what about the flow-control and variables? Jul 09 16:08:53 alexanderhiam : I have kept a few days for designing the return values stuff Jul 09 16:08:58 karki_: those could get complex and are needed to finish the DIO. Jul 09 16:09:02 it is exactly how you did with adk read/write from/to userspace in the usb driver Jul 09 16:09:10 <_av500_> praveendath92: render_hline Jul 09 16:09:12 the same principle is followed as i kno Jul 09 16:09:18 <_av500_> and handle_damage Jul 09 16:09:26 vvu: Yes. So, when a frame has to be updated which call back is used? Jul 09 16:09:34 <_av500_> render_hline Jul 09 16:09:39 <_av500_> and handle_damage Jul 09 16:09:44 <_av500_> its not frames Jul 09 16:09:48 <_av500_> its a single framebuffer Jul 09 16:09:59 <_av500_> X renders into it and tells you what parts got updated Jul 09 16:10:05 <_av500_> put printks into the function and see Jul 09 16:10:07 jkridner : I will be using https://github.com/texane/pru_sdk to make life easier Jul 09 16:10:34 <_av500_> praveendath92: so for a quick start, copy the whole buffer on handle_damage Jul 09 16:10:38 <_av500_> it will be slow Jul 09 16:10:47 <_av500_> but you get an image and you can easily test Jul 09 16:10:58 jkridner : where is the starter ware code? I haven't used StarterWare...... Jul 09 16:11:03 I will test with that. Jul 09 16:11:35 _av500_: When you said X tells the buffer what parts are updated. Jul 09 16:11:43 karki_: k. The #beaglepilot team did an import and experiment with StarterWare: https://github.com/BeaglePilot/PRUSS-C Jul 09 16:11:52 thanks! Jul 09 16:12:03 Does the framebuffer send a whole new frame when ever there is an update? Jul 09 16:12:22 <_av500_> praveendath92: the framebuffer does not "send" anything Jul 09 16:12:29 <_av500_> the framebuffer is a buffer Jul 09 16:12:36 <_av500_> see dlfb_ops Jul 09 16:12:40 I meant the udlfb driver Jul 09 16:12:45 <_av500_> these are all the ops that make the fb API Jul 09 16:12:53 <_av500_> praveendath92: no, it does not Jul 09 16:13:04 <_av500_> thats why handle_damage has x and y and size Jul 09 16:13:38 <_av500_> praveendath92: see that most ops end up in handle_damage Jul 09 16:13:47 <_av500_> and that ends up in render_hline, which sends one line over Jul 09 16:14:08 panto, alexanderhiam: any other queries for karki_? Jul 09 16:14:17 Oh. I get it now. Jul 09 16:14:34 <_av500_> you have to write your own render_hline Jul 09 16:14:40 karki_: please publish the opcode stuff ASAP and add the flow-control and variables to the schedule. Jul 09 16:15:01 _av500_: An resource where I can read about the fb API? Jul 09 16:15:15 rseethamraju: any questions about next steps or any blocking issues? Jul 09 16:15:17 Any* Jul 09 16:15:45 karki_: please do confirm you understand my request. Jul 09 16:15:53 <_av500_> http://www.linux-fbdev.org/HOWTO/4.html Jul 09 16:16:00 jkridner : flow control etc. are this week. I'm writing code to compile the IF's and SET var's etc to byte code right now Jul 09 16:16:04 <_av500_> praveendath92: but google can tell you that too :) Jul 09 16:16:36 This is elaborative. The ones I landed on are not so. Jul 09 16:16:39 Thanks :) Jul 09 16:17:04 <_av500_> https://www.google.com/search?q=linux+framebuffer+api Jul 09 16:17:11 <_av500_> thank larry and sergey Jul 09 16:17:35 * vvu encourages everybody to use lmgtfy Jul 09 16:17:50 vvu: Haha. Jul 09 16:18:05 jkridner: not really Jul 09 16:18:09 rseethamraju: any updates on the SPI interrupt issue? Jul 09 16:18:12 sorry got stuck Jul 09 16:18:29 jkridner : that is what you are asking, right? (I'm done with the lex part, now working on bit of yacc. once I can generate the bytecode, I'll update the firmware) So don't worry if you were thinking about the IF, and SETs and variables etc. Jul 09 16:18:58 no have to fix that Jul 09 16:19:39 jkridner: it turns out the issue is with the interrupt caode itself, the sensor is getting configured fine Jul 09 16:19:44 I'm looking into it Jul 09 16:20:00 av500: won't be easier to send a full buffer to the android side rather than line by line ? don't think u can render a new line in a imageview or smth like that Jul 09 16:20:14 alexanderhiam: eqep docs means docstrings or documentation? Jul 09 16:20:19 <_av500_> vvu: for a start, yes Jul 09 16:20:26 <_av500_> anything to get me a picture Jul 09 16:20:35 <_av500_> vvu: but usb will be the bottleneck Jul 09 16:20:38 karki_: yes, the IF, SET and also DIO w/ variables is what has me worried. Jul 09 16:20:44 <_av500_> so updating lines still makes sense I think Jul 09 16:20:47 rseethamraju: function docs and file docs first, then wiki pages as well Jul 09 16:20:50 <_av500_> then we can rerender on android ide Jul 09 16:21:08 yeah, i remember sending the .img.xz over usb on android took a lot of memory Jul 09 16:21:22 my app was freeing like crazy memory to acomodate its needs Jul 09 16:21:46 alexanderhiam: ok Jul 09 16:22:01 jkridner : Don't worry :) I have it covered! Jul 09 16:22:09 alexanderhiam: k. hope that isn't holding rseethamraju up. thanks for jumping in to help fix. Jul 09 16:22:26 * jkridner hears famous last words Jul 09 16:22:39 alexanderhiam so do I remove the setAlarm in the example? Jul 09 16:22:57 jkridner: no thats not holding me up Jul 09 16:23:19 rseethamraju: not yet, I should hopefully have it figured out by the time you're done with the eqep docs Jul 09 16:23:29 praveendath92: seems you are getting a lot of guidance today. how are you feeling about your next step and ability to make progress? Jul 09 16:23:37 * alexanderhiam speaks famous last words Jul 09 16:24:08 jkridner: I passed the hurdle that has been bothering for most of this week, Jul 09 16:24:26 All thanks to _av500_ Everything looks good right now. Jul 09 16:24:31 alexanderhiam: doing the docs right now Jul 09 16:25:17 jkridner: I should be able to render a frame on Android by next week. Jul 09 16:25:56 <_av500_> praveendath92: end of this week pls :) Jul 09 16:26:09 Yes. yes. Jul 09 16:26:27 cool, I'll shop for a cheap Android tablet to have something bigger than my Galaxy S2. Jul 09 16:27:23 next step is beagleception, put android on another BBB and try to run everthing :) Jul 09 16:27:32 jkridner: I also use a GS2 :) Jul 09 16:27:56 vvu: and then use an android tablet to receive the signal from that another android BBB :P Jul 09 16:28:13 praveendath92: k, if you feel good and I see vvu and _av500_ interacting here, I'll move on to DiegoTc. Jul 09 16:28:30 vvu: I will try to get the image on Android by this week (not beagle-gsoc week ;)) Jul 09 16:28:33 Abhishek_: too much beagleception Jul 09 16:28:37 And then I will do that part. Jul 09 16:28:43 DiegoTc: Thanks for the chat earlier in the week. We'll do that again this week, but I wanted to try to cover your blockers here. cc VoltVisionSteve Jul 09 16:28:59 praveendath92: when you have time do a full tutorial that people can follow. Jul 09 16:29:04 ok jkridner Jul 09 16:29:16 step by step Jul 09 16:29:17 I'm concerned that while we didn't give the complete greenlight on the editor, I think we did walk away with some explicit actions to address on it. Jul 09 16:29:49 vvu: I will. Also, I need to combine the adk mode switching with the udlfb driver. Jul 09 16:29:58 DiegoTc: do you feel like you have a list you are working against? Jul 09 16:29:59 Right now I need to load two modules. Jul 09 16:30:08 DiegoTc: because I didn't see it in the status report. Jul 09 16:30:45 jkridner: yes, I focus it all on the edit and create, Jul 09 16:30:51 i wasn't specific Jul 09 16:31:09 I have a big concerned, issue, right now about bone101 Jul 09 16:32:01 ? Jul 09 16:32:39 I now I will finish the project, and will have some good tutorials written, and they will work live using bonescript lib. But I think you & VoltVisionSteve will not like it completely. I mean I'm focusing on functionality right now, not how it looks Jul 09 16:33:15 praveendath92: i will step out for today, if there is something mail and i will try to help Jul 09 16:33:25 vvu: Sure. Jul 09 16:33:36 DiegoTc: understood. I know VoltVisionSteve and I both complain a bit about various visual aspects.... please feel OK ignoring those and focusing on the functionality. Jul 09 16:33:48 vvu: I will read the API for now. Jul 09 16:34:01 ok, i will take a look too later today Jul 09 16:34:06 I have that feeling, that design is being an issue. I know that create isn't the great website ever, but I don't consider it the worst also: http://diegotc.github.io/bone101/Support/GSOC/app/views/create.html Jul 09 16:34:18 <_av500_> praveendath92: regardless of API, you need a way to send the framebuffer over to the android Jul 09 16:34:20 praveendath92: basically it is a char driver with extra goodies Jul 09 16:34:23 <_av500_> and to render on android Jul 09 16:34:24 DiegoTc, jkridner : agreed. Functionality first...then pretty it up...perhaps we can get the Guatemalans to pick up on that sometime soon. Jul 09 16:34:30 (or someone else) Jul 09 16:34:31 functionality does include things like making both HTML WYSIWYG and code (Ace editor) cards, plus create/edit/fork options. Jul 09 16:34:51 yes, that I have it. Jul 09 16:35:11 praveendath92: that part you have already in the adk driver *as i remmeber*, you just need to hook em up in a nice way. Jul 09 16:35:18 alexanderhiam: there’s the stepper library in the experimental branch Jul 09 16:35:26 DiegoTc: I still owe you some input on the visual side as well Jul 09 16:35:43 jkridner: Create with WYSIWYG, preview card should be small, code card and html card should be normal size Jul 09 16:35:53 rseethamraju:oh, good point Jul 09 16:35:55 DiegoTc: if you could rewrite the list of TODOs for the status report, I'd appreciate that. Jul 09 16:35:56 _av500_: vvu: A bulk transfer is happening when I start xserver. Jul 09 16:36:00 ok Jul 09 16:36:03 I think it is the framebuffer. Jul 09 16:36:11 DiegoTc: agree on all those points. Jul 09 16:36:11 I will put it on the group list Jul 09 16:36:26 I had to update the endpoint address in the udlfb driver urbs. Jul 09 16:36:29 praveendath92: yep that thingie, just put bulk where you have the full buffer ready and ship it to android Jul 09 16:36:29 <_av500_> praveendath92: you mean using the displaylink protocoll? Jul 09 16:36:40 <_av500_> you need to remove that Jul 09 16:36:42 <_av500_> and use yours Jul 09 16:37:08 <_av500_> Id like you to add a few prinks and see what api calls happen and with what params Jul 09 16:37:31 have it Jul 09 16:37:39 after the meeting I'm adding it Jul 09 16:37:40 _av500_: Yes. Some data is being transferred to Android. Yes, it is using DisplayLink protocol. Jul 09 16:37:47 DiegoTc, VoltVisionSteve: should the final code displayed be displayed using that GIST preview or loaded into an ACE editor window? I'm inclined to believe it is better for it to be in an ACE editor view than that GIST embed. Content would still be loaded from GIST. Jul 09 16:38:10 I was thinking of the same. Adding printks Jul 09 16:38:13 alexanderhiam: and the test.py Jul 09 16:38:46 jkridner, if in the ACE editor, it would encourage editing and tweaking and playing on the fly right? Jul 09 16:38:47 DiegoTc, VoltVisionSteve: if displayed in ACE, then you really are getting WYSIWYG even for the code. Jul 09 16:38:57 yes Jul 09 16:39:03 VoltVisionSteve: exactly, just like on the existing tutorials. Jul 09 16:39:13 ACE Jul 09 16:39:15 Save/fork could aways be an option to preserve your playing. Jul 09 16:39:30 DiegoTc: do you understand/agree with the request? Jul 09 16:39:47 jkridner: not really Jul 09 16:39:55 trying to understand it Jul 09 16:40:20 I'm saying pull the content from GIST just like you'd do to edit the content for the display of that content as well. Jul 09 16:40:34 and use ACE to do the display/edit. Jul 09 16:40:44 rseethamraju: where's test.py? Jul 09 16:40:50 jkridner: you mean something like http://jsfiddle.net/ Jul 09 16:40:56 oh sorry I meant testenc.py Jul 09 16:41:01 you see it live, but you can edit it Jul 09 16:41:06 yes. Jul 09 16:41:17 which is exactly how the existing tutorials are done. Jul 09 16:41:34 alexanderhiam: never mind Jul 09 16:41:41 I got you Jul 09 16:41:48 sweet. Jul 09 16:41:52 there’s only the stepper example Jul 09 16:41:54 but I will continue using ACE & summernote Jul 09 16:41:55 this lets people edit/play on the fly and leads them down the path of forking eventually. Jul 09 16:42:23 Question about that Jul 09 16:42:39 ACE for code and Summernote for HTML. Jul 09 16:42:58 Code = JavaScript, BASH, Python, etc. Jul 09 16:43:03 If i get VoltVisionSteve tutorial and edit live and save it Jul 09 16:43:15 my edition will cause what? Jul 09 16:43:29 if it came from VoltVisionSteve, your save should create a fork... Jul 09 16:43:31 a fork? update VoltVisionSteve tutorial Jul 09 16:43:48 and you should fork your list of tutorials to now include your fork. Jul 09 16:44:18 you shouldn't be able to write a new revision directly to VoltVisionSteve's tutorial... Jul 09 16:44:42 (that would be ouchy) Jul 09 16:44:43 but you can let him know about your version if you want such that he could integrate your changes, such as if you have a bug fix. Jul 09 16:44:50 question, you are planning that the edit works on the card? Jul 09 16:44:58 I mean I have this tutorial Jul 09 16:44:58 http://diegotc.github.io/bone101/Support/GSOC/app/views/tutorial.html?gistid=afb483bbf1c1789be837 Jul 09 16:45:36 you want to edit it Jul 09 16:45:37 mmmm Jul 09 16:45:45 If you are the owner, you should be able to edit it to make new revisions. Jul 09 16:45:46 I have it Jul 09 16:45:52 if you aren't the owner, you should be able to fork it. Jul 09 16:46:02 ahh first you jhave to click fork Jul 09 16:46:02 ok Jul 09 16:46:27 yes, fork then edit. Jul 09 16:46:35 fork = copy to your ownership. Jul 09 16:46:49 ok, sounds great! Jul 09 16:47:08 yeah Jul 09 16:47:57 you'd also want to fork the listing of tutorials such that you keep a list of all of your tutorials. I know your current approach is just to search all GISTs for a given user, but I do have concerns about that scaling. If you don't get my meaning, I can address this later. Jul 09 16:48:30 ok, go ahead jkridner Jul 09 16:48:41 you want me to elaborate? Jul 09 16:49:04 your current solution does a search for GISTs that use "Bone101 Tutorial" as the title.... Jul 09 16:49:11 I though you were give me the idea of how you were palnnin to do it Jul 09 16:49:19 So i can implement it Jul 09 16:49:20 that's cool until someone has hundreds of gists. Jul 09 16:49:29 then it starts to bog down. Jul 09 16:49:49 A gist that contains a list of gist IDs is another way. Jul 09 16:49:54 Yes Jul 09 16:50:15 an individual can add new gists to his own list and even have gist IDs for tutorials he didn't create. Jul 09 16:50:47 so, instead of doing a search to create the list based on the owner, you are just using the gist IDs listed within this GIST. Jul 09 16:51:08 when I did my demo, I included that functionality. Jul 09 16:51:17 (I just never handled the forking aspect) Jul 09 16:51:28 Yes, I'm using it foe filling the index Jul 09 16:51:29 https://gist.github.com/DiegoTc/25aec40876dfb11f8d36 Jul 09 16:52:28 OK, so you are already taking this approach and not just doing a search? Jul 09 16:52:44 <_av500_> jkridner: praveendath92 vvu: need to go Jul 09 16:52:56 * jkridner waves to _av500_ Jul 09 16:52:57 I'm doing the search for user, not for getting all tutorials Jul 09 16:53:01 _av500_: Ciao :) Jul 09 16:53:10 But I was thinking in doing it the same way you just told me Jul 09 16:53:31 the first time a user creates or forks a tutorial Jul 09 16:53:48 An IndexBone101 gist will be created Jul 09 16:53:59 with the id of all the gist he owns Jul 09 16:54:14 DiegoTc: the reason I brought it up was when you fork VoltVisionSteve's tutorial, you might have found it in a list of tutorials he has (a collection of decks). You'd want to fork that list at the same time, replacing the one deck you are editing with a pointer to the new deck you created. Jul 09 16:55:11 DiegoTc: the concept is that while there is a master 'bone101' list of tutorials, there could be hundreds or thousands of collections done by other people choosing different tutorials to put in the list. Jul 09 16:55:40 this "collecting" aspect along with the simplicity of making a tutorial is what is meant to make this a hugely collaborative effort. Jul 09 16:56:03 Further, people could embed their collections on their own websites. Jul 09 16:56:23 Hope I'm making this more clear and not less clear. Jul 09 16:56:48 I think I got you Jul 09 16:56:54 * jkridner looks for Abishek_ Jul 09 16:57:02 jkridner: that's all? Jul 09 16:57:05 hi Abhishek_... Jul 09 16:57:14 * Abhishek_ was looking for the gavel in jkridner's hand :) Jul 09 16:57:17 only a couple of minutes and wanted to make sure you could start. Jul 09 16:57:21 alexanderhiam: should I put the license stuff in both the README and the beginning of the library? Jul 09 16:57:40 DiegoTc: yeah, unless you have concerns. I can hang around after... just wanted to get started with Abhishek_. Jul 09 16:57:48 ok Jul 09 16:57:50 thanks Jul 09 16:58:40 karki_: have you checked out what Abhishek_ has done regarding the kernel driver? Jul 09 16:58:59 karki_: supposedly Abhishek_ has split remote_proc from beaglelogic, though I haven't verified myself yet. Jul 09 16:59:06 Abhishek_: I'm recompiling your latest stuff now. Jul 09 16:59:22 Abhishek_: I used karki_'s approach to grabbing kernel sources. Jul 09 16:59:23 rseethamraju: just do it however the other libraries do Jul 09 16:59:35 k Jul 09 16:59:39 Abhishek_: which means I edited your kernel driver Makefile. Jul 09 17:00:22 jkridner: there's a pru_rproc_bl branch that has the remoteproc module which you could compile separately Jul 09 17:00:33 the patched remoteproc Jul 09 17:01:47 rseethamraju: email id? alexanderhiam@gmail.com or hiamalexander@gmail.com Jul 09 17:01:54 jkridner: I do not recommend that now, however since the code is upstream, but it's useful to test without recompiling the kernel (though I am not sure if it works now) Jul 09 17:02:58 rseethamraju: put your name and email on the files you wrote, you should take the credit Jul 09 17:03:07 oh Jul 09 17:03:10 right Jul 09 17:03:14 it will but you might end up loading the compiled-in remoteproc instead of the module pru_rproc_bl so the latest kernel is what I recommend, bone60 onwards you needn't compile any modules at all, it's all there Jul 09 17:03:14 Abhishek_: it is upstream? Jul 09 17:03:25 and just say something like "Part of PyBBIO" Jul 09 17:03:31 jkridner: ^ Jul 09 17:03:32 Abhishek_: do you mean in the rcn-ee kernel? Jul 09 17:03:33 k Jul 09 17:04:04 alexanderhiam: that means instead of Copyright 2012 Alexander Hiam? Jul 09 17:04:06 boneXX != upstream Jul 09 17:04:12 upstream == Linus's tree Jul 09 17:04:23 rseethamraju: right Jul 09 17:04:29 ds2: sorry for the terminology, I call that "mainline" Jul 09 17:04:41 Upstream = "vendor" Jul 09 17:04:45 'k Jul 09 17:05:14 but what is 'vendor'? that should be based on the debian kernel in the first place.... vendor could also mean the TI tree(s) Jul 09 17:05:39 Upstream here is rcn-ee's kernel Jul 09 17:05:52 the one that is shipped in debian images Jul 09 17:07:19 k, I prefer to call that rcn-ee's kernel or the BeagleBone kernel... upstream to me === mainline Jul 09 17:07:47 k, I will post a clarification on the update mail for the record. Jul 09 17:09:00 Abhishek_: know your next tasks? any blockers? Jul 09 17:09:29 the next task is benchmarking the socket.io link Jul 09 17:09:31 Abhishek_: your "issues" look more like next-steps. Jul 09 17:09:57 yup, because the next-steps would turn up issues Jul 09 17:11:23 and about the kernel driver and upstreaming it, larsc at #sigrok pointed me to the IIO framework which had a more probability of acceptance. Anyway, upstreaming is a post-GSoC task so, we'll see how it can be done Jul 09 17:13:05 IIO would be on top of remoteproc, no? Jul 09 17:13:12 panto: ? Jul 09 17:13:30 ds2, bradfa: ? Jul 09 17:13:33 yup, so it is a long way, only after remoteproc goes upstream. Jul 09 17:13:50 jkridner, one second, I'll scroll back Jul 09 17:14:22 in theory, sure Jul 09 17:14:32 I have yet to see a general usage of IIO Jul 09 17:14:33 I could try and sneak in the PRU-specific code into BeagleLogic, but it would be reinventing the wheel Jul 09 17:14:58 so, if you want to chase that outside of GSoC, go ahead Jul 09 17:15:05 jkridner, yes Jul 09 17:15:16 it's just a higher level protocol like PWM Jul 09 17:16:10 k. just wanting a clear assertion that remoteproc isn't taken out of the picture with suggestion of using IIO... it just means you would have a more generic interface than today at the higher level. Jul 09 17:16:29 also jkridner, biot is currently testing the BeagleLogic patch, so it should be in the upstream sigrok very soon :) Jul 09 17:16:36 jkridner, sorry, don't think I'm one to really comment on that, not my area of knowledge Jul 09 17:16:45 Abhishek_: sent you a pull request. Jul 09 17:16:46 [unless he uncovers bugs I couldn't see in my tests] Jul 09 17:17:26 ...got to head out. Jul 09 17:18:41 * jkridner slams gavel. Jul 09 17:18:43 thanks all! Jul 09 17:19:28 jkridner: This Makefile pertains to cross-compiling the kernel module out-of tree from my build PC more than compiling it on the BeagleBone itself. Jul 09 17:19:28 Abhishek_, DiegoTc, praveendath92, rseethamraju, karki_: please continue as you have queries/time. Jul 09 17:19:50 karki_: please do coordinate with Abhishek_ on using the remoteproc in -bone60 Jul 09 17:20:04 sure :) Jul 09 17:20:04 Abhishek_: k. any way to make it more generic? Jul 09 17:20:25 panto was talking about refactoring the whole rproc driver.... Jul 09 17:20:26 * jkridner only compiles big stuff cross in order to simplify instructions for newbs. Jul 09 17:20:35 yup, I'll see and make up a small patch. Jul 09 17:21:08 rseethamraju: fixed the attachInterrupt() issue, working now on that immediate false interrupt (it's a different issue) Jul 09 17:21:33 ok Jul 09 17:22:09 alexanderhiam: I just finished the eqep documentation and pushed to my spi Jul 09 17:23:15 ok so I’ll add the readme to the temp sensor and docs to the eqep Jul 09 17:23:23 great Jul 09 17:23:30 I meant spi Jul 09 17:23:41 and the docs too Jul 09 17:23:55 is the eqep readme ok? Jul 09 17:25:13 looks great! Jul 09 17:34:22 jkridner: which "boneXX" kernel is on your BBB? Jul 09 17:35:36 alexanderhiam: do I have to write a #!/usr/bin/env python in the example programs? Jul 09 17:37:08 I haven't been, but there's no reason not to Jul 09 17:43:29 Abhishek_: right now, -bone50, but I just did 'update_kernel.sh' to -bone60 Jul 09 17:43:47 alexanderhiam: done! Jul 09 17:44:33 jkridner: if you already have the firmware from https://d8a0b5d606f320db2dca525de17833da935fbbb0.googledrive.com/host/0B7U2bJEjkNeZSVVBMFU4WVBkS2c/ , does modprobe "beaglelogic" work? Jul 09 17:44:56 * jkridner doesn't work that way. :-) Jul 09 17:45:21 if I can't build it from source for projects like this, I don't try it. Jul 09 17:45:52 I see Jul 09 17:47:34 I took in your pull request. Jul 09 17:51:38 jkridner: ok, what more impedes you from compiling and testing it? The remoteproc module or the beaglelogic module? Jul 09 17:51:54 time Jul 09 17:52:26 the pull request might not work for you with cross compilation... don't want to break that. Jul 09 17:52:56 but I can override the KSRC=on my side on make, that should not hurt Jul 09 18:26:21 * Abhishek_ flushes the accumulated spam queue in his blog Jul 09 18:37:23 jkridner: have you noticed that epoll based GPIO interrupts are firing a false event when you first register them? (It's happening for me both in pybbio and bonescript; we're using the same approach) Jul 09 18:37:59 yeah, I've seen that. I think you can read to eliminate it. Jul 09 18:40:28 jkridner: what do you mean? Jul 09 18:43:22 don't recall exactly, but I think you always get an initial event and you can simply perform a single (blocking or non-blocking) read at the beginning to clear the event and then go to a blocking read to detect future events. Jul 09 18:44:23 ah, gotcha Jul 09 21:02:34 Abhishek_: ping Jul 09 21:02:52 anujdeshpande: pong Jul 09 21:04:07 Abhishek_: https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/BB-BEAGLELOGIC-00A0.dts i see that you are using the pru0 as input, know any place where i’ll get the dts for pru1 as input ? Jul 09 21:04:24 * anujdeshpande is trying to save some efforts Jul 09 21:04:54 anujdeshpande: mine uses PRU1 as input. Jul 09 21:05:04 which line are you looking at? Jul 09 21:06:58 Abhishek_: my bad, i meant pru0 as input. the ones from p8-11 to 31(or most of it) Jul 09 21:08:09 hmm, k, BTW what are the inputs intended for on the BeaglePilot hardware? Jul 09 21:08:43 Abhishek_: we are going to have pru0 do the inputs, and pru1 will be doing the pwm outputs Jul 09 21:09:20 Abhishek_: https://github.com/BeaglePilot/ardupilot/blob/master/Tools/Linux_HAL_Essentials/BB-BONE-PRU-05-00A0.dts Jul 09 21:10:17 hmm, what kind of inputs will you be using the PRU for? Jul 09 21:11:45 PPM-SUM, sbus, etc Jul 09 21:12:22 I see. Jul 09 21:12:40 So no pointers to easy help ? Jul 09 21:12:47 you could grab a DTS with the pindefs and modify the pinmuxes Jul 09 21:13:49 I mean, if there's a DTS which has those PRU0 configured for output, you would just need to modify the hex codes to config them as inputs Jul 09 21:13:59 for the hexcodes, refer: Jul 09 21:14:09 http://pinmux.tking.org/ Jul 09 21:14:49 Abhishek_: i get that. i am wondering if i have to make changes to the fragments other than the one which has the reg offsets and values Jul 09 21:15:50 yep, the one which has the offsets and values. In your case: https://github.com/BeaglePilot/ardupilot/blob/master/Tools/Linux_HAL_Essentials/BB-BONE-PRU-05-00A0.dts#L70 Jul 09 21:16:47 Abhishek_: so no changes https://github.com/BeaglePilot/ardupilot/blob/master/Tools/Linux_HAL_Essentials/BB-BONE-PRU-05-00A0.dts#L102 onwards ? Jul 09 21:17:16 no, that's intended for the remoteproc driver, does not affect the pinmux Jul 09 21:18:19 Abhishek_: thanks Jul 09 21:18:41 all you need to do would be just unset 0x20 from each commented line Jul 09 21:18:57 0x26 -> 0x06 ; 0x25 -> 0x05 and so on Jul 09 21:19:31 Abhishek_: all i need is one line tbh :) Jul 09 21:19:37