Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Extra safe LCD module interface circuitry.

Status
Not open for further replies.
... The first and most important part is the delays, there are none for the last four commands. Unless the clock is really really slow the μC would be hammering the LCDM with command after command before it had time to complete them.
...

Take a look in the Hitachi 44780 LCD driver IC datasheet, int he commands table it should list the delays needed for certain commands.

...
Second is that, as you pointed out, 160us could/should be 1.6ms. We can't know from the code shown since they didn't have the forethought to let us know how this "Delay()" function actually works.
...

Agreed! :) SInce you are coding in C you could just use the C functions for delays in actual mS, like Delay_mS(x) and match or exceed the delays required by the datasheet.

...
The last details aren't really deal breakers, they are more conceptual problems. Calling command() three times in a row while passing the same exact data to it each time is inefficient and unnecessary IMO. All that really needs to be done is to load the command once, then just |Delay|->|Strobe E|->|Delay|->|Strobe E|->|Delay|.
...

True, but in C the compiler will be reasonably efficient for multiple calls with the same argument. It should load the data value once on the C stack and then just call the function 3 times. In the interest of good coding personally I would just leave it as 3 function calls.

...
Finally, and I could be totally wrong, but I don't think the entire sequence shown is necessary. I have been down this road with them before, followed their sequence to the letter, couldn't get the thing to work for weeks. I finally broke down and went to their forums where they gave me an entirely different sequence than the suggested one. It worked on the first try.
...

The datasheet should have the correct startup sequence, it looks something like the code you posted. You can sometimes eliminate some of it and get a working LCD but again for good coding practice following their sequence should hopefully ensure good compatibility with all brands of display etc.

...
I have a cute little "interlock" routine now that I hope works. Just as the name implies, it is designed in such a way that you (mostly) can't do LCD/PORT operations without going through these routines, and there is no combination of calls to them that can lead to both devices being Low-Z simultaneously. I also have two simple checks and a "panic room" catch all that can be used independently should one be forced to bypass the interlock system. ...

Sounds like a clever solution. Congrats. :)
 
Looks like the hardware works to pass signals (It can do stuff correctly on the LCDM). But the big questions are... Is it safe from a short circuit? And, am I brave enough to test it to find out? In any case, I will have picture proof that it works when I get something clever showing up on the screen. :D

Just to recap a bit . . .
The suggested hardware protection circuit in series with each bus wire is simply a 4k7 resistor and a 1nF cap in parallel with it.

The idea is simple, use a resistor to limit DC short circuit current, *BUT* bypass the AC with a cap to speed up the edges of the signal (rise/fall time). The hope for the safety aspect is that during a short circuit, the cap will be small enough that the large[ish] momentary current will be so short lived that it will not cause damage to the fully on output driver.

I simulated a 200 Ohm resistance for driver output transistor, and the current went from ~30mA down to 1mA in only ~700ns, which I think is pretty safe. I actually believe that the max power/energy the transistors will ever have to survive is a fixed constant. Which should be derived from the voltage and the capacitance, regardless of the output transistors on resistance. If that's true then the output transistors needs to survive 12n Joules, assuming I did the math right.

J = 1/2 * V[SUP]2[/SUP] * C

V = 5 Volts
C = 1nF = 0.000000001F
 
As promised, here are some pictures of the prototype, proof it's working, schematic, and the source code for my interlock routines.

0111030707.jpg0111030707a.jpg0111030711.jpg0111030711a.jpg

Here is the circuit, could easily work for other things than just MCU -> LCD coms.
Code:
                      1nF
       │        ┌------╫------┐        │
       │_       |             |       _│
  PIC  │_│------┴----\/\/\----┴------│_│  LCDM
       │              4K7              │
       │                               │

And below is the source code for the interlock routines. Note that I give simple check routines that are made to call a single PANIC routine if it fails the check. This PANIC routine can be anything you want it to be. From as simple as calling Z_LOCK (or manually doing the equivalent) then looping indefinitely, to as complex as a system check and fully restarting the entire PIC and LCD. Alternately you can simply change the call to the correct fix for each situation separately. It is entirely up to you.

Code:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Software "Interlock" routine's for (relatively) safe LCDM  use ;{
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Do to the fact that both a PIC and an LCDM have the ability to source or sink
; current. It is necessary to be very careful when enabling PORTx as output.
; If any two pins are driven from both sides with opposite polarity . . .
;			***** POOF *****
; To prevent this, one MUST make sure the R/W pin is always LOW(0) when
; PORTx is being driven. Inversely, one MUST always make sure TRISx is 0xFF
; whenever we have R/W pulled high. Things *WILL* break if this is ignored.
;
; PORTx is your 8-bit LCDM bus port. PORTy's is your LCDM control lines.
;
; A few other safeties are (1) to be able to make both sides High-Z simultaneously, 
; and (2) to be able to check each side for when it's not High-Z, and deal with it.
;
; This problem is mentioned briefly in DS31009A - 9.10, bottom of page 14.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; LCD2PIC - prep for LCDM to PIC direction of data flow. [LCD] --[2]--> [PIC]
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;	
LCD2PIC		movlw	b'11111111'	; Set TRISx so all PORTx
		movwf	TRISx		; Pins are inputs only.

		movlw	b'00011111'	; Non destructively make the top
		andwf	TRISy, F	; three pins of PORTy outputs

; It should be OK to let the LCDM drive the bus now, as PORTB is High-Z.

	 ;*** WARNING ***   *LCDM is now Low-Z*
		bsf	RW		; Set R/W. 
	 ;*** WARNING ***   *LCDM is now Low-Z*
	
	return
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; PIC2LCD - prep for PIC to LCDM direction of data flow.  [PIC] --[2]--> [LCD]
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
PIC2LCD		bcf	RW		; clear the R/W pin

		movlw	b'00011111'	; Non destructively make the top
		andwf	TRISy, F	; three pins of PORTx outputs

; It should be OK to let PORTB drive the bus now, as the LCDM is in High-Z.

      ;*** WARNING ***    *PORTx is now Low-Z*
		clrf	TRISx		; Clear TRISx. 
      ;*** WARNING ***    *PORTx is now Low-Z*

	return
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Z_LOCK - This makes it so PORTx and the LCDM are both High-Z simultaneously.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Z_LOCK		movlw	b'11111111'	; Make all PORTx pins input
		movwf	TRISx		; 

		movlw	b'10111111'	; Give us control over LCDM
		andwf	TRISy, F 	; R/W pin. Don't change others

		banksel	PORTy		; Clear the RW command pin
		bcf	RW		; making the LCD go High-Z

	return
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Check to see if the E pin is set to make LCDM output, if so... PANIC.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;		btfsc	RW		; Test the RW pin. (not the latch)
;		bra 	PANIC		; Anything other than Low... PANIC
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Check to see if any of PORTB's pins are set to output, if so... PANIC.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;		incfsz	TRISx, W	; Test to see if any TRISx bit is low/0
;		bra	PANIC		; Anything other than all 1's... PANIC;}
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
Last edited:
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top