**** BEGIN LOGGING AT Tue Jun 21 02:59:58 2016 Jun 21 03:50:27 Wormo: yes about the clpru ? Jun 21 04:27:40 So, its now not the mailbox that being used for communication , but system level interrupts, in the latest kernel version 4.4.-12.-ti-r31 Jun 21 04:28:05 btw, I am unable to see the related commit in the history. Jun 21 04:31:53 ZeekHuge: yes that's what I meant, they referred to clpru vs gcc port Jun 21 04:40:06 okay. Jun 21 05:04:40 Need some help with PRU interrupts. Jun 21 05:05:14 Okay so the point it , why do we need more than 2 hosts if only 2 of them are connected to the PRU. Jun 21 05:05:22 My understanding is that ... Jun 21 05:06:01 there are a few system events, from 16 to 31 that can be generated by the PRUs Jun 21 05:06:37 these system events, that are generated by the PRU can be mapped to the other hosts ie from host 3 to 9 Jun 21 05:07:49 and then these hosts can be further mapped to channels, which can be further mapped to any of the 64 system events, over the whole SoC Jun 21 05:08:46 so what make me unsure about the above thing is undirected arrows in the pruReferenceManual. Jun 21 05:09:08 so just want to confirm If my understanding is right . is it ? Jun 21 05:09:24 ds2: Abhishek_ Wormo alexhiam Wormo Jun 21 05:09:27 ^^ Jun 21 05:10:57 *uni-directed arrows in the pruReferenceManual Jun 21 05:13:29 nope .. Jun 21 05:20:56 I was able to generate a system event without any INTC mapping, writing to R31 is enough to generate system event, then why do we have other hosts in the INTC ? Jun 21 12:17:51 Hi ! I am the pru code written in asm and compiled using PRU-CGT is not getting loaded . is it the pru_rproc ? Jun 21 12:17:51 thats causing this issue ? Jun 21 12:17:52 *I have the Jun 21 13:34:03 I am so happy ! I got blinky ! Jun 21 13:34:07 after all day ! Jun 21 13:34:19 using inline asm code Jun 21 13:34:25 :D Jun 21 13:34:26 :D Jun 21 13:34:29 :d Jun 21 13:34:31 :D Jun 21 14:14:58 ZeekHuge: nice! everything pushed to github? Jun 21 14:37:03 alexhiam: ahh .. yeah ! was about to ... but then ... I was removed some redundant code from make file, and now its not compiling ! Jun 21 14:37:06 haha .. Jun 21 14:37:19 working on it ... will be up soon. Jun 21 14:37:40 fun Jun 21 14:46:11 alexhiam: by the time, can you help me with a doubt ... Jun 21 14:46:42 why does the PRU INTC has more than 2 HOST when only 2 of those 10 are connected to PRU cores ? Jun 21 14:47:08 uhh.... Jun 21 14:47:15 ds2: Abhishek_ Wormo ^ Jun 21 14:47:21 * alexhiam open the PRU reference manual... Jun 21 14:48:05 ah, "2 Host Interrupts for the PRUs", "8 Host Interrupts exported from the PRU-ICSS for signaling the ARM interrupt controllers" Jun 21 14:48:12 section 6.1 Jun 21 14:55:03 alexhiam: ahh .. yeah . Thank you, I should have read the first page. But then, I was confused as , the diagram has uni-directional arrows and by the fact that I was able to generate system event without any INTC mapping. but I got it now. :) thank you Jun 21 15:25:15 hi jkridner Jun 21 15:25:21 howdy! Jun 21 15:26:07 I have a problem on looping over probes Jun 21 15:27:12 when the user pick a button into the graph, the 'select pin' event becomes active Jun 21 15:27:48 pins should be kept highlighted till the user choose one pin Jun 21 15:28:16 why is that a problem? Jun 21 15:28:35 the probe.test() function shouldn't have any logic about if the probe is selected or not. Jun 21 15:28:50 it should just let the ui know if the mouse is over a probe and which one. Jun 21 15:29:06 so, why should the state cause an issue? Jun 21 15:30:13 the idea is that you should be able to know from the UI perspective, without needing to know anything about the geometry, if the mouse is over anything interesting. Jun 21 15:30:14 each probe has a category "probe", pin object can't define "probe" Jun 21 15:30:32 why would it need to? Jun 21 15:31:19 button.push function sets the category to "probe" for each inserted button Jun 21 15:32:02 when the probe inserted in graph, the corresponding pins should kept highlighted Jun 21 15:32:20 and pins are highlighted depending on the button category Jun 21 15:33:35 I don't know why we have to change the category to "probe" ? Jun 21 15:35:05 https://github.com/amragaey/bone101/blob/gh-pages/Support/bone101/UI/bbui.js#L453 Jun 21 15:35:09 what would you do with it? keep it button? Jun 21 15:36:07 I thought that you have to treat them as a new category Jun 21 15:36:17 we just use the term 'probe' to let us know it is an active probe, or connection between a pin, a graph and an on/off/slider control Jun 21 15:36:40 I'd think we would, which is why we set the category to 'probe'. Jun 21 15:38:30 I'm thinking addTest() is not the general probe test function. https://github.com/amragaey/bone101/blob/gh-pages/Support/bone101/UI/bbui.js#L848 Jun 21 15:39:52 looks like it is only testing for the adding function, not for the highlighting, etc. Jun 21 15:40:06 yes, If we would change the category to 'probe', how would we highlight pins for this "probe" category ? Jun 21 15:40:17 a general probe.test() function like https://github.com/amragaey/bone101/blob/gh-pages/Support/bone101/UI/bbui.js#L288 should loop over the probes, no? Jun 21 15:40:38 we'd need to add a probe.test() function. Jun 21 15:41:04 I added a one like button.test() but what would be the different ? Jun 21 15:42:28 when I used it, it returns "0" and "1".. the probeIndex of the probes. Jun 21 15:48:42 Is there a way to return the button object not the property name? Jun 21 15:52:20 jkridner, sorry internet disconnected Jun 21 15:52:38 I got last message " we'd need to add a probe.test() function " Jun 21 15:53:29 I added a one like button.test() but what would be the different ? when I used it, it returns "0" and "1".. the probeIndex of the probes. Is there a way to return the button object not the property name? Jun 21 15:54:16 jkridner, you still there ? Jun 21 16:05:21 Abhishek_: alexhiam ds2 mdp Wormo : https://github.com/ZeekHuge/BeagleScope/tree/master/examples/firmware_exmples/PRU_inline_asm_blinky Jun 21 16:05:29 using inline asm . Jun 21 16:05:35 now dinner :) Jun 21 16:31:24 amr_ragaey: back Jun 21 16:32:15 amr_ragaey: you could return the probe object. Jun 21 16:32:28 amr_ragaey: we'd want to try to find some consistency. Jun 21 16:32:44 * jkridner isn't sure where the equivalent is in https://github.com/jadonk/Beaglebone-UI/blob/master/BBUI.html Jun 21 16:35:16 alexhiam: there? Jun 21 16:36:46 * ZeekHuge - back Jun 21 16:40:17 one question, how are we going to manage the sampling rate ? Will it be like doing it some how in PRU fw ? or sampling the PRU at max and if lower sampling rate is asked, ignoring the extra data in the kernel code ? what approach should we take ? Jun 21 16:40:29 ds2, Wormo , Abhishek_ ^ Jun 21 16:49:23 jkridner, I returned the object :D .. I have to see how to highlight pins now for this probe Jun 21 18:38:22 ZeekHuge: did you speak to the office? Jun 21 18:40:09 I tried every office i could find contact - number of, non of them helped. Either they were directing me to customer service, or providing with contact number to another office. Jun 21 18:41:05 did they send you any email with a contact information on it? Jun 21 18:41:41 ZeekHuge: you got the invoice from jkridner, does that help? Jun 21 18:42:10 To fill out that form they gave you already Jun 21 18:44:17 I have already mailed them that the application is not actually valid for my consignment. They acknowledged the mail and said that they will reply soon. Jun 21 18:44:46 Abhishek_: Nope they didnt . They just told me the number on call. Jun 21 18:47:17 Wormo: yes. I did some research and found that form is required when consignor is in one state and consignee is in the other, both in India. So the form is not actually applicable in our case. Jun 21 18:47:42 interesting Jun 21 18:48:22 And i have mailed them stating this. I will mail them tomorrow again if they dont reply. Jun 21 18:48:29 So they should just send you the package without further paperwork? Jun 21 18:48:31 Abhishek_: what is ? Jun 21 18:49:03 Most likely. Jun 21 18:49:09 Wormo: I think so .. Jun 21 18:50:55 I hope they do so. Meanwhile, software work can go on... Jun 21 18:51:03 and I got pru->pur->ARM interrupts working ! Jun 21 18:51:16 and pru inline code too ! Jun 21 18:51:38 sounds good Jun 21 18:51:56 *inline assembly ! Jun 21 18:52:36 https://github.com/ZeekHuge/BeagleScope/tree/master/examples/firmware_exmples/PRU_inline_asm_blinky Jun 21 18:52:48 I was just noticing it got pushed :) Jun 21 18:53:22 yeah, will probably push pru->pru->ARM INT code too .. Jun 21 18:53:34 some questions now. Jun 21 18:57:20 Abhishek_: you there ? it will just take a few minutes Jun 21 19:00:37 Abhishek_: okay so i will put up the question here, please do answer even if I am not here, I will keep looking at the logs, for missed things. Jun 21 19:00:49 So, its about the INTC. Jun 21 19:01:00 *PRUSS INTC Jun 21 19:02:41 according to my understanding, the PRU can or other peripherals can generate system events. Now these system events are kind of independent , but they are mapped to the INTC and further can be mapped to the channels in the INTC Jun 21 19:02:58 these channel can be further mapped to HOSTS Jun 21 19:03:17 and then HOST0 and 1 are serving the PRU cores Jun 21 19:03:53 the other HOSTS are connected to the A8 INTC Jun 21 19:04:28 and then so system events ->(read mapped to) channels -> Host (other than 0 and 1) interrupt the ARM Jun 21 19:04:54 further the ARM INTC somehow knows which HOST it was . Jun 21 19:06:29 and then there will be a driver which will take care of these interrupts, depending upon the host Jun 21 19:06:29 so different hosts are like different signals. Jun 21 19:06:29 further, signals can be generated in two ways. Jun 21 19:06:30 either use these 8 hosts we have got. Jun 21 19:08:01 or use just one host to interrupt ARM, and then make write some message in the DDR Jun 21 19:08:01 and then the ARM interrupt will make ARM read that message Jun 21 19:08:10 yeah, so that all. Is there anything wrong there ? Jun 21 19:08:33 and second question : Jun 21 19:08:40 http://git.ti.com/pru-software-support-package/pru-software-support-package/commit/69805828df0f262fb60363c2db189d1b8d0b693c/diffs Jun 21 19:09:09 this commit says that PRU0 uses sys_evnt 16 and 17 Jun 21 19:09:59 just a sec .. Jun 21 19:13:35 how does the ARM interrupts the PRU ? Jun 21 19:14:22 is it through those 3 EDMA sys_evnts ? 61 to 63 Jun 21 19:14:38 *interrupt Jun 21 19:17:42 further , in that software-support-package link, they are using sys-evnts 16 and 17. So why two sys_evnts ? ... okay so if i will have to guess, one is for ARM-> PRU and other PRU-> ARM, but then the pru-reference manual states that sys_evnts from 16 to 31 can only be generated by the PRU core itself. Jun 21 19:18:13 page 222 : http://www.siue.edu/~gengel/bbbWebStuff/am335xPruReferenceGuide.pdf Jun 21 19:18:18 ds2: ^ Jun 21 19:20:07 m_w: Wormo ds2 Abhishek_ : other question, how we are going to manage different sampling rates ? is it something that PRU fw should be configurable ? or we should run the PRU core at it max and ignore extra data in the kernel if slower sampling rate is required ? Jun 21 19:21:54 ZeekHuge: how easy is it to control the frequency of the clock coming from the PRU? Jun 21 19:22:07 I would prefer to see the sample rate passed in during setup by kernel, control how many wait states for the sampling Jun 21 19:22:44 You might be able to pull it off in the firmware Jun 21 19:24:47 in fw, the number of wait instructions will be like multiple of 2 . one SUB and other using QBEQ (Quick branch if equal to ) to compare it with zero Jun 21 19:25:04 right ? Jun 21 19:25:25 Abhishek_: Wormo m_w ^ Jun 21 19:26:55 I dont think it will be difficult, we can pass arguments to the inline asm code. Jun 21 19:27:07 m_w: ^ Jun 21 19:27:10 ZeekHuge: something like that should work Jun 21 19:28:23 ZeekHuge: you would have to do a calculation to best approximate the desired frequency with the instruction delays Jun 21 19:28:29 Yup, BeagleLogic uses inline ASM magic for achieving sample rates. Jun 21 19:28:37 *configurable Jun 21 19:30:43 actually, as we need to supply the clock too, I was thinking to make two different asm functions. one that would only run at the highest sampling rate and will be non - configurable. Other will be use when we need lower sampling rates. Jun 21 19:31:44 That is because, in case of highest sampling rate, those two SUB and QBEQ will result in a loss of 2 cycles for no reason. Jun 21 19:32:29 while in case of lower sampling rates, we have enough time to waste those two cycles and thus make it configurable. Jun 21 19:32:41 Abhishek_: m_w : ahh ... does that make sense ? Jun 21 19:38:53 Interesting you made that observation. BeagleLogic has two sample loops, one for 100MHz and other for lower sampling rates. Jun 21 19:38:59 hey bradfa There? Jun 21 19:39:04 mdp, ^^ Jun 21 19:39:38 For the exact same reason. Jun 21 19:39:57 Abhishek_: cool ! so plan to make two different codes is right ? Jun 21 19:39:58 okay Jun 21 19:40:28 Abhishek_: and what about the PRUSS-INTC thing all above there ? Jun 21 19:47:52 Abhishek_: ahh ... what was your status till first mid eval ? Jun 21 19:48:09 if you dont mind telling that. Jun 21 19:48:59 Abhishek_: but please do ans to my all that INTC thing above. I am not directly using it, but its hard to keep a doubt in mind. Jun 21 19:52:08 ZeekHuge: in general students should be able to tell if they are going to pass midterm eval, based on whether they have been responsive to any concerns mentors have responsive to things mentors have brought up Jun 21 19:53:01 those who have been responsive don't need to worry, those who have not been so responsive should get in contact with their mentors quickly... Jun 21 19:53:38 and get on board whatever improvement plan the mentors offer Jun 21 19:54:10 oops a bit scrambly there at the start Jun 21 19:54:29 s/have responsive to things Jun 21 19:54:43 s/have responsive to things mentors// Jun 21 19:56:23 bradfa, mdp, I have a doubt regarding the the struct file*flip pointer flip pg 67 in ch 3 ldd3. In my case, I am not reading from a file but from the address returned by ioremap.So I am confused what to do. Jun 21 19:56:28 Wormo: I am not at all concerned about the mid-eval. My only concern is the progress of the project and its pace. Jun 21 19:57:39 I am like always worried if I am going too slow, and taking too much time in simple things. Jun 21 19:58:41 And bradfa Should I return MISO one bit at a time to the userland?Or run a loop and store stuff in a buffer and then use copy_to_user? Jun 21 19:58:55 chanakya_vc: userspace does writes to a /dev/ char driver file, kernel does copy_from_user(), takes data and sticks it into PRU (which may use ioremap address). Is that not the flow? Jun 21 19:59:15 chanakya_vc: you can do it however you want, this is just for debugging Jun 21 21:25:10 bradfa, mdp, I have completed the basic framework of the driver and pushed it.Please have a look and tell me what you think of it. Jun 21 21:26:11 bradfa, I will work on modifying the framework tomorrow and also try to complete the makefile.But might need your help with the makefile. Jun 21 21:26:18 *firmware Jun 21 21:26:43 * chanakya_vc writing this weeks progress report. Jun 21 22:02:31 bradfa, There? Jun 21 23:46:58 jkridner, Jun 21 23:47:01 hi Jun 21 23:47:45 jkridner, Could provide some information about graph.test() function ? Jun 22 01:29:53 does he mean the spi parts? Jun 22 01:51:33 * ZeekHuge was asleep last night :( Was hoping to work on the driver and fw. **** ENDING LOGGING AT Wed Jun 22 02:59:58 2016