View previous topic :: View next topic |
Author |
Message |
ELCouz
Joined: 18 Jul 2007 Posts: 427 Location: Montreal,Quebec
|
LCD: Nibbles vs PMP |
Posted: Sun Mar 22, 2015 9:07 am |
|
|
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! |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Sun Mar 22, 2015 9:17 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
ELCouz
Joined: 18 Jul 2007 Posts: 427 Location: Montreal,Quebec
|
|
Posted: Sun Mar 22, 2015 9:26 am |
|
|
temtronic wrote: | 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 |
This pic have over 86 i/o pins so it's not really an issue even left some reserved pins for further improvement or devices added in maybe a revision of the board.
I've did a little bit of research ( even found out some PMP driver example for a LCD in the books I have about the PIC24) and wow it's easy!
From what I've read the LCD will update faster (still a slow device) and code complexity is greatly reduce.
I still don't know if the PMP really offload the pic24 of doing basic lcd driving tasks.
Thanks your opinion is appreciated ! ![Smile](images/smiles/icon_smile.gif) _________________ Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Sun Mar 22, 2015 10:25 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Sun Mar 22, 2015 1:54 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Sun Mar 22, 2015 2:50 pm |
|
|
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..... |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Wed Mar 25, 2015 8:51 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Wed Mar 25, 2015 9:10 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
|