**** BEGIN LOGGING AT Wed Mar 19 02:59:58 2014 Mar 19 05:00:10 vmayoral: ping Mar 19 05:00:14 sidbh: ping Mar 19 05:00:22 anujdeshpande: ping Mar 19 05:00:26 *pong Mar 19 05:00:41 sidbh: i was thinking of revising our objectives. Mar 19 05:00:59 yes, go ahead Mar 19 05:01:42 me doing device tree, gcs, smaller modules as mentioned by panto Mar 19 05:02:05 then that would mean I totally not look into remoteproc, loading, comm, kernel interfaces. Mar 19 05:02:57 sidbh: i basically wanted to discuss what all modules I should cover. i would like to cover all of them really Mar 19 05:03:27 what all smaller modules you have thought of Mar 19 05:03:31 but of course if you want to work on some, I don't mind. I just don't want my objective list getting shorter Mar 19 05:03:58 pwm, ppm, ppm-sum, spi for starters Mar 19 05:05:47 anujdeshpande: for PRU peripherals or for both ARM and PRU peripherals Mar 19 05:07:40 sidbh: both I guess. or do you want to split that ? Mar 19 05:08:18 if you are doing the heavy lifting of remote proc and loading and comm and kernel interface, I need to cover a lot of ground to match your work Mar 19 05:11:47 sidbh: what did i miss Mar 19 05:12:11 anujdeshpande: remote proc & everything are already there as said by panto, bringing them up to the userspace is not more than 2-3 weeks Mar 19 05:12:54 sidbh: I was going through the proposal by mdp and mrantosay on the ideas page. did you check that out ? Mar 19 05:14:35 sidbh: http://elinux.org/BeagleBoard/GSoC/Ideas#PRU_firmware_loader as well as http://elinux.org/BeagleBoard/GSoC/Ideas#PRU_upstreaming Mar 19 05:16:12 * anujdeshpande i was thinking of doing this http://elinux.org/BeagleBoard/GSoC/Ideas#Generic_Device_Tree_Creator too. won't be that difficult .. Mar 19 05:17:46 anujdeshpande: the pru firmware loader part is done by panto, that's what i'm trying to say. Mar 19 05:19:04 today you can put PRU's firmware file in the firmware directory and load the PRU's dtb file and you are good to go Mar 19 05:19:51 there is a driver for PRU in 3.8 kernel written by panto https://github.com/beagleboard/linux/blob/3.8/drivers/remoteproc/pru_rproc.c Mar 19 05:20:03 check it out... Mar 19 05:21:40 the PRU rproc functionalities are handled there even uio driver for PRU is there too, as i said we just need to bring there functionality to the userspace Mar 19 05:22:34 i see. so whats your solution ? Mar 19 05:22:58 sidbh you do the load+comm+spi ? Mar 19 05:24:14 :D Mar 19 05:24:39 anujdeshpande: let the things be as before Mar 19 05:25:06 sidbh: hardly anything for me to do :-P Mar 19 05:25:46 sidbh i shall talk to mdp mrantosay and panto and figure out other things to be done then Mar 19 05:26:29 anujdeshpande: how the things are less for you Mar 19 05:26:45 let me state the tasks: Mar 19 05:27:02 I wouldn't be doing anything related to the load+comm Mar 19 05:30:58 PRU+PWM+PPM-SUM+SPI(bitbanged) libs for PRU, then data handling lib on ARM for those libs, porting all these libs to the Ardupilot's AP_HAL and then testing, GCS, Device tree Mar 19 05:31:31 why PWM via the PRU? Mar 19 05:32:23 ds2: realtime... Mar 19 05:32:37 why not use the ehrpwm hardware blocks? Mar 19 05:34:58 ds2: using ehrpwm through linux userspace will induce latency, the writing of PWM register will not be at the time as needed i guess Mar 19 05:36:58 ds2: what do you think? Mar 19 05:41:44 eh? Mar 19 05:41:56 the ehrpwm is accessible in the kernel Mar 19 05:42:09 don't see any more latency then the PRU Mar 19 05:43:54 * sidbh thinks ds2 has got a point Mar 19 05:44:33 do not code unless absolutely needed Mar 19 05:44:48 code == way to introduce bugs Mar 19 05:48:29 ds2: having PWM through PRU will be helpful in case anybody wants to write the main/failsafe control loop inside the PRU itself Mar 19 05:51:21 anujdeshpande: what do you think of the workload i mentioned?, also i think you'll have to write/port codes for easy debugging of the lib functionalities... Mar 19 05:52:20 sidbh: yepp. sounds good. tridge mentioned a test script to check if all the requisite pins are doing their job i.e. set in the right mode, etc. that'll be there in this too I believe Mar 19 05:52:37 shall update the proposal then Mar 19 05:53:08 yep, and also the upcalls and downcalls as panto had done in his testpru example Mar 19 05:54:37 understood Mar 19 05:54:44 i was also thinking that we might've to create a failsafe control loop inside PRU if anything goes berserk Mar 19 05:55:57 i guess you can take this part too, i think LorenzMeier/Kevinh__ will be the best guide on this topic Mar 19 05:58:36 anujdeshpande: what do u think? as per my understanding these all tasks will easily eat up your 3 months of time :) Mar 19 05:59:16 sidbh: makes sense. Mar 19 05:59:34 yepp. loads of smaller, independent tasks that need to be done. Mar 19 07:10:23 vmayoral: ping Mar 19 09:23:18 sidbh: pong Mar 19 09:23:54 vmayoral: you wanted to talk to me about something... Mar 19 09:24:00 yeap Mar 19 09:24:37 got your email yesterday and posted some queries in the BeaglePilot mailing list, i just wonder if "that" mailing list is the one that will be checked by the mentors Mar 19 09:25:42 vmayoral: invites have been sent to all mentors :-) Mar 19 09:26:15 sidbh: great,thank you! just double checking :) Mar 19 09:27:34 sidbh: thanks for updating the BeaglePilot/beaglepilot repo with your timeline, it really helps to get everything in a single table Mar 19 09:28:25 vmayoral: do you know who has setup the logger for this channel? Mar 19 09:28:33 http://logs.nslu2-linux.org/livelogs/beaglepilot Mar 19 09:30:36 sidbh: no, didn't know Mar 19 09:31:27 anyways, nice thing to have web logs for this channel:) Mar 19 09:32:56 i think so, yeap :) Mar 19 09:43:23 sidbh, ds2: i've seen your discussion about using EHRPWM modules against implementing them in the PRU Mar 19 09:45:23 of course the former solution is straightforward and for the time being works perfectly (tested) however i recall having spoken with tridge that implementing PWM in the PRU might allow to have more PWM signals with 1) good timings and 2) configurable characteristics (e.g. different frequencies) Mar 19 09:47:13 kevinh_, tridge: please take a look at https://groups.google.com/forum/#!topic/beaglepilot/apdfrT2fS-8 for some more questions about the driver implementation Mar 19 09:47:26 btw, you can always use the hardware pwm from PRU Mar 19 09:47:30 set it up from linux Mar 19 09:47:41 have the PRU bang the registers to change ratio Mar 19 09:54:07 vmayoral: I guess we can provide both options and leave it to user whichever pwm module he/she want to use Mar 19 09:56:15 vmayoral: ? Mar 19 09:56:57 panto: mmm that's a good point Mar 19 09:57:02 sidbh: sounds good! Mar 19 09:57:58 vmayoral: i guess i missed some discussion... Mar 19 10:00:05 last message i receved was "of course....................(e.g. different frequencies) Mar 19 10:00:08 " Mar 19 10:00:50 sidbh: panto suggested that "you can always use the hardware pwm from PRU, set it up from linux and have the PRU bang the registers to change ratio" Mar 19 10:01:17 so that's probably a third option to take into account Mar 19 10:01:28 you might have to tweak the linux driver a bit but it's not a big deal Mar 19 10:01:59 that part is going to get covered under my work pack Mar 19 10:02:00 the trick is to avoid doing setup from the PRU where code space is at a premium Mar 19 10:03:51 panto: setting up of PWM peripheral from arm and using it from PRU? Mar 19 10:09:49 yes Mar 19 10:09:57 use the linux kernel driver Mar 19 10:10:57 ok Mar 19 10:11:52 brb Mar 19 17:21:59 panto: ping Mar 19 17:29:55 pong Mar 19 18:58:03 panto: RFC http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/anujdeshpande92/5698390809640960 Mar 19 19:03:45 anujdeshpande, k **** ENDING LOGGING AT Thu Mar 20 02:59:58 2014