ILI9341 & XPT2046 Touchscreen

[jgu1]

Hi Martin and Ben!

I have also just perform a test not working.

As far I understand.

In hardware. Mosi same connection as Touch Mosi display
Miso same connection as Touch Miso display
Clk same connection as Touch Clk display
CS different pin

In configuration also same pin only not CS.

Am I rigth
jorgen

[mnfisher]

Hi Jorgen - yes. I'm using jumpers from display MOSI - Touch MOSI etc..

Just testing again - and if I include the display component and don't initialise it - the code crashes. If I just include the touch component - it works. Something about sharing SPI between components isn't compiling correctly...

Martin

[mnfisher]

Accuracy issues..

Seem to have worked around this - I read that first read is sometimes 'noisy', so read Pressure twice (but just keep second value) - then read x and y twice and report touch if abs(x1 - x2) < 'factor' && abs(y1 - y2) < 'factor'. Currently using 30 as factor - but this is just a guess at a suitable value....

This seems to discriminate pretty well - and plotting a 'point' at each touch shows the scatter of points on touch....

Martin

[jgu1]

Hi Martin!

If I use same SPI, for the display and my touch, nothing work. Well ok if it´s not possbible, I can live with they ar seperated, but would be nice with 3 extra i/o

Br Jorgen

[BenR]

Just testing again - and if I include the display component and don't initialise it - the code crashes. If I just include the touch component - it works. Something about sharing SPI between components isn't compiling correctly...

Thanks for testing this Martin.

Any ideas where the problem is happening. i.e. where the crash is happening as this might help me in knowing where exactly to look.

[mnfisher]

Hi Ben,

Thanks - I'll try some more tests and see if I can get a handle on where the problem lurks...

Martin

[mnfisher]

A quick 'test' program that demonstrates the issue - much smaller / quicker to load and easier to check (maybe) This attempts to have two SPI devices attached to the same channel (as per including the two components) - just none of the extra 'baggage' - wiring is as before for ease (it's how my board is setup) - with output checked on oscilloscope.

Two SPI channels - both attached to channel 1 - writing to channel 1 is okay - the write to channel 2 gives a WDT reset. Removing (disabling) the second 'write' (Master_Byte) means it runs okay.

Attempting to 'init' CAL_SPI2 also results in a crash.

SPI Test.fcfx

(16.04 KiB) Downloaded 89 times

Martin

[mnfisher]

Ok - I think I've found the error - if not the fix....

As I understand it : If a second component attempts to use an 'already in use' SPI channel then calls to use the second SPI channel 'redirect' to the first... (in ESP_CAL_SPI.c)

For example

Code: Select all

	#define MX_SPI_RED1 CAL_APPEND(FC_CAL_SPI_Master_Init_, MX_SPI_CHANNEL_IN_USE)
	CALFUNCTION(MX_UINT8, FC_CAL_SPI_Master_Init_, (void))	{ return MX_SPI_RED1(); }

Should create a 'redirect' function for Init.

Something isn't quite right with this. I modified the Master_Byte redirect code slightly and this fixes the sample above:

Code: Select all

	//#define MX_SPI_RED3 CAL_APPEND(FC_CAL_SPI_Master_Byte_, MX_SPI_CHANNEL_IN_USE)
      #define MX_SPI_RED3 FC_CAL_SPI_Master_Byte_1 
	CALFUNCTION(MX_UINT8, FC_CAL_SPI_Master_Byte_, (MX_UINT8 DataOut))	{ return MX_SPI_RED3(DataOut); }

Note - I've simply hard-coded channel 2 to redirect to channel 1 (note the nomenclature is slightly confusing - so this is redirecting Cal_SPI2 to use channel 1 which is also in use by Cal_SPI1....

The sample code then works

However - there is more work to do (all the other functions - yes) - and to 'generalise' the code - MX_SPI_CHANNEL_IN_USE should equal 1 but doesn't for some reason... I'd guess it must equal 2 and this creates a recursive crash - otherwise some function not found errors would result?

Also - the esp32 doesn't like a channel being initialised multiple times - so if multiple components use the same channel then the 'initialisation' needs to be a bit smarter. (This issue can be sidestepped with the display and touch sensor - the user can omit the call to the Touch sensor initialisation - which only does CAL_SPI_Init - but again not a general fix)

Martin

[mnfisher]

A little more testing - and the value in MX_SPI_CHANNEL_IN_USE is indeed == 2

This should be 1 - and so a simplistic fix is to change the #define of this :

Code: Select all

	//Define hardware channel usage
	#if (MX_SPI_CHANNEL_X > 0)
		#if (MX_SPI_CHANNEL_X == 1)
			#define MX_SPI_CH1_IN_USE 1         //  Set to 1 !!!
                       // was set to MX_SPI_NUM
		#endif
		#if (MX_SPI_CHANNEL_X == 2)
			#define MX_SPI_CH2_IN_USE MX_SPI_NUM
		#endif
	#endif

I haven't tested with channel_x == 2 - but a similar alteration might be in order.

However - it looks like MX_SPI_NUM (which is used extensively) should be 1 when MX_SPI_CH1_IN_USE is #defined?

Martin

[BenR]

Thanks Martin,

I think this has given me some more to go on and possibly the problem could just be the initialise is being called twice, once by SPI ref 1 and again by SPI ref 2. I'll have a play with the hardware and see if I can get anywhere.

Hmm, I've had a good play and I'm not sure I can make it work now. It might have to be something we tackle in Flowcode rather then relying on preprocessor magic.