**** BEGIN LOGGING AT Sat Mar 08 02:59:59 2014 Mar 08 09:33:21 morning Mar 08 15:31:16 jkridner: ping Mar 08 15:32:01 jkridner: i was wondering when the pru compiler was slated for public release. Mar 08 15:38:39 morning Mar 08 16:21:58 mdp: ping Mar 08 16:22:23 <_av500_> mdp is travelling back from macao Mar 08 16:25:42 hmm, when could we have him back? Mar 08 16:48:19 ka6sox: how far can streaming GPIO data from PRU benefit with a kernel-mode code written for it than a program running in userspace? Mar 08 16:56:11 jkridner: ping Mar 08 19:05:22 Is there a application template put out somewhere? I couldn't find it on the GSoC wiki pages. Mar 08 19:13:07 karki: it will be available on melange Mar 08 19:13:11 <_av500_> yes Mar 08 19:13:12 once applications open Mar 08 19:18:54 are previous applications available to see? Mar 08 19:19:04 <_av500_> no idea Mar 08 19:19:06 <_av500_> try Mar 08 19:19:11 <_av500_> hmm Mar 08 19:19:16 <_av500_> not sure they were public at all Mar 08 19:19:19 <_av500_> mentors can see Mar 08 19:19:32 <_av500_> not sure if students can see other applications Mar 08 19:19:39 <_av500_> probably not Mar 08 19:26:27 previous ones were. I had seen anuj's 3-4 months ago on melange. But now it has been removed. Mar 08 19:33:16 karki: you can see if the user has made it public.. mine was. i don't know why it isn't now though .. Mar 08 19:36:19 so i can't see my own proposal now . melange is weird Mar 08 19:46:01 Abhishek_: I'm in transit atm...but gpio data from pru via buffering allows higher sample rate than anything in linux via kernel/userspace gpio apis Mar 08 19:46:53 buffering, as in? Mar 08 19:50:33 Abhishek_ : I think mdp means caching the values temporarily Mar 08 19:51:46 I'm just guessing, haven't been following the conversation Mar 08 19:52:00 that's correct Mar 08 19:52:51 so, one pru can read gpis with r30 using a single instruction Mar 08 19:53:43 optimally you'd then shove the value through the scratch pipeline to the other pru Mar 08 19:53:56 I see Mar 08 19:54:31 that pru could store in sram and move chunks to dram as needsd for linux handling Mar 08 19:55:30 the trick is to not do the time critical acquisition with same pru as you use to go out to the dram Mar 08 19:56:17 as stalls are possible accessing anything on the soc interconnect..like dram Mar 08 19:56:44 so it would be something like PRU0 reads, then value is passed on the PRU1 and PRU1 writes it to a DRAM buffer Mar 08 19:57:00 * mdp is about to go dark...aircraft door soon to close :) Mar 08 19:57:02 yes Mar 08 19:57:28 can [PRU0 reads, then value is passed on the PRU1] be done in a single instruction, or would it take two? Mar 08 19:57:32 Using the scratch pad registers which have much lesser latency than the DRAM right? Mar 08 19:57:41 I think so Mar 08 19:57:46 there's a special single cycle path Mar 08 19:58:11 yes, scratchpad have guarantees single instruction access Mar 08 19:58:25 the best way to understand them would be to read to the PRU ref manual in sitara reference, right? Mar 08 19:58:28 So it will be one instruction itself. Mar 08 19:58:59 Who else here is working on the PRU? Mar 08 19:59:10 read the latest trm chapter on pru Mar 08 19:59:40 I think they put the chapter back in to later trm revs Mar 08 20:00:00 the docs package on github is good too Mar 08 20:00:07 the Dec 11 rev A1 ? Mar 08 20:00:46 spruh73?.pdf Mar 08 20:00:55 am335x trm Mar 08 20:01:11 ok..bye Mar 08 20:01:25 yeah right Mar 08 20:01:40 happy and safe journey :) Mar 08 20:02:06 I'm just wondering since you are using two threads of control, how will you ensure synchronization? Mar 08 20:04:16 hmm that would be tricky. Hope to figure it out once code turnout begins Mar 08 20:06:51 Best of luck :) Mar 08 20:07:14 There's a long way to go. Thanks, and same to you :) Mar 08 20:07:31 I'll try to figure something myself. your problem seems interesting. ;) Mar 08 20:10:38 mdp: i am interested in the PRU firmware project as described in the wiki. Mar 08 20:10:41 mdp: Mar 08 20:11:35 mdp: I would be thrilled to do it because i rellay playing with the kernel Mar 08 20:12:44 bit how much this proposed idea is important among all other project that deal with partical matters like bonescript and android ? Mar 08 20:12:56 mdp: do you know off hand if you write to the main SRAM, it will also be as slow as writing to DDR? Mar 08 20:14:19 it is 64K compared to 12K for the PRU RAM Mar 08 20:14:26 ds2: hello, ds2 :), just to be sure, i am not taloking about the jtag pru fimware loader from last year ... Mar 08 20:14:57 hi chocko Mar 08 20:15:11 hmm, That's why this is very tricky Mar 08 20:15:38 yes Mar 08 20:15:45 the PRU is the undiscovered country Mar 08 20:16:08 i just wish there's time to sort out the DMA Mar 08 20:16:18 Normally if I were to use an STM32, I would just DMA off the GPIO port into the SRAM, and then shove it off to USB Mar 08 20:16:20 the EDMA engine should be able to do help Mar 08 20:16:46 Abhishek_: what's the top speed the GPIOs can run at on the stm32? Mar 08 20:16:58 I think stock generic GPIO on the am335x tops out around 10MHz or so Mar 08 20:17:08 The datasheet reads 100 MHz for the F4s Mar 08 20:17:26 does someone know when mdp will be finally available ? Mar 08 20:17:38 ah Mar 08 20:17:43 I've never tried, though I have played around for quite a while with the STM32F4Discovery board Mar 08 20:17:55 is the GPIO's on the F4's synchronized with a clock? Mar 08 20:18:33 I vaguely recall there is some gotchas to that 100MHz number... the FAE at the seminar made a quick brief mention of it Mar 08 20:19:05 Hi, I am a student interested in applying to beagleboard through gsoc this year. I was interested in Android-based remote display project in the ideas list. Was hoping to get a few pointers on how to start off and proceed. What you expect from a prospective student for this etc. Mar 08 20:19:22 slack_: what do you know about the project? Mar 08 20:20:52 I just went quickly through the GPIO section, there seems to be no mention of a clock in any block diagram Mar 08 20:21:07 are these numbers the reason for why the PRu are stalled when they pulled things on the GPIO ? aka GPIO are bottlenecks for the PRU ? Mar 08 20:22:07 From what I understood, Project is to have some functionalities of the beaglebone operable through the mobile. Communication done through usb using the library that beaglebone supports Mar 08 20:24:19 hmmm Mar 08 20:30:19 no luck with the STM32 datasheet too Mar 08 20:30:35 Would it not take more than 1 cycle to write to the SRAM? and how much extra effort will it take to move data from SRAM to DDR or USB - I see more synchronization problems. Mar 08 20:34:10 The stock system image, though suppors a Virtual COM port but it seems that I tend to get a terminal everytime I open it. Mar 08 20:36:55 Though I am already accessing it via RNDIS anyway Mar 08 21:01:28 g'night **** ENDING LOGGING AT Sun Mar 09 02:59:58 2014