Mikro's Visual GLCD with PBP3

Hi guys,
i am working on adding a T6963C 240x64 as well as a 240x 128 , with resistive touch GLCD to my current project
I have been evaluating Mikro's Visual GLCD program and the free font generator program to generate the fonts, layout buttons, and other feature the software templates provide

http://www.mikroe.com/visualglcd/
http://www.mikroe.com/glcd-font-creator/
both programs generate MIkobasic code output.


the current thought is to run this code in isolation to sort out the final display look and issues , then port the library, and associated files it to PBP3 in the final code to marry up with the rest of the projects code in PBP3.

this is not a small task to do , the libray used would take to time to redo in pbp3, plus all the extra code generated for the the display it self

if any one who has used this software , can give an insight on IF this is the best approach to do this, or offer another way.

i have found some code done in picbasic to support the 6963c controller in picbasic,
but at this point i cant see how to make use of it when looking at adding extra graphics screen logos and fonts easly , but the base library and demo seems to be a good start

http://www.compsys1.com/support/PBP_Files/T69B/

I have not at this point used mikrobasic at all, but have access to it , but these 2 programs ability to generate code from nice on screen graphics etc , is way better than my own at this point, even if a learning curve is required and then to change it all to pbp3 ????

look forward to some guide on this


regards

Unless you are very clear on the requirements for your GUI and define its elements, you may find it very uphill to find enough room to handle the elements later on. Best way to do that is to draw the various screens (by hand if you may) to decide what you really need

Usually, a GUI is built up with graphic elements like icons, rectangles, rounded-rectangles, sometimes circles, images, text of various sizes and such. The usual way to draw these would be to store the images of them somewhere and retrieve when needed. The other way would be to generate them via code. the code approach needs a processor with a decent speed to enable drawing the screen multiple times. The larger the graphic element, the longer it takes to put to screen; so, storing the graphic as an image and pulling it on demand is the faster way to do things. However, the disadvantage is you cannot size up/down easily.

Typically, a RGB display would use the RGB565 16bit format for color handling. You could also use the 24 bit full color format. An image 320x240 pixels rendered in full color will need 320x240/8 bytes per plane. So, rendering the 3 planes of Red, Green and Blue will need data worth 320x240/8*3 (=28800) bytes. So, now you see how big the demands can be. AFAIK, visualglcd uses a display with a SD card memory bank to store visual elements. I may be wrong there. I am not conversant with how displays with the backing SD memory work.

There are ways around this situation in a slightly restrictive way. For one, you could render a monochrome bitmap in a single color of your choice. So, the icon could be rendered with pixels of a single color only. Dithering can help generate monochromic shades in the color.

Fonts too require a lot of room to store. More fonts, more space needed. Ideally, a couple of font sizes is what may be really needed.

There are some tools that will help you convert on-screen fonts to data arrays and also on-screen bitmaps to data arrays. Unfortunately, most of them are C-oriented. One that I like best is a GPL'ed tool called "The Dot Factory" from Eran 'Pavius' Duchan http://www.pavius.net

Drawing primitives like line, circle can be done using the Bresenhams' algorithm - plenty online references. Drawing rectangles is just an extension to drawing lines. Filled / unfilled, same story. Rounded rectangles needs a little more. As you keep building the primitives library, you will realize, graphics is not intended for tiny embedded systems with limited resources. You need a capable processor with lots of flash and RAM for double buffering. At most times, embedded systems will use static / slow moving dynamic screens. Achieving video frame speeds needs a lot of hardware support too(like DMA and External memory interface).

There is another site that was quite an inspiration to me - Andy's workshop. Though most code is in C++, you can get quite a lot of knowledge there. http://andybrown.me.uk

I hope this has been of some use to you

the requirements of the displays are that they are mono , with most of the fonts limited to 3 sizes and numerics , very few graphics , i have larger storage on board though sd card for logging , but are hoping that i may get it down to be used in the 128k words space of the pic. my C translation skills are not great , less than they would be for the mikrobasic , which i compiled a sample test of the font code today from the free font software.

It seems like there is no easy way to go with this part of the project , no ready fix to apply a graphics screen , other than to try an see , which , is very slow way to go

Don't be discouraged, I too started with monochrome displays at first. Though it seems difficult at first, the joy of having it working is a thrill in itself. Monochrome displays are very easy to work with. They follow the same rules as the color displays. You need to create the fonts / images and draw them to screen. The real challenge is in making it draw fast enough to make it appear as near to real-time as possible; keeps the display flicker-free.

well after looking at the glcd library and the generated file from mikrobasic , i left attempting to change it to PbP3 format till another day

, i have continued with the example t69_lib on the link given , its very old code but it gives a starting point to get the display running

I have managed to get the font size and data from the mikro free font creator and after re writing some of the old t69b_lib got the larger font chrs to be displayed at the locations need , BUT......


yes there is always a 3 letter or 4 letter word

The larger font chr are slow to update and cause the display to flash the chrs more so than smoothly update them

my routines to show the larger fonts are simply , select the chr required using asci , jump to a subroutine that contain the data and send 90 bytes of that chr to screen , this does this for 10 chrs 24(x) x30(y)

removing any delays from this graphic update , just flashes the screen for those chr faster , and dims the display of those chrs

i clearly need to update 1 only the chrs that change , but as this is a fast counter being displayed most are changing anyway

Can anyone advise on how this overcome in how i approach displaying large fonts on glcd which is changing chr fast

Regards

Sheldon

I'd be glad to help.

Typically, writing to the glcd should be done as fast as you practically can. Ideally, your glcd routine needs to flip bits CS, WR, RD, A0, before you write something; it will be better to concatenate those 4 operations into one single write. It saves a few uSecs, but doing this repeatedly, you end up saving a lot. You may also consider in-lining your basic Command_Write, Data_Write operations so that the gosub-return overhead is avoided. Within those XXXX_write routines, you may save still more if you can write some optimized ASM. This can be the most frustrating, yet most gratifying exercise of getting the glcd to do your bidding.

Before trying to update large fonts, try to speed up the basic fonts to the maximum you practically can achieve.

Once you have this part working, you should consider writing-over LCD data. Erasing the screen / area and then writing will cause a flicker. Sometimes you may need to erase some section of the glcd. Try to keep that to a minimum.

yes , i am looking at those routines , i have found that by correctly setting the graphics area and home , then by reducing a few other not required gosubs for setting the gaphics text i have a very smooth display of the larger fonts , speed is still an issue , but at least the display is workable with the larger fonts., the small fonts are ok so far and i have rewritten the the Font Select routines so as to use the 6x8 fonts correctly and on the fly , the lib does not do this well

further improvement is need for speed , i am having trouble making the display work on 64mhz, works ok at 32mhz using the library , i have added some pauses in the send routines that set the wr,rd , data bus, but to date its not helped , can you take a look at the library

i do get some artifacts ( dots going on ) on the screen where the screen is not refreshed for an update over time , any reason why this occurs ?


cheers

Sheldon

A quick cursory look at your code reveals you have made a few hacks. However, they have some loose ends

These are just a couple I could find within the few minutes I looked at your code


Busy check does not really work. Bits sta0 and sta1 are not defined anywhere. Since they would read 1, busy_chk seems to work, but isn't really doing what it is intended to do
if (glcd_sta0 <> 1) AND (glcd_sta1 <> 1) then busy_chk

txt_home already does a send2. In putchar you do it again after gosub txt_home

Since busy_chk is not working, you might be getting the artifacts on screen

yep i pick that up in the busy routine , commenting out that part is ok at 32mhz , but i did defined variables on data pins for bit , 0 and 1 to try it , setting a check counter on the when the busy is retried , it rarely used is at 32mhz , but at 64mhz its always retrying the busy check , clearly its unable to access this Lcd at 64mhz and the busy routine is always retryed , but increasing then send routines pause's does not help, thats got me stumped


i have found setting the pause to 2us in the send/ busy routines , helped with the artifacts , with the cpu running at 32mhz, any less seem to introduce artifact to the large fonts at some point

this lib is a not bad a s base , but i finding more to rewrite in it as i go further forward, so far i have rewriten section on the FS use , initiation , puting a byte in the graphics area, adding area info to graph home , and then using it , which has helped , but , getting a speed increase so that the 1/100 sec timer number are blur is not happening with the large fonts , it intern it slow the smaller normal fonts down on refreash . i think if i can get the thing to run at 64mhz and not introduce more delays in doing so may be the anwer , in the end need the system to run at 64mhz for other processes



I am using a for , next loops for x, y data that brings in a lookup table of the 90 odd bytes per char , each byte then is placed on the screen x first ,

the fonts" file is then included as a seperate file at a compile time , could not think of any better way to go about this , this file also included 240x 64 banners etc

am sure that its slowing things down as it has to go lookup the 90 bytes then put them on the screen then change it all for each chr , but i dont know any better way to do it , i am wish i could put in faster !!!


cheers

sheldon



yes as i loom further at the lib there is unused code in there , but for the most part it works

resolved to start with , display looking ok using the lib , with a lot of mods , speed sorted due to running at 64mhz now and changes to how the graphics mode is selected and used , but a indexed vram code is really needed to load a large font char to gain any speed for display

if some code in pbp that can do this i would lov to see an example, and will send a coin to u if you have a working example that can use the lib

I willl post code conversion routines to use the font generator code to the lib at a later date after the project is sorted a bit further but i would recommend that if you are playing with a t6963c GLCD that the lib linked is a good starting point even if its close to 8 years old , but in the end you will need to rewrite it to suit your requirements

cheers

Sheldon

has anyone got an example of using the t6963C controller that setups the the blinking cursor , and reverse background in the txt area in pbp for doing menus and thier selection

an example for how to index the VRam for loading the large fonts in the graphics area would also be great to see

pm me if you like

cheers

Sheldon

vid ( remove the "txt" extension from the file name) shows testing of large fonts on T6963C controller, 240x64, digits fonts were created in font creator and ported to PBP, cpu running at 64mhz , the digits use 90 bytes each , and this is all its doing for this test , so it need to be a lot faster for the project in the end.

this would work a lot better if the bytes can be loaded as a one group from the vram , instead of loading the address pointer then the byte , but i need some help to do that