Re: [LAU] open hw soundcard

On Mon, 16 Nov 2009 21:13:54 +0000
Folderol <folderol@email-addr-hidden> wrote:

> On Mon, 16 Nov 2009 10:56:17 +0100 (CET)
> karl@email-addr-hidden (Karl Hammar) wrote:
>
> > Martin Peach:
> > > >> karl@email-addr-hidden (Karl Hammar) wrote:
> > ...
> > > >>> If we are going to have multiple analog inputs at higt sample rate,
> > > >>> isn't it better to have a parallell interface. With spi the number of
> > > >>> channels will be limited to something like 8 for a 24bit converter.
> > > >>> Plus that the AT32AP7000/AT91SAM9260 only has two spi-busses.
> > ...
> > > Another way to do that would be to bit-bang 8 SPI devices sharing one
> > > clock line (and /CS/FS) onto a byte-wide port, read all 8 in parallel
> > > one bit at a time in perfect sync.
> > >
> > > It actually should be possible to use a /RD line for an SPI clock, so 24
> > > successive reads of a single address would clock in 8 24-bit samples.
> >
> > I tend to dislike bitbanging, but yes, that should be doable, something
> > like:
> >
> > void read_all_adcs() {
> > uint32_t adc[32]; // up to 32 adc converters
> > int ix;
> > int kx;
> > uint32_t bits;
> >
> > chip_select(0);
> > // the first few bits are to start converter
> > bits = get_data();
> > bits = get_data();
> > bits = get_data();
> > bits = get_data();
> > bits = get_data();
> > for (ix = 0; ix < 24; ix++) {
> > bits = get_data();
> > for (kx = 0; kx < 32; kx++) {
> > adc[kx] <<= 1;
> > adc[kx] |= bits & 1;
> > bits >>= 1;
> > }
> > }
> > chip_select(1);
> > }
> >
> > I have to think about that. The big "but" would be that the clock
> > (the frequency of get_data()) should be stable, I don't know how much
> > variation is allowed.
> >
> > Regards,
> > /Karl
>
> Possibly, the only one that needs to be stable is the one that actually
> initiates the sampling. i.e. number 5. This seems a bit messy, however,
> could numbers 1-4 be done at any time after the previous conversion,
> then number 5 initiated by a very stable hardware clock source, and the
> remaining pulses derived from the processor.
>
> indeed, turn it round so:
>
> chip_select(1); // end of previous cycle
> // some form of minimal time delay
> chip_select(0);
> // the first few bits are to start converter
> bits = get_data();
> bits = get_data();
> bits = get_data();
> bits = get_data();
> // wait in this state for hardware clock
>
> Because we've faked a serial fetch would that upset the normal fetch, or
> can we simply make one more than we need and throw it away?

Talking to myself again :)
Too late, it dawned on me that we are no longer talking about using
spi so the above line is nonsense :(

> The hardware clock source could also be used to

generate, not 'transmit'

> the
> syncronising pulse to the network - assuming this card is the master,
> which the first development one will be of course.
>
>
> Hmm, we now have a big enough thread for me to create a new fold in my
> mailreader just for these entries :)
>
OK guys, back to normal!

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user