Compile using STM CubeIDE

[BitLoose]

Has anyone used the STM Cube IDE to compile this?
I´ve loaded it okay into Cube, just getting a make file error so will check my Make installation next
make: ../Makefile:263: pipe: No such file or directory

[db4ple]

Hi,

sorry, this is not supported. I haven't heard from anyone doing this, let alone having success with it.

You should stick with the setup for development as documented in the Wiki using Eclipse Embedded CDT.

You can also compile using make on the command line if you more of the command line person.

73
Danilo

[BitLoose]

Hi, I've just found M0NKA's STM CubeIDE version, his ReadME states "This directory contains SW4STM32 and CubeIDE compatible project that allows easy import to any of those tools".
It's compiled fine apart from missing a number of Audio links, AudioReverb_Calc, IIR_100hz_500 etc, so it is there.

[BitLoose]

The linker is outputting "mchf-uhsdr.elf section .ccm' will not fit in region ram1'", so I swapped ram1 to the larger section that's 128K long to solve it, is this a known issue?
MEMORY
{
rom (rx) : ORIGIN = 0x08010000, LENGTH = 1024k - 64k
ram1 (rwx) : ORIGIN = 0x20000000, LENGTH = 128k (was ram)
ram (rwx) : ORIGIN = 0x10000000, LENGTH = 64k (was ram1)
}

I'm also getting undefined symbol errors yet within the editor it has no problem opening the declaration, which is unusual:-
d:\st\stm32cubeide_1.10.1\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: ./mchf-eclipse/drivers/audio/audio_driver.o: in function AudioDriver_I2SCallback': audio_driver.c:(.text.AudioDriver_I2SCallback+0x1118): undefined reference to is_demod_rtty' <-- this is an inline function, why would the linker not be able to see it?

I'd like to use STMCubeIDE if possible for the debugging facilities. Is it possible to get it working?

[db4ple]

Hi,

swapping ram is not a solution. It may make the system compile but it will not work.
The larger RAM is the main ram and holds the run-time stack which requires (depending on the configuration. significant amount of RAM) RAM1 is not able to receive DMA transfers, so even if the stack requirement would be there swapping these will break the system. Have a look at the memory description in reference manual for the processor.

However, it is a known challenge that ram1 is a very tight fit. Nevertheless, it fits with the right compiler (and settings).

"Graphical" debugging is also possible with the Eclipse CDT setup.

I am sorry that I was not aware the SW4STM32 and CubeIDE are somehow the same thing. But it also explains why I cannot help you with this environment. Maybe someone else can chime in here... otherwise you have to figure it out by yourself.

I advise strongly against playing with the linker scripts, though.

Your easiest option: Turning off some features, especially FreeDV will significantly reduce the memory requirements so this should allow you to build a system AND then work from there.

You can set the define IS_SMALL_BUILD to achieve this either in your IDE as parameter to the build or just uncomment this line in the source

UHSDR/mchf-eclipse/hardware/uhsdr_board_config.h

Line 117 in 0348876

// #define IS_SMALL_BUILD

[BitLoose]

Hi, thanks, after some midnight oil I managed to get it working, lots of fiddling with the code, paths, etc, quite painful but now its all compiling in the correct section.
Amazing that the compiled program is so big, 621 KB, massive really. It´s a very impressive piece of work, Kudos to the developers!

[df8oe]

This is widely dependent on the way the compiler builds binaries together. For "production" I stick on gcc-arm-none-eabi-8-2019-q3-update which is quite outdated but which produces a much, much smaller binary. For compare look at the binaries which are published here: https://df8oe.github.io/UHSDR/ All gcc which have been released later produce binaries which are 40 percent bigger. We never investigated why.

[BitLoose]

From the .map file there is 802 KB of ROM used, and 290 KB used by these three libs:-

Newamp USB streaming library: "newamp1vq_cb";"0x080a1cac";"0x080a1cac";"80.05 KB"
lsp_codebook: "lsp_cbjvm";"0x08097c6c";"0x08097c6c";"40.06 KB"
Complex FFT tables: "twiddleCoef_4096";"0x0807d5a4";"0x0807d5a4";"32 KB" + 140KB in related Coef allocations

Is the older library you mention the CMSIS-DSP lib, as I just found this comment, but can't find the related flag or config.hpp file:-

"Unfortunately, the latest CMSIS library opts for the fastest possible speed at the expense of ROM (more detail than is probably interesting here, but they’re using a mixed radix FFT)

However, they have a prior version that, with some patching, is almost as fast (and still uses HW acceleration), BUT, has the added benefit of very little ROM cost. (TMI: radix 2 FFT with one table for all FFT sizes)

We’re working on this patch and once it’s released, the EIDSP_USE_CMSIS_DSP flag will cost far less ROM."

[db4ple]

All of the libraries mentioned are related to FreeDV / Codec2 AFAIR. Disable FreeDV (search for #define USE_FREEDV) in board_config.h) and check the difference.

[BitLoose]

I think it's worth finding out why the memory has jumped up so much, could be affecting performance, and maybe the code can be reduced to under 256 kb for the 32f401 chip. I've been looking at the code and the spi dma LCD support seems set for 32f7 and 32h7 MCUs only, and chip hardware i/o memory mapping of the lcd i cannot find anywhere. Any ideas? Is anyone actively working on improving the code? Such a great project it deserves support. 73 Rob On 31 Oct 2022 07:45, DF8OE ***@***.***> wrote: This is widely dependent on the way the compiler builds binaries together. For "production" I stick on gcc-arm-none-eabi-8-2019-q3-update which is quite outdated but which produces a much, much smaller binary. For compare look at the binaries which are published here: https://df8oe.github.io/UHSDR/ All gcc which have been released later produce binaries which are 40 percent bigger. We never investigated why. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[BitLoose]

Thanks for the tip, appreciated. 73On 2 Nov 2022 16:44, db4ple ***@***.***> wrote: All of the libraries mentioned are related to FreeDV / Codec2 AFAIR. Disable FreeDV (search for #define USE_FREEDV) in board_config.h) and check the difference. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>