**** BEGIN LOGGING AT Sat Dec 19 02:59:58 2015
Dec 19 03:36:20 <zmatt> yates: labels
Dec 19 03:36:23 <zmatt> yates: local labels
Dec 19 03:38:16 <zmatt> numerical labels are typically used for local labels since they're quite macro-friendly.  they can be defined multiple times: a branch or other instruction that wants to refer to it uses "1f" or "1b" depending on whether it means the first 1: label forwards or backwards in the code
Dec 19 03:38:22 <zmatt> I don't think they're an ARM thing
Dec 19 03:38:28 <zmatt> they're a GNU assembler thing
Dec 19 04:03:26 <yates> oh yeah. not just gnu, i think i saw them on a TI TMS320x24x assembler too.
Dec 19 04:03:27 <yates> thanks
Dec 19 04:07:36 <yates> well, no.
Dec 19 04:08:25 <yates> these are not macros
Dec 19 04:08:35 <zmatt> you can use them outside macros too of course
Dec 19 04:08:43 <zmatt> they're just labels
Dec 19 04:09:01 <zmatt> I use them standard for nearby labels not worthy of a name
Dec 19 04:09:05 <yates> that's awful.
Dec 19 04:09:10 <zmatt> why is that awful?
Dec 19 04:09:23 <yates> freaking just put in a unique label, for criminy sake.
Dec 19 04:09:39 <zmatt> most label names are about as nonsensical as a C comment along the line of
Dec 19 04:09:42 <yates> because you have to then count to find which one?
Dec 19 04:09:45 <zmatt> x += 2;  // add two to x
Dec 19 04:09:47 <zmatt> no
Dec 19 04:09:58 <zmatt> b 1f  always refers to label 1:
Dec 19 04:10:17 <zmatt> the first one you encounter
Dec 19 04:10:27 <zmatt> (if there are multiple
Dec 19 04:10:28 <zmatt> )
Dec 19 04:10:41 <zmatt> though I never reuse label numbers within a function I'm pretty sure
Dec 19 04:11:13 <zmatt> and having to specify the direction of the branch (1b vs 1f) is actually quite descriptive
Dec 19 04:11:31 <yates> are we talking about the same piece of code? http://ur1.ca/ocofd -> http://paste.fedoraproject.org/303050/45049827
Dec 19 04:12:15 <yates> in what universe?
Dec 19 04:12:31 <yates> freaking just tell it THE LABEL. (not the direction or whatever...)
Dec 19 04:12:34 <zmatt> oh ok so I sinned
Dec 19 04:13:11 <zmatt> though only because they're really tiny loops :P  but I'll admit I would normally not do that, I have no idea why I did that there
Dec 19 04:13:22 <zmatt> then again, I would normally never write this in asm anyway
Dec 19 04:13:44 <yates> oh, i forgive you. i don't forgive the assembler writers though. what an awful thing to allow...
Dec 19 04:13:56 <zmatt> not at all, I hate long local label names
Dec 19 04:13:59 <zmatt> I lose overview
Dec 19 04:14:05 <yates> who said they have to be long?
Dec 19 04:14:10 <yates> L1, L2, etc.
Dec 19 04:14:36 <yates> i've just never seen such a thing.
Dec 19 04:14:44 <zmatt> because allowing duplicates is very useful for macros, and disallowing them outside macros would be inconsistent
Dec 19 04:14:50 <zmatt> but also, for me it's a local label
Dec 19 04:14:55 <zmatt> the branch will be very nearby
Dec 19 04:15:01 <zmatt> 1:  yada
Dec 19 04:15:03 <zmatt>    bne  1b
Dec 19 04:15:09 <zmatt> is a pattern I instantly recognize
Dec 19 04:15:24 <zmatt> (regardless of the actual label number)
Dec 19 04:15:25 <yates> for macros you can use "L?
Dec 19 04:15:32 <yates> for macros you can use "L?".
Dec 19 04:15:40 <zmatt> yeah I know there is some mechanism
Dec 19 04:15:45 <yates> let the assembler replace the ?
Dec 19 04:15:55 <yates> that's what the TI assembler does.
Dec 19 04:15:59 <zmatt> I didn't think it was that straightforward in gcc
Dec 19 04:16:23 <zmatt> also, I appreciate a bit cleanliness in the symbol table
Dec 19 04:16:25 <yates> ok, well cool. i guess i learnt sumtum
Dec 19 04:16:29 <yates> sumtin
Dec 19 04:16:46 <zmatt> I should at least have inserted a newline though
Dec 19 04:16:50 <zmatt> between the two blocks
Dec 19 04:17:04 <yates> you're fine.
Dec 19 04:17:06 <zmatt> well, and used different label numbers
Dec 19 04:17:15 <yates> it's really that it is even allowed that gets me.
Dec 19 04:17:27 <zmatt> no that I fully understand
Dec 19 04:17:36 <zmatt> using generated labels in macros is much trickier
Dec 19 04:17:48 <zmatt> like, I now have two instances of waiting for a module to become ready
Dec 19 04:17:48 <yates> trickier for whom? the assembler writer?
Dec 19 04:17:52 <zmatt> that's asking for a macro
Dec 19 04:18:10 <yates> the writer of the assembler program, that is.
Dec 19 04:18:22 <zmatt> you could just copy/paste those three lines into a macro, make the register offset a macro argument, and you're done
Dec 19 04:18:38 <zmatt> I agree local labels ought to be unique within a function
Dec 19 04:18:47 <zmatt> and I'll push a patch later to fix that
Dec 19 04:19:31 <yates> this looks so much cleaner to me: http://paste.fedoraproject.org/303053/04987521
Dec 19 04:20:12 <zmatt> not to me, I see lots more noise making it harder to read
Dec 19 04:20:22 <zmatt> the label name is also duplicative with the comment
Dec 19 04:20:30 <zmatt> like I said....   x += 2;  // add 2 to x
Dec 19 04:21:05 <yates> well, i guess you like redheads and i like blonds...
Dec 19 04:21:05 <zmatt> btw, do that labels continue to exist in the symbol table?
Dec 19 04:21:08 <zmatt> yeah
Dec 19 04:21:15 <zmatt> it's probably also just what you're used to
Dec 19 04:21:17 <yates> i don't remember.
Dec 19 04:21:38 <yates> zmatt: no, i think it's a matter of principle. labels should be unique.
Dec 19 04:21:53 <yates> that seems clearer to me.
Dec 19 04:21:59 <zmatt> symbols should be unique
Dec 19 04:22:18 <zmatt> local labels are not deserving of becoming symbols to begin with
Dec 19 04:22:22 <yates> indeed, that was required in all assembly code i've written for 35 years..., until now...
Dec 19 04:22:42 <zmatt> I don't want a frickin' label for every silly little 3-line loop
Dec 19 04:22:54 <zmatt> but
Dec 19 04:22:58 <zmatt> matter of taste :
Dec 19 04:22:59 <zmatt> :)
Dec 19 04:23:15 <zmatt> *frickin' symbol
Dec 19 04:23:28 <yates> in most of the assemblers, these things won't be "exposed" unless you make them ".public" or somesuch (declare at the top of the file).
Dec 19 04:23:53 <yates> most of the assemblers i've used, i.e.
Dec 19 04:23:55 <zmatt> prepare for horror with gnu asm
Dec 19 04:24:35 <zmatt> iirc some symbols are automatically local based on naming scheme, all other symbols -- if not declared otherwise -- are global
Dec 19 04:25:05 <zmatt> this horror goes far beyond just the assembler
Dec 19 04:25:25 <yates> by the way, are you (i.e., gnumake) actually using a separate assembler for these? or does gcc automagically go into assember mode when it sees a .S input file?
Dec 19 04:25:56 <yates> i guess i could run the make and see...
Dec 19 04:25:57 <zmatt> make uses a different invocation to allow a different choice of flags
Dec 19 04:26:05 <zmatt> but gcc recognized it anyway
Dec 19 04:26:50 <yates> zmatt: that's crazy.
Dec 19 04:26:57 <zmatt> if you need to specify it manually (e.g. when compiling stdin) you need to pass e.g.   -x assembler-with-cpp
Dec 19 04:27:10 <zmatt> why? TI's compiler does the same
Dec 19 04:27:19 <zmatt> every compiler I know looks at the file suffix
Dec 19 04:27:30 <yates> no, i mean about the "automatically global" thing
Dec 19 04:27:34 <zmatt> oh yes
Dec 19 04:27:43 <zmatt> but like I said, it gets worse, hold on
Dec 19 04:27:54 <yates> pimple-faced compiler writers...
Dec 19 04:28:01 <zmatt> ABI designers
Dec 19 04:28:16 <zmatt> though on embedded systems you're spared the worst since you don't have shared objects
Dec 19 04:28:55 <yates> yeah
Dec 19 04:30:04 <yates> did you notice that the Micron DDR3L DRAM used on the BBB is capable of running at 800 MHz but the am335x EMIF can only go up to a max of 400 MHz?
Dec 19 04:30:59 <yates> 800 MHz, 1600 MT/s
Dec 19 04:31:37 <yates> it'll work..
Dec 19 04:31:52 <zmatt> yes, not unusual... memory controllers of embedded systems aren't quite anywhere near PC ram speeds
Dec 19 04:32:00 <zmatt> actually you need to be careful with that
Dec 19 04:32:57 <yates> why, nuclear war may ensue if you run at the wrong clock speed?
Dec 19 04:33:13 <yates> or magic smoke?
Dec 19 04:33:19 <yates> :)
Dec 19 04:33:46 <zmatt> it's not a linear ordering
Dec 19 04:34:18 <yates> you mean it's not a true metric space? :)
Dec 19 04:34:21 <zmatt> but hold on, I was still showing you the symbol thing
Dec 19 04:34:34 <zmatt> point is JEDEC defines specific classes
Dec 19 04:34:56 <yates> go ahead - i stay logged in - but i have to go in a minute.
Dec 19 04:35:20 <zmatt> do stay logged in, disappearing halfway a sentence is annoying... when will you be back?
Dec 19 04:35:27 <zmatt> I actually gotto do some stuff first too
Dec 19 04:35:37 <yates> probably not until tomorrow morning. it's 11:30pm here
Dec 19 04:35:41 <yates> EST
Dec 19 04:36:15 <yates> question: what editor do you use?
Dec 19 04:36:22 <yates> just curious.
Dec 19 04:36:56 <zmatt> https://docs.google.com/spreadsheets/d/13UBY1PXElPrd8bldaBXN-_bWHXSzUKWU8LmyfYDv2mE/pubhtml   <--  DDR3 bins (labeled in first column) and some subtle variations between them
Dec 19 04:37:09 <zmatt> and the actual latencies you need to configure if you run them at lower then max speed
Dec 19 04:38:22 <zmatt> like 1333H might downgrade to 1066G or 1066F
Dec 19 04:38:52 <zmatt> 1066F might downgrade to 800E or 800D
Dec 19 04:39:08 <zmatt> which is the case should be listed in the datasheet
Dec 19 04:39:13 <yates> what are the alphabetic suffixes about?
Dec 19 04:39:19 <yates> what's an 800"E"?
Dec 19 04:39:21 <zmatt> latency
Dec 19 04:39:29 <zmatt> cas latency
Dec 19 04:39:51 <yates> these are parameters i have to set up in the EMIF?
Dec 19 04:41:02 <yates> sorry if that's a stupid question: i haven't gotten too far yet.
Dec 19 04:41:43 <zmatt> like DDR-1333H is more commonly known as "DDR-1333 9-9-9"
Dec 19 04:41:51 <zmatt> for PC enthausiasts
Dec 19 04:42:31 <zmatt> like DDR3-1333G (sorry forgot the 3 earlier) would be "DDR3-1333 8-8-8"
Dec 19 04:43:18 <zmatt> the JEDEC standard speed bins always have the same value for those three numbers btw (cas latency, ras-cas delay, row precharge)
Dec 19 04:43:29 <yates> where did you get this table from?
Dec 19 04:43:49 <zmatt> and yeah you need to program that, but since they're standard bins you can just grab the emif config from some existing location like u-boot
Dec 19 04:44:14 <zmatt> especially since you're close to the BBB anyway
Dec 19 04:44:24 <zmatt> made it by summarizing the docs
Dec 19 04:44:27 <yates> exact same memory
Dec 19 04:44:39 <zmatt> yeah the memory doesn't matter anyway
Dec 19 04:44:45 <yates> but the layout is way different
Dec 19 04:44:45 <zmatt> your timings are limited by the memory controller
Dec 19 04:44:50 <zmatt> uh oh
Dec 19 04:45:08 <yates> it's i think a 6 layer board, and bbb is what, 10?
Dec 19 04:45:13 <yates> for one..
Dec 19 04:45:23 <zmatt> your hw designers have done ddr3 layouts before?
Dec 19 04:45:44 <zmatt> I have no idea, I didn't think it was that many...
Dec 19 04:45:53 <yates> i queried about the 20 pages of layout guidelines and was assured they knew what they were doing.
Dec 19 04:46:10 <yates> they have done DDR before, i am sure
Dec 19 04:46:17 <zmatt> DDR != DDR3
Dec 19 04:46:26 <zmatt> beaglebone is 6-layer
Dec 19 04:46:40 <yates> oh?
Dec 19 04:47:08 <zmatt> https://e2e.ti.com/support/arm/sitara_arm/f/791/p/407051/1442741#1442741
Dec 19 04:47:10 <yates> still, i know they didn't just copied the layout of the BBB
Dec 19 04:48:01 <zmatt> the BBB didn't look quite perfectly according to the rules either when I briefly looked at it (I'm not really a pcb person, I just can't use those programs)
Dec 19 04:48:05 <zmatt> but
Dec 19 04:48:09 <zmatt> it's a single RAM chip
Dec 19 04:48:15 <zmatt> all signals are point-to-point
Dec 19 04:48:17 <zmatt> no branching
Dec 19 04:48:23 <yates> right.
Dec 19 04:48:29 <yates> you don't have several banks.
Dec 19 04:48:36 <zmatt> *ranks
Dec 19 04:48:43 <zmatt> ddr3 always has 8 banks
Dec 19 04:48:50 <zmatt> but that's internal in the chip
Dec 19 04:48:51 <yates> yeah, whatever the term is.
Dec 19 04:49:09 <zmatt> well banks and ranks are kinda similar (in name and meaning)
Dec 19 04:49:54 <zmatt> except banks are integrated in the RAM controller and have no electrical impact
Dec 19 04:50:13 <yates> is this uboot ddr3 configuration file a C source code file or something else?
Dec 19 04:50:20 <zmatt> GEL probably
Dec 19 04:50:35 <yates> GEL?!? Like what Code Composer Studio uses?
Dec 19 04:50:38 <zmatt> oh
Dec 19 04:50:40 <zmatt> uboot
Dec 19 04:50:42 <zmatt> sorry
Dec 19 04:50:47 <zmatt> wasn't paying attention
Dec 19 04:50:53 <zmatt> u-boot is all C
Dec 19 04:50:54 <yates> np
Dec 19 04:51:27 <zmatt> I gave you quite recently a pastebin link that already gathers most of the info
Dec 19 04:52:01 <yates> you mean the google docs spreadsheet? yes, i guess i'd just like to see the setups in uboot too.
Dec 19 04:52:03 <zmatt> (the subroutines and constants involved, gathered from all other the source tree)
Dec 19 04:52:07 <zmatt> no a pastebin
Dec 19 04:52:20 <yates> you did that tonight ?
Dec 19 04:52:22 <zmatt> no
Dec 19 04:52:40 <zmatt> I can check logs if you want
Dec 19 04:52:56 <yates> sure.
Dec 19 04:53:03 <yates> that would certainly be useful.
Dec 19 04:53:28 <zmatt> or you can even, #beagle ends up on the web anyway, but I can probably find it faster :P
Dec 19 04:54:09 <yates> i accidently lost a session we had a few weeks ago - might've been in that.
Dec 19 04:54:14 <zmatt> oh, found the link
Dec 19 04:54:30 <yates> <drum roll, please>
Dec 19 04:54:37 <zmatt> but for some reason I must have selected some stupid expiry
Dec 19 04:55:43 <zmatt> I can reconstruct it later easily, but I really need to pay attention to other stuff first ... so you'll probably see it later.    can I ask you a quick question though
Dec 19 04:55:58 <yates> sure
Dec 19 04:56:53 <zmatt> are you guys doing anything in pro-audio?  I briefly looked at your site and it didn't look like it, but was just wondering
Dec 19 04:57:17 <yates> "you guys" is me.. :)
Dec 19 04:57:25 <zmatt> heh
Dec 19 04:57:26 <yates> no, not currently.
Dec 19 04:57:51 <zmatt> ok, since my boss would probably not be happy with me if I'd turn out to be giving free help to a competitor ;)
Dec 19 04:58:17 <yates> do you know Al Clark, or Robert Bristow-Johnson?
Dec 19 04:58:32 <yates> they are my buddies, and THEY do pro-audio!
Dec 19 04:58:46 <yates> Robert used to work at Aphex.
Dec 19 04:58:52 <yates> and Kurzweil
Dec 19 04:59:16 <yates> i've done audio, but not PRO audio..
Dec 19 04:59:20 <yates> amateur?
Dec 19 04:59:29 <zmatt> I'm not really deeply into the world at all myself, my background is not in audio (pro or otherwise) at all
Dec 19 04:59:38 <yates> ok, gotta go now - wife is calling. talk to you soon, matt.
Dec 19 06:08:24 <Shaunak> hey there
Dec 19 06:08:29 <Shaunak> hey there
Dec 19 15:24:42 <Abhishek_> rcn-ee ping again
Dec 19 15:25:06 * GenTooMan tosses a few pongs out for fun.
Dec 19 15:25:27 <veremit> rcn will likely be back  monday
Dec 19 15:25:44 <Abhishek_> posted anyway
Dec 19 15:26:08 <Abhishek_> BTW, anyone tried qemu-static on a beagleboard stock image?
Dec 19 15:50:58 <GenTooMan> not I
Dec 19 16:26:51 <jamesaxl> hi
Dec 19 16:28:11 <jamesaxl> is there away to compile arm without using eclipse and remote session
Dec 19 16:29:21 <jamesaxl> i am using C++
Dec 19 16:31:31 <GenTooMan> you mean use a cross compiler on your linux desktop?
Dec 19 16:33:13 <GenTooMan> yes
Dec 19 17:50:03 <adugenske> Trying to install the latest Debian OS on my BBB. http://beagleboard.org/latest-images says to edit the /boot/uEnv.txt file on the Linux partition on the microSD card. But there is no /boot on the result SD image. Any help?
Dec 19 17:53:11 <tbr> adugenske: you mounted the card with linux?
Dec 19 17:53:45 <adugenske> <tbr>Doing it from Windows 7
Dec 19 17:53:56 <tbr> right, that won't work
Dec 19 17:54:13 <veremit> why?!
Dec 19 17:54:26 <veremit> just d/l the image .. write tu uSD, go.
Dec 19 17:54:34 <veremit> such old instructions :/
Dec 19 17:55:10 <tbr> you could boot the image, and edit it from within
Dec 19 17:55:32 <tbr> or look for a flasher image
Dec 19 17:56:07 <veremit> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2015-11-03
Dec 19 17:57:29 <tbr> yup
Dec 19 17:57:42 <adugenske> <veremit>Thanks for the link to the flasher image. I'm surprised it isn't more prominate on bb.org
Dec 19 17:58:43 <veremit> We need a BBB documentation project. Elinux is good .. but not enough points to it .. so it doesn't get ranked highly in google :/
Dec 19 17:59:00 <jsmith> veremit: I couldn't agree more...
Dec 19 17:59:02 <veremit> you gotta really know what you're looking for .. which is hard for newbies
Dec 19 17:59:25 <jsmith> veremit: Same goes for the green, x15, etc. :-p
Dec 19 17:59:36 <adugenske> So I plan to flash the SD with BBB Rev C/BBG (4GB eMMC) and then load to eMMC on BBB. Good plan?
Dec 19 17:59:58 <veremit> adugenske .. the 'flasher' images will boot and write the emmc
Dec 19 18:00:25 <veremit> best way imo, unless you have reason to disable emmc or do testing
Dec 19 18:00:43 <adugenske> I like the emmc.
Dec 19 18:00:53 <veremit> jsmith .. fortunately due to RN's efforts .. we have a common image for all am335x boards
Dec 19 18:01:29 <jsmith> veremit: Oh, will that same image work on the x15?  See... I didn't know that, because I didn't see it documented anywhere :-p
Dec 19 18:01:36 <adugenske> I'll flash the SD, place SD in BBB, reboot BBB, wait, then done. Typical op?
Dec 19 18:03:02 <veremit> adugenske.. yup. You should see all leds on or off .. can't remember which
Dec 19 18:03:23 <veremit> jsmith .. no there are separate x15 images .. same site .. bit further down .. http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2015-11-03
Dec 19 18:04:57 <jsmith> veremit: Maybe that's my problem -- I wasn't looking on the BBB page for x15 images :-p
Dec 19 18:05:50 <veremit> jsmith .. yeah dunno how they got filed there .. lol
Dec 19 18:06:17 <veremit> either there, or for Any ARM board .. check out RN's personal site at eewiki.net
Dec 19 18:06:22 <jsmith> veremit: I followed the instructions here https://eewiki.net/display/linuxonarm/BeagleBoard-X15
Dec 19 18:06:29 <veremit> yup all good ^^
Dec 19 18:06:51 <veremit> depends whether you need ready-built or roll-your-own
Dec 19 18:11:24 <adugenske> Sorry to be noob, but what's the diff between lxde and console flashers?
Dec 19 18:15:41 <veremit> lxde is a desktop environment
Dec 19 18:15:50 <veremit> console is just a shell / command-line
Dec 19 18:25:34 <adugenske> Thanks
Dec 19 18:58:59 <adugenske> I just flashed my BBB with BBB-eMMC-flasher-debian-7.9-lxde-4gb-armhf-2015-11-03-4gb. The BBB shows-up as a storage device, but can't ping it at 192.168.7.2. Any thoughts?
Dec 19 19:01:27 <tbr> adugenske: is this the first boot?
Dec 19 19:01:41 <adugenske> Yes
Dec 19 19:05:43 <tbr> then wait a while, then possibly reboot
Dec 19 19:05:54 <tbr> did the usb cdc acm device come up?
Dec 19 19:06:53 <adugenske> What's the usb cdd acm?
Dec 19 19:07:13 <tbr> a serial device that you can connect a terminal client to
Dec 19 19:07:30 <tbr> probably will show up as COM?:
Dec 19 19:09:15 <adugenske> No sure, where would this showup in windows?
Dec 19 19:30:07 <tbr> well, just power cycle it
Dec 19 19:42:17 <adugenske> <tbr>I got the serial connection working to the BBB
Dec 19 19:43:25 <tbr> ok
Dec 19 19:44:18 <tbr> that gives you direct login to the board
Dec 19 19:46:17 <tbr> if you are still on first boot, just issue a reboot for starters
Dec 19 19:46:23 <tbr> that might fix the network
Dec 19 19:47:14 <adugenske> I'm connecting via putty, but can't enter anything (only receive output).
Dec 19 19:52:44 <adugenske> <tbr>I noticed the serial prompt is changing /-\ which I'm guessing is progress.
Dec 19 21:08:36 <veremit> turn flow control off .. lol
Dec 20 01:24:23 <M51> Hello. I am looking for a board to use for an upcoming project. Is all the firmware on the BeagleBone Black open source, or does it have closed bits like Raspberry Pi?
Dec 20 01:25:06 <M51> I need something that can run a linux-libre kernel and use only open video drivers.
Dec 20 01:37:24 <veremit> M51.. as long as you don't need video acceleration you're good
Dec 20 01:40:01 <GenTooMan> veremit the code for the EGL on the gfx is not open source right?
Dec 20 01:40:15 <veremit> iirc yes GenTooMan
Dec 20 01:40:31 <veremit> so .. framebuffer is fine :)
Dec 20 01:41:59 <M51> ok, cool. Thanks!
Dec 20 01:52:18 <GenTooMan> so no 3d acel (unfortunately) but the FB is fast enough for most stuff.
Dec 20 01:52:34 <veremit> I say get sgx .. f* it
Dec 20 01:52:46 <veremit> my ideology isn't so strict :D
Dec 20 01:55:14 <michaila> Hello, I am currently working on a project which performs face, eyes and mouth detection from camera input. This application is really slow on beagleboard xm running ubuntu 12.04 with opencv. I am trying to find ways to fasten up the performance. I am reading something about dsp. Will it help me? Does anyone have an idea?
Dec 20 01:55:44 <veremit> heh I'm not surprised
Dec 20 01:57:57 <veremit> http://elinux.org/BeagleBoard/DSP_Howto
Dec 20 01:59:25 <veremit> http://beagleboard.org/project/opencv+acceleration/
Dec 20 02:01:17 <veremit> Ah the xm has a different processor .. with the dsp core ..
Dec 20 02:01:20 <veremit> didn't know this
Dec 20 02:02:53 <GenTooMan> veremit and that thing has other "strange" things (IP for the DSP to decode MPEG2)
Dec 20 02:03:13 <michaila> I know nothing about dsp or how to use it. I have already seen all these sites. Do you believe it will worth the try? Will it help me with what I am trying?
Dec 20 02:04:10 <veremit> however .. http://wiredsoup.blogspot.co.uk/2013/04/the-mystery-of-opencv-and-beagleboard-xm.html
Dec 20 02:04:28 <veremit> GenTooMan .. the xm? quite possibly
Dec 20 02:05:37 <GenTooMan> actual project https://github.com/jadonk/opencv-dsp-acceleration
Dec 20 02:07:01 <veremit> mhmm
Dec 20 02:07:18 <veremit> if it were me, I'd seriously ditch the beagleboard .. its never going to have enough grunt for real-time
Dec 20 02:07:44 <veremit> you need something with dedicated dsp hardware for video processing
Dec 20 02:07:56 <veremit> or a LOT of cpu to make up for it
Dec 20 02:08:28 <veremit> there are no shortcuts for heavy processing like that, amd arm processors really weren't designed for it
Dec 20 02:08:33 <veremit> and*
Dec 20 02:09:22 <michaila> Thank you for your replies. I will consider using something else.
Dec 20 02:09:24 <veremit> you're talking about doing a *lot* of math ..
Dec 20 02:09:34 <veremit> a *lot* of math very quickly!
Dec 20 02:10:51 <michaila> I know. This is my thesis and my professor gave me beagleboard xm without considering the needs I have.
Dec 20 02:13:27 <veremit> interesting stuff in opencv though .. http://docs.opencv.org/2.4/modules/contrib/doc/facerec/facerec_tutorial.html
Dec 20 02:18:06 <GenTooMan> how about the apteva micro supercomputer?
Dec 20 02:18:41 <GenTooMan> aka parallela
Dec 20 02:19:33 <GenTooMan> http://www.parallella.org/
Dec 20 02:19:55 <veremit> ah I was just lookin at the fusion stick
Dec 20 02:20:09 <GenTooMan> I have one :D
Dec 20 02:20:30 <GenTooMan> It does come with a big heat sink and you will want to use a fan on it.
Dec 20 02:20:53 <veremit> GenTooMan .. interesting :)
Dec 20 02:21:00 <GenTooMan> it has 2 ARM15 cores and 16 openCL compatible cores
Dec 20 02:21:26 <michaila> Thank you for your suggestions. I will ask to change board.
Dec 20 02:21:52 <GenTooMan> the neat thing about that is it comes on an FPGA so you can reprogram IO as needed.
Dec 20 02:27:55 <veremit> that said .. allegedly the XM does have a digital video chip ..
Dec 20 02:28:10 <veremit> just whether the dsp core has enough to do the processing .. I see f** all on google ..
Dec 20 02:28:33 <veremit> I just chceked the revC2 bom.
Dec 20 02:28:48 <veremit> It's the DM3730
Dec 20 02:29:04 <veremit> so its got a tms320dm64x dsp .. apparently.
Dec 20 02:29:48 <GenTooMan> hrmmm 6000 series requires the TI compiler :P
Dec 20 02:30:16 <GenTooMan> CC Studio has a size limit for it in the free license don't remember what it is.
Dec 20 02:31:42 <veremit> grr feckin google
Dec 20 02:31:51 <veremit> right I gotta sleep .. 'nother long day tomorrow
Dec 20 02:31:56 <veremit> nite folks I-)
Dec 20 02:32:23 <michaila> goodnight and thanks again
Dec 20 02:32:56 <veremit> where there's a will ... ^^
Dec 20 02:32:59 <GenTooMan> I believe you should gander at the parallela as a number of people have used it. You do need to get the right one.
Dec 20 02:33:00 * veremit wafts into the night
**** ENDING LOGGING AT Sun Dec 20 02:59:59 2015