Question about cogs, dacs and pins

ReinhardReinhard Posts: 384
edited 2020-01-30 - 12:54:03 in Propeller 2
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

Comments

  • 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.
  • 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.
  • 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.
  • Yes, I tested that. It works perfectly. Sometimes I think too complicated.
  • 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
    // --------------------------------------------------
    
    800 x 480 - 132K
    c
    c
  • 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:
    640 x 480 - 16K
    640 x 480 - 17K
  • sorry, I forget to give this info.
    fastspin -2b -D__LP__ --fixedreal synth1.c
    
  • Ah, thanks, that looks better. :)
  • ReinhardReinhard Posts: 384
    edited 2020-02-01 - 12:11:56
    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 .
  • 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.

  • evanhevanh Posts: 9,015
    edited 2020-02-02 - 00:06:11
    -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 ...

  • evanhevanh Posts: 9,015
    edited 2020-02-02 - 01:55:38
    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.
  • 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.
  • ReinhardReinhard Posts: 384
    edited 2020-02-02 - 07:22:18
    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.
    c
    c
  • 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. :)

Sign In or Register to comment.