Go Down

Topic: Due GUI (Graphical user interface) - [now community project] (Read 109624 times) previous topic - next topic


I gave up on this DueGUI since it seems to be "stuck" on an older
version of the IDE, and only work on the 5" display.

So, I modified the UTFT, UTFT_CTE, and UTouch libraries to
support the CTE32HR, CTE35, CTE40, CTE50, and CTE70,
as used with the CTE display shield for Due.

I then made a version of the CTE Demo and a version of the
K-Demo and Paint that would work on all 5 displays, with only
one line of code change in my script, the choosing of the display.
All for the Landscape orientation of the display.

Then, I added touch-buttons, including text and integer labels,
checkboxes, radio buttons, and and progress bars, all in an h-file
on a tab in my script.


Could someone point me in the right direction to where I might get hold of the CTE modified libraries?

I concur with ediaz that it would be better if DUEGUI inherited from Henning's original libraries as they seem to work flawlessly across all hardware permutations, but for curiosity I would also like to see 'WHAT' modifications CTE made to the original libraries, hopefully to gain a little more insight to which would be the best solution to get DUEGUI functioning on displays other than the 5".

I have had minor success getting 'something' to appear on screen using DUEGUI as is, but the result is far from successful with a complete absence of any text, and the touch calibration is wildly adrift for my 3.2" display.

I appreciate the efforts cowasaki has made to this project, and I guess to an extent we all make sketches that work on our own hardware setup, but it seems a crying shame to have strayed so far away from solid reliable UTFT and UTouch. I would be willing to collaborate with my small to medium abilities to try to restore DUEGUI to sit on top of Henning's original libraries if anyone else would be willing / interested to persue this?

It would be good if the creator of this project would chime in but regardless, I can see the potential, I would personally be able to use it, but it needs more work to work on a broader range of hardware and I am not ashamed to admit that I dont think my abilities are up to the task by myself.  =(


UTFT_SdRaw now included in library manager!! ;) High speed image drawing from SD card to UTFT displays for Mega & DUE.
UTFT_GHL - a VASTLY upgraded version of UTFT_CTE. Coming soon to a TFT near you! 8) Shipping April 1 2016!


mmm so I figured out why I have no text....... DUEGUI ASSUMES cold tears display AND font ic...... Not very useful for users like myself that don't have one of those....

So why not go the 'whole hog' and disable non CTE-displays?

So many contradictions in this project.....

I would like to see full compatibility with all functions able to work on all sizes of display with or without CTE font ic, who's with me?

I reiterate, this could be an awesome project with huge benefits to anyone with any tft/shield if done properly..... We are so far away from 'done properly' at this point.....  :(


UTFT_SdRaw now included in library manager!! ;) High speed image drawing from SD card to UTFT displays for Mega & DUE.
UTFT_GHL - a VASTLY upgraded version of UTFT_CTE. Coming soon to a TFT near you! 8) Shipping April 1 2016!


I went to modify the post...and deleted it by mistake.  stupid user trick (we used to call it the ID 10T error).  Oh well...

Instead of retypeing the whole thing... I just went over to Hennings site... made a donation.. and told him thanks for his work on the UTFT stuff.

Quiero una vida simple en Mexico...nada mas.


Nov 04, 2013, 07:43 pm Last Edit: Nov 04, 2013, 07:59 pm by ediaz Reason: 1
When comparing the two configurations DUEGUI and UTFT, i noticed with an oscope, that the RS, WR, RD lines are not toggling. The DB lines are toggling.

I have a simple example that takes the touch input and draws to the screen. When I touch the screen I can see that data transfer to the smart display occur(except for RS,WR,RD). I am in the process is taking the UTFT init sequence  and copying it into the DUEGUI. Hopefully, I can find the point of interest. Hopefully, I can figure it out.


Here is my example. I now have the UTFT init sequence in the DUEGUI constructor  and InitLCD. Still not seeing the RD,WR lines toggle.

Code: [Select]

/** colors */
#define BLACK   0x0000
#define BLUE    0x001F
#define RED     0xF800
#define GREEN   0x07E0
#define CYAN    0x07FF
#define MAGENTA 0xF81F
#define YELLOW  0xFFE0
#define WHITE   0xFFFF

#include <ads7843.h>

//#include <UTFT.h>                                  //OPTION 1
//UTFT myGLCD(HX8352A,22,23,31,33);                  //OPTION 1

#include <DUEGUI.h>                                  //OPTION 2
DUEGUI myGLCD(HX8352A,22,23,31,33);                  //OPTION 2

/** elechouse TFT shield pin map */
#define DCLK     25
#define CS       26
#define DIN      27
#define DOUT     29
#define IRQ      30

/** global variable */
ADS7843 touch(CS, DCLK, DIN, DOUT, IRQ);

// Declare which fonts we will be using
extern uint8_t SmallFont[];

Point p;
uint16_t color[]={

void setup(void)
 /** ADS7843 initial */
 myGLCD.setColor (255, 255, 0);
 //myGLCD.setColor(0, 0, 255);

void loop(void)
 uint8_t flag;
 int lx, ly;
 /** get random number */  
 int pacy=random(0, 7);  

 p=touch.getpos(&flag) ;
 // myGLCD.setColor (random(255), random(255), random(255));
   ly=(p.x- 0)/15.8;       // 240
   lx=(3800-p.y )/9.5;     // 400
   /** get next position */
   p=touch.getpos(&flag) ;


Nov 04, 2013, 08:54 pm Last Edit: Nov 05, 2013, 05:10 pm by ediaz Reason: 1
Problem:  3.2 inch display doesnt work with DUEGUI.

Success!! I got it to work.

The problem looks like the cbi sbi implementations.

Please note that this is after transplanting the UTFT init sequence into DUEGUI.

I backed up to the original DUEGUI init sequence and modify the cbi/sbi implementation, with no success. More investigation is required on this point.

So, if you want to repeat what I did. You need to copy the UTFT constructor into the DUEGUI constructor, also copy over the InitLCD method, and update the defines in HW_SAM_defines.h (as attached below.). There is a bug with pulse_low that doesn't actually pulse.

If your interested I can zip what I have done, and email it.

Now its time to play with DUEGUI, hopefully I have no other issues.


Code: [Select]
// *** Hardwarespecific defines ***

#define cbi(reg, bitmask) *reg &= ~bitmask
#define sbi(reg, bitmask) *reg |= bitmask

#define pulse_high(reg, bitmask) sbi(reg, bitmask); cbi(reg, bitmask);

#define pulse_low(reg, bitmask) cbi(reg, bitmask); sbi(reg, bitmask);
//#define pulse_low(reg, bitmask) sbi(reg, bitmask); sbi(reg, bitmask);
// looks like an actual bug

#define pulse_WR() REG_PIOD_CODR=0x2; REG_PIOD_SODR=0x2;

#define cbi_RS() cbi(P_RS, B_RS);
#define sbi_RS() sbi(P_RS, B_RS);
//#define cbi_RS() REG_PIOD_CODR=0x1;
//#define sbi_RS() REG_PIOD_SODR=0x1;

#define cbi_CS() cbi(P_CS, B_CS);
#define sbi_CS() sbi(P_CS, B_CS);
//#define cbi_CS() REG_PIOD_CODR=0x4;
//#define sbi_CS() REG_PIOD_SODR=0x4;

#define cbi_RST() cbi(P_RST, B_RST);
#define sbi_RST() sbi(P_RST, B_RST);
//#define cbi_RST() REG_PIOD_CODR=0x8;
//#define sbi_RST() REG_PIOD_SODR=0x8;

#define pgm_read_word(data) *data
#define pgm_read_byte(data) *data

#define cport(port, data) port &= data
#define sport(port, data) port |= data

#define swap(type, i, j) {type t = i; i = j; j = t;}

#define fontbyte(x) cfont.font[x]  

#define regtype volatile uint32_t
#define regsize uint32_t
#define bitmapdatatype unsigned short*



I am interested in doing exactly what was suggested. It looks like DUEGUI would need multiple inheritance for touch and display. It also looks like the keyboard would need to be re-sized for the screen size.

I was thinking that given such a small screen the keyboard input should be its own screen with one line on top for entry. I need to get this working anyways, or build my own, so I think I will try to implement a display agnostic version of DUEGUI.

I was hoping that there was an agnostic working solution already existing. It would be nice to have a c# or java-like display interface with a layout manager.

I don't know if there are any other victims that would like to participate.



Nov 10, 2013, 03:30 am Last Edit: Nov 10, 2013, 03:48 am by ediaz Reason: 1

So far so good. I have decoupled DUEGUI from all low level functions.  I opted to have the DUEGUI constructor to be instantiated with two passed objects, a display and touch. All is working so far. I am in the process of getting fonts to work, and then I will tackle the keyboard. Once I make more progress and some clean up, I will look at making a GITHUB home for it.

My goal is to make DUEGUI independent of size, and functional via other display and touch objects. Currently UTFT is a standard that I can rely on, however it looks like there is no standard interface for the touch object. Looks like I will need to create a standard touch interface for DUEGUI, so that with some simple teaks that touch object can be implemented, with a specific vendor touch hardware.

It also looks like the button response currently works through a timer interupt check.I would like to create an interface that is an ActionListener, hopefully a simple layout manager also.




Sorry, computer failure stopped play, back online today.

Give me a day or 2 to catch up on your messages and progress, and I will be able to get a bit more involved I hope.


UTFT_SdRaw now included in library manager!! ;) High speed image drawing from SD card to UTFT displays for Mega & DUE.
UTFT_GHL - a VASTLY upgraded version of UTFT_CTE. Coming soon to a TFT near you! 8) Shipping April 1 2016!



Did you have any thoughts on extracting CTE from non-CTE text drawing routines?

I am thinking least possible modification to Henning's genuine working functional libraries..... Best way to implement this?

I suspect we need to attack the text print routines with an external variable of some description??

Better still, buy a CTE display and f**k it...  :P But that defeats the object of implementing DUEGUI on ANY display....  :smiley-roll-blue:

Out of curiosity............ what displays have you got? Personally I only have an Sd1289 3.2"..... Struggling to acquire a 5" CTE at the moment, furthermore, I REALLY like the look of the NEW 5" CTE with some new-fangled frame buffer memory, that Henning does not currently appear to support :(

Choices......choices..... ?

Where to go from here?

Anybody else got any ideas?


UTFT_SdRaw now included in library manager!! ;) High speed image drawing from SD card to UTFT displays for Mega & DUE.
UTFT_GHL - a VASTLY upgraded version of UTFT_CTE. Coming soon to a TFT near you! 8) Shipping April 1 2016!


Nov 15, 2013, 06:16 am Last Edit: Nov 16, 2013, 05:33 am by ediaz Reason: 1

I have extracted all CTE routines from my versions. I have fonts, keyboard, touch, display all working. I just need to finish up the Load image implementation. The CTE image routines depended on all the images residing on the display memory itself. I am going to opt to using images stored in the internal Arduino flash. However, with the fonts I am now limited with the UTFT granularity.

I noticed the UTFT_buttons on Hennings site, which is all I really need. I feel like just tossing the DUEGUI implementation, since its array based and not really a true OO implementation, probably to minimize SRAM footprint. However, I wonder if a true OO implementation could be done efficiently.

I think I will clean it up and finish it. Currently, its like the UTFT_buttons methodology. You create two objects a UTFT and a UTouch and then you call the DUEGUI constructor with them.

I eliminated all of the OFFSET version of all functions. There was this concept of offseting the image for a pop keyboard, so that the actual field could be used for text visulization. I would rather have a popup keyboard have its on text line and upon completion of input, the data is transferred to the field. I still have a lot of work to do, and I am not two happy about the direction.

BTW, I have a HX8352A, 3.2" 240x400 LCD.



Nov 16, 2013, 06:34 am Last Edit: Nov 16, 2013, 09:24 pm by ediaz Reason: 1

Just wanted to note a bug that I found in DUEGUI, I fixed it in my (nonCTE)  version. When I am done I will upload it to GITHUB. Since its more abstracted now, maybe we should call it ARDUINOGUI or UTFTGUI?


In drawSingleKey, popup_ys  should actually be GUI_ysize:
   case 40: drawActualKey(5+(i*30),GUI_ysize+(k*30),25,20,"CAP",capcolour,textcolour); break;

and in checkAllButtons, popup_ys should actually be GUI_ysize:
  byte k=(ypos-GUI_ysize)/30;

Please note that when the popup is active GUI_ysize gets redefined:



Nov 18, 2013, 08:38 pm Last Edit: Nov 19, 2013, 05:16 am by ediaz Reason: 1

So far. I have a DUEGUI object that takes a UTFT and UTouch object. The DUEGUI UTouch->getX and getY have to be fudged. I noticed that on my display UTouch doesnt work quite right. So the getX and getY functions take the absolute values and corrects for X and Y.

Replace your DUEGUI.cpp and DUEGUI.h, with the two versions attached, and let me know if it works.

Please note that lots of work is still needed. I don't have the image functionality working yet. They keyboard now is a function of the display size, and should re-size correctly. The keyboard no longer offsets the screen, instead it will create a text line above the keyboard, where you can update your changes. When you hit enter, the field gets updated. For small screens the offset function just seemed cumbersome.

Please note that I also decreased the max number of array elements from 100 to 20. You may need to bump that up again.



Hi ediaz,

I have not fell off the edge of the earth, I am playing, evaluating, and generally messing about with your good work, will get back to you when I have something worthwhile to report.

I think congrats are in order though, well done.

UTFT_SdRaw now included in library manager!! ;) High speed image drawing from SD card to UTFT displays for Mega & DUE.
UTFT_GHL - a VASTLY upgraded version of UTFT_CTE. Coming soon to a TFT near you! 8) Shipping April 1 2016!



Great to see other people running with my DUEGUI library as I really don't have the time to put into it at the moment.  I merged everything into one for two reasons (1) simplicity and (2) because despite spending a week trying then asking on here all I got was a cryptic response from someone rather than a useful explanation of how to call one library from another!  I would have liked to have had the DUEGUI as a separate library calling whatever version of Henning's library was current.  It would also have been good to be able to use fonts with any screen size.  The only screens I have are a 5" and a couple of 7" ones.  It would also have been nice to have kept compatibility with the 1280/2560 arduinos but I lost that early on.

Anyway, you have my full support in taking it forward and hopefully you will have time to implement the things I didn't have time for.  The touch calibration, I am told, has been sorted by someone else on another thread I started but I couldn't find it when I just looked but I am sure it will turn up.

Go Up