would also encourage everyone to chime in here. These decisions are vital
to the success of the product and as I said, they are not easily changed.
Further it's not just the Neuros' success that's at stake. If we have
success with this type of open development, you can bet that other manufacturers
will ultimately follow suit, and that's going to result in more open products
for all of you to hack. So if you have opinions or thoughts, don't be
You raise good points, as always.
Daniel Stenberg wrote:
On Wed, 28 Sep 2005, Bob Faskos wrote: Bob: Why is this "an awful lot of work"? The drivers for the
NET2272 have been present in the standard uCLinux distribution for a long
time. There is usb Gadget support and everything right off the distribution.
Why do you think that the effort of enabluing these features is not worth the
prize of having all sorts of possibilities open?
The main reason we chose the NET2272 route is to
enable other than direct-to-disk applications in high speed. Such
applications include Janus (MTP), Ethernet-over-USB (RNDIS), fast serial
as well as mass storage.
Correct, if you want your box
to be able to fly to the moon and make coffee automatically every morning
(over USB), you'll need these features! ;-)
In my view, this looks
like you get an awful lot of work and trouble for some very blue-sky dreams
of the future. And again your choices and dreams for the 442 spill over and
make N3 development harder.
But that's me.
I think that Janus or any other DRM scheme is of secondary
importance - I *H*A*T*E* any DRM schemes.
But I think that you can't
dismiss the possibility of implementing it.
But that is me. To
me there are much more important uses to this bus-driven USB.
For example I
can see a scenario where someone wants to develop application code to run on
the N3. Since there is no Ethernet adapter on the N3, one good way of setting
up the environment would be to use the high speed USB interface to connect to
your Linux PC host using NFS, and do a NFS root mount on the N3. This is such
a flexible development environment that I would jump through hoops to be able
Let me know if I conviced you or if you still swayed to
the other side.
Bob: Sadly, you are right. You can't
power off the DSP without losing control of the audio port.
The architecture of the chip is such that only the
DSP has access to the ADC and DAC, but there will be interfaces from the
ARM side available that just pass the PCM samples back and forth.
Right. But then you can't power off the DSP part to
save power (if that is even possible - this little MCU is as usual not
possible to read up any details on so how can we tell?).
DSP can be sleeping when it is not needed, and come out of IDLE whenever there
is audio to be processed. This consumes next to nothing in power. Actually,
when you consider the big picture the DSP side of the chip is more economical
than the ARM side. Unfortunately you cannot completelly shut down either
I don't think we've seen any good use for the DSP yet in the N3.
Or am I wrong? Bob: The MIPS - Millions of Instructions Per Second. The ARM is
powerful enough to implement prettymuch any audio decoder or encoder that
somehow never got implemented on the DSP. Also, the ARM can be used to decode
audio and leasve the entire DSP available to decode video. This achieves much
higher performance due to load
Then there are the advanced decoders. These can
work on the ARM and pass 24-bit samples to the DSP at up to 96 KHz SR. The
MIPS are available.
This SF.Net email is sponsored by: Power Architecture Resource Center: Free
content, downloads, discussions, and more.
_______________________________________________ Neuros442linux-main mailing
------------------------------------------------------------ Mail was checked
for spam by the Freeware Edition of No Spam Today! The Freeware Edition is
free for personal and non-commercial use. You can remove this notice by
purchasing a full license! To order or to find out more please visit: