**** BEGIN LOGGING AT Sun Mar 13 02:59:58 2016 Mar 13 15:08:57 hi i am new to beaglebone community.previously i have worked on arduino uno and worked on some projects.I am interested to learn about beaglebone and learn to contribute to GSOC 2016.I am novice help needed to on links to study Mar 13 15:11:58 what prerequisites do I need to study in detail beaglebone so as be competant to able to understand more ideas descriptions of GSOC 2016. Mar 13 15:12:00 ? Mar 13 15:23:01 hi Mar 13 15:27:26 anyone from beaglebone community know where to study more materials on beaglebone and help needed to learn more about gsoc idea-"Heterogeneous co-processor support in open source operating systems and libraries" Mar 13 15:33:13 Hello vikram01 Mar 13 15:33:18 Please have a look Mar 13 15:33:20 http://beagleboard.org/support/bone101 Mar 13 15:36:09 Also try the following: Mar 13 15:36:11 http://makezine.com/projects/make-32/get-started-with-beaglebone/ Mar 13 15:36:30 https://www.linux.com/learn/tutorials/725368-getting-started-with-the-beaglebone-black-a-1ghz-arm-linux-machine-for-45 Mar 13 15:36:50 http://www.tested.com/art/makers/459278-everything-you-need-know-about-beaglebone-black/ Mar 13 15:37:49 When you are ready to start making projects and are familiar with the development environment, please go through this as well: Mar 13 15:37:50 https://github.com/graycatlabs/PyBBIO/wiki Mar 13 16:49:01 alexhiam, ds2,Just had an idea.I was looking into implementation of I2C driver and it turns out that the parametres are basically written to different registers in the memory. Mar 13 16:50:16 alexhiam, ds2,So we could create the same registers in the shared memory and use the existing driver for I2C by changing its memory mapping? Mar 13 17:16:29 chanakya_vc: which existing driver? I think it makes much more sense to design something well optimized for the PRU and the shared memory rather than trying to emulate some specific I2C controller Mar 13 17:36:43 alexhiam: what is the ble and wifi which we are using in blue? Mar 13 17:36:54 alexhiam: are there drivers already in the kernel? Mar 13 17:37:19 kiran4399: not sure, but safe to assume they have drivers Mar 13 17:37:49 alexhiam: Remember victors gsoc project?? beaglepilot?? Mar 13 17:37:56 yeah Mar 13 17:38:08 alexhiam: does it use pru for esc output? Mar 13 17:39:09 alexhiam: and when you told yesterday that there are 8 pru outputs for servo... does it means that I have to implement 4 on 1 pru and 4 on another pru? Mar 13 17:39:23 alexhiam, What I meant was,that the current existing driver for I2C in linux basically writes the parameters related to I2C in registers at certain memory locations.The values in these registers would then be read by the external I2C hardware and the required paramateres are then set by it. Mar 13 17:39:46 hmm, I'm not sure, the earle-brain has 12x PWM outputs, so I guess they must be using the PRU Mar 13 17:40:00 ideally all 8 would be driver from 1 PRU so the other is still free Mar 13 17:40:13 alexhiam,So if we were to replicate these registers in the shared memory space Mar 13 17:41:23 alexhiam, We could use the existing driver for I2C in linux by simply changing the memory mapping of it.So that the parameters are written in the shared mem Mar 13 17:41:34 https://github.com/diydrones/ardupilot/tree/master/Tools/Linux_HAL_Essentials/pru/pwmpru Mar 13 17:41:43 chanakya_vc: sounds to me like you may be confusing the I2C controller with the remote device... Mar 13 17:42:37 alexhiam, Okay.I will research on it a bit more and get back to you. Mar 13 17:42:38 m_w: that link for me? Mar 13 17:42:43 yup Mar 13 17:43:01 they appear to be handling up to 12PWMs in one PRU Mar 13 17:43:05 that sure looks useful Mar 13 17:43:10 alexhiam, Did you see my mail?What do you think about the timeline? Mar 13 17:44:26 https://github.com/diydrones/ardupilot/tree/master/Tools/Linux_HAL_Essentials/pru/aiopru Mar 13 17:46:06 chanakya_vc: haven't had a chance to look at the ml much in a few days Mar 13 17:47:34 Hey ! I have some doubts about the SPI module in am335x SOC. (With reference to the technical reference manual : phytec.com/wiki/images/7/72/AM335x_techincal_reference_manual.pdf) Mar 13 17:48:30 tmi? tl;dr? Mar 13 17:49:01 mcspi with cheese? Mar 13 17:49:02 tl;dr?? it's only 4000 pages... Mar 13 17:49:11 from page 3996 table 24-3, the CLKSPIREF is told to have max 48MHz. Mar 13 17:49:36 yeah that is a controller limitation Mar 13 17:49:45 alexhiam, Ohh. Please do go through it whenever you have time.I would be basing my proposal on your inputs :) Mar 13 17:50:28 And is that the highest limit of spi_clk pin too ? Mar 13 17:50:50 alexhiam: should we make any dsm2 reciever driver for bb blue which is compatable with the ardupilot reciever-transmitter system? Mar 13 17:51:11 ZeekHuge: I think so Mar 13 17:51:34 table 24-18, page 4049 indicates so.. Mar 13 17:52:03 as does 24-8 on 4013 Mar 13 17:53:03 kiran4399: does one not exist already? Mar 13 17:53:22 alexhiam: not on the beaglebone... right?? Mar 13 17:54:25 well I assume it's just a UART thing Mar 13 17:54:31 any linux driver for it should work Mar 13 17:56:27 alexhiam: and by the way... for the standalone ros... can't we just reuse ros implementation of bb black? Mar 13 17:57:03 ZeekHuge: according to Molloy he is maxing out the bitbanging of SPI at around 1MSps on ADS7883. So ~12MHz SCLK. Mar 13 17:57:30 and if that is true, dosent that mean, we would be able to get only (48*10^6)/8 sampling rate for 8bit data ? ie. 6 MSps? Mar 13 17:57:33 kiran4399: the key would be to make sure it has interfaces to the APIs for all the hardware on the blue Mar 13 17:58:20 m_w: on the PRU? Mar 13 17:58:38 ZeekHuge: roundabouts Mar 13 17:58:43 alexhiam: yes Mar 13 17:58:48 http://exploringbeaglebone.com/chapter13 Mar 13 17:59:22 but beaglelogic uses bitbanging and it is still able to get about 100Msps Mar 13 17:59:27 https://github.com/abhishek-kakkar/BeagleLogic/wiki Mar 13 17:59:49 ZeekHuge: that's with 1 bit per sample Mar 13 18:00:15 alexhiam: has anyone developed a kernel driver for pru? Mar 13 18:00:16 using single-cycle access inputs Mar 13 18:00:32 kiran4399: huh? Mar 13 18:01:31 alexhiam, Could you guide what I should do next?Apart from the proposal and cross compilation task. Mar 13 18:02:09 ZeekHuge: sampling GPIO is not the same as sampling ADC Mar 13 18:02:29 the GPIO are latched a whole sample at a time Mar 13 18:03:19 what i am basically asking is, the IIOs are meant for high speed data acquisition. But using the onboard SPI peripheral, we would be able to get at most in any case 6 MSps, with 8bits/sample. Will that be good enough ? Mar 13 18:04:02 Though typically sampling rates higher than 100Khz are said to be "High speed data acquisition" Mar 13 18:04:09 that's waaaay better than the current adc driver for the beaglebone :P Mar 13 18:04:26 Ohk :) Mar 13 18:04:40 What do you think alexhiam ? Can that be achieved ? Mar 13 18:05:38 Though it seems that we can access SPI via PRUs with a latency of about 35-40 cycles. I am trying to test it on the target. Mar 13 18:06:53 http://processors.wiki.ti.com/index.php/AM335x_PRU_Read_Latencies Mar 13 18:07:17 table 2, McSPI0-1 Mar 13 18:07:29 ZeekHuge: do you think you'd only be able to get those rates from the PRU? Mar 13 18:08:47 the point is offloading from the main controller freeing up CPU cycles Mar 13 18:09:16 right Mar 13 18:09:43 you could probably access these highspeed devices but the main would get hammered Mar 13 18:09:53 No, Not at all. Ofc the rates will be much lower then 6 MSps. But I was just asking if a good enough rate could be achieved. Mar 13 18:10:18 remind me the project idea here? This would be continuous sampling? Mar 13 18:11:05 https://plus.google.com/+MichaelWelling79/posts/inp2PYdpPQg Mar 13 18:11:19 it is an idea from the IIO maintainer Mar 13 18:11:24 Its actually about, interfacing the IIO devices (based on SPI and I2C buses) and offloading the lower level implementation to the PRUs Mar 13 18:12:31 The transactions, and polling the device or waiting for the interrupts would be done by the PRUs. Mar 13 18:13:19 cool Mar 13 18:13:58 alexhiam, Would it be necessary to show the assembly code for PRU's for controlling LED's etc. before the application period ends.Or I could do that later? Mar 13 18:15:04 ZeekHuge: there's some overlap with chanakya_vc, so that should ideally be figured out so you're not proposing to do the same thing (and that youre projects don't depend on each other at all) Mar 13 18:16:09 chanakya_vc: would probably make for a stronger application if you can already demonstrate an understanding of PRU development Mar 13 18:17:12 is chanakya_vc's proposal posted somewhere? Mar 13 18:17:15 Hey chanakya_vc ! Is the project you will be proposing on the ideas page ? Mar 13 18:17:43 m_w, I posted on the timeline. Mar 13 18:17:52 link? Mar 13 18:17:54 ml Mar 13 18:17:59 timeline on ml Mar 13 18:18:27 https://groups.google.com/forum/#!topic/beagleboard-gsoc/9wXKTdMiT9k Mar 13 18:19:19 ZeekHuge, Yup that's the link. Mar 13 18:20:05 it is not really the same project Mar 13 18:20:28 alexhiam, we are trying to use the SPI peripheral on the SoC Mar 13 18:20:59 he is exposing bitbanged i2c/spi to the userspace at standard linux drivers Mar 13 18:21:22 gotcha. Didn't know if there was some bit-banging involved as well since you were looking at the molloy post Mar 13 18:21:49 we can still use bitbanging at first Mar 13 18:22:02 but the philosophy is different Mar 13 18:22:06 that would allow higher speed data acquisition and the PRUs would be responsible to manage the device. Mar 13 18:22:43 we are handling transactions to devices in the PRU instead of a Linux driver Mar 13 18:23:07 are we afraid that they will copy from each other? Mar 13 18:23:12 ZeekHuge, alexhiam ,m_w What I understand of your project is that you would be offloading certain tasks like polling done by the standard driver in linux to the PRU? Mar 13 18:23:32 in essence Mar 13 18:23:50 m_w: no, just wouldn't be very efficient if they both ended up writing code to bit-bang SPI and I2C on the PRU at the same time Mar 13 18:24:08 alexhiam, so do you think this project is significantly different to be a different proposal ? Mar 13 18:24:35 yeah, sounds that way Mar 13 18:24:45 phew Mar 13 18:24:54 :) Mar 13 18:25:05 this would essentially be the entire IIO device driver implemented in the PRU? Mar 13 18:25:07 That sounds great :) Mar 13 18:25:29 alexhiam: the critical sections Mar 13 18:25:30 Yes Mar 13 18:25:38 cool Mar 13 18:25:50 the parts that create overhead for the MPU Mar 13 18:25:50 we would still need an IIO driver to expose the results Mar 13 18:26:03 of course Mar 13 18:26:28 analog is doing similar with the FPGA and I would like some feedback from them Mar 13 18:26:31 alexhiam , m_w In any case I would have to write a new device driver.So I don't think that me and ZeekHuge would have any code in common? Mar 13 18:27:01 chanakya_vc: on the Linux driver side it would certainly be totally different Mar 13 18:27:10 they may have similar aspects Mar 13 18:27:36 Yes, my part on the linux side would be just to expose the data and communicate the PRUs Mar 13 18:28:56 alexhiam: has anyone developed a pru servo driver for beaglebone black? Mar 13 18:29:03 am i right m_w ? Mar 13 18:29:09 yeah Mar 13 18:29:09 ZeekHuge,m_w And even on the PRU's I don't think you would be writing entire code for bitbanging I2C. I mean you are only offloading a certain part of the protocol right? Mar 13 18:29:48 kiran4399: oh, well that was what m_w linked before Mar 13 18:30:21 this one: https://github.com/diydrones/ardupilot/tree/master/Tools/Linux_HAL_Essentials/pru/pwmpru Mar 13 18:31:35 the I2C or SPI transaction would be complete controlled by the PRU and abstracted from Linux Mar 13 18:32:12 Linux would just send or receive data to the PRU Mar 13 18:33:55 also m_w , we can use the two PRUs in such a way so as to allow good speed of data transfer, from SPI peripheral to PRUs Mar 13 18:34:28 m_w, It is essentially the opposite of what I am trying to do I guess :) Mar 13 18:34:45 it is complementary Mar 13 18:35:18 and, the SPI also have a 64 byte deep FIFO, so maybe we could read that as a block and transfer that to one of the banks. writing to the banks inside PRUSS take just one cycle. Mar 13 18:35:53 cool Mar 13 18:36:13 we really need to proof of concept the SPI controller access Mar 13 18:36:26 m_w, I guess the philosophy behind your project is to have faster data transfer with certain devices that use these protocols right? Mar 13 18:36:54 it may not be faster just less tasking on the main processor Mar 13 18:37:10 the documents by TI strongly suggest that it can be done. Table 2 in : processors.wiki.ti.com/index.php/AM335x_PRU_Read_Latencies Mar 13 18:37:47 yeah that is good Mar 13 18:37:47 they have stated the time latency for McSPI0-1 Mar 13 18:38:17 we would probably need to disable the standard SPI driver Mar 13 18:38:34 and, I will soon try to access the SPI, possibly will do that before the proposal submission deadline. Mar 13 18:38:51 and hopefully the overhead of communicating with the SPI controller is not too much to fit in the PRU Mar 13 18:39:08 yes, that would be just changing the DT and rmmod-ding the SPI driver, wont it be ? Mar 13 18:39:33 sure Mar 13 18:39:51 no, the SPI peripheral does have an interrupt that is directly inside the PRUSS-ICSS Mar 13 18:40:11 *PRU-ICSS Mar 13 18:41:05 okay well keep at it and remember to send those emails Mar 13 18:41:14 I have to go grocery shopping Mar 13 18:41:32 I haven't completely read the SPI documentation but, the interrupts are probably generated when the FIFO is almost full. Mar 13 18:41:41 Sure, I will do that tonight. Mar 13 18:41:47 Oh Mar 13 18:41:54 I will check in after I get back Mar 13 18:42:20 * ZeekHuge didn't see the time, its more then 00:00 here. Mar 13 18:49:06 alexhiam, In the standard driver for I2C in linux ,when you set the parameters for I2C like self address,clock frequency,whether we are using 7 or 10 bit addressing,what I have understood is that the driver a certain bit combination to different registers in the memory,which represent these parametres.Am I incorrect in my reasoning? Mar 13 18:49:52 chanakya_vc: that depends on the I2C controller used Mar 13 18:51:48 Okay so it is not fixed but depends upon the external hardware? Mar 13 18:53:21 How does the driver figure out to which register it is supposed to write.How does the driver get this info?Through DTO? Mar 13 18:54:34 chanakya_vc: there's the core i2c driver, then there's also a hardware specific i2c driver, e.g. the one for TI's OMAP processors: https://github.com/beagleboard/linux/blob/4.1/drivers/i2c/busses/i2c-omap.c Mar 13 18:54:40 which is what's used on the BeagleBone Mar 13 18:55:16 all the hardware specific drivers implement the same interface for the i2c driver to use Mar 13 18:56:11 so for you're project you would be implementing a HAL driver, like the i2c-omap.c one, providing that standard I@C HAL interface for the PRU bit-banging firmware Mar 13 18:56:42 same idea for SPI: https://github.com/beagleboard/linux/blob/4.1/drivers/spi/spi-omap2-mcspi.c Mar 13 18:59:10 alexhiam, So two questions: First is that if I was using I2C in linux,I would have to first get the hardware specific driver.This would then interact with the core driver or work standalone and write in registers which my controller would look to set parametres? Mar 13 19:03:18 actually I'm not sure if an I2C HAL driver like that can be compiled as a module... Mar 13 19:03:46 alexhiam, Ohh. Mar 13 19:05:16 in which case I guess I guess it would mean writing a driver that emulates the i2c-dev driver...(?) Mar 13 19:07:05 alexhiam, Okay.In essence I guess it would boil down to writing a hardware specific driver only?Only in our case the register mem locations would be fixed as the controller(PRU) would be fixed? Mar 13 19:07:45 well I'm not convinced that creating an emulated register map like that is the way to go Mar 13 19:10:14 But if we were to create a register map,we could even define and leave free registers for adding additional features later by the community. Mar 13 19:12:37 I mean there are so many parameters in I2C,many of which are not commonly used.So if someone wanted a specific functionality,all they would do is enable certain registers Mar 13 19:14:01 alexhiam, What would you suggest? Mar 13 19:20:34 isk, but I suspect going that route would lead to twice as many reads from memory on the pru, as it would get the signal from the ARM that something has changed, then would have to read from a common location to find out at what address there was a change, then go read from that address Mar 13 19:21:12 idk* Mar 13 19:51:00 can't they just use the same shm region? Mar 13 19:52:01 * nerdboy reading backwards... Mar 13 20:00:15 Okay so defining registers in shm would lead to problems with mail TI processor? Mar 13 20:01:04 *main Mar 13 20:03:51 * nerdboy thinking some kind of shared messaging interface Mar 13 20:06:22 https://lcm-proj.github.io/ <= like thi smaybe? Mar 13 20:06:41 nerdboy, That link for me? Mar 13 20:06:43 alexhiam: seen this ^^ Mar 13 20:06:46 yes Mar 13 20:11:57 sometimes you can apply stuff in unintended/novel ways... Mar 13 20:12:34 but that stuff is for real-time messaging Mar 13 20:13:03 so abuse it to your heart's content Mar 13 20:20:18 nerdboy, But how would this integrate with the driver?I mean this would pass messages between the userland and the shm right? But won't require the driver? Mar 13 20:20:34 nerdboy, Please correct me? Mar 13 20:23:39 it's a library Mar 13 20:24:14 you'd either need to use it directly or make your driver talk/listen to it Mar 13 20:25:04 "LCM is a package designed to allow multiple processes to exchange messages in a safe and high-performance way." Mar 13 20:25:59 you have arm and 2 prus so at least three things need to talk to each other Mar 13 20:26:23 * nerdboy "designing" out his ass, so... Mar 13 20:26:34 you still need to do the analysis/testing Mar 13 20:31:06 seems like that could be the "backend" interface between i2c interface and pru firmware? Mar 13 20:32:02 would abstract away the i2c stuff and just send messages back and forth Mar 13 20:33:13 maybe make a protocol map and yaml message definition Mar 13 20:33:39 I was imagining going as simple as possible, e.g. any config stuff could just be sent in single downcalls, and there could just be rx and tx circular buffers and a couple signals events to signal that data is ready Mar 13 20:35:13 ideally each PRU would be totally independent, so I don't thin a message bus in needed Mar 13 20:35:14 people work/think at different levels Mar 13 20:35:30 i.e. a single driver for a single pru Mar 13 20:35:52 * nerdboy apparently can't take off big picture architecture hat Mar 13 20:36:09 there's also the limited code size on the pru to consider Mar 13 20:36:36 message interface/firmware could be the same Mar 13 20:36:45 * alexhiam would love to see something message bus based using both PRUs though Mar 13 20:36:56 isn't that string based though? Mar 13 20:36:59 yeah, might be a little bit of an optimization problem Mar 13 20:37:24 I think string parsing on the pru would be a can or worms Mar 13 20:37:32 try the c examples and see small it is Mar 13 20:37:54 you mean I should look at it before I shoot it down?! Mar 13 20:39:30 I'm definitely bookmarking that one. But it does look to be based on the message names, right? Mar 13 20:40:09 you create your own type defs Mar 13 20:40:13 and messages Mar 13 20:40:42 I'm just looking at the subscribe routine, seems to be based on the string Mar 13 20:40:51 e.g.: `exlcm_example_t_subscribe(lcm, "EXAMPLE", &my_handler, NULL);` Mar 13 20:41:41 ohhh, that's the 'channel' Mar 13 20:41:50 it's pub/sub and pretty flexible Mar 13 20:42:10 yeah, you define types and each gets a channel i think Mar 13 20:43:41 there's also rpmsg, which TI has got working on the PRU Mar 13 20:44:09 alexhiam, What do you think?Should I look at this? Mar 13 20:44:12 is that kinda similar? Mar 13 20:45:06 it's a messaging framework designed for remote processors - not sure of the details Mar 13 20:45:44 maybe that's intended more for this kind of application Mar 13 20:46:38 at least the pru firmware side might be less overhead? Mar 13 20:47:05 or maybe not... Mar 13 20:47:22 but still not sure going the route of a full-fledged messaging framework won't just lead to unnecessary complexity and overheads Mar 13 20:47:44 though maybe it'll serve as a better example for the pru? Mar 13 20:50:18 alexhiam, Okay.Are you sure that HAL driver cannot be compiled as a module? Mar 13 20:52:14 using the ti framework is probably a good thing, unless it just sucks for this kind of project... Mar 13 20:54:09 chanakya_vc: not at all Mar 13 20:55:25 alexhiam, Okay let me search about it and get back to you. Mar 13 20:56:51 alexhiam, Meanwhile I would request you to please go through my timeline on the ml. Mar 13 20:58:19 chanakya_vc: you should start by reading through all of this: https://www.kernel.org/doc/Documentation/i2c/ Mar 13 20:58:53 looks like that HAL layer is called an "adapter driver" Mar 13 21:01:31 alexhiam, Okay will go through that. I thought I had drivers completely figured out :) Mar 13 21:05:15 we had gregkh here in 2014... Mar 13 21:05:37 he maintains Linux i2c, doesn't he? Mar 13 21:05:45 no Mar 13 21:06:10 wolfram sang does Mar 13 21:06:13 oh, used to? or am I totally making that up... Mar 13 21:08:00 he may have at one time Mar 13 21:16:47 m_w: I have the latest version of the layout. Mar 13 21:16:47 you want to see Mar 13 21:16:54 ? Mar 13 21:22:18 top layer: https://drive.google.com/file/d/0B1Sxahs4DCgrR2tNaldDekJTdE0/view?usp=sharing Mar 13 21:22:52 bottom layer: https://drive.google.com/file/d/0B1Sxahs4DCgrT2tkeEMzd3BlZzA/view?usp=sharing Mar 13 21:28:49 Hello Mar 13 21:29:46 I am interested in pursuing the project "Port/implement MAV (drone) optical flow or stereo image processing to PRUs" Mar 13 21:30:44 I have been able to get the pru set up and have got it working for a basic application Mar 13 21:31:19 I have also familiarized myself with stereo image processing ( i have opencv experience) Mar 13 21:32:00 I wanted to get some guidance as to what task i could take before the application periods end to demonstrate my ability Mar 13 21:32:12 and start working towards the project? Mar 13 21:39:49 push some stuff to github? Mar 13 21:40:08 make a project plan? Mar 13 21:41:12 see if you can identify any problematic/questionable assumptions and work out some possible mitigation? Mar 13 21:41:33 Yep..what could be that "some stuff" be? it would help me to a great degree if i had a clearly cut out task which i could take on Mar 13 21:41:46 okayy Mar 13 21:42:04 it sounds like you have enough prep work Mar 13 21:42:27 i'd start the application draft and work on the above Mar 13 21:42:49 one area that i am still working on is working with the remoteproc driver Mar 13 21:43:18 okay..i will start with that then Mar 13 21:43:18 whatever you have so far can go in protoytpe-y folder in your repo Mar 13 21:43:26 okayy Mar 13 21:43:55 draft project plan can address that Mar 13 21:44:22 document you unknowns and what you plan to do about them Mar 13 21:44:33 *your even Mar 13 21:45:12 yess okay Mar 13 21:45:34 I will get started with that immediately then Mar 13 21:46:08 I had a question though Mar 13 21:47:00 Now since i am transferring huge chunks of data to and from the pru, what from your experience wuld be the most efficient way? Mar 13 21:47:26 define huge... Mar 13 21:47:49 and that would be something to test/refine in the project Mar 13 21:48:25 shared mem is probably easiest/fastest Mar 13 21:48:53 but i'm not the pru expert Mar 13 21:50:07 maybe look at the ti rpmsg thing alexhiam mentioned Mar 13 21:50:54 and the beaglelogic project, which sends fairly large chunks of data from the pru Mar 13 21:51:41 Um..each image would be about 6 megabytes Mar 13 21:51:58 oh alright Mar 13 21:52:03 are 6mb images really needed? Mar 13 21:52:14 or would a lower resolution work? Mar 13 21:52:41 i think that also would be something we'd need to test and find out ? Mar 13 21:52:52 yeah Mar 13 21:52:59 yes Mar 13 21:53:16 maybe extract a smaller piece? Mar 13 21:53:40 * nerdboy not sure how you would identify the "piece" you want Mar 13 21:54:12 maybe if most of the image was uninteresting Mar 13 21:55:01 nope, it would need to be full size at "best" resolution Mar 13 21:55:01 yess..we could probable try that in the later parts of the project..say we keep decresing the resolution/get a smaller chunk till my depth map generated is enough to complete the task Mar 13 21:55:22 why would that ^be ? Mar 13 21:55:31 finding best would be a good task item Mar 13 21:56:08 for stereo images you'd want most/all of the image Mar 13 21:56:26 the required framerate would also be application specific, e.g. if it's on a robot that's moving super slow it might prefer higher resolution @ a lower rate Mar 13 21:56:34 given not too much geometrical distortion around the edges Mar 13 21:56:42 (making that user configurable would be best I think) Mar 13 21:56:49 yup Mar 13 21:56:52 yes.. Mar 13 21:58:05 and the frame processing rate could be a subset of actual fps Mar 13 21:58:32 yay another optimization problem Mar 13 21:58:35 i think resolution of the image can be compromised to certain degree to make the process more optimal Mar 13 21:58:56 could trim a little i suppose Mar 13 21:59:00 haha..yes..lot of factors will depend on the the end user application Mar 13 22:01:28 I think I will start working on making a project timeline, and then with the help of the mentors, I'd scrutinize and identify the problematic areas Mar 13 22:01:37 That the right way to start ? Mar 13 22:02:14 yup. the sooner you get a proposal with a timeline on the ml the more time you'll have to get feedback and tweak it Mar 13 22:02:47 okay great! I'll start working on it! Mar 13 22:05:28 * alexhiam heads to dinner Mar 13 22:09:58 pmezydlo: I will check it out now Mar 13 22:12:01 the tracks on the bottom could be routed a bit cleaner Mar 13 22:12:22 but otherwise probably good enough for government work Mar 13 22:14:35 the 90 angle on the miso track could be avoided Mar 13 22:14:59 you could push the sclk over and go straight down Mar 13 22:18:08 m_w: Mar 13 22:18:08 corrected miso Mar 13 22:19:03 you might want investigate using series termination resistors Mar 13 22:20:02 m_w:bottom layer also fill GND? Mar 13 22:20:36 sure couldn't hurt Mar 13 22:22:31 post another link with the updated schematic and PCB when you are done Mar 13 22:22:46 I will go through it one more time Mar 13 22:23:19 I will be back in a little while, gonna hang with my family for a little while longer... Mar 13 22:23:26 m_w:ok thanks for the reply Mar 13 22:23:36 no problem Mar 13 23:16:28 m_w: bottom layer: https://drive.google.com/file/d/0B1Sxahs4DCgrai1JRGlNYjdIVDg/view?usp=sharing Mar 13 23:17:23 m_w: top layer:https://drive.google.com/file/d/0B1Sxahs4DCgraTFpM3RxMS1HZTg/view?usp=sharing Mar 13 23:18:06 m_w:It looks pretty good Mar 13 23:19:04 m_w:vias and gold pins are standard sizes Mar 13 23:49:36 pmezydlo: the pour on the bottom layer is not connected to GND Mar 13 23:51:04 there GND islands on the top layer that do not connect Mar 13 23:52:53 the easiest way to fix this is putting vias on the GND connects of C2, C3, and C4 Mar 13 23:53:06 and connecting the bottom actually to GND Mar 13 23:54:13 the bottom pour that is Mar 13 23:55:24 pmezydlo: Do you see what I am saying? Mar 13 23:56:35 U2, U3, and U4 are also connected to the same islands that don't actually connect to GND Mar 13 23:57:01 good thing I took a fresh look at the design :) Mar 13 23:58:05 U2 pins 2 and 5 are even on their own islands Mar 13 23:58:39 I usually just use vias near the pins and connect to a pour on the bottom layer Mar 14 00:00:47 just correcting Mar 14 00:01:18 m_w:https://drive.google.com/file/d/0B1Sxahs4DCgrYThYSFZqQno4V3c/view?usp=sharing Mar 14 00:02:18 pmezydlo: bottom is better but I dont see the new GND vias for the floating connections Mar 14 00:02:56 m_w: in the corners Mar 14 00:03:19 no for the GND island on the top layer Mar 14 00:04:28 top and bottom layer is connected to GND Mar 14 00:04:54 islands are isolated copper pours Mar 14 00:05:07 that dont connect actually to GND Mar 14 00:05:12 https://www.youtube.com/watch?v=_MJvt8JL1TI Mar 14 00:05:34 fast forward to 3:30 Mar 14 00:10:00 i see but under device is gnd Mar 14 00:10:26 and connects the gnd Mar 14 00:11:52 the GND is disconnected from the rest of the pour Mar 14 00:12:58 still don't get it? Mar 14 00:16:13 try to draw a line from the pin on the chip to a pin on the beagle connector without leaving the pour Mar 14 00:18:19 m_w: I'm sorry but I really can not see https://drive.google.com/file/d/0B1Sxahs4DCgrM3E0U0Z6TTR6SnM/view?usp=sharing Mar 14 00:18:55 lemme mark it up perhap it will be more clear Mar 14 00:20:21 ah there are connects sneaking under the chip Mar 14 00:20:59 my eyes were deceiving me Mar 14 00:22:09 you are good to go Mar 14 00:22:17 :) Mar 14 00:22:22 yeah, how do you think that now is ok? Mar 14 00:22:24 o thanks Mar 14 00:22:51 add some bling to the silkscreen and ship it ;) Mar 14 00:23:11 pmezydlo: wouldn't hurt to add some via stitching between the top and bottom ground planes Mar 14 00:23:33 helps keep them at the same potential and avoid ground loop issues Mar 14 00:23:48 pin 1 indicators would be nice on the silkscreen too Mar 14 00:24:49 I guess there are small one inside the chips Mar 14 00:25:23 for example the ground path for that right most IC is all the way through the narrow spaces between the pins of each other IC. A few vias between each IC would lower the impedances on the ground returns Mar 14 00:25:52 might not actually make any noticeable difference here, but a good habit to get into Mar 14 00:26:17 and +1 to pin 1 indicators! Mar 14 00:26:33 there are different schools of connecting GND, but this is not an analog system Mar 14 00:26:53 they are best on the outside of the components for optical inspection Mar 14 00:28:05 pmezydlo: there's more than two voltage level - sounds analog to me ;) Mar 14 00:28:34 it's true it's not RF, but ground loop issues certainly can be a problem on any type of electrical system Mar 14 00:30:27 Remembering Bob Pease, I suggested his lectures about GND contecing Mar 14 00:35:27 I added some vias Mar 14 00:35:30 just using the GND pour on the bottom would avoid loops Mar 14 00:35:42 lets have a look Mar 14 00:35:48 true Mar 14 00:37:46 https://drive.google.com/file/d/0B1Sxahs4DCgrMG5ESXRYYXRHSzQ/view?usp=sharing Mar 14 00:38:09 What do you think? Mar 14 00:40:14 not important - but I'd move those vias on pins 3 and 4 of U2 in a little to allow the plane to fill around them. Unconnected islands like that just bug me :P Mar 14 00:41:36 I wonder what percentage of time I spend on layouts just being nitpicky... Mar 14 00:45:30 thanks for your help, I was very pleased, it's better now correct it Mar 14 00:49:27 I am pretty confident it will work Mar 14 00:52:34 Tomorrow starts the application, at my timezones already Mar 14 00:52:34 for a few hours Mar 14 00:53:10 good luck! Mar 14 00:53:16 whether we can continue to talk about projects? Mar 14 00:54:05 pmezydlo: for sure. the best way to do it is to submit your application asap so you can get comments on it and rework it as needed Mar 14 00:54:55 you did mean during the application period, right? Mar 14 00:57:17 yes Mar 14 00:58:13 I ask out of curiosity, I'm from Poland, You have any association with that country? Mar 14 00:58:29 then yeah, we expect lots of project discussion Mar 14 00:58:53 me? no, why? Mar 14 00:59:48 just asking Mar 14 01:03:25 sorry, i mean memories, situations or maybe some poles Mar 14 01:08:50 my grandfather on my mother's side was polish Mar 14 01:09:38 never been, and not sure I've met anyone from Poland... why? now I'm curious! Mar 14 01:10:54 a lot of people confuse Poles with Russians Mar 14 01:11:07 m_w:thats greas Mar 14 01:11:16