LCD speed

[echase]

In http://www.matrixmultimedia.com/mmforum ... =25&t=6396 and other posts I struggled to get an 16x2 text LCD to work whilst also having significant interrupts going on. Now upgraded from 16F690 ay 20MHz to a super fast 18F14K22 at 64MHz. My code structure is basically:

TMRO interrupt every 100us
Read one A/D input
Do some maths on the result
End interrupt, back to main loop.

This interrupt takes about 20us, mostly in A/D time, leaving 80us between interrupts

In main loop periodically the LCD is written to. The commands like clear LCD can take tens or hundreds of ms. So within that tens or hundreds of ms the interrupt will kick in hundreds of times. I was finding that this would often corrupt the LCD resulting in random characters.

There is another less good way for me to do this which is to pause the interrupts for 20ms and do the LCD writes but even that is not enough time for some LCD operations.

In Flowcode 5 are there any tweaks I can do to speed up the LCD e.g. by C Code and did you implement the 8 bit write that you mentioned in above post? Or can you think of an alternative way to do this LCD write? I thought of using a 24F device to shorten the 20us of the interrupt routine even further but am not convinced it really solves the problem as still get interrupts every 100us.

[Benj]

Hello,

A simple fix might be to call the LCD start macro in your program loop instead of the LCD clear command. The start macro will take slightly longer to execute but should allow the display to re-sync and ensure there is no lasting corruption.

Otherwise you could maybe disable interrupts just while the LCD data enable signal is active. I think this is only ever high for a couple of microseconds at a time.

[echase]

1) Having successfully reduced the A/D time it now gives me nearly 90us between samples to write to the LCD. Based on my limited understanding of C Code the basic LCD write command in the C listing is:

FCD_LCDDisplay0_RawSend(MX_UINT8 in, MX_UINT8 mask)

This has about 25 lines and five10us delays (if Boost C compiler) in it so takes say 60us, so is squeezable in that gap and I could probably experiment with reducing the 10us a bit.

Note quite sure though what happens if the word I am writing has say 4 characters. Does that take 4 times 60us? If so might be doable as I tried it and does seem to successfully write a many character word, so seemingly is not upset by the interrupts every 100us that triggers the next A/D sample.

2) There are some LCD statements that have much longer than 100us delays like

FCD_LCDDisplay0_Clear()
{

FCD_LCDDisplay0_RawSend(0x01, 0);
Wdt_Delay_Ms(2);
FCD_LCDDisplay0_RawSend(0x02, 0);
Wdt_Delay_Ms(2);

Could I do this as C Code instead? Like:

FCD_LCDDisplay0_RawSend(0x01, 0);
Do other stuff and make sure no other write to LCD command is done for >2ms
FCD_LCDDisplay0_RawSend(0x02, 0);
Do other stuff and make sure no other write to LCD command is done for >2ms

I do not need to return the LCD lines to tristate or inputs as never used for other things.

5) I read somewhere that cursor commands can only advance one space at a time so moving to bottom right of a 2x16 display can take 32 times as long as to top left. Is that true because looking at your code it seems it might jump straight to the position and so not take this long? Also if the new cursor position is just one space ahead of the last number write position does it take a short time even if down in bottom right corner?

4) There is a statement I don’t understand:

#if MX_CLK_SPEED >= 32000000
#define LCD_47__PORT0 latc
.
.
#else
#define LCD_47__PORT0 portc

As I am at 64Mhz does this affect any of the timings etc. above?

[Benj]

Hello,

In reply to your questions.

1) Yes each character is around 60us and has its own delay while the enable line is being toggled.

2) Yes I don't see why the clear command cannot be broken down and called using C icons. Don't see any problems with doing this.

3) As far as I am aware the cursor command jumps directly to the position you require. It is the shift display macro that has to be done a character at a time.

eg a 2 x 16 display has something like a 2 x 40 byte buffer meaning you can store a lot more then 2 x 16 and shift the display left and right to see the rest.

4) This is basically a read / modify / write bug workaround. Basically the port register is being updated so fast that the next read comes in wrong causing the modify and write to be wrong leading to output level corruption on the port. The LAT register is updated immediately on a write and is always available on PIC devices capable of operating above 32MHz.

For example this code running at over 32MHz would become corrupted, bit 0 should be set but it will end up as 0 due to the port register taking time to recognise the level change.

set_bit(portb, 0);
set_bit(portb, 1)

This alternate code does not have the issue.

set_bit(latb, 0);
set_bit(latb, 1)

[echase]

1) Yes each character is around 60us and has its own delay while the enable line is being toggled.

4) This is basically a read / modify / write bug workaround. Basically the port register is being updated so fast that the next read comes in wrong causing the modify and write to be wrong leading to output level corruption on the port. The LAT register is updated immediately on a write and is always available on PIC devices capable of operating above 32MHz.

For example this code running at over 32MHz would become corrupted, bit 0 should be set but it will end up as 0 due to the port register taking time to recognise the level change.

set_bit(portb, 0);
set_bit(portb, 1)

This alternate code does not have the issue.

set_bit(latb, 0);
set_bit(latb, 1)

Thanks, so to be clear the FCD_LCDDisplay0_RawSend(MX_UINT8 in, MX_UINT8 mask), taking 60us, only writes one character so has to be repeated 4 times if the number is 4 characters long? Looking again I see it is six 10us delays in 2 groups so it seems to be writing the upper and lower words twice. Why twice?

The workaround, as long as it’s still called, can be ignored if I shift code from Flowcode to C commands. I note that that workaround arose out of a problem I reported here http://www.matrixmultimedia.com/mmforum ... 5&start=25 Did it get officially put into a Flowcode release or is it on my computer because of the fix put in that post? It is very difficult to remember what one has manually altered versus official releases!