On Wed, Dec 10, 2008 at 7:48 AM, Philip Covington <span dir="ltr"><<a href="mailto:p.covington@gmail.com">p.covington@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Wed, Dec 10, 2008 at 7:33 AM, Bob McGwier <<a href="mailto:rwmcgwier@gmail.com">rwmcgwier@gmail.com</a>> wrote:<br>
> ...<br>
> It CAN run erlang and do the VR kernel bit and run a yaws server as well!<br>
<br>
</div>...</blockquote><div> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Of course, eventually you'd want to do your own OMAP board, but the<br>
BeagleBoard looks like it would be useful for experimentation.  All of<br>
the build files are available including Gerbers.</blockquote><div><br> Two thoughts, obliquely related.<br><br>(1) An OMAP board would provide *very* deep system infrastructure support. Much of what you'd want to provide in the way of system services to the DSP code is off-the-shelf. Likewise the paths to the outside world, user apps, etc. Likewise room for later expansion of functionality, etc.<br>
<br>(2) A development trajectory like generic platform -> Beagle Board -> custom OMAP means that a working development environment would be available, free, and would come with a significant support community, *right now*.<br>
<br>My private opinion, not one I'm urging on anybody else, is that *not* using a strategy like (2) is mostly an expression of severe NIH syndrome.<br><br>73<br>Frank<br>AB2KT<br></div></div><br>-- <br>If you want to know what God thinks of money, just look at the people he gave it to. -- Dorothy Parker<br>