Show Posts
Pages: 1 [2] 3 4 ... 7
16  Using Arduino / Displays / Re: [SOLVED] CTE TFT with font ic, what size are the fonts please? on: February 27, 2014, 02:17:23 pm
Hi Gary,

Thanks for that extra snippet of information! Very interesting and I will definitely look into it.

Regards,

Graham
17  Products / Arduino Due / Re: SdFat for Due posted on: February 27, 2014, 08:46:33 am
I have SD.h for now, and I'm not sure how I can get SDfat library.

Please let me know if you have any more suggestions. Thanks again.


-Simon

Hi Simon,

You can look here for sdfatlib https://code.google.com/p/sdfatlib/.

The only other comments I have is that there is always the possibility the SD card you are using is a bit naff? I had a cheap ebay job that would not work with SD.h but did work with sdfatlib at slow speed.

Finally, did you try the 'CardInfo' example? This should tell you at least that the card is detected and wiring is correct, it will also initialize with SPI_HALF_SPEED by defualt, which will go some way towards proving if the SD card is not so good.

Quote
Initializing SD card...Wiring is correct and a card is present.

Card type: SDHC

Volume type is FAT32

Volume size (bytes): 3518857216
Volume size (Kbytes): 3436384
Volume size (Mbytes): 3355

Files found on the card (name, date and size in bytes):

You do NOT need to bother 'trying' 4,10,52 as your SS pin...............on the coldtears shield it IS 53 !! PERIOD.

If this still does not help you, beg/steal/borrow a different SD card, preferably SanDisk, Transcend, Kingston ..... even only 1GB or 2GB at least until you are confident of your hardware and software arrangement.

Regards,

Graham
18  Products / Arduino Due / Re: SdFat for Due posted on: February 25, 2014, 12:44:05 am
Hi Simon,

Quote
However I get an "initialization failed" error message from the code, which means that the DUE failed to write to the SD card.  After reading several documentations, I suspect that pin 4 and 10 are indeed the right ports to read/write, but I could be wrong...

There "initialization failed" error message does NOT mean the DUE failed to write to the SD card, it did not even get past initialization.......

"I suspect that pin 4 and 10 are indeed the right ports to read/write", clearly you have misunderstood how SPI access to the SD card works, MISO/MOSI are the data in/out ports and are NOT pins 4 or 10. You should read up some more about SPI http://arduino.cc/en/Reference/SPI but in a nutshell, the gist of it is this, you have a clock, data in and data out which go to ALL SPI devices, the only pin that changes and thus allows you to access a specific device is the CS(SS) pin

There are a couple of things you need to check.    

Taken from "DUE_Shield_readme.txt"
Quote
Shipping default jumper configuration:

The TFT/SD Shield for arduino DUE is shipped with the following jumper config, if you use TFT modules in our store, you do not need to reconfig the jumpers.

LCD Vcc - 3.3V (JP2 shorted)
LCD backlight (LEDA+) - 3.3V (JP4 shorted)
arduino Pin32 to TP_DIN (JP10 opened)
On board SD - disabled (JP8 opened)

NOTE JP8 opened/on board SD - disabled. !!!!!   Did you put a solder blob on JP8?

Assuming you did, the next thing to check is that you changed both entries relating to CS(SS) in your SD code :-

Code:
 Serial.print("Initializing SD card...");
  // On the Ethernet Shield, CS is pin 4. It's set as an output by default.
  // Note that even if it's not used as the CS pin, the hardware SS pin
  // (10 on most Arduino boards, 53 on the Mega) must be left as an output
  // or the SD library functions will not work.
   pinMode(10, OUTPUT);
  
  if (!SD.begin(4)) {
    Serial.println("initialization failed!");
    return;
  }
  Serial.println("initialization done.");

As a self-confessed newbie, did you pick up on the misleading error in the example??

pinMode(10, OUTPUT); & if(SD.begin(4)) {  ??

The 10, and 4 relate to the same pin and therefor SHOULD at least be the same, in your case 53!

The coldtears shield is exactly what I have if you read the very post before yours, and it works fine with both SD and SDFATLIB once you bridge JP8, and use pin 53 as SS.

Best wishes,

Graham
19  Products / Arduino Due / Re: SdFat for Due posted on: February 24, 2014, 02:52:53 pm
Is there a reason, why I can`t run on FULL_SPEED?
Or has anybody a tip how to get a better performance?

Hi Rob,

There is a possibility that your SD shield uses resistor level shifters, this appears to be the biggest stumbling block preventing successful use of SPI_FULL_SPEED, however, there is also the possibility that the SD card you are using might not be up to it?

I have a Fujifilm Class 4 SDHC 8GB card, and also a SanDisk Class 4 Micro SDHC 4GB card, both of which work successfully with the ColdTears(CTE) TFT/SD/TOUCH Shield.

For your own reference using your figures, 50MB file, 32768 buffer size, I get the following speeds :-

Fuji 8GB
Write  3100KB - 3320KB  Read 3887KB - 3905KB
SanDisk 4GB
Write  3452KB - 3628KB  Read 4320KB - 4338KB

I have a further point I would like to mention which although is not directly related to the sdfat library, I did notice the differences when running the sdfatlib benchmarks.

When compiled on IDE 1.5.4 the bytes written to flash was 22340  with #include <SPI.h>  22456
When compiled on IDE 1.5.5 the bytes written to flash was 22492  with #include <SPI.h>  22616
Furthermore, without the SPI library, free RAM is 62751 for V1.5.4        and    62751   for V1.5.5      
however,                with the SPI library, free RAM is 62703 for V1.5.4 but only 62699 for V1.5.5

The use of #include <SPI.h> in the above tests, did not demonstrate any noticeable differences in performance.

Conclusion :- V1.5.4 produces a smaller flash image and uses less RAM in certain cases, I no longer have older IDE's to continue this testing, has anyone else noticed any similar differences?

Regards,

Graham
20  Using Arduino / Displays / Re: CTE TFT with font ic, what size are the fonts please? on: February 24, 2014, 01:52:48 pm
Hi Graham,

The last W would not be vertically aligned.
I have attached to photographs for you.
Of course, you can use fonts drawn by the Arduino, but there may a speed penalty by not using the on-board font IC.

I use TFT displays, Only one of my displays has a font IC on it.  It is quicker to write text using the font IC.
It would depend on your requirement.

See attached pics.



Hi Gary,

Thanks very much for your help that answers my question.

My original motive behind asking, was that I wondered if it would be possible to emulate the font ic in software, but I see that is not possible since the UTFT soft fonts are fixed space.

Regards,

Graham
21  Using Arduino / Displays / Re: CTE TFT with font ic, what size are the fonts please? on: February 04, 2014, 08:25:35 pm
Hi Gary,

Many thanks for your response, as you see I have been waiting quite a while....

Ok I take your point about proportional font, and of course I understand that 'W' will be wider than 'T', however...

Could you possibly try this for me? If you make a few rows of a few characters, does the horizontal allignment actually vary?  eg

WWWWW
IIIIW
TTTTW
AAAAW

That represents 4 characters and W, what I am asking is the last W horizontally aligned or does is alter as shown here?

Thankyou and regards,

Graham
22  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: January 06, 2014, 02:59:37 pm
@Vasilis, WOW!! I read quite a bit of your Raspberry PI PLC thread, very well done!  smiley I have not got a Raspberry Pi although I am aware of what they are of course...... I often wondered why I would want one when my computer does everything better/faster than the computer aspect of the PI, and my Arduino DUE does everything better/faster than the microcontroller aspect of the raspberry pi? Feel free to enlighten me if you wish  smiley-wink  I appreciate you are busy as you have previously said, but I wonder if sometime when you can spare a little time if you could possibly help me out with this http://forum.arduino.cc/index.php?topic=208814 please, as nobody else has yet. I don't presently own a CTE display, but I wanted to see what I could do to assimilate assorted UTFT fonts as approximations of CTE fonts? The idea being to give us a hardware independent DUEGUI library that is not reliant on the font ic but can use it if available.

@all, Ok, so back on topic, I have been playing with the optInvisible side of things, and I cannot find any rational explanation why it behaves as it does, it may be a cop-out, but I am not going to try to figure it out any further as I am quite enthusiastic to crack on with the touch calibration screen!

@ediaz Happy new year! You are quiet  smiley

Graham
23  Using Arduino / Displays / [SOLVED] CTE TFT with font ic, what size are the fonts please? on: January 05, 2014, 08:36:47 pm
Hi all,

I wonder if anyone with a CTE 5" or 7" would mind or could possibly give me the dimensions(pixels) of these fonts please?
If I had one of these, I would not need to ask, in the meantime, someone surely could help me out please?

BVS_13
BVS_15
BVS_19
BVS_22
BVS_28
BVS_34
BVS_43
BVS_52
BVS_74
BVS_112

Thanks and regards,

Graham
24  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: January 01, 2014, 04:40:15 pm
Hi Gary

Ok I agree in what you say.
I am not using anything what you did so far. When I have time I will try to understand your concept in DUE GUI but my time is limited in that moment and I want to increase my knowledge in C.  I have the intention If I understand what you are doing to help in any way I can and contribute.
But my mind is still troubling with a high level HMI .

I am 60 years old I am not learning as fast as before and despite the fact that I am in the computer business since 1979 I "learn" C just one year ago and not exercising frequently

Finally I will try to help and stay with all you.
So happy New Year again
Vasili


Vasilis


Hi Vasili,

That is great!!  smiley-grin You have a huge amount of knowledge no doubt, and that is valuable in its own right. Let me give you a snapshot of who I am...... I was 13 back in 1981 when I was introduced to a computer for the first time, it was an Acorn BBC Micro Model 'B', I taught myself BBC Basic, and 6502 Assembly language. I studied electrical and electronic engineering after school, and became an electronics service engineer for the English N.H.S. for around 17 years. My hobby and passion was always electronics, but a close 2nd was computers, and more recently Arduino, I tinkered and played with C back at college, but that was early 1990's, and now I am playing with C++ for fun with the Arduino! I do take your point about not learning at the same pace as when you were younger!!!  smiley-roll-blue smiley-eek-blue smiley-lol

I for one will never criticise you for what you don't know, but I hope you would be prepared to fault find, test, or simply take part in any way you feel able to do so? I have commented previously it is a little disappointing there are not more people showing an interest in this project, because I feel once it is working as Darren originally intended on any hardware UTFT supports, that it will have great potential in various applications??

Regards,

(I am not wishing anyone Happy New Year again, I did plenty of that earlier!! BAH HUMBUG LOL)

Graham
25  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: December 31, 2013, 09:37:19 pm
So unless some with good  knoledge of C. C++ lead this project it will end up with everybody with cut and past makes his version only for himself.

No! That is absolutely not what I envisage, whoever or wherever this library is hosted is not important, who wishes to be lead contributor, and or lead coordinator is not important,  'Kernighan Ritchie' levels of understanding of C, kind of seems to imply less knowledgeable mortals have nothing to offer, which I absolutely disagree with, and finally the whole point of a community project is that ALL suggestions from ANY angle are to be accepted, appreciated, discussed and dealt with appropriately, with the result being uploaded to git? Is that not what an ideal community collaboration is all about?

@cowasaki has already handed over the reigns due to limited time, Henning I think you will find has enough on his plate with his existing projects and maintenance of his various libraries and resources. Git gives us the ability to fork, branch, and monitor any/all changes/variations/additions/deletions and produce useful documentation collaboratively! The repository is public as such is available as a 'free for all' with no control from me, I just hosted it because nobody else had......... I don't see that this has empowered me or nominated me in any way? You may have noticed that  @ediaz and myself have been in dialogue a little while now, and I think it would be more appropriate to have a staging area / brain storming arena away from this forum where trivialities and any/all comments can be made without swamping the forum with tooing and froing of questions/suggestions/test reports etc?

One of the most urgently required imminent updates to this needs to be the dynamic calibration screen, while I accept maybe I am no K&R prodige, I do consider it to be within the realms of my abilities to do this, the major limitation I have, is that I only have 1 display. I am hoping and will need, other people with different flavours of shield and or display to verify the modifications when I have made them, which actually brings this full circle, @ediaz gave me his code to test on my display. He and I already agree something needs to be done about this, and here we are, this is the point you have joined in. Come the time I have dealt with the invisible object problem, and the touch calibration screen, I will be looking for as many as possible different people to test this, not only myself and @ediaz, thus ensuring the ultimate flexibility of the DUEGUI library.

What individuals then chose to do with that library of course will very much be on a 'each to themselves' arrangement. My demo was made by me, for me, on my own display, as a start point to then get down to doing some remedial work on the library itself. The sketch I gave was a work in progress, and in hindsight, maybe I should not have given it you if you are not intending to bring anything back?  smiley-mad smiley-sad

Regards and a VERY Happy New Year everyone!!  smiley-grin

Graham
26  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: December 31, 2013, 11:01:45 am
Hi Vasilis,

You are welcome and I am pleased I could help on this occasion! smiley-grin As you say, only the first screen works, I am aware of that and I only got that far before I realised there were problems with 'invisibility'. The Screen you see at startup looks like this (or it should do) :-



Ok, so the problem I am having is this, at startup you should see the screen shown above, touch the 'R' button, this is re-draw all objects, and you will see the whole screen visibly shimmer as it redraws....... do this several times until you know what I am talking about.........   then touch the -1&2 button, which will make the '1' , '2' and '-1&2' buttons disappear...........  now touch the 'R' button........ several times..............  the 'R' button turns red to indicate it realises it is active............... but the corresponding redraw does not happen..............  And actually this is also the case if the screen is originally drawn with any invisible objects present...... I have not managed to track down why yet, and that is the main reason I have not continued to format the fan, clock and cal screens yet, ediaz has already done significant work on the input screen, and I understand it fits a 400*240 screen correctly, but as you will be aware not quite perfect on 320*240. My priority is/has been to try to resolve this invisible problem, and so far I have drawn a blank and become a little de-motivated to be honest, but I will keep chipping away at it, unless someone figures it out before I do.

The next idea I think would be good, would be to take advantage and use CTE fonts if they are available, or normal UTFT fonts if not. The current ediaz version is now only UTFT fonts. My problem with this idea is that as yet I don't have a CTE TFT with fonts and although I am planning to get the 5" 800*480 with fonts, it is not going to be for another month or 2, which kind of restricts my abilities to experiment in that area...  smiley-cry

I very much like your idea of the PYTHON display design project and drop into DUEGUI to compile, that does sound great, and I must admit, while you might not believe it, it did actually take me quite a long time to produce that first screen with nice formatting and layout, which you may or may not be aware, does not contain everything of the original DEMO_02.

I had intended to carry on and redesign the remaining screens all to nicely fit 320*240, but I then decided was perhaps more important to try to resolve identified problems as/when they are discovered, I fixed the 2 digit date problem along the way but that was easy.... Since others are now showing interest and asking about the current state of this project, I figured the more the merrier and released what I have so far, Ed, I hope you don't mind as I do appreciate you did the bulk of the work and I don't wish to tread on your toes!!

This invisibility problem has taken a huge amount of my time already, as while I was playing/designing that first screen I had almost completed it when I decided to introduce invisible buttons, and then touch stopped working, but I didn't connect no touch with invisible objects immediately, so actually that first screen is the stage I was at basically early November!!  smiley-cry smiley-mad

Lastly, but perhaps most importantly? Would be to deal with the touch calibration screen, dynamically adjusted to cope with ANY display size at the library level, currently ediaz has it hardwired for 400*240, I modified that and hardwired it for 320*240, but this is not an ideal long term solution for what hopefully is going to be a universal library.

Regarding your weak C abilities, don't worry about it, Google knows everything!!  smiley-mr-green smiley-lol experimenting and playing is a good way to learn, start with DUEGUI its already broke, you can only make it better!!

To those of you requesting SVN, git etc, until somebody else wants to take control and move it somewhere else, this is my first stab at a repo..... Do what you like with it....

https://github.com/ghlawrence2000/DUEGUI.git   This is no longer functional, I have no more interest in this project.

Happy new year,

Regards,

Graham
27  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: December 30, 2013, 04:48:40 pm

"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  smiley

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

Code:
//  (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  smiley-grin. 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  smiley-wink

HAPPY NEW YEAR everyone !!!  smiley-grin

Regards,

Graham
28  Products / Arduino Due / Re: ITDB32 / SSD1289 With Due on: December 27, 2013, 03:39:18 pm
@dtmacdonald76,

There seems to have been extensive problems with Sainsmart 3.2" TFT, not only with DUE, but MEGA also. You do not need external psu with this display.

My own setup is :-

Arduino DUE ( clone apparently smiley-sad  )
CTE TFT LCD/SD Shield for Arduino Due v1.04
Sainsmart  TFT_320QVT

If you are using the CTE shield, have you uncommented the code in UTFT\hardware\arm\HW_ARM_defines.h ?

Code:
// CTE TFT LCD/SD Shield for Arduino Due
// -------------------------------------
// Uncomment the following line if you are using this shield
#define CTE_DUE_SHIELD 1      < -----------------   !!! uncomment this line
//
// For this shield: RS=25, WR=26, CS=27, RST=28
//********************************************************************

Failing this, maybe you could include your init code?

Again for the CTE shield, and Sainsmart 3.2" TFT, the following code works for me.

Code:
#include <UTFT.h>
#include <UTouch.h>
#include <UTFT_Buttons.h>
UTFT myGLCD(ITDB32S,25,26,27,28);
UTouch myTouch(6,5,32,3,2);
UTFT_Buttons myButtons(&myGLCD, &myTouch);
extern uint8_t SmallFont[];
extern uint8_t BigFont[];

void setup()
{
// Open serial communications and wait for port to open:
Serial.begin(115200);
while (!Serial) {
;
}
Serial.println("Initialising LCD.");
myGLCD.InitLCD();
myGLCD.clrScr();
myGLCD.setFont(SmallFont);
myTouch.InitTouch();
myTouch.setPrecision(PREC_MEDIUM);
myButtons.setTextFont(BigFont);
int butskip=myButtons.addButton( 85,  219 ,70,  20, "Skip");
Serial.println("LCD initialised.");
myButtons.drawButton(butskip);
Serial.println("Waiting for Skip button.");
int skip=2;
while(skip==2) {
if(myButtons.checkButtons()==butskip)
{
Serial.println("Skip button detected");
skip=true;
}
}
}

void loop()
{
}

Regards,

Graham
29  Products / Arduino Due / Re: Printf in Arduino Due on: December 06, 2013, 10:35:59 am
Well I eluded to this in my previous post, but my 'tuppence worth, is that if you do need to issue "\r\n" then do so, but if the choice is taken away programatically such that "\n" will issue CR/LF regardless.............. what if a user actually requires independent control of "\n" , "\r", "\n\r" or am I missing the point here?

Regards,

Graham
30  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: December 06, 2013, 10:29:20 am
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

Code:
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!!  smiley-cry

Regards,

Graham
Pages: 1 [2] 3 4 ... 7