ADS7843 board file for Arduino

[jtronix]

I successfully configured Arduino sketch to use GDISP module on ChipKit Max32 and TJCTM24028-SPI (ILI9341 & TS2046) hardware. I have attached a sketch folder in case somebody else finds this interesting. Use UECIDE to open it.

Now I need to get TS2046 touch panel working. The TS2046 readme.txt file says to use the ADS783 driver due to full compatibility with the XPT2046. Is there ADS7843 board sample configuration file available for Arduino platform?

gfx_test.sar

[Joel Bodenmann]

Hello @jtronix and welcome to the µGFX community!

Thank you for sharing your example sketch. Things like this are always very helpful for other people. Do you feel like the sketch is "good enough" to be added to the downloads section on this website as an example project?

Regarding the ADS7843: I don't know of any existing board file for that setup. There's a GDISP board file for Arduino in the /boards/base/ArduinoTinyScreen/ directory but I guess that won't help much as you already got everything working. At the end the stuff you have to do in the ADS7843 board file is exactly the same as for a GDISP board file: Implement the different functions to talk to the hardware (eg. SPI in this case) and that's it. You can find a template board file in the ADS7843 driver directory.
If you're having trouble understanding what each function should do we're happy to help where ever we can. If you're having troubles with the Arduino library I guess the folks over at those Arduino forums will be happy to help where ever they can as well  

[jtronix]

Hi Joel, thank you for your help. I would wait until touch panel is functional before using it as an example project.

There are two ADS7843 configurations which I can use as a starting point: FireBull-STM32F103-FB and HY-MiniSTM32V. Later I will probably need some help with function descriptions, but for now I'm ok. I will publish the results anyway.

[Joel Bodenmann]

Sounds great!

Looking forward seeing the final example project  

[jtronix]

Touch panel is finally working. Please feel free to add it to Arduino project examples. I had to edit src/gdriver/gdriver.h, otherwise it does not compile. Change line 90 from "typedef const struct GDriverVMT const   GDriverVMTList[1];" to "typedef const struct GDriverVMT GDriverVMTList[1];"

ugfx_demo_touch_raw_readings.sar

[inmarket]

That language construct is perfectly valid C but some compilers incorrectly generate warnings for it.  This is actually a compiler bug caused by a misinterpretation of the C standard by the compiler writer. The most commonly known compiler with this bug is GCC.

It looks like your compiler does one worse - it actually errors on it. Are you sure you just haven't set your compiler flags to error on all warnings?

If not please send us the details of what compiler you are using so that we can put a special #ifdef around the code to account for its brokenness. I think the gfxconf option is something like GFX_OS_COMPILER_SHOW but check the gfxconf.example.h

 

[jtronix]

The compiler I use is PIC32 version 1.43, its GCC based on XC32 version 1.43 from Microchip. I did not enable to any flags explicitly, it is actually set to suppress all warnings via UECIDE menu.

[inmarket]

Please turn on the define as above, do a rebuild all and then tell us what compiler uGFX thinks you are using.

[jtronix]

Compiler shows the following message:

 Error at line 956 in file gfx_compilers.h:
‣ Compiler: "GCC" [enabled by default]

Edited August 21, 2017 by jtronix

[inmarket]

Thank you. It looks like the GCC bug rears its head again. I will look to see if I can add something to turn off that error/warning on GCC.

[inmarket]

It also looks like your IDE is telling GCC to treat all warnings as errors.

[jtronix]

I'm not sure if UECIDE  treats warnings as errors, its configured as in the picture below:

UECIDE calls pic32-g++ compiler with the following parameters:

-mprocessor=32MX795F512L -Os -G1024 -g -fno-exceptions -ffunction-sections -fdata-sections -mno-smart-io -mdebugger -Wcast-align -fno-short-double -DF_CPU=80000000L -DARDUINO=157 -D_BOARD_MEGA_ -DMPIDEVER=10001932 -DMPIDE=157 -DOPT_BOARD_INTERNAL -DOPT_SYSTEM_INTERNAL -DIDE=UECIDE -D_USB

UECIDE  console shows the following uFGX messages on compilation, there are more warnings but they are not relevant to uGFX:

• Error at line 72 in file gmouse_lld_ADS7843.c:
‣ initialization from incompatible pointer type [enabled by default]

• Error at line 72 in file gmouse_lld_ADS7843.c:
‣ (near initialization for 'GMOUSEVMT_OnlyOne[0].init') [enabled by default]

• Error at line 90 in file gdriver.h:
‣ duplicate 'const'

Compiling Failed
 

 

[jtronix]

Editing only one line in gdriver.h is not a big problem, I can live with that.

But I found one more problem related to gcc duplicate const error. Customised keyboard layout requires GVSpecialKey declaration in the main sketch. After adding #include "src/gwin/gwin_keyboard_layout.h" to the sketch, UECIDE shows the following two errors:

• Error at line 53 in file gwin_keyboard_layout.h:
‣ duplicate 'const'

• Error at line 54 in file gwin_keyboard_layout.h:
‣ duplicate 'const'

Compiling Failed

Is there any way around this issue? Perhaps adding some gcc compilation flags? I would like to avoid modifying uGFX source if possible.

[inmarket]

GCC should output an error number for the duplicate const error it is outputting. If we know that number we can add a #pragma to turn it off. Unfortunately I don't have time to research it right now but I may be able to look on the weekend if you haven't found it by then.

[jtronix]

Thank you @inmarket. I can't see any error numbers in the compiler output. I have asked a similar question on UECIDE forum and currently awaiting for the response.

[jtronix]

UECIDE support says this kind of error can't be hidden. I can try migrating from ChipKit PIC32 to Teensy ARM hardware platform while keeping same software tools, but I'm afraid to face similar issues because Teensy ARM compiler that is bundled with UECIDE is gcc based too.

[inmarket]

Interesting when a compiler bug expressed as a warning in the original compiler becomes a fatal error (and still a bug) in a derivative compiler.

That section of code is being rewritten for other reasons in V3 so it will go away there. Unfortunately though not for the keyboard layout definitions. I will have to build a special exemption for gcc derivitives.

Note: with the standard arduino IDE this is not a problem last time I tried and it isn't a problem for most gcc derivative compilers because they only generate a warning. For whatever reason UECIDE have decided to convert this warning into an error therefore compounding the seriousness of the compiler bug.

[jtronix]

I solved this problem with the help from UECIDE forum by relocating C style declarations into a separate .c file. For detailed solution see the link I posted earlier. This means that uGfx library does not require modifications, except in gdriver.h! 

Edited August 24, 2017 by jtronix

[inmarket]

By way of explanation of the compiler bug and looking at the referenced link there are a lot of people defending the undefendable and repeating the mistake that gcc have made in interpreting the C standard. An explanation here will hopefully help future readers.

First let me make it clear - I am not talking about a C++ compiler. C++ is a different language with different rules. C is not equal to a limited version of C++. There are some language constructs and rules that are quite different and this is one such area. 

In C a "const char *x" means x is a readonly pointer to something (in this case a singular character). The something cannot be altered and the compiler will prevent you from altering that data via that x pointer. You could assign x to a char * pointer via a cast and the compiler should let you then try to edit the data via the now char * pointer.

A "const char y[]" however is different. This says that y is the address to an array of characters that is readonly. It is not the address that is readonly (persay) but the character data itself. Typically the compiler will put the character data into real readonly storage eg the instruction space or ROM of the cpu. As such assigning a const char * pointer to y is allowed. Assigning a char * pointer to x however should generate an error even via a typecast as the data should never be alterable. Obviously there are ways around it (typecasting to const char * and then casting again to a char *) however the principle applies - x is treated as real constant data not just as a pointer to data.

This semantic difference is important in a couple of situations - 1. On parallel processing where this distinction can affect parallelism, and 2. When decisions need to be made about where the data is stored (eg ROM or RAM). Situation 2 is particularly important when compiling for embedded platforms (and therefore for uGFX).

A "const char * const x []" therefore is a const array of const char * pointers. Not only is each stored pointer pointing to readonly data, the array of pointers itself should be readonly (and therefore probably stored in ROM by the compiler). Where gcc got it wrong is in not understanding the slight differences in semantics between the two consts. If you leave one of the consts out gcc (and most but not all compilers) will promote the const in both directions ie both the storage and the pointer will be treated as const. This promotion is strictly not correct semantically but it is not against the rules (it is not clearly defined) and it definitely usually reflects the intent of the programmer and therefore cuts down unnecessary warnings so I have no complaint about that. What annoys me however is when the compiler complains about the strictly correct syntax. Note in C++ that promotion is defined and therefore in C++ the double const is not valid.

Note this double const only makes sense on array definitions. It does not make sense on singular variables as a singular variable name cannot be used synonymously with a pointer. Only for arrays is the variable name actually the address of the data not the data itself.

 

[inmarket]

Congratulations on solving it. As you found out - avoiding C++ compilation was the solution.