blackfin control rate about aleph HOT 4 OPEN

implemented in a basic way.
( 14683da )
could be a more elegant queue structure.

from aleph.

reopening this. never had time to do a satisfactory implementation and reverted to direct-set from the spi rx isr (bad). still storing global copy of module parameter data, with dirty flag, which is burning resources but will probably be useful.

aleph/dsp/module.h
aleph/bfin_lib/src/spi.c

from aleph.

not super sure this is related but I'm working on a separate spi event message, the idea is to send just an empty message which calls a module_event(), typically some kind of trigger or next step happening, this part is done. Hoping to add a filter somewhere in the spi process to so that events always are handled before parameter changes.

update with added links to code...

creating an event from an incoming cv trig,
https://github.com/electropourlaction/aleph/blob/dev/apps/prgm/src/handler.c#L32-34

spi transfer, ending with a call to module_set_event()
https://github.com/electropourlaction/aleph/blob/dev/avr32_lib/src/bfin.h#L76
https://github.com/electropourlaction/aleph/blob/dev/avr32_lib/src/bfin.c#L346-351
https://github.com/electropourlaction/aleph/blob/dev/common/protocol.h#L28
https://github.com/electropourlaction/aleph/blob/dev/bfin_lib/src/spi.c#L89-92
https://github.com/electropourlaction/aleph/blob/dev/dsp/module.h#L58

stuff happens, module specific implementation,
https://github.com/electropourlaction/aleph/blob/dev/modules/prgm/prgm.c#L401-418

from aleph.

i'm referring to a broader change in the architecture wherein control changes would be processed at a fixed rate on the blackfin, slower than the audio rate, instead of directly from the SPI RX interrupt.

our current strategy is to use the bfin_ready GPIO to hold off sending from the avr32 until bfin is not currently processing an audio frame, and assuming that this means it has time to process an SPI transaction before the next audio frame. seems to work pretty well...

but i'm working on restructuring the whole mess to something like this:

• maintain an 8- or 16-frame sample buffer for audio I/O
• read and write to this buffer on audio ISR
• main loop processes the whole buffer (instead of a single frame)

a complementary step would be to maintain a similar buffer for control changes, push param changes / events in SPI ISR, and process them in main loop once per audio block.

from aleph.