Touch Screen Connection Help SSD1963 MAX11802

[solijoli]

Hi all,

I'm new to ARM controllers and touch screens but I'm trying to learn. I wanted to implement the DSO project of naftilos76 to have a better understanding for the future. Like him, I am using the STM32F407 discovery board but I'm using the touch screen INT070ATFT which is 7 inch and has SSD1963 and MAX11802. In the project file which I downloaded from,

http://naftilos76.net/dl/tutorial.pdf

I've editted the gdisp_lld_panel.h file so that it is compatible with a 7 inch screen but I couldn't know what to change on the ginput_lld_mouse_board.h and ginput_lld_mouse_config.h files because the codes are written for ADS7843 on an Olimex STM32E407 which was available at the drivers section of the ugfx. What do I need to do for it to work on my screen? Also I didn't touched the main.c code, will that change as well? As I said, I'm currently learning and was hoping to make this project work and build on it, so I appreciate any help. Thanks a lot.

[steved]

Wait until the morning - I've got that display (and touch screen) working, but the driver hasn't made it into the repository yet.

I'll upload it once I'm at work.

[Joel Bodenmann]

Hello solijoli and welcome to the community!

First of all, please note that the tutorial that you are refering to uses a rather old version of uGFX. Many things changed (to the better) by now. We are close to release the new drivers interface that makes it A LOT easier to write new drivers. Therefore, I'd recommend you to check out the newmouse branch of the uGFX repository in order to implement a driver that will be compatible with all the new upcoming uGFX versions.

But sadly we don't have any available documentation to that yet. However, the already ported drivers should be more than enough to see how you have to implement a driver. And if you ever hit any problem, the forum is always there for you!

A general advice: When starting to implement uGFX into your project, it is strongly recommended to start off just with the GDISP module enabled. Using this minimal configuration it is a lot easier getting your project set up and compiling. You should even start by taking the empty board template for your GDISP driver (in your case it is /drivers/gdisp/SSD1963/board_SSD1963_template.h) and try to compile with that one first.

Edit: As I just see, steved seems to help you out with this one As far as I know he already uses the new driver structure as well!

Let us know when you have any questions.

~ Tectu

[Joel Bodenmann]

Wait until the morning - I've got that display (and touch screen) working, but the driver hasn't made it into the repository yet.

Oh... I remember that there was something... Did you port the driver to the new driver structure from the newmouse branch? We'd be more than happy to add your driver to the repository ASAP then

Otherwise I'll port it myself if you (re)provide us with your driver that works with the current master branch. However, I'll need you to test and probably debug it.

~ Tectu

[steved]

Here's the driver interface I'm using with the INT070ATFT.

I've basically done a diff between my working copy of ugfx and the latest trunk repository, so there may be a few irrelevant files there.

Note that I've modified the standard mouse driver to give the option of storing calibration data in a central repository (rather than being a bit application specific); the additional files for that are posted in the development section of this forum.

Tectu - still using the 'old' mouse interface, so if you get the chance to modify what I've done I'm happy to test.

UGFx_my_mods_161014.zip

[Joel Bodenmann]

still using the 'old' mouse interface, so if you get the chance to modify what I've done I'm happy to test.

This means that solijoli should use the master branch in that case.

@steved: I will let you know once I ported the driver. But days are currently very busy. Don't expect anything within the next 8 days please.

~ Tectu

[solijoli]

Hi guys,

Thanks so much for helping. I've used the files that steved posted but there has been some problems as you can see in the picture where the "ginput_lld_mouse_board.h" file is the file in boards\addons\ginput\touch\MAX11802 from steved's post. Also it says too few arguments to function 'read value'. So the problems seen are mostly based on that file. What can be done to solve this problem? Also if you think that there is something else I can send you my ChibiOS/uGFX file and the project itself. Thanks!!

[steved]

Looks as if I never updated the ginput_lld_mouse_board_st_stm32f4_discovery.h file with the final code; I think it should be the same as the board-specific ginput_lld_mouse_board.h in the DDS1414 board directory.

Incidentally, I'm using ChibiOS 3, but doesn't look as if that's a problem.

Edit: Think the file for the Discovery used a different SPI port; have done an update as attached (but not tested it)

ginput_lld_mouse_board_st_stm32f4_discovery.zip

[solijoli]

Hello again,

I couldn't managed to build the DSO project so I wanted to go back to basics. I downloaded the Chibios 2.6.6 and added the Tectu's ugfx folder inside ext folder. Then on Chibios, I copied the demo for STM32F4 Discovery to a new folder, updated the Makefile and was able to build it, so I don't think there is a problem with Chibios. Then, I wanted to add Ugfx to my project so i went to "ugfx\demos\modules\gdisp\basics" folder and copied those files into my existing project, replacing the "main.c" files. I also adjusted the makefile according to, http://ugfx.org/get-ugfx/11-documentati ... fx-chibios, I've added "ugfx/boards/base/DDS1414/board.mk" which steved sent previously. I also put all the files that steved had sent to my ugfx folder and just editted the "ugfx\drivers\gdisp\SSD1963" folder so that it is compatible with my board, so I didn't need to add anything else to my project folder. Also I've added a "gdisp_lld_panel.h" which I got the structure from, viewtopic.php?f=22&t=5, to my "ugfx\drivers\gdisp\SSD1963" folder and included it in the "ssd1963.h". Now whenever I try to build i get this error. Where was I supposed to define the device on Chibios? I'm pretty sure there is going to be other problems if this problem is fixed and I'm frustrated for being unable to building a demo project. Can someone tell me what I'm doing wrong? I'm sharing my chibios+project folders. I really appreciate help, thanks!

https://drive.google.com/file/d/0B30BBd ... sp=sharing

[steved]

Two things.

Firstly, I'm using Chibios 3.x (which is, strictly speaking, still in development, although very stable). There have been some changes in configuration files and core functions which may well not be accounted for in my board files, although uGfx has the necessary conditional compilation in its core routines.

Secondly, the 'DDS1414' board directory is based on the Olimex STM32-E407. It includes the Chibios board definitions, assuming they are selected in your make file. There are some differences between this board and the Discovery; certainly some of the clock configuration values.

I did actually start by using a Discovery, and I think the attached file contains the code I used. If nothing else, it should highlight some of the differences to you.

Whichever configuration you use, you may need to adjust it to select the correct SPI port and/or a few of the FSMC signals (e.g. command/data select)

DD_Special.zip

[Joel Bodenmann]

@solijoli: I have no idea where you got that link from. That article is probably a hundred years old and I didn't even know that it exists. All the official documentation can be found here ---> http://wiki.ugfx.org

In general, you should never trust links in a public forum that are older than half a year.

Everything else is pretty well covered by steveds post. If you have a project that compiles with ChibiOS/RT and uGFX, I strongly recommend you to disable everything but the GDISP module in the configuration file and just compile with the blank (empty) board file template that you can find in the drivers directory (in your case /drivers/gdisp/SSD1963/board_SSD1963_template.h). This way you can be absolutely be sure that no project specific issues keep you from getting a successful compile.

~ Tectu

[inmarket]

The compile errors you are seeing are due to using chibios V2 board files in a chibios V3 compile or visa versa. Either revert to using the chibios version which match your chibios board files, mcuconf.h etc or update those files to be compatible with the latest chibios.

Chibios V3 has a number of demo files to get you started although personally I would revert to chibios V2 because the V3 api is still in flux and changes in incompatible ways from time to time.

Also, if you can't solve it that way you should discuss this on the chibios forum as this is definitely a chibios problem.

I recently updated the ugfx support for Chibios V3 because of its changing api. Unfortunately that means we are then incompatible with older snapshots of V3.

[steved]

The compile errors you are seeing are due to using chibios V2 board files in a chibios V3 compile or visa versa. Either revert to using the chibios version which match your chibios board files, mcuconf.h etc or update those files to be compatible with the latest chibios.

At least some of the compile errors were due to use of files intended for the Olimex E407 in a Discovery environment - notable the clock-related ones.

[solijoli]

Hello,

I managed to build the demo project on eclipse, thanks so much for the help! But now that I uploaded the code on the touch screen, I only see a white screen now like in the picture (before it was worse where there were much noise all over the screen). I've used the DD_Special board the steved had sent but changed

      GDISP_SCREEN_WIDTH, GDISP_SCREEN_HEIGHT,	// Panel width and height
		2, 2, 41,									// Horizontal Timings (back porch, front porch, pulse)
		CALC_PERIOD(800,2,2,41),					// Total Horizontal Period (calculated from above line)
		2, 2, 10,									// Vertical Timings (back porch, front porch, pulse)
		CALC_PERIOD(480,2,2,10),					// Total Vertical Period (calculated from above line)
		CALC_FPR(800,480,2,2,41,2,2,10,60ULL),		// FPR - the 60ULL is the frames per second. Note the ULL!
		0											// Flags

to

      GDISP_SCREEN_WIDTH, GDISP_SCREEN_HEIGHT,	// Panel width and height
		46, 210, 41,									// Horizontal Timings (back porch, front porch, pulse)
		CALC_PERIOD(800,46,210,41),					// Total Horizontal Period (calculated from above line)
		23, 22, 10,									// Vertical Timings (back porch, front porch, pulse)
		CALC_PERIOD(480,23,22,10),					// Total Vertical Period (calculated from above line)
		CALC_FPR(800,480,46,210,41,23,22,10,60ULL),		// FPR - the 60ULL is the frames per second. Note the ULL!
		0											// Flags

and didn't changed the gdisp_lld_SSD1963.c file (Was I supposed to?) In the readme file it said "SD1963 driver modified to handle Displaytech INTXXX displays"

I've connected the pins of stm32f4 and the board according to:

https://www.google.com/search?q=stm32f4 ... B948%3B521

which is also the same with naftilos76' project and the datasheet, where I have connected all CS, RS, all the grounds except the fields about touch. I have also built a circuit that takes 5 V and creates 3.3 and 1.2 V for the requirements of VDDIO, VDDD, VDDLCD.

http://www.mouser.com/ds/2/116/int070at ... 221474.pdf

@steved in the board_SSD1963.h file in DD_Special, you use

      IOBus busD = {GPIOD, (1 << 0) | (1 << 1) | (1 << 4) | (1 << 5) | (1 << 7) | (1 << 8) | (1 << 9) | (1 << 10) | (1 << 14) | (1 << 15), 0};

		IOBus busE = {GPIOE, (1 << 3) | (1 << 7) | (1 << 8) | (1 << 9) | (1 << 10) | (1 << 11) | (1 << 12) | (1 << 13) | (1 << 14) | (1 << 15), 0};

Where did PE3 need to connect? In the board.h file it is stated in GPIOE setup section; PE3 - FSMC_DC. I didn't understand what to do with that but I think the problem is probably about the touch screen connections? What can be done about this? Thank you!

[steved]

PE3 (which is FSMC_A19) is what I have connected to the 'Command/Data' line of the display. That's a bit important! (It is possible to use other lines, but then you have to modify the driver a little).

The Displaytech units don't actually need you to set up the SSD1963 registers - you make sure you don't enable any of the signals to the display for about a second after power up or reset, and the display initialises itself.

If you set GFX_NO_DISPLAY_INIT to TRUE (which it was in the original board_SSD1963.h) it disables the relevant bits of initialisation. The driver should then also handle the reset line correctly (although possibly that bit's not tested).

Older versions of the displays had a hardware fault which meant it was best not to drive reset at all - to implement this, set GFX_NO_RESET_DRIVE to TRUE in board_SSD1963.h

[solijoli]

But when you use PE3 to Command/Data, in my case RS, where do you connect PD11 with? Other than that are the connections same with you? I'am using the codes you sent. There is GFX_NO_DISPLAY_INIT TRUE in the board_SSD1963.h file. I just changed the timings so they should be good for 7 inches. Thanks.

[steved]

But when you use PE3 to Command/Data, in my case RS, where do you connect PD11 with?

If you use PE3 (as is the case in my example), you don't use PD11 for the display - you can use it for something else.

There is GFX_NO_DISPLAY_INIT TRUE in the board_SSD1963.h file. I just changed the timings so they should be good for 7 inches. Thanks.

There should be GFX_NO_DISPLAY_INIT TRUE in the board_SSD1963.h file - its needed with the Displaytech. I suggest you read its data sheet carefully - it automatically initialises itself with the correct parameters if you give it enough time after power up or reset.

(My understanding is that timings can vary significantly even with different displays of the same size).

Bear in mind that the files I have posted are ones I am actually using!

[Joel Bodenmann]

The MAX11802 touchscreen driver by steved has been added to the repository.

~ Tectu