You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey team,
I have had this issue with several projects now (Tuft2040) and the latest was the BME68X and LTR559.
I am no CMake ninja by any standards. I fully admit that. But seeing a common theme after spending countless hours copy/pasting files as well as trying to edit CMakeLists.txt files has been eye opening that I think something's not right in the C/C++ boilerplate or the Pimoroni SDK.
Ironically I followed the instructions and I was able to build ALL the projects on the GitHub site (for the Pico) so I have U2Fs of all of them. However this doesn't help me, as all my projects like most people are a combination of chips doing things etc...
Here is the issue I'm seeing. I have followed all the documentation. I copied the Pimoroni for a 2nd time into where I build my projects as it says to do. I've set the ENV Variable in my .bashrc file for the Pimoroni SDK.
So first attempt I did it the "dumb" way. I took every folder the project required, usually /common /libraries /drivers. and copied them into my Visual Studio Code project along with all the respective files (I did remove all of the sensors from the libraries and drivers folders and unpdated the CMakeLists to not look for them. So they basically only had one entry which was the chip I was working with I copied all the files from /common /libraries / drivers again for the chip I'm using (except common that gets copied completely).
I essentially built the exact folder structure tree that is on the GitHub site, case sensitive for all files, copy everything. Usually I'll get some error when I try to build about the SDK's which I clear out with a clean reconfigure / clean rebuild. It can find both SDK's Pimoroni and Pico's.
After all this I thought I was good, then I started browsing files and noticed they were complaining with squiggles saying files could not be found, tracing them back it usually turn out to be **pimoroni_common.hpp ** no matter what I did it didn't work. So the project was dead in the water.
Then I tried a more refined approach.
I didn't bring in all the files/folders into Visual Studio. I used the boilerplate, adjusted the libraries, used the ones listed as a guideline in the boilerplate. After some CMake struggles (again I'm not great at this) hey look at the build process threw no errors! I move on to compile. Things are looking good, its getting towards the very end no and then....womp womp. Cannot find pimoroni_common.hpp
At this point I knew it was reading the Pimoroni SDK because my VS project consisted of the demo.cpp and the CMakelists.txt (which was weird to me seeing a project with nothing but one file).
No matter what I tried pimoroni_common.hpp wouldn't work.
I found a previous issue reported in 2021 by someone else having an issue with I2C (which is in the common folder) he never got a solution from Pimoroni rather he created a workaround by creating a CMakelists file for it and adding it. (this thought had cross my mind awhile back but again not knowing CMAKE well I screwed it up probably).
I noticed that in the SDK /common had two .cmake files one for I2C and one for BUS /common DOES NOT have one for pimoronicommon. So I tried this guys approach again. I created a common.cmake file, edited based on what the I2C and BUS ones looked like and added it to the common/CMakelists.txt (which just calls the other make files). What do you know it worked!!! My program compiled and works (LTR559). What's troubling for me is I had to make changes to the SDK itself to make this work, what's going to happen with the next chip or the next? Editing the SDK seems sloppy and not the right way, but I don't know.
So here is my solution:
created in /common "pimoroni_common.cmake"
Pull in pico libraries that we need
target_link_libraries(${LIB_NAME} INTERFACE pico_stdlib hardware_spi hardware_i2c)
`
Then in the CmakeLists file located in the /common folder I added:
`
include(pimoroni_i2c.cmake)
include(pimoroni_bus.cmake)
include(pimoroni_common.cmake)
`
My VSCode CMakelists.txt that came from the boilerplate file looked like this now (there could be redundancies here or a better method but again CMake is confusing as heck to me. I have a book I'm reading to help me learn)
CMakelists.txt :
`
cmake_minimum_required(VERSION 3.18)
Change your executable name to something creative!
set(NAME LTR559) # <-- Name your project/executable here!
set(OUTPUT_NAME LTR559)
project(${NAME} C CXX ASM)
set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 17)
Initialize the SDK
pico_sdk_init()
Add your source files
add_executable(${NAME}
main.cpp
)
Include required libraries
This assumes pimoroni-pico is stored alongside your project
include(common/pimoroni_i2c)
include(common/pimoroni_common) <----------------I created this/added this
include(drivers/ltr559/ltr559)
include(libraries/breakout_ltr559/breakout_ltr559)
#add_library(${NAME} common/pimoroni_common.hpp) <---testing, commented out
#target_link_libraries(${PROJECT_NAME} pico_stdlib hardware_i2c) <---testing, commented out
#target_include_directories(${PROJECT_NAME} PUBLIC include) <---testing, commented out
I think the boilerplate and or the SDK need fixing in terms of having common/pimoroni_common.hpp found by the compiler.
I'm I am just doing something wrong please let me know, and examples help!
I think (my opinion) is that Pimoroni thinks if a user has gone the c/++ boilerplate route (versus Micropython) that they are super skilled, that is not always true. I don't know Micropython, eventually I'll learn it but I like and know C/C++. I think documentation for the boiler plate needs to be more deep in explanation as well as a few complete examples of a few chips in there fully commented and documented, that'll help people who are not wizards like me but still use C to program some help. That's just a personal hope/suggestion. the common/pimoroni_common.hpp I think is a legit flaw/bug/ect...
Please advise! I love your company and spend a fortune buying stuff all the time! I do need reliable methods to get the samples working though... Sorry I tried putting the code using the code brackets, I don't know why its not working. I moved all the code to line up with no leading white-spaces and no blank lines didn't help :(
Respectfully,
Anglerfish27
The text was updated successfully, but these errors were encountered:
Hey team,
I have had this issue with several projects now (Tuft2040) and the latest was the BME68X and LTR559.
I am no CMake ninja by any standards. I fully admit that. But seeing a common theme after spending countless hours copy/pasting files as well as trying to edit CMakeLists.txt files has been eye opening that I think something's not right in the C/C++ boilerplate or the Pimoroni SDK.
Ironically I followed the instructions and I was able to build ALL the projects on the GitHub site (for the Pico) so I have U2Fs of all of them. However this doesn't help me, as all my projects like most people are a combination of chips doing things etc...
Here is the issue I'm seeing. I have followed all the documentation. I copied the Pimoroni for a 2nd time into where I build my projects as it says to do. I've set the ENV Variable in my .bashrc file for the Pimoroni SDK.
So first attempt I did it the "dumb" way. I took every folder the project required, usually /common /libraries /drivers. and copied them into my Visual Studio Code project along with all the respective files (I did remove all of the sensors from the libraries and drivers folders and unpdated the CMakeLists to not look for them. So they basically only had one entry which was the chip I was working with I copied all the files from /common /libraries / drivers again for the chip I'm using (except common that gets copied completely).
I essentially built the exact folder structure tree that is on the GitHub site, case sensitive for all files, copy everything. Usually I'll get some error when I try to build about the SDK's which I clear out with a clean reconfigure / clean rebuild. It can find both SDK's Pimoroni and Pico's.
After all this I thought I was good, then I started browsing files and noticed they were complaining with squiggles saying files could not be found, tracing them back it usually turn out to be **pimoroni_common.hpp ** no matter what I did it didn't work. So the project was dead in the water.
Then I tried a more refined approach.
I didn't bring in all the files/folders into Visual Studio. I used the boilerplate, adjusted the libraries, used the ones listed as a guideline in the boilerplate. After some CMake struggles (again I'm not great at this) hey look at the build process threw no errors! I move on to compile. Things are looking good, its getting towards the very end no and then....womp womp. Cannot find pimoroni_common.hpp
At this point I knew it was reading the Pimoroni SDK because my VS project consisted of the demo.cpp and the CMakelists.txt (which was weird to me seeing a project with nothing but one file).
No matter what I tried pimoroni_common.hpp wouldn't work.
I found a previous issue reported in 2021 by someone else having an issue with I2C (which is in the common folder) he never got a solution from Pimoroni rather he created a workaround by creating a CMakelists file for it and adding it. (this thought had cross my mind awhile back but again not knowing CMAKE well I screwed it up probably).
I noticed that in the SDK /common had two .cmake files one for I2C and one for BUS /common DOES NOT have one for pimoronicommon. So I tried this guys approach again. I created a common.cmake file, edited based on what the I2C and BUS ones looked like and added it to the common/CMakelists.txt (which just calls the other make files). What do you know it worked!!! My program compiled and works (LTR559). What's troubling for me is I had to make changes to the SDK itself to make this work, what's going to happen with the next chip or the next? Editing the SDK seems sloppy and not the right way, but I don't know.
So here is my solution:
created in /common "pimoroni_common.cmake"
It contains:
`
set(LIB_NAME pimoroni_common)
add_library(${LIB_NAME} INTERFACE)
target_sources(${LIB_NAME} INTERFACE
${CMAKE_CURRENT_LIST_DIR}
)
#target_include_directories(${LIB_NAME} INTERFACE ${CMAKE_CURRENT_LIST_DIR})
Pull in pico libraries that we need
target_link_libraries(${LIB_NAME} INTERFACE pico_stdlib hardware_spi hardware_i2c)
`
Then in the CmakeLists file located in the /common folder I added:
`
include(pimoroni_i2c.cmake)
include(pimoroni_bus.cmake)
include(pimoroni_common.cmake)
`
My VSCode CMakelists.txt that came from the boilerplate file looked like this now (there could be redundancies here or a better method but again CMake is confusing as heck to me. I have a book I'm reading to help me learn)
CMakelists.txt :
`
cmake_minimum_required(VERSION 3.18)
Change your executable name to something creative!
set(NAME LTR559) # <-- Name your project/executable here!
set(OUTPUT_NAME LTR559)
include(pimoroni_pico_import.cmake)
include(pico_sdk_import.cmake)
Gooey boilerplate
project(${NAME} C CXX ASM)
set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 17)
Initialize the SDK
pico_sdk_init()
Add your source files
add_executable(${NAME}
main.cpp
)
Include required libraries
This assumes
pimoroni-pico
is stored alongside your projectinclude(common/pimoroni_i2c)
include(common/pimoroni_common) <----------------I created this/added this
include(drivers/ltr559/ltr559)
include(libraries/breakout_ltr559/breakout_ltr559)
#add_library(${NAME} common/pimoroni_common.hpp) <---testing, commented out
#target_link_libraries(${PROJECT_NAME} pico_stdlib hardware_i2c) <---testing, commented out
#target_include_directories(${PROJECT_NAME} PUBLIC include) <---testing, commented out
Don't forget to link the libraries you need!
target_link_libraries(${NAME}
pimoroni_i2c
pimoroni_common <------I added this
ltr559
pico_stdlib
hardware_i2c
pimoroni_i2c
breakout_ltr559
)
Enable usb output and uart
pico_enable_stdio_usb(${OUTPUT_NAME} 1)
pico_enable_stdio_uart(${OUTPUT_NAME} 1)
create map/bin/hex file etc.
pico_add_extra_outputs(${NAME})
`
I think the boilerplate and or the SDK need fixing in terms of having common/pimoroni_common.hpp found by the compiler.
I'm I am just doing something wrong please let me know, and examples help!
I think (my opinion) is that Pimoroni thinks if a user has gone the c/++ boilerplate route (versus Micropython) that they are super skilled, that is not always true. I don't know Micropython, eventually I'll learn it but I like and know C/C++. I think documentation for the boiler plate needs to be more deep in explanation as well as a few complete examples of a few chips in there fully commented and documented, that'll help people who are not wizards like me but still use C to program some help. That's just a personal hope/suggestion. the common/pimoroni_common.hpp I think is a legit flaw/bug/ect...
Please advise! I love your company and spend a fortune buying stuff all the time! I do need reliable methods to get the samples working though... Sorry I tried putting the code using the code brackets, I don't know why its not working. I moved all the code to line up with no leading white-spaces and no blank lines didn't help :(
Respectfully,
Anglerfish27
The text was updated successfully, but these errors were encountered: