Anyone Compared methods of driving Alphanumeric displays?

[Stephen Moss]

Recently there was a post regarding a parallel display from a single pin. I know from looking at the asm that even using the compilers Print command generates a lot of code, logically one would think that driving say a 2 line x 16 alphanumeric display that has the standard Hitachi chip on it in parallel would be both faster and more code efficient than serial but has anyone actually compared the methods using say a simple...
Hello
World
output? If so it would be interesting to see a table of results for that, i.e.

Code Select Expand

Method:                                                           Lines of Assembler:     Memory Size:    Execution Time:
8 Bit Parallel
4 Bit Parallel
1 Bit (bit-bashed to external SIPO to 4/8 bit parallel)
1 Bit (MSSP Module to external SIPO to 4/8 bit parallel)
1 bit (bit-bashed) to Serial input Display
1 bit (MSSP) to Serial input Display
While the lure of the low pin count a 1 bit serial data stream can seems attractive how practical is it really?
Such a comparison table may help users to better determine the best method for a particular project/device. For example, as efficient as I am sure Les' recently posted sample code for using a SIPO shift register to convert serial LDC data to 4 bit parallel LCD data is, when considering the potential code size/execution time overhead and that the extra cost and board space of the SIPO is probably about the same as that of using a PIC with a slightly bigger pin count (allowing the use of possibly faster parallel data transfer) I can't help but feel that it could be lot of effort for little reward.
A comparison table such as that of the example above would reveal it that were the case or not.

[dr-zin]

If you have the pins, use them.  With a 28 or 40 pin PIC, you may have many to burn, so wiring up a parallel interface for an LCD display may be overhead well spent.  The allure of 1-pin communications is really for the 8 pin chips, or even for an 18 pin PIC like the 16F628, where you may not want to burn nearly an entire port just to send communication to the outside world.  Providing that capability to the low end products at the expense of one external TTL chip gives them more leverage and helps to even the playing field, especially for beginners or those not wanting to build enormous projects with expensive chips with features they don't otherwise need.

Concerning the aspect of your question involving speed and processor resources, I don't have the data to make an assertion other than to say that when it comes to LCD readouts, you only have to keep up with the human eye persistence of vision (POV).  If you can get your info. to the screen at a refresh rate of around 25 mS, you can have smooth animation.  If you are just sending data updates once a second or so, it doesn't really matter.

For the small chips, there may be a noticeable slowdown sending out the serial stream at 4 MHz, so maybe they have to run at 20 MHz (if they can).  Like most designs, this may have to be handled on a case-by-case basis, with features left out due to speed, or a rethink on the need to step up to a faster or more powerful chip (maybe even a GAL or CPLD for parallel processing).

That said, your idea of populating a chart of memory vs. speed is not a bad exercise, and I encourage anyone with the set-up to run the numbers and provide more knowledge to the crowd.  That's my 2 cents/pence...

[dr-zin]

BTW, based on your topic header, I originally thought your question was going to be about LED alphanumeric display modules, similar to the 7 segment displays, only with additional (14 or 16) lighted segments used to form more realistic upper and lower case Arabic letters.  That is also an area where shift registers and other port expanding multiplexers come in handy.  That could be a topic in its own right.