From owner-freebsd-small@FreeBSD.ORG Sun May 14 18:45:09 2006 Return-Path: X-Original-To: freebsd-small@freebsd.org Delivered-To: freebsd-small@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96FED16A403; Sun, 14 May 2006 18:45:09 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E734443D49; Sun, 14 May 2006 18:45:08 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.6/8.13.6/NETPLEX) with ESMTP id k4EIiW1g013362; Sun, 14 May 2006 14:44:32 -0400 (EDT) Date: Sun, 14 May 2006 14:44:32 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: gnn@freebsd.org In-Reply-To: Message-ID: References: <20060513103640.GL69354@cicely12.cicely.de> <20060513085933.R986@odysseus.silby.com> <20060513151305.GP69354@cicely12.cicely.de> <20060513.115539.74661598.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-small@freebsd.org, gallatin@cs.duke.edu, jhb@freebsd.org, silby@silby.com, ticso@cicely12.cicely.de, wb@freebie.xs4all.nl, ticso@cicely.de Subject: Re: Eclipse for Embedded FreeBSD? X-BeenThere: freebsd-small@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 May 2006 18:45:09 -0000 On Sun, 14 May 2006, gnn@FreeBSD.org wrote: > At Sun, 14 May 2006 11:02:17 -0400 (EDT), > Daniel Eischen wrote: >> >> On Sat, 13 May 2006, Warner Losh wrote: >>> I can tell you that my company has committed to an ARM design. Unless >>> there something really bad that we've not hit, we'll be supporting it >>> for at least 10 years in the field. I'm planning on adding support >>> for additional designs. Jean-Mark is adding support for Cirrus Logic >>> ARM-9 boards (at least one anyway). Benno Rice is adding support for >>> the gumsticks. Other folks at BSDCan have suggested that they will be >>> doing their own devices in the near future, but have asked me to keep >>> their names and projects under my hat. I'll likely do at least one >>> more arm board. There's much interest in taking FreeBSD/arm and >>> FreeBSD/i386 (and other archs when they are ready) to the next level >>> of embedding. >> >> And what is the next level of embedding? An easily configured >> GUI or Eclipse plugin thingy that lets you configure and build >> your target, and also shows your your memory requirements for >> each selected component? And will it have a VME bus driver? >> Please give us another alternative to vxWorks :-) > > Would you prefer Linux or CE then? ;-) No, I confess I still use a series of makefiles using ln, lndir, cp, et. al. to build vxWorks images. One reason I dislike vxWorks is that you need write rights to the installation directory, and it annoys the hell out of me that I have to work around it so that anyone without privileges can build. But the GUI-based tools to configure VxWorks, Linux, CE, or whatever, are attractive to the majority of developers and most especially look good to the people who are responsible for justifying and buying them. _We_ might snub our noses at such tools, but they look good to others. > And, more seriously, it very much depends on those who work on it. > Clearly our current configuration systems (text files) are not going > to be useful to the majority of people who wish to configure an OS > vs. those who are going to hack on the core of it. So, if you have a > suggestion we'd love to hear it. Well, see above. A GUI-based configuration tool, with tree-like heirarchy of dependencies and space requirements would be useful. Eclipse seems to be the standard for such things, but I admit I've never used it. And for industrial controls and military applications, a VME bus (nexus) driver supporting device drivers and mmap'able VME A32, A24, & A16 space would be great. -- DE