**** BEGIN LOGGING AT Tue Apr 07 02:59:59 2015 Apr 07 06:24:54 morning! Apr 07 07:08:26 gm Apr 07 07:08:29 * av500 is back Apr 07 07:42:07 lo all Apr 07 09:56:02 good morning !!! Apr 07 11:23:33 hi kiran4399 !!! Apr 07 11:23:56 beng-nl: hey howdy !!! How are you ?? Apr 07 11:24:59 beng-nl: Ben gras ?? Apr 07 11:26:21 yeah that's me Apr 07 11:26:29 * beng-nl looks shiftily Apr 07 11:27:29 beng-nl: I saw you in rtems !! :-P Apr 07 11:27:54 oh right haha :-) Apr 07 11:28:10 small world ;-) Apr 07 14:16:23 av500, hi Apr 07 14:21:54 hi is any gsoc mentor present here who can help me out Apr 07 14:22:23 just ask Apr 07 14:24:28 vvu, i need to change some part of my poposal .can yu allow me to do that . Apr 07 16:28:52 ds2 ping Apr 07 16:28:59 apaar: pong Apr 07 16:29:34 you had suggested on making pru bridge fully realtime Apr 07 16:30:30 if we move the buffers to the shared memory between the prus(local memory 12Kb) it should allow the pru side of things to be realtime Apr 07 16:31:24 but i had one concern(i think you raised it too)...what it the driver and pru try to access the memory at the same time then is it possibly some jitter can occur?? Apr 07 16:31:30 apaar: that's one way you can do it. there are many ways Apr 07 16:31:56 apaar: yes it can. the SBCO instructions can incur penalty cycles but they should be mostly small Apr 07 16:32:23 apaar: if you look at the PRUSS as a whole, there are 3 main banks of memory of interest to us Apr 07 16:32:32 DRAM0, DRAM1, and SharedMem Apr 07 16:32:59 they are banks. if you design things right, you can minimize access conflicts Apr 07 16:34:00 yep :)...so i was thinking would it be possible to move the control buffer to DRAM0 or 1 then the driver could check that and accordingly touch the shared memory preventing conflicts Apr 07 16:34:45 apaar: I did something like that and it seems to worked Apr 07 16:35:38 be back. got to do a call. Apr 07 16:36:18 cool thanks :) Apr 07 16:37:24 guy was busy... Apr 07 16:37:30 got about 10 mins Apr 07 16:39:06 ah nice so i think i will change the design for DDR mem to local memory tgus allowing the pru to be fully realtime even with the bridge Apr 07 16:39:25 provide options for the user of it Apr 07 16:39:50 if there is something that needs to generate tons and tons of data (i.e. Beagle Logic), the slave PRU mightbe best Apr 07 16:40:09 and that assumes a slave PRU can be affording :D Apr 07 16:40:11 afforded Apr 07 16:41:13 well the read routine on the pru side could be put in a loop using a complete pru but that is up to the user Apr 07 16:41:50 ??? Apr 07 16:42:52 i was just mentioning that the read routine could be used in a loop for larger amounts of data Apr 07 16:43:05 but there can still be some conflicts that could arise at the control buffer but that should be avoidable(i am still working on that bit but it should no be too hard) Apr 07 16:43:06 what read? Apr 07 16:44:28 sorry i meant the write(did not notice the beaglelogic use case and just took it to be loads of data both ways) Apr 07 16:44:49 read can be used to import data from the arm Apr 07 16:46:02 the nature of BeagleLogic distorts things Apr 07 16:46:13 it can take some shortcuts that isn't always possible Apr 07 16:46:22 consider this - Apr 07 16:46:43 a device is generate parallel data at some high rate... say 25MHz Apr 07 16:47:09 so you wire up the PRU clock pin to the device's clock signal, and the PRU.in0...7 to the parallel data Apr 07 16:47:37 to make sure you do not drop data, you will need to maintain some kind of synchronization with the device Apr 07 16:48:11 at 25MHz, you have at most 40nS or 8 instructions to do that Apr 07 16:48:40 where as BeagleLogic just does a async read of the lines Apr 07 16:48:59 not needing to maintain sync simplifies things a LOT Apr 07 16:49:41 ah so write must take a max of 8 instructions(hopefully less) but wit beaglelogic i need not care beyond a point?? Apr 07 16:49:50 with* Apr 07 16:50:01 sort of but it is worse then that Apr 07 16:50:34 in that 8 cycles you will need to: read the PRU's pins. maintain pointers, write to memory somewhere, and maintain clock synchronization Apr 07 16:50:58 if you do the math, that cannot fit in 8 cycles (if it can, I've love to hear from you proving otherwise ;)) Apr 07 16:51:21 so to make that work, you have to play games which is why loops on the PRU is not that simple as plugging in blocks Apr 07 16:51:50 ds2 :i have to give attendance in hostel(we have to do it every night)...could i come back in 10 minutes or so?? Apr 07 16:53:20 yes Apr 07 16:58:12 ds2: got back Apr 07 16:59:05 so we need to fit a whole read from pin + write to memory + write to control buffer in 8 cycles right? Apr 07 17:01:10 on call Apr 07 17:01:58 ok cool do ping me when you are free Apr 07 17:02:02 k Apr 07 17:03:41 apaar: ping - back Apr 07 17:04:01 apaar: yes or you games Apr 07 17:04:17 for example - you unroll the loop a little bit Apr 07 17:04:53 LOOP: read pin to register - update control - read pin to register - write out both values Apr 07 17:05:47 the amount of unrolling depends on how much time you need but the key there (using my example) is you cannot block for more then about 8 instructions Apr 07 17:06:26 in reality, it can be a little worse then that due to clock tolerances and the remote clock being async. Apr 07 17:07:43 why not fist store a fixed number of samples(depending on memory available) and export them as a block Apr 07 17:07:51 first* :P Apr 07 17:08:33 cuz the SBCO instruction timing is something like - Apr 07 17:08:53 1 cycle + N * cycle where N is the number of words being written Apr 07 17:09:14 so at min. you burn 2 cycles each time you write to memory Apr 07 17:09:43 ah so that would lead to large breaks in the middle of sampling right Apr 07 17:09:49 yes!! Apr 07 17:10:23 given that tight timing, I have doubts about a general purpose design Apr 07 17:10:29 for really slow stuff, sure Apr 07 17:10:51 (FWIW - I have implemented this so it is not a hypothetical discussion) Apr 07 17:12:46 so bridge fails only for cases where you want very high speed data transfer.can we not just do it the beaglelogic way in those cases Apr 07 17:14:31 right now it is be fully realtime just slow for some niche cases...would it not be very useful for other cases like a serial monitor or a rpmsg implementation Apr 07 17:15:41 that is fine if you can use the other PRU as a slave Apr 07 17:15:54 if you need it to do something else, that won't work Apr 07 17:16:17 PRU resources are limited and it is a shame to burn one as a DMA controller when there is a fine one on the board Apr 07 17:17:41 so it wont work only for the situation where you need both pru's(parallel data ) and need to pass them even then will it not be faster than doing it on linux Apr 07 17:18:59 but apart from that the uses are quite a few Apr 07 17:19:13 I wouldn't say that Apr 07 17:19:36 if you are doing very slow stuff, I question the need to use the PRUSS Apr 07 17:20:14 apaar: are you still planning on having an event loop in pru-bridge? Apr 07 17:20:37 alexanderhiam: no i updated my proposal with what you ad suggested Apr 07 17:20:44 had* Apr 07 17:21:33 we will now be using a routine that the dev calls instead of polling Apr 07 17:21:40 ok, I thought so. I couldn't tell from this conversation if you were still envisioning that model Apr 07 17:22:12 that means that you could potentially have separate programs on the two prus each using pru-bridge Apr 07 17:22:55 something like that but i have not fully finalised the details yet Apr 07 17:25:56 ds2 : will it still not be much faster than doing it on linux and also it will be very useful for one off data transmission allowing newer users to aviod writing a complete driver just to pass a few words Apr 07 17:28:24 new user tools are nice but I am not a fan of disposable tools Apr 07 17:30:30 well seeing that it took a full gsoc to implement stuff like pruspeak(which bridge will make quite easy) i do believe that the pruss learning curve is just too inhibiting for most new users also stuff like a serial monitor or a rpmsg implementation will be cool to have Apr 07 19:43:27 hendersa : did some changes in proposal as you mentioned. please have a look. :) **** ENDING LOGGING AT Wed Apr 08 02:59:59 2015