Electronics > Microcontrollers

Starting with STM32 (NUCLEO-L412KB)

<< < (43/43)

dietert1:
With analog audio the voltage represents acceleration (proportional to force of air pressure).
To go from the velocity measurement of a Doppler system to audio one needs one differentiator.
To convert a position measurement to analog audio one needs two differentiators to first derive speed and then acceleration. At high frequencies a position measurement doesn't work well.
But is has been done, for example in the famous active speakers of Backes & Müller. They built kind of a capacitor microphone into the tweeter to get the dome position. Capacitance was small and the first derivative happened by measuring capacitive displacement currents.

Regards, Dieter

gf:

--- Quote from: Picuino on June 02, 2024, 08:22:18 am ---Compiling the previous example, a warning has appeared about the variables that catches my attention.

../Core/Src/filter.c:20:20: warning: initialization discards 'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers]

In the following line of code:

--- Code: ---    uint16_t *p1 = &adc1_buff[init];
--- End code ---

adc1_buff is volatile. Perhaps the compiler is asking for the pointer to a volatile to be volatile as well?

--- End quote ---

Yes, if adc1_buff[] is volatile, then it expects a pointer to a volatile destination, otherwise the volatile qualifier is lost and and the accesses of the function to adc1_buff[] are not volatile. Therefore the warning.

Unfortunately, gcc emits more instructions if the pointer destination is volatile :(

But I do not see a stringent need for declaring adc1_buff[] volatile. I can hardly imagine a situation where the generated code would not reload the buffer contents from memory each time the function is executed. To be on the safe side when the function happens to be inlined in another function multiple times in a row or in a loop, you can add a compiler barrier to the very beginning of the function.


--- Quote ---On other occasions compiler optimizations have led to not updating the buffer by not declaring it volatile.

--- End quote ---

I think when you encountered this problem, you had declared the buffer as a local variable inside the function.

Picuino:
The other time I had a problem was with the output DAC buffer. First the buffer was defined as global, but not volatile. A loop is in charge of updating the buffer contents to generate a sine wave, but the compiler detects that the program does nothing with the buffer contents and the first position was not written:

https://www.eevblog.com/forum/microcontrollers/starting-with-stm32-(nucleo-l412kb)/msg5516341/#msg5516341

After defining the buffer as volatile, the problem disappeared.

I will look into adding a compiler barrier.

gf:

--- Quote from: Picuino on June 02, 2024, 04:48:29 pm ---The other time I had a problem was with the output DAC buffer. First the buffer was defined as global, but not volatile. A loop is in charge of updating the buffer contents to generate a sine wave, but the compiler detects that the program does nothing with the buffer contents and the first position was not written:

https://www.eevblog.com/forum/microcontrollers/starting-with-stm32-(nucleo-l412kb)/msg5516341/#msg5516341

After defining the buffer as volatile, the problem disappeared.

--- End quote ---

See https://godbolt.org/z/MdqTYMqoP
I cannot see a problem in the emitted assembly code, IMO it does what it should do.
Unfortunately you did not provide enough context, but only the 3 lines of the loop. So I can't see what you have really done.

A couple of posts earlier (https://www.eevblog.com/forum/microcontrollers/starting-with-stm32-(nucleo-l412kb)/msg5515009/#msg5515009) you definitively did define dac1_buff[] as local variable inside main(), and not global.


--- Code: ---int main(void) {
    ...
    uint16_t dac1_buff[1000];
    for (int i = 0; i < 1000; i++) {
        dac1_buff[i] = i * 4;
    }
    ...
}

--- End code ---

Picuino:
Yes, in that case the variable was declared as local. Now it is declared as global in the dac.c file. I don't remember when I changed it, I think it was before I had that problem, but I don't know.

The best way to check if there is a problem with this is to run the program and see its output. If it is as expected, then I guess all is well.

Anyway I have re-declared the variables as volatile and with the code enhancement it is still very fast.

As soon as I get the second filter with decimation up and running, I'll post the code.

For now I post the provisional code as it is at the moment.

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod