> linnix wrote:
> > larwe wrote:
> > > On Feb 4, 5:47 pm, "linnix" <m...@linnix.info-for.us> wrote:
> > >
> > > > Anyway, doing DCT first might be
> > > > a better solution in your case,
> > > > rather than RX the raw signals.
> > >
> > > The whole point of the exercise is to acquire raw data which will be
> > > DSP'd in the PS3's SPEs
> >
> > .Actually yes, i need raw data too.
> >
> > The FTDI can do parallel (USB ATA),
> > but not in the LM board. There are
> > 8 data and 4 control lines in each channel.
> >
> > I can perhaps patch some I/Os to channel A
> > and multiplex the Jtags, but then it's
> > sounding like another custom board.
>
> I need 1 Mb/s uncompressed and perhaps 512 Kb/s compressed.
>
> According to the spec, the FTDI 2232 can do 1 Mb/s in RS232
> 3 Mb/s in RS422 and 5.6 Mb/s in Bit Bang (Jtag, Spi, etc).
>
> So, it should work in theory, but ...
Never mind, got it to work on 920K baud.
So, if you are still interested in capturing 6 channels of 48KHz.
We can do it.
>
> The 2.6 driver does not handle Bit Bang, but found some code
> that hook into the USB message stack directly.
> Still trying to figure out what to do.
>
> Any experts in FTDI Bit Bang out there?
Still trying to Jtag the chip.
I can reset the chip, but not reading TDO yet.
Reply by linnix●February 5, 20072007-02-05
linnix wrote:
> larwe wrote:
> > On Feb 4, 5:47 pm, "linnix" <m...@linnix.info-for.us> wrote:
> >
> > > Anyway, doing DCT first might be
> > > a better solution in your case,
> > > rather than RX the raw signals.
> >
> > The whole point of the exercise is to acquire raw data which will be
> > DSP'd in the PS3's SPEs
>
> .Actually yes, i need raw data too.
>
> The FTDI can do parallel (USB ATA),
> but not in the LM board. There are
> 8 data and 4 control lines in each channel.
>
> I can perhaps patch some I/Os to channel A
> and multiplex the Jtags, but then it's
> sounding like another custom board.
I need 1 Mb/s uncompressed and perhaps 512 Kb/s compressed.
According to the spec, the FTDI 2232 can do 1 Mb/s in RS232
3 Mb/s in RS422 and 5.6 Mb/s in Bit Bang (Jtag, Spi, etc).
So, it should work in theory, but ...
The 2.6 driver does not handle Bit Bang, but found some code
that hook into the USB message stack directly.
Still trying to figure out what to do.
Any experts in FTDI Bit Bang out there?
Reply by linnix●February 4, 20072007-02-04
larwe wrote:
> On Feb 4, 5:47 pm, "linnix" <m...@linnix.info-for.us> wrote:
>
> > Anyway, doing DCT first might be
> > a better solution in your case,
> > rather than RX the raw signals.
>
> The whole point of the exercise is to acquire raw data which will be
> DSP'd in the PS3's SPEs
.Actually yes, i need raw data too.
The FTDI can do parallel (USB ATA),
but not in the LM board. There are
8 data and 4 control lines in each channel.
I can perhaps patch some I/Os to channel A
and multiplex the Jtags, but then it's
sounding like another custom board.
Reply by larwe●February 4, 20072007-02-04
On Feb 4, 5:47 pm, "linnix" <m...@linnix.info-for.us> wrote:
> Anyway, doing DCT first might be
> a better solution in your case,
> rather than RX the raw signals.
The whole point of the exercise is to acquire raw data which will be
DSP'd in the PS3's SPEs.
Reply by linnix●February 4, 20072007-02-04
larwe wrote:
> On Feb 4, 5:02 pm, "linnix" <m...@linnix.info-for.us> wrote:
>
> > Yes, in theory.
> > In practise, I am having trouble getting 230K through USB.
> > between
>
> You are using a USB-to-serial converter. This does not operate in iso
> mode, plus it has the added "bonus" of going through the async
> management layer of your host OS, which wasn't designed for these high-
> speed data rates.
>
> USB hard disks sustain a much higher data rate than 230K!
You are probably correct.
But lacking a better alternative,
i have to deal with the FTDI
(Dual channel USB serial).
However, there is a program channel
that I might be able to use, if
i can make use of the Jtag lines.
Namely, TX on port 1 (lower rate)
and RX on port 2 (max. rate).
Alternatively, I can wire some I/Os
to another bus (parallel port?)
Anyway, doing DCT first might be
a better solution in your case,
rather than RX the raw signals.
Reply by larwe●February 4, 20072007-02-04
On Feb 4, 5:02 pm, "linnix" <m...@linnix.info-for.us> wrote:
> Yes, in theory.
> In practise, I am having trouble getting 230K through USB.
> between
You are using a USB-to-serial converter. This does not operate in iso
mode, plus it has the added "bonus" of going through the async
management layer of your host OS, which wasn't designed for these high-
speed data rates.
USB hard disks sustain a much higher data rate than 230K!
Reply by linnix●February 4, 20072007-02-04
On Feb 4, 1:38 pm, "larwe" <zwsdot...@gmail.com> wrote:
> On Feb 4, 2:52 pm, "linnix" <m...@linnix.info-for.us> wrote:
>
> > > Griffin iMic, which provides audio input and output in stereo at
> > > 48kHz. YDL apparently has support for this peripheral out of the box.
>
> > I don't see any Linux support on there web.
>
> They don't provide any. Support is native in the Linux kernel. <http://
> seehuhn.de/comp/hardware/imic>
>
> > Seriously, 48KHz x2 on USB would be tough.
>
> Why? Even if it is operated in full duplex, 48K x 16bit x stereo x
> full-duplex is only 384kbps, well within the USB 1.1 specification.
> USB audio drivers operate in isochronous mode.
Yes, in theory.
In practise, I am having trouble getting 230K through USB.
between
1. 1.6 GHz Atheron (USB 2.0) & 50 MHz Arm
2. 200 MHz Geode (USB 1.1) & 50 MHz Arm
High data rate simply lockup the USB stack.
See my post below.
Reply by larwe●February 4, 20072007-02-04
On Feb 4, 2:52 pm, "linnix" <m...@linnix.info-for.us> wrote:
> > Griffin iMic, which provides audio input and output in stereo at
> > 48kHz. YDL apparently has support for this peripheral out of the box.
>
> I don't see any Linux support on there web.
They don't provide any. Support is native in the Linux kernel. <http://
seehuhn.de/comp/hardware/imic>
> Seriously, 48KHz x2 on USB would be tough.
Why? Even if it is operated in full duplex, 48K x 16bit x stereo x
full-duplex is only 384kbps, well within the USB 1.1 specification.
USB audio drivers operate in isochronous mode.
Reply by linnix●February 4, 20072007-02-04
On Feb 4, 11:24 am, "larwe" <zwsdot...@gmail.com> wrote:
> On Feb 4, 12:37 pm, cs_post...@hotmail.com wrote:
>
> > > That's the path I am expecting to take - the difficulty is to find
> > > someone who can say authoritatively "this works in PPC Linux". Even
>
> > Well, as your experience points out it wouldn't be proof, but I don't
> > believe there is much stopping you from downloading the driver source
>
> True. After searching a lot, it seems that the _most likely_ to work
> (known to work on PPC in general but not guaranteed on the CBE) is the
> Griffin iMic, which provides audio input and output in stereo at
> 48kHz. YDL apparently has support for this peripheral out of the box.
> I'm sufficiently convinced that I'm dropping $30 on one. Fingers
> crossed...
I don't see any Linux support on there web.
Are you going to write the driver?
Seriously, 48KHz x2 on USB would be tough.
I was planning on DCT on the device side at least.
Reply by larwe●February 4, 20072007-02-04
On Feb 4, 12:37 pm, cs_post...@hotmail.com wrote:
> > That's the path I am expecting to take - the difficulty is to find
> > someone who can say authoritatively "this works in PPC Linux". Even
>
> Well, as your experience points out it wouldn't be proof, but I don't
> believe there is much stopping you from downloading the driver source
True. After searching a lot, it seems that the _most likely_ to work
(known to work on PPC in general but not guaranteed on the CBE) is the
Griffin iMic, which provides audio input and output in stereo at
48kHz. YDL apparently has support for this peripheral out of the box.
I'm sufficiently convinced that I'm dropping $30 on one. Fingers
crossed...