**** BEGIN LOGGING AT Thu Mar 17 02:59:58 2016 Mar 17 03:40:48 anyone there to help ? Mar 17 03:42:12 m_w, ds2 ! are we still on that idea ? Mar 17 03:53:44 I am here Mar 17 03:54:25 did you see the email I forwarded from Jonathan? Mar 17 03:59:22 I am reading that .... Mar 17 04:07:33 m_w: did mpu9250 work with mpu6050 driver? Mar 17 04:07:43 yes Mar 17 04:08:02 m_w: how?? how did you get the magnetometer stuff working? Mar 17 04:08:50 I registered it in the devicetree. And I did not test the magnetometer. Mar 17 04:09:49 m_w: link Mar 17 04:09:56 to what? Mar 17 04:10:15 m_w: to the device tree you registered in. Mar 17 04:10:53 I used the patched the Dragonboard 410C devicetree in the mainline Mar 17 04:11:39 actually it was linux-next Mar 17 04:12:19 because the patch just came in recently Mar 17 04:13:30 it is not online anywhere Mar 17 04:13:39 you want me to post it? Mar 17 04:14:07 the patch that I applied that is Mar 17 04:14:16 m_w: yeah.. Mar 17 04:14:26 okay Mar 17 04:20:07 m_w: is the pru servo driver merged in the 4.1 kernel? Mar 17 04:20:12 http://pastebin.com/wC5PV1yx Mar 17 04:20:20 I mean to say this: https://github.com/diydrones/ardupilot/tree/master/Tools/Linux_HAL_Essentials/pru/pwmpru Mar 17 04:20:29 no it is not Mar 17 04:21:16 m_w: the link which I posted.. is the pru servo driver right?? Mar 17 04:22:48 I believe so Mar 17 04:23:11 do you know how to clone linux-next? Mar 17 04:26:13 m_w: what is linux-next? Mar 17 04:29:30 it is the integration tree for the linux kernel Mar 17 04:29:56 https://www.kernel.org/doc/man-pages/linux-next.html Mar 17 04:30:36 you patch against this tree when looking to mainline patches Mar 17 04:31:31 you will see the tag that I checked out in the pastebin Mar 17 04:41:27 m_w: OK.. gotcha!! Mar 17 04:42:22 m_w: Do you know about meta-ros? Mar 17 04:42:49 it is an openembedded layer for ROS Mar 17 04:54:06 m_w: can't ros itself run on beaglebone? Mar 17 04:54:26 m_w: just like it can on raspberry pi and so on.. Mar 17 04:54:31 *can run Mar 17 04:57:22 sure Mar 17 05:07:06 m_w: if ROS itself can run on beaglebone.. why is meta-ros used?? Does it provide some features which ROS itself does not have? Mar 17 05:08:38 it is for building ROS from source using openembedded Mar 17 05:09:00 are you using debian on your BBB? Mar 17 05:13:32 http://wiki.ros.org/BeagleBone Mar 17 05:17:17 https://vmayoral.github.io/beagle-ros/ Mar 17 05:17:32 this is for angstrom Mar 17 05:51:46 hey nerdboy ! do you think a project such as this ... be a part of GSoC- https://www.youtube.com/watch?v=YrtANPtnhyg Mar 17 05:52:03 ofc, only a part, as it would be a very long project. Mar 17 06:10:21 m_w: there? Mar 17 06:10:23 this take me back to 2009-10 when I had a beagleboard revC and pico projector Mar 17 06:10:27 yes Mar 17 06:10:44 m_w: so... I am using ubuntu in beaglebone black.. Mar 17 06:10:44 nerds were flocking from all around Mar 17 06:10:49 so Mar 17 06:11:13 you can install using apt probably Mar 17 06:11:19 m_w: I mean.... we can directly install ros there right?? Mar 17 06:11:46 apt-get update Mar 17 06:11:53 apt-cache search ros Mar 17 06:12:08 m_w: using this: http://wiki.ros.org/indigo/Installation/UbuntuARM Mar 17 06:12:36 http://elinux.org/BeagleBoardUbuntu Mar 17 06:13:34 lemme see Mar 17 06:13:43 yeah that Mar 17 06:14:09 what version of Ubuntu you have? Mar 17 06:14:17 cat /etc/issue Mar 17 06:19:11 meta-ros is just a metadata layer for openembedded Mar 17 06:19:54 m_w: Ubuntu 14.04.3 LTS Mar 17 06:22:23 builds ros into oe image Mar 17 06:22:34 there's meta-uav also Mar 17 06:22:43 nerdboy: do you know beagle-ros? Mar 17 06:22:51 nope Mar 17 06:23:20 a little about amvlink/ardupilot Mar 17 06:23:25 *mavlink even Mar 17 06:29:30 kiran4399: have you tried the installation based on the instructions from the link you posted above? Mar 17 06:29:33 i can add meta-ros and meta-uav to the beagle manifest thing Mar 17 06:30:33 couldn't hurt Mar 17 06:30:35 m_w: I am trying now.. Mar 17 06:30:39 good Mar 17 06:30:42 m_w: everything is running smooth.. Mar 17 06:30:53 excellent Mar 17 06:31:14 nerdboy: did you look at ZeekHuge's new idea? Mar 17 06:31:33 m_w: I am supposed to develop a standalone ros on beaglbone blue.. Mar 17 06:31:53 m_w: not sure if alexhiam meant the meta-ros or the main ROS itself.. Mar 17 06:32:13 meta-ros builds the main ROS Mar 17 06:32:50 for an OE based distro Mar 17 06:32:59 like poky or angstrom Mar 17 06:33:19 yeah, can't watch it right now Mar 17 06:33:32 anything written? is it open source yet? Mar 17 06:33:51 it is "open source" :) Mar 17 06:34:12 sadly it is for windows in C# Mar 17 06:34:26 but it uses opencv in there somewhere Mar 17 06:34:59 I think a gesture recognition project would suit him well given his experience Mar 17 06:37:06 m_w: what is oe based distro? Mar 17 06:37:38 oe = openembedded Mar 17 06:37:54 m_w: is debian a oe_based distro? Mar 17 06:37:59 https://en.wikipedia.org/wiki/OpenEmbedded Mar 17 06:38:00 [WIKIPEDIA] OpenEmbedded | "OpenEmbedded is a software framework used for creating Linux distributions aimed for, but not restricted to, embedded devices. The build system is based on BitBake recipes, which behave like Gentoo Linux ebuilds.Recipes in the old OpenEmbedded-Classic were all found in one place. In the new OpenEmbedded..." Mar 17 06:38:03 I mean ubuntuarm Mar 17 06:38:32 https://en.wikipedia.org/wiki/Yocto_Project Mar 17 06:38:32 [WIKIPEDIA] Yocto Project | "The Yocto Project is a Linux Foundation workgroup whose goal is to produce tools and processes that will enable the creation of Linux distributions for embedded software that are independent of the underlying architecture of the embedded software itself. The project was announced by the Linux Foundation..." Mar 17 06:39:29 I have been openembedded since before it was cool Mar 17 06:40:30 nerdboy, http://www.pranavmistry.com/projects/sixthsense/ Mar 17 06:40:56 or this https://en.wikipedia.org/wiki/SixthSense Mar 17 06:40:57 [WIKIPEDIA] SixthSense | "SixthSense is a gesture-based wearable computer system developed at MIT Media Lab by Steve Mann in 1994 and 1997 (headworn gestural interface), and 1998 (neckworn version), and further developed by Pranav Mistry (also at MIT Media Lab), in 2009, both of whom developed both hardware and software for both..." Mar 17 06:42:51 http://angstrom-distribution.org/ Mar 17 06:45:07 off to bed Mar 17 07:07:03 https://github.com/VCTLabs/vct-beagleboard-bsp-platform/tree/oe-master Mar 17 07:07:34 try oe-master branch if you want uav/ros layers Mar 17 13:07:22 Hello everyone Mar 17 13:14:02 Good Morning ! Mar 17 13:14:16 Hey ds2 ! you there ? Mar 17 15:21:37 Hi ds2 ! there ? Mar 17 15:22:42 hey alexhiam ! how does this project look to you ? https://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/08/04/bbb--high-speed-data-acquisition-and-web-based-ui Mar 17 15:22:53 implementing it in a more generic manner ? Mar 17 15:23:13 and extending its capabilities ? Mar 17 15:25:22 ZeekHuge: not sure what "a more generic manner" means... is there a source repo? Is the code under an open source license? Mar 17 15:26:24 perhaps adding analog support to Abhishek_'s beaglelogic? not sure if sigrok supports that Mar 17 15:27:20 the only imp code is that of PRU, which is just to capture data .. and dump it into the shared memory. Mar 17 15:27:49 generic manner = making it readily available ... Mar 17 15:28:58 not sure what "readily available" means either... I see a downloadable zip of all the code Mar 17 15:30:56 yes. it is there .. Mar 17 15:31:36 also , sigrok supports analog as it supports oscilloscopes : https://sigrok.org/wiki/Supported_hardware#Oscilloscopes Mar 17 15:32:23 what I'm getting at is that I'm not yet seeing a summer's worth of full time work involved in making that more available. If you can flesh that out into a solid proposal it could work though Mar 17 15:32:43 I'd encourage you to try and get in touch with shabaz Mar 17 16:49:37 alexhiam: ping :) Mar 17 17:03:10 jkridner, alexhiam: the ROS support for beaglebone which I plan to do... I hope I need not use meta-ros right? Mar 17 17:03:27 I just need to develop the main ROS.. right? Mar 17 17:05:43 where's your draft? Mar 17 17:06:08 nerdboy, did you see that sixth sense project ? Mar 17 17:07:33 nerdboy: that message for me? Mar 17 17:14:27 kiran4399: yes Mar 17 17:14:57 http://www.qgroundcontrol.org/mavlink/start <= you guys should go through the mavlink/mavconn/architecture stuff Mar 17 17:15:18 https://pixhawk.ethz.ch/software/middleware/start Mar 17 17:15:33 it ties in with ros via mavros Mar 17 17:16:23 https://erlerobotics.gitbooks.io/erlerobot/content/en/mavlink/ros/mavros.html Mar 17 17:17:59 jkridner: Ha. I'm over here now Mar 17 17:18:03 kiran4399: what exactly is in your "plan" so far? Mar 17 17:18:57 I am almost done with my first draft.. will be up by tomorrow morning.. :-) Mar 17 17:19:07 mavlink/mavconn/ros are all higher level "things" Mar 17 17:19:15 nerdboy: do you want me to tell the crude layout of my plan? Mar 17 17:19:21 they all need ardupilot more or less Mar 17 17:19:44 no, i can wait to see the draft... Mar 17 17:20:25 so 1. would be ardupilot support for all the sensor interfaces Mar 17 17:22:26 I think before that comes getting all the kernel drivers in place, doesn't it? Mar 17 17:22:41 including the PRU servo firmware and driver? Mar 17 17:22:54 that *is* getting driver support Mar 17 17:23:29 right. It's just not ardupilot specific Mar 17 17:23:30 meaning ardupilot can see/talk to them Mar 17 17:24:06 we were also talking about then porting the Strawson C APIs to use those drivers, for those who don't want to use ardupilot Mar 17 17:24:08 in this case it kinda is, in that the other stuff does nothing without ardupilot integration Mar 17 17:24:51 it's the first/necessary layer in top of hradware interfaces Mar 17 17:24:56 yup Mar 17 17:24:57 *hardware even Mar 17 17:29:08 so maybe 1. enable sensor interfaces, and 2. ardupilot integration, then 3. another layer (ros/mavlink) Mar 17 17:30:42 nerdboy: that's exactly how I planned my timeline!! Mar 17 17:32:09 and let's not forget documentation and examples ;) Mar 17 17:33:26 alexhiam: yeah.. Mar 17 17:33:49 alexhiam: do you have any idea on how to test the kernel drivers for mpu9250, baro and pru servo driver? Mar 17 17:33:59 and some tests... Mar 17 17:34:40 *requirements and tests Mar 17 17:34:40 Hi: I would like to mentor a project (or maybe more) for GSoC Mar 17 17:34:57 Ideas include an Android port to BeagleBoard x15 Mar 17 17:35:09 And a Brillo port to BBB Mar 17 17:35:20 Do you think these are runners? Mar 17 17:35:45 and since we're using some python, maybe a reqs tool even Mar 17 17:36:16 http://doorstop.info/ <= people can start documenting/pushing project reqs now Mar 17 17:36:28 what a concept! Mar 17 17:37:35 http://doorstop.info/reqs/index.html <= nice example Mar 17 17:37:53 anyone get the joke yet? Mar 17 17:40:23 if you're getting excited now, you *might* be a software engineer... Mar 17 17:47:58 jkridner: should I just post ideas in the GSoC page? I'm not sure if they are suitable Mar 17 17:48:18 simmondscd: you are looking to be a mentor? Mar 17 17:48:32 Brillo to BBB would be great! Mar 17 17:51:07 jkridner: Yep, I am Mar 17 17:53:37 jkridner: what is the baro used? Mar 17 17:53:40 in blue? Mar 17 18:07:40 On what? Blue? BMP280 Mar 17 18:12:16 kiran4399: well getting data from the devices would be a good test of the drivers Mar 17 18:44:39 Ohk so , this link shows an interesting application of the on chip PRUs. Now what i would like to propose is ( with this link as a proof of concept ), adding oscilloscope and voltmeter capabilities to the beaglebone black. As the sigrok already supports the oscilloscope functionality, the user space processing of the data would be implemented using sigrok. But at the PRU end, the data would be sampled at high rate using a parallel ADC. In such a Mar 17 18:44:41 manner the board could read atleast 1Mhz sine wave (and more if we are able to optimize it ) further, could be added to this if a sampling rate less than the highest limit of the PRU is needed. We could oversample the ADC to get some extra bit depths. Mar 17 18:45:39 hello everyone, I am Pranjal and I am interested in GSoC for BeagleBone. Can someone please help? Mar 17 18:46:02 link - https://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/08/04/bbb--high-speed-data-acquisition-and-web-based-ui Mar 17 18:47:21 anyone? Mar 17 18:48:16 So that would probably involve writing firmware for the PRUs on would be sampling the data, other transferring the data. And this would be through the remoteproc .. Mar 17 18:48:40 Any mentors would like to suggest any missing point in that ? Mar 17 18:49:26 as alexhiam said .... it dosent seem to be a long enough project ,. Mar 17 18:50:02 can you please suggest how to add bits so as to make it useful and a valid project for a period of three months ? Mar 17 18:51:30 ds2 ! would you like to comment on that ? Mar 17 18:53:00 jkridner: I've talked with ebadawy about bone101 to know more about how it works, I've noticed that there are some issues with the last PR that need to be fixed. Mar 17 18:53:52 jkridner and also reviewed your post on the milling list and want to know more details about your ideas. Mar 17 19:47:49 hey, can someone please tell me if these proposed ideas are done or is someone working on it...i am interested in working on these ideas 1. Enhance ADC driver for BeagleBone and BeagleBone Black 2.Library of Arduino-compatible functions for StarterWare Mar 17 19:51:05 onezero_: who are the mentors listed? Mar 17 19:52:12 for 1 -> Hunyue Yau and for 2 -> Jason Kridner Mar 17 19:56:07 jkridner is here somewhere... Mar 17 20:04:55 around, but not reading. Mar 17 20:05:35 questions about starterware? ^^ Mar 17 20:14:52 starterware is cool Mar 17 20:14:54 :-) Mar 17 20:18:18 onezero_: ask away Mar 17 20:41:23 jkridner: amragaey is the friend of mine I was telling you about, I've discussed with him what I did in bone101 last year Mar 17 21:00:22 jkridner: I'm preparing to write the proposal, I need to know your ideas this year. I can see there're some bugs already that need to be fixed, and I have some ideas to enhance UX for novice developers Mar 17 21:00:49 amragaey: my ideas are on the ideas page. Mar 17 21:10:04 jkrinder: I checked it, I want to get some details on the methods need improvements. Is it already implemented and I have to provide the proper UX to users, or I have to add the those methods first ? Mar 17 21:15:46 Hello Mar 17 21:16:24 Is there a way we can get the PRU's and the SGX to talk? Mar 17 21:16:44 I did a bit of digging and couldnt find anyhting Mar 17 21:23:45 i don't think there's any "built-in" way... Mar 17 21:24:19 not unless you implement one using lcms or something Mar 17 21:29:04 *lightweight marshaling library made for "talking" Mar 17 21:40:11 ebadawy Do you know if these methods already implemented in bone101 now ? Mar 17 21:40:55 nerdboy : ohh okay! Mar 17 21:41:24 amragaey: not sure what methods you mean, let me check the idea page again. Mar 17 21:42:30 nerdboy : so after our discussion yest, i was looking at sgx, and i think we could actually run our image processing codes in the sgx Mar 17 21:42:40 rather than in the pru's Mar 17 21:42:51 we use the pru's only to capture data Mar 17 21:43:37 and the image processing algos are run in the sgx Mar 17 21:46:18 hey alexhiam,You there? Mar 17 21:46:58 amragaey: if I'm getting jkridner right, i think if you focus your work on BBUI and its functionality with different types of senors plus the python support, that would be good to have. Mar 17 21:47:08 Here is the link to my helloworld driver.It is a very simple code but I hope to build on it:https://github.com/chanakya-vc/BBB-Gsoctry/tree/master/Drivers Mar 17 21:49:11 alexhiam, What kind of sample code for drivers would you be expecting before the proposal period ends? Mar 17 21:50:09 yashoza: sounds okay as long as the rest of the pipeline can keep up Mar 17 21:51:08 pru's capturing data in "real-time" will need a consumer to collect it at the same rate Mar 17 21:51:23 ebadawy: aha so I have to check functionality first and improve user experience after that.. I'm thinking to provide a guide like tooltips for new developers to on new components. Mar 17 21:52:15 maybe even something like ^^ lcms to generate notifications Mar 17 21:53:28 ebadawy: what do you mean to have python support here ? Mar 17 21:53:53 yashoza: mostly that stuff is already implemented and you should use it Mar 17 21:54:57 oh okay! Mar 17 21:55:28 amragaey: I mean that somehow you should be able to right javascript code (bonescript) in python, something like API interface between js and py Mar 17 21:55:39 but as u said, i'll be writing a communication medium of sorts for the pru and the sgx, right ? Mar 17 21:55:39 not sure how it will be implemented though. Mar 17 21:57:24 yashoza: https://pixhawk.ethz.ch/software/middleware/start Mar 17 21:58:33 http://qgroundcontrol.org/mavlink/start Mar 17 21:59:10 there is already mavlink/lcms and mavlink/ros for sharing/passing image data, etc Mar 17 21:59:48 you would just need to supply camera data and/or tap the data path Mar 17 22:00:31 okayy Mar 17 22:01:09 Great! Mar 17 22:01:23 ebadawy: why do we need to do that ? Mar 17 22:02:01 Also, nerbody, i wanted to ask you how we could move the project forward such that it is a big + to the community ? Mar 17 22:03:10 amragaey: some users prefer python over js, would be a good feature to add. Mar 17 22:09:18 ebadawy: interesting! I think python code code be sent through bonescript then.. I'll made some research on how to do that Mar 17 22:09:49 code could# Mar 17 22:10:38 great! I think you should work on your proposal as well because there is only one week left. Mar 17 22:10:42 good luck :) Mar 17 22:13:00 I hope to finish ASAP.. thanks ebadawy :) Mar 17 22:16:47 nerdboy, what say about this ? https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/edit?usp=sharing Mar 17 22:17:00 still to complete but that may give a rough idea Mar 17 22:18:56 yashoza: need to get some feedback i guess Mar 17 22:19:23 yes..i need to start doing that asap Mar 17 22:19:29 should become more obvious if you can sketch out a plan/where the holes are, etc Mar 17 22:19:43 as i am almost done with my timeline Mar 17 22:19:54 * develop/extend X interface here => Mar 17 22:19:58 etc Mar 17 22:19:59 yepp..i am almost done drafting that Mar 17 22:20:13 will post it up tomm morning Mar 17 22:20:17 okayy Mar 17 22:20:45 within the existing frameworks as much as possible Mar 17 22:20:56 any comments on that ? Mar 17 22:21:01 okayy Mar 17 22:21:31 unless you want/need to streamline the full pipeline on your own Mar 17 22:21:51 sketch that out too (probably a lot more work) Mar 17 22:21:52 i do not think that would be worth the time, would it? Mar 17 22:22:27 depends on reqs, but i tend to use stuff if works/fits my needs Mar 17 22:23:39 hmm..okay.. Mar 17 22:24:13 I'll need quite a lot of time & help to do that Mar 17 22:24:31 in this case it should be "about right" to fit your pieces into mavlink/ros Mar 17 22:24:35 that'll have to be submitted with my proposal, right? Mar 17 22:24:35 one or the other Mar 17 22:24:53 hmm Mar 17 22:25:13 i wouldn't spend much time on the "full" option Mar 17 22:25:21 *if any Mar 17 22:27:28 okayy..then i'll start by posting what i have drafted already, and we'll keep adding/modifying things as we move..is that okay? Mar 17 22:27:39 like i said, getting the messages/data-aq/consumers/gpu working smoothly with testing/docs will be enough work Mar 17 22:29:40 okay..so i'll fit that all into my timeline and post the draft asap Mar 17 22:30:46 and then the very important thing- getting feedback and making sure the project benefits the community :) Mar 17 22:34:11 should i proceed ? and how should i proceed ? anything on that ? Mar 17 22:40:25 sorry, was in regular afternoon mtg... Mar 17 22:41:01 ZeekHuge: gimme a few minutes Mar 17 22:41:09 sure :) :) Mar 17 22:41:22 and yashoza try to make a diagram? Mar 17 22:42:51 https://github.com/VCTLabs/foss-rst-presentations/blob/master/drones/images/mavlink_protocol_links.png Mar 17 22:43:08 that one is online somewhere, along with others Mar 17 22:44:02 in this case autopilot(ardupilot) and mavconn/ros run on the same host Mar 17 22:45:29 ^^that one is the lcm/mavconn version as opposed to the ros version Mar 17 22:45:48 you should pick one or the other Mar 17 22:46:33 if you do the interfaces right it could probably work for both Mar 17 22:47:12 you *could* add your own mavlink messages Mar 17 22:47:40 which would route over the right stuff in both cases Mar 17 22:48:13 http://qgroundcontrol.org/mavlink/create_new_mavlink_message Mar 17 22:50:50 hi I just finished writing application, Could you assess what I have to improve? Mar 17 22:51:41 Link is here: https://docs.google.com/document/d/1QGxnjvGWkyppsN7H8Hrc7XFoltBzVDaxKx9nXnQ1fBY/edit?usp=sharing Mar 17 22:54:46 ZeekHuge: that looks okay Mar 17 22:55:11 How about the idea ? that seems to be useful ? Mar 17 22:55:29 :) Mar 17 22:56:11 yeah, but i'm not the biggest user of that stuff Mar 17 22:56:39 so, any other mentor ? who is available at the moment ? Mar 17 22:56:44 audio processing maybe Mar 17 22:56:54 sounds good though Mar 17 22:57:07 thank you :) Mar 17 22:58:10 maybe wormo has some comments... Mar 17 22:59:03 but he isn't online .. Mar 17 22:59:32 she should be sooner or later Mar 17 23:00:02 ohk :) I'll ask her :) Thank you ! any suggestions on that ? Mar 17 23:00:17 Need to add a lot more to it though .. Mar 17 23:00:18 she's on weird/guest wireless when goes onsite usually so it might be later Mar 17 23:00:39 ahhh... ohk . Mar 17 23:01:25 pmezydlo: which one is yours? Mar 17 23:01:42 i don't see your nick on the google-y list Mar 17 23:02:33 * nerdboy upgrading firefox again Mar 17 23:03:20 not submitted yet i guess? Mar 17 23:08:49 how do you see said list? Mar 17 23:09:23 on the google-y review site? Mar 17 23:10:17 pmezydlo: instead of bash for the desktop side i would just use autotools/make Mar 17 23:10:31 otherwise keep going Mar 17 23:10:37 looks good so far Mar 17 23:10:45 yes Mar 17 23:13:12 ZeekHuge: regarding draft at https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/ Mar 17 23:13:26 yes .. Mar 17 23:13:34 the part about interrupt-driven data acq could be a little more nuanced, since there are a lot of cases where it is a perfectly good solution if the data rate is slow enough compared to CPU speed Mar 17 23:13:45 I guess I am not really a mentor Mar 17 23:13:45 also the other peripherals being serviced by main CPU needs to be considered Mar 17 23:14:19 i corrected it, if there is any mistake yet? Mar 17 23:14:30 if the data acq is done just saving to memory, interrupts will be serviced fine, as opposed to a CPU tied up having to babysit a bunch of other devices during acquisition Mar 17 23:14:36 m_w: did you register/login to gsoc site? Mar 17 23:14:56 it is by invite correct? Mar 17 23:15:11 the mentor invite should be enough Mar 17 23:15:21 overall it looks like the draft is coming along nicely though Mar 17 23:15:39 * nerdboy uses gmail account and i mostly just works... Mar 17 23:15:59 was I supposed to get an email with the invite? Mar 17 23:16:00 so Wormo, how should i correct that part ? Mar 17 23:16:04 google doc perms are separate Mar 17 23:16:13 m_w: yes Mar 17 23:16:22 did you? Mar 17 23:16:26 nope Mar 17 23:16:29 jkridner: ^^ Mar 17 23:16:35 invite please? Mar 17 23:16:49 ZeekHuge: I would just try to explain better the types of problems that really cry out for a separate data acq system like PRUSS Mar 17 23:17:13 ohk .. Mar 17 23:17:38 also Wormo , did you see that element14 link ? Mar 17 23:18:04 no maybe you just added it? Mar 17 23:18:28 yes i just did it .. Mar 17 23:18:51 jkridner: for m_w i mean, or i guess we could poke _av500_ Mar 17 23:19:33 well I will fall off the IRC until an email comes in Mar 17 23:19:36 it's good, relevantn Mar 17 23:19:56 good luck everyone Mar 17 23:20:00 ohk :) Mar 17 23:20:05 m_w, tc Mar 17 23:20:11 you can still see google docs and answer questions Mar 17 23:20:26 yeah I have been helping Mar 17 23:20:36 er, give a clue to the right direction... Mar 17 23:21:09 but I dont want to overstep my bounds if I am not a real mentor Mar 17 23:21:28 i don't think that matters much Mar 17 23:21:38 "not a real mentor" = not responsible for reviews Mar 17 23:21:48 okay Mar 17 23:21:53 and not getting the T-shirt, which I'm skipping anyways... Mar 17 23:22:07 I think I have helped quite a bit so far Mar 17 23:22:17 * Wormo has a room full of SCALE shirts Mar 17 23:22:26 always need another t-shirt... Mar 17 23:22:26 Wormo, are you on the doc ? should I add you with editing permissions ? Mar 17 23:22:52 ZeekHuge: no it's fine, I'll discuss it here Mar 17 23:23:15 m_w: yup, and don't let me stop you... Mar 17 23:23:22 ohk, it looks like someone there is trying to edit or add a comment to it .. Mar 17 23:23:44 * nerdboy has that annoying teacher's habit of not giving away the answers Mar 17 23:23:56 I was trying to figure how to add that feedback as a comment but decided to just tell you here Mar 17 23:24:20 Ohk :) Mar 17 23:27:55 you figure students using gsoc would be better at googling stuff Mar 17 23:29:10 there's a little black art there... Mar 17 23:29:31 but i didn't have google in school Mar 17 23:29:43 maybe alta vista i think Mar 17 23:29:55 Nope that was college Mar 17 23:30:00 at the end in grad school... Mar 17 23:30:10 Mmmmm yocto Mar 17 23:31:05 got a manifest thingie for that already Mar 17 23:31:07 hey ds2 ! how about this idea ? https://docs.google.com/document/d/1GfnoWusWUeH2VsLbt1qJaRi20uNxCC8O_Xw1CHoGY9A/edit?usp=sharing Mar 17 23:38:13 ZeekHuge: not in a place I can look at links... can you describe? Mar 17 23:38:34 sure .. Mar 17 23:38:56 so its about sampling an parallel ADC Mar 17 23:39:04 or such based device . Mar 17 23:39:15 tell me more :D and what sample rate? Mar 17 23:39:27 I have a personal project doing that... Mar 17 23:40:18 well, the already present work, can allow the board to read a sine wave of 1 MHz Mar 17 23:40:30 oh blah Mar 17 23:40:41 that isn't interesting :D Mar 17 23:40:54 ahh ... ? Mar 17 23:41:04 if you got 20-30MHz.... Mar 17 23:43:32 ADC1175 perhaps Mar 17 23:43:44 but that can be possible i think, given an ADC with better quality i guess. Mar 17 23:44:32 we can see what beaglelogic founnd to be the maximum rate Mar 17 23:44:50 to read a 20MHz sine wave it will need to sample at 40MHz .. isnt it ? Mar 17 23:44:58 I can look up my part Mar 17 23:45:07 at least Mar 17 23:45:47 nyquist says at least twice the highest frequency Mar 17 23:46:06 and the cores are at 200MHz so, and it takes single cycle to read a GPI ... so it can be achieved i think . Mar 17 23:46:15 yes .. Mar 17 23:46:21 no, nyquist doesn't quite say that Mar 17 23:46:28 what do you think ds2 ? Mar 17 23:46:29 nyquist says twice your BW Mar 17 23:46:41 sampling theorem Mar 17 23:46:45 ZeekHuge: depends on how you sell it... I can personally use that code in my project but... Mar 17 23:47:04 twice the highest frequency you want to reproduce iirc Mar 17 23:47:09 I can sample 25-26MHz signals with less then 52MHz Mar 17 23:47:30 read the theorem carefully (or look up undersampling or bandpass sampling) Mar 17 23:47:39 all sampling does is make a series of paper doll copies Mar 17 23:47:49 you can pick which one you want Mar 17 23:48:21 i didn't say there weren't tricks, etc Mar 17 23:48:36 200Mbps is the theoretical max on the PRU Mar 17 23:48:41 it isn't a trick; it is what the theorem really say Mar 17 23:48:42 basic sampling theorem is what it is Mar 17 23:48:56 ohk, so I will do the research, but so as to prevent what happened earlier, does this idea seems to be implementable ? Mar 17 23:49:14 ZeekHuge: what speed are you shooting for? Mar 17 23:50:37 how about > 50Mhz? Mar 17 23:50:42 atleast 20 MHz Mar 17 23:51:13 m_w: 50MHz isn't doable, AFAICT (do prove me wrong) Mar 17 23:51:33 ZeekHuge: that could be useful Mar 17 23:52:04 m_w: that is based on 1 instruction per cycle and having to toggle the sampling clock. 50MHz -> doing everything in 4 cycles Mar 17 23:52:22 and do you think that can be possible ? I mean, my rough calculations suggest so .. but do you think ? Mar 17 23:52:29 yes doable Mar 17 23:52:36 Ohk :) Mar 17 23:52:47 I have written code that mostly do that Mar 17 23:52:55 So I'll start my research on that .. Mar 17 23:52:58 but how will it talk to Linux? Mar 17 23:52:59 IIO? Mar 17 23:53:09 PRU code itself is uninteresting Mar 17 23:53:26 having an example of how to interface PRUs to a proper Linux subsystem is useful Mar 17 23:53:40 base also assumes a human hearing range where the low end is almost zero Mar 17 23:53:42 you mean PRU communication with the ARM ? Mar 17 23:54:17 yes Mar 17 23:54:17 ZeekHuge: yes. most folks thesedays just hack a way through. we needto start using standard APIs Mar 17 23:54:35 so say if you did an I2C master, it should appear to Linux as a proper I2C master Mar 17 23:54:38 * nerdboy makes too many audio assumptions Mar 17 23:54:53 well, then it what can be better than the existing PRU-framework project ? Mar 17 23:54:58 nerdboy: you can't "hear" DC? :D Mar 17 23:55:33 ZeekHuge: no no... the PRU framework is for the PRU... but your PRU firmware creates a soft peripheral...that needs to appear as a proper Linux device Mar 17 23:55:40 eh? Mar 17 23:55:56 * ds2 cranks up the volume Mar 17 23:56:06 I think it would be best to write an IIO driver that talks to the PRU firmware Mar 17 23:56:17 yes.. Mar 17 23:56:26 m_w: that'd be fine... we need examples in the community on how that is done Mar 17 23:56:40 a driver that talks to PRU on one end and IIO subsystem on the other Mar 17 23:57:57 memmaping the PRU's DRAM/SHRAM in userland is not really an acceptable solution Mar 17 23:58:10 ioremap the PRU in the driver Mar 17 23:58:17 and have at it Mar 17 23:58:30 no Mar 17 23:58:42 use the remoteproc api to get the addresses Mar 17 23:58:53 ah Mar 17 23:58:54 no shortcutting ! Mar 17 23:59:03 ha Mar 17 23:59:15 ah.. the PRU-framework is about remoteproc .. isnt it? Mar 17 23:59:20 so is there any code anywhere that does this the right way? Mar 17 23:59:26 well the new way is remoteproc; the old way is UIO Mar 17 23:59:42 m_w: not really... hence the need for examples.. that is where I see the value Mar 18 00:00:14 then the project is a goldmine Mar 18 00:00:52 but isn't there another project that will be attempting something similar? Mar 18 00:00:55 there are too many "crap" projects abusing Linux... need to clean that up. it isn't the authors fault either Mar 18 00:01:21 which other project? Mar 18 00:01:23 m_w: it is a project I proposed but I haven't seen students for it. Unless you mean the SPI slave aka eeprom emulator? Mar 18 00:01:44 the first one Mar 18 00:02:06 well maybe both Mar 18 00:02:10 ah... be happy to have it morph a bit depending on available resources/student interest Mar 18 00:02:15 ohk so what can be and should be used is remoteproc right ? Mar 18 00:02:28 ;) Mar 18 00:02:30 yes... Mar 18 00:02:37 to communicate and control the PRUs from the linux part. Mar 18 00:02:55 uio might be tolerated (Beagle community is addicted to UIO but TI and others want remoteproc as the path forward) Mar 18 00:03:53 ZeekHuge: good thing you spent all of that time trying to get it to work Mar 18 00:04:10 so basically what remoteproc basically does is , it provides APIs for operations like booting up, shutting down and loading the firmware onto the PRUs Mar 18 00:04:20 Yep! Mar 18 00:04:39 it is for coprocessors not just PRU Mar 18 00:04:50 while virtio_rpmsg is what is used to communicate with the PRUs while they are operative. Mar 18 00:04:56 yes, the M3 is treated the same way Mar 18 00:04:58 m_w, yes :) Mar 18 00:05:01 https://www.kernel.org/doc/Documentation/remoteproc.txt Mar 18 00:05:10 already read it :) Mar 18 00:05:23 ZeekHuge: yes but rpmsg has issues, IMO... if you can get it to work at the data rate great. but suspect the overhead is going to kill things Mar 18 00:05:43 ut oh Mar 18 00:06:05 What option do we have then ? pru1 writting on the reserved location ? Mar 18 00:06:10 *writing Mar 18 00:06:17 on the main RAM ? Mar 18 00:06:38 sure, pru can write to sram or dram then generate an interrupt. the ARM side can read ram on interrupt Mar 18 00:06:45 that's essentially the backend of rpmsg Mar 18 00:06:58 problem is rpmsg wants to do small chunks in a network like fashion which adds overhead Mar 18 00:07:14 it has stuff like name service and link addresses to deal with Mar 18 00:07:24 too much trashing Mar 18 00:07:32 it would be nice if you could do it all on 1 PRU but a pair is I guess tolerable Mar 18 00:07:41 I'd personally try it on 1 PRU Mar 18 00:07:52 but virtio_rpmsg_bus seems to work differently ? (not sure) Mar 18 00:07:57 Notes: PRUSS is the entire subsystem; PRU is the cores on the PRUSS Mar 18 00:08:09 look at the code for rpmsg Mar 18 00:08:21 it uses a mailbox as a helper (that's another HW block) Mar 18 00:08:45 virtio_rpmsg_bus exposes the device as a virtual PCI device i guess.. Mar 18 00:12:10 not sure though ... please correct me Mar 18 00:12:28 that was according to what I read .. Mar 18 00:15:08 read about virtio Mar 18 00:34:44 donno the answer to that off hand Mar 18 00:34:57 I just had to use it; was more focused on the PRU end Mar 18 00:35:04 https://github.com/shubhi1407/PRU-framework/wiki Mar 18 00:35:15 this wiki suggests so ^^ Mar 18 00:35:24 can you now go onto the link ds2 ? Mar 18 00:35:44 or should i copy-paste the relevant paras ? Mar 18 00:36:48 virtio provides different/specific driver interfaces Mar 18 00:37:04 virtual block device for storage Mar 18 00:37:18 virtual ethernet interfaces, etc Mar 18 00:38:37 it's a "transparent" interface to the underlying storage mechanism Mar 18 00:39:08 *in the case of virtio storage, the backend can be several things Mar 18 00:39:28 like an lvm volume, etc Mar 18 00:39:41 ohk so virtio is different from rpmsg ? and thus do not have issues that rpmsg has .. Mar 18 00:39:43 right ? Mar 18 00:39:50 and that can be used ? Mar 18 00:40:14 well, virtio is ofc different from rpmsg. Mar 18 00:40:23 it's a way to make a virtual interface that hides the real backend Mar 18 00:41:13 ohk......... Mar 18 00:44:53 yeah, the wiki seems stuff good Mar 18 00:45:08 that's what you want Mar 18 00:45:27 so this virtio_rpmsg_bus can be used to communicate seamlessly, isnt it ? Mar 18 00:46:26 read those virtio references Mar 18 00:48:04 "For the PRU, instead of going for rpmsg, the underlying vring has been used for this project" Mar 18 00:48:20 key sentence ^^ Mar 18 00:48:42 that should be your approach Mar 18 00:49:34 * nerdboy 's best ass-guess anyway... Mar 18 00:50:54 for yashoza it would be virtio_camera and trigger mavlink message Mar 18 00:52:50 sorry, I am buried in stuff for now Mar 18 00:55:52 nerdboy, I am bit confused here .. Mar 18 00:55:55 https://github.com/shubhi1407/PRU-framework/wiki/Remoteproc-page-2 Mar 18 00:56:31 the second para says about virtio_rpmsg_bus, and this is what i am talking about .. Mar 18 00:56:57 and while i was trying to get the pruss_remoteproc working .. Mar 18 00:57:16 I had to modprobe the "virtio_rpmsg_bus" Mar 18 00:57:35 so, isnt it that facilitating the communication ? Mar 18 00:58:16 yup Mar 18 00:59:04 ohk .. so this is the approach that we can follow .. isnt it ds2 ? Mar 18 00:59:34 instead of going through rpmsg ? Mar 18 00:59:35 "virtio_rpmsg_bus" is part of it, yes **** ENDING LOGGING AT Fri Mar 18 02:59:58 2016