First off, I searched the forum for solutions but couldn’t find anything that helps.
I have two related questions:
How do I set up a sample project like, say pod/MultiEffect, in Visual Studio 2022? There is no .sln file. I can open the folder in VS… and then what? Basically, I want to be able to jump back and forth between MultiEffect.cpp and the libDaisy + DaisySP code.
This link describes something similar and I followed the steps:
It’s a new embedded project and I added to the solution the libDaisy and DaisySP projects.
However, when I build from VS, I get errors in libDaisy. (I have this thread about it: https://forum.electro-smith.com/t/sdram-c-not-found-in-libdaisy/2578/2
At this point I’m stuck and would appreciate any input.
I might go crazy with this stuff soon…
I resolved some of the libDaisy build errors that looks like were happening due to folder conflicts in the STM32 Devices installation. I had a set of older HAL drivers in my project folder and newer ones in the /AppData/Local/xxx installation.
I simply copied the newer folders and overwrote the older ones in my project folder. Now I’m getting different errors that are not due to my setup anymore.
Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_dma.c:302:26: error: ‘DMA_SxCR_TRBUFF’ undeclared
The include is stm32h7xx_hal.h, but there is no DMA_SxCR_TRBUFF in that header file, or in any file for that matter.
It looks like the STM32 Devices installation came with missing stuff… Any suggestion what I could do? I’ve been running in circles for hours.
BTW, rebuild_all.sh works fine with libDaisy, it’s the build inside Visual Studio that fails.
Well… it’s official, DMA_SxCR_TRBUFF is not fully implemented.
The STM release notes state:
Add support for DMA_SxCR_TRBUFF
I’m not sure what to say, this is a first… I never encountered a situation where the software is knowingly released with bugs.
I don’t know how to make Visual Studio ignore those issues when building.
It looks like no one here experienced anything similar, probably everyone uses rebuild_all.sh or has an older, functioning version in their VS. I guess down I go the rabbit hole again looking for some fix.
I got again from Github the drivers from the libDaisy repository
I don’t get anymore any errors in STM like I was getting for DMA_SxCR_TRBUFF.
However, in libdaisy.vcxproj.filters and libdaisy.vcxproj there are many compiler references to various .h and .c files that simply don’t exist. I removed them manually from those two files and the libDaisy builds now successfully from Visual Studio build. Not sure though if this will have a negative impact.
All in all, the implementation of the libDaisy VS solution seems to not be mature at this point. I wish I had known this from the beginning and save me the many hours chasing my tail.