**** BEGIN LOGGING AT Mon Dec 21 02:59:59 2015 Dec 21 03:29:48 "SOAP over UDP" .. why do people invent these sorts of things? are they angry at the world? Dec 21 03:35:14 veremit: I don't think you need a video= commandline if the device tree correctly specs the LCD screen Dec 21 07:11:06 to give you the fun of reimplementing tcp for multicast messages on top of it matt Dec 21 07:20:29 they don't, a message is simply required to fit into a datagram Dec 21 07:21:16 fortunately XML is well-known for its conciseness :P Dec 21 08:17:17 and you need to take care of retransmission and stuff like that... Dec 21 11:10:22 Hello here ! Dec 21 11:12:22 I have one question about beagleboard, is that good to use a beagleboard for doing videoprocessing ? Or something like RaspberryPi is good enough ? Dec 21 11:13:09 depends on what kind of processing Dec 21 11:14:07 just detection of colors and obstacles for a robot Dec 21 11:17:58 so we're talking about something like openCV? Dec 21 11:18:38 yes :) Dec 21 11:20:29 then it's just ARM core performance Dec 21 11:22:15 rpi - meh, bbb - better, rpi2 only better if running proper distro (NOT raspbian) Dec 21 11:22:46 bbb has the issue of video input though... usb is your only option, and is meh Dec 21 11:23:28 ok ! Dec 21 11:23:34 thought there was a camera cape once, or did that only work with bbw? Dec 21 11:23:50 maybe it used sdio? Dec 21 11:23:58 bbb/bbw doesn't really matter Dec 21 11:25:01 I've seen on the website that there is a cape for camera Dec 21 11:25:05 no ? Dec 21 11:25:28 http://elinux.org/CircuitCo:BeagleBone_3.1MP_Camera - not sure if that is still available anywhere Dec 21 11:25:54 zmatt: looks like it uses GPMC, as expected Dec 21 11:26:26 I also just found this http://radiumboards.com/HD_Camera_Cape_for_BeagleBone_Black.php but doesn't really say how it interfaces Dec 21 11:26:43 can't be gpmc, sdio still seems like a good possibility Dec 21 11:27:15 huh Dec 21 11:27:35 gpmc... how can they seriously advertise that for bbb Dec 21 11:28:42 ok ! I will see this solutions, so thank you and have a nice day ! Dec 21 12:45:29 i'm thinking about buying a development and testing board to compile/debug/deploy system images for beaglebone black. the purpose is to have more performance while still mantaining the same hardware platform. any suggestion? Dec 21 12:46:32 samael: well you won't have the *same* hardware platform strictly speaking of course Dec 21 12:47:07 I think rcn-ee uses some freescale board Dec 21 12:47:41 zmatt: yep of course (having more performance means different cpu), but i think the same architecture is enough Dec 21 12:49:30 i'll ask him when he'll join, thanks Dec 21 12:49:58 I actually managed to boot up a BBB image on an amd64 system using systemd-nspawn :) with a few critical progs overmounted by their equivalents from the host system and relying on qemu-user for the rest Dec 21 12:50:17 qemu is obviously not going to help with getting better performance though Dec 21 12:51:20 woah.. don't think it's a good solution for deploying production images, but it seems a good excercise indeed :) Dec 21 12:51:51 it yields a really weird "uname -a" though... containing both "amd64" and "armv7l" Dec 21 12:53:02 but if I can get the emulated arm compiler replaced with a native cross-compiler then it might actually be a useful environment for cross-compiling things that normally stubbornly refuse cross-compilation Dec 21 12:54:15 for booting I just needed to overmount systemd and a few of its subsidiary daemons, and some network config utilities (qemu-user doesn't support netlink) Dec 21 12:54:53 of course booting the target system image often isn't strictly necessary, opening up a shell often suffices Dec 21 12:55:22 i'm evaluating also the cross-compiler solution, don't really know if things moved on, but the last time i used them i had hard times configuring the toolchain and all the bells and whistles. i suspect buying some baremetal trick is less headache-prone Dec 21 12:55:54 a faster ARM board is likely to be the easy approach yes Dec 21 12:56:56 although it'll be hard to compete with cross-compilation from a fast x86 system... when it works Dec 21 12:58:54 the beauty of the mixed container is that the cross-compiler would appear to be the native compiler, and the resulting executables can be run, so e.g. configure scripts should work normally Dec 21 12:59:15 but I haven't yet had a chance to try to get it to work :) Dec 21 13:00:17 I'd definitely use cross-compilation for things like the kernel Dec 21 13:00:39 which supports it hassle-free Dec 21 13:07:36 i see. but most of my work is system-oriented, especially tests with external I/O devices; i suspect i'd be much more comfortable with more cpu power over a similar board Dec 21 13:08:00 yes Dec 21 13:08:17 though tests with external I/O are always tricky since they tend to be highly hardware-dependent Dec 21 16:06:10 anyone familiar with using an audio cpae, or stripping audio from BBB comm lines Dec 21 16:16:58 Hello Dec 21 16:20:45 I'm not sure if a Beagleboard Black is overkill, but I want to use it as a portable server. I want to use it as personal firewall, GPS receiver/logger, file server and more. I need to have a very reliable GPS because I have severe spatial issues, Android is ok. Google Maps isn't so good and UnifiedNLP isn't so reliable so I would like to have a better GPS and use all those databases to manage best location without needing Google ( Dec 21 16:24:19 I also want to use a Pebble-like device, TI Chronos seem a great candidate instead those battery draining devices. I also love to be very hackable. Dec 21 16:25:57 In addition to spatial issues, I also have ADHD and anxiety. I'm a buggy human, so I want to monitor myself and take care of time to not get distracted and remember tasks... Dec 21 16:26:37 Current mainstream smartwatches are crap, too much eye candy Dec 21 16:29:03 Item finder, lighting... all this seems a dream for a geek with ADHD ;) Dec 21 16:36:00 zmatt: re: LCD + DT .. well, would hope not. Dec 21 16:36:20 zmatt: SOAP is evul. Check out ONVIF one day if you're bored and .. yea. Dec 21 16:39:22 Good evening! is there any info on how to use PWM on debian 8.2 with 4.1.12-ti-r29? Dec 21 16:39:43 I'm a bit stuck. I got config-pin on the system already and was able to change P9.14 to PWM, but how do I write to it? Dec 21 16:40:05 :...( Dec 21 16:44:13 have you tried rtfm? Dec 21 16:44:15 https://www.kernel.org/doc/Documentation/pwm.txt Dec 21 16:45:51 Im about to rtfm through the wiki of TI, just a bit confused :D Dec 21 16:47:28 hey everyone :) Dec 21 16:47:49 anyone mind saying which style hdmi is for the beagle, I guess it's micro hdmi? Dec 21 17:35:19 tbr: how do I figure out which pwmchip on sysfs is which pin on the beagle? Dec 21 17:43:54 derjanni, http://elinux.org/Beagleboard:Cape_Expansion_Headers Dec 21 18:07:20 nerienna: thanks, but how do I figure out which PIN the sysfs entry /ocp/epwmss@48300000/ehrpwm@48300200 is? Dec 21 18:16:38 two pins, or where do you specify if this is pwm0 or pwm1 of pwmchip 0? Dec 21 18:17:33 I suspect by the time you've configured the device-tree for pwm .. you know which is which .. lol .. Dec 21 18:17:46 unless you can fire up pwm without... Dec 21 18:18:30 I'd say I figured out how to use the PWM kernel interface, I'm just confused on how to identify the PINs Dec 21 18:18:35 a wild guess .. it will/won't show up unless its configured. So you can check whats there before/after. Dec 21 18:19:38 I don't know 4.1, I'm still working with bancient 3.8.13, but I think this adress is only for the epwmss, not for one pwm Dec 21 18:20:43 you can look up the 2 pins for pwmss0 in the cape expansion headers Dec 21 18:20:44 ah 3.8 is probably better documented :) Dec 21 18:21:16 but the register addresses won't be different Dec 21 18:21:21 true Dec 21 18:22:00 and one epwmss will still manage 2 ehrpwms Dec 21 18:22:08 -> 2 pins Dec 21 18:22:18 ah ok. Dec 21 18:22:31 you should be able to do some initial testing with the on-board leds too Dec 21 18:22:39 iirc Dec 21 18:23:07 might be wrong on that though. Dec 21 18:26:32 does someone know, how device tree overlays have to change from 3.8 to 4.1? Dec 21 18:27:05 I dunno if a lot changes in actual content .. just how you compile and load them Dec 21 18:27:43 eg. cape manager is back in 3.8 from a long vacation lol Dec 21 18:27:47 4.1* sorry Dec 21 18:27:52 this guys got it figured out: https://briancode.wordpress.com/2015/01/06/working-with-pwm-on-a-beaglebone-black/ Dec 21 18:27:55 I think it was present in 3.8 Dec 21 18:28:19 derjanni .. I saw that .. wondered about its method. Dec 21 18:28:21 so that's the next thing I will have to learn - how to compile device tree overlays and load them Dec 21 18:28:28 there's always pro's and con's :) Dec 21 18:28:54 and whats weird is that I Dec 21 18:29:03 device-tree compiler .. and .. I dunno lol Dec 21 18:29:16 I've got pwmcip0,2,4,6,7 Dec 21 18:30:09 I already told you that you are trying to do something with pwmchip0 Dec 21 18:31:46 pwmchip7 only has one pwm :\ strange, but I'll follow up the guys site I posted above Dec 21 18:32:38 ooo .. this looks quite simple .. http://www.toptechboy.com/tutorial/beaglebone-black-lesson-6-control-pwm-signals-on-gpio-pins-from-python/ Dec 21 18:33:35 I *really* should do some python coding Dec 21 18:35:36 my husband told me, if I start to learn python, I'd have to look for a new place to live... Dec 21 18:35:47 whoah Dec 21 18:35:50 I'm using c Dec 21 18:36:15 although kudos for the c/c++ approach .. a bit purist these days Dec 21 18:36:40 have to Dec 21 18:36:45 has to be fast Dec 21 18:36:58 ah well thats a fair constraint :) Dec 21 18:37:11 you stickin to the userspace .. or thinking of PRUs ? Dec 21 18:37:50 I think pRU c is a bit more restricted .. although I've programmed in assembly before .. Dec 21 18:37:59 I'm sticking to the userspace, but I only write the test software to teat our hardware Dec 21 18:38:10 righto Dec 21 18:38:12 the programmers will use the PRUs Dec 21 18:38:19 cool Dec 21 18:41:09 defining the positions via switches read by the eqep strobe and GPIOs, reading eQEPs, AINs and set the PWMs Dec 21 18:43:07 servos? Dec 21 19:07:54 you can do a lot from userspace too... but its 40-80 μs interrupt latency (delivered via uio) is of course crap compared to how fast a baremetal application (whether PRU or cortex-a8) can react to things Dec 21 19:08:48 and I still need to patch the kernel to make writes posted instead of non-posted as they are currently :/ Dec 21 19:09:14 (for userspace apps that is, kernelspace drivers already use posted writes) Dec 21 19:20:42 mornin zmatt :P lol Dec 21 19:24:25 USB is not the only way to get video input Dec 21 19:25:16 nor the best Dec 21 19:32:42 veremit, sorry, diner was ready. no servos, but 5 motors. Servos don't need the backfeed from encoders or potentiometers (ains) Dec 21 19:33:10 sometimes they do ;) Dec 21 19:33:25 np though .. cool stuff Dec 21 19:34:05 this whole PWM thing on the beagle is so weird Dec 21 19:34:22 3 big motors controlled by the eQEPs and 2 small ones with potentiometers Dec 21 19:35:17 works nice Dec 21 19:36:40 first time I worked with ARM processors, and now I love them Dec 21 19:38:52 hehe you picked a good 'un with the BBB Dec 21 19:40:50 hmm? Dec 21 19:41:06 the PWM on the BBB is prefectly normal Dec 21 19:41:36 apart from the HR-feature of eHRPWM Dec 21 19:41:58 Also this CapeMgr thing, I'm not getting it. Dec 21 19:42:21 zmatt: but the eQEP... Dec 21 19:42:26 then don't use it, you don't need it unless you want to autodetect capes Dec 21 19:42:38 CapeMgr is an abomination Dec 21 19:42:41 avoid it. Dec 21 19:42:49 zmatt: I reserve RAM and then ioremap it, and this makes it appear at 0xExxxxxxx. The prototype I found for ioremap has no body, but I presume this behaviour is normal, since it's supposed to be doing address virtualization. Does this sound right? Dec 21 19:44:18 arrrrgggggggggg use the drivers#@$#$#!@#!@#!@#@ Dec 21 19:44:28 ds2: lol Dec 21 19:44:41 ds2: what about eQEP ? Dec 21 19:44:45 the pwm interface is insanely easy Dec 21 19:44:58 zmatt: eQEP doesn't have the high rez mode Dec 21 19:45:17 ds2: eQEP has nothing to do with pwm though Dec 21 19:45:31 I know how to use the kernel PWM interface and its absolutely fine, but I have no clue which kernel PWM is on which PIN on the beagle. Dec 21 19:45:38 Trying to figure that out since an hour now Dec 21 19:45:50 derjanni_: https://goo.gl/Jkcg0w Dec 21 19:45:57 let me pull up the trm Dec 21 19:46:11 it is pretty clear Dec 21 19:46:18 there are instances of it, and they should pretty much follow it Dec 21 19:46:25 (except for the start at 1 vs start 0 thing) Dec 21 19:46:27 derjanni_: the P9/P8 tabs are the most useful Dec 21 19:46:41 1-based numbering needs to die Dec 21 19:47:14 zmatt: eCAP. My mistake Dec 21 19:47:48 Ragnorok: sounds fine I think, but I'm no kernel expert Dec 21 19:47:57 Roit toe. Dec 21 19:47:59 Thanks! Dec 21 19:48:18 derjanni: worse case, use the sysfs interface and toggle the pin. watch it on the scope. Dec 21 19:48:21 ds2: eCAP's pwm mode is fairly basic yeah (though still better than that of the timers) Dec 21 19:48:27 then back out hte magic numbers you need Dec 21 19:48:42 lol what Dec 21 19:48:54 zmatt: I find the HR mode quite useful for audio output Dec 21 19:49:05 avoids insanely high base freq's Dec 21 19:49:43 zmatt: thanks! Dec 21 19:49:50 ds2: my issue with HR mode is that the MEP step size isn't documented (they refer to the datasheet, it ain't there of course), and PVT-dependent yet with no obvious way to calibrate it Dec 21 19:50:30 zmatt: a working kernel driver lets one be ignorant that ;) Dec 21 19:50:48 the current C2000 microcontrollers (which is where eHRPWM originally came from) have a more recent version that actually has a calibration mechanism Dec 21 19:51:18 ds2: except it seems likely someone just then picked a number :P Dec 21 19:51:20 zmatt: what was the targeted usecase on the C2000? Dec 21 19:51:52 ds2: euh, dunno off the top of my hat, I think the TRM documents some examples Dec 21 19:52:44 iirc the omap-L137 ds does document a MEP step size, although they also warn it's merely an estimate and actually voltage/temperature-dependent Dec 21 19:52:45 Btw: different topic. Is it true OpenSUSE currently cannot be installed in flash? Dec 21 19:53:30 and the am335x is fabricated on a smaller technology node than the omap-L137 so the number isn't portable Dec 21 19:53:34 zmatt: the way I look at it is, for the apps where I am using PWM, I don't think it needs to be that well defined **** ENDING LOGGING AT Tue Dec 22 02:59:58 2015