New streamer ADC input modes
cgracey
Posts: 14,134
in Propeller 2
I was thinking how we can stream data out DACs, but not ADC data in. I will augment the streamer's WFxxxx modes to sum IN data from ADCs, so that we can have automated high-speed data acquisition.
Streamer WFxxxx new modes sum ADC signals and write them:
WFLONG
8 ch into 8 nibs, up to 15 clocks per sample
4 ch into 4 bytes, up to 255 clocks per sample
2 ch into 2 words, up to 65535 clocks per sample
1 ch into 1 long, up to max clocks per sample
WFWORD
4 ch into 4 nibs
2 ch into 2 bytes
1 ch into 1 word
WFBYTE
2 ch into 2 nibs
1 ch into 1 byte
Streamer WFxxxx new modes sum ADC signals and write them:
WFLONG
8 ch into 8 nibs, up to 15 clocks per sample
4 ch into 4 bytes, up to 255 clocks per sample
2 ch into 2 words, up to 65535 clocks per sample
1 ch into 1 long, up to max clocks per sample
WFWORD
4 ch into 4 nibs
2 ch into 2 bytes
1 ch into 1 word
WFBYTE
2 ch into 2 nibs
1 ch into 1 byte
Comments
Does this auto-wrap ?
Yes and yes.
Does it cost much to add 32b ?
I've got some external integrator ideas, that should push well past 16 bits ... (P2 is purely digital)
In this case, the capture result would need to stream, but I think that's the same pathway as ADC ?
Yes, the stream comes through the IN bit.
I think that's saying the 32b capture is already in there ? In that case. I'd keep it, for > 16b cases, even if all 32b are not useful, more than 16b could easily be.
This means doing some redesign at the level of the pad ring, or I'm losing something?
At the present design (the one we already have), have you resorted to any ONC18: G/MS available Deep N-well features, for noise isolation at the most sensitive analog areas?
I will implement the 32-bit mode, also.
Each pad has one giant deep N-well for all the 3.3V circuitry. I wonder if it would be good to divide that wells up, in order to isolate things like the ADC.
Or is there just one streamer for all COGs?
curious,
Mike
Every cog has a streamer.
Chip, I was right. Amiga of microcontrollers. The stuff people are going to do with this thing! (I got plans, who doesn't?)
Can't wait to see all that happen.
Re: super fast 4 bit oversampling. From what I read, doing that needs some white noise, and or imperfection in the ADC to actualuze improved resolution. There has to be something to average.
Thinking about uses for this, those 'up to' mean you could stream bytes, but have 5 or 6 valid bits, with 32/64 sysclks pacing ?
How does the ADC itself behave at these high sample rates ?
It seems there will be some slew-rate spec in there, meaning you cannot take 2 x 4 or 5 bit samples, and expect them to read opposite rails instantly.
That slew will be C-sample and Current Source related.
What is the low-bit-numbers slew rate ?