[Mep-dev] Tuesday Challenge for 14 April 2009

[Eric Fort]

I would tend to agree except that it seems "they will come if you build it"
works, not so much if they have to build it by first shoveling the sand to
load into the process machines and make their own silicon wafers which they
then....well you get the point.  I think it's importaint that as well as
specifying the air interface parameters that TEAM MEP produces multiple
units of a reference design that are easily replicated and the team should
coordinate their focused effort on a single hardware/software platform for
that reference design.  if someone wants to go out and redesign from the
ground up or otherwise a compatable system, great but at the end of the day
what matters is deployable hardware that's easy to use and actually serves
it's intended purpose.

Eric
AF6EP

On Thu, Apr 16, 2009 at 11:18 AM, Assi Friedman <assi at san.rr.com> wrote:

> So instead of trying to tie the system to a specific architecture, why not
> shift the focus to developing the boundary interfaces of the system.  I.e.
> specify the behavior of the system rather than the operation. That way, you
> leave the implementation open for porting to many other systems.  Look at
> the approach crypto designers take. They design the behavior of the
> algorithm with considerations for a 8bit or 32bit processor and they leave
> the rest to the system implementers.  That way, to each his own...
> Assi kk7kx
>
>
> > -----Original Message-----
> > From: mep-dev-bounces at uppermeadow.com [mailto:mep-dev-
> > bounces at uppermeadow.com] On Behalf Of Michelle
> > Sent: Thursday, April 16, 2009 7:25 AM
> > To: mep
> > Cc: Frank Brickle
> > Subject: Re: [Mep-dev] Tuesday Challenge for 14 April 2009
> >
> >
>
> > It's my understanding that developing MEP upon embedded linux means we
> > must necessarily develop for one architecture at a time. For example,
> > the TI OMAP.
> >
> >
> > So, what are some reasons for considering Android for MEP?
> >
> > My feeling is that porting MEP to as many processers as possible should
> > be a very strong consideration, and here is why.
> >
> >
>
> _______________________________________________
> Mep-dev mailing list
> Mep-dev at uppermeadow.com
> http://uppermeadow.com/mailman/listinfo/mep-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://uppermeadow.com/pipermail/mep-dev/attachments/20090416/823b4b1a/attachment.html