Spin Semiconductor

Hi, sorry if this has been covered already - I was just wondering if someone could please confirm some test results for me and/or explain some observations:

On program change, it appears that the following happens:

- DACs store the last written value somewhere and are then held at 0.0
- All general purpose registers, ACC and PACC are cleared to 0.0
- All delay memory is cleared to 0.0
- After about 18ms (roughly 580 samples with a 32768Hz xtal), the new program is started
- One sample later, the DACs start outputting the last written value - even if it was from the previous progam or just during the first program iteration.

Firstly: Is the ~18ms delay a function of the sample rate? Or is this dictated by other factors, like EEPROM access? If the delay is related to the sample rate, what is the actual value? For a given sample rate, is it possible to predict what the delay is going to be?

Secondly: It seems like no matter what happens in the first iteration of the program, any writes to DACL and DACR, even though they definitely 'stick' are replaced with 0.0. Is this deliberate, normal and correct? Is it perhaps something to do with the RUN flag for the skp operation?

From my testing, the second sample is definitely getting out, it's just the first one that seems to disappear.

Any info would be greatly appreciated. Thanks!

ndf wrote: ↑Mon Jul 29, 2019 2:38 pm - DACs store the last written value somewhere and are then held at 0.0

The last written is not stored, outputs are set to 0

ndf wrote: ↑Mon Jul 29, 2019 2:38 pm - All general purpose registers, ACC and PACC are cleared to 0.0
- All delay memory is cleared to 0.0
- After about 18ms (roughly 580 samples with a 32768Hz xtal), the new program is started

Yup

ndf wrote: ↑Mon Jul 29, 2019 2:38 pm - One sample later, the DACs start outputting the last written value - even if it was from the previous progam or just during the first program iteration.

Should be outputting 0 or the results of the new program

ndf wrote: ↑Mon Jul 29, 2019 2:38 pm Firstly: Is the ~18ms delay a function of the sample rate? Or is this dictated by other factors, like EEPROM access? If the delay is related to the sample rate, what is the actual value? For a given sample rate, is it possible to predict what the delay is going to be?

Depends on a number of variables, in the case of selecting a program from the internal ROM the time it takes to clear the delay RAM is the main factor, if reading from an EEPROM then the time to read in from the EEPROM. And when the program change starts depends on when the inputs change and if you pass multiple selections and bounce in the switches. Best I can suggest is find the longest time from experimenting, add a little buffer time and use that.

ndf wrote: ↑Mon Jul 29, 2019 2:38 pm Secondly: It seems like no matter what happens in the first iteration of the program, any writes to DACL and DACR, even though they definitely 'stick' are replaced with 0.0. Is this deliberate, normal and correct? Is it perhaps something to do with the RUN flag for the skp operation?

DAC outputs are ramped up so the first sample is "lost" as the volume is 0.

Thanks heaps Frank, that makes perfect sense now.

frank wrote: ↑Tue Jul 30, 2019 8:23 am The last written is not stored, outputs are set to 0

That seems contrary to the test results I've observed - If you create two programs, the first one sets DACL to some fixed, non-zero value:

or 0x400000
wrax DACL,0.0

And then a second program that is empty (ie all NOP). Run the first program and then run the second program, the DACL output is muted on the program change, but then it goes back to the last value written by the previous program.

ndf wrote: ↑Tue Jul 30, 2019 6:38 pm Thanks heaps Frank, that makes perfect sense now.

frank wrote: ↑Tue Jul 30, 2019 8:23 am The last written is not stored, outputs are set to 0

That seems contrary to the test results I've observed - If you create two programs, the first one sets DACL to some fixed, non-zero value:

or 0x400000
wrax DACL,0.0

And then a second program that is empty (ie all NOP). Run the first program and then run the second program, the DACL output is muted on the program change, but then it goes back to the last value written by the previous program.

That may be true, I did not design the DACs and this is how they were explained to me. It is possible Keith changed his mind and did not tell me.