**** BEGIN LOGGING AT Thu Aug 08 02:59:59 2013
Aug 08 11:26:17 <vvu> av500: ping
Aug 08 12:09:43 <vvu> av500: small ping
Aug 08 12:10:24 <av500> yo
Aug 08 12:10:30 <av500> dont ping, just ask
Aug 08 12:10:34 <av500> its irc
Aug 08 12:10:39 <av500> I can read what you write :)
Aug 08 12:10:42 <av500> even later
Aug 08 12:10:45 <vvu> had time to compile the thingies?
Aug 08 12:10:49 <av500> no
Aug 08 12:11:20 <vvu> some updates when the ramdisk is loaded all 4 leds will be on and not flashing
Aug 08 12:11:41 <vvu> then the image is transferred completely only 2 leds will be on and not flashing.
Aug 08 12:11:54 <vvu> led 1 and 3 if i remmeber right
Aug 08 15:17:37 <mluckham> panto, ping
Aug 08 15:30:37 <anujdeshpande> koen: what 3d printer would you recommend ?
Aug 08 15:31:36 <koen> anujdeshpande: ultimaker if you have the $$$$ or printrbot
Aug 08 15:33:04 <anujdeshpande> koen: google has been very kind :) makerbot not that good ? our local hackerspace was thinking of getting that one..
Aug 08 15:33:27 <koen> makerbot used to be good
Aug 08 15:33:32 <koen> now they are just expensive
Aug 08 15:34:11 <anujdeshpande> koen: i see.. thanks for the tip !
Aug 08 15:36:15 <panto> mluckham, pong
Aug 08 15:42:47 <mluckham> hi, i've been trying some changes to testpru0, testpru1 and have a couple of questions
Aug 08 15:43:00 <panto> ok
Aug 08 15:44:04 <mluckham> in pru0, sc_print(etc) output to dmesg, c_puts outputs to the vring vport0p0
Aug 08 15:44:31 <mluckham> in pru1, sc_puts is there but I cannot find it's output
Aug 08 15:45:16 <panto> sc_print are system calls
Aug 08 15:45:20 <panto> they don't use vrings
Aug 08 15:45:58 <mluckham> that's what i thought (but I couldn't find any documentation about them)
Aug 08 15:46:00 <panto> only PRU0 is using the vring via c_puts
Aug 08 15:46:19 <panto> start chanting... bleeding edge, bleeding edge
Aug 08 15:46:28 <mluckham> oooommmmmm
Aug 08 15:46:37 <panto> trying to port the PRU stuff to 3.11 anyway
Aug 08 15:47:17 <panto> just remember, you don't have to use everything as it is in the testpru stuff
Aug 08 15:47:29 <panto> think of it as a collection of methods
Aug 08 15:47:54 <mluckham> that's right - tools to accomplish something else (JTAG in this case)
Aug 08 15:48:07 <mluckham> so I was looking for a way for pru1 to output debug strings
Aug 08 15:48:53 <panto> that's what sc_puts is for
Aug 08 15:49:08 <mluckham> yes ...
Aug 08 15:49:12 <panto> it works, but, you break realtime
Aug 08 15:49:41 <panto> in a nutshell, don't do stdio from the PRU that you want to do the realtime stuff
Aug 08 15:50:09 <panto> you can use sc_puts for debugging sure, but not during normal operation
Aug 08 15:50:09 <mluckham> right, but just use it for debugging and take it out to debug the next thing
Aug 08 15:51:16 <panto> right
Aug 08 15:51:21 <mluckham> according to my notes, sc_puts on pru1 didn't output anything (that I could find)
Aug 08 15:51:34 <mluckham> i was looking in dmesg
Aug 08 15:52:50 <mluckham> i could see the pin states wiggling, of course
Aug 08 15:54:53 <mluckham> second issue, shutting down the slot # using capemgr seems to work for pru0 but not pru1 - are you working on that?
Aug 08 15:55:15 <mluckham> it would make the debugging cycle go much faster :)
Aug 08 15:57:13 <mluckham> I looked in pru_rproc to see if I could do it ... much more learning needed, I think
Aug 08 16:16:47 <panto> mluckham, sc_puts on pru1 should work too
Aug 08 16:17:29 <panto> there's a problem with shutting down any PRU with an active vring
Aug 08 16:18:42 <mluckham> apologies!  I looked way back in dmesg, sc_puts is working for pru1 - sorry about that!
Aug 08 16:19:18 <mluckham> capemgr calls on pru_rproc when the .dtbo is being loaded, to do the work?
Aug 08 16:20:27 <mluckham> so whatever fix is needed, would be in pru_rproc?
Aug 08 16:20:45 <mluckham> or are there issues in the pru subsystem?
Aug 08 16:21:26 <panto> in pru_rproc
Aug 08 16:22:01 <panto> there's a sysfs attribute that you can use to load new PRU firmware without shutting down anything
Aug 08 16:22:17 <panto> but you'll have to handle the vring
Aug 08 16:22:42 <mluckham> would it be possible to shut down pru1 and reload it, without touching pru0?
Aug 08 16:23:20 <panto> that already works for PRU1
Aug 08 16:24:03 <mluckham> via capemgr?
Aug 08 16:24:26 <panto> no
Aug 08 16:24:33 <panto> it's a pru_rproc sysfs facility
Aug 08 16:24:58 <panto> look for the load attribute
Aug 08 16:25:34 <mluckham> ok
Aug 08 16:26:30 <panto> usage is echo "[0:pru0-fw-name][,1:pru1-fw-name]" >load
Aug 08 16:32:06 <mluckham> oh that's useful, thanks :)
Aug 08 16:32:54 <mluckham> also on my do-very-soon list is to create a new type of device driver, like 'pwm'
Aug 08 16:33:22 <mluckham> but concurrently I need to have a proper JTAG device model - I wish jj2baile was more communicative
Aug 08 16:33:29 <mluckham> it would be a big help
Aug 08 17:01:47 <mluckham> dxf
**** ENDING LOGGING AT Fri Aug 09 02:59:59 2013