Using VL53L4CD with other I2C devices in the same bus

[FFS]

Hello folks, I am trying to adapt my product to use the new VL53L4CD sensor, replacing another SPI distance sensor that is in use.

However, I only have one I2C bus available and it is already shared with other sensors and devices, such as a FRAM.

The problem arises when I modify my project in STMCubeMX, it removes the I2C HAL files, creating new instances that control the I2C peripheral. I am unsure how to address this issue, I have already implemented a good amount of code using the I2C HAL libraries and would like to maintain these implementations.

Any advice would be greatly appreciated.

[TDK]

> it removes the I2C HAL files

The library files? You shouldn't be modifying HAL library files. That's not a supported mode of operation.

If you place your code within USER CODE blocks, it will remain through code generation.

[SofLit]

Hello,

if "it removes the I2C HAL files" means that you added the HAL file manually, I recommend you to configure I2C from CubeMx. The HAL drivers will be added automatically to your project. 

Also you need to populate your .c/.h files with your own code between 

/* USER CODE BEGIN XXXX */ and /* USER CODE END XXXX */

[Tesla DeLorean]

Stop using CubeMX to generate code, and just write the code for the problem you have?

[FFS]

Hello TDK and SoftLit,

Thank you for your prompt response.

I want to address a possible misunderstanding regarding my mention of the I2C HAL libraries being removed. To provide a clearer picture, here are more details:

1- I assure you that I'm not breaching any restricted code sections.

2- Before adding the X-CUBE-TOF1 Middleware via CubeMX, the includes section in main.c was as follows:

/* Includes ------------------------------------------------------------------*/
#include "main.h"
#include "adc.h"
#include "crc.h"
#include "dma.h"
#include "i2c.h"
#include "spi.h"
#include "tim.h"
#include "usart.h"
#include "usb_device.h"
#include "gpio.h"

 3- After integrating X-CUBE-TOF1, the i2c.h include is missing, leading to build errors. Here's the revised includes section:

/* Includes ------------------------------------------------------------------*/
#include "main.h"
#include "adc.h"
#include "crc.h"
#include "dma.h"
#include "spi.h"
#include "tim.h"
#include "usart.h"
#include "usb_device.h"
#include "gpio.h"

4- You may check how I've included the Middleware in the images attached.

5- As expected, the application fails to build due to the following errors:

fatal error: i2c.h: No such file or directory my_main.c /FDLite_firmware/Core/Src line 18 C/C++ Problem
fatal error: platform.h: No such file or directory vl53l4cd.c /FDLite_firmware/Drivers/BSP/Components/vl53l4cd line 21 C/C++ Problem
fatal error: platform.h: No such file or directory vl53l4cd_api.h /FDLite_firmware/Drivers/BSP/Components/vl53l4cd/modules line 16 C/C++ Problem
fatal error: vl53l4cd_api.h: No such file or directory platform.c /FDLite_firmware/Drivers/BSP/Components/vl53l4cd/porting line 19 C/C++ Problem

6- A comparison using git reveals that the /Core/Src/i2c.c and .h files were deleted after adding the TOF Middleware.

Given that the TOF Middleware is pre-compiled, I'm uncertain how to proceed with accessing I2C.

I hope this clarifies my situation, and I look forward to any assistance you can provide.

Best regards,

[FFS]

The problem is that these new sensors don't have an open datasheet mapping registers nor library.

How do you recommend to proceed then? 

[John E KVAM · Accepted solution]

We do have a library. :) It's small and easily understood, and written in as straight-forward a manner as we could possibly make it. 

STSW-IMG026

Ultra lite driver (ULD) application programming interface (API) for the VL53L4CD Time-of-Flight high accuracy proximity sensor

It's only a couple of K and uses very little RAM. 

One note: That 'dev' in the function calls is not a Linux (or Unix) dev, but a simple integer - it's the sensor address. 

The driver is so simple, we didn't even want structures.

The only 'trick' is that if you are NOT using an STM32, you will need to write the functions that talk to your I2C.  Or get them from GitHub. But it's pretty easy.

[FFS]

Indeed John, I was able to port it and it was not very hard to do so for the STM32F4.

I am still facing some issues regarding the calibration, but I am in the way to solve them

[FFS]

By the way, this is the platform.c for the STM32F4 series, if anyone in need.