On Mon, 16 Nov 2009 21:13:54 +0000
Folderol <folderol(a)ukfsn.org> wrote:
On Mon, 16 Nov 2009 10:56:17 +0100 (CET)
karl(a)aspodata.se (Karl Hammar) wrote:
Martin Peach:
>> karl(a)aspodata.se (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.