Without the added part, the program generates an 8 kHz sine wave on pin PB7 (stm32f103), when the if function is added, I expect a square wave on pin PC13, but there is no signal on PC13, and on PB7 the sine wave also disappears
as @alto777 already posted the only place the led pin is changing is inside the function init_wave(). So it will be performed once and as quick as the controller handles the for-loop. It could be solved with a specific wave data array and DMA routine or a separate timer function.
I guess the compiler is clever enough to recognize that the term sin(stp * i) does not change inside the for-loop and it will use the value without calling the function again. It does not matter in a setup() function but it might be a good idea to store this kind of data if the same, unchanged value is used at different places in the code.
BTW: Shouldn't the function init_wave() be called before dma_start() as init_wave() creates the data that are used by the DMA routine? Not essential, but might be cleaner.
How are you measuring this? If you try to make a measurement after the 130 iterations of the for loop have completed, you will see a constant LOW voltage on Pin 13 (assuming that LED_BUILTIN==13 on your board).
Probably because the variable PWM appears to be undefined, and because you call dma_conf() before calling init_wave().
But it does, stp * i marches right from 0 to 2 * pi.
The expression guarding the digitalWrite()s yields zeros for the first half and ones for the second half of the circle.
But
while true in some sense, is not what @tom321 is going for. I think the intent is to have a square wave auto-interrupt-generated along side the sin wave.
For that, something will have to be done not just in setup() once. The stupid solution is to use init_wave() to build a second table for the digital output that will be the square wave.
If you look at the entire sketch and squint, init_wave() serves to initialize an array used subsequently to provide a continuous sine wave output. Those calculations are done once at setup(), so speed isn't much of an issue.
Toggling an output bit there while building the table is nonsense.
Perhaps @tom321 will elaborate on the circuitry and what the idea of the sketch is with a bit more detail around IRS and DMA. There may be an easy way to set up (another) interrupt-driven function to do the toggling in synch.
What I wanted to say is that term sin(stp * i) is used two times inside the for-loop and the value of (stp * i) does not change from the first to the second use.
I assume the compiler will recognize this case and not call sin() a second time with an identical value to shorten the execution time.
Sorry for the misunderstanding.
Creating a second wave table may not be the most elegant solution but it's a valid one that provides easy possibilities to change from square wave to other wave forms like sawtooth or triangle. And it's easy to implement a second DMA channel as the mechanism is already there.
It depends on what the TO wants to achieve... Which is still unknown.