Show Posts
Pages: [1] 2 3 ... 7
1  Using Arduino / Displays / Re: Proportional/TTF/OTF Fonts using UTFT and windows on: September 19, 2014, 03:01:35 pm
Hi David,

I don't know if you still follow your thread? I just wanted to say I was a little slow to the party but I am glad I discovered this thread!

I have pointed folks here from another thread, just thought you should know.

http://forum.arduino.cc/index.php?topic=164788.msg1885789#msg1885789

The major use for this that I can see, is people wishing to use the BVS fonts included in the Coldtears display font IC, that do not have that ic. So I located Bitstream Vera Sans.ttf and converted it using your ttf2c_vc2003 tool to all the sizes I know about, and this worked flawlessly thankyou!!

However one 'slight' niggle/suggestion if I may? Could you modify the tool slightly to use <output-file> as the c array name? Such that
Quote
ttf2c 112 vera.ttf BVS_112.c
   would yield a c array of the same name as the filename in this case BVS_112.c?

I am surprised a thread as old as this, offering the features you do, has not gotten more traffic or comments, so let me say a big thankyou! I for one certainly appreciate your efforts and can definitely see it receiving some use here.

Regards,

Graham
2  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: September 19, 2014, 02:34:06 pm
Hi everyone,

Since my last post I have had chance to play with UTFT_DLB. It does what it says on the tin!! I am impressed how easily you can have ANY TTF/OTF font you could desire. Since the focus of many people is the BVS fonts included in the CTE font and icon ic, I have converted all of the sizes I am aware of into .c arrays for use with the UTFT_DLB extension library ( BVS_13, BVS_15, BVS_19, BVS_22, BVS_28, BVS_34, BVS_43, BVS_52, BVS_74, BVS_112 ).

No doubt you are aware, but for newbies I will point out that the larger the font size, the larger the array will be, such that BVS_112 alone is 232KB!

I think this is a great discovery for anybody having the same issues with missing BVS fonts that I had!!

Regards,

Graham
3  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: September 17, 2014, 01:22:18 pm
Hi Everyone!

If anybody is still following this thread with an interest in fonts for non font-ic based displays, I came across something interesting earlier. It is a library by a fellow arduiser (word copyrighted to me meaning arduino user!  smiley-razz smiley-wink ) called arduinodlb aka ' David Badham'. He has produced an extension library to UTFT which allows

Quote
Proportional/TTF/OTF fonts to be displayed on Arduinos. It extends the UTFT library and adds ttf derived font capability. It includes a tool that runs on windows and converts any ttf/otf font into a compact proportional bitmap font for use on TFT displays.

See his original thread here http://forum.arduino.cc/index.php?topic=189964.0.

I have not played with or tried his library yet, but it sounds like an ideal addition to DUEGUI!! I would be interested to hear others' thoughts? Henning already has the market covered for monospaced fonts, but I felt there was a need for proportional spaced such as the built in BVS font on the CTE SD1963 displays?

For those of us not fortunate enough to have such a display, the font abilities of the UTFT library are somewhat limited, 've3sjk' recently raised this point although completely overlooking the fact that ediaz already allowed us to use UTFT fonts on non font-ic equipped displays!

I have a question of my own at this point, my CPLD 5" CTE display does not have any form of font-ic, however it does have the SOIC-8 pad to allow one to be added. So what is the largest capacity viz-a-viz best recommendation for an ic to add to my display?

Regards,

Graham

Edit: I answered my own question regarding best choice of IC, it would appear to be the Winbond W25Q128FV  128mbit(16MB Hi-speed 104MHz QSPI) - it turned out to be a little more difficult than anticipated trying to locate them in the UK( including Scotland!! smiley-wink ) however!
4  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: September 16, 2014, 11:48:47 am
Hi Endevor,

Top of page 10 is a git link. Thats the latest. Ediaz did most of the work but has extracted the original UTFT/Touch etc from DUEGUI to allow it to function on whatever hardware is supported by the UTFT suite of libraries.

I ran into problems with the 'invisibility' function and how best to implement fonts on non-font ic equipped displays (although you can still use bigfont/smallfont built in to UTFT).

I vaguely remember something about interrupts........ was the reason not compatible with Mega? Don't quote me! Since the UTFT libraries do run on the Mega, you have nothing to lose by trying?!

Regards,

Graham
5  Products / Arduino Due / Re: Using a 7" tft touch display with Due... some needs.... on: September 14, 2014, 11:24:34 am
Hi akard,

Slow down a bit!! Try to get only one function working first, then the next, then the next.

From the picture of the kit you provided on ebay, the flash ic appears to be absent, indeed I understand it to be a little 'hit and miss' as to whether you have the ic or not. You can check, look if there is an ic soldered on the 8 pin pad at the side of the SD cage on the rear of TFT.

By defualt, the SD socket on the CTE shield is not enabled. Please see technical info quoted from CTE_DUE_shield.zip/DUE_Shield_readme.txt.

Quote
CTE TFT/SD shield for arduino DUE
coldtears electronics
http://www.coldtears.com/electronics

This shield is created for arduino DUE, which fit two types of LCD:

1. 40pin version LCD which is commonly used in previous version of TFT Mega shield for Arduino MEGA 2560
2. 32pin version LCD which is commonly used in STM32 development board.

There is a SD slot and a Font IC (SPI flash) footprint, for upgrade to include Font IC to draw text to the LCD. These two features are created to support LCD modules which do not have SD slot or font IC.
-----------------------------------
To use with UTFT library:

1.uncomment "#define CTE_DUE_SHIELD 1" in the HW_ARM_defines.h in the \hardware\arm folder of the UTFT library

2.Change the pinout to : UTFT myGLCD(CTE50,25,26,27,28);

-----------------------------------

Using the Touch function:

Remember to change the touch initialization to the following if it does not work.
The TP DataIN is routed to pin 32 of arduino DUE instead of 4.
(Because pin4 of arduino is a hardware SPI CS pin, which is reserved for SPI device)


------------------------------------
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)

First of all, it can be seen that to use the SD socket on your CTE Shield, you need to bridge JP8 with a blob of solder.

Then you will need Henning Karlsen's libraries :-
tinyFAT http://www.henningkarlsen.com/electronics/library.php?id=37
and
UTFT_tinyFAT http://www.henningkarlsen.com/electronics/library.php?id=53


I don't wish to hold your hand do this for you, but the common pitfalls with tinyFAT are SD card MUST be 2GB or less, formatted as FAT16, and filenames MUST be 8.3 old style dos names ie:-  myimage1.raw

Henning says
Quote
The library supports FAT16 formatted SD cards up to 2GB in size. 4GB FAT16 formatted SD cards does not work. Long filenames are not supported. Keep your filenames compliant with the old 8.3 standard.

Be warned!! tinyFAT and UTFT_tinyFAT take some doing to get working successfuly, as there are just so many variables. SPI Speed can be a big issue with several newer SD cards and quality of level shifters if required.

Once you have the tinfyFAT working............UTFT_tinyFAT is easy  smiley-wink

Code:
myFiles.LoadBitmap(xcoord, ycoord, xsize, ysize, "myimage1.raw", (rotateangle [optional]));
myFiles.LoadBitmap(xcoord, ycoord, xsize, ysize, "myimage1.raw");

The touchscreen size issue, I am aware of but not familiar with, as I do not have the SD1963 version of this display, mine is the CPLD version, I suspect I am not able to assist you further.

If you wish to post back your experiences based on my suggestions, feel free, I just thought I would try to help you since nobody else replied so far!!

Also, as a final comment, maybe worth mentioning some people have had problems with the 7" displays if you are relying completely on USB power, you should also use external wall power adaptor (9V 1A).

Regards,

Graham
6  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: September 10, 2014, 02:16:43 pm
Hi ve3sjk,

Oddly enough, the last time I checked, my display didn't have the BVS font either, nor did any of the examples used by ediaz or myself....

Regards,

Graham
7  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: September 03, 2014, 10:14:39 am
Hi Melodic,

In that case, this thread is definitely not the best place to be asking for help.

Good luck with your endeavour.

Regards,

Graham
8  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: September 03, 2014, 08:52:18 am
Hi melodic,

Ok, so that adds some more detail to your requirements. I started something similar a couple of years ago with GPS, although not 18Hz.

My initial thoughts would be, why do you NEED 18Hz screen refresh? To be honest unless you are travelling at Mach 3 you probably don't actually need 18Hz GPS either, but as with all things there are countless ways to achieve a similar end result.

The way I tackled the screen was to have a flag, which called to refresh the screen if 'something' on screen changed, whether that was the time, latitude, longitude, altitude, speed, distance from/to target or way-point or whatever else you might dream up from your flashy new 18Hz GPS!!  smiley-wink However you do need to be sensible and realistic, you are not in control of an i7 with SLI nVidia display hardware  smiley-razz. You will NEVER achieve what you are asking with the hardware you are using, so you need to compromise, and it is up to you to decide which compromises will be acceptable.

Let's say you have a MANDATORY requirement for the 18Hz GPS, thats ok, the DUE can handle that in its idle time..... so do your clever calculations and stuff on the data coming from the GPS and update only the required parameters on screen which I can promise will not need 36fps!!

The 100*50 pixels graphics...... what is that? Pointers, arrows, direction indicators, or map fragment? Will it ALWAYS be in the same location? If so, there is no need for full screen erase/update, just overwrite and only update the necessary fields.

I would also say that DUEGUI is not your best platform to do what you are wanting, as such, there is a whole heap more wisdom and knowledge on the Arduino forums if you were to start a new thread in the DUE section, or Display section.

I understand your code snippet is just an example of what you are trying to show, but a couple of pointers, bad practice to include things that will not change inside the loop, also the repeated clear screen is what causes your flicker. Try this :-

Code:
#include <UTFT.h>

extern uint8_t BigFont[];

UTFT myGLCD(GEEE28, 38, 39, 40, 41);

void setup()
{
  myGLCD.InitLCD();
  myGLCD.clrScr();
  myGLCD.setFont(BigFont);
  myGLCD.setColor(255, 255, 255);
}

void loop()
{
  long int mytime = millis();
  myGLCD.clrScr();
  for (int i = 0; i < 255; i++)
  {
    myGLCD.printNumI(i + 100000000, CENTER, 0);
    myGLCD.printNumI(i + 100000000, CENTER, 20);
    myGLCD.printNumI(i + 100000000, CENTER, 40);
    myGLCD.printNumI(i + 100000000, CENTER, 60);
    myGLCD.printNumI(i + 100000000, CENTER, 80);
    myGLCD.printNumI(i + 100000000, CENTER, 100);
  }
  myGLCD.printNumI(mytime - millis(), CENTER, 225);
  delay(2000);
}


Regards,

Graham
9  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: September 02, 2014, 09:46:38 am
@melodic,

I too saw the example of hand modified UTFT library that you reference, but if you were to compare your hand modified AVR version with the standard DUE version, I believe you will find the DUE to outperform even the modified AVR version? Can you give us an example of what you are trying to achieve and the performance figures for that task on modified AVR and standard DUE?

I have played extensively with Hennings UTFT library, modifying some elements of UTFT_TinyFAT to better serve my requirements for drawing bitmaps. I now have the ability to draw a portion of a LARGE bitmap on screen and scaled if required, on my DUE and CTE shield, and SD1689 display, this takes about 0.3seconds for 240*240 image.... Oh, just to mention, the same thing on a MEGA2560 took approx 1.2Seconds....

It really is quite meaningless to just say even on a DUE it is slow. WHAT is slow?

Regards,

G
10  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: August 24, 2014, 05:14:18 pm
Quote
https://github.com/ghlawrence2000/DUEGUI.git   This is no longer functional, I have no more interest in this project.

I may have been slightly untruthful about functionality, try it, you never know!!  smiley-lol

Graham
11  Products / Arduino Due / Re: Due GUI (Graphical user interface) - [now community project] on: August 24, 2014, 09:43:58 am
Hi Pamapama,

If you have read this full thread you will see I came late on in development and lost interest fairly soon afterwards. However, I will try to help if I can.

Have you successfully compiled and ran any of the other UTFT Demos? What I am getting at is, have you changed

\Arduino\libraries\UTFT\hardware\arm\HW_ARM_defines.h

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

Let me just mention, I have not played with IDE 1.5.7 before, but just trying to give further meaningful assistance today, I have tried to compile and run 'several' sketches of my own that previously worked fine under 1.5.4 but now appear to have developed issues. Sorry.

Try this first, and in the mean time, I will try to sort out my IDE problems.

Regards,

Graham

PS, It just occurred to me, are using DUEGUI 0.13? from page 1 of this thread? Potentially, it would be easier if you used ediaz' version which has been extracted from the incorporated UTFT, UTouch etc.
12  Products / Arduino Due / Re: SdFat for Due posted on: August 08, 2014, 06:55:40 am
Hi ArdunioDetection.
 
Quote
I have a Breakout Board for microSD Transflash from SparkFun (https://www.sparkfun.com/products/544) and I am trying to connect it to the Arduino Due I just bought.

Those things are notoriously difficult to get working first time, especially if you are new to all of this! The first and most common problem is connecting wires that are too long, and personally I like the to have the wires the same length too.

Quote
5V into Vcc and GND into GND

????????!!!!!!! 5V into Vcc!!!!!!!!!???????

You may actually have destroyed your SD card..... You SHOULD NOT be using 5V with an SD card!! They are all 3.3V for supply and signal level!!

Quote
I read this entire forum and countless others and still can not figure out what i am doing incorrectly.

You read this entire forum but chose to ignore my post immediately prior to yours?
Quote
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 default, which will go some way towards proving if the SD card is not so good.

One final comment, I  notice from your code you commented out the pinmode statement.

Quote
// or the SD library functions will not work.
 
  //pinMode(52, OUTPUT);    <---------- ?? Uncomment this!!!

  if (!SD.begin(52)) {
    Serial.println("initialization failed!");
    return;

Assume your SD is now dead after its exposure to 5V, so test in another device or get another card before you go any further.

Try my suggestions, and post back how you get on.

Regards,

Graham
13  Using Arduino / Storage / Re: SD card + TFT 3,2" on: April 09, 2014, 05:00:53 pm
I find it strange that Sainsmart is still producing these boards with errors.

Thanks in advance,
JMR smiley-sad

So do I!! My V1.0 Sainsmart board ordered 23/10/12 worked straight out the box with none of the problems everyone else seems to have had with this board!!

Regards,

Graham
14  Using Arduino / Displays / Re: Problem with UTFT bitmap buttons and setFont on: February 28, 2014, 02:20:37 pm
Sorry I couldn't be more help, and I did spend quite a large portion of today working on this to try to make amends for my previous mis-information  smiley-sad I agree this does seem to be a fairly big problem, with limited successful solutions, and even with what I have read and discovered, I think to implement some of the suggestions would require additional input from Henning, who I know from past dealings is not keen to make big changes for small audiences..... So just for information really if nothing else, and if you are committed to the MEGA maybe this will serve you in future projects....

http://forum.arduino.cc/index.php?PHPSESSID=2ohs6febc03cn3u0k753e69om4&topic=146211.0

The reason why your sketch works on the DUE and not the MEGA is sort of what I thought(ish)... compare these two pages :-

http://coverclock.blogspot.co.uk/2012/02/arduino-data-types.html

http://coverclock.blogspot.de/2012/12/arduino-due-data-types.html

I do like the idea of multi segmented PROGMEM statements utilizing #include <morepgmspace.h> but I dont see how that could easily be implemented with UTFT....

Best wishes,

Graham
15  Using Arduino / Displays / Re: Problem with UTFT bitmap buttons and setFont on: February 28, 2014, 10:20:34 am
My knowledge of these things is not sufficient to explain clearly to someone else, I just know enough to get by and understand why its not working. Try looking at this link and some of the others in this reference document http://www.atmel.no/webdoc/AVRLibcReferenceManual/group__avr__pgmspace_1ga73084a8bbde259ffae72980354b3f027.html.

Someone with a greater understanding of this stuff than me................could possibly tell you how to work around this on the MEGA. If you look inside UTFT.cpp,  you will find there are a few uses of
Quote
pgm_read_byte
, specifically UTFT::printChar and UTFT::rotateChar both of which are used by UTFT::print. Additionally in UTFT::drawBitmap, you will see
Quote
pgm_read_word
is used which is how your images appear on your buttons.

I can't explain why the same code works fine on the DUE but not on the MEGA, my tentative personal suspicion is that maybe 'word' = 32 bit on the DUE but only 16 bit on the MEGA.

Not sure if this is helpful to you, but it is the best I can figure at the moment.........

Regards,

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