cancel
Showing results for 
Search instead for 
Did you mean: 

VL53L5CX API Size "vl53l5cx_buffers.h" seems to be too large for the MCU to handle. Is splitting the buffers ( "VL53L5CX_FIRMWARE[]" )into smaller 'chunks' to send to the SPAD a reasonable solution?

DAzu.1
Associate II

I am trying to use the VL53L5CX with an AVR128DB48. 

The .h file "vl53l5cx_buffers.h" seems to be too large for the MCU to handle. 

I think, as it stands, it breaks the 32727 byte limit that AVR is capable of. 

Is splitting "VL53L5CX_FIRMWARE[]" into smaller 'chunks' to send to the SPAD a reasonable solution? 

Has anyone else encountered this problem?  

Is there an alternative that I have missed that is more compatible with an AVR MCU?

Is there any reason that this will not work with the VL53L5CX? 

4 REPLIES 4
John E KVAM
ST Employee

Absolutely acceptable. Lots of MCUs need to do this with various max lengths.

You need to modify it in the platform.c file.

So just go ahead and break up the transfer into whatever size you need.

It will work fine.

  • john

Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'
DAzu.1
Associate II

Great, thank you.

Do you mean vl53l5cx_api.c?

I can't see anything in platform.c that relates directly to writing the firmware, apart from the I2C read/write functions.

In vl53l5cx_api.c the firmware is written using the following:

/* Download FW into VL53L5 */
	status |= WrByte(&(p_dev->platform), 0x7fff, 0x09);
	status |= WrMulti(&(p_dev->platform),0,
		(uint8_t*)&VL53L5CX_FIRMWARE[0],0x8000);
	status |= WrByte(&(p_dev->platform), 0x7fff, 0x0a);
	status |= WrMulti(&(p_dev->platform),0,
		(uint8_t*)&VL53L5CX_FIRMWARE[0x8000],0x8000);
	status |= WrByte(&(p_dev->platform), 0x7fff, 0x0b);
	status |= WrMulti(&(p_dev->platform),0,
		(uint8_t*)&VL53L5CX_FIRMWARE[0x10000],0x5000);
	status |= WrByte(&(p_dev->platform), 0x7fff, 0x01);

I have modified this to to account for the limited array size in my MCU. Splitting 'VL53L5CX_FIRMWARE[]' into 5 sections. VL53L5CX_FIRMWARE[]1 ...VL53L5CX_FIRMWARE[]4.

status |= WrByte(&(p_dev->platform), 0x7fff, 0x09);
    
	status |= WrMulti(&(p_dev->platform),0,
		(uint8_t*)&VL53L5CX_FIRMWARE[0],0x4000);
    
    status |= WrMulti(&(p_dev->platform),0x4000,
		(uint8_t*)&VL53L5CX_FIRMWARE1[0],0x4000);
    
	status |= WrByte(&(p_dev->platform), 0x7fff, 0x0a);
    
	status |= WrMulti(&(p_dev->platform),0,
		(uint8_t*)&VL53L5CX_FIRMWARE2[0],0x4000);
    
    status |= WrMulti(&(p_dev->platform),0x4000,
		(uint8_t*)&VL53L5CX_FIRMWARE3[0],0x4000);
    
	status |= WrByte(&(p_dev->platform), 0x7fff, 0x0b);
    
	status |= WrMulti(&(p_dev->platform),0,
		(uint8_t*)&VL53L5CX_FIRMWARE4[0],0x5000);
    
	status |= WrByte(&(p_dev->platform), 0x7fff, 0x01);

I have already bricked one module testing my code. Because there is no documentation on the register structure in the SPAD, I would like to double check with you that this would work.

Is this correct?

Kind regards

@John E KVAM​ 

John E KVAM
ST Employee

I think that approach is going to get in into trouble. A much more general approach would be to put the change in the platform.c file.

The WrMulti() and RdMulti() functions were intended to be implemented in the platform.c file which we conveniently left empty for this purpose.

Rather than change a lot of places, just make these functions more useful.

if the size is greater than MAXSIZE,

While sent_size >0 {Send MAXSIZE bytes; sent_size -=MAXSIZE}

And don't forget to do the same thing for the RdMulti.

I don't understand how you could 'brick' the sensor by issuing poorly constructed I2C commands. I mess them up all the time and have never ruined a chip that way.

(Although I must admit to ruining a lot of sensors in other creative ways.)

  • john


Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'