**** BEGIN LOGGING AT Mon Jul 18 02:59:58 2016 Jul 18 14:29:53 alexhiam: there? Jul 18 14:31:26 kiran4399: yeah Jul 18 14:31:46 so.. I've been working on the firmware and driver.. Jul 18 14:32:07 alexhiam: the question is.. do you want me to pass the pwm values as an array to the sysfs device? Jul 18 14:33:21 kiran4399: I think ideally it should look like a regular pwm sysfs hierarchy, perhaps using the pwm subsystem Jul 18 14:34:18 alexhiam:but you just need to put the pwm values right?? Jul 18 14:34:34 so I was wondering why make it so complicated.. Jul 18 14:35:01 once the list is passed to sysfs.. it can be parsed in the firmware. Jul 18 14:35:30 well, if you used the pwm subsystem it could create the sysfs entries for you, though it's true that it would be more complicated to implement a full featured pwm driver Jul 18 14:36:20 so yeah, something like a boneblue_servo/ directory with a sysfs entry for each servo would be good (e.g. servo_1, etc.) Jul 18 14:37:53 that interface could take the angle in degrees (0-180), and the driver could convert that into pulse widths before passing the the pru so the firmware doesn't need to do any extra math Jul 18 14:39:56 that make sense? Jul 18 14:41:35 alexhiam: can you tell me how to create 8 such sysfs entries? Jul 18 14:41:44 alexhiam: I mean.. one such approach is.. Jul 18 14:41:51 alexhiam: to declare all the entries.. Jul 18 14:42:17 alexhiam: is there any way to declare 8 entries in a correctly? Jul 18 14:42:25 http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/ Jul 18 14:43:45 ok.. Jul 18 14:43:52 alexhiam: and in the firmware Jul 18 14:43:53 https://github.com/kiran4399/bbb_pru_firmware/blob/master/servo_pru.c#L80 Jul 18 14:44:09 should the gpio contain the global address of the output pin? Jul 18 14:48:19 well, at each time step each pwm channel is either high or low depending on the current position in the cycle and the pulse width setting of each channel, so you could generate a bitmask during each timestep Jul 18 14:48:54 there's only two channels, right? and the other 6 servos are driven from the PWM subsystem? Jul 18 14:57:45 Does anybody know why the logs are not recording? Jul 18 14:57:47 http://logs.nslu2-linux.org/livelogs/beagle-gsoc.txt Jul 18 14:58:33 it restarts every day, the archives are here: http://logs.nslu2-linux.org/livelogs/beagle-gsoc/ Jul 18 14:59:43 alexhiam: ok so.. all the things which you told me would be published tomorrow? Jul 18 15:00:18 no, I see them in the link you gave... Jul 18 15:00:19 alexhiam: because Jul 18 15:00:51 alexhiam: that's wierd.. why I am I not able to see them? Jul 18 15:01:06 ok... sorry.. Jul 18 15:01:07 what do you see? Jul 18 15:01:09 now I got them.. Jul 18 15:01:12 k Jul 18 15:01:18 yeah.. as you were saying Jul 18 15:01:36 6 servo channels would be taken care by pwmss? Jul 18 15:01:39 ?? Jul 18 15:02:10 I assume so, just based on the face that there's two outputs in the original pru firmware Jul 18 15:02:34 labeled A and B Jul 18 15:03:38 then what about the dc motors? Jul 18 15:03:41 soft pwm? Jul 18 15:04:13 good question... Jul 18 15:05:07 k, looks like the 4 eHRPWM outputs are used for the DC motors Jul 18 15:05:59 that's what.. Jul 18 15:06:06 becuase I remember doing them? Jul 18 15:06:07 .. Jul 18 15:08:00 ehrpwm and pwmss are different? Jul 18 15:08:05 alexhiam: ^^ Jul 18 15:08:29 the PWM subsystem includes the eHRPWM and eCAP modules Jul 18 15:08:57 alexhiam: now what is ecap? Jul 18 15:09:00 eCAP doing the other two PWM outputs on the BeagleBone Jul 18 15:09:16 "enhanced capture" iirc Jul 18 15:10:32 alexhiam: why can't we use pru for all the servo ports? Jul 18 15:11:55 looks like it needs to be, not sure why the strawson firmware only does 2... Jul 18 15:12:10 servo 4 isn't on a PRU GPO pin :( Jul 18 15:14:18 alexhiam: so what shall we do? Jul 18 15:16:05 I just emailed jkridner about it, hopefully not too late to change on the blue. For now just ignore it I guess Jul 18 15:20:21 alexhiam: so all servo ports from pru? Jul 18 15:20:41 yeah Jul 18 15:20:58 alwxhiam: can we use ecap module for encoders btw? Jul 18 15:21:16 *alexhiam: Jul 18 15:22:03 oh, lol, I was looking at the encoder firmware! the strawson one does drive all 8 channels Jul 18 15:22:17 eQEP is used for the encoders Jul 18 15:22:39 alexhiam: I am asking about the last one? Jul 18 15:25:24 ahh. that might be possible, but more complicated and the ecap module is already being used by the pwmss driver Jul 18 15:25:41 plus, I doubt it's on ecap pins Jul 18 15:26:55 alexhiam: ok.. Jul 18 15:33:21 alexhiam: btw.. here.. Jul 18 15:33:22 https://github.com/kiran4399/bbb_pru_firmware/blob/master/servo_pru.c#L88 Jul 18 15:34:07 alexhiam: I am not able to send a pulse to a specific pwm port.. Jul 18 15:34:26 alexhiam; I mean let us say that you need to send a 50 hz 50% pulse on port 5 Jul 18 15:34:39 what do you mean? each bit in R30 corresponds to a different pin Jul 18 15:34:51 alexhiam: and then how do you get out of the loop and send another one .. say a 50 hz 20% pulse on port 1? Jul 18 15:38:06 you don't leave the loop - what you want is to have a loop that's running every 'dt' fraction of the period. at every dt step (time through the loop), you know how far along the cycle you are, and clear bits by comparing to their set pulse width Jul 18 15:58:00 kiran4399_: here's some real rough psuedocode: http://pastebin.com/pqswkBy0 Jul 18 15:58:07 * alexhiam goes afk Jul 18 16:30:52 alexhiam: Thanks a lot.. then there is no need of an interrupt I assume? Jul 18 16:54:04 ZeekHuge: how is the code coming along? Jul 18 16:54:15 record any waveforms yet? Jul 18 16:55:11 kiran4399_: you mean for the ARM to interrupt the PRU when it writes a new value? To be safe you might want to have the ARM write new values to a certain location then interrupt the PRU, then the PRU copy those values into a local memory location. That way you know the PRU will never read a value while it's being written by the ARM Jul 18 16:55:55 alexhiam: how do you want me to check the interrupt? Jul 18 16:56:00 alexhiam: polling? Jul 18 16:57:02 well, yeah, the PRU doesn't actually have interrupts. Look at some of the demos Jul 18 16:58:31 e.g. http://git.ti.com/pru-software-support-package/pru-software-support-package/trees/master/examples/am335x/PRU_ARMtoPRU_Interrupt Jul 18 17:05:33 hmmmm Jul 18 17:05:48 p Jul 18 17:09:51 http://processors.wiki.ti.com/index.php/PRU_Interrupt_Controller Jul 18 17:10:46 http://elinux.org/PRUSSv2_Interrupt_Controller Jul 18 17:13:45 "Interrupts" Jul 18 17:14:57 interrupts rain on the realtime parade Jul 18 17:15:44 alexhiam: how do you direct this mask to the appropriate gpio? Jul 18 17:17:18 alexhiam: ok.. so they are all hardwired to the pru r30 register ok.. Jul 18 17:17:20 I got it.. Jul 18 17:17:45 kiran4399: each bit in the mask corresponds to a different pin. e.g. if the 8th and 10th bits are 1, then when __R30 is set to the mask value R30.8 and R30.10 will be set high (which are SVO1 and SVO2) Jul 18 17:19:27 alexhiam: one last question.. what is the codition for halting the pru? Jul 18 17:19:42 alehiam: I mean, until when does the outer loop run? Jul 18 17:19:51 *alexhiam; Jul 18 17:20:19 kiran4399: either forever and just let pru_rproc kill it, or have a flag so the ARM can stop it Jul 18 17:20:49 oi. Jul 18 17:20:51 oi.. Jul 18 17:20:54 ok Jul 18 17:21:44 alexhiam: ok.. regarding topics away from this.. Jul 18 17:22:09 alexhiam: Have you finalized how we should do the documentation? Jul 18 17:23:07 I'd prefer doxygen for api docs Jul 18 17:23:38 then at least a real good README with clear install instructions, and a good set of demo programs Jul 18 17:24:34 ok.. Jul 18 17:25:03 alexhiam: do you want me to push the pru custom kernel driver to the beagleboard kernel repository and send a pull request? Jul 18 17:26:17 that would be nice to upstream once it's complete and cleaned up Jul 18 17:27:08 though I'm not sure the best way to do that when it also depends on a binary for the PRU... Jul 18 17:32:56 alexhiam: yeah.. even I feel the same.. why can't we just do directly from the userspace? Jul 18 17:33:05 alexhiam: using remoteproc? Jul 18 17:34:04 well, the kernel driver is how you create the userspace interface Jul 18 17:34:26 remoteproc gives you a kernel->PRU interface Jul 18 18:55:45 quiet monday **** ENDING LOGGING AT Tue Jul 19 02:59:58 2016