ConnectEVE and EVE Click released!

[anikolic]

ConnectEVE and EVE Click released!



We are proud to be the first manufacturer in the world to release two boards for FTDI Chip's cutting-edge
FT800/EVE graphics controller. We call them ConnectEVE and EVE click.

ConnectEVE brings fast and visually stunning user interfaces to your devices. It’s state-of-the-art FT800Q
graphics controller integrates display, audio and touch onto a low cost, easy-to-use, single-chip solution.
Twelve components (widgets) natively supported by FT800Q chip, transparency support, anti-aliasing and
other features will make your designs shine. Price of the board is $69.00.

EVE Click™ features FT800Q graphics controller and additional modules all packed in mikroBUS™ form factor.
It communicates with a microcontroller over SPI interface (up to 30 MHz). EVE click contains flat cable
connector for connecting 4.3" touchscreens. It also features LM4864 audio amplifier with output screw
terminals as well as power LED diode. Price of the board is $39.00.

Now even 8-bit MCUs can run GUI devices without worrying about performance. FT800 easily handles
4.3” touch screen with 480x272px resolution. We provide free FT800 library for all of our mikroC,
mikroBasic and mikroPascal compilers. Every feature of the controller is covered with a specialized function.
Provided examples help you to get started quickly.

New Live Update 3.6.1 of VisualTFT software is released. It includes board definitions and improved code
generators for these two boards. Now even total beginners will be able to create amazing TFT-based
applications with ease.

We invite you to visit board webpages for more information.

Yours sincerely,
MikroElektronika

[lpmsr]

Is there any documentation for the FT800 library... properties, events, methods? I want to convert an existing SSD1963 project to FT800 and need to understand the differences.

[marina.petrovic]

Hi,

There is preliminary Datasheet for FT800:

http://www.google.rs/url?sa=t&rct=j&q=& ... 1780,d.Yms

FTDI is working on completing the documentation for FT800 chip and soon it will be the official version.

FT800 library you can download from LibStock Web site:
http://www.libstock.com/projects/view/583/ft800-library

Best regards,
Marina

[lpmsr]

I have those. I don't see any documentation in VTFT or Libraries Help for MikroBasic for the FT800. I can see for instance a number of references in the driver code to various methods, but when I use them, I don't get any context sensitive help from the compiler.

ALso, nothing is drawn to the screen until I also use DrawScreen. For instance, if I use DrawLine to draw some lines, only one line is drawn, and then only after I follow it with DrawScreen. Can objects be drawn individually, or do you always have to DrawScreen? Is there a different methodology from the regular TFT library? Are there equivalents to TFT_Dot, TFT_Line, TFT_V_Line, TFT_H_Line, etc? Would the arguments be similar? Exactly how is the stack processed / handled?

I am trying to convert some existing projects from SSD1963 to FT800.

Hi,

There is preliminary Datasheet for FT800:

http://www.google.rs/url?sa=t&rct=j&q=& ... 1780,d.Yms

FTDI is working on completing the documentation for FT800 chip and soon it will be the official version.

FT800 library you can download from LibStock Web site:
http://www.libstock.com/projects/view/583/ft800-library

Best regards,
Marina

[lpmsr]

It appears that what I need is the FT800 Programmer's Guide, but FTDI does not have that posted anywhere. Do you have a link to it?

I have those. I don't see any documentation in VTFT or Libraries Help for MikroBasic for the FT800. I can see for instance a number of references in the driver code to various methods, but when I use them, I don't get any context sensitive help from the compiler.

ALso, nothing is drawn to the screen until I also use DrawScreen. For instance, if I use DrawLine to draw some lines, only one line is drawn, and then only after I follow it with DrawScreen. Can objects be drawn individually, or do you always have to DrawScreen? Is there a different methodology from the regular TFT library? Are there equivalents to TFT_Dot, TFT_Line, TFT_V_Line, TFT_H_Line, etc? Would the arguments be similar? Exactly how is the stack processed / handled?

I am trying to convert some existing projects from SSD1963 to FT800.

Hi,

There is preliminary Datasheet for FT800:

http://www.google.rs/url?sa=t&rct=j&q=& ... 1780,d.Yms

FTDI is working on completing the documentation for FT800 chip and soon it will be the official version.

FT800 library you can download from LibStock Web site:
http://www.libstock.com/projects/view/583/ft800-library

Best regards,
Marina

[marina.petrovic]

Hi,

As I mentioned earlier FTDI is not yet completed documentation, so unfortunately you'll have to wait a little bit.

In VisualTFT you can look at Help-> FT800 Specifics to see some specifics of the FT800 controller.

FT800 always do DrawScreen() function because he "draw" his internal memory.
Controller is designed to do DrawScreen() easy and fast (20ms), therefore it should not be a problem.

Best regards,
Marina

[lpmsr]

Yes, I already measured DrawScreen and found it to be 20ms. I am impressed with the performance, and have changed my overall procedure to just updating components in batches and then then doing a DrawScreen. It appears that I will be rewriting large portions of my project in order to switch to FT800, though.

I have noticed the following so far...

1) Fonts for non-EVE components are not being properly added to the resources file when I recompile my project with FT800 as the interface.
2) Lines are handled in a totally different way than before as I have detailed in other recent forum posts. We need new methods and indexed line properties in order to create multiple line displays like FFT or line graphs. In general, it would be advantageous to have indexed components/properties in most cases, to allow grouping of functionality in the program. This would greatly reduce the amount of work in VTFT since groups of objects could be created programatically in the compiler.
3) In my case (EVE Click & Fusion v7), the default SPI channel needed to be changed to SPI3.
4) EVE Buttons gradient only works if Flat is False, but Flat False adds black shadow, so you can't use black text. Also, there is no edge for Eve Buttons. Of course, there are workarounds like layering buttons.

Which brings up a question. Is there an inherent advantage to using EVE widgets when there is an option to do so? For instance, I have dozens of buttons, round buttons, text, progress bars, etc., and hundreds of lines of code to call them that I don't want to rewrite if there's no obvious advantage to doing so.

Hi,

As I mentioned earlier FTDI is not yet completed documentation, so unfortunately you'll have to wait a little bit.

In VisualTFT you can look at Help-> FT800 Specifics to see some specifics of the FT800 controller.

FT800 always do DrawScreen() function because he "draw" his internal memory.
Controller is designed to do DrawScreen() easy and fast (20ms), therefore it should not be a problem.

Best regards,
Marina

[marina.petrovic]

Hi,

Please, can you explain me a little bit more what exactly you meant when you said: " Fonts for non-EVE components are not being properly added to the resources file"?

Advantage FT800 is that offers optimized solution that reduces power, board area, BOM costs and much more.

In-built widgets allow easy creation of complex objects and in many situations makes your job easier, but if you use your own components, you might need a little bit time to adjust them for EVE click.
Widgets are optimized for quick display on the screen which is a huge advantage.

Best regards,
Marina

[lpmsr]

First question:
When I take an existing VTFT project designed for SSD1963, change the hardware profile to Fusion_v7_FT800 and recompile, the font constants in the resources file are different in name, size, etc.

For example...

SSD1963,

const Arial_Narrow11x16_Regular as byte[1976] = (

const Arial_Narrow12x20_Bold as byte[2572] = (


FT800,

const Arial_Narrow_11x16_Regular as byte[3500] = (

const Arial_Narrow_13x20_Bold as byte[4276] = (


2nd question:
When you say they are optimized for quick display, do you mean that it will affect the 20ms ScreenDraw time? My project has a screen with a dozen buttons and three progress bars, another screen with 150 lines that draws a FFT display, and one with 250 lines that draws a graph. Only the first screen can currently be replaced with EVE widgets. Would there be a measurable difference in screen write time between using the legacy components vs. EVE widgets?

While I really like the performance of the FT800, it looks like I will be starting my projects all from scratch, and they will be much more complicated in VTFT, and use much more code in MikroBasic than my current SSD1963 versions unless there are some new methods coming in the FT800 library... especially as it applies to line drawing.

Hi,

Please, can you explain me a little bit more what exactly you meant when you said: " Fonts for non-EVE components are not being properly added to the resources file"?

Advantage FT800 is that offers optimized solution that reduces power, board area, BOM costs and much more.

In-built widgets allow easy creation of complex objects and in many situations makes your job easier, but if you use your own components, you might need a little bit time to adjust them for EVE click.
Widgets are optimized for quick display on the screen which is a huge advantage.

Best regards,
Marina

[lpmsr]

I think I have tracked down this problem. When opening an existing VTFT project, then switching to an FT800 hardware profile, VTFT assigns some fonts as "System Fonts" when they should be assigned as "Windows Fonts". Manually selecting Windows Fonts and re-selecting the proper fonts cures this problem.

First question:
When I take an existing VTFT project designed for SSD1963, change the hardware profile to Fusion_v7_FT800 and recompile, the font constants in the resources file are different in name, size, etc.

For example...

SSD1963,

const Arial_Narrow11x16_Regular as byte[1976] = (

const Arial_Narrow12x20_Bold as byte[2572] = (


FT800,

const Arial_Narrow_11x16_Regular as byte[3500] = (

const Arial_Narrow_13x20_Bold as byte[4276] = (

Hi,

Please, can you explain me a little bit more what exactly you meant when you said: " Fonts for non-EVE components are not being properly added to the resources file"?

Best regards,
Marina

[lpmsr]

Here are more observations in trying to convert my project...

The original with SSD1963 compiles in 58% ROM space, but changing only the hardware profile to Fusion_v7_FT800 increases ROM usage to 87%!

Legacy ProgressBar when FT800 hardware profile is selected does not have Gradient property shown. I can still use a gradient if I add it in my code in the compiler, but it does not appear in VTFT. I prefer the legacy ProgressBar, as opposed to the EVE one, because it has square edges and can have a gradient.

I think I have tracked down this problem. When opening an existing VTFT project, then switching to an FT800 hardware profile, VTFT assigns some fonts as "System Fonts" when they should be assigned as "Windows Fonts". Manually selecting Windows Fonts and re-selecting the proper fonts cures this problem.

Hi,

Please, can you explain me a little bit more what exactly you meant when you said: " Fonts for non-EVE components are not being properly added to the resources file"?

Best regards,
Marina

[/quote]

[marina.petrovic]

Hi,

I'm glad you solved the problem with fonts.

Quick widget display on the screen will not affect the 20ms ScreenDraw() time.

There can be a measurable difference between using the legacy components vs. EVE widgets.
But I can not know whether it is a significant value (difference) in terms of the fact that you said that your project using a large number of components.

I think that when you start to write your project for FT800 from scratch, you will find that is much easier than translating the code
from SSD1963 to FT800, and it should not be complicated for you (in VisualTFT).

If I understand you correctly, you prefer legacy ProgressBar because it has square edges?
You can disable rounded "button" (false) in ProgressBar EVE widget properties to get square edges.

Best regards,
Marina

[lpmsr]

I prefer square edges and gradient. I do not see properties in Properties window for EveProgressbar for "gradient", "button" or "rounded". Here is what I see...

EveProgressBar1.OwnerScreen = @Screen0
EveProgressBar1.Order = 13
EveProgressBar1.Visible = 1
EveProgressBar1.Opacity = 255
EveProgressBar1.Tag = 255
EveProgressBar1.Left_ = 340
EveProgressBar1.Top = 217
EveProgressBar1.Width = 100
EveProgressBar1.Height = 18
EveProgressBar1.Background_Color = 0x03DA
EveProgressBar1.Color = 0x0148
EveProgressBar1.Value = 40
EveProgressBar1.Range = 100
EveProgressBar1.Flat = 0

Hi,

I'm glad you solved the problem with fonts.

Quick widget display on the screen will not affect the 20ms ScreenDraw() time.

There can be a measurable difference between using the legacy components vs. EVE widgets.
But I can not know whether it is a significant value (difference) in terms of the fact that you said that your project using a large number of components.

I think that when you start to write your project for FT800 from scratch, you will find that is much easier than translating the code
from SSD1963 to FT800, and it should not be complicated for you (in VisualTFT).

If I understand you correctly, you prefer legacy ProgressBar because it has square edges?
You can disable rounded "button" (false) in ProgressBar EVE widget properties to get square edges.

Best regards,
Marina

[marina.petrovic]

Hi,

You're right, I apologize for the error, EVE ProgressBar does not have "rounded" button.
"Rounded" button exist only in legacy ProgressBar.

Best regards,
Marina