2025-01-09 12:56 AM
2025-01-09 1:05 AM
Stm32F1 and stm32L4 both have arm cortex M processors.
What problems do you get offering the STM32F1 assembly files to an assembler for L4?
2025-01-09 1:28 AM - edited 2025-01-09 1:29 AM
STM32F1 uses M3 core
STM32L4 uses M4 core
I do not want to put a lot effort into getting it to work if there is an obvious issue.
2025-01-09 7:02 AM
Opus is BSD licensed. If that works for you you can use a non-ST port/implementation of OPUS.
https://opus-codec.org/license/
https://github.com/xiph/opus
2025-01-13 1:39 AM
Problem with Opus is the flash size, not the license.
2025-01-13 11:06 AM - edited 2025-01-22 7:52 AM
Have you tried porting the speex library? What assembler files need to be ported? I can't find the example.
2025-01-15 5:25 AM
No, I wrote I donot put effort in something that already have issues.
The STM32F1 code is not at ST website, but found it here
2025-01-15 7:48 AM
Cortex-M4 is a superset of Cortex-M3.
JW
2025-01-16 1:39 AM
@RFlod.2 wrote:No, I wrote I donot put effort in something that already have issues.
What issues? Do you get compile errors or doesn't the program operate properly?
Like @waclawek.jan wrote the M4 is a superset of the M3. So inline assembly should work.
If not use C code instead of assembly code. If that doesn't perform enough you can try to see if you can use CMSIS DSP library: https://github.com/ARM-software/CMSIS-DSP
2025-01-16 2:00 AM
It wil take time to implement and verify this implementation.. It would be preferable to use an existing working solution.
Debugging assembler is something I would like to avoid. Even though the core might be compatible there can be callls to other oarthe in the STM32 which are not compatible.
We’re moving the ST Community to a new platform to give you a better and more reliable community experience.