The 'problem' LCD's are Optrex DMC-20481NY-LY-ABE, as well as the older version of this part with the yellow backlighting (I don't have the older number on-hand). Just to be clear, the time spent writing to the LCD is not my main concern. What is my main concern is being able to run the CPU at 117.9...

Thanks for the offer xor, but my hardware is setup for an 8-bit interface. Four bit interface mode is slower than 8-bit mode, and my application (a production test fixture for an X-ray system) needs every bit of speed I can get. I have noticed that the four line displays need longer command and data...

Hello Zristic, Perhaps the reason it 'works there' is because your not using the same LCD module? Two line LCD's do not have the same refresh timing as four line LCD's have. Also the timing of LCD's from different vendors is not the same. (check the data sheet for the 44780 controller chip for detai...

I've been kept away from MikroBasic for a few months, and have just gotten back to working on my old project. Using V4.00 of the compiler I still find that the LCD 8-bit timing has major problems: I am using a 30F6011A with a 7.37 mhz XT crystal. If I compile the code for 117.92 mhz and program the ...

From now on, I'll wait for the day after a new release to report bugs!

SUBB has the same problem.

Is there a way to force the in-line assembler to include a hex value?

In other words, can I include the hex value of an instruction directly?

The following code stops the compiler on the ADDC line, but no error message is generated:

asm
MOV _operand_one, W2
MOV #@_operand_two, W1
MOV #@_result_word, W0

MOV _adder_status, SR
ADDC W2, [W1], [W0]

MOV SR, W0
MOV W0, _adder_status

end asm

.

GLCD Read?

But once again this problem effect character LCD's, not GLCD's.

Also my code never reads from the LCD. The problem happens when writing to the LCD.

Zristic,

I'm confused by your reply.

The Lcd8_Out problem effects character LCD's, not GLCD's.

Lcd8_Out does not control GLCD's with the /CS1 and /CS2 signals.

Disabling IRQ's inside the LCD functions would be a problem, if we disabled them at the start of the function and only re-enabled them as we exit the routine. What I'm asking about is slightly different. What if we disabled the IRQ's only during the handshaking routine that transfers a byte of data ...

Update:

This GLCD corruption only happens with IRQ's enabled while running the dsPIC at 117.92 mhz. If I reprogram the dsPIC to run at 58.96 mhz (PLLx8) the GLCD display is correct.

Note that the compiler clock setting it still set to 117.92 mhz.

Yes, I have experimented with setting the compiler clock frequency setting and the programmer's configuration settings seperately. I can compile my code for one speed, then program the dsPIC to run at a higher or lower speed. What I have observed is that even if I set the compiler for 58.96 mhz (XT,...

I have found that the GLCD display will be corrupted if mikroBasic services interupts while writing to the LCD. I took the GLCD sample program, and added the following IRQ handler: sub procedure timer1int org $1a count_var = count_var + 1 grn_led = count_var.0 IFS0 = IFS0 and $fff7 end sub In my mai...

Actually I did modify my hardware. In theory I may not have had to do this, but I wanted to follow the reccomendations from Optrex exactly. Optrex shows the unused data lines floating. I did not want to take a chance that the LCD functions might alter the TRIS register settings for the remaining fou...

Yes, thanks, I did receive the source code.

Right now I've replaced the Optrex display with a GLCD, so I can proceed with my project.

but I will re-install the Optrex display later this week and spend some time with the oscilloscope and try to find the timing issue.