**** BEGIN LOGGING AT Wed Mar 09 02:59:58 2016
Mar 09 03:24:30 <nerdboy> i noticed at least one ping sensor with analog voltage output
Mar 09 03:25:02 <nerdboy> so you can directly measure the timing between pulse and return signals
Mar 09 03:26:27 <nerdboy> making it easy-ish to calculate wind components *if* there's enough variation in the timing measurements
Mar 09 03:27:31 <m_w> so the analog value is proportional to the distance?
Mar 09 03:28:18 <nerdboy> the distance is calculated from the timing and air properties
Mar 09 03:28:36 <nerdboy> sometimes compensated for temperature
Mar 09 03:31:43 <nerdboy> "effiective" speed of sound in air is linear function of T
Mar 09 03:32:56 <nerdboy> *dry air
Mar 09 03:33:32 <m_w> cool
Mar 09 03:33:40 <nerdboy> can do better if you include moisture/density with temp
Mar 09 03:34:55 <nerdboy> you would need at least an internal temp sensor to calculate winds on-the-fly
Mar 09 03:35:37 <nerdboy> humidity even better
Mar 09 03:36:16 <m_w> http://la3za.blogspot.no/2014/05/temperature-compensation-for-arduino.html
Mar 09 03:36:23 <nerdboy> one pru to do dry air approximation and one to do the density curve?
Mar 09 03:40:21 <m_w> maybe
Mar 09 03:46:57 <m_w> SHT3x maybe
Mar 09 03:47:09 <m_w> https://www.sensirion.com/products/digital-humidity-sensors-for-reliable-measurements/digital-humidity-sensors-for-various-applications/
Mar 09 13:10:09 <rimerio> Hello, everyone. I am new to the BeagleBoard community, so I've got some questions considering GSoC. On the ideas' page there is a paragraph about heterogeneous co-processor support in open source operating systems and libraries, which includes msp430. What can be done there? I have quite a good experience of msp430 development, so I think there is something I could do.
Mar 09 13:37:52 <angel_patel> Heyy !! I am intrested in a few projects that are available for GSoC applicants.  Can you please guide me forward to it.. ?
Mar 09 15:39:34 <chanakya_vc> alexhiam, I read that to load a module the Kmod daemon has to basically run and then initiate modprobe.So I am unable to understand how will The DTO ,once loaded,call the Kmod daemon?
Mar 09 15:41:20 <chanakya_vc> Or in other words I am unable to understand what triggers the Kmod daemon to initiate modprobe on loading the required DTO?
Mar 09 15:41:57 <chanakya_vc> Can any of the mentors please help me.
Mar 09 15:42:03 <pmezydlo> bradfa: hi, schematic and layout is ready.
Mar 09 15:44:27 <pmezydlo> bradfa:do you have time, i have a few questions?
Mar 09 15:44:55 <Sonal> yes
Mar 09 15:47:17 <bradfa> pmezydlo: sorry, this morning is crazy busy for me, can you please ping me this afternoon around 2pm?  I will have some down-time then waiting for builds to occur.
Mar 09 15:47:30 <bradfa> pmezydlo: sorry, 2pm is a horrible way to describe the time :)
Mar 09 15:47:41 <bradfa> pmezydlo: in 3 hours 15 minutes from now, it's 2pm for me :)
Mar 09 15:48:32 <pmezydlo> bradfa: ok thanks, see you later
Mar 09 16:00:23 <pmezydlo> dear mentors, one of the requirements is to give the address on elinux.org, Can I create this page?
Mar 09 16:01:41 <chanakya_vc>  alexhiam, I read that to load a module the Kmod daemon has to basically run and then initiate modprobe.So I am unable to understand how will The DTO ,once loaded,call the Kmod daemon? What triggers the Kmod daemon to initiate modprobe
Mar 09 16:02:01 <chanakya_vc> alexhiam, On loading the DTO?
Mar 09 16:12:28 <alexhiam> chanakya_vc: https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/BB-BEAGLELOGIC-00A0.dts#L204
Mar 09 16:17:26 <chanakya_vc> alexhiam, Okay will check that out.Thanks.
Mar 09 16:31:22 <alexhiam> pmezydlo: where's that?
Mar 09 16:35:36 <pmezydlo> https://summerofcode.withgoogle.com/organizations/4817552005922816/  section  "about you"
Mar 09 16:36:46 <alexhiam> pmezydlo: oh, that's just your elinux username, if you have one
Mar 09 16:37:13 <alexhiam> accepted students need an account on there to create their project pages
Mar 09 16:37:24 <alexhiam> but it doesn't need to be setup now
Mar 09 16:37:44 <pmezydlo> ok, thanks
Mar 09 16:39:10 <chanakya_vc> alexhiam, The DTO for Beaglelogic (the link that you shared) is basically a modified version of the original DTO for rproc driver right?
Mar 09 16:39:37 <karki_> chanakya_vc : yes
Mar 09 16:40:17 <karki_> well that depends - if you mean panto's, then yes
Mar 09 16:40:44 <chanakya_vc> alexhiam,karki_, And it basically calls the driver in the line where it basically says pru-beaglelogic enable?
Mar 09 16:41:24 <kiran4399_> alexhiam: does the beaglebone blue has any free gpio pins? Can you please provide me an image how it looks??
Mar 09 16:41:53 <kiran4399_> alexhiam: and btw.. to what all pins are the sensors connected?
Mar 09 16:42:30 <alexhiam> kiran4399_: AFAIK it's the same as the Strawson robotics cape, so you can check out the schematics for that
Mar 09 16:44:12 <kiran4399_> alexhiam: and can I be using mmap while writing the device drivers for bb blue?
Mar 09 16:45:26 <alexhiam> what do you mean?
Mar 09 16:45:41 <chanakya_vc> alexhiam, karki_ So I would assume that when you mean write the driver as an extension to rproc,it would amount to  just calling the extension driver in the modified DTO(same as in case Beaglelogic)
Mar 09 16:46:20 <karki_> well, you have to write the driver as well.
Mar 09 16:47:24 <karki_> I'm don't know the context. Just joined the discussion now. alexhiam -- are you helping him out?
Mar 09 16:47:33 <karki_> *I
Mar 09 16:47:36 <kiran4399_> alexhiam: well, I think we have to map the device to the physical address of the bb blue right?
Mar 09 16:47:59 <chanakya_vc> And this would initiate kmod daemon to modprobe for the required driver(which i would write :) ). And then when it looks for dependencies(in modules.dep) and load remoteproc as well
Mar 09 16:48:43 <alexhiam> chanakya_vc: I think that sounds about right
Mar 09 16:49:26 <alexhiam> kiran4399_: not sure what you mean... All the subsystem drivers are there, so you wouldn't actually be reading/writing any registers
Mar 09 16:49:38 <chanakya_vc> alexhiam, karki_  Got it .Thanks!
Mar 09 16:50:38 <kiran4399_> alexhiam: But what about the external devices like mpu9250, the baro sensor??
Mar 09 16:53:40 <alexhiam> kiran4399_: you'd be interfacing with those over I2C (or SPI maybe for the baro, not sure), like the MPU-9150 driver does
Mar 09 16:55:29 <alexhiam> mmap shouldn't be used in userspace at all for reading/writing the AM3358's registers, which is what it does in the Strawson API and is why part of this project is writing the drivers
Mar 09 16:59:21 <Abhishek_> @all mentors: Please join #beagle-mentors for the meeting.
Mar 09 17:01:36 <jkridner> Switching off phone soon
Mar 09 17:02:24 <ds2> hmmm
Mar 09 17:02:30 <jkridner> Anybody here?
Mar 09 17:02:40 <alexhiam> howdy
Mar 09 17:02:40 <ds2> me0w
Mar 09 17:02:45 <anujdeshpande> hola
Mar 09 17:02:50 <henrix_> Hi, my name is Henrik Langer and I've created the software drivers for the multichannel audio system (CTAG face2|4) which is listed under project ideas for GSoC this year. I'm very interested in extending the driver architecture to the BeagleBoard X15. Due to my experiences with the soundcard and ASoC I think I have good chances to successfully port the soundcard drivers to the AM5728 SoC. I've got still some questions about the
Mar 09 17:02:57 <henrix_> What exactly should the library do? Should it be in user space to simplify the usage of the DSPs?
Mar 09 17:03:02 <jkridner> Great!
Mar 09 17:03:14 <Abhishek_> hi
Mar 09 17:03:51 <jkridner> Can we not use the OpenCL stuff at the kernel level?
Mar 09 17:04:18 <Abhishek_> I'm not sure, I did think about a OpenCL GSoC project this year though.
Mar 09 17:04:43 <ds2> you cannot use OpenCL in the kernel, IIRC
Mar 09 17:04:46 <Abhishek_> ... that there should be some project on OpenCL for the X15 but what it should be, I'm still open to that
Mar 09 17:05:19 <ds2> I'd much rather see OpenGLES 2 used instead of OpenCL just so the older siblings can take advantage
Mar 09 17:06:53 <jkridner|work> but OpenGLES doesn't provide the degree of programming as OpenCL, does it?
Mar 09 17:06:59 <jkridner__> would OpenGLES enable use at the kernel level?
Mar 09 17:07:33 * jkridner_ is missing scrollback buffer for the first of the meeting today...
Mar 09 17:07:40 <ds2> GLES is more limited for GPGPU apps
Mar 09 17:07:41 <jkridner_> let me try to call us to order by finding out who is around.
Mar 09 17:07:53 <ds2> none of them allow for direct kernel use. HW isn't open
Mar 09 17:08:03 <jkridner_> I have multiple people contact to excuse themselves from today, but will be on future meetings.
Mar 09 17:08:26 <jkridner_> well, we have a C6x gcc compiler.
Mar 09 17:08:30 <ds2> GLES also has limited data type mapping but it is what is available on a lot of devices
Mar 09 17:08:41 <jkridner_> but I don't know if OpenCL is integrated with that compiler.
Mar 09 17:09:00 <jkridner_> we also have a (less tested) gcc for PRU.
Mar 09 17:10:48 <_av500_> hi there, mentors and admins please join #beagle-mentors
Mar 09 17:11:15 <ds2> oh CL against the DSPs
Mar 09 17:11:20 <ds2> thought you meant CL against the SGX
Mar 09 17:11:21 <ds2> blah
Mar 09 17:11:45 <kiran4399_> alexhiam: I just have a basic question..
Mar 09 17:12:08 <kiran4399_> alexhiam: we are writing the driver in the kernel for a specific device..
Mar 09 17:12:40 <kiran4399_> alexhiam: actually.. we just write the device driver without keeping in mind the architecture, the memory map and so on..
Mar 09 17:13:29 <kiran4399_> alexhiam: But how does the kernel know how to use that device keeping in mind the specific architecture? In this case am335x..
Mar 09 17:14:48 * Abhishek_ 's interning at Google, Mountain View as a Hardware Engineer this summer.
Mar 09 17:16:18 <alexhiam> kiran4399_: there's an I2C driver already loaded that does read/write the subsystem registers
Mar 09 17:18:09 <kiran4399_> alexhiam: ok.. got it..
Mar 09 17:19:14 <_av500_> whois rdone
Mar 09 17:27:18 <henrix_> Can anybody give me some information what exactly the DSP library for the BB-X15 DSPs should do (project: Improving_the_BeagleBone_low-latency_multi-channel_audio_system)? I'm very interested in that project.
Mar 09 17:27:35 <jkridner_> henrix_: that's really up to you.
Mar 09 17:27:56 <jkridner_> _av500_: what was some of the thoughts around it?
Mar 09 17:29:11 <_av500_> henrix_: are you on the mailing list?
Mar 09 17:29:26 <_av500_> Robert who wants to mentor around the cape is not here today
Mar 09 17:29:33 <_av500_> but I want something to point him to
Mar 09 17:29:40 <_av500_> so please make a post if you didnt already
Mar 09 17:29:52 <_av500_> please mention the IRC nick
Mar 09 17:31:05 <henrix_> _av500_: ok, thanks.
Mar 09 19:30:43 <ZeekHuge> m_w, !
Mar 09 19:30:45 <ZeekHuge> m_w, !
Mar 09 19:30:50 <ZeekHuge> m_w,
Mar 09 19:30:58 <ZeekHuge> I got the PRUs working !
Mar 09 19:31:00 <ZeekHuge> haha!
Mar 09 19:31:03 <ZeekHuge> m_w, !!
Mar 09 19:31:11 <ZeekHuge> you there ?
Mar 09 19:31:17 <ZeekHuge> m_w, !!1
Mar 09 19:31:27 <ZeekHuge> :)
Mar 09 19:31:30 <ZeekHuge> :D
Mar 09 19:32:52 <ZeekHuge> using pruss_remoteproc on 4.1.x
Mar 09 19:32:59 <ZeekHuge> :)
Mar 09 19:34:58 <Abhishek_> care to post a patch?
Mar 09 19:37:18 <ZeekHuge> Sure ! I am just trying to get a blinky using PRUs ! And I'll then document and push it up :)
Mar 09 19:48:32 <chanakya_vc> alexhiam, Just wanted to ask that the apart from loading the firmware and driver,the information regarding which output/input pins would behave as MOSI,MISO,SCLK,CS(in SPI for example) would also go into the DTO right?
Mar 09 19:52:52 <chanakya_vc> alexhiam, And I am also confused regarding UART.Which one of RS232-C,RS-422 or485 would we use?And the voltage levels seems to be absurd -5v AND 12v
Mar 09 19:56:18 <pmezydlo> bradfa:hi, I'm already, do you have time?
Mar 09 20:05:58 <pmezydlo> chanakya_vc: i have few code for pru on my github: https://github.com/pmezydlo/BBB_PRUSSv2_SM
Mar 09 20:14:36 <chanakya_vc> pmezydlo, Thanks.Will check them out.Which project are you working on?
Mar 09 20:18:22 <bradfa> pmezydlo: sorry, even more crazy stuff going on this afternoon, it didn't quiet down like I had hoped.  Can you email to the list and I'll try to take a look at it as soon as I can.
Mar 09 20:23:05 <pmezydlo> bradfa: ok I will try to write a letter of questions?
Mar 09 20:23:49 <bradfa> pmezydlo: yes, please
Mar 09 20:24:05 <pmezydlo> chanakya_vc: i deal with nor flash emulator.
Mar 09 20:24:08 <bradfa> pmezydlo: sorry that I'm not able to help much real-time today :(
Mar 09 20:24:59 <bradfa> pmezydlo: I'm in the midst of trying to get an internal release out within the next hour and troubleshoot a few other work issues currently, which has to take priority right now, sorry
Mar 09 20:30:44 <pmezydlo> bradfa: its ok, dont worry, tomorrow is another day ;)
Mar 09 20:32:11 <chanakya_vc> pmezydlo, Ohh. Dont have much idea about that project.
Mar 09 20:56:30 <m_w> sorry
Mar 09 20:56:49 <m_w> I was out for lunch
Mar 09 20:57:32 <m_w> ZeekHuge: You got it to work?
Mar 09 20:57:46 <ZeekHuge> Hey ! m_w
Mar 09 20:57:53 <ZeekHuge> Yes ! :) :) :) :D
Mar 09 20:58:03 <m_w> Awesome
Mar 09 20:58:06 <ZeekHuge> trying blinky on it !
Mar 09 20:58:11 <m_w> what was the problem?
Mar 09 20:58:18 <ZeekHuge> just getting confused with dt things
Mar 09 20:58:46 <m_w> well progress is great
Mar 09 20:59:10 <ZeekHuge> ahh, I don't know exactly. But it was something with virtio_rpmsg_bus module. Also the firmwares are buggy
Mar 09 20:59:40 <ZeekHuge> plus, the header files, we added that day, they were wrong
Mar 09 20:59:54 <m_w> oooops
Mar 09 21:00:15 <m_w> you post the changes to your github fork?
Mar 09 21:00:33 <m_w> I would like to check out what you have done so far
Mar 09 21:00:57 <ZeekHuge> also, the header files I cloned from that "testpru", wont work.
Mar 09 21:01:36 <ZeekHuge> Not yet, I wish to get the blinky first and then push it up.
Mar 09 21:01:44 <m_w> awesome
Mar 09 21:02:13 <ZeekHuge> Also, what should i do with virtio_rpmsg_bus ? I just recompiled it in my case.
Mar 09 21:02:30 <m_w> not sure on that one
Mar 09 21:02:51 <m_w> do you have to patch it first?
Mar 09 21:03:24 <ZeekHuge> no, I jsut got the source and compiled that module only.
Mar 09 21:03:46 <m_w> okay then just explain in the README doc
Mar 09 21:04:00 <ZeekHuge> earlier i compiled the kernel with rpmsg_pru support, but then learned that it wont help.
Mar 09 21:04:03 <ZeekHuge> Okay.
Mar 09 21:04:55 <m_w> you going to try doing the PRU offload thing?
Mar 09 21:04:57 <ZeekHuge> As soon as i get the blinky, I'll see if i am able to access the SPI through PRUs.
Mar 09 21:05:04 <ZeekHuge> Sure !
Mar 09 21:05:34 <ZeekHuge> the one on mentioned on that g+ link ? right ?
Mar 09 21:05:59 <m_w> yes, Jonathan post another couple of comments too
Mar 09 21:06:27 <m_w> there is a example from a book that does something similar to what we are trying to accomplish
Mar 09 21:06:57 <pmezydlo> m_w: do you want to see layout?
Mar 09 21:07:15 <m_w> pmezydlo: sure
Mar 09 21:08:08 <ZeekHuge> Okay, so how about the proposal for that project ? Is it up in the ideas page ?
Mar 09 21:08:13 <m_w> if all else fails we can just use bitbanging on the SPI but then make a more generic platform
Mar 09 21:08:48 <pmezydlo> m_w: bottom: https://drive.google.com/file/d/0B1Sxahs4DCgrVEFUVEFsRE9tZ2s/view?usp=sharing
Mar 09 21:08:54 <m_w> it actually covers parts of a few of the proposals
Mar 09 21:09:25 <pmezydlo> m_w: top https://drive.google.com/file/d/0B1Sxahs4DCgrMTJVMGhKalJKU2c/view?usp=sharing
Mar 09 21:10:55 <m_w> are there traces on the bottom layer?
Mar 09 21:11:07 <m_w> sorry
Mar 09 21:11:21 <ZeekHuge> ahh, will it be made a different project ?
Mar 09 21:11:21 <m_w> I need to read first ask question later.:)
Mar 09 21:11:51 <m_w> they proposal are just project ideas
Mar 09 21:12:43 <ZeekHuge> Ohk, so it in not a compulsion to have the project on the ideas page ?
Mar 09 21:13:00 <pmezydlo> what do you mean by traces?
Mar 09 21:14:59 <m_w> ZeekHuge: it is not required to be
Mar 09 21:15:23 <m_w> pmezydlo: ignore that comment I didn't see the second link
Mar 09 21:16:26 <pmezydlo> what do you think about it?
Mar 09 21:16:42 <m_w> it looks okay
Mar 09 21:17:11 <ZeekHuge> ohk Cool ! Can you please give share the link ? to that book you mentioned earlier ?
Mar 09 21:17:27 <m_w> the silkscreen needs to be adjusted a bit
Mar 09 21:17:33 <m_w> ZeekHuge: sure
Mar 09 21:18:57 <m_w> http://exploringbeaglebone.com/chapter13/
Mar 09 21:19:50 <m_w> R2 silk is covered by the header above
Mar 09 21:21:02 <m_w> U$3 U$5 U$2 and U$4 silkscreen is over the component pads slightly
Mar 09 21:21:42 <m_w> and the probably should be U3, U5, U2, and U4 without the $ in the middle
Mar 09 21:22:23 <ZeekHuge> Will surely go through it. Btw, what we are trying to do is allow PRU to get data from SPI and I2C buses . right ? as this would allow it to interact with IIO based devices ?
Mar 09 21:23:35 <m_w> it will allow access to devices that are typically connected to with IIO subsystem drivers
Mar 09 21:24:27 <m_w> but it would need an IIO driver on top if we want the same interfaces
Mar 09 21:25:10 <pmezydlo> m_w:I always remove subtitles because It does not look good.
Mar 09 21:25:48 <pmezydlo> m_w but i  I can correct it?
Mar 09 21:25:55 <ZeekHuge> Ohk so we are removing the limitations that come with IIO driver under linux ?
Mar 09 21:26:51 <ZeekHuge> offloading the interaction part with those devices to the PRUs ?
Mar 09 21:27:08 <m_w> ZeekHuge: bingo
Mar 09 21:27:35 <m_w> pmezydlo: subtitles?
Mar 09 21:27:49 <ZeekHuge> So, if we are able to access SPI and I2C that will help us lot ! Remove a lot of bitbanging overhead . right ?
Mar 09 21:28:13 <ZeekHuge> And ofc leaving more space for the firmware on PRU
Mar 09 21:29:36 <m_w> I am not sure about that
Mar 09 21:29:53 <ZeekHuge> yeah, but that is the idea, isnt it ?
Mar 09 21:30:11 <m_w> it was but ideas evolve with experimentation
Mar 09 21:30:29 <m_w> see what is possible first
Mar 09 21:30:42 <ZeekHuge> Ohk, I'll report about the SPI thing as soon as i can.
Mar 09 21:31:03 <ZeekHuge> And if it works ! It will be Eureka moment ! :) :) :D
Mar 09 21:31:09 <m_w> great
Mar 09 21:31:24 * ZeekHuge was literally dancing when he got PRUs working !
Mar 09 21:31:46 <m_w> good stuff
Mar 09 21:33:05 <pmezydlo> m_w: labels for exmaple: R2, U$2
Mar 09 21:35:15 <m_w> pmezydlo: silkscreen should always clearly designate the components as labelled in the schematic
Mar 09 21:36:38 <m_w> the silk should never overlap pads but must board houses will correct this automatically
Mar 09 21:37:08 <m_w> which PCB fab house are you going to use?
Mar 09 21:38:07 <pmezydlo> m_w: no, I want to order it at the factory.
Mar 09 21:38:29 <m_w> which factory?
Mar 09 21:41:07 <m_w> each one will have different design limitations at cost levels
Mar 09 21:41:28 <m_w> specifically track width and spacing
Mar 09 21:41:46 <pmezydlo> m_w: pcb factory. You send your pcb project and return the pcb
Mar 09 21:42:01 <m_w> what width traces are you using?
Mar 09 21:43:50 <m_w> and via size?
Mar 09 21:45:12 <chanakya_vc> m_w, when you say access SPI on the PRU without bitbanging ,what does that exactly mean?
Mar 09 21:45:50 <chanakya_vc> m_w, Could you please explain a bit as to what you and ZeekHuge are trying?
Mar 09 21:46:23 <pmezydlo> traces width is:  0.6mm
Mar 09 21:46:32 <m_w> well, we are trying to access the internal SPI controller from the PRU
Mar 09 21:48:02 <chanakya_vc> m_w, But the internal SPI controller would only talk to SPI adapter right?
Mar 09 21:48:52 <m_w> yes but then the main processor would not have to deal with it
Mar 09 21:48:58 <pmezydlo> m_w: via diameter is 1mm and drill is 1,9mm
Mar 09 21:51:48 <m_w> I am used to mils
Mar 09 21:51:48 <chanakya_vc> m_w, Okay so put the data you get from an SPI device onto the shared memory and let PRU access it maybe?
Mar 09 21:52:19 <m_w> chanakya_vc: essentially
Mar 09 21:53:10 <chanakya_vc> m_w, Essentially doing the opposite of what I am trying :)
Mar 09 21:56:08 <m_w> sure
Mar 09 21:56:32 <m_w> we are set in stone quite yet though
Mar 09 21:56:38 <m_w> we are not
Mar 09 21:56:46 <chanakya_vc> m_w, But wouldn't the PRU present handicap in processing the data one might get from an SPI device?
Mar 09 21:57:04 <chanakya_vc> *a
Mar 09 21:57:27 <m_w> not sure
Mar 09 21:58:20 <chanakya_vc> m_w, Ohh.But seems to be a great idea!
Mar 09 21:59:11 <m_w> the example from the textbook link above is handling data from an ADC with the PRU
Mar 09 21:59:33 <m_w> and it is using bitbanging for SPI
Mar 09 21:59:55 <m_w> so that may be useful in your efforts
Mar 09 22:01:10 <m_w> we might use bitbanging as well but we would encapsulate the protocol into the PRU
Mar 09 22:02:25 <m_w> https://plus.google.com/+MichaelWelling79/posts/inp2PYdpPQg
Mar 09 22:02:39 <m_w> read through the G+ post for more information
Mar 09 22:02:56 <m_w> I think the FPGA offloading is pretty cool
Mar 09 22:05:13 <chanakya_vc> m_w, Okay will do that. I don't have much experience with FPGA'S.But controlling FPGA's with PRU's would be a difficult task i presume?
Mar 09 22:05:44 <m_w> it would be interesting
Mar 09 22:05:52 <yashoza> m_w : yes..i have gone through this link..do u think we could use the same idea for other applications ?
Mar 09 22:06:14 <m_w> FPGA are typically memory mapped
Mar 09 22:06:25 <yashoza> like for example the project for stereo imaging ?
Mar 09 22:06:42 <m_w> yashoza: the ideas are there for everyone
Mar 09 22:07:05 <m_w> sounds good to me
Mar 09 22:07:38 <m_w> what kind of image sensors do you have?
Mar 09 22:07:51 <yashoza> yep..because a big constraint in that project is the limited memory we have to transfer the data from the pru
Mar 09 22:08:06 <yashoza> so this would be a brilliant way to solve the problem :D
Mar 09 22:08:45 <yashoza> i actually have only 1 cmos camera :(
Mar 09 22:09:49 <m_w> what interface does the camera use?
Mar 09 22:11:10 <yashoza> i2c interface
Mar 09 22:12:14 <pmezydlo> m_w:improved layout, labels and dimensions in mil presents for you tomorrow :)
Mar 09 22:12:57 <m_w> pmezydlo: great
Mar 09 22:13:29 <yashoza> i use the i2c interface to configure the camera..the pixel data can be read from the i/o ports using spi
Mar 09 22:14:35 <m_w> yashoza: is the really PRU required for accessing the camera?
Mar 09 22:16:05 <yashoza> hm..we dont use the pru to access the camera, we use it to get the depth map of the image
Mar 09 22:16:18 <yashoza> the image is obtained via the usb port only
Mar 09 22:16:28 <m_w> ah
Mar 09 22:16:46 <yashoza> the depth map is obtained and the cpu is free'd up from that overload
Mar 09 22:17:07 <yashoza> and the depth map is then transferred back
Mar 09 22:17:16 <m_w> okay
Mar 09 22:18:33 <yashoza> yep..
Mar 09 22:18:51 <m_w> so the map is stored in shared memory
Mar 09 22:18:59 <m_w> but you dont have enough
Mar 09 22:19:06 <yashoza> yessssss
Mar 09 22:19:25 <m_w> what is required to compute the depth map?
Mar 09 22:20:18 <yashoza> i dont think i understand the ques
Mar 09 22:20:32 <yashoza> we'd use the image data that we capture via the usb
Mar 09 22:21:04 <m_w> and compute a map from two sensors right?
Mar 09 22:21:31 <yashoza> yes
Mar 09 22:23:17 <m_w> can the image be subdivided?
Mar 09 22:23:42 <m_w> performing the computation in chunks?
Mar 09 22:24:40 <yashoza> yes..that is one way i think we could do it
Mar 09 22:25:00 <yashoza> some resources online point out that the image has to be divided into 4 chunks
Mar 09 22:25:15 <yashoza> and then the data can be passes one after the other
Mar 09 22:25:39 <yashoza> *passed
Mar 09 22:26:14 <m_w> block matching?
Mar 09 22:26:16 <m_w> https://en.wikipedia.org/wiki/Block-matching_algorithm
Mar 09 22:29:09 <yashoza> okayy
Mar 09 22:29:31 <yashoza> yes..this looks good and i think it czn be implemented
Mar 09 22:29:35 <yashoza> *can
Mar 09 22:29:57 <yashoza> but the data will still have to be transferred some n number of times
Mar 09 22:30:11 <yashoza> which i think will still take the same amount of time
Mar 09 22:31:53 <m_w> okay let us know how it works out
Mar 09 22:32:07 <yashoza> okay, sure :)
Mar 09 22:33:09 <yashoza> i actually wanted to do some work before the application process started
Mar 09 22:33:27 <yashoza> Is there anything anything you can suggest ?
Mar 09 22:36:25 <m_w> to what extent?
Mar 09 22:39:50 <yashoza> to get started with the project
Mar 09 22:40:04 <yashoza> just to start with something basic
Mar 09 22:40:33 <m_w> is the project on the gsoc ideas page?
Mar 09 22:41:20 <yashoza> yes
Mar 09 22:41:36 <m_w> "Process Sensor Data in Real-Time"?
Mar 09 22:41:58 <yashoza> @Port/implement MAV (drone) optical flow or stereo image processing to PRUs, use "Blue" or Black (via BBIO cape) as Ardupilot platform."
Mar 09 22:42:00 <yashoza> yess
Mar 09 22:42:36 <m_w> okay
Mar 09 22:43:57 <m_w> go though the PRU examples and tutorial to get a better understanding of how it works
Mar 09 22:44:08 <m_w> have you done anything with the PRU before?
Mar 09 22:44:51 <yashoza> nope
Mar 09 22:45:05 <yashoza> but i got it running just sometime back
Mar 09 22:46:33 <m_w> then try to use the PRU to perform a simple operation on a block of data
Mar 09 22:46:53 <yashoza> yep
Mar 09 22:46:54 <m_w> you have any opencv experience?
Mar 09 22:46:56 <yashoza> alright!
Mar 09 22:48:17 <yashoza> oh yes
Mar 09 22:48:29 <yashoza> i have used opencv before
Mar 09 22:48:54 <m_w> on the beaglebone?
Mar 09 22:49:11 <yashoza> yes, on the bbb
Mar 09 22:50:13 <m_w> okay
Mar 09 22:51:31 <m_w> have you tried the conventional stereo image processing with BBB?
Mar 09 22:51:58 <yashoza> No..i haven't been able to do it
Mar 09 22:52:09 <yashoza> I am still waiting for my second camera
Mar 09 22:52:40 <m_w> try to get that working as baseline
Mar 09 22:54:56 <yashoza> hmm..okayy
Mar 09 22:55:24 <m_w> have you seen this?
Mar 09 22:55:26 <m_w> http://derekmolloy.ie/beaglebone/beaglebone-video-capture-and-image-processing-on-embedded-linux-using-opencv/
Mar 09 22:56:58 <yashoza> yes..i have
Mar 09 22:57:20 <yashoza> it was very helpful in getting opencv up and running
Mar 09 22:57:23 <yashoza> and build on it
Mar 09 22:57:30 <m_w> ah
Mar 09 22:59:55 <m_w> okay experiment with sending and receiving data to/from the PRU
Mar 09 23:00:09 <yashoza> yes..ill do that and get back!
Mar 09 23:00:13 <yashoza> thanks !
Mar 09 23:00:22 <m_w> no problem
**** ENDING LOGGING AT Thu Mar 10 02:59:58 2016