Glcd Busy Flag

[kjaw1991]

Hi,

does the built-in glcd library read the display to check the 'Busy flag' when writing to the display or is this something the user has to do?

[biljana.nedeljkovic]

Hello,

You can take a look at the example code for GLCD in the compiler at this path:
"C:\..\mikroC PRO for dsPIC\Examples\Development Systems\EASYPIC v7 for dsPIC30\GLCD"
"C:\..\mikroC PRO for dsPIC\Examples\Development Systems\EasyPIC Fusion v7\PIC24EP512GU810\GLCD"

There is no need to check for the Busy flag.

Many more projects that use GLCD are available here:
http://libstock.mikroe.com/project_categories/

Have you had some problems with GLCD library?

Best regards,
Biljana

[kjaw1991]

Hi biljana

So to elaborate on the issue;
Currently we are running the dsPIC30F6014A, at 80MHz (10Mhz PLL x8)
Originally for the past 4-5 years we have used a displaytech glcd (64128Q) this has now became discontinued, although displaytech will still supply it but MOQ's to high.

So we have found what should be a direct replacement from a new supplier, TRI-T TMBG12864E

However we seem to get random lines/dots coming up on the screen where they shouldn't be, I have tried many different ideas to get around it, but no complete solution.

When i spoke to our supplier they suggested it maybe a timing issue? I tried running the program at 40MHz which did seem to cure the problem however the knock on effects for this mean we can not use this as a solution.

He also mentioned about checking the 'busy flag' something which i was not familiar with.(New to programming, Our software guy recently retired)

I am currently fighting to try and get more documentation from them, however i must add, I am not 100% that it is not an issue with the displays themselves, some seem to work better than others and there is no consistency in provoking the errors.

Any thoughts gladly welcome.

Thanks

[biljana.nedeljkovic]

Hello,

Can you send me the link to see the exact displays and your supplier?
Is it possible the problem is in hardware?

Does this new GLCD uses the same display controller as the previous one?

You can also check out Visual GLCD:
http://www.mikroe.com/visualglcd/specification/

Best regards,
Biljana

[kjaw1991]

I dont think it is a hardware problem (but cannot rule it out for sure).
I currently have a meeting set up end of the week with one of the tech guys from the supplier.

Old display: http://www.displaytech-us.com/128x64-gr ... displays-q
New display: http://www.diamondhmi.co.uk/sites/defau ... 12864E.pdf

It is not the same controller but both are shown in the list of Supported controllers on Visual GLCD

Thanks

[biljana.nedeljkovic]

Hello,

Unfortunately, I do not have that display controller to try it.

This controller, S6B0108, is supported in our software.

You can attach a small project, and contact me again once you have that meeting with the supplier.

Best regards,
Biljana

[oliverb]

So does the library perform busy checks or does it just rely on timing. The impression I get from tracing in is that it uses a relatively long write cycle, possibly as long as 20us, and doesn't check busy.

An alternative example from Sourceforge used a 10us cycle and failed to initialize a Midas display. I thought the answer might be to add busy checks but perhaps it just needed more time immediately after reset?

Another example I found didn't seem to bother checking either so running on timing alone must work sometimes. The datasheet I've read was vague on timing, but apparently a 1/64 duty display might use a 250kHz clock, and the longest busy period is 3/Fc. That would suggest that the longest delay ever would be 12us, so operation with a fixed 20us delay should work?