[sdiy] Last chance for 4xD PCB order

[Andre Majorel]

On 2006-07-16 21:28 +0100, Seb Francis wrote:
> 
> >>>If adding VC delay involves sacrificing rotary encoders, that's
> >>>fine ; once I have VC, I expect I won't have any use for them
> >>>except perhaps a coarse delay range control per channel (and
> >>>even that might not be needed at all).
> >>>      
> >>Well, this is another option: sacrificing rotary encoders will give you 
> >>2 CV inputs to the UI PIC per sacrificed encoder (up to a maximum of 8 
> >>CVs).  But doing it this way you would need to provide your own CV input 
> >>buffers off-board, and the achievable max sampling rate and resolution 
> >>would be lower.  On the plus side though, you could update the LED 
> >>display, internally held rotary encoder positions and flash RAM from the 
> >>CVs.
> >>    
> >
> >So ditching the rotary encoders and routing each CV input to
> >both the SPI and the UI PIC, we could have both VC delay time
> >and delay time display, yes ?
> 
> I'm not sure what you mean by "routing each CV input to both the SPI
> and the UI PIC".

Each CV input is fed to both one dsPIC ADC (for direct, high
speed control of the delay time) and one UI PIC ADC (for delay
time display).

> Routing 4 CV inputs to the UI PIC (in place of 2 of the rotary
> encoders) will allow you to sample these CVs.  You will need some code
> to detect* a new CV value (possibly will need some hysteresis logic to
> avoid falsely triggering when the CV isn't changing).  When a new
> value is detected you can treat this in the same way as if someone has
> turned one of the rotary encoders, or sent a MIDI message: i.e. send
> an SPI message to the appropriate dsPIC, display the value on the LED,
> and flag that the value should be stored in the flash RAM.

Sounds good to me.

> >The sampling rate and resolution limits are non-issues here, I
> >think.
> 
> The UI PIC has a "10 bit" A/D converter, but in my experience with PICs 
> this resolution is rarely achieved without proper external voltage 
> references and special layout considerations, so I would assume 
> something like 8 bit (makes the maths easier as well!)
> 
> With a 12.500 MHz clock, min A/D acquisition time is 30.72us which 
> equates to ~32kHz or ~8kHz per CV.  See below for discussion of whether 
> there's enough CPU time for this rate of sampling.

I was thinking along the lines of 5 Hz ! Anything faster than
that is wasted unless you can read faster than I do.

> >It would be nice to have sub-ms display precision for
> >short delays, but so would having it delivered to me by a group
> >of promiscuous, scantily-dressed girls.
> 
> There is sub-ms precision by default (anything less than 1ms is 
> displayed 0.n).  The default software uses an 8 bit value for each delay 
> time as follows:
> 0 - 0ms
> 1 - 0.1ms
> 10 - 1ms
> 11 - 2ms
> 109 - 100ms
> 110 - 102ms
> 159 - 200ms
> 160 - 205ms
> 253 - 670ms
> 
> These 8-bit values on the left are actually how the data is sent to the 
> dsPICs where it is then converted into the actual delay time in samples.

It's an exponential-ish scale ? Excellent. That solves the
accuracy issue.

> This stepped delay time increment suits panel controls as it avoids 
> having to turn the knobs quite so many times to set the larger delay 
> times, and of course the internal software LFOs modify the delay times 
> smoothly without steps.  However, I would imagine with a CV you will 
> want a non-stepped response, so you will probably need to set the delay 
> time range with an encoder and make a calculation to map it to the 
> expected 8-bit value.

Well, no, I'll follow your suggestion of controlling the actual
delay time without going through the UI PIC. The CV fed to the
UI PIC will only be there for display. It will have no influence
on the dsPIC. And should that mean losing the software LFOs,
I'll happily sacrifice them on the altar of VC.

> This calculation will likely burn plenty of CPU cycles in the
> UI PIC (as the 16FXX PICs have no single cycle multiply
> instruction) so the sampling frequency may well suffer.  Some
> 'back of envelope' calculations ...
> 
> 8bit x 8bit multiply = up to 73 instruction clocks
> Call it 100 instructions in all per CV sample for other CV
> sampling logic
> That's 400 instructions for 4 CVs
> At 3.125 MIPS that's 7.8125kHz
> But you can't use all the CPU time just for this, so think more like 
> 4kHz max sampling rate.  Better still, think 2kHz max to be safe as 
> these are very rough calculations.  The SPI communication to
> the dsPICs is plenty fast enough for these sampling rates.
> 
> In summary, I would say that if you want smoothly operating, high 
> resolution CV control over the delay time you might be better just 
> sampling the CVs directly in the dsPICs - I suppose you could *also* 
> sample the CVs in the UI PIC just for display purposes ...

Yes, that's the idea. Although 2 kHz is probably good enough.

> P.S. The promiscuous, scantily-dressed girls I'm afraid you
> will have to arrange for yourself ;)

So that's the catch !

Thanks again.

-- 
André Majorel <URL:http://www.teaser.fr/~amajorel/>
Do not use this account for regular correspondence.
See the URL above for contact information.