Touchscreen calibration

[yo5ptd]

Just activated touch on my ver 0.4 UI board, and it seems the reverse touchscreen function is not enough to make it function properly. It would be very easy for me to just write the necessary code by changing: Config menu - Reverse touchscreen - from yes/no into NO / X / Y / Both keeping the FLAGS1_REVERSE_TOUCHSCREEN eeprom setting for the X axis (former YES answers will translate correctly) and adding into mchf_board.h #define FLAGS1_REVERSE_TOUCHSCREEN_Y 0x8000 so it won't affect at all any other eeprom config setting. Of course the necessary translations and UI changes too that this would need to work.

My question is if such a feature would be needed? Is the solution something much simpler, like I'm holding the mcHF upside down :-) ?

[db4ple]

Hi, I think holding the mcHF upside down would add to the many ways to use it and would make you very unique. But joke aside, I think we should go with your proposal. But please wait before submitting the Pull-Request. We are planning to merge a rather big set of changes today, it will affect the touchscreen part (not much). But to be on the easy side for all of us, just base your pull request on the software AFTER we do the merge. One thing to note is the Y reversal may need a similar adjustment as the X reversal has. With you being the only one to have a fully reversed display it is on you to test this.

[db4ple]

Hi, the merge has happend, please rebase your development environment (see https://github.com/df8oe/mchf-github/blob/active-devel/CONTRIBUTING.md ). We are looking forward to your contribution.

[yo5ptd]

I'm coming with c# and arduino background, I'm new to ARM development. Unfortunately I can't get past the "Please select first the target STM32F10x device used in your application (in stm32f10x.h file)" error during the build, even if the preprocessor is set to STM32F407VG for all compilers. Uncommenting the #define line in stm32fxx.h doesn't help either, so it may take I while.

[db4ple]

Hi,

did you follow the instructions on:

https://github.com/df8oe/mchf-github/wiki/Setting-up-Firmware-Development-Software ?

Which combination do you want to use (Operating System/Distribution; Which IDE or make).

The easiest setup is make on Linux / Ubuntu or Debian The most powerful setup is Eclipse on Windows or Linux

In the middle is the new embitz IDE support, see https://github.com/df8oe/mchf-github/blob/active-devel/mchf-embitz/Readme.md but this is Windows only.

[yo5ptd]

Thanks for answering.

Yes, I've followed that guide, also trying to do updates where necessary on it. I'm on Ubuntu 17.04 with Eclipse Neon 4.6.3. GNU Arm Toolchain and Eclipse Plugin Installed (gcc-arm-none-eabi-6-2017-q1-update). I can create empty projects for STM32F4 in Eclipse.

[db4ple]

Ok, I assume you have the mchf-github repository clone on your local drive.

Now follow the (just updated instructions) https://github.com/df8oe/mchf-github/wiki/Setting-up-Firmware-Development-Software#eclipse

This should build you a nice mchf-eclipse.bin. You can flash this via USB drive, after rename of course (mchf.bin).

[yo5ptd]

Thanks! The updated guide helped, I think the missing step was building the DebugLib first (I'm not sure as I've redone all the dev environment setup steps this time on a Fedora Core).

I've added two more Config options, so now there is:

1. Touch Reverse X -on/off
2. Touch Reverse Y -on/off
3. Touch Flip - on/off (exchanges X with Y axis) These settings solve my problem. I'll have to work a bit on the adjustment table for case 2 and 3. I've found touchscreen issue mentioned on Raspberry PI forums, so at least I'm not alone...

[db4ple]

I would prefer to combine all three items (or at least 1+2) into a single menu item in order to limit the number of items the user has to consider when configuring the system. In most cases the default will be good enough, so more independent item make life more complicated for a "normal" user. The argument for more explicit items is the fact that the right setting maybe hidden if multiple choicese are combined into a set of selections (in our case the flip may not be obvious. However, I think, we a calibration we would be able to acquire all choices automatically if the user correctly touches what he/she thinks is left upper, right upper, ... corner of the touchscreen...

[df8oe]

I propose to use one menu entry "Touchscreen" using following settings: "not mirrored" x-reversed y-reversed flip x/y

Maybe later we must add more possibilities as x+y reversed and/or combinations with flip. I do not know if we ever do need that but it is only ONE menu entry. And yes: you must calculate a correction table for each mirror / flip...

[db4ple]

Single menu item: -> here we are on the same page, good. Correction tables: what I meant something slightly different: If we ask at first start up / configuration reset for touch the various corners, you will be able to deduce all 8 possible combinations of reverse x/y (4) and flip x/y (2) just by having the user press into four corners in the correct order. In fact 2 presses are sufficent to figure that all out. In addition these presses can serves as calibration for the positioning accuracy. But all of this comes later (although there is some calibration screen work already present in ui_driver but in a not ready state)

[yo5ptd]

I would agree with a single menu too (see my original post), however in my case I need the flip x/y AND the y-reversed but NOT the x-reversed, that's why I had to try with three separate menu options.

But indeed ans db4ple mentions, we should not reinvent the wheel. My touchscreen devices from 2003 had already the four corners/center calibration. Two corners + center may also work.

I can give it a try and implement this, so the touchscreen revert option(s) would become obsolete. What would be the best button combinations to start the touchscreen calibration? I'm thinking of a startup option like the new firmware load or the button test mode.

[db4ple]

Hi, plesase consider doing it in two steps:

• added configuration (using the flags as you proposed) and menu item(s) to change these
• "automatic" configuration based on calibration screen (see below). The first one solves your problem (and potentially others), the second improves and simplifies our live. Smaller steps are better I think. Anyway, as mentioned, there is already a starting point for calibration and even a sequence to activate:

See https://github.com/df8oe/mchf-github/wiki/Operating-Manual#key-press-map , last entry. It is F5 plus a press on the touchscreen itself during boot. This will bring up the calibration screen as implemented in ui_driver.c UiDriver_TouchscreenCalibration().

That can serve as a starting point for your work on step 2. Step 1 can be done quickly and gets you used to contributing something (useful) to the DF8OE firmware.

[df8oe]

I have had already started touchscreen calibration routine some months ago. It can be started with pressing button F5 and press any place on touchscreen during power on sequence (bootscreen). You can use that code. But I have had considered that unlinearities are quite "scattered" over the whole LCD so that I never used that. But it can be good enough for identifying what kind of mirror / flip you need.

[db4ple]

I think we should go fulll here and simply offer all 8 combinations, and thats it. Here my texts: No Y-Axis X-Axis X+Y-Axis No, Flip X/Y-Axis X-Axis, Flip X/Y Y-Axis, Flip X/Y X+Y-Axis, Flip X/Y Remember that the entry itself says "Reverse Touch" or something like this.

[yo5ptd]

Done. The menu text indeed needed to be shortened to "Reverse touch", but it's a single entry for all these options:

• No,
• Y Axis,
• X Axis,
• Both Axes,
• None but Flip,
• X Axis & Flip,
• Y Axis & Flip,
• Both and Flip.

Original EEPROM setting will map to the first menu option (Y Axis) so it's reverse compatible.

I haven't figured out if I have to remap the X axis after reverting it, I see some anomalies like jumping coordinates from 13 to 20, 28 to 33, 35 to 38 with no values between, I won't really have time to play with these. The source is in my forked branch, please feel free to use it.

[df8oe]

Thank you for your contribution. I am working on merging.

[df8oe]

I have tested - but it does not work. Touchscreen mirrored in y-axis (which is the only used mode until now) is unusable in your commit due to a wrong calibration table implementation. Please rework - I cannot merge it at this stage. You have removed complete correction routines

            if(x == 57 || (x < 7 && x > 1)) k=2;
            if(x == 56 || (x == 8 || x == 7))   k=3;
            if((x < 56 && x > 50) || (x < 16 && x > 8)) k=5;;
            if(x == 50 || (x == 17 || x == 16) || (x == 47 || x == 46)) k=6;
            if(x == 45) k=7;
            if((x == 49 || x == 48) || x == 44 || (x < 34 && x > 30) || (x < 21 && x > 17)) k=8;
            if((x < 44 && x > 33) || (x < 27 && x > 20))    k=9;
            if(x < 31 && x > 26)    k=10;
            x = x - k;

which are mandatory for y-mirrored mode... Instead of removing there must be different correction routines for x-mirrored mode, too...

[df8oe]

please correct or close this pull request.

[df8oe]

Implementation was faulty. I never have had seen any LCD that uses other touchscreen orientations as the two which are already implemented.

Please fix your PR and resend it otherwise nobody wil work on this. Please close this issue after reviewing.