[sdiy] Parallel processing clock design question

[phillip m gallo]

I wouldn't waste the foreground.

Consider the task. If the task has dynamism it should probably occur in the
foreground.

The example "moog filter" perhaps has an accompanying ADSR.  Generating the
ADSR, and the espression of the ADSR current value against any "wave data"
is an obvious foreground task.

The concern for interrupt latency can be ameliorated by generating data
"behind by 1 clock tick",
that is, the interrupt generates data to be used at the next clock
occurance. This allows for variable interrupt latency or variable
(conditional) interrupt service execution lengths (always shorter than the
interrupt period).

If the clock causes the "use" of the data generated with the last clock
occurance without processor intervention ("i.e. latches data into a DAC) no
indeterminite "jitter" results.

regards,
p



let's try not to kill ourselves over one or two
micro's cycles. Cant say about AVR, but in PIC
it would look like:

using interrupt:

main_loop:
     goto main_loop
interrupt:
     call minimoog_vcf   ;whatever instruction of interest
     .
     .
     .
     bcf INTF        ;clear interrupt flag
     retfie

using polling:

main_loop:
     btfss SAMPLEin
     goto main_loop
     call minimoog_vcf
     .
     .
     .
wait_until_clock_low:
     btfsc SAMPLEin
     goto wait_until_clock_low
     goto main_loop

so actually, polling requires one more instruction to enter than
interrupting. We don't need to save anything after interrupt, so it doesn't
require any overhead. And when returning to the main loop we must make sure
that sample clock is already LOW, otherwise it'd enter the loop again within
same sample time.

Roman
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.500 / Virus Database: 298 - Release Date: 7/10/03