Due GUI (Graphical user interface) - [now community project]

Hardware Arduino Due
101

Hi,

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.

Thanks,
ediaz

102

All,

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?

[BUG]

In drawSingleKey, popup_ys should actually be GUI_ysize:
case 40: drawActualKey(5+(i30),GUI_ysize+(k30),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:
GUI_ysize=getDisplayYSize()-popup_ys;

Thanks,
ediaz

103

@ghlawrence2000

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.

Thanks,
ediaz

DUEGUI.h (16.5 KB)

DUEGUI.cpp (100 KB)

104

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.

G

105

ediaz,

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.

106

Hi Darren,

Well thankyou for all your efforts with this project that gave us the start point.....

It would be nice to see your face around here again at some time in the future should you be able to find the time.... :smiley:

Regards,

Graham

107

I'm still about just not as often as I would like at the moment. I have several hobbies on the go at the same time with one of them being rebuilding my land rover which is nearly there now. Once that is up and running I have lots of ideas for things in my electronics workshop which I've spent quite a bit to build up but not had much chance to use yet PCB plant (MEGAUK kit D - http://www.megauk.com/pcb_kits.php), colour digital storage scope, SMD rework station & preheater, nice bench PSU etc etc not to mention a vast array of parts. I've had some great ideas for gadgets and gizmos for the landrover but they will have to wait till it is actually water proof :smiley:

Anyway I will be hovering about and I have a good few ideas for future objects such as rev counter type dials, gauges and other car related stuff.

108

I've just changed the thread title too......

Let me know if it needs changing again to reflect versioning etc.

109

cowasaki:
I've just changed the thread title too......

Let me know if it needs changing again to reflect versioning etc.

Its nice to see you are still around, and if you feel inclined to stay involved that would be good! :smiley:

mmmm rover of any description land or otherwise, they never were great in the wet!! XD

G

110

Thanks Darren and Graham,

"..I got was a cryptic response from someone rather than a useful explanation of how to call one library from another!"

This one had me for a while. It wasn't until how I saw how UButtons was implemented by Hennings, that I figured it out. I have been on the fence about how a GUI with limited memory should be implemented. It would be nice to be able to have a true OO implementation. I am not a static member expert, but I believe a static method cant access member variables, which is what we would really need, so that all the object methods would reside in flash, and just the variables(which are currently in an array form) would reside in SRAM. I think the best implementation given the Arduino constraints would be to leave it in an indexed array methodology as it currently is.

Btw, I noticed that in last post I failed to mention how to instantiate the DUEGUI object, for others to see:

#include <UTFT.h>
#include <UTouch.h>
#include <DUEGUI.h>     

UTFT myutft(HX8352A,22,23,31,33);                   
UTouch touch(25,26,27,29,30);
DUEGUI DueGUI(&myutft, &touch);

Thank you Darren for your support. Time is a precious thing, and I can relate to having to many projects and to little time. :slight_smile:

Thanks,
Edward

111

ediaz:
Btw, I noticed that in last post I failed to mention how to instantiate the DUEGUI object, for others to see:

#include <UTFT.h>

#include <UTouch.h>
#include <DUEGUI.h>

UTFT myutft(HX8352A,22,23,31,33);                  
UTouch touch(25,26,27,29,30);
DUEGUI DueGUI(&myutft, &touch);




Thank you Darren for your support. Time is a precious thing, and I can relate to having to many projects and to little time. :)

Thanks,
Edward

Hmm, what shield are you using with your display? That is not a combination of pins I have seen before....

My tuppence for what it is worth, I think the coldtears DUE shield was probably the first to come out, and naturally mates well with the CTE displays so far favoured by this project until now. As such I think it is worth mentioning the initialisation code for that situation.

UTFT       myGLCD(ITDB32S,25,26,27,28); 
UTouch  myTouch(6,5,32,3,2);
DUEGUI  DueGUI( &myGLCD , &myTouch);

@Edward
,

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.

Is this also the case with the genuine Henning library examples? Also what about the calibration routine? I was just thinking if possible it would be better to cure the cause, not the symptom. Since the underlying aim is now to produce a hardware independent DUEGUI, I just wonder if this fix could potentially cause problems as yet unknown on different hardware?

Was just wondering where the error may have cropped up.

I am still tinkering and going through the changes you have made, I also have yet to finish my test sketch which will essentially just be a modified version of Darren's original demo.

HOWEVER...............This is where I got distracted and went off at a tangent...... I don't like the single 16x16 font option, I was thinking it would be nice to assimilate a variety of fonts which would be a close approximation to the CTE Font ic fonts. The first problem with that idea is 34 point is not divisible by 8... similarly, neither is 28 which are the two principle font sizes in DUEGUI so far that I have encountered.

I was also thinking this is specifically to you Edward, is there anything in particular you want me to try/test/do for you, as I suspect I am likely to go off on several tangents with this thing..... :roll_eyes:

Regards,

Graham

112

Hi,

I use the elechouse 3.2" display that rotates the display so that you can still get to the other headers. I think most displays have the 0-3900 a2d read back range. Its in the conversion to XY that it need to be fudged based on display size and rotation of the touch film and how it was placed.

Thanks,
Edward

113

Hi All,

I am still tinkering with the text/font side of things, while doing so I came across this slight gremlin if anybody else is still playing with this?.....:roll_eyes: :stuck_out_tongue:

Just a small bug in date format, 2 digit did not work correctly, here's the fix:

void DUEGUI::setObjectDate(int objectNumber,int yyyy, int month, int day, bool dateNorm, bool dateFour){
  if (dateNorm){
    GUIobject_top[objectNumber]=displayNumFormat(day,2)+"/"+displayNumFormat(month,2);
  } else {
    GUIobject_top[objectNumber]=displayNumFormat(month,2)+"/"+displayNumFormat(day,2);
  }
  if (dateFour){
    GUIobject_top[objectNumber]=GUIobject_top[objectNumber]+"/"+String(yyyy,10)+" ";
  } else {
    GUIobject_top[objectNumber]=GUIobject_top[objectNumber]+"/"+String(yyyy,10).substring(2)+" ";
  }
}

Regards,

Graham

114

Edward/Ediaz,

Are you still following this thread?

Now I have a preliminary tentative working sketch, I have a few points, one of which I think we perhaps need to collaborate on, the others I only mention that I have discovered, not that I have tried to diagnose or resolve yet.

1st) Touch is flipped on the X axis, but as you will be aware the

DueGUI.setReverseX(1);

command no longer works as you stripped out the gubbins relating to it.

2nd) Unhide does not appear to work, as yet i have not persued why.

3rd) Text input formatting errors, such as ##, Cap and Space are all stacked and overlapping, again not persued yet, maybe this will resolve itself once I have done more with available font sizes.

My feeling is that we need to resolve the touch side of things more universally than at present, but I did not start to do anything about that yet, if you are still interested in trying to make this a universal project it has to be the way to go.

It would have been nice if there was more interest in this project, besides you, myself and of course Darren!! =(

Regards,

Graham

115

Hi,

Yes I agree. There needs to be a universal calibration method. The best way would be for a first time run to calibrate and self-flash the value on a known address. Maybe at the top of the flash space. On subsequent power-on events, if the values exists in flash memory, no calibration would be required(touch four corners).

(It looks like we can use the EEPROM area for what we want) http://www.arduino.cc/en/Reference/EEPROM
To store the results of the initial calibration test.

I have been busy with holidays, family, and I sneek some Arduino time in when possible. Also trying to teach myself clojure.

Thanks,
Ed Diaz

116

demos in original post do not compile... ide 1.5.5 due

117

Hello,
I can not insert images with DueGUI.addImage function. Only pictures of example DueGUI_demo_02 work.
Here is my code:

#define URNTB1 1
#define URNTB2 2
#define URNRemove 3
#define URNAdd 4
#define URNRefresh 5
#define URNFanScreen 6
#define URNInputScreen 7
#define URNClockScreen 8
#define URNCalibrate 9
#define URNProgressbar 10
#define URNProgressbar2 11
#define URNghostbutton 12
#define URNimagebutton1 13
#define URNimagebutton2 14
#define URNstringcycle 15
#define URNimageLogo 16

DueGUI.InitGUI(6,5,32,3,2,52,2,51);
DueGUI.addImage(320,120,287,true,URNimageLogo);
DueGUI.drawImage(URNimageLogo);
delay(4000);
// Display "main_menu" screen
DueGUI_createScreen(main_menu);

When I use it in another program the CTE_LCD.Load_image function (320,120,287), it works

Can someone tell me how to insert pictures (I may be wrong in transferring the images from the SD card to the EEPROM, or am I wrong location)?

Thank you and happy christmas

118

Hi
I am trying to see if this library is still being developed?

Ediaz, I believe your approach to decouple the library from UTFT is on the right track as UTFT is
being updated and we'd need to keep it up to date easily.

Can you shine some light on the status of the library now? it would be great if we can get it
hosted on SVN and start some documentation, perhaps I can pinch in as well along side
other motivated developers. I just can't reach anyone about this library.

Thanks

119

Hi everybody

I follow this thread from the start. I never interfere because my knowledge in C is limited (about 20%) but I involved many times in HMIs as my job is full time Industrial automation (commercial PLC and custom made).
@cowasaki did a grate start and really inspired me until the final grate idea @ediaz had to separate DUEGUI from UTFT libraries (like UTFT_Buttons.h works).

So far I was unable to run ANYTHING using DUEGUI. I have version Arduino IDE 1.5.5, I did all modifications @ediaz recommended but when I compile "DueGUI_demo_02 work" I have errors...

"DueGUI_demo_02.ino: In function 'void setup()':
DueGUI_demo_02:382: error: conversion from 'int' to 'String' is ambiguous
C:\Program Files\Arduino\hardware\arduino\sam\cores\arduino/WString.h:61: note: candidates are: String::String(const __FlashStringHelper*)
C:\Program Files\Arduino\hardware\arduino\sam\cores\arduino/WString.h:59: note: String::String(const char*)
"
Anyway maybe it is nothing but I do not want to look around and lost. I am willing to help @ediaz in any way I can (with my experience in commercial and custom made HMI programs) . @cowasaki as far as I remember is still with us but doing some work on his car.

So please where is the final code so far? can it run in 1.5.5? I want to help in any way
I know is Christmas but this project is joy or not?
Happy new year to everybody
Vasilis
Greece

120

vorrias:
"DueGUI_demo_02.ino: In function 'void setup()':
DueGUI_demo_02:382: error: conversion from 'int' to 'String' is ambiguous
C:\Program Files\Arduino\hardware\arduino\sam\cores\arduino/WString.h:61: note: candidates are: String::String(const __FlashStringHelper*)
C:\Program Files\Arduino\hardware\arduino\sam\cores\arduino/WString.h:59: note: String::String(const char*)
"

So please where is the final code so far? can it run in 1.5.5? I want to help in any way
I know is Christmas but this project is joy or not?
Happy new year to everybody
Vasilis
Greece

Vasilis, Hi :slight_smile:

Yes more people joining in with this would be good, I must admit I have had a few weeks of other stuff to do, but the immediate 'cure' for that particular error is

//  (c) 2013 Darren Hill (Cowasaki)
//
#define VERSION "0.13"  <--------------------  NOTE quotes!
//
//  This program is not as yet complete.  There are a number of missing features and features not fully implemented.

I cannot as yet comment on suitability of IDE 1.5.5 as I am still on the previous release.
While I was busy creating the zip and making sure it worked, I got 1.5.5. and can confirm that it works fine :D. FWIW, this is the current library, complete with working example for a SSD1289 based 320*240 display and CTE shield.

There is much more to be done with this as only the main screen is correctly formatted as yet, there are problems with invisibility which is as far as I got, since my touch screen is also not working correctly, and I got bogged down with a few other things too, but HOPEFULLY, this should give something at least visible and working on screen.

@marbeuhan08, I have not got as far as trying to play with image buttons yet, maybe ediaz could comment further, as far as I am aware he was looking into image storage in flash, but my own thoughts are SD (since I already modified UTFT_tinyFAT to retrieve images using sdfatlib)...... More input/discussion is needed on several aspects of this project, but sadly to date, all modifications from cowasaki's original library are entirely the work of ediaz, I can not take any credit for the work done so far.

@fadik, ediaz is currently the leading light on this project, although I am dabbling in a few areas myself at the moment, it would be great to have more eyes on this project, github is another possibility for collaboration, I don't know if Ed has any thoughts?

@ed the only differences between (ediaz) and (ghl-tweaked) versions, is that I added back in all the spaces you removed so I could do line by line side by side comparison to original cowasaki version, and also slight change to 'posCentre' parameter, and also 2digit date format.

The included archive as it stands, and the ghl_DueGUI_CTEshield_320x240_SSD1289 example is formatted nicely. The ediaz version of the library will rapidly show the differences :wink:

HAPPY NEW YEAR everyone !!! :smiley:

Regards,

Graham

DUEGUI.zip (86.1 KB)