> > > Is there a speed improvement over serial with the FTDI chips? (if
> not
> > > I say leave the USB out and let the user add a converter if they
> need
> > > it)
> >
> >         Nope, the current hardware runs at 19200, the limit is the
> PC software side
>
> I guess I meant, "in general". If FTDI chips only emulate a serial
> port and can't run faster than a "normal" serial port, just seems like
> added complications with little bennifit.

        Agreed, I wasn't the one who suggested a USB solution, I personally don't
"like" USB so I rarely consider it.

> > > Clarify this sample rate issue for me. Is the sample rate based
> > > strictly on hardware (i.e. different clock can for different
> rate), or
> > > is it software based (i.e. widget on the PC client software)?
> >
> >         Strictly on hardware. The main bottlenecks on speed are the
> bandwidth of
> > the probes, the propagation speed of the CPLD and the write speed of
> the
> > memory. IIRC when I did some calcs I found the memory was the first
> > bottleneck to be hit. TTYL
> >
>
> Granted those would be upper limit concerns, but my question was
> pointed more towards daily usage. Is the sample rate software
> selectable over some range, or is it governed strictly in the
> hardware?

        The sample rate is fixed in hardware to 8 discrete steps: osc, osc/2,
osc/4, osc/8, osc/16. osc/32, osc/64 and osc/128 IIRC, osc being the
frequency of the oscillator feeding the CPLD.

        The CPLD also has a clock mux which allows the PIC to provide the clock,
this is used to download the sample from the memory, however there is
nothing stopping someone from modifying the PIC firmware to instruct the PIC
to provide the sample clock as well, in which case the sample rate could be
almost any speed below the PIC's running speed. TTYL

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body