LCD: Nibbles vs PMP

[ELCouz]

Hi,

Just wondering what are the pro's and con's of using nibbles vs PMP for driving a character LCD.

My PIC24 (PIC24FJ128GA010) have a Parallel Master Port module.

What would you use if you had the choice of both?

If I chose by popularity nibbles are very common way to drive them but seems to be a magnitude slower.

Less processing done by the uC?
_________________
Regards,
Laurent

-----------
Here's my first visual theme for the CCS C Compiler. Enjoy!

[temtronic]

8 bit mode is faster, though really it's just an LCD which is a 'slow' device but there's less code 'overhead' for the PIC so one could argue the PIC could do 'more stuff' but I bet that PIC is running at 40-60-80 MHz, so really it's not an issue.Serioulsy doubt code space is an issue either.
There's points about 4 bit using less pins, so that might be a deciding factor. Sure be upset if you needed some peripheral on a pin that's now connected to an 8 bit LCD config. Not that I've ever done that.....
Man, I can 'sit on the fence' on this..see both sides, though 8 bit just seems 'right' to me !!

Guess that show's I'm Canadian, eh !!

Jay

[ELCouz]

[Ttelmah]

There is a great simplicity to using 8bit, but speed is not really much of a gain, on anything above perhaps a 10MHz processor, you end up having to add delays to simple things like the enable pin operation....
You can update an LCD, perhaps 10000* faster than it can display it anyway!. Most have a 'refresh' time in the order of 0.25 seconds.
A lot depends on whose LCD you use. Genuine 'named brand' LCD's, usually have good specifications of the timings needed/allowed, enabling fast operation using an interface like the PMP. However be prepared to have 'trouble' getting it to operate correctly with 'lesser brand' units. Also, 'beware' if the leads are more than a very few cm long. I had problems using PMP, with a display that was only 6" from the board, while the nibble based code merrily worked. Had to use twisted pair cable, and terminating networks at both ends to get reliable operation.
The nice things about the 'off the shelf' 4bit code, is that it happily works with 99.9% of these displays.

[temtronic]

Yeesh, 86 pins !! Now if I was to use that PIC, three days after the PCBs came in, I'd have to 'revise' the layout as the ONE pin I now need is tied to the LCD.
I've been thinking about this while freezing my fanny outside and I would use 8 bit mode. Seems to be a 'cleaner' approach,software is simpler,faster. I/O connector could be a 16 pin IDC.

Jay

[Ttelmah]

I use 8bit mode, _but have had problems with PMP_.

Problem is that the clock edges are just so fast, and most LCD's have quite surprising track layouts and lengths on their boards. Start using PMP, and it expects nice clean logic signals.....

[asmboy]

i have had good luck with reducing ringing/glitching on longer data lines by adding a 100 to 200 ohm resistor in series with each data line and including a delay_cycles(x) call between state changes ,
where increasing of 'x' is a function of processor speed.

the resistor indirectly uses the same capacitance on the line that causes ringing and under/over shoot and damps it by the short time constant thus formed.

[Ttelmah]

Agreed totally.

Point is that the original poster was talking about using PMP. With PMP, you don't have the flexibility to delay very much. Normally just a few cycle times (3.25Tcy max on the chips I've used). When you are talking Tcy times like 60nSec, this gave problems on LCD's. Especially with read operations.

I found it miles easier, to just do an '8bit' version of the Flex driver (you just program the display to 8bit mode, and substitute a lcd_send_byte write operation, which outputs the data as a single byte (doesn't use the nibble routines). Use the R/W version so you can wait for the display, rather than for 'assumed worst case' times, and it works well, and is fast.