[sdiy] Last chance for 4xD PCB order

[Seb Francis]

>>> 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".

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.

* Actually according to my rough calculations below you could forget the 
'new value' detection logic and just transmit continuously sampled 
values without clogging the SPI communication (but then the LED display 
will become unreadable, and since you will be continuously flagging that 
the values should be stored in flash, this will get written to every 
10.7s, and after 124 days of continuous operation you will  exceed the 
typical EEPROM endurance rating).

>
> 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.

> 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.

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.  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 ...

Seb

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