2-Line Serial Backpack

elec_mech

New Member
Hi All,

I've been working with another member to develop a cheap serial backpack for LCDs. We came across a recent article in Nuts & Volts that uses two lines to communicate to an LCD through a 74HC595. The code was written in GreatCow Basic for a PIC and after much trial and error, I successfully (I think) converted it over to PICAXE BASIC with some help from Westaust55's 3-digit display code using the '595. My code works, but not reliably. Code and schematic attached.

Sometimes the LCD works perfectly off the bat. Other times, I have to cycle power repeatedly before the LCD will work properly. I've tweaked the initialize (INIT) routine which seems to help, but does not eliminate the problem.

I've also noticed, sometimes the LCD will start up in one-line mode and display gibberish until it gets down to the block cursor example in the code - it then displays the first line only.

Another issue I noticed this weekend was the program appeared to reset randomly after running for several minutes. Sometimes this was okay, other times the LCD appears to go into one-line mode (not in code) and stay that way.

Unfortunately, the problem is not consistent so it's been hard to troubleshoot. I'm wondering if the problem is strictly with the INIT routine, possibly the sendNib routine, or if it is with the circuit layout, perhaps something to do with having the shift and storage register pins tied together? I read something about delaying signals between two pins using a capacitor and resistor. Don't know if that is required here though.

I've tried adding pull-down resistors on the data line to the '595 as well as the DB7-4 lines with no real difference. Also tried using different '595s. The TI I had seemed to have more problems than ST ICs. I was using an NXP IC this weekend.

I was just wondering if anyone else had experience interfacing '595s with LCDs, specifically using two lines? Would three lines be better? Would using two '595s to send 8-bit data to the LCD be a better choice?

Thanks in advance.
 

Attachments

hippy

Technical Support
Staff member
Two-signal shift register controlled LCD interfaces can be a pain, especially with regards to pulsing the E signal, having data and RS signals stable for enough time before E is pulsed, resetting the shift register, and preventing inadvertent activations. It can come down to hardware and even timing within the software all of which can cause intermittent failures.

In addition there can be issues with not sending the correct initialisation sequences for the LCD or not complying with the correct timing.

The problems you have all seem typical of the above and can be difficult to identify and resolve, especially as it requires understanding the principles of the circuit and how that is controlled, as well as understanding the software doing the control. You will probably need some logic analyser tracing to see exactly what is being written to the shift register and LCD in order to find out what isn't right.

Because of these potential problems and software control overheads I have mostly stayed away from shift register LCD controlled and would choose to go with a simpler serial-to-LCD interface using a PICAXE ( such as the AXE133 range ) or use direct parallel control.
 

elec_mech

New Member
Thank you hippy. I was afraid of that. At least it's good to know I wasn't going crazy. Dedicated uC it is!
 

AllyCat

Senior Member
Hi,

Hmm, looking at the circuit diagram, that's not the way I would have done it. ;)

I particularly dislike the capacitor coupling to the LCD and the shared clock from the micro. Personally, I would have wired two S-R outputs directly to the E and RS pins and put the "tricky" circuitry on the uC to S-R interface. That way you can measure if the SR is actually doing what you want. Also, I'm not convinced that the Reset will always work: Probably if Q7 happens to go high at power-up, but what if Q7 stays low but some of the other outputs go high?

However, I have had some success with a two-wire S-R interface (not a 595) using a common Data/Clock signal and separate "Enable" or "Load/Transfer" pulse. The Data input is ac-coupled such that a short clock pulse (active trailing edge) loads one logic state into the shift register but after a "long" clock pulse the ac-coupled level has decayed to the opposite logic level. Bit-banging the clock width-modulation is rather slow with a PICaxe, but another trick is to use the (hardware) serial output with just a few selected characters that create the long and short pulse sequences (taking into account the start and stop bits, of course).

Cheers, Alan.
 
Last edited:

westaust55

Moderator
I posted my own version of a 2 (or 3) wire shift register based LCD interface back in 2009 here:
http://www.picaxeforum.co.uk/showthread.php?13900-2-(or-3)-wire-LCD-module-interface
This gave me an 8-bit parallel interface with the control signals plus ability to control a backlight.

I had no problems with the display I used but as hippy indicates there could be problems if you have a display where the timing must be exactly as per the LCD controller chip Datasheet.
 

hippy

Technical Support
Staff member
I am not convinced by two-signal shift register designs. It can be argued they should not work and it is just good fortune when one does.

When shifting a byte into the register, D7-D4 and RS outputs may only become stable at the same time as E is set and that would violate any timing for having D7-D4 or RS stable before E is set. It is even possible that some of D7-D4 or RS may not yet have become set when E is set.

That it sometimes works probably come down to the shift register used, the LCD itself, and even stray capacitance on the signal lines. These things allow the design to work through luck of the implementation rather than through good design.

The same can be seen in parallel connected LCD designs where software may set D7-D4, RS and E in a single set outputs command. For some people this works fine but for others it does not. Designs which set D7-D4 and RS, then set E, then clear E, then change D7-D4 and RS are far more robust.

A three-signal shift-register design, with E as separately controlled signal, should similarly be more robust because D7-D4 and RS will be stable before and after E is pulsed.
 

inglewoodpete

Senior Member
To me, the number of hours spent tweaking the HC595 circuit is many times the cost of a PICAXE-based 1-wire serial solution. Rev-Ed even supply the software for a simple backpack solution. I developed a high speed serial version using a 20X2 described here.

Getting back to the HC595 version, slowing the data transmission rate or playing with the enable capacitor size may help. Easier to do with an oscilloscope of course.
 

hippy

Technical Support
Staff member
In the control program 'init' routine there is only one Function Set command sent to initialise the display in 4-bit mode. For HD44780 there should be four nibbles sent and with quite specific timing between them. Not doing that correctly could explain some not always working at power-on issues.

Some HD44780 datasheets suggest three nibbles but (1) an additional redundant nibble sent should have no adverse effect and (2) this often conflicts with other descriptions in the datasheet which show four as necessary.

It gets complicated because the nibbles being sent are being received as bytes until 4-bit mode is entered. For initialising 4-bit mode I always send $3, $3, $3, $2 as single nibbles or $33, $32 as bytes ( nibble pairs ). Though the latter sending as bytes violates the timing specs it always seems to work with HD44780 displays I have had.

Initialisation sequences can also have differing effects depending on whether power has been left on or turned off. It's not uncommon to have initialisation which seems to work, only to find it doesn't when it's turned off then on again. An additional problem is that LCD's draw such little current that they may keep working on residual capacitor voltage long after power is turned off so they aren't always in a true not powered state before power is turned on.
 

elec_mech

New Member
Thank you for the information.

Westaust55, thank you for the link to your post. I'll review it in greater detail later, but it certainly looks nice.

Hippy, the Nuts & Volts author did what you mentioned in his code: 3x $3, etc. I've been studying the HD44780 datasheet from Sparkfun in detail. On page 42, it calls out how to sent up the LCD in 4-bit mode. It shows sending one nibble then one byte to set the function set. I've done this and it seems to perform as well as sending multiple nibbles of $3 then a $2.

Now it is possible the eBay LCDs I got are using a HD44780-like controller which may have different timing characteristics which may be part of the problem. I also didn't know there were different HD44780 ICs with slightly different timing characteristics.

I can't say I entirely follow the operation of the circuit (I know, I know, bad). I have tried to study it, but I'm not sure how the reset function is working in conjunction with Q7 on the '595. Also, since the load and latch registers share the same pin, I wonder if this contributes to the stability of the data and R/S lines while E is enabled and disabled. If these must be stable before E is enabled, I can see this being a problem. I haven't studied the HD44780 datasheet enough to understand the timing of E relative to the other lines, but problems I'm seeing make sense if the data isn't stable before E is enabled. I'll look more into this.

I assume a stable three-line '595 circuit would have one of the uC lines tied directly to the E pin of the LCD?

I didn't try it this past weekend, but I did try physically removing power a few weeks ago for 30 seconds to a minute and still had the same issues.

I'm also thinking about attempting to use an I/O port expander like the MCP23017. Think I'd have the same issues?

Thank you all again for the great insight and advice.
 

AllyCat

Senior Member
Hi,

I doubt if we'd build anything much ourselves, if we costed our own time. But equally with I2C (two-wire) backpacks at little more than a Dollar, I wouldn't spend too much time "rolling my own" either.

Even with good test gear, it's still better to devise a "sound" design, so I would wire the LCD Enable back to the PICaxe, and then worry about the Shift Register. But perhaps the 595 is over-complex for this application: the transfer (S-R to output latch) is edge-triggered and it's not obvious from the datasheet if it's valid to drive the shift and transfer clocks from the same source (and if so, it still implies an extra clock cycle).

However, a transistor, capacitor and two resistors (i.e. less than shown in the current schematic) can make a perfectly respectable (and predictable) monostable timer (t = 0.7 * C * R), so the method I outlined above can reliably load the S-R using a single line/pin. Not tried, but it might even be possible to also directly control the RS line, leaving the S-R to just deliver the 4 (or now 8) Data bits.

Cheers, Alan.
 

elec_mech

New Member
Alan,

Sorry, didn't mean not to include you in my thanks - I will look into the SR latches and timing you mentioned. I'm thinking a dedicated uC is the best way to go since one can control the timing of each pin with greater precision.
 

AllyCat

Senior Member
Hi,

For clarification, I'm afraid that I've been a little "lazy" in my recent posts, using "S-R" for Shift-Register. However, a "SR Latch" (Set-Reset) is rather similar but not the same thing.

The 595 is really rather a complex device (a simple package containing 4, 6 or 8 D-Latches might actually be better in this case) but component choice has (naturally) become rather based on price and availability. It depends how much you have already sourced and/or built, but a reasonable solution can probably be found, if you have good reason to "re-invent the wheel". ;)

Cheers, Alan.
 

hippy

Technical Support
Staff member
I can't say I entirely follow the operation of the circuit (I know, I know, bad).
It is quite esoteric as it is using clever design to get the data to the latch, triggering the E, then clearing the latch so an inadvertent E isn't triggered until a new set of data is written.

I have tried to study it, but I'm not sure how the reset function is working in conjunction with Q7 on the '595.
Once the 1 for the E bit has been latched to Q6 and pulsed via the C to the LCD, the next shift of the register forces that 1 into Q7 which pulls MR low which clears the register but not the outputs, a second shift of the register with MR low then sets the outputs to register (zero), which lets MR go high and the next set of data can be shifted in.

When the E bit is on Q6 the bit in Q5 must be zero so that during the same shift Q6 won't again be set high and activate another E to the LCD.

Also, since the load and latch registers share the same pin, I wonder if this contributes to the stability of the data and R/S lines while E is enabled and disabled.
Hard to tell without reading the 595 datasheet, analysing and theorising.

I assume a stable three-line '595 circuit would have one of the uC lines tied directly to the E pin of the LCD?
That is correct.

I'm also thinking about attempting to use an I/O port expander like the MCP23017. Think I'd have the same issues?
You can, but if done right you can set data before setting E and clear E before changing the data and have the most robust sequence. The problem is then the code needed to create and send out the right sequences of commands.

Plus every byte sent has to be through a call that routine to send it as you don't have the convenience of SEROUT to more easily send whatever you want.

For convenience it starts to make sense to add a PICAXE bridge which can take serial and turn that into shift register or port expander control but as the PICAXE can interface directly why bother with anything more than that PICAXE ?

Of course a PICAXE is more expensive than a shift register so it can become a difficult decision; cost and complexity versus ease of use and what you save in costs may be spent in time and effort in making the cheap solution work.

That's not to say don't do it because you will be exploring all these issues for real. Well worth it if you want to explore and assess the merits of alternatives, but perhaps not so much if just looking for a solution to use.

( And a thumbs-up for the forum's Restore Auto-Save Content option when editing having clicked Cancel rather than Send having written all that ! )
 

AllyCat

Senior Member
Hi,

Yes, the operation is ingenious, but doesn't appear to remotely comply with the (or an) HD44780 data sheet (which I've just explored again, after many, many years). It seems that it is the trailing edge of E which latches in the Data, so the design uses a C-R network to create a falling edge well away from the Shift Register Data transitions, and thus comply with the data setup and hold times.

However, the data sheet specifies the E pulse to have a minimum width of ~500ns and maximum rise/fall times of ~25ns. The C-R network has a time constant of 470ns, so even the pulse width (typically 0.7tc) seems inadequate. But I can't see how the "sawtooth" (actually exponential) pulse from the C-R network could get even close to the specified falltime - and it's this "slow" edge which is the "active" edge for the chip. :(

Yes, the forum's auto-backup has also saved me wasted time on more than one occasion. :)

Cheers, Alan.
 

hippy

Technical Support
Staff member
It seems that it is the trailing edge of E which latches in the Data, so the design uses a C-R network to create a falling edge well away from the Shift Register Data transitions, and thus comply with the data setup and hold times.
That is also how I read it, but there are additional setup times for D7-D4 and RS before E goes high. The datasheet timing diagrams I have shows them but doesn't state values.

However, the data sheet specifies the E pulse to have a minimum width of ~500ns and maximum rise/fall times of ~25ns. The C-R network has a time constant of 470ns, so even the pulse width (typically 0.7tc) seems inadequate. But I can't see how the "sawtooth" (actually exponential) pulse from the C-R network could get even close to the specified falltime - and it's this "slow" edge which is the "active" edge for the chip. :(
Thanks for some numbers, and I would agree these are the types of problems which can cause some LCD's to fail and my notion that it can be luck that some do work outside their specifications which leads to some success.

How something like the RC differentiator behaves in practice may also differ from theory, can be affected by slew rate of the shift register outputs, actual supply voltage, input impedance of the LCD E pin, plus resistances and stray capacitance of connections, and actual supply voltage may also affect where an LCD's logic switching points are. A small difference in what are otherwise two identical circuits can make a huge difference in practice; one may work while another does not, with temperature and other changes what works at one time may not work at another. Component manufacturing tolerances will likely mean that no two identical circuits are truly identical.

Hardware and software can be adjusted to be on the better side of mostly working but as inglewoodpete alluded to; there can be considerable time spent on tweaking such things to get it right. It's natural for a developer with a specific setup to tweak what they have to the fastest they can make it work, and forget that may mean it doesn't then work as well for others.

This is probably a fine example of where SPICE and other simulations can be used to verify having a compliant system with worst case scenarios but I would imagine that is rarely done by the people who design these things.
 

AllyCat

Senior Member
Hi,

there are additional setup times for D7-D4 and RS before E goes high. The datasheet timing diagrams I have shows them but doesn't state values.
Yes, you're correct about RS (and R/W where relevant). It's called the "Address setup time" and is specified as 40ns (with a hold time of 10ns) to the leading edge of E. So it doesn't seem "safe" to take both (E and RS) signals from the same shift/latch clock pulse.

Actually, the setup time could be accommodated by making the "Q5" bit the same as "Q4" (RS). That means that the Q6 pulse (E) might be extended by another cycle (if RS = 1), but that may not matter because the capacitor coupling has already decayed to a "0" so E will just remain low.

Alternatively, the 595 could be used with separate shift and latch clocks, but that probably defeats the two-wire interface concept.

Cheers, Alan.
 

AllyCat

Senior Member
Hi,

Out of interest I decided to create a "hierachy" of possible methods to drive LCD/OLED displays, descending from (potentially) "Easy" to "Hard". The OP diagram in this thread is at the bottom; I did consider adding a few more items to push it down to "#13", but I think the conclusion is clear anyway ;)

1. A "dedicated" micro receiving ASCII characters over a single wire (driving the LCD via 8-bit data + controls) :D
1a As above, using a 4-bit bus to free up 4 pins of the dedicated micro (and to include additional functions)
2. Drive the LCD via a parallel 8-bit bus, plus 2 - 4 control pins (R/W and Backlight optional)
3. Drive the LCD via a parallel 4-bit bus, plus 2 - 4 control pins (R/W and Backlight optional)
4. Drive the LCD via an I2C-expander interface (4-bit data bus plus 4 control lines) ;)
5. Drive the LCD (data) via an 8 bit shift register (2 control lines), plus 2 - 4 control signals direct to LCD
6. Drive the LCD (data) via a 4 bit shift register (2 control lines), plus 2 - 4 control signals direct to LCD
7,.Drive a Shift Register via a "homebrew" interface, plus 2 - 4 control signals direct to LCD
8. Drive the LCD via a "homebrew" interface (plus a Shift Register for the Data bus)
9. Drive the LCD AND the Shift Register via a "homebrew" interface
10. Drive the LCD (and the Shift Regsiter) via a "homebrew" interface FROM the Shift Register
11. Drive the LCD via a "homebrew" Shift Register interface, using demonstrably invalid timing data. :(

I won't go into detail, but even the first few "steps" are quite large. From 1. to 2. the (monetary) cost reduces considerably, but the number of (PICaxe) pins rises from 1 to 10+ and a reasonable understanding of the "Hitachi" LCD chip interface is required. Then the jump from an 8-bit to 4-bit bus is far from trivial, in understanding, operation, and speed (or lack of).

However, 4. (as linked earlier in the thread) does have some appeal, not only because it's available off-the-shelf for around a Pound, includes simple connections and a LCD contrast control. Also, it needs only 2 pins (or none if I2C is already being used), has the ability to control the Backlight (I've even dimmed mine with "PWM") and R/W control (but I've yet to get my brain around reading data via the 4-bit bus AND the I2C expander).

So there may not be much point in delving deeper down the above list, but I do believe that I can offer a reliable "home brew" 2-wire method, using similar (but simpler and predictable) hardware to that in the OP diagram. I've not tried it with a 595 and a LCD, but have used an Octal Latch (wired Qn to Dn+1, etc.) to drive a 7-segment display from a single PICaxe pin.

My starting point is to dedicate a PICaxe pin to directly drive the E line, to ensure that all the timing reqirements of the LCD chip can be met. The second pin then directly drives the RS line, but with the Shift Register control "piggybacked" on the same line. The Shift Register Clock Pulse Input (or both for the 595) would be wired directly to the RS line and to the D (Data) input via a "monostable" timing circuit. The trick is to set the quiescent level of the RS line "High" so that the Shift Regsiter is loaded on the trailing (rising) edge of the clock pulse.

The monostable can be as simple as the C-R network shown in the OP diagram, but the timing tolerance is poor. The threshold of CMOS chips is not well defined, for example "4000 series" and HC should be close to half the supply rail, but HCT and PICaxes, etc. use a threshold nearer to 1.4 volts (regardless of the Vdd). The functionality also relies on the (undefined) "protection" diodes fitted to CMOS inputs.

[EDITED onwards from here]


However, a PULSOUT can deliver a 10us pulse (if a 4 MHz clock) and even 10 or 20 times this period is short compared with typical PICaxe instruction times. So the "Data" can be applied to the Shift Register input via a simple capacitor coupling of perhaps 100us time constant (e.g. 10k + 10nF), with the bias resistor to the supply rail. Within 10us, the D input should rise (from earth) by only about 10% towards the supply rail (so clearly a logic "0") whilst after 200us it should be within 10% of the supply rail (so clearly a "1").

Having clocked the required number of bits into the Shift Register, the RS line can then be set low (if required) without shifting any more data through the register, then E pulsed to load the Data into the LCD chip. This method could use a Quad, Hex or Octal Shift Register or Latch; the Hex supporting Backlight and/or R/W control, and the Octal (e.g. 595) permitting a return to the much easier 8-bit bus mode.

So the only remaining issue is to find the most efficient PICaxe program code to load the Shift Register. Can anyone do any better than the following examples for "inline" (faster) or "looping" (compact) code ?

Code:
;   FASTER   (~100 bytes for 8 bits)
if bit7 = 0 then pulsout RS,1
else pulsout RS,20 : endif
if bit6 = 0 then pulsout RS,1
else pulsout RS,20 : endif
if bit5 = 0 then pulsout RS,1
else pulsout RS,20 : endif
if bit4 = 0 then pulsout RS,1
else pulsout RS,20 : endif
;  etc..
;  COMPACT   (~25 bytes)
for bitn = 0 to 7
if char < 128 then pulsout RS,1
else pulsout RS,20 : endif
char = char + char		; Shift left
next bitn
Cheers, Alan.
 
Last edited:

elec_mech

New Member
You guys are awesome! Sorry for the late reply. I'm still sifting through all the wonderful information, but wanted to give everyone my thanks. Hippy, thank you for the breakdown of the existing circuit, this will immensely help my understanding if nothing else. Alan, thank you for the breakdown of various LCD control options - I thought of a couple, but your list puts mine to shame.

Thank you all again.
 

hippy

Technical Support
Staff member
Out of interest I decided to create a "hierachy" of possible methods to drive LCD/OLED displays...
I must have missed that post earlier so just a few comments.

The problem with using a serial-to-4-bit PICAXE interface is that it can be difficult to do that quickly enough to avoid having to break up SERTXD commands to it. X2's have background receive which helps but then increases costs over M2 parts.

For reading of LCD's and control of R/W; I don't see many cases where there would be a need to do that.

If you have separate control of E there is no need to have separate control of RS. Complicated monostable systems just add complexity and aren't needed.

The I2C expander is probably the cheapest and easiest two-wire solution but does make for more complicated and slower software control.

My preferences would be -

One-wire : Serial to 8-bit PICAXE adapter (AXE132)
Two-Wire : I2C expander to 4-bit interface
Three-Wire : Shift register to 4-bit interface, plus separate E
 

AllyCat

Senior Member
Hi,

Yes, I recently bought as many of the (£1) I2C backpacks as I have (spare) LCD panels, and they certainly do provide a cheap and usable solution. You can't do any better than "zero extra PICaxe pins", at least if I2C is being used anyway. However, there are some (potential) issues associated with the 4-bit bus, particularly reduced speed with more code and complex/unreliable initialisation routines.

Indeed, I was planning to ask if R/W control is of any real value (since the I2C expander backpacks do connect the R/W pin), or if it can even be used with an I2C expander in 4-bit mode (obviously it cannot with the basic Shift-Register/Latch method). But, I would like to "defend" my alternative shift-register proposal above. IMHO one resistor and a capacitor with a timing tolerance around -75% +400% is not "complicated", particularly if it offers the possibility of returning from a 4-bit to an 8-bit bus system.

Again, "out of interest", I was about to add an HC595 to a recent order for components, but noticed that it was "awaiting delivery", so I changed to an HC4094. That's even cheaper and potentially easier to use (than an HC595), because I believe the main difference is that it has a "Transparent Latch" (which can be tied active) rather than a "D-Latch" (which requires a clock pulse) interface to the buffered Outputs. It's definitely not high on my "todo" list, and I don't expect to even see the 4094 until after Easter, but maybe I'll add some practical results to this thread in due course. However, can anybody do any better than my suggested data-width modulation code above?

Cheers, Alan.
 

hippy

Technical Support
Staff member
However, can anybody do any better than my suggested data-width modulation code above?
If you can tweak the timing so the PULSOUT is 1 or 2N+1 you can optimise as below, PULSOUT 1 or 17 in this case

b1 = 1
bit12 = bit7 : PulsOut RS, b1
bit12 = bit6 : PulsOut RS, b1
bit12 = bit5 : PulsOut RS, b1
bit12 = bit4 : PulsOut RS, b1
 

AllyCat

Senior Member
Hi,

Ah yes, I had thought of putting each output bit into "bit4" (or bit12 in this case) using a "mask" over the (shifted) "character" byte, but that's obviously better. Might be possible to output a complete data byte in around 10ms, even with a 4 MHz clock. ;)

Thanks, Alan.
 
Top