I have been complaining in the past about the T6963C library or the timing in general. Never had anything
definite to offer or that would support my complaint. So I guess they went into the round file.
I am currently working on an application that uses a T6963C based LCD 240x128 Monochrome. In the past I
did not dismiss the possibility that the LCD would have some problems since it intermittently would draw
stuff that I did not intent to have.
The display is very intensely used and is updated constantly.With the release of dSPic C Pro Version 2.0 I attacked the issue again and
continued on the code for the application. To my surprise, the LCD drew clean without any artifacts.
Since I did at first not believe that this did happen, I had the application running over night plus a few more hours. A check
did not show any mishaps with the Version 2.0 release. By the way the Example Einstein did always work, because the
entire screens gets cleared between changes and contents don't get updated, rather the pages are switched!
By installing the Beta Version 3.0 I had the old extremely agonizing screwed up screen again. NOT an idea why!!!!
To insure that the compiler was actually causing the problem, I went back to the 2.0 Version. Viola, again no more screen problems.
I would like to point out that there is absolutely no difference in code that was compiled with the V3.0 and V2.0.
Can't tell what causes it, but there is something within the compiler messing around with timings for the LCD.
Perhaps it is tight and may work with generous T6963C chips or equivalents, perhaps not,
why would it work in Version 2.00 flawless??
Thought I post my finding!
Cheers,
Norbert
P.S. I would have expected the annoying "Hex exceeding"
message to be a thing of the past, even in a Beta!While drafting the above the application is drawing beautifully the way it was anticipated. With the Version 3.0 it took less than a minute
to draw all over the screen!!!!!!!!!
