Question about cogs, dacs and pins

Reinhard

Suppose I have more cogs running. Everyone creates a different waveform. It is certainly allowed that I can output each waveform on the same dac/pin. Maybe that's a stupid question, but I want to be sure I won't break anything.
edit: what I mean is an addition from two or more waveforms in hardware.
Reinhard

cgracey

Reinhardt, don't worry. You're not going to break anything. You just must be careful about not exposing I/O pins or Vxxxx pins to >4V.

To mix two signals into a DAC, they would need to be summed before setting the DAC output value. You can use some locations in hub RAM for cogs to write their values into. The cog that sets the DAC would read and sum the valuea, then set the DAC.

Reinhard

Yes, that's the more elegant way.
I then just have to make sure that the individual samples are then added and output synchronously. This has something to do with the LOCK mechanism. I'll take a closer look at that.
Thank you.

cgracey

You don't need LOCKs. Just read the locations that the other cogs are writing their data into. There are no conflicts to worry about.

Reinhard

Yes, I tested that. It works perfectly. Sometimes I think too complicated.

Reinhard

that's what i wanted to show. I have to move from sequential to parallel thinking.
maybe like an FPGA.

// --------------------------------------------------
// DSP_Lab/synth1.c : 
// cog1 -> ramp -> cog1_sample 
// cog2 -> step -> cog2_sample
// cog3 -> cog1_sample + cog2_sample -> cog3_add
// cog4 -> filter(cog3_add) -> cog4_filtered
// cog0 -> cog3_add -> DAC/P0 ; cog4_filtered -> DAC2/P2
// --------------------------------------------------

evanh

Neat. Running the code myself, using -D __HP__, I'm not getting the same filtered results though.
Here's result of 80MHz sysclock and 320MHz sysclock:

Reinhard

sorry, I forget to give this info.

fastspin -2b -D__LP__ --fixedreal synth1.c

evanh

Ah, thanks, that looks better.

Reinhard

This is another demo:
a piano octave on the keyboard, C ... C #, with mixer and filter effects.
Not as spectacular as Ahles mix / driver, but it's a completely different approach.
When you compile

fastspin -2b --fixedreal synth2.c
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2020 Total Spectrum Software Inc.
Version 4.1.0 Compiled on: Jan 25 2020
synth2.c
ftab.c
fputs.c
sleep.c
fmt.c
synth2.p2asm
Done.
Program size is 5920 bytes

and load, you get this menu:

loadp2  -t -b 230400 -p/dev/ttyUSB0 synth2.binary
( Entering terminal mode.  Press Ctrl-] to exit. )
cog 0 main started
cog 1 tone1 started
use the keyboard as one octave piano  -- qwertz --
 w e   t z u
a s d f g h j k
1 ... Filter on     0 ... Filter off
+ ... Effect on     - ... Effect off
+1a-0

then you need an Osci on P0/P2 or change the pins .

evanh

Huh, fastspin -O2 doesn't work. Took me a few edits before I realised that might be the problem.

Used the audio accessory on P6 and P7. Lol, a piano it isn't.

evanh

-O1 works fine.

I note that -O2 creates a call to FCACHE_LOAD_ at the tone1() while loop, just after the audio init. There is an audible click so I figure the init occurs but the audio loop never seems to run. There is no tone.

EDIT: Oh, it might be the cordic optimising code, it seems to have dropped the GETQX instructions ...

evanh

I'm not sure why, but, I think, by merging the three __asm{}'s together seems to have fixed it.

Here's a more optimised arrangement. Note I've added a preceding GETQX, this is just precautionary clearing of any dead result catching of prior errant cordic op. It only handles a single op in the pipeline so isn't a perfect solution.

	__asm {
		getqx	sample1
		qrotate	amp,phi1
		add	phi1,localfrq1
		qrotate	amp,phi2
		add	phi2,localfrq2
		qrotate	amp,phi3
		add	phi3,localfrq3
		getqx	sample1
		getqx	sample2
		getqx	sample3
	};	

EDIT: Ha! -O2 optimisation eliminates that preceding GETQX. So much for precautions.

EDIT2: Thinking about it now, the preceding GETQX isn't likely to help in compiled code. It is a problem with buggy aborts from heavily pipelined hand crafted assembly.

Reinhard

I'm sorry you have such problems. I should have said more about what to expect. Let's start again. Change the line global_frq2 = 330 to global_frq2 = 0 in the main.
Then no signals are generated.
if you then press 'a' on the keyboard, a frequency of 262 Hz is output on one channel.
At 's' -> 278 Hz etc. to 'k' -> 524 Hz. This is an octave on the scale. Something is only output on the other channel if the filter is switched on. The other two global frequencies are there for summation, which then results in a beat. I didn't use any optimization. and with --fixedreal there are no problems with the float constants either.

Reinhard

if you change the filter coefficient, like in the attached file, you can see the filter maximun is at 350Hz. Left and right from this, the amplitude goes lower.

evanh

It's working fine. I was just digging into why Fastspin's optimiser was killing it is all. I had followed up in the main Fastspin topic - https://forums.parallax.com/discussion/comment/1488675/#Comment_1488675 and Eric is fixing it. All sorted.