**** BEGIN LOGGING AT Sat Jun 14 02:59:58 2014
Jun 14 03:46:27 <zmatt> i2s is sort of like spi, but for audio
Jun 14 03:47:36 <zmatt> dogrocket: I've never seen the labels "din" or "dout" being used for I2S to be honest
Jun 14 03:49:01 <zmatt> then again, the chips I've worked with were either ADCs or DACs, not combined, hence usually the pin is just called "DATA" or such since the direction is obvious
Jun 14 03:49:30 <zmatt> on the am335x side every data pin is software-configurable as either input or output
Jun 14 03:51:13 <zmatt> oh wait, *which* "beagle" ?
Jun 14 03:51:59 <zmatt> (I assumed beaglebone, but just noticed you didn't mention that anywhere)
Jun 14 04:01:04 <dogrocket> its beaglebone black,  actually im using the pin outs for the audiocape,  and the audiocape names them as such
Jun 14 04:01:39 <dogrocket> but yes i2s bidirectional uses din dout
Jun 14 04:02:20 <veremit> you could be sampling and coding audio at same time .. think mic/headphones
Jun 14 04:02:37 <zmatt> veremit: that would use separate data lines
Jun 14 04:02:56 <veremit> hence din/dout :)
Jun 14 04:03:01 <dogrocket> yep.. but essentially you can veremit
Jun 14 04:03:19 <dogrocket> audio cape can do that
Jun 14 04:03:24 <veremit> at high data rate you can do it half-duplex
Jun 14 04:03:33 <veremit> since audio is low bandwidth
Jun 14 04:04:00 <dogrocket> well id like to use them both if i have them. :)
Jun 14 04:04:08 <veremit> sure :)
Jun 14 04:04:35 * veremit wonders what interface is used on the wand codec ...
Jun 14 04:05:08 <zmatt> dogrocket: I'm looking at the "audio cape" schematic but it seems to have its own codec and just analog i/o... I don't see any "DIN/DOUT" pins
Jun 14 04:06:42 <dogrocket> oh boy
Jun 14 04:07:19 <dogrocket> http://elinux.org/Beagleboard:BeagleBone_Audio
Jun 14 04:07:28 <veremit> yeah its i2s as well
Jun 14 04:07:58 <veremit> din/dout and 2 clocks
Jun 14 04:08:06 <veremit> no make that 3
Jun 14 04:08:12 <veremit> and i2c control
Jun 14 04:09:39 <zmatt> hm, what the hell is that third clock
Jun 14 04:09:45 <dogrocket> yep...  the clock confused me, dont know if thats for external clock or internal
Jun 14 04:10:25 <veremit> two output and one input on my schems
Jun 14 04:10:35 <veremit> one is frame sync?
Jun 14 04:10:50 <zmatt> bclk is the data clock, wclk the frame sync
Jun 14 04:10:53 <veremit> oh wait .. wrong way
Jun 14 04:10:55 <zmatt> I think
Jun 14 04:11:04 <dogrocket> mclck and blclk,   they are multiples of sampling rate i think
Jun 14 04:11:19 <zmatt> oh right
Jun 14 04:11:41 <zmatt> sorry I was confused for a sec because they called the frame sync a clock
Jun 14 04:12:00 <veremit> yeah my mistake .. misinterpreting pin / signal names
Jun 14 04:12:16 <zmatt> but yeah two clocks (system/master/highspeed clock mclk and bit clock bclk) + frame sync ("wclk")
Jun 14 04:12:23 <veremit> codec in front of my says "lrclk/sclk on the i2s, sys_mclk"
Jun 14 04:12:39 <zmatt> sclk = mclk, lrclk = wclk
Jun 14 04:13:02 <zmatt> at least, I think I've seen the highspeed clock also called sclk in places
Jun 14 04:13:10 <dogrocket> im think aud_fsx is another name for lrclk,  and i think that means left / right clock,  in other words it tells reciever when left channel or right channel is to be sent... but could be wrong
Jun 14 04:13:11 <zmatt> (isn't standardized terminology great)
Jun 14 04:13:20 <zmatt> fsx is framesync yes
Jun 14 04:13:21 <veremit> yea
Jun 14 04:13:30 <dogrocket> they dont name any of this crap the same.. dumb, really dumb
Jun 14 04:13:30 <zmatt> specifically, frame sync transmitted by the McASP
Jun 14 04:13:45 <veremit> I got "txfs" on the wand and TxC and just plain audio_clk lol
Jun 14 04:14:43 <dogrocket> heh... new ones to me
Jun 14 04:15:34 <zmatt> dogrocket: btw, you linked to the rev A cape... I was on the rev B cape page which notes as changes "compatibility with the BeagleBone Black"
Jun 14 04:15:38 <dogrocket> so what i was figuring and i could be way wrong, was hook up my codec the same as the audiocape,
Jun 14 04:16:02 <dogrocket> oh... and you notice they actually rename pin outs too.. lol
Jun 14 04:16:32 <veremit> lol its all fun, isn't it?! :D
Jun 14 04:16:50 <dogrocket> because the platform or machine driver would probably have same pin outs as the ti codec thats built into some kernels..
Jun 14 04:17:14 <zmatt> of course, which pin you need on the BBB probably also depends on whether you want to run the codec as master or slave
Jun 14 04:17:24 <dogrocket> right...
Jun 14 04:17:36 <veremit> does it matter?
Jun 14 04:17:39 <veremit> master/slave?
Jun 14 04:17:42 <dogrocket> i gotta read on audio cape some more see what it uses
Jun 14 04:17:55 <dogrocket> yeah.. one or other.. cant be same
Jun 14 04:18:08 <veremit> well duh
Jun 14 04:18:20 <veremit> surely its more important when you have more than one device :)
Jun 14 04:18:24 <zmatt> veremit: well, it matters in that you need different pins on the McASP ;)  and not all audio chips support the same settings for both
Jun 14 04:18:30 <veremit> ahh
Jun 14 04:20:47 <dogrocket> mines a maxim98089 codec... shoulda stayed with the ti3xxx series
Jun 14 04:21:12 <dogrocket> but maxim has the drivers for the alsa-soc that ti3xxx uses
Jun 14 04:21:31 <zmatt> actually, hold on... fsx might actually mean "frame sync for transmit section" rather than "frame sync transmit"
Jun 14 04:21:35 <veremit> sgma5000 on the wand :P lol
Jun 14 04:22:07 <zmatt> yeah it does, my bad
Jun 14 04:22:18 <zmatt> so those are programmable in/out too
Jun 14 04:22:33 <zmatt> so connections are the same regardless of whether the codec is master or slave
Jun 14 04:22:38 <veremit> d you need a firmware blob for the beagle?
Jun 14 04:22:39 <zmatt> just config
Jun 14 04:22:57 <zmatt> I think the audio cape just used a device tree overlay
Jun 14 04:23:19 <veremit> mm spose that makes sense
Jun 14 04:23:45 <dogrocket> i thought they used the alsa-soc drivers um am335x_soc  or something like that,  ties into alsa
Jun 14 04:24:10 <veremit> oh it all ties into alsa :P
Jun 14 04:24:19 <veremit> or its completely useless :D
Jun 14 04:24:28 <dogrocket> but theres hardly any instructions on audio cape anywhere on net,
Jun 14 04:24:51 <dogrocket> well its got the completely useless part down good so far :P
Jun 14 04:25:01 <veremit> lol
Jun 14 04:25:46 <zmatt> hmm, for revB they say "Audio Cape uses the same audio signal from the onboard HDMI interface"
Jun 14 04:26:21 <dogrocket> yep... you have to kill hdmi audio for it to work
Jun 14 04:26:25 <veremit> yeah you gotta watch the hdmi gotcha
Jun 14 04:27:18 <dogrocket> i think i just realized something,  the maxim has a separate clock pin in another location, labeled xtal or mclk!
Jun 14 04:27:31 <zmatt> that's the ahclk
Jun 14 04:28:06 <dogrocket> that one should go to mclck pinout labeled on cape then
Jun 14 04:28:42 <zmatt> I'm still not sure what you're doing with that cape if you're connecting your own codec
Jun 14 04:29:06 <zmatt> you can't connect two codecs simultaneously to the same pins obviously
Jun 14 04:29:38 <dogrocket> just referencing the pin outs, these are supposed to be pin outs assigned in device tree i guess
Jun 14 04:30:02 <dogrocket> doesnt really matter what codec as long as you use same pinouts i think
Jun 14 04:30:26 <dogrocket> then you load a module specific to codec operation,  which maxim made
Jun 14 04:31:52 <dogrocket> the ti codec normally comes compiled into kernel from robert i think, its so audio cape is plug and pray
Jun 14 04:31:53 <zmatt> I'm not sure I can be of more help here... I'm familiar with McASP and I2S, but not really with stuff like the pinouts on the BBB or how all this is made to work under linux
Jun 14 04:32:25 <dogrocket> thanks zmatt
Jun 14 04:32:54 <zmatt> np
Jun 14 04:33:12 <dogrocket> well who should do master clock im wondering. whoevers got the fastest clock i guess
Jun 14 04:34:24 <zmatt> master clock is normally always provided by the cpu
Jun 14 04:34:56 <zmatt> unless you have some special external clock circuit e.g. to synchronize to some external clock source
Jun 14 04:35:33 <zmatt> (and it's not really a case of "fastest", it needs to have a specific frequency)
Jun 14 04:36:27 <dogrocket> AudioCape: The codec interfaces with the Multichannel Audio Serial Port of
Jun 14 04:36:28 <dogrocket> the AM335x via audio serial bus
Jun 14 04:36:51 <dogrocket> i think mcasp only comes out on those pins
Jun 14 04:38:35 <zmatt> well, am335x has two McASPs actually, and can be muxed between various pins
Jun 14 04:38:39 <zmatt> (see SRM)
Jun 14 04:39:39 <dogrocket> ah, i think the second one is harder to work with for some reason
Jun 14 04:39:40 <zmatt> but the pin the audio cape (rev B) is using as mclk is (in mode 0) mcasp0_ahclkx
Jun 14 04:40:01 <dogrocket> thats externel clock i think
Jun 14 04:40:02 <zmatt> which means the BBB generates the master clock
Jun 14 04:40:18 <dogrocket> oh
Jun 14 04:40:40 <dogrocket> heh.. this stuff is like learning greek.
Jun 14 04:41:12 <zmatt> oh crap I made the same mistaken thought... it could actually receive a master clock instead
Jun 14 04:41:27 <dogrocket> The digital audio data transfer is clocked by a bit clock (BCLK) received from the
Jun 14 04:41:27 <dogrocket> AM335x.
Jun 14 04:42:00 <dogrocket> thats not mclk thought
Jun 14 04:42:02 <dogrocket> though
Jun 14 04:42:05 <zmatt> no
Jun 14 04:42:08 <zmatt> mclk is
Jun 14 04:42:15 <zmatt> mclk is much much higher rate
Jun 14 04:44:06 <zmatt> normally something like 256 * sample rate
Jun 14 04:44:42 <veremit> should be the codec master clock .. surely
Jun 14 04:44:54 <zmatt> though the codec they put on the rev B audio cape is apparently quite flexible... it even has an integrated PLL
Jun 14 04:44:59 <veremit> it has to be synced to the sampling clocks though
Jun 14 04:45:40 <zmatt> normally yes
Jun 14 04:46:17 <zmatt> (this is the first time I've seen a codec with a PLL inside, which pretty much invalidates all the rules)
Jun 14 04:46:35 <veremit> lol oh well :) there's exceptions to Every rule ..
Jun 14 04:46:59 <zmatt> it accepts mclk anywhere from 512 kHz to 50 MHz
Jun 14 04:47:51 <zmatt> in that case you'd want the codec to be master though
Jun 14 04:48:26 <zmatt> (since if bclk has no fixed relationship to mclk, there'd be no other way for McASP to stay synchronized with the codec)
Jun 14 04:50:01 <dogrocket> ok, will make maxim mclk, and i think it can be varied, but thought its standard was 13mhz
Jun 14 04:50:02 <zmatt> but yeah, that's unusual... normally mclk ensures the synchronization of all components and bclk is some divided clock thereof (and fs/lrclk is bclk divided by 2 * number of bits transferred per channel)
Jun 14 04:52:10 <zmatt> 13 ? that sounds wrong
Jun 14 04:52:11 <dogrocket> maxim: If an external
Jun 14 04:52:11 <dogrocket> audio source is used, choose either the on-board 13MHz
Jun 14 04:52:11 <dogrocket> oscillator or an external clock. To
Jun 14 04:52:23 <zmatt> hmmz
Jun 14 04:52:57 <zmatt> what sample rate and resolution were you planning to use?
Jun 14 04:54:07 <zmatt> like normally I'd expect some non-round number, like 12.288 MHz
Jun 14 04:54:23 <zmatt> (= 256 * 48 kHz)
Jun 14 04:56:03 <dogrocket> 48000 would be highest
Jun 14 04:56:06 <zmatt> and then e.g. bclk = mclk/4 for 2 channels * 32 bits * 48 kHz
Jun 14 04:56:17 <zmatt> or /8 for 16 bits / channel
Jun 14 04:56:23 <dogrocket> 16 bits
Jun 14 04:59:03 <dogrocket> i must be doing math wrong...
Jun 14 04:59:17 <zmatt> or me, I kinda should have gotten some sleep by now
Jun 14 05:00:08 <dogrocket> heh... well it looks like you might be right, they are using device dtree  and may not be related to the alsa am35xx drivers...
Jun 14 05:00:37 <dogrocket> i will get on alsa-soc chat tomorrow, maybe someone will be awake
Jun 14 05:00:39 <zmatt> I wouldn't expect the mcasp driver to be am335x-specific
Jun 14 05:00:46 <dogrocket> thanks for help though
Jun 14 05:00:47 <zmatt> it's on tons of TI SoCs
Jun 14 05:01:14 <zmatt> np
Jun 14 05:01:43 <dogrocket> alsa-soc uses davinci drivers and other stuff its confusing, but supposedly thats what i should use
Jun 14 05:02:43 <zmatt> yeah I think the linux mcasp driver is called davinci-mcasp for some reason
Jun 14 05:03:47 <dogrocket> CONFIG_SOC_AM33XX=y
Jun 14 05:04:04 <zmatt> sure, but that's not audio related I'd think?
Jun 14 05:04:12 <dogrocket> theres the beagle or evm specific alsa_soc driver yep
Jun 14 05:04:35 <dogrocket> theres an soc driver for video but its called something different
Jun 14 05:04:50 <zmatt> huh... ok well like I said I'm not really familiar with how they did things in linux
Jun 14 05:05:13 <zmatt> (I'm doing baremetal programming on a TI SoC myself)
Jun 14 05:06:14 <Aston> I need some help with the ADC. When i do the python adc read on the cloud9 IDE it works. But when i write the same code to a py file and execute in terminal, it gives me an error saying it cannot do the ADC setup. Im running a 3.8 kernel and debian(REV C)
Jun 14 05:06:26 <dogrocket> oh.. crap,  that was wrong one, here it is
Jun 14 05:06:31 <dogrocket> CONFIG_SND_SOC=y
Jun 14 05:06:31 <dogrocket> CONFIG_SND_AM33XX_SOC=y
Jun 14 05:06:48 <dogrocket> that previous might have been the video one
Jun 14 05:08:15 <dogrocket> think im tired too.. :P
Jun 14 05:10:05 <zmatt> yeah, gonna get some sleep, and maybe tomorrow have another go at filling in that horrible DDR3 ram configuration spreadsheet from TI to get the ram on our board up&running
Jun 14 05:13:01 <treeherder> hey, i did a little writeup about expanding my rootfs, anybody care to provide criticism? https://gist.github.com/treeherder/34830497fa90c1b5eaea
Jun 14 06:39:38 <Guest91216> Hi. I'm looking for a fix for network instability in Beaglebone Black: https://groups.google.com/forum/#!topic/beagleboard/Vp4pxwHm8BU
Jun 14 06:40:03 <Guest91216> I have 2 of them and this issue makes both pretty much unusable
Jun 14 06:43:26 <Guest91216> Is the root cause of this known by now or is it still a mistery?
Jun 14 06:57:24 <tbr> Guest91216: are you the original reporter of that issue?
Jun 14 07:36:09 <treeherder> Guest91216, have you tried implementing a software watchdog
Jun 14 07:36:32 <treeherder> also i've yet to experience this glitch
Jun 14 07:36:45 <treeherder> haven't had my BBB more than a few months
Jun 14 07:36:53 <treeherder> but it's plugged into the internet nonstop
Jun 14 07:47:41 <Dip> Hello!
Jun 14 07:47:52 <Dip> This is Dip and I need a small help
Jun 14 07:48:36 <Dip> I am having LM35 Temperature sensor and I'd like to get reading from BBB over analog pins
Jun 14 07:48:43 <Dip> Can someone help?
Jun 14 07:48:57 <Dip> Mine BBB is running with Ubutnu 12.04 LTS
Jun 14 14:55:17 <dogrocket> anyone know what name is of i2c module for bbb?
Jun 14 15:06:25 <aleandros> Question here: the power led button is not working, and I believe it is because someone (not me, I swear!) connected 24V to a GPIO pin. Would that be enough for trashing the entire board? or that would just damage that pin?
Jun 14 15:17:40 <Guest91216> tbr, No, I'm not the original reporter
Jun 14 15:18:35 <Guest91216> treeherder, SW watchdog will not help since only hard reset fixes it
Jun 14 15:23:55 <tbr> Guest91216: then you should tell us more about your setup, how you power the devices, what you have connected, etc
Jun 14 15:24:59 <xenoxaos> aleandros: wow.....i think it may be time to get a new one....and/or contact someone at circuitco to see if it can be repaired
Jun 14 15:27:17 <Defiant> dogrocket: you found the answer?
Jun 14 15:34:14 <dogrocket> Defiant: nope im clueless
Jun 14 15:35:47 <Defiant> dogrocket: its probably compiled in, have you updated your ddevicetree?
Jun 14 16:09:56 <dogrocket> Defiant: im trying to hook up a codec to bbb, i was just wanting to see if codec responded to i2c commands because from what ive read sometime one needs pullup resisters to communicate
Jun 14 16:10:54 <Defiant> what kind of codec? And i2c always needs pullup resistors
Jun 14 16:17:12 <dogrocket> its a maxim98089
Jun 14 16:19:28 <dogrocket> its said one can use either the maxim98088 or maxim98090 alsa-soc drivers for the 89 just rename them
Jun 14 16:21:02 <dogrocket> datasheets.maximintegrated.com/en/ds/MAX98089EVKIT_WLP.pdf
Jun 14 16:21:07 <Defiant> uhm that one looks complicated. What is you plan with this?
Jun 14 16:21:40 <dogrocket> yep... want all the sound input and eq and mixing capabilities... it is complicated.. :P
Jun 14 16:22:33 <dogrocket> its probably one of most compilcated ones out there that actually has alsa-soc drivers im thinking
Jun 14 16:24:40 <dogrocket> wishing there were better docs for setting up alsa-soc drivers.
Jun 14 16:36:51 <aleandros> Hi people!
Jun 14 16:41:58 <vvu> hello there
Jun 14 18:47:03 <nate`> aloha
Jun 14 18:47:36 <nate`> Figure I might as well fire off a quick question, I'm sure other persons have attempted this.
Jun 14 18:48:17 <nate`> Doing a "car" computer.  Gonna replace the standard 1 unit size stereo and the cubby below it with a TFT, based on my measurements this should work: http://elinux.org/Beagleboard:BeagleBone_LCD7 anyone use it before in this sort of application?
Jun 14 18:49:18 <nate`> Figured if I had to make a mux for 3.5mm inputs to an output for my radios/scanner, why not just tear everything out of that portion of the console :p
Jun 14 18:50:10 <nate`> Also just starting my research on what to get before I go hogwild with random parts like I did with my pi project.
Jun 14 18:51:53 <nate`> Other thing I haven't been able to find, something for FM reception.
Jun 14 18:53:03 <Abhishek_> nate`: Do you think that the cheap TEA5767 modules available on eBay by 2-3$ a piece could fit your bill?
Jun 14 18:53:52 <nate`> I could probably get that wired in along with the aidafruit ultimate gps
Jun 14 18:54:36 <nate`> and still figure out a way for wifi along with possibly an accelermeter along with camera and audio recording (can't trust cops ya knwo)
Jun 14 18:55:04 <nate`> I'm more of a software person than hardware person.  I know enough to get things built with hardware but not enough to do "true" designs.
Jun 14 18:56:21 <nate`> Thing about the FM is i'd like my touch screen to do the tuning, don't really have room for more analog controls, my MUX switches are eating up the last bit of space by replacing my ash tray.
Jun 14 18:56:57 <nate`> by the way this is an old vehicle from '88 :p
Jun 14 19:08:10 <nate`> RTL2832 & R820T look stupid promising.
Jun 14 21:53:50 <pjustice> that lcd's brightness is 350 cd/m^2
Jun 14 21:53:59 <pjustice> you probably want 1000 or more for daylight readability in a vehicle
Jun 15 00:34:52 <nate`> pjustice: have a better LCD out there than the one I'm looking at then?  I do have tinted everything though.
Jun 15 00:35:43 <pjustice> when I was looking for displays for vehicle use, there seemed to be too dim and too expensive :)
Jun 15 00:36:02 <nate`> what's "too expensive?"
Jun 15 00:39:30 <pjustice> upwards of USD700
Jun 15 00:39:48 <nate`> The one I'm looking at I think will do the trick.
Jun 15 00:39:59 <pjustice> there _may_ be some transflective stuff that would be readable and cheaper
Jun 15 00:40:03 <nate`> It may be cheap but I can easily hack it with a brighter LED if need be.
Jun 15 00:40:20 <nate`> I also need to build a custom case for it which can include a screen cover when I get to that stage.
Jun 15 00:40:47 <pjustice> loooots of stuff is sold as "daylight readable" or "sunlight readable" that's like 300 cd, and gets reviews of "not daylight readable at all"
Jun 15 00:41:07 <pjustice> main thing is that you know about the issue
Jun 15 00:41:36 <nate`> Well unless it's eInk I doubt I'm gonna get a perfect view on anything.
Jun 15 00:41:54 <nate`> every tablet i've had's main issue has been sunlight.
Jun 15 00:42:25 <nate`> same for my laptops
Jun 15 00:43:29 <treeherder> can one buy eink screens?
Jun 15 00:43:40 <treeherder> breakout modules or something
Jun 15 00:43:45 <nate`> Do have that TFT, a beagle, the ultimate GPS, and that radio dongle coming in the mail.  Gonna start there inside the home
Jun 15 00:44:13 <nate`> maybe not in the 7" range but there's always this: http://www.seeedstudio.com/depot/204-EInk-Display-Shield-p-1374.html :p
Jun 15 00:44:21 <nate`> crap, that's discontinued
Jun 15 00:44:36 <improvnerd> Adafruit has a couple of options: https://www.adafruit.com/categories/150
Jun 15 00:44:45 <nate`> but there are a few out there
Jun 15 00:45:03 <nate`> not sure how well eInk would be for navit
Jun 15 00:46:35 <veremit> you need a high brightness tft .. they exist
Jun 15 00:47:07 <nate`> inside my 4runner I don't need sunglasses because of the polarized tint
Jun 15 00:47:35 <improvnerd> What are the requirements for this display?  I missed them.
Jun 15 00:47:47 <nate`> 7" either by 4" or 6"
Jun 15 00:47:57 <nate`> if it's 6" then I just gotta cut some plastic from my center console.
Jun 15 00:48:03 <nate`> once I find a replacement one ;)
Jun 15 00:48:17 <nate`> Those are also rough estimates done with a tape measure
Jun 15 00:48:34 <nate`> Could go smaller if I build a frame for it
Jun 15 00:48:39 <veremit> was trying out one of the chalk electronics ones .. touch screen .. high res .. very good actually for the $$
Jun 15 00:49:15 <nate`> all it needs to do is output radio signals, change channels and do GPS for the first round.
Jun 15 00:49:21 <nate`> So it doesn't need to be anything horribly fancy.
Jun 15 00:49:38 <nate`> well radio signals/mp3s
Jun 15 00:49:43 <nate`> don't give a shit about movies.
Jun 15 00:49:49 <nate`> too busy driving a 4x4 for that
Jun 15 00:50:53 <nate`> also probably a good idea to have AUX input for the analog MUX i'm building for my CB, HAM and Scanner.  That way I can route either through my small radio amplifier and still listen to music or switch to just the sound system incase of emergencies.
Jun 15 00:51:44 <improvnerd> nate: How about an iPad mini?
Jun 15 00:52:15 <nate`> not a fan of iOS.
Jun 15 00:52:26 <improvnerd> Phablet then?
Jun 15 00:52:49 <nate`> this is also a permanent installation, having an iPad installed in the console means some crack head will break a window and tear out a console that I have to hunt down in junk yards
Jun 15 00:53:31 <nate`> I'll get a picture of what the console looks like for reference tomorrow.
Jun 15 00:53:38 <nate`> It's too dark to get a good one at the moment.
Jun 15 00:55:30 <nate`> in all honesty I'd much rather build things with power tools ;)
Jun 15 00:55:40 <nate`> or using my forge and anvil.
Jun 15 01:01:55 <ds2> EPDs are nice if it iwasn't for the update rate
Jun 15 01:02:27 <ds2> TR displays are superior to any high brightness normal displays
Jun 15 01:06:41 <nate`> One thing I know, this is definitely not my EMP proof vehicle heh.
Jun 15 01:13:36 <Neo_> Does anyone know why I do not have omap as in /sys/devices/platfom/omap     ?  (I am using bealge bone black rev C debian distro)
Jun 15 01:34:40 <thurgood> probably because bbb is not an omap
Jun 15 01:48:31 <improvnerd> thurgood, so BeagleBoard was, but BeagleBone isn't?
Jun 15 01:59:52 <thurgood> beaglebone are am335x
Jun 15 02:02:40 <improvnerd> Those are definitely six alphanumeric characters.
Jun 15 02:03:43 <thurgood> it's the processor family
Jun 15 02:09:18 <treeherder> i've got a very noob question
Jun 15 02:09:29 <treeherder> are the GPIO of the BBB directly from the ARM processor?
Jun 15 02:09:56 <treeherder> or is there some other mcu
Jun 15 02:10:01 <treeherder> i guess i should just google this
Jun 15 02:14:14 <myself> did you check the SRM?
Jun 15 02:32:13 <treeherder> ys, i did vcheck the reference but it's not made explicit
Jun 15 02:35:06 <myself> schematic
Jun 15 02:35:33 <treeherder> do you have a link to that?
Jun 15 02:36:04 <musufu> search for
Jun 15 02:36:07 <musufu> "BBB SRM"
Jun 15 02:36:16 <treeherder> i have that ocument open
Jun 15 02:37:03 <musufu> and for your question "are the GPIO of the BBB directly from the ARM processor?"
Jun 15 02:37:05 <treeherder> found i
Jun 15 02:37:05 <treeherder> t
Jun 15 02:37:32 <musufu> none of them coming directly from the processor, but I understand your question and the answer is yes.
Jun 15 02:37:48 <treeherder> ok thank you
Jun 15 02:37:59 <treeherder> my question is really about speed and aavailable resources
**** ENDING LOGGING AT Sun Jun 15 02:59:58 2014