LCD speed

[echase]

In the Flowcode macro C file there are a lot of delay lines such as delay_ms(2); which I assume is a 2msec delay. Why are these there as I thought it was possible to write new data to the LCD port pretty quickly, like in under 1us for a single character according to one LCD datasheet I looked at.

Is they a realistic chance of my cutting down these delays by modifying the fcd file as I want to be able to write a single text field like “voltage” or number like “32000” or perform a clear or cursor move in under 150us. If not possible I would like to aim for under 0.5ms but I’d then have to turn off/on my interrupt before/after the LCD action if it were 0.5ms.

Is the delay time taken up with switching the PIC port from an input to an output and back again? I don’t need to do this in my application as the port is solely used for the LCD.

[Benj]

Hello,

The delays we provide as standard in the LCD C component file allow most display types to run correctly. If you have a faster then average display then you can tweak the delays in the component C code by editing the C file (v3/v4) or by using the custom code feature (v4).

Is they a realistic chance of my cutting down these delays by modifying the fcd file as I want to be able to write a single text field like “voltage” or number like “32000” or perform a clear or cursor move in under 150us. If not possible I would like to aim for under 0.5ms but I’d then have to turn off/on my interrupt before/after the LCD action if it were 0.5ms.

Nothing is impossible but this seems unlikely, Could you disable your interrupts for longer then 0.5ms by buffering or taking an average or maybe displaying less often?

Is the delay time taken up with switching the PIC port from an input to an output and back again? I don’t need to do this in my application as the port is solely used for the LCD.

No the code generally leaves the pins in an output state unless told to do something else by say a Flowcode output icon. The delays are for interfacing the driver chip of the LCD.

[echase]

Nothing is impossible but this seems unlikely, Could you disable your interrupts for longer then 0.5ms by buffering or taking an average or maybe displaying less often?

I could turn off the interrupt if I could be sure it is off for a fixed time. So say I knew the LCD command took a certain time (and I suspect not as text and integers will take different times), I add to that the interrupt command off/on time and then add that combined time to my now shortened overall loop time derived from counting interrupts. So the total time comes back to the one second that I need.

Do you read the BUSY flag from the LCD? Looks to me like you do not. I suspect that you are waiting a reasonable delay time to be absolutely sure the LCD’s internal processor has finished processing before writing any new data. I believe an alternative strategy is to poll the BUSY flag and write when it clears.

If I was clever enough I could maybe write the whole LCD routine in C using the BUSY flag, using your fcd file as a basis.

[Benj]

Hello,

We don't use the busy flag but instead our delays should be fairly close to the throughput you would get should you be monitoring the busy flag. One thing you could do is to clear a count variable and then start a timer interrupt on a fairly fast frequency when you start to write to the LCD. During the LCD write when an interrupt occurs add 1 to the count variable. When you have finished writing to the LCD stop the timer interrupt and the count variable will contain roughly the amount of time you were inside the LCD routines.

[echase]

I could let the interrupt just go ahead, rather than squeeze the LCD actions in before the next interrupt, and so pause the LCD actions for 200us whilst the interrupt is happening, but I have found in the past that this corrupts the LCD much of the time but not always (get random characters) so I have to stop the interrupts during any LCD command. Any idea why? Possibly it's because you are using a divide by 10, 100,1000 function in your code and my interrupt uses divide too, although I think I have now made these /2, /4, /8 so maybe won't now clash. I'll check later for divide warnings when compiling.

By far the easiest solution would be if there was something easy to do to, e.g. to the fcf file, to stop this corruption. For instance is it because in double 4 bit mode if the interrupt starts in-between the two 4 bit writes then will the LCD not be able to properly respond? As LCDs only need less than 1us per data write I could afford to turn off the interrupt for that time, but not for the full 43us it takes for the LCD’s processor to act on that data and make itself ready for the next data input.

Is it possible that your LCD code works for short interrupts but, as mine is long (and not shortenable), it does not operate with your LCD code?

[echase]

I am no C expert but looks to me from the below truncated rawsend routine that you are using four 10 or 100us delays to write the two 4bit numbers. Bit puzzled about that as you can write them in only 0.5us. But maybe you are using the remaining time to ensure you pass 43us.

#ifdef _BOOSTC
#define LCD_328762_DELAY delay_10us(10)
#endif
#ifdef _C2C_
#define LCD_328762_DELAY delay_us(100)
#endif
#ifndef LCD_328762_DELAY
#define LCD_328762_DELAY delay_us(100)
#endif

void LCD_328762_RawSend(char nIn, char nMask)
{

clear_bit(outVal, LCD_328762_E);

LCD_328762_PORT = outVal;
LCD_328762_DELAY;
set_bit (LCD_328762_PORT, LCD_328762_E);
LCD_328762_DELAY;
clear_bit (LCD_328762_PORT, LCD_328762_E);

LCD_328762_PORT = outVal;
LCD_328762_DELAY;
set_bit (LCD_328762_PORT, LCD_328762_E);
LCD_328762_DELAY;
clear_bit (LCD_328762_PORT, LCD_328762_E);
LCD_328762_DELAY;

[Benj]

Hello,

As I said before our code is designed to be fairly bulletproof on all types of these alphanumeric displays. Why not use the custom code feature of V4 to experiment with the delay values and see what works and what doesn't on your specific hardware.

[echase]

Hello,

As I said before our code is designed to be fairly bulletproof on all types of these alphanumeric displays. Why not use the custom code feature of V4 to experiment with the delay values and see what works and what doesn't on your specific hardware.

Nice idea but your marketing leaflets are very brief and so I can’t see from them :-

a) what the custom code feature is or does
b) generally what benefits v4 gives me over V3; the Panel Designer is the only really obvious change.

Thus I have never been persuaded that it’s worth my buying v4.

Maybe there is a more detailed description of the upgrades but I can’t find it.

[Benj]

Hello,

I agree, the marketing material is not as good as it could be and hopefully we will get better in this area for future releases.

Main upsides of v4 over v3.

Multiple new / upgraded components
Numerous Bug Fixes to Components / Simulation / Definition files
Numerous new target devices
Panel Designer
Vnet - Simulation between Flowcode instances
Component Customization - Ability to override component C file without editing component C file, can be exported / imported.

There is a reduced price upgrade route available from here if your interested.
http://www.matrixmultimedia.com/product ... PHPSESSID=