De-initialise touchscreen STM32F7Disco on-the-fly

[randomrat]

Hi,

I would like to disable the FT5336 touchscreen programmatically and then re-enable it again at a later point in my code. 

The reason why i'd like to do this is because I am using the F7 Disco Serial Audio Interface which also uses I2C line. I find that once I have finished playing the audio file, my code hangs in the while loop of the stm32f7_i2c.c "i2cRead" function. Is this a bug or something?

	// Transmit the whole buffer
	for (i = 0; i < length; i++) {
		while (!(i2c->ISR & I2C_ISR_RXNE)); //<-- hangs here
		data[i] = i2c->RXDR;
	}

 

For now, as a temporary solution, I am happy to disable the touchscreen driver whilst the audio is playing and then re-enable it once the track has finished. 

 

Looking in "gmouse_lld_FT5336.c" I see the following:

const GMouseVMT const GMOUSE_DRIVER_VMT[1] = {{
	{
		GDRIVER_TYPE_TOUCH,
		GMOUSE_VFLG_TOUCH | GMOUSE_VFLG_ONLY_DOWN | GMOUSE_VFLG_POORUPDOWN,
		sizeof(GMouse) + GMOUSE_FT5336_BOARD_DATA_SIZE,
		_gmouseInitDriver,
		_gmousePostInitDriver,
		_gmouseDeInitDriver
	},
	1,				// z_max - (currently?) not supported
	0,				// z_min - (currently?) not supported
	1,				// z_touchon
	0,				// z_touchoff
	{				// pen_jitter
		GMOUSE_FT5336_PEN_CALIBRATE_ERROR,			// calibrate
		GMOUSE_FT5336_PEN_CLICK_ERROR,				// click
		GMOUSE_FT5336_PEN_MOVE_ERROR				// move
	},
	{				// finger_jitter
		GMOUSE_FT5336_FINGER_CALIBRATE_ERROR,		// calibrate
		GMOUSE_FT5336_FINGER_CLICK_ERROR,			// click
		GMOUSE_FT5336_FINGER_MOVE_ERROR				// move
	},
	ft5336Init, 	// init
	0,				// deinit //<--- Do I need to write/add an ft5336DeInit function and add it here.
	ft5336ReadXYZ,	// get
	0,				// calsave
	0				// calload
}};

 

I'm not sure really sure how to go about de-initialising the driver. should I be adding a deinit function and calling it from my code? I feel as though this is supposed to be something very trivial but I am struggling a bit. 

Thank you for your time.

Edited February 3, 2017 by randomrat

[inmarket]

Deinitialisation is not well supported in ugfx because typically in an embedded environment you never do deinit and the deinit code takes up precious rom space.

Yes it should be possible to put a deinit routine there and then get the driver to deinit using the gdriver destroy api call. Afterwards though it may be very difficult to reinitialise it properly.

A much better solution is to properly implement the bus arbitration calls in your board files for the touch driver and the audio driver. That is what they are designed for, for when two peripherals share a common bus.

[randomrat]

Thank you for your advice.

I think I found something that has been causing my problems.

In the "stm32746g_discovery_audio.c" file, the BSP_AUDIO_OUT_Stop function sends commands to the WM8994 codec to shutdown. If I don't call this function, it solves the hang 9/10 times and I can still play a new track as and when I need to. Touchscreen still operates.

uint8_t BSP_AUDIO_OUT_Stop(uint32_t Option)
{
  /* Call the Media layer stop function */
  HAL_SAI_DMAStop(&haudio_out_sai);
  
  /* Call Audio Codec Stop function */
  if(audio_drv->Stop(AUDIO_I2C_ADDRESS, Option) != 0)
  {
    return AUDIO_ERROR;
  }
  else
  {
    if(Option == CODEC_PDWN_HW)
    { 
      /* Wait at least 100us */
      HAL_Delay(1);
    }
    /* Return AUDIO_OK when all operations are correctly done */
    return AUDIO_OK;
  }
}

Anyway, it looks like need to do some reading on bus arbitration and how to use the calls. 

[inmarket]

Using the CubeHAL audio driver is totally unsupported in a uGFX environment. It may work but also may not work (particularly when there are hardware contention issues).

What we would really like is for you to create a uGFX driver for that codec chip, handling the contention appropriately. We can then add that as a configuration we will support.

Whilst we can help with uGFX related issues and provide pointers on where to look for related issues (like the above problem), we are not able to support or debug outside uGFX code.