[TUTORIALS] V-TFT beginners example projects

[Megahurts]

Hi All Users,

Just a quick notice for those following the development of the Beginners Tutorial Project Manual.

I got a little more editing done on it and added some more graphics that is easier to follow than the text.
I have also added a graphic marker to sections that are under construction and waiting for more content to be added.
(I'm pretty sure you would want them to have more information)

Added a few "Pro Tips Scrolls" that contain advanced V-TFT project principles. More to be added later.

The manuals file name now is: Event Counter Tutorial Manual Ver3.0_update 12-15-2013

I'm still learning the ins and outs of the oOoWriter program and trying things to make the updating of the manual easier for me to do.
I have also added mPASCAL for PIC to my tools and testing it out.
So there may be a time before the next update while I do some conversions of what I have in it now.

Regards, Robert.

[Cobalt]

Just waned to stop in and say thanks for the work Megahurts.

The guide has been pretty helpful, keep it up!

[Megahurts]

Hi Cobalt,

You're Very Welcome And Thank You For Stopping By To Say So.
I am still adding and working on updates. There are so many things I didn't get put in the tutorial that I didn't think of at the time.
At "Beginners" level, there is a lot of "little" pieces of information required (or very handy at least) for every element of using V-TFT and
Some of the required information also encompasses the other HW and SW also.

Sometimes a thing turns out to be more difficult than first thought of.
AND, Only 2 of a V-TFT Projects files have been covered so far, I just realized
kidding I knew they still needed 2 be done
Good thing I like challenges.

But good news, have a small update to the example project V-TFT files almost done:

event_counter_screen1_v1_new.jpg (39.18 KiB) Viewed 9235 times

New GUI graphics panel screws additions to the top panel that now has boarders.

event_counter_screen1_v1_new2.jpg (34.87 KiB) Viewed 9235 times

New Reset and [-] Minus Button boarder will alternately blink (both shown red above) after reset clicked 1 time waiting for decision.
and the message is now a boarder less Button used instead of a Label Component,
so redrawing the whole screen to erase it after reset or cancel has been clicked is not done.

File is now updated [11/18/2013] get it from here: (includes ESC Screens Package)
http://www.libstock.com/projects/downlo ... _dspic.zip

l8ers, Mhz.

[Megahurts]

Following Image Is A Composition Of The V-TFT Screens IN The DL Link Below:

esc_screen_collection.jpg (658.72 KiB) Viewed 9225 times

I have some V-TFT screens made for an ESC project for MMB that I won't be using any more.
I switched the project to the FT800 EVE HW, so these are available for you to examine, use, burn, whatever...

You just need to un-zip, it makes a folder, (each screen (.scr) has a picture (.bmp) to view), and then import into V-TFT (the file.scr) to see how it is made
with V-TFT objects and components and the layering on different layers.

A better way to supplement the Tutorials Layering section - hands on examples.
I didn't want to see the work go to waste (trash bin).

All Objects (Components) are reusable in any V-TFT Project.

ESC Screens.zip

(195.81 KiB) Downloaded 330 times

enjoy, Robert.

[SimonD]

Hi Megahurts,

First at all, congratulations on your excellent work and your patience!
Please, i would like to ask something rather simple for you.
Suppose we have a project with 1 main and 3 ... 4 sub-screens.
how and where we could add a subroutine (in mikroBasic) so if after x time eg 3 seconds, not pressed any button screen (event), to return automatically to the main screen?
I suppose that should be made use of interrupts? ( I work with ARM STM32).

Thanks in advance,
Simon

NB Sorry for my bad English.

[Megahurts]

Hi SimonD,

Thanks for stopping by and saying so, and you're welcome. I've had fun making this whole tutorial and feel it was worthwhile to do so.
I am not done with it yet either, more to come still. A lot of areas of using V-TFT and making projects work was not covered.
That is due to how flexible the software is and the multitude of possibilities you can make with it.
Your English is fine also btw.

The easiest way I can think of to do what you want is to do something like how I make the RESET button blink in the tutorial.

Think on this:

In your project, whenever user presses a button to get to a different screen from the main one, in that buttons event handler
have it call a "User Code" routine that sets a global variable flag (byte), clears a counting variable (it might need to be at least of word or longword type, maybe larger, depends on speed of MCU)
Every Button that takes user to different screen calls that routine so that code is common for each and only needs to be written once.

Then a user code test block in the "Main Loop" (like mine in example) checks if flag is set.
If flag is set it calls another routine in the "User Code" area in projects "events_code" file.
In that routine, first it checks if the counting variable has reached a threshold amount, if not increment the counting variable by 1 and exit routine back to instruction after its call.
If it has reached threshold - do what ever tasks needed to get ready to go back to your apps main screen and once ready
do the drawscreen(screennameScreenID) to change screens back to it right before exiting the routine.
Also clear the flag before exiting it otherwise the counter timer keeps running and not wanted to.
(you will need to experiment with the threshold value to get the timing you want)

No interrupt needed and still available for other uses if needed.

The counting routine acts as a timer for how long to wait before changing screens.
In this method, all of your applicable Buttons for each screens event handlers need to check flag state and or counting timer value
and set flag and counting variables values to set timing conditions for current state.

Flags states:
One state (say 0) nothing happens and routine is not called.
2nd state (say 1) the counting timer routine is called and timing is being done.

Button event handlers on "sub screens" will also clear back to zero (0) the counting variable anytime one is pressed. (resets timer)
(but the counting timer routine is being called once every pass in main loop so is running as long as not on main screen)
So as long as on any sub-screen the counting timer routine gets called as a 2nd main loop task.
Any Button activity that take user back to main screen clears flag and counting variable.


Or if you want to do the interrupt way, find the values to have it cause one at the time you want.
Your event handlers routines have code to check if interrupt is active or not and set it as desired for user caused conditions.
(basically every time user presses a button, clear counting variable or reset interrupt timer)
The interrupt service routine just needs to clear the interrupt condition and set a User Code Flag for user code in main loop to act on.

Examine the tutorials code and comments on the User 2nd main loop task and the flowchart examples in the latest PDF manual.

I only use PIC based devices for now so can't give detailed instructions for other HW I don't know about.

But I hope this gets you going right, Robert.

[Megahurts]

Hi all,

Since it is almost Christmas, I have a present for you all.

New Version 3.0 Tutorial Manual is available now at the Libstock manual download link posted below in this post.
(or at the Libstock examples page)

New topics, graphics and page layout size. More information but close to same number of pages as before (33).

Ver.3 Table of Contents showing new topics

event counter manual v3 toc.jpg (279.23 KiB) Viewed 9037 times

Includes now some coverage on the Driver File and a sneak peek at upcoming program update.

Again, version is now 3.0 and edit date of 12/15/2013
http://www.libstock.com/blog_docs/get/5 ... ter-tu.pdf

Addendum: I guess timing is everything, New version of V-TFT released the day after I get this done and posted, wow.
So good news for everyone and means I got to get back to work on some revisions myself. Will be testing newest version
to see what needs to be updated in manual. So next update will be next year regardless. Happy programming everyone.

Happy Holidays to all and a Happy safe New Year celebrations wish, see ya next year, Robert.

[PIC007]

Hi Robert,

In your helpful tutorial you have stated "Buttons automatically erase the old displayed data as they write the new data. (less user code instructions needed)".

At first I seemed to be unable to get this working. My test code being:

void ButtonRound_Btn1OnClick() {
DrawBox(&Box_Results); // Bring results box to FG & make components visible
Button1.Caption = "Text1 ";
DrawButton(&Button1);
Delay_ms(1000);
Button1.Caption = "Text2";
DrawButton(&Button1);
}

Output appears as Text2 superimposed on Text1?

After a lot of trial and error, I found the problem was that I had set the button's transparency property to true (to force the appearance of a text label on the background). It seems if you set it to transparent, then the previous caption is not erased before the new one is written.

The work around to get the functionality you mentioned is to leave transparence as false and set its color property to the same as the background it is on.

Any idea why it does not work if transparency is used?

[JohnGB]

There are 2 ways of erasing text:

1 Write out the old text value but with the font set to the background colour the write then new value
(This is not a reliable method as rounding errors in the code leave parts of the original characters)

2 Place solid rectangle over the area to be erased with the fill colour set to the background colour.

The second method is the method used to paint a button.
First the button outline is painted with the fill colour set to the colour value for the button. If it is transparent the button outline will be simply the outline with no fill. The new text is then written to the button.

Thus if you set the button to transparent you will never be able to overwrite the text. You must set the button colour to a proper colour value.

I hope that clarifies the issue.

[Megahurts]

Hi PIC007,

JohnGB is right.

I need to edit that part in the manual, too vague now that I read it again. The info was there, but not clearly ordered and some
screen captures of the differences would help make it easier to understand.

The Transparent property is a tricky one to use and get desired results.
When any object has transparent set to True, an area of the object (the fill color(s) in center of object), just becomes no data to send to the screen and have drawn. Whatever is on the screen in that area remains as it is, unchanged.

If you have a Button on a screen, then change only its transparency to True and redraw it, you will see no change happen on the screen. This is because nothing changed any pixels states in the display buffer. What pixels get changed depends on color changes and text changes.

Color changes happen because V-TFT objects are just primitive drawing commands native to the TFT organized into specific shapes and drawing order. V-TFT drawing functions will send all the commands needed to the TFT for every object, but the TFT display will only change if those drawing commands it receives actually makes changes to the data (display buffer) it is currently using to make the display you see.

V-TFT and the common TFT's used do not keep track of what WAS on the screen behind anything that gets drawn to it. All they know is what is there right now, so you have to plan your visuals as steps in a series (order) leading to the final result at all times.

There is no way to track old display data unless you code a virtual display buffer to save last screen displayed info yourself and it would require a lot of memory to do so. Memory for the screens resolution and code to properly index it for I/O to rest of the application and interaction testing. You would not be doing anything else for the next year probably.


The next updates will be a lot of pictures added in the areas where there is only text describing stuff. It's the way I go about making these in some areas, ideas to text first, then add pictures if text is not enough to explain accurately.

As this post would have been better if I had pictures of examples described here, right. 1 picture = thousand words.

Btw, there is a third way to get changes displayed correctly, DrawScreen().

PIC007, did you also check out the other example V-TFT project I made about using Buttons as Labels?
It is also at Libstock and the new manual has hot link to it also.
That example shows Labels and Buttons displaying the same things and some variations of Button visual configurations.

Don't worry, after you get the way the TFT and V-TFT work together, you will find that you naturally make your projects screen layout designs so that they are easier to code and manage. You learn to automatically stay within the HW/SW limits.
Takes time, but it does become easier.

Thanks for the assist John. Happy Holidays to you guys also. Hope this clears things up for you PIC007.

If you still have questions, just ask. Cheers, Robert.

[PIC007]

Thank you Robert and JohnGB for the helpful answers and background explanation on how the transparency property works.

PIC007, did you also check out the other example V-TFT project I made about using Buttons as Labels?
It is also at Libstock and the new manual has hot link to it also.
That example shows Labels and Buttons displaying the same things and some variations of Button visual configurations

http://www.libstock.com/projects/view/7 ... mples-demo
Thanks, this is the link from your v3.0 tutorial manual, I will study the code.

Btw, there is a third way to get changes displayed correctly, DrawScreen().

Yes, I do realize this but have avoided using this method as I note unpleasant "blink" in the screen as a new one is drawn.

Actually this touches on a fundamental issue I am grappling with in vTFT - I have a layout where much of my main screen is common to others (header, footer, menu buttons down one side) and only an active display area changes from one 'page' to another. Is the preferred approach to prepare a screen for each 'page' and DrawScreen the appropriate screen each time a menu button is pressed, or should one be keeping only one screen and trying to hide those components no longer needed in the active area and make visible new ones?

I keep feeling something is missing in VTFT that stops me grouping together those components needed on one page and make them visible / invisible as required; but then again, maybe I am approaching this all wrong?

Thanks Megahurts for the great work you do to help us all with your tutorial - and John for the prompt replies.
Tony

[JohnGB]

Personally, I try to keep the number of screens down to avoid the very obvious redraw.
Wherever possible I try to put all components on the screen and only make those components currently needed to be made visible.

There are some issues with this approach if you just use the visible property because in my experience it requires a screen redraw to hide a visible control. The better approach is to overlay the component. Even this causes quite visible flicker which is impossible to avoid.

I agree with you about grouping and it would be very helpful if you could operate on a group of components at run time. However, mE's priorities are to sell boards and so the support of new boards comes before anything else and there are a number of issues I would like to see addressed before grouping.

[Megahurts]

Hi Tony,

I understand the confusions. All too well.

This is actually a topic I was hoping to get some help from Aleksandar on covering soon. (sooner now it appears)

When Aleksandar gave me his submission for the alternate code for the example project, I realized he knew a cool trick for users
to make their own code groupings to control multiple objects properties.
The clue was his using a user declared pointer array to a property in multiple objects.

It is in the Tutorial manuals example code listing of the events_code file.
Those interested, take another look over his code in the manual, specifically the declarations part.
Maybe you can see what I seen and take it further than that sooner, until Aleksandar and I can get something put together.

If done right and doable in the programming languages, being able to do what you want to do (controlling many objects visible or not by a single flag) can be done by users making their own pointer controls.

As to doing less screens but make it appear there are more by controlling the objects visible property, this solution can be a big help in keeping the objects
working in virtual groups together with regard to the multiple properties needed to be changed correctly so no issues arise as to what is visible or not and keeping the "Active" properties synced with them also.
Personally, I do not have a problem with doing a complete screen redraw in cases like this. It would have to done anyway if you were to actually change screens so appearance wise, you got same results.

I think it is a very powerful and doable solution to allow users advanced control and more flexibility in their designs. I know there are more possibilities available in V-TFT by the way it is designed and how objects are code structured, but it has been up to us to find them so far because of the lack of a fully detailed product manual.
The only information we got with V-TFT is the bare facts of the objects properties and nothing about all the various ways users can
take advantage of referencing their properties with their own pointer structures in any examples.
If there are any in the examples, they are not pointed out or mentioned as useful practices for users in the current documentation.

My work in V-TFT and seeing what problems and questions users are posting about has led me to some very intensive studying of the output code V-TFT makes
and I have seen what I think are solutions to many problems users are having and requests users are making for features to be added to V-TFT.

I have made a resolution to solve as many of those as is practical to do for the next year, but I do have to have some help from others
that have more talent or skills in a few areas of the programming languages that I do not possess, yet.

If I get the help, Next Year will be a different one for V-TFT users, I promise, Robert.

[lejeff]

Hi Robert

ARe you sure of that (page 24 of your tutorial) :

"SHRT_STR[0] = TEMP_STRING[3]
' if (Button_Million_Caption <> SHRT_STR) then
' Button_Million_Caption = SHRT_STR
' DrawButton(@Button_Million)
' end if"


I've check that method in my code.
It seems that the expression of the "if statement" above (Button_Million_Caption <> SHRT_STR) is not valid.
string comparison is not allowed and release a compiler error with mikrobasic pro for pic
The work around I've used is to compare the "byte value" of the 2 strings (with str2byte)
.... if (str2byte(Button_Million_Caption) <> str2byte(SHRT_STR)) then ...

[Megahurts]

Hi lejeff,

Nope, I was not sure, I was using regular PC programming type logic allowed, didn't think about PICs limits, Sorry.
I forget the limits of automatic conversions to simplest terms sometimes.

Your work around is probably the only realistic method to do to do it. Thanks for testing and pointing that out.

I'll change the manual and with your permission, put your code in to replace and credit you for it?

Robert.