From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21522 invoked by alias); 17 Sep 2004 18:07:42 -0000 Mailing-List: contact ecos-maintainers-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@sources.redhat.com Received: (qmail 21259 invoked from network); 17 Sep 2004 18:07:41 -0000 Date: Fri, 17 Sep 2004 18:07:00 -0000 From: Andrew Lunn To: Andrea Michelotti Cc: Andrew Lunn , ecos-maintainers@ecos.sourceware.org Subject: Re: [Bug 1000096] new AT91 platform: JTST Message-ID: <20040917180643.GB26968@biferten.ma.tech.ascom.ch> References: <20040917115657.246B365C110@smtp.ecoscentric.com> <06c801c49cd6$948bc9a0$0b0110ac@ipitec.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06c801c49cd6$948bc9a0$0b0110ac@ipitec.it> User-Agent: Mutt/1.4i X-SW-Source: 2004-09/txt/msg00017.txt.bz2 On Fri, Sep 17, 2004 at 06:51:26PM +0200, Andrea Michelotti wrote: > It exists supplemental DSP APIs for debbuging, user support and for > system service routines. The problem is that I have to undestand the > best way to plug them into eCos. At the moment I have a package > that is situated in my local tree in package/devs/dsp/arm/magic. Humm. As a starting point that is reasonable. However we might want to think a bit about the long term. I can see more silicon with a CPU and a DSP together comming along. eg there is TI OMAP and im sure there are others. You should also think about your own internal plans. Maybe you will release another chipset which has the same DSP but a different processor. Or maybe you keep the same processor but have a different DSP. You want to keep the API the same to make it easy to port software between the different systems. So you might want to split it up into multiple packages. Maybe one package that implements the API. Another which implements the things which are specific to the DSP and a third which is specific to the processor? Now is the API generic enough that it could say be used for the OMAP or some other manufactures CP+DSP chipset? Im guessing not, it would be very difficult to have such a generic API. So maybe you need something like the following structure packages/devs/dsp/atmel/magic packages/devs/dsp/atmel/jtst packages/devs/dsp/atmel/api Since there is nothing like this at the moment we have much more freedom for discussion, so if you have other ideas or requirements please let us know. > We have developed (work done by atmel China) an ecos driver also for the USB > (philips isp1181) included in the JTST; but I must check if we can > distribute the sources.. We would also need to look at the copyright assignment. Is it specifc to you, Atmel Italy, or Atmel world wide? Andrew