2024-04-30 02:49 AM - last edited on 2024-07-03 08:13 AM by Amel NASRI
I'm developing an end-node based on the STM32 Nucleo-L476RG with a LoRa module SX1272MB2DAS and a Grove sensor (based on DHT11). I'm facing a dilemma regarding how to retrieve data from the sensor. I'm torn between two options: modifying the data retrieval method in the I-Cube-Lrwan example (rather than using I2C) or implementing my own middleware in a new project. Which approach would you recommend, and how could I effectively implement it?
2024-04-30 02:56 AM
@ABA wrote:modifying the data retrieval method in the I-Cube-Lrwan example (rather than using I2C)
Not sure what you mean by that?
It's not an I2C sensor.
It uses a proprietary single wire interface - so you're going to have to write some software yourself whatever happens
2024-04-30 03:02 AM
I've already successfully implemented the sensor separately, without integrating it with the LoRa functionality. Now, I'm attempting to incorporate it into the LoRa project using the example code provided in the I-cube-lrwan project. However, since the sensor uses a different interface, I'm encountering challenges in adapting the code.
2024-04-30 03:22 AM
@ABA wrote:I'm encountering challenges in adapting the code.
What challenges, exactly?
2024-04-30 07:54 AM
I'm struggling to locate where GPIO settings are configured, as well as integrating sensor data acquisition code into the example project. I find it difficult to extract and implement example code provided by ST, especially since it's often merged with other functionalities. I'm used to CubeMX for configurations and I find it challenging to use just CubeIDE
2024-04-30 08:06 AM - edited 2024-04-30 08:13 AM
How about stepping through the code using the debugger - that'll show you where things happen ...
EDIT:
Also try browsing the project for references to HAL_GPIO_Init() ...
2024-04-30 08:27 AM - edited 2024-04-30 08:29 AM
Unfortunately in reality you often can't just expect code to be conjured out of thin air, you have to be able to code, and frankly walk other code to understand how it works and interacts. This doesn't have to go into the minutia, unless necessary, but you need to get an overview / lay-of-the-land, so you know where to look when that becomes necessary.
Cube hides stuff all over the place, the Semtech LoRa stuff less so, and in a less transparent way, you'll see it call specific tasks to do specific things. Look in the "HW" files, rather than "MSP" files.
Would suggest investing some time/money in Static Analysis tools so you can navigate code, and understand the inter-play. Within your chosen IDE, look at the Right-Click type context options to follow code, calls, definitions, etc, look at the Find-in-Files type searches, and perhaps in a File Manager so you can navigate code trees, and find things that way too.
2024-04-30 08:39 AM - edited 2024-07-03 08:25 AM
@Tesla DeLorean wrote:Within your chosen IDE, look at the Right-Click type context options to follow code, calls, definitions, etc,
+1
@ABA eg, in STM32CubeIDE there's the Call Hierarchy:
This gives you a "tree" view of where the selected function is called:
These buttons
Let you switch the view between callers and callees