Showing results for 
Search instead for 
Did you mean: 

How to reduce vl53l5cx_init() timing footprint?

Associate II
uint8_t vl53l5cx_init(
		VL53L5CX_Configuration		*p_dev)
	uint8_t tmp, status = VL53L5CX_STATUS_OK;
	uint8_t pipe_ctrl[] = {VL53L5CX_NB_TARGET_PER_ZONE, 0x00, 0x01, 0x00};
	uint32_t single_range = 0x01;
	status |= WrByte(&(p_dev->platform), 0x000F, 0x40);
	status |= WrByte(&(p_dev->platform), 0x000A, 0x01);
	status |= WaitMs(&(p_dev->platform), 100);
	/* Wait for sensor booted (several ms required to get sensor ready ) */
	status |= WrByte(&(p_dev->platform), 0x7fff, 0x00);
	status |= _vl53l5cx_poll_for_answer(p_dev, 1, 0, 0x06, 0xff, 1);
	status |= WrByte(&(p_dev->platform), 0x000E, 0x01);
	status |= WrByte(&(p_dev->platform), 0x7fff, 0x02);

There is a 100ms fixed delay in the vl53l5cx_init() function.

I am supposing that this delay could be reduced to the strinctly minimum required for SW reboot.

It could be replaced with a polling function like _vl53l5cx_poll_for_mcu_boot or _vl53l5cx_poll_for_answer or a custom one?

Thank you

ST Employee

The function _vl53l5cx_poll_for_answer() does a poll as you suggest. But the 100ms is there to allow the tiny processor in the sensor to get booted up.

You might experiment with lowering the 100ms to some other number.

We tend to be pretty conservative with stuff like that.

But don't get too close to the edge, you'll find different sensors are very slightly slower or faster than the few units you have.

  • john

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question. It helps the next guy.
Associate II

It would be feasible to replace the fixed delay of 100ms with a _vl53l5cx_poll_for_answer() to a known register of the tiny processor? If so, which register/value could be used to test if processor is already booted up?

Thank you