cancel
Showing results for 
Search instead for 
Did you mean: 

Using L476rg and sx1272MB2DAS

ABA
Associate II

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?

7 REPLIES 7
Andrew Neil
Evangelist III

@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

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.

 


@ABA wrote:

 I'm encountering challenges in adapting the code.


What challenges, exactly?

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

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() ...

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

@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:

AndrewNeil_0-1714491091295.png

 

This gives you a "tree" view of where the selected function is called:

AndrewNeil_1-1714491142261.png

 

These buttons 

AndrewNeil_3-1714491233404.png

Let you switch the view between callers and callees