LCD BARgraphs

[Christopher4187]

Wow, is that thing slowwwwwwww. 600uS. for just about any of the control instructions? I really think you need to check your command and data delay settings. If I was using it I would also operate it in 8 bit mode. Twice as fast..... I also suggest reading the busy flag because if you are not then you are probably sending it instructions while it is executing the last instruction.

If the command and data delay settings are wrong or the device is too slow, why does it work perfectly with displaying letters and numbers? In addition, I could put a for/next loop from 0 to 33 and the bargraph routine runs perfectly hours on end. More testing reveals this:

Range.... Number where the bargraph is not displayed correctly
64 .... 4
128 .... 8
256 .... 16
512 .... 34
1024 .... 66
2048 .... 132

This means something, just not sure what. The one common thing I can see is that when one box (three vertical "l"'s) fills up, the next time the bargraph routine attempts to write to the next box, it will fail. If I adjust the column from 0 to 1, it will now allow me to successfully write four boxes instead of one.

[mackrackit]

why does it work perfectly with displaying letters and numbers?

Maybe that is all it is good for?

[Darrel Taylor]

A vast majority of people that call tech support with LCD problems, are using Newhaven displays.
It doesn't seem to matter what type (LCD, OLED, COG).

But i agree with Dave, the timing requirements are ridiculous.
It's even 600 uS for data transfers (per nibble) according to the datasheet.

Try changing to this ...

LCD_DATAUS CON 600 ' Data delay time in us (was 50)

[Christopher4187]

Maybe that is all it is good for?

C'mon, man! We don't give up that easily!

It's not a timing issue because it runs fine at 25uS or 1000uS. I've found a conflict with the "LCDbar_INC" program and the OLED screen. When the LCDbar program attempts to write to even columns, it displays wacky stuff. When it writes to odd columns, it works like a champ! I'll explain more in detail when I get home from work.

I got it working.....sort of....

[mackrackit]

C'mon, man! We don't give up that easily!

Life is too short to play with junk. Yes, I would give up and get a unit that works.

[Christopher4187]

I'm not smart enough to figure out why this is happening but the problem has been identified. Whenever the program sends "Threebars," it goes wacky. If I modify the code from this:

SELECT CASE BARtemp
            CASE IS > BARloop
                     LCDOUT ThreeBARS              ; send 3 bars    |||
            CASE IS < BARloop

to this:

SELECT CASE BARtemp
            CASE IS > BARloop
                
            CASE IS < BARloop

it will run fine. Of course only two bars will be displayed but something with the code is causing a problem in the display.

I made a bargraph routine and it works just fine so the problem is a conflict between the lcdbar inlcude file and the OLED screen. There isn't enough experience in my brain to figure out why so maybe someone else can. It was a good experience for me because I never used bargraphs before and I learned a lot from DT's program. The only thing I don't like about the program below is that it keeps writing over the previous graph, even if the data doesn't change, so if the bargraph stays at 100% or a high amount, you can see the bargraph flicker a little bit. I'm guessing that a routine is needed whereby nothing is written unless the number changes.

C0     VAR     BYTE
 C1     VAR     BYTE
 C2     VAR     BYTE
 C3     VAR     BYTE
 C4     VAR     BYTE
 C5     VAR     BYTE
 C6     VAR     BYTE
 C7     VAR     BYTE

C0  = $40
C1  = $48
C2  = $50
C3  = $58
C4  = $60
C5  = $68
C6  = $70
C7  = $78

lcdout 254,C0,REP 16\8
lcdout 254,C1,REP 24\8  
lcdout 254,C2,REP 28\8
lcdout 254,C3,REP 30\8
lcdout 254,C4,REP 31\8
BOX     VAR     WORD
LINE    VAR     WORD

FRICT_PAD_TQ_BAR    VAR    WORD
LINE_DISPLAY        VAR     BYTE
BOX_DISPLAY         VAR     BYTE
FRICT_PAD_TQ        VAR    WORD


MAIN: 
 
FRICT_PAD_TQ_BAR=(FRICT_PAD_TQ-12)/5
BOX_DISPLAY=127
LINE_DISPLAY=0
FOR LINE = 0 TO FRICT_PAD_TQ_BAR
    LCDOUT $FE, BOX_DISPLAY,LINE_DISPLAY
    LINE_DISPLAY=LINE_DISPLAY+1
        IF LINE_DISPLAY=5 THEN
            BOX_DISPLAY=BOX_DISPLAY+1
            LINE_DISPLAY=0
        ENDIF
    LCDOUT $FE,212, DEC FRICT_PAD_TQ_BAR
NEXT LINE
BOX_DISPLAY=0
LINE_DISPLAY=0
GOTO MAIN

[Dave]

Chris, Have you written code to look at the BUSY bit? I think you would be a bit supprised to find out just how long it takes some SPOOLED commands to execute. I have had this problem before with some NewHaven displays and with there lack of documentation you just have to figure out things on your own. What I would do is, write a routine to first set an output bit and connect a scope, then look at the busy bit after you send a command string to the display. re-check the busy bit to be clear, reset the output bit when the bit is clear and you would be supprised. Why do you think they make it available? You as the programmer are supposed to knowlegable enough to use the BUSY bit. Otherwise, don't complain about someone elses routines not working unless you know what the problem is....... Happy Thanksgiving......

[Christopher4187]

Otherwise, don't complain about someone elses routines not working unless you know what the problem is

It wasn't a complaint, Yoda. I said there was a conflict between DT's program and the OLED screen. That's a factual statement. In fact, I'm very appreciate of the information Darrel posts on here. Exhibit A:

Darrel, this program is awesome by the way!

I learned a lot from DT's program.

I've been using the OLED screens for over a year now. I know people have had problems with the displays but I really like them and never had a problem. If you know of a better OLED screen, by all means a better suggestion is always welcomed. Do you think people on here use Newhaven LCD/OLED screens? I'd be inclined to say yes. Given that fact, someone along the way is going to run into this same problem.

If there's a simple solution or a new line of code can be inserted to make it work correctly, why not do it? The main intent of the post was to elicit substantive discussion regarding the Newhaven OLED screen and DT's program. It doesn't work "off the shelf," which is perfectly fine. However, if Darrel or anyone else can provide a solution to make the program work, that would be great, but everyone on here understands there are no obligations. I don't have enough programming knowledge to contribute a lot here, so maybe this is a chance for me to do so if nobody else has the time to do it.

Personally, a lot of time has been spent on this and I'm really learning a lot. Even if I don't find a solution, it's time well spent.