At 02:05 PM 8/10/00 -0500, you wrote:
>>
>>Next step up is to just use a PIC, sample on portB into internal
>>RAM - [storage space limited by internal RAM size]. However, you can
>>do sampling to 1 Msps easily this way [w/20 Mhz xtal], plus can
>>setup for various triggering schemes in firmware [bit hi/lo, pattern,
>>etc].
>
>
>Or bypass the pic altogether, and sample at a fixed clock rate into SRAM
>with nothing more than a 4020 counter and clock. (or is it the 4040, I
>forget..)
>

Yeah, these counters are only marginally useful, since they are
"ripple" counters, and you have to live with long latencies on
the MSBs.
==============

>You'd need something to read out the states, but that's only after the dust
>settles.
>
>You could also hack this approach to get states before and after the
>trigger by sampling continuously, and then running for a settable number of
>samples after trigger, which gives you moveable trigger position within the
>sample buffer.
>

Yeah, this is the major problem. Once you decide to go past the most
simplistic aprroaches, the whole thing immediately snowballs, and you
are adding chip after chip becasue of the complexity of performing
the various tasks - and putting in that "extra" feature. This is why
many units [like the one originally cited] have gone to gate arrays.

Oh, in my previous posting regarding 10-12 chips, I forgot to mention
needing another 2-3 chips to deal with setting the timebase. I actually
designed such a thing a year or so ago, and it came in at 13 chips,
and this employed both an 18-pin PIC and 28-pin Scenix used in a manner
to eliminate another 2-3 chips. It would sample at 50 Mhz into a
32KB RAM. Kinda lost interest - probably easier to buy than to make.

- danM

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]: PIC only [EE]: engineering [OT]: off topic [AD]: advertisements