From wpdster@gmail.com Tue May 31 15:50:17 2011 Received: from mail-fx0-f44.google.com ([209.85.161.44]) by stoneboat.aleph1.co.uk with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.69) (envelope-from ) id 1QRQGp-00013c-OJ for balloon@balloonboard.org; Tue, 31 May 2011 15:50:17 +0100 Received: by fxm15 with SMTP id 15so3538396fxm.31 for ; Tue, 31 May 2011 07:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=JiR4+ZlXJre0WHChPPkdEMNn5+7QKU3qF/uGBV9rh00=; b=PtoilR84Ms0tvB2uZGhIlypGxV0FG1IpKcBpcc0eK8JJsYaggLrJcMzovd0ZJurT8O FZ4Z5rkiB1yqRfy7CkVxyz11t83hs4dt+BQLwGh6p3adEoNdHLSLtTzLwT2BfDRf5Rnv 2K/9z+wcn/a5de7CPGXnSpRhbMKLCJ3Xmse64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=ZuC0HhJS0soRTCvfisiJiszu4hrITlJ4z5FRsxWDn/78+lmr2cu9MkNRYeXzjfDjCZ AldrKF+xQpdzlcF9LgFnXHyZkqY6zNYToStnT3P9sjEod9QHq2Gf4J95gUxwFnm6i5wH Tgw3D6Z5gS8ojX31A07dpKETJEew8UU4mtuDY= Received: by 10.223.91.85 with SMTP id l21mr420859fam.80.1306853406118; Tue, 31 May 2011 07:50:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.157.131 with HTTP; Tue, 31 May 2011 07:49:46 -0700 (PDT) In-Reply-To: References: From: Patrick Doyle Date: Tue, 31 May 2011 10:49:46 -0400 Message-ID: To: balloon@balloonboard.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 209.85.161.44 X-SA-Exim-Mail-From: wpdster@gmail.com X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on stoneboat.aleph1.co.uk X-Spam-Level: X-Spam-Status: No, score=-3.7 required=4.5 tests=AWL,BAYES_00, RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on stoneboat.aleph1.co.uk) Subject: Re: [Balloon] Balloon4 X-BeenThere: balloon@balloonboard.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Balloon List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 14:50:17 -0000 On Tue, May 31, 2011 at 6:41 AM, David Bisset wrote: > > I'd like to respond in general to the points raised to date. > > Firstly it's really important that we don't forget that B4 is not Beagle. > What does this mean? > =A0 a) B4 is chasing a completely different market sector (embedded equip= ment, adaptable systems, portable systems). > =A0 b) B4 is not, by design, a desktop PC replacement, or a netbook. (It'= s not designed to do code development 24/7) > =A0 c) B4 is not trying to become the "standard" OMAP 3 development tool.= (Beagle and derivatives already fulfil that slot cheaply and effectively.) > =A0 d) We can do things differently. > > Secondly, the design for B4 is the core design for all derived products (= e.g. Challenger). > It therefore needs to try and address current and future needs in the mar= ket we are interested in. > So B4 needs to be > =A0 a) Embeddable, or at least its derivatives need to be. > =A0 b) Power efficient. > =A0 c) Adaptable (Beagle is not). > =A0 d) Manufacturable, and low volume manufacturable. > > So what about visual output? > > Why do we need it? > =A0 a) for native development. > =A0 b) for the end application. > > What sort of visual output do we need? > For native development we need a large graphic area, good resolution etc. > =A0 This could be VNC or USB or other remote technologies. > =A0 In most cases dev does not need fast complex graphics. > =A0 In nearly all cases remote connection is preferable as given the embe= dded nature of B4 it is likely that the target device is not on a bench but= buried inside some 'kit'. > =A0 If an application does need good graphics then chances are a good dis= play (or a connection to one) has been designed in to the system, so that n= eeds to be possible but is not essential. > > For the end application we will need either an LCD, nothing, a TV output = or a large monitor. > =A0 LCD we can do, both large and small. > =A0 TV S-Vid we can do, but this is not going to win friends in some quar= ters, but as it comes for free lets have it. > =A0 Monitors; most monitors have DVI (of some flavour) some have HDMI, la= rge TV's have HDMI and SCART/Composite. > =A0 So why should we try and support full blown HDMI? (as opposed to DVI = on a non standard connector). > =A0 It is immaterial how we deliver DVI except for the PCB cm^2 required = for the connector. > =A0 As Steve points out proper compliant HDMI requires consortium members= hip ($5k min per annum + approvals costs etc), well out of even TCL's reach= given the low level of potential use. > =A0 What most people are asking for is DVI, Beagle happens to deliver thi= s via a non-standard connector to save cm^2. > > Conclusion: > > Go for a connector (as low a cm^2 count as we can manage) that delivers D= VI. > =A0 We need to discuss what this means both in terms of the connector reu= sability as GPIO and the spec for the DVI. > Any extra signals needed for HDMI should be there in case someone wants t= o pay the $ to get it sorted. > This will do the "connect it to a monitor" for native development , and t= he connect to large TV (with the same large red warning stickers as Beagle)= . > > This leads on to what I see as the bigger debate. > What connectors do we want "On B4" and what are we prepared to put on an = expansion board. > What needs to be on B4, what will represent the best use of space? > The functional requirements for B4 at this stage are mixed, and this mix = may be confusing the design process. > > My take on this is to keep the on-board connectors to a minimum (others m= ay disagree): > a) To reduce board space. > b) To prove that the design is embeddable (As IO speeds go up this gets h= arder, and as power/standby control needs to be better this gets harder) > c) to make B4 embeddable (Challenger has to be embeddable, B4 may not be)= . > > Counter to this is the need to have a standalone system. > However a processor board with minimal connectors that combines with a br= eakout board making a usable standalone system should be completely accepta= ble and may better allow B4 to be embeddable in its own right. > > We have always said that B4 will arrive with an expansion board from day = one. > I'll do my best to ensure that this happens in the same time frame as B4. > So the major question is Whats on B4 and Whats on the expansion board? > Or is everything on B4 and there is no need for an expansion/breakout boa= rd? > > Thoughts please on all the different issues above. Perhaps this has been discussed before... I realize that I am very new to the BalloonBoard community and am not aware of past debates or hot topics, so please forgive me if this has all been hashed out in the past... My own preference would be to make the B4 a processor+memory (volatile & nonvolatile)+FPGA platform and move all of the IO decisions to a daughterboard. Mate the B4 to the daughterboard via a high density connector. This is very similar to the Gumstix approach (www.gumstix.com). The differentiator is the inclusion of programmable logic, which is what brought the BalloonBoard to my attention in the first place. But that's just my own personal bias. I don't have any market data to back it up. But you did ask for thoughts on the issues you raised :-) --wpd Then design the daughterboard