• [00:33:43] * prpplague (n=dave123_@ppp-70-244-160-94.dsl.rcsntx.swbell.net) has joined #beagle
  • [00:34:11] * prpplague (n=dave123_@ppp-70-244-160-94.dsl.rcsntx.swbell.net) Quit ()
  • [01:18:33] * RogerMonk (n=a0740758@nat/ti/x-20cf113b13e321a5) has joined #beagle
  • [02:16:46] * RogerMonk (n=a0740758@nat/ti/x-20cf113b13e321a5) Quit (Remote closed the connection)
  • [03:53:56] * jkridner (n=jason@c-76-31-18-64.hsd1.tx.comcast.net) Quit (kubrick.freenode.net irc.freenode.net)
  • [03:55:41] * jkridner (n=jason@c-76-31-18-64.hsd1.tx.comcast.net) has joined #beagle
  • [03:55:44] <jkridner> that was strange
  • [04:06:23] <Zeta_RHI1> So I've been reading the channel over the past few days trying to get a handle on how we go about programming the beagle board in general and I'm a touch lost...
  • [04:07:00] <Zeta_RHI1> (I'm new to the embedded linux crowd, being the main thing)
  • [04:08:22] <Zeta_RHI1> I'm from the group that's been talking about the robotics project that'd use the board as it's core processing unit, fyi
  • [04:11:01] <Zeta_RHI1> We've a team member currently working with the dm642 board and I have some experience with linux in general, but I'm not quite understanding how the "toolchain" for this device works
  • [04:13:34] <Zeta_RHI1> You mentioned before that the codec engine is how you interface with the DSP core, but is that something that's compiled into a standard program, or is it something more?
  • [04:16:38] <BThompson> its built into a standard program, but you build a little differently
  • [04:17:13] <BThompson> if you do a keyword search for codec engine on the ti site you will find a few documents covering the various parts of codec engine development
  • [04:17:20] * Zeta_RHI1 nods
  • [04:18:23] <BThompson> i imagine that it is what we will eventually use for the OMAP, but at this point I am not sure we are offering support outside of the cortex A8, there might be another more direct method of communicating with the DSP...
  • [04:18:36] <BThompson> something called dsp link or dsp bridge, which is what sits under codec engine
  • [04:18:54] * Zeta_RHI1 nods
  • [04:19:53] <Zeta_RHI1> I've been looking at the documentation, and it's very complete... I was just trying to figure out how to use it with respect to a normal c program and got lost in the documentation, basically
  • [04:20:41] <Zeta_RHI1> We're looking to have a USB webcam image processed by the DSP core and then the results interpreted into motor control via the A8, in summary
  • [04:21:17] <Zeta_RHI1> I was also wondering what driver support with respect to cameras was currently available on that kernel in the repos
  • [04:23:26] <BThompson> From a beagle board perspective you are looking at using some sort of USB webcam for capture I believe, I do not know of any existing driver software for that though, it is still kind of early
  • [04:23:51] * Zeta_RHI1 nods
  • [04:24:05] <BThompson> if the OMAP devices do end up using codec engine, there will probably be an example which runs a example codec on the DSP, so you would have a c file that does the calls to codec engine to load things, and a c file that is actually run on the DSP
  • [04:24:08] <Zeta_RHI1> We were thinking a USB webcam from the beginning
  • [04:24:29] <Zeta_RHI1> That's exactly what we're looking for :)
  • [04:25:01] <BThompson> i know of such examples for other ARM devices (Davinci) however this is all still in development for the OMAP3
  • [04:26:26] * Zeta_RHI1 nods
  • [04:26:39] <Zeta_RHI1> Any idea on a timeframe on something like that?
  • [04:27:21] <Zeta_RHI1> Or at the very least, on the portability of code generated for the dm642 boards to that c64x core?
  • [04:27:26] <BThompson> not that I have, jkridner may have some idea on that
  • [04:27:27] <Zeta_RHI1> As I recall, it's the same core
  • [04:27:39] <BThompson> its an updated core, but it is binary compatible
  • [04:28:02] <BThompson> if you have C you can rebuild to get the new features of the C64x+
  • [04:28:26] <jkridner> you got my attention, but now i have to catch-up
  • [04:28:35] <Zeta_RHI1> Excellent on both counts :)
  • [04:28:56] <Zeta_RHI1> thank you for the assist, by the way
  • [04:29:10] <BThompson> the big change in software will be working out the communication with the ARM, so putting your code into some sort of framework
  • [04:29:19] <Zeta_RHI1> I have to say, we're rather excited about the capabilities of this board
  • [04:29:28] <Zeta_RHI1> Indeed
  • [04:29:31] <BThompson> but you should be able to keep any libraries you have verbatim if you wanted
  • [04:30:02] <Zeta_RHI1> You just made our image processing specialist very happy :)
  • [04:30:15] <jkridner> ah, the DM642 code will run on the OMAP3 C64x+ core.
  • [04:30:51] <jkridner> the best way to make the algorithms portable is to write them as xDM and xDAIS compliant
  • [04:30:51] <BThompson> jkridner: the question I cant answer is when we will have any code that utilizes the C64x+ on the omap
  • [04:31:09] <BThompson> im not sure if/when codec engine will be on it
  • [04:31:47] <jkridner> I believe we've announced availability in 3Q08.
  • [04:32:14] <jkridner> We will have codec engine support. That is known.
  • [04:32:45] <BThompson> i think that covers it
  • [04:35:38] <Zeta_RHI1> That sounds good as far as our timetable is concerned, I think.
  • [04:36:27] <Zeta_RHI1> We could probably even help test the initial revisions if that'd be of assistance
  • [04:38:53] <Zeta_RHI1> We're looking for an early November completion date on our project, so the sooner we get something to attack on the processing side, the better
  • [04:40:53] <Zeta_RHI1> Well, that's good enough for now... we'll get cranking on our code for both modules and write it in such a way as to hopefully be compatible with the codec engine once it's functional
  • [04:40:59] <Zeta_RHI1> Thank you :)
  • [05:13:43] * BThompson (n=BThompso@cpe-76-183-86-15.tx.res.rr.com) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [10:48:32] * RogerMonk (n=a0740758@nat/ti/x-875e3bc8fd7deadd) has joined #beagle
  • [11:32:25] * DarrenEtheridge (n=a0867391@nat/ti/x-4b3c8c892003c0d4) has joined #beagle
  • [13:16:04] * Crofton (n=balister@206.196.151.254) has joined #beagle
  • [13:19:45] * prpplague (n=dave@mail.americanmicrosystems.com) has joined #beagle
  • [13:41:33] * Crofton (n=balister@206.196.151.254) Quit ("Leaving")
  • [13:59:55] * BThompson (n=BThompso@nat/ti/x-e1ec0eb629660ccb) has joined #beagle
  • [14:59:38] * travisutk (n=travis@mil.engr.utk.edu) has joined #beagle
  • [15:22:43] * JoeBorn (n=rootmeis@cpe-66-1-5-91.il.sprintbbd.net) Quit ("afk a few hours")
  • [17:10:58] * travisutk (n=travis@mil.engr.utk.edu) Quit (Remote closed the connection)
  • [17:11:09] * travisutk (n=travis@mil.engr.utk.edu) has joined #beagle
  • [17:11:36] <prpplague> jkridner: ping
  • [17:11:43] <jkridner> yes?
  • [17:12:33] <jkridner> My IRC client is pretty good at recognizing the ping and getting my attention.
  • [17:13:17] * jkridner is going back to working on my taxes.
  • [17:13:34] <prpplague> jkridner: ugh taxes
  • [17:13:41] <jkridner> indeed.
  • [17:14:05] <jkridner> I needed to take a couple of days off to straighten up my office and get through them.
  • [17:14:11] <prpplague> jkridner: if the flyswatter works out for you, will it be the jtag dongle you'll recommend for the beagle? or will you guys do your own design later?
  • [17:14:28] <jkridner> It is hard to concentrate on them when I know I have some code here waiting to run on this board.
  • [17:14:40] <prpplague> jkridner: indeed
  • [17:14:58] <jkridner> TI has several JTAG solutions, but BeagleBoard.org can be used to promote all options.
  • [17:15:35] <jkridner> I'm open to feedback from the folks on the IRC and the mailing list on what should be promoted as option #1.
  • [17:15:46] <jkridner> actually trying it out would make a difference.
  • [17:16:18] <jkridner> currently, I use a Spectrum Digital XDS510USBPlus with Code Composer Studio 3.3 SR8.
  • [17:16:28] <prpplague> jkridner: yea, boss is amicable(sp?) to sending you one, i just needed to give him an idea if it was going to be something long term for sales
  • [17:16:58] <jkridner> BeagleBoard.org is open for editing, if you read the discussion group and understand how to do the editing.
  • [17:17:11] <jkridner> I'm open to folks promoting their products that work with Beagle.
  • [17:17:51] <jkridner> I think most of us can recognize shameless plugs from useful targeting.
  • [17:18:25] <jkridner> the cheaper the JTAG solution, the more interesting it is to me.
  • [17:18:38] <jkridner> Also, having support for kernel-aware debug is critical.
  • [17:19:02] <jkridner> For Beagle, I'd think that a lot of high-end features aren't all that attractive.
  • [17:19:12] <jkridner> but, stability is critical.
  • [17:19:26] <jkridner> keep it simple, make sure it works.
  • [17:20:05] <jkridner> I'll be happy to get in touch with the right guys inside TI to get the secret to putting the Cortex-A8 in the scan chain, but I cannot promise any timeframes.
  • [17:20:31] <jkridner> having a unit helps.
  • [17:20:41] <prpplague> understood
  • [17:20:47] <jkridner> and, I have no idea how well Beagle will sell.
  • [17:21:20] <jkridner> I mean, I have some confidence points, but I don't know the upper bound.
  • [17:21:38] <prpplague> indeed
  • [17:21:42] <jkridner> I might know that better once we start taking orders. I'm reluctant to take pre-orders.
  • [17:21:55] <prpplague> yea we were reluctant as well
  • [17:24:46] * jkridner is off to lunch
  • [17:25:00] <prpplague> jkridner: later
  • [17:26:19] * dirk2 (n=dirk@F33bd.f.strato-dslnet.de) has joined #beagle
  • [17:26:39] <prpplague> dirk2: greetings
  • [17:27:53] <dirk2> promoting flyswatter: http://elinux.org/BeagleBoard#JTAG does it already :)
  • [17:29:06] <prpplague> hehe
  • [17:29:17] <prpplague> dirk2: yea i was just talking to jkridner about it
  • [17:29:29] <DarrenEtheridge> $49.95 is a great price for a JTAG
  • [17:29:40] <dirk2> yes, read the log before joining ;)
  • [17:29:59] <prpplague> dirk2: ahh
  • [17:30:15] <prpplague> DarrenEtheridge: indeed as it also adds a serial port as well
  • [17:30:27] <DarrenEtheridge> how good is the OpenOCD debugger - I have not used that one?
  • [17:31:47] <prpplague> DarrenEtheridge: well we use it pretty much exclusively for our arm7 and arm9 system bringups and debugging, as well as in a hacked fashion to do mass flash programming
  • [17:31:51] <DarrenEtheridge> does it enable JTAG based Linux kernel debug, and user app debug?
  • [17:32:09] <dirk2> Don't know, never used it. But I read somewhere that it is good e.g. for inital flash writing via JTAG and some debugging. But this source said that a "professional" JTAG tool is faster (?)
  • [17:32:32] <DarrenEtheridge> yeah but professional usually == expensive
  • [17:33:04] <dirk2> yes
  • [17:33:14] <prpplague> we mainly use it for user land app debugging
  • [17:33:29] <prpplague> i also use it for debugging bootloader type stuff and initial board bringups
  • [17:33:33] <prpplague> as to the flashing
  • [17:33:58] <DarrenEtheridge> $50 is the right price point for the average Joe to buy for use at home - to turn Beagle into a cool appliance
  • [17:34:00] <prpplague> professional jtag devices are faster, but the cost is very high
  • [17:34:29] <prpplague> we can take 10 flyswatters and plug them into one pc, and have ten copies of openocd running flash scripts
  • [17:35:14] <DarrenEtheridge> i like it
  • [17:35:15] <prpplague> we can erase 128MB flash, program the bootloader, 2 kernels, 2 initrds, and a jffs2 partition for 10 boards in about 6 minutes
  • [17:54:39] * travisutk (n=travis@mil.engr.utk.edu) Quit ("Leaving")
  • [17:57:13] * DarrenEtheridge (n=a0867391@nat/ti/x-4b3c8c892003c0d4) has left #beagle
  • [18:26:35] <dirk2> Regarding other OMAP3 boards: I'd like to add a link to "OMAP35x Evaluation Module (EVM)" http://focus.ti.com/docs/toolsw/folders/print/tmdxevm3503.html to BeagleBoard wiki http://elinux.org/BeagleBoard#Other_OMAP_boards. But I wonder if this is a different board or if it is identical with EVM from Mistral which is already linked there?
  • [18:28:17] <dirk2> Mistral calls their board "OMAP???35x EVM", too...
  • [18:28:29] * DarrenEtheridge (n=a0867391@nat/ti/x-a4c6ddb9a9c89546) has joined #beagle
  • [18:28:35] <jkridner> they are the same board.
  • [18:29:15] <dirk2> Ah, same name, same board ;)
  • [18:29:19] <jkridner> I guess they could come with different software sets. I wasn't aware that Mistral was selling the board themselves as an OMAP35x board.
  • [18:30:04] <jkridner> the kernel patch provided on the Mistral site might be of interest to those who purchase the TI OMAP35x EVM.
  • [18:30:29] <dirk2> For download you need login :(
  • [18:30:37] <prpplague> yea i mean to ask about that, i see OMAP35x and then i also see OMAP35xx
  • [18:30:53] <jkridner> :(
  • [18:30:58] <prpplague> is that two seperate SoC's or is there some typo going on?
  • [18:31:04] <jkridner> typo.
  • [18:31:28] <jkridner> OMAP35x is "right", yet the devices are OMAP3503, etc.
  • [18:31:46] <ds2> is the 3530 complete identical to the 3430?
  • [18:31:59] <prpplague> ok so the series is refered to as OMAP35x then?
  • [18:32:58] <jkridner> the OMAP3530 is offered in a reduced different package and does not support some wireless-specific peripherals.
  • [18:33:22] <jkridner> the "correct" way to refer to the series, as I have been informed, is OMAP35x.
  • [18:34:11] <ds2> what does that really mean in practice for nontelco applications? Is it possible to have a single binary run on both 3530 and 3430?
  • [18:34:42] <jkridner> These logins have to go. I'll caulk the logins up to growing pains for now.
  • [18:34:59] <jkridner> yes, it is really possible to have a single binary.
  • [18:35:42] <jkridner> in the kernel, there are a bunch of board-specific things to handle (pin muxes for example)
  • [18:36:12] <jkridner> at the application layer, it is difficult to come up with points of incompatibility.
  • [18:36:13] <ds2> *nod* learned about those the hard way
  • [18:36:30] <ds2> I was thinking more along the lines of kernel drivers
  • [18:36:43] <ds2> userspace is an afterthought for me ;)
  • [18:37:04] <jkridner> depends on the interconnect. as long as the interconnect is compatible, the kernel drivers will be compatible.
  • [18:37:42] <jkridner> all common peripherals are identical in behavior, with the exception of potential bug-fixes.
  • [18:37:48] <ds2> this makes me wonder how extensive would the changes be to the linux-omap kernel
  • [18:37:49] <prpplague> jkridner: the rs-232 header on the beagle is level shifted for rs-232 correct?
  • [18:37:57] <jkridner> no speculative enhancements.
  • [18:38:14] <ds2> so things like PM _should_ work barring new erratas?
  • [18:38:47] <jkridner> the kernel changes would be from things like the Ethernet MAC sitting on the EVM.
  • [18:39:06] <jkridner> prpplague: yes, they are at RS232 voltage levels.
  • [18:39:44] <jkridner> external memory options could be different.
  • [18:39:49] <jkridner> things like that.
  • [18:40:06] <ds2> so a common uboot is out then?
  • [18:40:22] <prpplague> jkridner: if you decide to go with the flyswatter, we can have a custom cable included to go from the 2x10 to the 1x10 rs-232 header on the flyswatter
  • [18:40:37] <jkridner> on-chip peripherals are identical barring new errata.
  • [18:41:12] <jkridner> Beagle peripherals are planned to be a-la-carte.
  • [18:41:28] <jkridner> there will be a purchasing page for Beagle and a list of recommended peripherals.
  • [18:41:43] <ds2> peripherials? such as?
  • [18:41:46] <jkridner> I think only the USB cable is included.
  • [18:42:08] <prpplague> jkridner: yea, i figured you'd have a place to purchase the 2x10 to db-9, dirk2 has it listed on the wiki
  • [18:42:17] <jkridner> serial cable, additional USB cables, USB hubs, keyboards, mice, monitors, USB-to-Ethernet adapters, ...
  • [18:42:43] <dirk2> alternate/additional power supply? 5V?
  • [18:42:44] <jkridner> exactly. we will have links to where you can buy all the "extras".
  • [18:42:45] <ds2> oh things tested to work with the beagle not things specific to it
  • [18:42:53] <jkridner> yes, an alternative power supply.
  • [18:43:00] <prpplague> jkridner: just figured it would be nice to include with a flyswatter for use with the beagle, we normally include the usb cable and a 2x14 jtag cable
  • [18:43:02] <jkridner> SD cards...
  • [18:43:06] <ds2> for a moment I thought you were suggesting there are add on daughter cards
  • [18:43:27] <jkridner> out of the box, you'll just get a beagle board and a USB cable. you'll be able to plug in and download a kernel via USB.
  • [18:43:41] <jkridner> you can also use the USB as the debug and network connection.
  • [18:43:51] <ds2> and to get console, one either needs to pay more or fab their own cable?
  • [18:44:04] <prpplague> jkridner: serial gadget driver?
  • [18:44:07] <jkridner> netconsole or USBTTY.
  • [18:44:10] <jkridner> exactly.
  • [18:44:16] <jkridner> serial gadget.
  • [18:44:22] <jkridner> we'll build it into the kernel.
  • [18:44:29] <prpplague> ahh ok gotcha
  • [18:44:45] <jkridner> actually, I think the latest kernel is built with the USBNET gadget.
  • [18:45:06] <prpplague> jkridner: the flyswatter adds a usb serial port to the host pc, so you can with a cable you could connect to the 2x10 rs-232 header
  • [18:45:15] * prpplague likes usbnet
  • [18:45:16] <jkridner> so, I think you'd have to do something with netcat and enable netconsole, but I'm not 100% sure.
  • [18:45:27] <prpplague> the nail board uses usbnet by default for it's gadget driver
  • [18:45:43] <jkridner> how do you do the console?
  • [18:46:03] <ds2> jkridner: you guys did the work to add netconsole support to the serial gadget?!
  • [18:46:17] <prpplague> jkridner: just use something like minicom and set the port to /dev/ttyUSB1
  • [18:46:50] <prpplague> jkridner: oh you mean with the nail board?\
  • [18:47:09] <jkridner> ds2: no. I'm suggesting more to use the CDC/RNDIS gadget.
  • [18:47:23] <ds2> oh :(
  • [18:47:25] <jkridner> ds2: wouldn't netconsole work over that (IP connection)?
  • [18:47:33] <jkridner> ds2: would you prefer serial?
  • [18:47:49] <ds2> jkridner: I don't think the gadget one will work as it needs some hooks to support netsconsole
  • [18:48:03] <ds2> jkridner: I strongly prefer serial in all the boards I work on
  • [18:48:08] <prpplague> as do i
  • [18:48:17] <jkridner> ds2: actually, my plan was to ship the boards with only U-boot and something like DFU-util.
  • [18:48:21] <ds2> somewhat disappointed in how some versions of CSST require USB :(
  • [18:48:30] <jkridner> require?
  • [18:48:43] <jkridner> prpplague: yes, I mean the nail board.
  • [18:48:43] <ds2> yes, as in they don't support using CSST over the serial port
  • [18:49:45] <jkridner> I don't know boards that have CSST support without serial port support, but I don't doubt you. I'm only familiar with OMAP3 stuff.
  • [18:50:01] <prpplague> jkridner: the nail board has a single usb B connection which then is connected to a four port hub chip. connected to the hub chip is the usb->jtag , a usb->rs-232, and the hammer's gadget driver
  • [18:50:20] <ds2> jkridner: it is not an OMAP3 board but it is a reference board
  • [18:50:25] <prpplague> jkridner: the usb->rs-232 is connected to the hammers serial console
  • [18:50:47] <prpplague> jkridner: and the hammer's default gadget driver is the cdc network gadget
  • [18:51:11] <prpplague> jkridner: so when you plug in the nail you get a jtag device, rs-232 console, and ethernet
  • [18:51:19] <prpplague> jkridner: all in one cable
  • [18:52:58] <prpplague> jkridner: in addition the usb->jtag has some host pc controlable gpio's that are connected to some gpio's for the hammer, which allows for you to do software interaction to similate button presses or simulate leds on your host pc
  • [18:53:19] <ds2> besides I don't trust MUSB enough to use it as a console ;)
  • [18:55:08] <prpplague> ds2: anyway if you use the flyswatter with the beagle you can connect the 2x5 serial port to the 1x10 header on the flyswatter for you serial port
  • [18:55:57] <ds2> prpplague: that's nice and all but I am strongly hoping that the 2x5 serial port follows the ad hoc industrial PC pin out
  • [18:56:14] <prpplague> ds2: it does based on what dirk2 has posted
  • [18:56:17] <jkridner> the serial pinout is the AT-EVEREX standard.
  • [18:56:24] <jkridner> IDC10.
  • [18:56:24] <prpplague> http://www.elinux.org/BeagleBoard#RS232
  • [18:56:48] <ds2> then I have stuff I can share with a PC
  • [18:56:56] <jkridner> I would think that the straight-through ribbon cables would be cheaper, but this one seems to be really common based on being used in old PCs.
  • [18:57:09] <ds2> or for real laziness, use a 10pin IDC ribbon cable straight to the PC :)
  • [18:57:33] <jkridner> excellent.
  • [18:58:06] <jkridner> prpplague: I think I need a picture for the hammer+nail. :)
  • [18:58:25] <prpplague> jkridner: http://www.elinux.org/Nail_Board
  • [18:58:48] <jkridner> if you have usb->rs232, why would you have a console on the CDC gadget?
  • [19:00:04] <prpplague> jkridner: sorry must have misunderstood, we don't use console on the CDC gadget, it is used for telnet, ssh, or other standard network connections
  • [19:00:31] <prpplague> jkridner: for instance, when i plug in my nail board to my host pc, i ssh in and start an X session
  • [19:00:48] <prpplague> jkridner: it displays the windows on my local pc , but are actually running on the nail board
  • [19:00:51] <jkridner> k, so that is 0 for 2 for netconsole. :)
  • [19:01:38] <prpplague> yea
  • [19:01:56] <jkridner> actually, I'm happy with the monitor and keyboard being the console, with the occasional debug over the serial port. but, I'm more of a userland guy.
  • [19:02:09] <prpplague> jkridner: but i'll be perfectly honest, i am far from your typical software developer
  • [19:02:26] <prpplague> jkridner: i am much more in the middle between the hardware and low level software
  • [19:03:53] <jkridner> prpplague: I've been more of a board/ASIC designer early in my career and a heavy Linux user. I'm still pretty new to kernel hacking beyond 'make menuconfig'. :)
  • [19:04:20] <prpplague> ahh
  • [19:04:39] <jkridner> prpplague: I was hoping to get to submitting some of the USB patches I worked on this week while I was off, but the week is slipping by fast.
  • [19:04:48] <jkridner> (too much time on IRC) ;)
  • [19:05:45] <prpplague> hehe
  • [19:06:24] <ds2> unless it has changed, I doubt netconsole will work over CDC
  • [19:06:28] <ds2> changed recently
  • [19:07:40] <jkridner> k. I just bought some of those serial cables for $1.98 each.
  • [19:08:05] <jkridner> trick is to make sure that people can buy them without paying extra shipping. I'm not sure we'll get that, but I'll try.
  • [19:10:14] <ds2> package it so it fits in the USPS Priority mail flat rate boxes
  • [19:14:13] * dirk2 (n=dirk@F33bd.f.strato-dslnet.de) has left #beagle
  • [19:18:49] <ds2> hmmm I2S is exposed and there is a stereo In/Out? does that mean the I2S on the header is a way to snoop data going to the twl4030?
  • [19:21:49] <BThompson> i guess if you wanted to collect the digital audio data than I suppose so, but anything interesting going to control the TWL4030 would probably go over the I2C link
  • [19:23:28] <ds2> it seemed odd to provide it.. i wonder if the TWL4030 can trystate its drivers for I2S
  • [19:24:03] <prpplague> yea that does seem odd, if you have an audio codec, you really can't use the I2S for anything else
  • [19:25:37] <prpplague> i guess you could turn of the codec with a i2c command
  • [19:25:42] <prpplague> s/of/off
  • [19:25:53] <prpplague> but that seems hardly worth the trouble
  • [19:26:07] <ds2> donno if that tristates the data line
  • [19:26:36] <ds2> the TWL4030 can't be turned off entirely as it also (normally) does other stuff like USB PHY
  • [19:27:35] <prpplague> ahh
  • [19:28:00] * prpplague isn't familiar with the TWL4030
  • [19:28:45] <ds2> the TWL4030 does a lot of stuff
  • [19:34:54] <BThompson> TWL4030 has a codec built into it, thus the I2S lines, I am not that familiar with the inner workings of the TWL4030 but I imagine it will have the ability to disable the audio codec, just like it should have an ability to configure it
  • [19:35:14] <BThompson> I believe all of the control for the TWL4030 will be done over the I2C bus though
  • [19:35:55] <jkridner> I2S channel on the expansion header is different than the one connected to the TWL4030.
  • [19:36:23] <ds2> didn't know the other McBSPs can do I2S
  • [19:36:24] <jkridner> The I2S is actually done using a McBSP peripheral, but I figure more people know I2S.
  • [19:37:16] <jkridner> I'm pretty sure they can, but I haven't confirmed. It would be strange to remove that feature. The low-power buffering wouldn't be there for the other ports.
  • [19:38:31] <jkridner> anyway, on Beagle, it is a different McBSP that goes to the expansion header than the one that goes to the TWL4030. I believe there are 5 McBSPs on the OMAP3530.
  • [19:38:51] <BThompson> I2S is one of the more common modes I see McBSPs used for, if it is the same basic McBSP peripheral as other TI devices it should support I2S
  • [19:39:58] <BThompson> looks like they do support I2S per the TRM
  • [19:39:59] <BThompson> http://focus.ti.com/lit/ug/sprufd1/sprufd1.pdf
  • [19:40:07] <BThompson> they dont support SPi though :(
  • [19:40:25] <prpplague> jkridner: ahh interesting
  • [19:40:29] <jkridner> there are, however separate SPI ports.
  • [19:41:07] <BThompson> yea, which is good, easier to use than McBSP SPI
  • [19:43:01] <BThompson> what is your interest in snooping data going to the TWL ds2?
  • [19:48:47] <ds2> BThompson: none, I was trying to make sense of the web page
  • [19:49:43] <ds2> the TRM seems to push people toward McBSP2 for audio so I thought there might be something unique but guess not
  • [19:59:18] <BThompson> If you were laying out a board i would probably use McBSP2 so it fits more with the standard (less driver modification), but it looks like the McBSP3 is the same in that they both have additional audio loopback capability... but if you didnt want that you should be able to do I2S on any of the 5 ports, looks like there is a bug in chapter 1 of the TRM where it mentions the McBSPs, it doesnt mention 4 or 5 in table 1-1... http://focus.ti.com/
  • [20:03:31] <ds2> Hmmm a free MCBSP... with a QSLIC/SLAC, this could turn the beagle into a VoIP FXS/FXO gateway
  • [20:08:27] <ds2> now only if TI can be convince to donate some free codecs (i.e. GSM or SPEEX or G.8xx series) that uses the DSP...
  • [20:14:37] <BThompson> unfortunately I havent seen any free... we offered a g.711 codec with the davinci devices that was licensable for a one time fee of $5k (cheap compared to other codecs).
  • [20:15:17] <BThompson> speex is open source, you could port it i suppose
  • [22:01:44] * BThompson (n=BThompso@nat/ti/x-e1ec0eb629660ccb) Quit ("Trillian (http://www.ceruleanstudios.com")
  • [22:07:13] * ds2 (i=noinf@netblock-66-245-251-24.dslextreme.com) Quit (Remote closed the connection)
  • [22:07:38] * ds2 (i=noinf@netblock-66-245-251-24.dslextreme.com) has joined #beagle
  • [22:38:20] * prpplague (n=dave@mail.americanmicrosystems.com) Quit ("Leaving")
  • [22:38:42] * BThompson (n=BThompso@cpe-76-183-86-15.tx.res.rr.com) has joined #beagle
  • [22:48:22] * RogerMonk (n=a0740758@nat/ti/x-875e3bc8fd7deadd) Quit (Remote closed the connection)
  • [22:55:33] * DarrenEtheridge (n=a0867391@nat/ti/x-a4c6ddb9a9c89546) Quit (Remote closed the connection)