On Tue 24/05/11 10:17 , David Bisset <
david_bisset@btconnect.com> wrote:
> > Not many SPIs. Do we care? Anyone use them, except for audio?
> We were thinking that this was the way forward for internal
> interconnect within products.
> So much small stuff uses SPI (light detectors, ADCs, keyboards
> etc.).
i2c is a sane alternative for some of these, but yes, a second SPI (or, if the software can be convinced to share nicely, a couple of chip selects) would be handy. The automated chip selects (which the datasheet calls SPI channels) aren't bonded out on our CUS packaged OMAP3.
> Having a small low power micro that can allow the system to shut
> down to micro amps and wake up on an external event is a big win.
> Once we have a full architecture diagram I guess it will be easier
> to see what else it could do, but all you mention above sounds like a
> good idea.
Yeah, I'll try to flesh out that area. I'm mostly warning you all that some software effort will be needed in the tiny micro to support this stuff.
<
http://processors.wiki.ti.com/index.php/OMAP35x-AM37x-DM37x_with_TPS65023:_Design_In_Guide> is a page well worth reading for anyone even remotely interested in this, who wants a primer before jumping in.
> My only concern is debugging the software, if we screw up we blow
> the chip and given the number of software debug cycles is usually >100
> (for embedded) thats a fair number of broken boards.
Nah, 10^4 minimum, 10^5 typical for MSP430. That'll do, in any sane world.
> So this will need careful design and a solid debug/test strategy to
> minimise the damage. (I'm guessing this is mine...)
Nicely done - thanks!
> > DRAM:
> OK, chuck me some pointers to potential parts and I'll see if we can
> find them, John is on holiday this week so it may take a few days to
> talk to distributors.
Micron MT46H128M16LFCK-6 IT
However, if it says LPDDR and is 1Gbit or above, I'm interested.
> I'm guessing the problem is that every mobile phone manufacturer
> sucks up the entire output and we are left to pick up the droppings
> when they have a short month, as usual....
Yes. Also, it's not used in laptops, so it's not completely commodity. Phone components seem to be less cost sensitive than other stuff, the end customer picks up the tab.
> > HDMI:
> I'm not in favour of supporting HDMI on OMAP3.
:)
I think I've become, if anything, more hardline on this.
Since the DSS pins can be freed up as precious GPIOs, I think I'm now leaning towards just sticking the entire interface on a connector. And a less annoying connector than the pair of 1.27mm sockets on Beagle.
If people want, I'll do an HDMI adaptor board, but that keeps all the horrors off the Ballon board itself. It also allows us somewhere to drop a simple buffered GPIO interface onto Balloon. Very easy for people to do their own, if they don't want to play with the FPGA side. (There's an SPI there, too, and if we run an i2c up the same connector, it becomes quite appealing)
> We also talked about low end LCD panel support via a CPLD,
No need, it bolts straight up. The DSS is as happy driving a cheesy LCD as anything else (as long as it either wants 1.8V signalling, or someone buffers).
> Do we still have the backplane connector, have we spec'd whats on it yet?
We have a place where the backplane connector goes - but I'm not yet sure what to put on it. Having the FPGA buffer the GPMC bus onto it seems reasonable, but does anyone want that sort of thing? Have we got to the stage that it just wants to be an assortment of serial buses? USB, UART, SPI, i2c, audio?
I'm contemplating a couple of mini-PCI-E sockets, too (in USB-only mode). This might be a less contentios way of adding wifi, cellphone and whatever else we fancy, without having to buy anonymous Chinese USB dongles and hoping the chipset's not changed.
If anyone wanted to build a GPMC - Wishbone - PCI-E (or even regular PCI) egine for the FPGA, we could run a very useful backplane. But that sounds hard.
Steve
--
Arbury.com Ltd, 2 Durnford Way, Cambridge, CB4 2DP, UK. Reg. 6573238
(text/plain)