USB data or audio capture on 64-bit PPC Linux?

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.

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.

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.

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?

linnix wrote:
> 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.