Searching \ for ' LCD Problems' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/lcds.htm?key=lcd
Search entire site for: 'LCD Problems'.

No exact or substring matches. trying for part
PICList Thread
'Matrix Orbital I2C LCD problems'
2000\02\04@101458 by Jim Dossey

flavicon
face
I was wondering if anyone on the has connected a Matrix Orbital LCD
panel to a 16C74A?  We are tring to connectin one but it is not
working.  We have a EEPROM connected to the I2C bus now, and we can talk
to it with no problems.  I'm using the same code to write to the LCD
panel that I used for the EEPROM (with a different I2C ddress and
without the EEPROM address).  The LCD panel doesn't ACK anything I send
it, and it never displays any text.  I connected the LCD panel to a PC
via the RS232 port and that worked fine.

We have about a 12" cable running to the LCD panel.  Would that cause a
problem?

I have also been in contact with tech support at Matrix Orbital.  They
said we might just have a bad unit.  But I thought I might check on the
PICLIST to see if anyone has done this before, and if they had any
special problems.

Thanks,
Jim Dossey


'[PICLIST] LCD Problems'
2001\02\04@214115 by Ian Hynes
flavicon
face
PICers,

Sorry to rehash an old topic but I CAN'T get this HD44780 LCD
programme to work with a 16F84. Tried everything.  What drives me nuts
is that the
same programme in a 16C57 works fine. Well, damn - what's going on?
Anybody got ideas??

Any help/advice/insights MUCH appreciated!

Thanx - Ian

title lcdtst01
;
;CCT CONFIGURATION :
                            ------   ------
; DAT_C, 74C922 =>       RA2 |1    ---   18| RA1         <= DAT_B,
74C922
; DAT_D, 74C922 =>       RA3 |2          17| RA0         <= DAT_A,
74C922
;     BATT TEST => T0CKI/RA4 |3          16| OSC1/CLKIN  <= 2MHz XTAL
;        +5 VDC ->     /MCLR |4          15| OSC2/CLKOUT <= 2MHz XTAL
;           GND ->       Vss |5   16F84  14| Vdd         <- +5 VDC
;    74C922, DA  <-  INT/RB0 |6          13| RB7        ->  LCD EN
;            NC  <-      RB1 |7          12| RB6        ->  LCD DT
;            NC  <-      RB2 |8          11| RB5        ->  LCD CK
;            NC  <-      RB3 |9          10| RB4        ->  NC
;                            ---------------

LIST p=16F84, F=INHX8M, R=HEX
     errorlevel 0, -302, -305
           ;302="register in operand not in "
           ;305="Using Default Destination"

__CONFIG _CP_OFF & _WDT_OFF & _XT_OSC

include "p16f84.inc"
include "asc2lcd.inc"    ;The LCD alpha-numeric assignments

;*********************************************************
;VECTOR ASSIGNMENTS
;*********************************************************
pic84    equ   0x01FD      ;MAX memory address

;*********************************************************
;LCD pin assignments
;*********************************************************
EN       equ 7
CH       equ 6
CK       equ 5

RS       equ 3       ;Bit #4 in LCDFLAGS determines Command\Character
for
                    ;the LCD
;*********************************************************
;FLAG REGISTER assignments
;*********************************************************
VT        equ  2      ;VALID TRANSMISSION from 74C922 to RB0

;*********************************************************
;MACROS
;*********************************************************
BANK_0 MACRO
bcf  STATUS,RP0       ;RP0=STATUS.b5
bcf  STATUS,RP1       ;RP1=STATUS.b6
ENDM

BANK_1 MACRO
bsf STATUS,RP0
bcf STATUS,RP1
ENDM

;*********************************************************
;REGISTER ASSIGNMENTS
;BANK #0
;*********************************************************
CBLOCK 0x00C
w_                     ;Stores w during interrupts
STATUS_                ;A 'dummy' STATUS register
PCLATH_
FSR_
flags                  ;A 'decision' register
Keydata                ;Holds DATA NIBBLE from the 74C922
count_00
count_01
count_02
count_03

;LCD registers.
temp                   ;Holds HEX data prior to conversion to ASCII
w2                     ;Dummy w register used by nib_tx
charac                 ;Data for the LCD
LCDflag                ;Flags R/W, cursor status etc
d10000                 ;ASCII digits
d1000
d100
d10
d01
count
count_10               ;PAGE #1 count registers, available for
count_11               ;up to 3-loop counters
count_12
count_13
ENDC

;********************************************************
;Begin the MAIN PROGRAMME
;********************************************************
;PAGE
        org       0x00
start    goto      main

        org       0x04
int      movwf     w_             ;Start interrupt routine
        movf      STATUS,0
        bcf       STATUS,0       ;Put registers into known page
        movwf     STATUS_
        movf      PCLATH,0       ;Save PCLATH
        movwf     PCLATH_
        movf      FSR,0
        movwf     FSR_
b1       nop                      ;Do nothing for now
        nop

int_ret  movlw     b'00011000'    ;Reset the INTCON bits BUT ...
        movwf     INTCON         ;.. let the PIC set GIE upon retfie
        movf      FSR,0
        movwf     FSR
        movf      PCLATH_
        movwf     PCLATH
        movf      STATUS_,0      ;Return from interrupt
        swapf     w_             ;Flip & laod the w register
        swapf     w_,w           ;without affecting the STATUS reg.
        retfie

;*************************************************************
;Initialise the PIC84's PORTS.
;
;PIN ASSIGNMENTS
;RB0  ..  INPUT. Reads DR  (Active High) from 74C922
;RB1  ..  NC
;RB2  ..  NC
;RB3  ..  NC
;RB4  ..  NC
;RB5  ..  OUTPT to 74164 (CK)
;RB6  ..  OUTPT to 74164 (Data B = CH)
;RB7  ..  OUTPT to LCD (EN)
;
;RA0  ..  INPUT. Reads DAT_A from 74C922
;RA1  ..  INPUT. Reads DAT_B from 74C922
;RA2  ..  INPUT. Reads DAT_C from 74C922
;RA3  ..  INPUT. Reads DAT_D from 74C922
;RA4  ..  INPUT. NC.
;
;*************************************************************
init     clrf    PORTB
        BANK_1
        movlw   b'00000001'    ;All except RB0 to be OUTPTs
        movwf   TRISB
        BANK_0
        movlw   0x0F1          ; Make sure OUTPTs are OFF
        movwf   PORTB

        clrf    PORTA
        BANK_1
        movlw   0x01F
        movwf   TRISA
        BANK_0
        movlw   0x01F          ;PORTA to be all INPUTs
        movwf   PORTA          ;Bits 0,1,2,3,4 set to "1"
        retlw   0x00

;*********************************************************
;LCD ROUTINES
;
; LCDtx4  .. a routine to drive the HC44780 LCD in 4-bit
;            mode via a 3-wire interface.
;
; Data byte must already be in the CHARAC when the
; routine is called. Data format ... D7 D6 D5 D4 RS x x x
;This routine shifts a NIBBLE of Data into the LCD but does so
;using a BYTE count. Data must be in the HIGH NIBBLE of the
;charac register.
;************************************************************
lcdtx4   movlw    0x08
        IFDEF DEBUG
          goto lcdout
        ENDIF

        movwf    count
        bcf      STATUS,C
        bcf      PORTB,CK
        nop                    ;Rest between bit ops.
        bsf      PORTB,CH      ;Initialise the Data port.
rotate   rlf      charac,1      ;Rotate the the Data thru CARRY, MSB
first.
        btfss    STATUS,C      ;Data bit = 1?
         bcf     PORTB,CH      ;No  - send a zero
        nop                    ;Rest between bit ops.
        bsf      PORTB,CK      ;Clock the bit thru
        nop
        nop                    ;Rest between bit ops.
        bcf      PORTB,CK
        decfsz   count,1       ;Stepped down thru 8 bits?
         goto    rotate-1      ;No  - keep clockin'
        nop                    ;Rest between bit-ops.
        bsf      PORTB,EN      ;Enable the LCD and
        nop
        nop
        nop
        nop                    ;transfer the Data.
        bcf      PORTB,EN
        nop
lcdout   bcf      PORTB,CH      ;Leave PORTB in a defined state. All
LOW.
        retlw    0x00          ;Return to calling routine in PAGE #1

;**************************************************************
;NIB_TX takes a Data byte and puts the LS nibble into the HIGH
;nibble of the charac register. Data byte must be in the w register.
;NIB_TX checks RS of the LCDflags register to determine CHARACTER or
;COMMAND mode for the LCD
;*****************************************************************
nib_tx  movwf    w2           ;w2 a VIRTUAL w register.. NOT w_
       movlw    b'11110000'  ;Isolate the upper nibble and
       andwf    w2,0         ;retrieve it in w.
       movwf    charac       ;Stash the processed byte in charac
       btfsc    LCDflag,RS   ;RS=0? COMMAND mode?
        bsf     charac,3     ;No - set RS line for CHARACTER mode.
       call     lcdtx4       ;and send it to the LCD.
       IFNDEF DEBUG
        call     DLY160      ;Wait 160 us till the LCD settles
       ENDIF
       swapf    w2,1         ;Invert the H & L nibbles
       movlw    b'11110000'
       andwf    w2,0         ;Isolate the new upper 4 digits
       movwf    charac       ;and store in charac register.
       btfsc    LCDflag,RS   ;RS=0? COMMAND mode?
        bsf     charac,3     ;No  - set RS line for CHARACTER mode.
       call     lcdtx4       ;Send'em to the LCD
       IFNDEF DEBUG
        call     DLY160      ;Wait 160 uS till the LCD settles.
       ENDIF
       retlw    0x00         ;Go back to page #1 calling routine

;****************************************************************
;DLY160 ... a one-loop, 160 usec (2.0MHz xtal) delay routine
;Both LCD delay routines are called from PAGE #1 and return there.
;DRTE : July 14, 1999
;*****************************************************************
DLY160   movlw    0x05F        ;0x050 Calculate C1= 4F (d79) for T=160
us)
        movwf    count_11
        decfsz   count_11,1
         goto    $-1
        retlw    0x00

;****************************************************************
;DLY_5 ...  A two-loop, 5-m sec (2.0 MHz xtal) delay routine.
;Both LCD delay routines are called from PAGE #1 and return there.
;DRTE  : July 14, 1999
;****************************************************************
DLY_5    movlw    0x01F      ;0x0F calculate C2=$0A (d10) for T = 5
msec
        movwf    count_12
        movlw    0x0FF
        movwf    count_11
        decfsz   count_11,1
         goto    $-1
        decfsz   count_12,1
         goto    $-5
        retlw    0x00

;**********************************************************
;Main Programme  .. begin from upper half of Bank #0. Turn
;the interrupts OFF till we're configured.
;**********************************************************
main    ;bcf      INTCON,GIE   ;Switch off interrupts while we  ...
       BANK_0
       call     init         ;Initialise the ports

;***********************************************************
;Power up and configure the LCD
;***********************************************************
pwr_up   clrf     LCDflag
        bcf      LCDflag,RS  ;Clear RS.. COMMAND mode ENABLED
        IFNDEF DEBUG
         call    DLY_5       ;Wait 15 ms after switch-on
         call    DLY_5
         call    DLY_5
         call    DLY_5
        ENDIF

        movlw    b'00110000' ;Write 0x03 to the LCD three
        movwf    charac      ;times with suitable delays
        call     lcdtx4      ;RS=0 for COMMAND instructions
        IFNDEF DEBUG
         call    DLY_5
        ENDIF

        movlw    b'00110000'
        movwf    charac
        call     lcdtx4
        IFNDEF DEBUG
         call    DLY160
        ENDIF

        movlw    b'00110000'
        movwf    charac
        call     lcdtx4
        IFNDEF DEBUG
         call    DLY160
        ENDIF

        movlw    b'00100000'  ;4 bit interface
        movwf    charac
        call     lcdtx4
        IFNDEF DEBUG
         call    DLY160
        ENDIF

;***************************************************************
;The following instrucs require 2 only NIBBLE WRITES to the LCD.
;Pass the parameters to the NIB_TX subroutine in w. NIB_TX will
;call the lcd_tx4 subroutine. BEWARE the nest level!!
;***************************************************************
        movlw    b'00101000'    ;Write FUNCTION SET
        call     nib_tx
        IFNDEF DEBUG
         call    DLY160
        ENDIF

        movlw    b'00001110'    ;Write ON/OFF
        call     nib_tx
        IFNDEF DEBUG
         call    DLY160
        ENDIF

        movlw    b'00000110'   ;write ENT MODE
        call     nib_tx
        IFNDEF DEBUG
         call    DLY160
        ENDIF

        movlw    b'00000011'   ;Return Cursor & LCD to home
        call     nib_tx
        IFNDEF DEBUG
         call    DLY160
        ENDIF

;************************************************************
;Then display a "WAKE UP" message ...
;************************************************************
wakeup   movwf    charac
        IFNDEF DEBUG
         call    DLY_5
        ENDIF

        clrf     LCDflag
        bsf      LCDflag,RS    ;Set RS=1 for CHARACTER mode.
                               ;Enable the 4 bit operating mode.
        movlw    lcd_I         ;Load 'I' =  B'01001001'
        call     nib_tx
        IFNDEF DEBUG
         call    DLY160
        ENDIF

        movlw    lcd_A         ;Load 'A' = B'01000001'
        call     nib_tx
        IFNDEF DEBUG
         call    DLY160
        ENDIF

        movlw    lcd_N         ;Load 'N' = B'01001110'
        call     nib_tx
        IFNDEF DEBUG
         call    DLY160
        ENDIF

setint  nop                        ;Forget interrupts till the LCD
works!
       ;BANK_1
       ;movlw    0x0D
       ;movwf    OPTION_REG
       ;BANK_0
       ;clrf     TMR0
       ;movlw    b'10011000'      ;Enable the interrupts
       ;movwf    INTCON
       ;clrf     flags            ;Initialise the flags

       goto    wakeup             ;Hold it here
       end

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\02\04@215409 by David VanHorn

flavicon
face
At 01:36 PM 2/5/01 +1100, Ian Hynes wrote:
>PICers,
>
>Sorry to rehash an old topic but I CAN'T get this HD44780 LCD
>programme to work with a 16F84. Tried everything.  What drives me nuts
>is that the
>same programme in a 16C57 works fine. Well, damn - what's going on?
>Anybody got ideas??
>

Assuming you did everything right to port the code:

Did you happen to change the crystal speed?
This will affect your timing delays.
The initialization is critical.


--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2001\02\05@020610 by dr. Imre Bartfai

flavicon
face
Hi,
without studying your code in-depth, I see some typical problem in your
ISR. Critical places are marked below. I hope this helps.

Regards,
Imre


On Mon, 5 Feb 2001, Ian Hynes wrote:

{Quote hidden}

*** Statement below is bad as itself changes the status register

>          bcf       STATUS,0       ;Put registers into known page
>          movwf     STATUS_
>          movf      PCLATH,0       ;Save PCLATH
*** sorry - PCLATH can not be read as spec gives.
*** it is better not to change pages and set up save registers for
*** every bank at the same location.

{Quote hidden}

*** if you do not use IT's, there is no point to write an ISR

{Quote hidden}

*** RB2..4 will be low, RB4..7 will be high...

>          movwf   PORTB
>
>          clrf    PORTA
>          BANK_1
>          movlw   0x01F
>          movwf   TRISA
>          BANK_0
>          movlw   0x01F          ;PORTA to be all INPUTs
>          movwf   PORTA          ;Bits 0,1,2,3,4 set to "1"
*** to write to inputs does not make any sense

{Quote hidden}

Sorry, I did not follow the whole part of code. However, as I recall,
74164 has a clear pin which should be considered.

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu


2001\02\05@022513 by Bob Ammerman

picon face
----- Original Message -----
From: dr. Imre Bartfai <EraseMErootspam_OUTspamTakeThisOuTPROF.PMMF.HU>
To: <PICLISTspamspam_OUTMITVMA.MIT.EDU>
Sent: Monday, February 05, 2001 2:03 AM
Subject: Re: [PIC]: LCD Problems


> Hi,
> without studying your code in-depth, I see some typical problem in your
> ISR. Critical places are marked below. I hope this helps.
>
> Regards,
> Imre

Yikes! At least some of your corrections are incorrect!

I've marked my opinion with "!!!" below.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Quote hidden}

!!! I assume you meant to say 'statement above', but the original
!!! value of STATUS will be properlyy copied to W

> >          bcf       STATUS,0       ;Put registers into known page
> >          movwf     STATUS_
> >          movf      PCLATH,0       ;Save PCLATH
> *** sorry - PCLATH can not be read as spec gives.

!!! Why not??

> *** it is better not to change pages and set up save registers for
> *** every bank at the same location.

!!! In the F84 all GPR is mapped in both banks 0 and 1 anyway

>
> >          movwf     PCLATH_
> >          movf      FSR,0
> >          movwf     FSR_
> > b1       nop                      ;Do nothing for now
> >          nop
> >
> > int_ret  movlw     b'00011000'    ;Reset the INTCON bits BUT ...
> >          movwf     INTCON         ;.. let the PIC set GIE upon retfie

!!! Normally you'd test bits in INTCON,
!!! handle the interrupt and then clear them

> >          movf      FSR,0
> >          movwf     FSR
> >          movf      PCLATH_
> >          movwf     PCLATH
> >          movf      STATUS_,0      ;Return from interrupt

!!! You are missing a MOVWF STATUS here
!!! to restore the status register

> >          swapf     w_             ;Flip & laod the w register
> >          swapf     w_,w           ;without affecting the STATUS reg.
> >          retfie
>
> *** if you do not use IT's, there is no point to write an ISR

!!! This is certainly true!

{Quote hidden}

!!! Yep, after 'glitching' to all lows becuase of the
!!! clrf PORTB, above

{Quote hidden}

!!! Yep, plus RA4 is defined as an  "INPUT NC (no connection)"
!!! This is a bad idea (floating input).

!!! I stopped looking at the code, here (Bob A)

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\02\05@191409 by Ian Hynes

flavicon
face
Hey Bob & Imre,

Thanks, I've been thru the corrections and made changes to the ISR.
Imre's way of configuring the outpt is good - the LEDs go high right
at the start ; can't see any low-going little glitches on a CRO.

OK, the new init & ISR segments look like so :-

init     movlw   b'11111111'
        movwf   PORTB          ;Make PORTB all HIGH, avoid turn-on
glitch??
        BANK_1
        movlw   b'00000001'    ;All except RB0 to be OUTPTs
        movwf   TRISB
        BANK_0
        movlw   b'00011111'
        movwf   PORTA
        BANK_1
        movlw   0x01F
        movwf   TRISA
        BANK_0
        retlw   0x00
;<...................>
       org       0x04
int      movwf     w_             ;Start interrupt routine
        movf      STATUS,0
        movwf     STATUS_
        movf      PCLATH,0       ;Save PCLATH
        movwf     PCLATH_
        movf      FSR,0
        movwf     FSR_
b1       nop            ;Do the interrupt routine
              ;There are KPD & LED routines in here let's not confuse
things ...
b2       nop            ;Send the result to RS232

int_ret  movlw     b'00011000'    ;Reset the INTCON bits BUT ...
        movwf     INTCON         ;.. let the PIC set GIE upon retfie
        movf      FSR,0
        movwf     FSR
        movf      PCLATH_
        movwf     PCLATH
        movf      STATUS_,0      ;Return from interrupt
        movwf     STATUS
        swapf     w_             ;Flip & laod the w register
        swapf     w_,w           ;without affecting the STATUS reg.
        retfie

The ISR works OK, as shown above. The cct grabs a nibble from a KPD
via a 74C922 and lights up 4 LEDs with it.

***The only thing that's NOT working is the LCD. ***

I made sure MPLAB is set to 2MHz, same as the cct, as Dave vanH
suggested. And i can change LCD, 74164 etc over into the 16C57 cct and
they work so it's not that ...

Wait'll i fiddle some more with it guys ... I'd better repost anyway
cuz I didn't put in the [PIC]: prefix originally. NEWTON's LAW
applies!<GR>


Bob Ammerman wrote:
>
> {Original Message removed}

2001\02\05@204604 by Bob Ammerman

picon face
----- Original Message -----
From: Ian Hynes <spamBeGoneelekspamBeGonespamNETSTRA.COM.AU>
To: <TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU>
Sent: Monday, February 05, 2001 7:10 PM
Subject: Re: [PIC]: LCD Problems


{Quote hidden}

   ^^^^^^^^^^^^^^^ Should be movf FSR_,0

(btw: I don't much care for the ",0" syntax. I prefer ",W" and ",F")


{Quote hidden}

your
{Quote hidden}

nuts
{Quote hidden}

retfie
{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamEraseMEmitvma.mit.edu


2001\02\06@182532 by Ian Hynes

flavicon
face
PICers,

OK, I've made changes to the ISR as Bob A. and other guys suggested.
*MANY* thanks for the tips! The interrupt part of the programme works
fine - grabs a data nibble from a 4x4 keypad, via a 74C922 decoder and
dumps it to 4 LEDs on PORTB.

But the %&#! LCD still doesn't give a bleep. What's totally
infuriating is the routines work - at least they do on a 16C57. If
anyone's got any ideas, I'd be mighty interested to hear.

(I've got both the 16C84 & 16C57 ccts set up on protoboard, so it's
easy to make hardware changes. Both are stock standard ccts, though.)

Thnaks for *any* advice - Ian.

I'm conpletely stumped, so here's the full code :-

title lcdtst01
;
;DATE      : February 2, 2001
;PURPOSE   : A programme to control an HD44780 LCD via a PIC 16F84
;AUTHOR    : Ian H.
;SCHEMATIC : LCDTST01.sch
;
;COMMENTS  :
;
;PIC CONFIGURATION :
;
;                            ------   ------
; DAT_C, 74C922 =>       RA2 |1    ---   18| RA1         <= DAT_B,
74C922
; DAT_D, 74C922 =>       RA3 |2          17| RA0         <= DAT_A,
74C922
;     BATT TEST => T0CKI/RA4 |3          16| OSC1/CLKIN  <= 2MHz XTAL
;        +5 VDC ->     /MCLR |4          15| OSC2/CLKOUT <= 2MHz XTAL
;           GND ->       Vss |5   16F84  14| Vdd         <- +5 VDC
;    74C922, DA  <-  INT/RB0 |6          13| RB7        ->  LCD EN
(ENABLE)
;          LED1  <-      RB1 |7          12| RB6        ->  LCD CH
(CHARACTER BITS)
;          LED2  <-      RB2 |8          11| RB5        ->  LCD CK
(CLOCK)
;          LED3  <-      RB3 |9          10| RB4        ->  LED4
;                            ---------------
;REVISIONS :

LIST p=16F84, F=INHX8M, R=HEX
     errorlevel 0, -302, -305
           ;302="register in operand not in "
           ;305="Using Default Destination"

__CONFIG _CP_OFF & _WDT_OFF & _XT_OSC

include "p16f84.inc"
include "asc2lcd.inc"    ;The LCD alpha-numeric assignments.
;
;CLOCK FREQ = 2.0 MHz

;*********************************************************
;VECTOR ASSIGNMENTS
;*********************************************************
pic84    equ   0x01FD      ;MAX memory address

;*********************************************************
;LCD pin assignments
;*********************************************************
EN       equ 7
CH       equ 6
CK       equ 5

RS       equ 3       ;Bit #4 in LCDFLAGS determines Command\Character
for
                    ;the LCD
;*********************************************************
;FLAG REGISTER assignments
;*********************************************************
VT        equ  2      ;VALID TRANSMISSION  ("VT") from 74C922 to RB0

;*********************************************************
;MACROS
;*********************************************************
BANK_0 MACRO
bcf  STATUS,RP0       ;RP0=STATUS.b5
bcf  STATUS,RP1       ;RP1=STATUS.b6
ENDM

BANK_1 MACRO
bsf STATUS,RP0
bcf STATUS,RP1
ENDM

;*********************************************************
;REGISTER ASSIGNMENTS
;BANK #0
;*********************************************************
CBLOCK 0x0C
w_                     ;Stores w during interrupts
STATUS_                ;A 'dummy' STATUS register
PCLATH_
FSR_
flags                  ;A 'decision' register
Keydata                ;Holds DATA NIBBLE from the 74C922
count_00               ;GP counters
count_01
count_02
count_03

;LCD registers.
temp                   ;Holds HEX data prior to conversion to ASCII
w2                     ;Dummy w register used by nib_tx
charac                 ;Data for the LCD
LCDflag                ;Flags R/W, cursor status etc
d10000                 ;ASCII digits to be loaded into the LCD
d1000
d100
d10
d01
count                  ;More counters .. used in the LCD routines
count_10               ;PAGE #1 count registers, available for
count_11               ;up to 3-loop counters
count_12
count_13
ENDC

;********************************************************
;Begin the MAIN PROGRAMME
;********************************************************
PAGE
        org       0x00
start    goto      main

        org       0x04
int      movwf     w_             ;Start interrupt routine
        movf      STATUS,0
        movwf     STATUS_
        movf      PCLATH,0       ;Save PCLATH
        movwf     PCLATH_
        movf      FSR,0
        movwf     FSR_
b1       call      kbdgrab        ;Do the interrupt routine
        movf      Keydata,0
        clrf      LCDflag
        bsf       LCDflag,RS     ;Set RS=1 for CHARACTER mode.
                                 ;Enable the 4 bit operating mode.
        movwf     temp           ;Now display the LCD readout
        call      hex2asc        ;Convert to ASCII
        movf      d01,0          ;And send to the LCD
        call      nib_tx
        movf      d10,0
        call      nib_tx
        movf      d100,0
        call      nib_tx

        rlf       Keydata,1
        bsf       Keydata,0
        movf      Keydata,0
        addlw     b'10100000'    ;Send 101 to the LCD INPUT (No new
data bits)
b2       movwf     PORTB          ;Send the result to RS232

int_ret  movlw     b'00011000'    ;Reset the INTCON bits BUT ...
        movwf     INTCON         ;.. let the PIC set GIE upon retfie
        movf      FSR_,0
        movwf     FSR
        movf      PCLATH_
        movwf     PCLATH
        movf      STATUS_,0      ;Return from interrupt
        movwf     STATUS
        swapf     w_             ;Flip & load the w register
        swapf     w_,w           ;without affecting the STATUS reg.
        retfie

;*************************************************************
;Initialise the PIC84's PORTS.
;
;PIN ASSIGNMENTS
;RB0  ..  INPUT. Reads DR  (Active High) from 74C922
;RB1  ..  LED1
;RB2  ..  LED2
;RB3  ..  LED3
;RB4  ..  LED4
;RB5  ..  OUTPT to 74164 (CK)
;RB6  ..  OUTPT to 74164 (Data B = 'CH')
;RB7  ..  OUTPT to LCD (EN)
;
;RA0  ..  INPUT. Reads DAT_A from 74C922
;RA1  ..  INPUT. Reads DAT_B from 74C922
;RA2  ..  INPUT. Reads DAT_C from 74C922
;RA3  ..  INPUT. Reads DAT_D from 74C922
;RA4  ..  INPUT. NC. Use for battery test?
;
;*************************************************************
init     movlw   b'11111111'
        movwf   PORTB          ;Make PORTB all HIGH, avoid turn-on
glitch??
        BANK_1
        movlw   b'00000001'    ;All except RB0 to be OUTPTs
        movwf   TRISB
        BANK_0
        movlw   b'00011111'
        movwf   PORTA
        BANK_1
        movlw   0x01F
        movwf   TRISA
        BANK_0
        retlw   0x00

;*********************************************************************
;KEYPAD GRAB - responds to an interrupt from the DA/VT pin on the
74C922,
;grabs the Data nibble and stores it in KeyData. It then sets b3 in
;flags before returning. VT, the pin, MUST be same as VT in the flags
register.
;*******************************************************************
kbdgrab movf     PORTA,0     ;Data are present.
       nop
       movwf    Keydata     ;Store the data
                            ;comf     Keydata,1   ;Invert the Active
Low input.
       movlw    b'00001111' ;Make SURE the upper nibble
       andwf    Keydata,1   ;really is b'0000'.
       bsf      flags,VT    ;Tell the main programme
       nop                  ;Jump to here if no input
       retlw    0x00

;********************************************************************
;hex2asc ... a HEX to BCD & ASCII conversion routine. The hex number
;to be converted must be in passed in 'temp'.
;Experimental - gives correct results on MPLAB simulator.
;********************************************************************
hex2asc  clrf    count
        bcf     STATUS,C
        movlw   0x064
        subwf   temp,1
        btfss   STATUS,C
         goto   $+3
        incf    count,1
         goto   $-5
        movf    count,0       ;Retrieve the MSD
        movwf   d100
        movlw   0x064
        addwf   temp,1
        clrf    count
        bcf     STATUS,C
        movlw   0x0A
        subwf   temp,1
        btfss   STATUS,C      ;-ve?
         goto   $+3
        incf    count,1
        goto    $-5
        movf    count,0       ;Retrieve the middle digit
        movwf   d10
        movlw   0x0A
        addwf   temp,1        ;???
        movf    temp,0        ;Retrieve LSD
        movwf   d01
        movlw   0x030         ;Convert to ASCII
        addwf   d100,1
        addwf   d10,1
        addwf   d01,1
        clrf    count
        clrf    temp
        retlw   0x00

;*********************************************************
; LCD ROUTINES .. protocols derived from HD44780 data sheet
; LCDtx4  .. a routine to drive the HC44780 LCD in 4-bit
;            mode via a 3-wire interface.
;
; Data byte must be passed in the 'charac' register
; Data format ... D7 D6 D5 D4 RS x x x
; Registers/PORTs needed :-
;                     w
;                     charac
;                     count
;                     PORTB.CH =     (character\instrucs)
;                     PORTB.CK =     (SIPO clock)
;                     PORTB.EN =     (LCD Enable)
;
;This routine shifts a NIBBLE of Data into the LCD but does so
;using a BYTE count. Data must be in the HIGH NIBBLE of the
;charac register. LOW nibble bits are all zeroes.
;************************************************************
lcdtx4   movlw    0x08
        IFDEF DEBUG          ;Bypass while trouble shooting.
          goto lcdout
        ENDIF

        movwf    count
        bcf      STATUS,C
        bcf      PORTB,CK
        nop                    ;Rest between bit ops.
        bsf      PORTB,CH      ;Initialise the Data port.
rotate   rlf      charac,1      ;Rotate the the Data thru CARRY, MSB
first.
        btfss    STATUS,C      ;Data bit = 1?
         bcf     PORTB,CH      ;No  - send a zero
        nop                    ;Rest between bit ops.
        bsf      PORTB,CK      ;Clock the bit thru
        nop
        nop                    ;Rest between bit ops.
        bcf      PORTB,CK
        decfsz   count,1       ;Stepped down thru 8 bits?
         goto    rotate-1      ;No  - keep clockin'
        nop                    ;Rest between bit-ops.
        bsf      PORTB,EN      ;Enable the LCD and
        nop
        nop
        nop
        nop                    ;transfer the Data.
        bcf      PORTB,EN
        nop
lcdout   bcf      PORTB,CH      ;Leave PORTB in a defined state. All
LOW.
        retlw    0x00          ;Return to calling routine in PAGE #1

;**************************************************************
;NIB_TX takes a Data byte and puts the LS nibble into the HIGH
;nibble of the charac register. High nibble is DATA, low nibble bits
;are all zero. Data byte is passed in the w register.
;NIB_TX checks RS of the LCDflags register to determine CHARACTER or
;COMMAND mode for the LCD
;*****************************************************************
nib_tx  movwf    w2           ;w2 a VIRTUAL w register.. NOT w_
       movlw    b'11110000'  ;Isolate the upper nibble and
       andwf    w2,0         ;retrieve it in w.
       movwf    charac       ;Stash the processed byte in charac
       btfsc    LCDflag,RS   ;RS=0? COMMAND mode?
        bsf     charac,3     ;No - set RS line for CHARACTER mode.
       call     lcdtx4       ;and send it to the LCD.
       IFNDEF DEBUG
        call     DLY160      ;Wait 160 us till the LCD settles
       ENDIF
       swapf    w2,1         ;Invert the H & L nibbles
       movlw    b'11110000'
       andwf    w2,0         ;Isolate the new upper 4 digits
       movwf    charac       ;and store in charac register.
       btfsc    LCDflag,RS   ;RS=0? COMMAND mode?
        bsf     charac,3     ;No  - set RS line for CHARACTER mode.
       call     lcdtx4       ;Send'em to the LCD
       IFNDEF DEBUG
        call     DLY160      ;Wait 160 uS till the LCD settles.
       ENDIF
       retlw    0x00         ;Go back to page #1 calling routine

;****************************************************************
;DLY160 ... a one-loop, 160 usec (2.0MHz xtal) delay routine
;Both LCD delay routines are called from PAGE #1 and return there.
;*****************************************************************
DLY160   movlw    0x0A5        ;0x050 Calculate C1= 4F (d79) for T=160
us)
        movwf    count_11
        decfsz   count_11,1
         goto    $-1
        retlw    0x00

;****************************************************************
;DLY_5 ...  A two-loop, 5-m sec (2.0 MHz xtal) delay routine.
;Both LCD delay routines are called from PAGE #1 and return there.
;****************************************************************
DLY_5    movlw    0x01E         ;0x0F Calculate C2=$0A (d10) for T = 5
msec
        movwf    count_12
        movlw    0x0FF
        movwf    count_11
        decfsz   count_11,1
         goto    $-1
        decfsz   count_12,1
         goto    $-5
        retlw    0x00

;**********************************************************
;Main Programme  .. begin from upper half of Bank #0. Turn
;the interrupts OFF till we're configured.
;**********************************************************
main    bcf      INTCON,GIE   ;Switch off interrupts while we  ...
       BANK_0
       call     init         ;Initialise the ports

;***********************************************************
;Power up and configure the LCD
;***********************************************************
pwr_up   clrf     LCDflag
        bcf      LCDflag,RS  ;Clear RS.. COMMAND mode ENABLED
        IFNDEF DEBUG
         call    DLY_5       ;Wait 15 ms after switch-on
         call    DLY_5
         call    DLY_5
         call    DLY_5
        ENDIF

        movlw    b'00110000' ;Write 0x03 to the LCD three
        movwf    charac      ;times with suitable delays
        call     lcdtx4      ;RS=0 for COMMAND instructions
        IFNDEF DEBUG
         call    DLY_5
        ENDIF

        movlw    b'00110000'
        movwf    charac
        call     lcdtx4
        IFNDEF DEBUG
         call    DLY160
        ENDIF

        movlw    b'00110000'
        movwf    charac
        call     lcdtx4
        IFNDEF DEBUG
         call    DLY160
        ENDIF

        movlw    b'00100000'  ;4 bit interface
        movwf    charac
        call     lcdtx4
        IFNDEF DEBUG
         call    DLY160
        ENDIF

;***************************************************************
;The following instrucs require 2 only NIBBLE WRITES to the LCD.
;Pass the parameters to the NIB_TX subroutine in w. NIB_TX will
;call the lcd_tx4 subroutine. BEWARE the nest level!!
;***************************************************************
        movlw    b'00101000'    ;Write FUNCTION SET
        call     nib_tx
        IFNDEF DEBUG
         call    DLY160
        ENDIF

        movlw    b'00001110'    ;Write ON/OFF
        call     nib_tx
        IFNDEF DEBUG
         call    DLY160
        ENDIF

        movlw    b'00000110'   ;write ENT MODE
        call     nib_tx
        IFNDEF DEBUG
         call    DLY160
        ENDIF

        movlw    b'00000011'   ;Return Cursor & LCD to home
        call     nib_tx
        IFNDEF DEBUG
         call    DLY160
        ENDIF

;************************************************************
;Then display a "WAKE UP" message ...
;************************************************************
wakeup   movwf    charac
        IFNDEF DEBUG
         call    DLY_5
        ENDIF

        clrf     LCDflag
        bsf      LCDflag,RS    ;Set RS=1 for CHARACTER mode.
                               ;Enable the 4 bit operating mode.
        movlw    lcd_I         ;Load 'I'
        call     nib_tx
        IFNDEF DEBUG
         call    DLY160
        ENDIF

        movlw    lcd_A         ;Load 'A'
        call     nib_tx
        IFNDEF DEBUG
         call    DLY160
        ENDIF

        movlw    lcd_N         ;Load 'N'
        call     nib_tx
        IFNDEF DEBUG
         call    DLY160
        ENDIF

setint  nop
       BANK_1
       movlw    0x0D
       movwf    OPTION_REG
       BANK_0
       clrf     TMR0
       movlw    b'10011000'      ;Enable the interrupts
       movwf    INTCON
       clrf     flags            ;Initialise the flags

       goto    $                 ;Hold it here
       end

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\06@191809 by Ian Hynes

flavicon
face
PICers,

Sorry to be a pain but ...

OK, the only lead I've got, maybe, is the following pin levels
measured on the LCD after startup and 1st, 2nd interrupts. (LOW = 0V,
HIGH = 5V)

LCD PIN    STARTUP     KPD inpt "1"    KPD inpt "D"

EN        LOW         HIGH            HIGH
RS        HIGH        LOW             LOW
D4        LOW         HIGH            HIGH
D5        HIGH        LOW             LOW
D6        HIGH        LOW             LOW
D7        HIGH        HIGH            HIGH

LEDs       ALL OFF     ALL ON          ALL OFF

Hmm ... seems to me EN & RS orta be the same after start up AND after
the ISR : they both call the same LCD routines. Do we have a lead
here? On it .......

Cheers - Ian

PS: Just to reiterate, the programme is LCDTST01, subject of my last
post, pin configs as shown nin that post, KPD is 4x4, decoder is
74C922.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


'[PIC]: lcd problems with a pic16f877'
2001\02\13@103604 by cas Fenoll Molina

flavicon
face
part 1 2349 bytes content-type:multipart/alternative; (decoded quoted-printable)


------ 2001\02\13@105741 by Peter Betts
picon face
1: you need a "return" at the end of the lcd_data routine for a start  and  2: you also need a      "loop goto loop" or something to terminate the main loop properly
otherwise it just runs off into the init code again.
Pete

{Original Message removed}

2001\02\13@120304 by Bourdon, Bruce

flavicon
face
I would strongly suggest that you do a search of the piclist and review
methods employed by others - then decide the technique that best fits your
needs.

At a minumum:

As Pete said, you need a return from your "lcd_data routine" and your main
block runs into your "lcd_init" block - you shouuld loop back or stop, etc.

Your "lcd_delay" routine never initializes its delay count. While this may
function for all non-first time calls (rolls over from previous call) who
knows how long it will take the first time?

"lcd_data"  does not generate a transition to clock the data...

I my code I always have small delays between the clocking transitions (of
"E"), "lcd_com" and "lcd_data" only delay for one edge (assuming the
previous bug is corrected).

...etc...

Also:

You probably should power the LCD from power, not RA3 - or at the very least
make RA3 high early!

Assuming a standard HD44780 controller (email me if you want its' pdf
document) on the LCD pcb; after the LCDs has powered up, it is busy and
should not be interrupted for at least 15 MS. It is generally a good idea to
place initialization code in the PIC to bring the LCD into a good state in
case it didn't reset properly, and do this after a suitable delay (i.e. more
than 15ms)...

This is what I do (note that this is not exactly my code as port bits and
interface width differ from yours):

Initialization Sequence (for an 8 bit interface):
Power on

VCC rises to 4.5 V

Wait for more than 15 ms
Send (without checking the busy flag):
 RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
 0  0   0   0   1   1   *   *   *   *

Wait for more than 4.1 ms
Send (without checking the busy flag):
 RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
 0  0   0   0   1   1   *   *   *   *

Wait for more than 100 µs
Send (without checking the busy flag):
 RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
 0  0   0   0   1   1   *   *   *   *

Send (either after checking the busy flag or after delay):
 RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
 0  0   0   0   1   1   1   0   0   0   ; 8-bit mode, 2-lines, std font.

Send (either after checking the busy flag or after delay):
 RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
 0  0   0   0   0   0   0   0   0   1    ; clear display.

Send (either after checking the busy flag or after delay):
 RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
 0  0   0   0   0   0   0   1   1   0    ; return home.

Send (either after checking the busy flag or after delay):
 RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
 0  0   0   0   0   0   0   1   1   0    ; cursor inc (on) and shift (off).


Send (either after checking the busy flag or after delay):
 RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
 0  0   0   0   0   0   1   1   1   0    ; display-on, cursor-off,
blink-off.


{Original Message removed}

2001\02\13@121340 by Bourdon, Bruce

flavicon
face
OOPS, return home should be:
Send (either after checking the busy flag or after delay):
 RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0
 0  0   0   0   0   0   0   0   1   0    ; return home.
-Bruce.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\02\26@142718 by Oliver Broad

flavicon
face
Don't know if this has been suggested but enable (RA0) polarity appears to be wrong in your routine 'lcdcom'
 {Original Message removed}


'[PIC]: LCD problems revisited'
2001\03\06@200120 by Ian Hynes
flavicon
face
PICers,
Uh, another dumb question!

Refer to the snippet from Myke Predko's 2 wire LCD interface routine.
Can anybody please explain *exactly* what he's doing with his movf
FSR,w/incf FSR/call message routine?

I don't see how it "knows" to get the proper ascii characters. I mean
I've stepped it thru and see it moving round the Outloop in proper
order - but it's a complete blank how it's getting the characters. I'm
trying to figure out how to pass ascii to it as parameters.


Message                         ;  Message to Output
 addwf  PCL                    ;  Output the Characters
 dt     "Hello", 0

SendCHAR
 movwf  Temp                   ;  Save the Temporary Value
 ... SNIP ....
 return

...SNIP ....

clrf    FSR                    ;  Output the Message

OutLoop
 movf   FSR, w                 ;  Get the Offset to Output
 incf   FSR
 call   Message
 iorlw  0                      ;  At the End of the Message?
 btfsc  STATUS, Z
  goto  Loop                   ;  Yes - Equal to Zero
 call   SendCHAR               ;  Output the ASCII Character
 goto   OutLoop



Thanx - Ian

PS: Man, I promise if ever I get a handle on this LCD stuff, I'll put
it all up on a web page for all to see. What little I know ...

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\03\06@202834 by Wayne Hortensius

flavicon
face
At 11:57 AM 3/7/01 +1100, Ian Hynes <RemoveMEelekTakeThisOuTspamspamNETSTRA.COM.AU> wrote:
>Refer to the snippet from Myke Predko's 2 wire LCD interface routine.
>Can anybody please explain *exactly* what he's doing with his movf
>FSR,w/incf FSR/call message routine?

FSR is used (I think) as a convenient register for the into the offset and
not how you might think it's supposed to be used. Try this:

       offset (fsr) = 0
Outloop
       get current offset (fsr)
       increment offset
       call Message       ; with offset in w, returning char in w
.                          ; stuff to check for end of message
.                          ; and output the returned character
.
.
Message
       add offset value to current PC ; i.e. jump to (PC+W)
;       dt     "Hello",0   ; which translates to....
       retlw 'H'          ; return 'H' when W is 0
       retlw 'E'          ; return 'E' when W is 1
       retlw 'L'          ; return 'L' when W is 2
       retlw 'L'          ; return 'L' when W is 3
       retlw 'O'          ; return 'O' when W is 4
       retlw 0            ; return 0 when W is 5

Hope that just didn't muddy the waters more!

Regards,
Wayne

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body


2001\03\06@232320 by James Cameron

flavicon
face
On Wed, Mar 07, 2001 at 11:57:54AM +1100, Ian Hynes wrote:
> Refer to the snippet from Myke Predko's 2 wire LCD interface routine.
> Can anybody please explain *exactly* what he's doing with his movf
> FSR,w/incf FSR/call message routine?

Firstly, he's just using FSR as general purpose register.  Ignore the
fact for the moment that FSR is also used with INDF.  Myke isn't using
that feature of the register in his code that you quote.

> I don't see how it "knows" to get the proper ascii characters. I mean
> I've stepped it thru and see it moving round the Outloop in proper
> order - but it's a complete blank how it's getting the characters. I'm
> trying to figure out how to pass ascii to it as parameters.

Well, it calls the function at label Message repeatedly, first with
the W register set to zero, then with it set to one, etc.  The Message
function adds the W register to the PCL, thus causing a branch into
one of the "dt" bytes, which are actually RETLW instructions.

So, when Message is called first, it returns with 'H' in the W
register.  When it is called the next time it returns 'e', and so on.
This Message function is what we call a table.

Now, for a step by step explanation of the bit you pointed out ...

>  clrf    FSR                    ;  Output the Message

This might be better commented as "reset the offset into the message".
It sets the FSR register, which is used as an offset into the message.
If FSR is zero, then it is the 'H', and so on.

> OutLoop
>   movf   FSR, w                 ;  Get the Offset to Output

This loads the offset into the W register so that it can be used by
the table function Message.

>   incf   FSR

This increments the offset for next time around.  Without this, it
would scream along with lots of 'H' characters and would not move onto
the 'e'.

>   call   Message

This "translates" the offset into a character from the message, by
calling the table function.  The result is returned in the W register.

>   iorlw  0                      ;  At the End of the Message?

This is used to check if the returned value is zero.

>   btfsc  STATUS, Z
>    goto  Loop                   ;  Yes - Equal to Zero

If it was zero, the sending stops (it branches to a label Loop, which
you didn't show the code for).

>   call   SendCHAR               ;  Output the ASCII Character

If it was _not_ zero, then the SendCHAR function is used to send the
character that was returned by Message.

>   goto   OutLoop

Round and round until the zero is found.

> PS: Man, I promise if ever I get a handle on this LCD stuff, I'll put
> it all up on a web page for all to see. What little I know ...

That's the idea.  Had a look at mine?  I've just put up some really
nasty functions for handling tables.  http://quozl.netrek.org/

--
James Cameron    RemoveMEquozlKILLspamspamus.netrek.org     http://quozl.netrek.org/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservSTOPspamspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\03\07@090515 by Olin Lathrop

face picon face
{Quote hidden}

<rant>This is another example of why poorly documented code is worse than no
code.  Think of all the collective time that has now been wasted as a
result.  I doubt any benefit from this code will be enough to make up the
difference.</rant>

He is using the value in FSR as an index into the "Hello" string.  The DT
directive in MESSAGE produces a set of RETLW instructions, one for each
character in the string.  The ADDWF PCL instruction jumps ahead by the value
in W.  MESSAGE therefore takes a 0-N character index in W in, and returns
with the indexed character in W - just like the header comments for MESSAGE
should have clearly explained.

I don't know anything about this guy other than the code shown here.  Given
that, I advise staying away from any of his stuff.  People who write bad
code in one respect also tend to write bad code in another.  At best this
points to a "I don't give a crap" attitude.  At worst ...


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, spamBeGoneolinSTOPspamspamEraseMEembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


2001\03\07@121350 by Bill Westfield

face picon face
   <rant>This is another example of why poorly documented code is worse
   than no code.  Think of all the collective time that has now been
   wasted as a result.  I doubt any benefit from this code will be enough
   to make up the difference.</rant>

I don't think much time was wasted.  Someone didn't understand it, a bunch
of people did and explained it.


   He is using the value in FSR as an index into the "Hello" string.  The
   DT directive in MESSAGE produces a set of RETLW instructions, one for
   each character in the string.  The ADDWF PCL instruction jumps ahead
   by the value in W.  MESSAGE therefore takes a 0-N character index in W
   in, and returns with the indexed character in W - just like the header
   comments for MESSAGE should have clearly explained.


This is VERY VERY standard string handling for a PIC, isn't it?  Even I
figured it out pretty quick.  The only "weird" bit was the use of FSR as a
general purpose counter in the OutLoop (which doesn't seem to be what
you're complaining about.)  You don't document all your C string functions
with comments that the strings are null-terminated, or every PIC subtact
with comments about the carry bit being backward...

BillW

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamEraseMEmitvma.mit.edu


2001\03\07@142555 by Drew Vassallo

picon face
> > Refer to the snippet from Myke Predko's 2 wire LCD interface routine.
> > Can anybody please explain *exactly* what he's doing with his movf
> > FSR,w/incf FSR/call message routine?
> > Message                         ;  Message to Output
> >   addwf  PCL                    ;  Output the Characters
> >   dt     "Hello", 0

>The ADDWF PCL instruction jumps ahead by the value
>in W.  MESSAGE therefore takes a 0-N character index in W in, and returns
>with the indexed character in W - just like the header comments for MESSAGE
>should have clearly explained.

Olin is brutal!  But I agree for the most part.  I comment almost every line
(jesus, it only takes a second), plus a nice little paragraph or so by each
routine to explain its purpose.  Why NOT do this??

BEWARE OF THIS METHOD OF TABLE ADDRESSING!  You'll note that his "Message"
table is located at ORG 0x000.  This is the only reason that this method
works.  If you locate your tables in another memory location, like after the
ISR (ORG 0x004), or if you have multiple tables, a better way for simple
indexing is:

Message
       addlw   -(Message+2)    ; adjust index before continuing
       addwf   PCL, 1
dt "Hello", 0

Of course, there is also the PCLATH concern, which Myke ignores here because
of the short table and memory placement.  For using this simple method of
addressing the table characters, you'll have to ensure that the table
doesn't cross a page boundary.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu


2001\03\07@143358 by Bill Westfield

face picon face
   > > Message                         ;  Message to Output
   > >   addwf  PCL                    ;  Output the Characters
   > >   dt     "Hello", 0

   BEWARE OF THIS METHOD OF TABLE ADDRESSING!  You'll note that his
   "Message" table is located at ORG 0x000.  This is the only reason that
   this method works.  If you locate your tables in another memory
   location, like after the ISR (ORG 0x004), or if you have multiple
   tables, a better way for simple indexing is:
   Message
           addlw   -(Message+2)    ; adjust index before continuing
           addwf   PCL, 1
   dt "Hello", 0

huh?  How come?  It's adding to the PC, rather than moving to the PC.
Shouldn't that work anywhere (not counting PCLATH) ?

BillW

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamKILLspammitvma.mit.edu


2001\03\07@144055 by Drew Vassallo

picon face
>BEWARE OF THIS METHOD OF TABLE ADDRESSING!  You'll note that his "Message"

DOH!!  More like: Beware of misinformation from the author!  I was thinking
of his 3-wire example code where he "combined" two tables into one, and
preloaded W with the location of the section he wanted to recall.  The
information I gave in this post is incorrect; the table is fine the way he
has it, and you can put it anywhere (with the caveat of page boundaries).

BUT, if you want to put two tables into one location, then the information I
gave was correct.  For example, preload W with Ptr_1 literal, call Message,
then preload W with Ptr_2 literal, call Message again.

>Message
>        addlw   -(Message+2)    ; adjust index before continuing
>        addwf   PCL, 1
>Ptr_1:
>dt "Hello", 0
>Ptr_2:
>dt "Hello again", 0

My deepest apologies for the confusion.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspam_OUTspammitvma.mit.edu


2001\03\07@210802 by Olin Lathrop

face picon face
> This is VERY VERY standard string handling for a PIC, isn't it?  Even I
> figured it out pretty quick.  The only "weird" bit was the use of FSR as a
> general purpose counter in the OutLoop (which doesn't seem to be what
> you're complaining about.)  You don't document all your C string functions
> with comments that the strings are null-terminated, or every PIC subtact
> with comments about the carry bit being backward...

I don't mention the null terminator on C strings, but I do use my SKIP_WLE
and SKIP_WGT macros in part to make it easier to understand compares, but
that's not what I was complaining about either.  I thought the most blatant
omission was any documentation as to what the subroutine did from the
caller's point of view.  One shouldn't have to look at the code to figure
out what it does except in rare circumstances.  And yes, I *DO* put header
comments on all my subroutines that document this.  I also thought the
unusual use of FSR might have been worthy of a comment or two, and the fact
that the subroutine must not cross a 256 program memory address boundary.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, TakeThisOuTolin.....spamTakeThisOuTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestKILLspamspamspammitvma.mit.edu


2001\03\07@210840 by Olin Lathrop

face picon face
> huh?  How come?  It's adding to the PC, rather than moving to the PC.
> Shouldn't that work anywhere (not counting PCLATH) ?

As long as the table doesn't cross a 256 block boundary.  A more robust way
to do this is to do a full add and propagate the carry into PCLATH.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, .....olinspamRemoveMEembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu


'[PIC]: Code Commenting, was: LCD problems revisite'
2001\03\07@220506 by myke predko

flavicon
face
Hmmmm....

I guess I should have jumped in a bit earlier - I didn't think the emails
would get as angry as they did so quickly.

Thanx to James for taking the time to explain the code instruction by
instruction.


Looking over the code, I would probably format/document things differently -
but not that differently.  The (apparently) offending code (formatted for a
monospace font) is:

 clrf   FSR      ;  Output the Message
OutLoop
 movf   FSR, w   ;  Get the Offset to Output
 incf   FSR
 call   Message
 iorlw  0        ;  At the End of the Message?
 btfsc  STATUS, Z
  goto  Loop     ;  Yes - Equal to Zero
 call   SendCHAR ;  Output the ASCII Character
 goto   OutLoop

What is interesting is, that the following code, which is critical to the
entire operation of the function was not included in the quotes:

Loop              ;  Loop Forever when Done
 goto   Loop


;  Subroutines
Message           ;  Message to Output
 addwf  PCL      ;  Output the Characters
 dt     "Hello", 0



and I agree, that the first and last comments in the code above are
confusing and I probably should have improved them.  For the first comment,
I should have commented it as something like:

;  Output the "Message"
;  using the FSR as the
;  index into the table.

as using FSR is non-standard and probably not good practice if you are new
to working with the PICmicro.  I tend to use the FSR because of experiences
with early (GI) PICs where if you weren't using indexed addressing, FSR was
another file register for your use.

My only excuse to this is that the purpose of this code is to demonstrate
the two wire interface - not to demonstrate how to read from a table.

As for the last comment (";  Output the Characters"), I would probably
delete it as it really doesn't make any sense.

Other than that (other than adding ", f" to the end of the "incf FSR"
instruction) I would leave the code alone.


This brings up the question, how should code be "properly" documented?
Personally, I prefer minimal comments so that the operation of the code can
be seen easily without being distracted by comments.

My personal feeling is that if the code isn't written in such a way that if
you have to have it explained, then it can't be that
efficient/intuitive/helpful.  Going back to this case, I feel like I was
successful because a number of people were able to explain what the code was
doing.  On the other hand, I was unsuccessful as a "newbie" wasn't able to
understand what I was doing and got frustrated.


I was surprised at the comments regarding PCLATH with the table read - I
deliberately left the general case *out* to avoid making the code confusing.
Again, the primary purpose of this code was to demonstrate how to interface
with an LCD using two wires, NOT explain how to read from a table.


So, the overall question is, what is the *best* way of writing code to show
concepts to others?  I am very interested in this topic (and I have very
strong opinions on what is the best way to write/document/test code).

This was discussed four or so years ago on the list with a lot of anger and
finger pointing and really degenerated into a non-useful exercise.

To try and keep down the hard feelings and keep the conversation
constructive, I would ask that people present *good* examples of source
code/documentation only.  If you want to send me examples of what you think
is good code, I'll be more than happy to discuss it with you and I hope that
this could be something very positive for the PICList as well as everybody
on it.

myke

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu


'[PIC]: LCD problems revisited'
2001\03\08@084046 by Bob Ammerman

picon face
----- Original Message -----
From: Olin Lathrop <TakeThisOuTolin_piclistspamspamEMBEDINC.COM>
To: <PICLISTEraseMEspamMITVMA.MIT.EDU>
Sent: Wednesday, March 07, 2001 6:49 PM
Subject: Re: [PIC]: LCD problems revisited


> > huh?  How come?  It's adding to the PC, rather than moving to the PC.
> > Shouldn't that work anywhere (not counting PCLATH) ?
>
> As long as the table doesn't cross a 256 block boundary.  A more robust
way
> to do this is to do a full add and propagate the carry into PCLATH.

I prefer _NOT_ to carry into PCLATH, especially for short tables. Instead, I
put 'guards' around the code to generate an assembler error if the table
spans a page boundary. It seldom does, and when it happens I usually just
shuffle the code around a bit to solve the problem.

I often explicitly place large tables on a page boundary with an ORG.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


'[PIC]: Code Commenting, was: LCD problems revisite'
2001\03\08@090545 by Olin Lathrop

face picon face
{Quote hidden}

can
> be seen easily without being distracted by comments.

Comments are there to help, not distract.  If everything is properly and
consistantly formatted then they are not "in the way" if you prefer to
ignore them.  To facilitate this, I consistantly use column 10 for opcodes,
18 for parameters, and 30 for comments.  I admit I haven't found a good way
to deal with assembly directives.

> So, the overall question is, what is the *best* way of writing code to
show
> concepts to others?  I am very interested in this topic (and I have very
> strong opinions on what is the best way to write/document/test code).

Since you asked, here is how I would write and format this code:


;
;   Write the message to the display.
;
        clrf    fsr         ;init message index
outloop  unbank              ;back here each new message character
        movf    fsr, w      ;get the index for this character
        incf    fsr         ;increment the index for next time
        mcallr  message, reg0 ;get the indexed message char in REG0
        movf    reg0        ;set Z if this char is null terminator
        skip_nz             ;got valid message char, not terminator ?
        goto    loop        ;done writing the message
        gcall   sendchar    ;send char in REG0 to the display
        goto    outloop     ;back to do next message character
;
;********************
;
;   Local subroutine MESSAGE
;
;   Return the indexed message character in W.  The 0-N character
;   index is in FSR, which is preserved.
;
message  locsub, noregs
        movlw   low msg     ;get low byte of table start address
        addwf   fsr, w      ;make table entry address low byte
        skip_ncarr          ;propagate carry to high address byte
        incf    pclath
        movwf   pcl         ;jump the the selected table entry

msg      dt      "Hello"     ;the message string to send
        dt      0           ;string terminator


This isn't exactly the same code you wrote.  I modified it slightly to fit
the way I write PIC code, which includes my bank switching and subroutine
linkage conventions.  I made the assumption that this code was neither speed
critical nor extremely tight on space (as is the case with 95% or more of
all code).  It is therefore far more important to make it robust and
maintainable than super fast and small.  For example, 256 word program
memory boundaries can now be ignored, which was not the case for your code.
Someone can come by in two years and add code above this snippet without
having to worry.  The only restriction is that all this code be on the same
code page.  I use linker sections to guarantee that all code within a module
is on the same page.  If I was writing this from scratch, I would have used
general table fetching subroutines, but it would have been messy to include
the source for them here.  I haven't tried to assemble this snippet above,
so it may contain typos, etc.

All the macros, general registers, and subroutine linkage conventions I used
above are defined in file STD.INS.ASPIC which can be found at
http://www.embedinc.com/pic.

And yes, I really do write all my code with this same general style and
level of commenting.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, RemoveMEolinEraseMEspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\08@093318 by Olin Lathrop

face picon face
{Quote hidden}

I just realized that I changed the subroutine to take FSR as the index (as
documented), but forgot to go back and update the calling code.  Oh well,
that's what I get for letting people see my untested code.  However, the
point of this code was the documentation style, which is still valid.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, @spam@olinRemoveMEspamEraseMEembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


'[PIC]: LCD problems revisited'
2001\03\08@093327 by Olin Lathrop

face picon face
> I prefer _NOT_ to carry into PCLATH, especially for short tables. Instead,
I
> put 'guards' around the code to generate an assembler error if the table
> spans a page boundary. It seldom does, and when it happens I usually just
> shuffle the code around a bit to solve the problem.
>
> I often explicitly place large tables on a page boundary with an ORG.

Sounds reasonable enough.  However note that this method isn't available if
using the linker.

I use the linker and diddle PCLATH.  The extra few instructions and cycles
are usually insignificant in the scheme of things and are usually well worth
the maintainability.  In dozens of PIC projects I can only remember one case
off the top of my head where speed was critical.  I was doing a table lookup
in the interrupt routine, so I used the CODE directive to start the table at
the last 256 word block in code page 0.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, EraseMEolinspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\08@104021 by Scott Dattalo

face
flavicon
face
On Thu, 8 Mar 2001, Olin Lathrop wrote:

> > I prefer _NOT_ to carry into PCLATH, especially for short tables. Instead,
> I
> > put 'guards' around the code to generate an assembler error if the table
> > spans a page boundary. It seldom does, and when it happens I usually just
> > shuffle the code around a bit to solve the problem.
> >
> > I often explicitly place large tables on a page boundary with an ORG.
>
> Sounds reasonable enough.  However note that this method isn't available if
> using the linker.

Actually, it becomes quite unreasonable in practice (my practice that is). I
agree with you (Olin) that dinking with PCLATH is a good trade off in speed vs
maintainability. Since we're talking about comments/lcd string stuff, here's
mine (which can be found http://www.dattalo.com/gnupic/lcd.html in the gpsim
module lcd-0.1.1.tar.gz):

;*******************************************************************
;write_string
;
;  The purpose of this routine is to display a string on the LCD module.
;On entry, W contains the string number to be displayed. The current cursor
;location is the destination of the output.
;  This routine can be located anywhere in the code space and may be
;larger than 256 bytes.
;
; psuedo code:
;
; char *string0 = "foo";
; char *string1 = "bar";
;
; char *strings[] = { string0, string1};
; char num_strings = sizeof(strings)/sizeof(char *);
;
; void write_string(char string_num)
; {
;   char *str;
;
;   str = strings[string_num % num_strings];
;
;   for( ; *str; str++)
;     LCD_WRITE_DATA(*str);
;
; }
;
; Memory used
;    buffer2, buffer3
; Calls
;    LCD_WRITE_DATA
; Inputs
;    W = String Number
;


This is just the comments for the header. I agree with Myke's commenting
philosophy of not over commenting the individual pic instructions. Instead, a
verbose description up front helps describe the intention well enough that
during debugging I often don't need to probe into the details.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


'[PIC]: Code Commenting, was: LCD problems revisite'
2001\03\08@104439 by Bruce Smith

picon face
Olin,
Wow as a newbie, your code is very understandable. Do you have a site with
more of that style code.

{Original Message removed}

2001\03\08@105445 by David VanHorn

flavicon
face
>> message  locsub, noregs
>>          movlw   low msg     ;get low byte of table start address
>>          addwf   fsr, w      ;make table entry address low byte
>>          skip_ncarr          ;propagate carry to high address byte
>>          incf    pclath
>>          movwf   pcl         ;jump the the selected table entry
>>
>> msg      dt      "Hello"     ;the message string to send
>>          dt      0           ;string terminator


The key point that I see here, is that the comments should say WHY you're
doing what you're doing, as they do here.
Any idiot can read the ASM code, but IMHO, the comments should provide the
reasoning behind the code.


--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\08@110855 by Sam Linder

flavicon
face
I agree with both Olin and Scott regarding the level of documentation that
should be present in both C and ASM programs. There should be an overall
description of what the chunk of code is doing and there should also be line
by line comments as necessary to help clarify what each part of the code is
doing (especially in ASM). For my money, I would always rather have too many
comments than not enough. Too many "guru's" out there think their code is so
"self-documenting" that they are blind to the fact that no one else can
initially understand it without a careful perusal of each line of code.

{Original Message removed}

2001\03\08@111659 by David VanHorn

flavicon
face
At 08:08 AM 3/8/01 -0800, Sam Linder wrote:
>I agree with both Olin and Scott regarding the level of documentation that
>should be present in both C and ASM programs. There should be an overall
>description of what the chunk of code is doing and there should also be line
>by line comments as necessary to help clarify what each part of the code is
>doing (especially in ASM). For my money, I would always rather have too many
>comments than not enough. Too many "guru's" out there think their code is so
>"self-documenting" that they are blind to the fact that no one else can
>initially understand it without a careful perusal of each line of code.


Written Chinese is also self-documenting. :)
--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\08@121457 by Douglas Wood

picon face
Having spent some time in China writing code for a "Hot Box" detector system
for trains that had to display Chinese characters in addition to English,
it's fair to say that NONE of the Chinese that *I* wrote was
"self-documenting"! :-)

Douglas Wood
Software Engineer
@spam@dbwoodspam_OUTspam.....kc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://www.piclist.com/techref/member/DW--RA4

{Original Message removed}

2001\03\08@122156 by David VanHorn

flavicon
face
At 11:19 AM 3/8/01 -0600, Douglas Wood wrote:
>Having spent some time in China writing code for a "Hot Box" detector system
>for trains that had to display Chinese characters in addition to English,
>it's fair to say that NONE of the Chinese that *I* wrote was
>"self-documenting"! :-)

It's self-documenting if you already know what it says.
Something like "cart hot, pu hao!" ?
:)

--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\08@123741 by Douglas Wood

picon face
On the other hand, I didn't make any disparaging remarks about anyone's
mother, either!! ;-)

Douglas Wood
Software Engineer
spamBeGonedbwoodEraseMEspamkc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://www.piclist.com/techref/member/DW--RA4

{Original Message removed}

2001\03\08@210623 by Olin Lathrop

face picon face
> Wow as a newbie, your code is very understandable. Do you have a site with
> more of that style code.

See http://www.embedinc.com/pic.  There is a lot more code I intend to add
to it eventually.  For now, there is an extensive set of macros I use for
PIC development.  These include bank switching, general registers, a
software stack, subroutine linkage, and some other tidbits.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinspamBeGonespamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\08@214543 by Ian Hynes

flavicon
face
PICers,

I'd just like to say a word of thanks to the guys who offered advice
on LCDs. Along with a lot of hot air there's a few gems of REALLY
USEFUL information on this list.

Ian.


myke predko wrote:
>
> Hmmmm....
>
> I guess I should have jumped in a bit earlier - I didn't think the emails
> would get as angry as they did so quickly.
>
>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\22@130918 by Bill Westfield

face picon face
{Quote hidden}

This thread died out a long time ago, but as long as I'm picking on Olin, I
thought I'd say that I find this example over-commented (and the comments
over-wordy, too.)  It's not so bad in this rather simple example, but I'd be
very worried that in code that has some algorithmic complexity, that the
"important" comments for the tricky parts would be lost in the general
busy-ness of text.  Even here, we have:

>             skip_ncarr          ;propagate carry to high address byte
>             incf    pclath

Manipulation of PCLATH, perhaps one of the most confusing aspects to a PIC,
and NO COMMENT!?  As a non-experienced PIC programmer, "incf" was a bit
shocking (but I guess I see how it works - pclath has to be "current" to
have gotten to the subroutine...)  Some of the non-obvious macros were a bit
disconcerting as well, but I guess they're OK since they're likely to be
commented to Olin's standards as well...

BillW

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-request@spam@spamspamBeGonemitvma.mit.edu


2001\03\22@155923 by Olin Lathrop

face picon face
> This thread died out a long time ago, but as long as I'm picking on Olin,
I
> thought I'd say that I find this example over-commented (and the comments
> over-wordy, too.)  It's not so bad in this rather simple example, but I'd
be
> very worried that in code that has some algorithmic complexity, that the
> "important" comments for the tricky parts would be lost in the general
> busy-ness of text.

I think this is part of a more general issue of comment scope.  It is just
as important to document the details in "algorithmically complex" code as it
is in any other code.  However, what you really want is comments with
varying scope.  In other words, I want to write a paragraph that applies to
the next 80 lines, but within that maybe three separate paragraphs that each
apply only to a subsection of the 80 lines, etc, etc.

Most languages allow end of line comments and separate lines that contain
only comments.  This easily allows for two levels, but that is often not
enough.  I usually put a line of stars above higher level comments.
Sometimes a long "bar" above very high level comments with shorter bars
above lower level comments, but this is easily lost on those not familiar
with the convention.  Nonetheless, I think it is still better than not
trying at all.  For example:

;
;************************************************************************
;
;   Subroutine DOIT
;
;   High level comment that applies to the whole subroutine.
;
    add   this          ;explain what/why, applies only this line or next few
    stuff that
    blah  counter, w
;
;******************
;
;   The approriate number is in COUNTER.  Now puflbloob the
;   frammistan.
;
    poof  counter
    bark  @tree
    ;
    ;   This comment applies just to the following section until the next
    ;   whole line comment of any type.
    ;

If you do this consistantly others will be able to follow once they get used
to the style.  I still wish there was a way built into the language to
declare the scope of a comment without impeding readability, but there
isn't.

> Even here, we have:
>
> >             skip_ncarr          ;propagate carry to high address byte
> >             incf    pclath
>
> Manipulation of PCLATH, perhaps one of the most confusing aspects to a
PIC,
> and NO COMMENT!?  As a non-experienced PIC programmer, "incf" was a bit
> shocking (but I guess I see how it works - pclath has to be "current" to
> have gotten to the subroutine...)

Now let's be fair, Bill.  If you include the line right above these two, you
will see what I really wrote was:

           addwf   fsr, w      ;make table entry address low byte
           skip_ncarr          ;propagate carry to high address byte
           incf    pclath

This is an add that produces something referred to as a "low byte", followed
by "propagate carry", which in this case takes two instructions.  I don't
think it is the job of comments to explain the opcodes, except perhaps when
unusual side effects are being used.  Comments are better spent describing
the PURPOSE of the opcodes, like doing an add to create the low byte and
then propagating the carry.

> Some of the non-obvious macros were a bit
> disconcerting as well, but I guess they're OK since they're likely to be
> commented to Olin's standards as well...

Yes, they are.  See STD.INS.ASPIC at http://www.embedinc.com.  You can even
use them yourself.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olin@spam@spamEraseMEembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestRemoveMEspammitvma.mit.edu


2001\03\22@192718 by Bill Westfield

face picon face
   I think this is part of a more general issue of comment scope.  It is
   just as important to document the details in "algorithmically complex"
   code as it is in any other code.  However, what you really want is
   comments with varying scope.  In other words, I want to write a
   paragraph that applies to the next 80 lines, but within that maybe three
   separate paragraphs that each apply only to a subsection of the 80 lines

Agreed.


   Most languages allow end of line comments and separate lines that contain
   only comments.  This easily allows for two levels, but that is often not
   enough.

Sometimes this is done with separate source files.

It occurs to me, though, that perhaps the biggest commenting lack I've seen
in "embedded microcontroller" documentation/commenting is a sort of
"bibliography" of the datasheets and other info used to put together the
code and algorithms.  It's GREAT to know something like "as described in
Microchip Applications-note AN1234", or "As per Knuth V3pp134-137" for
instance.



   Now let's be fair, Bill.  If you include the line right above these
   two, you will see what I really wrote was:

               addwf   fsr, w      ;make table entry address low byte
               skip_ncarr          ;propagate carry to high address byte
               incf    pclath

Right, but what was confusing me was that I didn't see how you could be
sure that pclath contained a value that pointed to the current section
of code.  You only set it before explicit page changes, and there are
other ways to get to a new code page, right?  I was assuming that your
"call" macro set pclath in order to call "message", so you could be
confident it was right, but maybe this is just a bug waiting to happen :-)


   I don't think it is the job of comments to explain the opcodes, except
   perhaps when unusual side effects are being used.

Agreed.  This is one of the differences between commenting code for
educational purposes vs documenting "real" code, though.  If you're posting
an example of PIC code as an education in PIC programming, your comments
will look a bit different than they will if you're posting DFT code for
purposes of explaining how to implement a DFT...

BillW

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestSTOPspamspam@spam@mitvma.mit.edu


2001\03\23@081204 by Olin Lathrop

face picon face
> Right, but what was confusing me was that I didn't see how you could be
> sure that pclath contained a value that pointed to the current section
> of code.  You only set it before explicit page changes, and there are
> other ways to get to a new code page, right?  I was assuming that your
> "call" macro set pclath in order to call "message", so you could be
> confident it was right, but maybe this is just a bug waiting to happen :-)

I use the convention that PCLATH always points to the current code page.
Yes, this IS documented, but elswhere.  Of course you couldn't have known
that, but I was trying to demonstrate commenting style, and not deeply
explain the code.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinEraseMEspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\23@090912 by Bob Ammerman

picon face
> I use the convention that PCLATH always points to the current code page.
> Yes, this IS documented, but elswhere.  Of course you couldn't have known
> that, but I was trying to demonstrate commenting style, and not deeply
> explain the code.

Olin,

I understand how it is easy to ensure that PCLATH matches the current
256-byte code page on entry to a routine and by resetting it after a call,
but how do you handle the case where there is a 256 byte boundary between
the entry point and where you do a computed jump?

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\23@123913 by Olin Lathrop

face picon face
> I understand how it is easy to ensure that PCLATH matches the current
> 256-byte code page on entry to a routine and by resetting it after a call,
> but how do you handle the case where there is a 256 byte boundary between
> the entry point and where you do a computed jump?

You load PCLATH with the high byte of the table start address, which I
forgot to do in the example.  Oops.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinspamspamBeGoneembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\23@130411 by Harold M Hallikainen

picon face
On Thu, 22 Mar 2001 16:26:43 PST William Chops Westfield
<spamBeGonebillwKILLspamspam@spam@CISCO.COM> writes:
> It occurs to me, though, that perhaps the biggest commenting lack
> I've seen
> in "embedded microcontroller" documentation/commenting is a sort of
> "bibliography" of the datasheets and other info used to put together
> the
> code and algorithms.  It's GREAT to know something like "as
> described in
> Microchip Applications-note AN1234", or "As per Knuth V3pp134-137"
> for
> instance.
>
>

       I try to do this. It's often the URL of a specific post in the PICLIST
archive...

Harold


FCC Rules Online at http://hallikainen.com/FccRules
Lighting control for theatre and television at http://www.dovesystems.com

________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
dl.http://www.juno.com/get/tagj.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\23@131838 by Bob Ammerman

picon face
----- Original Message -----
From: Olin Lathrop <olin_piclistspam_OUTspam@spam@EMBEDINC.COM>
To: <spamBeGonePICLIST@spam@spamMITVMA.MIT.EDU>
Sent: Friday, March 23, 2001 12:27 PM
Subject: Re: [PIC]: Code Commenting, was: LCD problems revisited


> > I understand how it is easy to ensure that PCLATH matches the current
> > 256-byte code page on entry to a routine and by resetting it after a
call,
> > but how do you handle the case where there is a 256 byte boundary
between
> > the entry point and where you do a computed jump?
>
> You load PCLATH with the high byte of the table start address, which I
> forgot to do in the example.  Oops.

Yeah, I thought it was something like that.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\03\23@134409 by jamesnewton

face picon face
One of the best (although sometimes painful) things about this list is the
way that any code you post with a dumb mistake in it is instantly torn
apart... <GRIN> Mostly in a nice way.

Anyone who hasn't read "the Cathedral and the Bazaar" should find the time
to do so...
http://www.tuxedo.org/~esr/writings/cathedral-bazaar/

This IS our tribe.

---
James Newton (PICList Admin #3)
RemoveMEjamesnewtonEraseMEspamKILLspampiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}


'[Pic:] LCD Problems'
2004\06\01@060717 by Jason S
flavicon
face
I'm trying to run an LCD from a pic for the first time, and I can't get any response out of it.

I'm using a 16F628, and basically the same wiring and program as in the book Pic'n up the Pace.  Everything appears to be working from the PIC end, but the display is completely blank; it looks the same as when it's not receiving power.

Usually when an LCD is powered, you can see some shadow even where the segments are turned off, and I don't have that, so I think I'm doing something basic wrong.  The contrast input is grounded, but I also tried connecting it to Vcc.  I'm working in 8-bit mode.

I've tried with 2 different displays from 2 different sources.  One has an HD44780 driver and the other an HD66702.

I'd appreciate any suggestions about what might be the problem.

Thanks,
 Jason

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\06\01@061547 by Jan-Erik Soderholm

face picon face
What does the data sheet says about the contrast adjustment ?
And have you done whatever the data sheet says about that?

Jan-Erik.

Jason S wrote :

{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\06\01@063244 by Jason S

flavicon
face
The one with the HD66702 is an Optrex 50218.  The datasheet says the LCD
driving voltage (what I was calling contrast) is Vcc - Vee.  In my case, Vcc
is 4.6V - I'm doing this from 3 AA batteries - and Vee is ground.  The
datasheet says Vcc - Vee should be 4.2 - 4.8V.  It does seem like I'm
complying with the datasheet there.

The other display has the number 20324 on it.  I can't find out much about
it; Optrex does have a 20434 that seems to be a 4-line version of the 2-line
20324.  Pin 1 is probably ground on the 20324 because it's connected to the
metal bezel.

Jason

{Original Message removed}

2004\06\01@064943 by Jan-Erik Soderholm

face picon face
Jason S wrote :

> The one with the HD66702 is an Optrex 50218.  The datasheet
> says the LCD driving voltage (what I was calling contrast) is
> Vcc - Vee.  In my case, Vcc is 4.6V - I'm doing this from 3 AA
> batteries - and Vee is ground.  The datasheet says Vcc - Vee
> should be 4.2 - 4.8V.  It does seem like I'm complying with the
> datasheet there.

You can not be sure that the *correct* contrast adjusment
voltage is *either* Vcc *or* Vdd. It could be somewhare between
them.

Use a pot (10k usualy works) so you actualy can *adjust* the
voltage...

Jan-Erik.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\06\01@070018 by Jinx

face picon face
> is 4.6V - I'm doing this from 3 AA batteries - and Vee is ground.  The
> datasheet says Vcc - Vee should be 4.2 - 4.8V.  It does seem like I'm
> complying with the datasheet there.

It does, although LCD readability on the ones I use drops off very quickly
if you dip below 5V, but it is discernably on. As you say, you can tell
where
the character positions are even on a cleared display

Usually on an LCD with just Vcc, Vee and Contrast grounded you'd see
either the top line on eg 2-line or first 8 characters on a 1-line as black
blocks before initialisation

If you're unsure about the connections you'd be able to trace them back
to the HD44780/HD66702, with reference to their respective data sheets

I hope you've not wired Vcc andd Vee back-to-front at some stage. IME
that's usually death to an LCD. But even dead they'll often look like an
uninitialised display, except the logic is buggered

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\06\01@070847 by Jason S

flavicon
face
I just tried that, I was carful to turn the pot slowly, and I even watched
the voltage change on my DMM, but I didn't see any sign of life on the
display.

Jason

{Original Message removed}

2004\06\01@071510 by Jinx

face picon face
I think you're running under-voltage. According to the d/s

http://www.optrex.com/SiteImages/PartList/SPEC/50218aae.pdf

Vcc is a standard 5.0 +/- 0.5. 4.6V is cutting it fine, although with
3 new batteries @ 1.65V you'd be at 4.95V

As defined in the d/s

Vcc is supply voltage
Vss is ground
Vee is Contrast

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\06\01@072544 by Jason S

flavicon
face
Just connecting power was a good idea.  On the 44780 one, the top line was
very faintly darkened (that's the one I don't have the datasheet for, maybe
it needs more than 6V?), on the 66702, there were vertical stripes across
both rows of characters very dark in a random looking pattern.

With the displays in circuit, I measure the same voltages at Vcc, Vee, and
ground as out of circuit, but they looked unpowered.  I looked very
carefully at the 44780 since it was so faint out of circuit, but I didn't
see anything.

Jason

{Original Message removed}

2004\06\01@073207 by Jan-Erik Soderholm

face picon face
Jason S wrote :

> With the displays in circuit, I measure the same voltages at
> Vcc, Vee, and ground as out of circuit, but they looked unpowered.

What does "out of circuit" meen ?
*What* "looked unpowered" ? All three ? Or just "ground"

"Ground" is "ground" and should be connected to "ground"...

Am I completly missunderstanding you ?

Exactly to what have you connected the ground on the LCD ?

Or better, exactly how have you connected *ALL* pins on the LCD ?

Jan-Erik.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\06\01@074241 by Jason S

flavicon
face
Out of circuit in this case means just Vcc on the display connected to + on
the battery pack, Vee, and Gnd on the display connected directly to - on the
battery pack and all other connections left unconnected.

In circuit is Vcc and R/W connected to the + bus on my breadboard, Gnd
connected to the - bus, Vee connected to the wiper of the pot (connected
across the power supply), RS, E, and D0-D7 connected to the PIC.

What I meant by "looked unpowered" is there is no shadow of active LCDs that
shows up even even a powered LCD is set to blank.

For my in circuit measurements, I meant "ground" on the display was showing
up as 0 volts relative to "ground" on my power source; the circuit wasn't
screwing that up.  I also read the same voltage at the positive terminal of
my power source at "Vcc" on the display and the wiper of the pot at Vee.

Jason

{Original Message removed}

2004\06\01@074655 by Jinx

face picon face
> maybe it needs more than 6V ?

The HD44780 and HD66702 (an HD44780 equivalent) are both
intended for 5V systems. Please do not use more than 5.5V in
normal operation. It would be preferable to use a regulated 5V for
repeatable results. Once you have the supply sorted out then you'll
be able to use one of the many 44780 initialisation routines around.
The main thing to do first is not kill the LCDs ;-)

> > I hope you've not wired Vcc and Vee back-to-front at some stage

BTW, I meant Vcc and Vss

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\06\01@094920 by Mike Hord

picon face
Are you certain these LCDs were even good in the first place?

I've wasted hours on LCDs that aren't, simply due to a
dogged determination not to "waste" an otherwise
"perfectly good" component.  It took me a while to realize
that I'm only "wasting" anything if I spend six hours messing
with an obviously bad component.

My advice:  get a known good LCD (from wherever- Jameco
and bgmicro have some good prices to start) and see if it is
any better behaved.  And this time, make DARN sure you
don't cross Vdd and Vss.

Mike H.

{Quote hidden}

_________________________________________________________________
Watch LIVE baseball games on your computer with MLB.TV, included with MSN
Premium! http://join.msn.click-url.com/go/onm00200439ave/direct/01/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\06\01@163033 by Jason S

flavicon
face
I haven't reversed Vcc and Vss, but I did get the LCDs as new surplus; it's
possible they were pre-damaged as Mike Hord suggested.  I just find it
surprising that both from different sources are.

Thanks for your help.

 Jason

{Original Message removed}

2004\06\01@175046 by Dave Lag

picon face
Any chance they are extended temperature ones that need a negative bias?
Guess that's the last thing to try after you have mentally written them off...
Dave



At 04:34 PM 6/1/04, you wrote:
>I haven't reversed Vcc and Vss, but I did get the LCDs as new surplus; it's
>possible they were pre-damaged as Mike Hord suggested.  I just find it
>surprising that both from different sources are.
>
>Thanks for your help.
>
>   Jason

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\06\01@181049 by Jason S

flavicon
face
It's possible that they are; that might explain why it was so faint when I
applied power to Vcc, Vee, and Vss.  Shouldn't I still see the faint text
even without a higher driving voltage though?

Is there any way of looking up obscure or discontinued displays?  Searching
on google just finds a couple of matches in the LCD discussion forum from a
few years ago that don't have any information.

Jason

{Original Message removed}

2004\06\01@192629 by Jinx

face picon face
> Is there any way of looking up obscure or discontinued displays?

You could try these

http://www.woe.onlinehome.de/e_index.htm

http://www.eio.com/public/lcd

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\06\01@194043 by Jason S

flavicon
face
With 6V at Vcc, and Vss/Vee grounded, the top line is quite a bit darker,
enough to be easily noticible but probably still to faint to use in a
project.

When I connect it to the circuit at 6V, both rows are on but much more
faintly.

It seems like something in the initialization is working.  I think the dark
top line is supposed to have all the dots on in an uninitialized state, and
both rows more faint is supposed to have all the dots off.  I am setting it
to a blinking cursor and trying to print text to the display but I don't see
that showing up at all.

In all cases, the second row of dots from the bottom of each character
stayed completely off, so it is possible the display is damaged.

Jason

{Original Message removed}

2004\06\01@221838 by Mike Hord

picon face
>It's possible that they are; that might explain why it was so faint when I
>applied power to Vcc, Vee, and Vss.  Shouldn't I still see the faint text
>even without a higher driving voltage though?

No.  If it's a high contrast LCD designed to have a negative contrast
voltage applied, even with it tied to zero you'll not see anything on
there.  I almost threw one out once as broken before I checked for
that...It doesn't take much drive below zero to get some good
contrast; one cell might help it.

Mike H.

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar   get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\06\02@012711 by Jason S

flavicon
face
I've gotten a bit further now.
The problem was the IO pin on the pic I was using for the RS line was stuck
high.  I've replaced the pic, but I had to use a 12F675 with a 74164 shift
register since it's the only other pic I have now (I bought a bunch of
12F675's and 16F628A's in my last parts order and I can't use the 628A's in
my un-upgraded picstart plus.  I have some 16F628's on order that I know
will work.

Also, this is with the whole system powered off 4 new AA batteries.  With 3,
the display is on, but too faint to tell what it's showing.  With 4 it's
clearly visable but I'd prefer it darker in a live application.

I can make it display characters but some of them are shifted by one letter
in either direction.

For example 'Hello World!' becomes 'Hfllo Woqld"' and 'Jason' becomes
'Ibsom'.

I've looked at the binary values of the ascii characters and it doesn't look
like there's any specific bit that's not getting through.

My code to output a letter is:
 MOVLW 'H'           ; display a letter
 CALL SER_OUT
 CALL PULSE

SER_OUT puts the byte on the shift register which is connected to the data
lines and then waits 125 microseconds.

PULSE raises the E line, waits 125 microseconds, then lowers it and waits 5
milliseconds.

I'm using long time delays to try and make sure the problem is not too short
a delay.

Jason

{Original Message removed}

2004\06\02@024011 by Jason S

flavicon
face
Disregard this message.  I had the wires to D0 and D1 swapped, everything is
working fine now.

Thanks to everyone for your help.

Jason

{Original Message removed}


'[SX] serial lcd problems...... want command like b'
2005\08\12@073247 by Johnson Rodn/a
flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Johnson Rod wrote:

did you try other baud rates to see if you get the same results, try N9600?

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=84123#m84133
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)

2005\08\12@073939 by beann/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, bean wrote:

Make sure you have the FREQ specified correctly or your baud rate will not generated properly.
Can you attach the complete program ?
Bean.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=84123#m84134
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)

2005\08\12@091602 by Jon Williamsn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Jon Williams wrote:

[Quoting: "Sawmiller"]
hi y'all

<snip>

i know it should be consistant.. also i cant seem to write to the screen any letters and  such and have them be the same all the time...

i think it has to do with the serout command, because the same lcd , hooked up to a bs2 works fine... or could it be that the sx just talks too fast ???
:hop:  anyways the reason i started this thread is a sugestion for the next rev of SXB i would like a command that would  open up a screen on the pc and i could output regular text to it to test my apps.

<snip>

dan ( dazed and confused )

Sorry, there will be no Debug window (BASIC Stamp style) in the SX-Key IDE; you'll need to connect a serial port and send data through that connection (using SEROUT).  The BASIC Stamp has that kind of port because it uses a generic serial connection for programming -- there is no way to send serial data back up the SX-Key.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=84123#m84147
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)

2005\08\12@112438 by Sawmillern/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Sawmiller wrote:

bummer on no easy to use , text output.....


dont understand the freq command that you asked about... its set to the default template

as for the baud rate , the lcd's default is 2400, would have to jumper across the lcd to get 9600
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=84123#m84164
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)

2005\08\12@113752 by beann/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, bean wrote:

Are you are using the internal 4MHz clock ? If so it is NOT accurate enough for serial communications.
Use a resonator and change the DEVICE line as needed.
Bean.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=84123#m84165
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)

2005\08\12@115950 by Sawmillern/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Sawmiller wrote:

ahhh i seee , ok will try that, thanks bean
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=84123#m84169
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)

2005\08\12@125305 by Johnson Rodn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Johnson Rod wrote:

saw,
the jumper is easy to install, on my ilm-216 test rig  i soldered a small jumper from pin 6 to pin 8 on the lcd. a small price to pay for a faster refresh rate.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=84123#m84170
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)

2005\08\12@131744 by Sawmillern/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Sawmiller wrote:

thanks bean, put a 50 mhz resonator there and its reliable... can turn on and off backlight, do serout individual chars... great

still havent got that tx_byte routine to work, gives me garbage on screen... but at least what i get is what i tell it to  :p  

will go and solder that jumper in,faster is better , no ?


thanks for the advice folks...

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=84123#m84172
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)

2005\08\12@145830 by Johnson Rodn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Johnson Rod wrote:

here'e some code that i'm working with right now. it reads proper through a max232 to hyperterminal.
try it. its modular!

'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SetBuffer:
' Sets the buffer for transmition
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 PUT buffer(0), "H", "E", "L", "L", "O"
 RETURN

'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TXBYTE:
' transmits a single byte
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ax = __PARAM1                              ' char to send
 SEROUT txPin, Baud, ax                      ' send the character
 RETURN

'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Broadcast:
' transmits entire buffer
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 FOR idx = 0 TO 4
   TXBYTE buffer(idx)                                ' transfer buffer
 NEXT
 dirPIN = 0
 RETURN
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=84123#m84179
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)

2005\08\13@033854 by Sawmillern/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Sawmiller wrote:

thnks nick , that snippet o code works good.. guess i will put my string variables in that way. the DATA/READ commands dont seem to work right for me..


progress  :yeah:

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=84123#m84222
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)

2005\08\13@051857 by beann/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, bean wrote:

READ is definately the way to send data to the LCD. With the latest version of SX/B (1.41) you can do stuff like:

TXSTR "Hello there!"
Or
Message:
 DATA "Hello There!",0
TXSTR Message using code such as:
'-----------------------------------------------------
TXSTR SUB 2 ' String parameter counts as 2
TXSTR:
 TempOffset = __PARAM1
 TempBase = __PARAM2
 DO
   READ TempBase+TempOffset, TempChar
   IF TempChar = 0 THEN EXIT
   TXBYTE TempChar
   INC TempOffset
   TempBase = TempBase + Z ' Adjust base if offset overflows
 LOOP
 RETURN
'-----------------------------------------------------
Bean.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=84123#m84225
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)

2005\08\15@063625 by Johnson Rodn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Johnson Rod wrote:

yeah i definately agree with bean. if you're storing pages of text the most efficient solution is definately read, that snippetts from a tranceiver network where the buffer is repetitive.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=84123#m84421
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2005 (http://www.dotNetBB.com)


'[EE] LCD problems/questions'
2005\10\31@195154 by James Seely
picon face
I'm pretty new to the electrical side of things but that's not keeping me
from jumping in over my head. I'm attempting to interface an LCD (AND471GST
from purdy electronis) to a Pic 16f877A. It doesn't seem to be working at
all. When I apply power to the circuit I don't see anything on the LCD and
when I adjust the contrast I don't see the display get lighter or darker.
Right now my guess is that I have this wired entirely wrong or my LCD is
bad.
I am wiring this up using a schematic and source code available from
http://www.rentron.com/Myke1.htm. I have tested the circuit using a DMM and
found that 5V is getting to the lcd. I'm 95% certain the wiring is correct
because of previous success wiring up some circuits from a schematic. I've
read the application notes and the spec sheet but haven't seen anything
overly helpful
 Does anyone have reference schematics, source code, or tests that can be
used to verify the functionality of this LCD module? If I just hook up
power, ground, and the POT for contrast adjustment shouldn't I see the the
screen get darker when I adjust it? Is there a way to jumper any of the pins
on the board to force a self test that will display information? Any help or
tips on how to get this going or verify that it is dead would be greatly
appreciated.
Thanks,
James

2005\10\31@200446 by Andre Abelian

flavicon
face
James,

You need to initialize your LCD to display any thing as far
contrast you should see the change on the screen.
Check the voltage on contrast pin ? what 's the voltage ?

Andre Abelian


James Seely wrote:

{Quote hidden}

2005\10\31@203504 by Jinx

face picon face
Looks like a pretty standard 2 x 16

http://www.purdyelectronics.com/PDF/AND471GST.PDF  (63kB)

> when I adjust the contrast I don't see the display get lighter or darker

With just power applied and Vo = 0V you should see dark blocks
on the top line, even before initialisation

Maybe the screen IS initialised but there's no data displayed ?

LCDs are pretty unforgiving about over-voltage on Vcc and it doesn't
take much to stuff them. It's never accidentally had (much) more than
5V on it ?

2005\10\31@204442 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Andre Abelian" <.....aabelianspamRemoveMEdnfcontrols.com>
To: "Microcontroller discussion list - Public." <piclistspam@spam@mit.edu>
Sent: Monday, October 31, 2005 8:04 PM
Subject: Re: [EE] LCD problems/questions


> James,
>
> You need to initialize your LCD to display any thing as far
> contrast you should see the change on the screen.
> Check the voltage on contrast pin ? what 's the voltage ?

Take a close read of the datasheet for the LCD.  You should see gray squares
by adjusting the voltage on the contrast pin.  However, extended temperature
LCDs require negative voltage on the contrast pin.  Some of them will show
absolutely nothing until the contrast pin gets below zero.

LCDs are a bit tricky in that little happens until you get them properly
initialized, and that takes a certain amount of code working right.  But
before that, +5, ground and contrast should get you some gray squares.
Possibly dim gray depending on the LCD, but nevertheless something.

--McD


2005\10\31@205118 by Jinx

face picon face
> Is there a way to jumper any of the pins on the board to
> force a self test that will display information ?

I'm not aware of such a test, not for a small LCD anyway



'[EE] LCD problems/questions'
2005\11\02@000031 by James Seely
picon face
>  Thanks to all for the suggestions. Here are some of them with responses.
> Sorry this is kind of long but I wanted to get it all together. I also seem
> to have had some success I discuss towards the bottom.
>
 "You need to initialize your LCD to display any thing as far
contrast you should see the change on the screen.
Check the voltage on contrast pin ? what 's the voltage ?"
<james>I'm trying to initialize the LCD with the Predko code but I'm not
certain that code is correct. I have a 10k pot hooked up to the contrast pin
and I can take it from 0v to 5v and never saw a difference in contrast.
"Maybe the screen IS initialised but there's no data displayed ?"
<james>A definite possibility but I should at least be able to see the
contrast adjust with no data being displayed (if I have a function LCD and
have wired it correctly)

"LCDs are pretty unforgiving about over-voltage on Vcc and it doesn't
take much to stuff them. It's never accidentally had (much) more than
5V on it ?"
<james> It is entirely possible. I have a couple of kids that are interested
in my project that might have helped me out (why have kids if you can't
blame them for stuff...). If I'm reading the spec sheet right it looks like
7v is the max it can handle and I highly doubt I've been over that. I say
that because I built a little 5v power supply from a schematic and it
actually only puts out something like 4.4v. I then hooked this up to one of
those fancy power supplies that lets you set the voltage and current and I
may have been over 5v when I ran up the voltage but only by a quarter volt
or so.
"However, extended temperature
LCDs require negative voltage on the contrast pin. Some of them will show
absolutely nothing until the contrast pin gets below zero"
<james> I don't think I need a negative voltage but how exactly woul I do
that if I wanted to?
 Some success?
I've been playing with this a bit tonight and seem to have stumbled across
something that made this sort of work. I was testing the voltages between
the Vdd pin and the Vo pin to see what they were after messing with the pot
and at one point I shorted between them. My board rebooted and suddenly I
saw some dark squares! Not exactly time for the happy dance but I may be
making progress with this. Now when I adjust the pot I do see the contrast
go up and down. I don't seem to see the pixels show up until that pin is
about 1.2v. Not sure if that's good or bad. Still don't see the text I'm
trying to ouput though.
Thanks to everyone for the suggestions. If anyone else happens to have seen
these types of issues I'd still like to hear final resolutions as this seems
a little too magical. I've written software for a while now and have always
seen magic code (that debug version that doesn't have the problem that the
release version does) but I didn't know the electrical side of things had
the same sort of magic. I understand the software magic. Just wish I
understood the electrical magic a little better.
Thanks,
James

2005\11\02@002815 by Kevin

picon face
On Tue, 1 Nov 2005, James Seely wrote:

{Quote hidden}

I don't know about the Predko code, but this is the first
code I got working on an LCD.

www.piclist.com/techref/piclist/cheapic/worktime.htm
It's for a F84 but should port to something else easily
enough.

2005\11\02@002849 by Jinx

face picon face
> It is entirely possible. I have a couple of kids that are interested
> in my project that might have helped me out

Next project - cattle prod ?

> actually only puts out something like 4.4v

You probably almost definitely maybe won't see anything with 4.4V.
The logic will work but the contrast drops off rapidly under Vspec

> Vo about 1.2v. Not sure if that's good or bad

Well, it's it's. Highest contrast is Vo = 0V, lowest is Vo = 5V

Are you using the two-wire circuit ?

2005\11\02@022234 by michael brown

picon face

----- Original Message -----
From: "James Seely" <EraseMEjames.seelyRemoveMEspamSTOPspamgmail.com>

 Some success?
>I've been playing with this a bit tonight and seem to have stumbled
across
>something that made this sort of work. I was testing the voltages
between
>the Vdd pin and the Vo pin to see what they were after messing with the
pot
>and at one point I shorted between them. My board rebooted and suddenly
I
>saw some dark squares! Not exactly time for the happy dance but I may
be
>making progress with this. Now when I adjust the pot I do see the
contrast
>go up and down. I don't seem to see the pixels show up until that pin
is
>about 1.2v. Not sure if that's good or bad. Still don't see the text
I'm
>trying to ouput though.

This sounds like you could have a possible rise time issue on the power
supply.  How are you powering your circuitry?  Do you have longish
jumper leads?  Too much inductance (long wires) and/or too much
capacitance (big caps on the power pins) can lead to slow rise times on
the voltage.  Allot of circuitry can be picky about this, including
PICs.




'[SX] LCD Problems'
2006\02\23@071104 by enowakn/a
flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, enowak wrote:

I am having problems driving a parallel LCD display with the SX-48 Proto board.  I am using the code written Al Williams.  It works perfectly when using an SX28, but when the same code is loaded into the SX48 second line feature doesn't work correctly, the message sometimes has random characters in it, and is not located properly.  I have attached the code that I am using for the SX48.  I could use some help on what I am doing wrong.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=111074
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\02\23@092130 by beann/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, bean wrote:

Are you using the latest version of SX/B 1.42.01 ?
If not you can download it from here:
Bean.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=111074#m111128
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\02\23@103047 by enowakn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, enowak wrote:

I am using SX/B 1.42  Do you think the .01 revision makes a difference?

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=111074#m111148
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\02\23@104932 by beann/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, bean wrote:

Why do you ask ?

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=111074#m111153
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\02\23@120731 by Jon Williamsn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Jon Williams wrote:

It might, and it's always good to use the very latest version of the compiler -- it exists because improvements/fixes have been made.  You can get the 1.42.01 version from the sticky note at the top of the SX forum.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=111074#m111169
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\02\23@130051 by Roadstern/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Roadster wrote:

I have found that going to the latest version cleared up alot of my problems when porting code from SX-28 - SX-48
---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=111074#m111176
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\02\23@132659 by enowakn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, enowak wrote:

I have tried the above program with 1.42.01 and now it will not compile.  The error message is "Line 148, error 44, Pass2: Address is not within lower half of memory page" This is mostly associated with the pulsee subroutine.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=111074#m111182
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\02\23@132919 by Coriolisn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Coriolis wrote:

The beginning address of subroutines must be in the lower 256 bytes of each 512 byte page, so rearrange your program so this is what happens, or place an ORG statement before the subroutine to bump it to the next page.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=111074#m111183
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\02\24@064757 by enowakn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, enowak wrote:

When writing code in SXB how do I know and control code so that subroutines are called in the lower half of a memory page?  I have tried moving some things around but still get the same error messages.  How is an ORG instruction implemented in BASIC and would this be wasteful of memory?

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=111074#m111277
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\02\24@072546 by beann/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, bean wrote:

enowak,
 SX/B DOES automatically handle the code pages, but you have to declare your subroutines using the SUB directive.
 See the template from the help file.
 SX/B has changed quite a bit since Al's book was written.
Bean.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=111074#m111290
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)

2006\02\24@105934 by Jon Williamsn/a

flavicon
face
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Jon Williams wrote:

Yes, and it continues to change -- some fun things are coming guys, and we ask that you be flexible when we make updates.  Please keep in mind that we update SX/B as feature requests come in.

---------- End of Message ----------

You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=111074#m111353
Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com
The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)


'[PIC] LCD problems (in microchip c18)'
2010\01\20@043501 by slippyr4
picon face
Hi All,

My project is using a hitachi compatible character lcd module in 4 bit mode,
and using the xlcd library from the mc18 libs.

Problem is that quite often, the LCD "goes wrong". After a few seconds of
use, at random, the LCD will start misbehaving - somtimes the screen blanks,
often it displays random characters.

To get it working again, I have to reset my circuit.

I'm only a hobbyist and i'm struggling to work out what the cause is.

The wires between my circuit board and the LCD are short - not more than 3".
I've tried adding a decoupling cap at the power pins of the LCD module.
I've tried a different LCD module, to no avail,
The circuit (pic and lcd) are powered from a 7805 1amp.
My PIC is an 18f252 clocked at 20 MHz with a crystal.
I've tried massively increasing the time delays that the xlcd routines ask
for:-
  the DelayFor18TCY routine delays for 100 cycles
  the DelayPORXLCD routine delays for 70 ms (350,000 cycles) instead of the
required minimum of 30ms
  the DelayXLCD routine is delaying for 14 ms

Nothing i've tried has helped. I'm not sure whether its a software or
electrical problem.

Has anyone got any insight or pointers for how i might diagnose what's going
on?

Thanks

slip

2010\01\20@045445 by Sarin Sukumar A

picon face
Check for any kind of array or pointer used in your software is overflowing
or accessing non allocated memory.

2010\01\20@045458 by ivp

face picon face
Slip,

> After a few seconds of use, at random, the LCD will start misbehaving -
> somtimes the screen blanks, often it displays random characters

Does it do this by itself or is it corrupting data you send ?

> To get it working again, I have to reset my circuit

Are you resetting the PIC or the power ?

> I'm only a hobbyist and i'm struggling to work out what the cause is

Do you have any access to an oscilloscope ? Can you put LEDs on the
LCD lines to detect any unwanted activity, particularly Enable, which is
the only line which signals the LCD to process data

> I've tried adding a decoupling cap at the power pins of the LCD module

I've noticed that some LCDs won't initialise properly without a decoupling
cap but run OK otherwise. It doesn't sound like an initialisation problem

> The circuit (pic and lcd) are powered from a 7805 1 amp

Is the regulator's input and output decoupled ? It might be oscillating at
some point

> I've tried massively increasing the time delays

If it really is 44780-compatible then commands should take 40us for most.
Set-up times as short as 1us should work

> I'm not sure whether its a software or electrical problem

Is there anything else in the circuit like a relay or solenoid or something
that might cause power spikes ? That can make an LCD go crazy

2010\01\20@045601 by Sarin Sukumar A

picon face
Check for any kind of array or pointer used in your software is overflowing
or accessing non allocated memory.

YOurs SaRIn....


On Wed, Jan 20, 2010 at 3:04 PM, slippyr4 <RemoveMEslippyr4KILLspamspamTakeThisOuTgmail.com> wrote:

{Quote hidden}

> -

2010\01\20@050514 by Alan B. Pearce

face picon face
>To get it working again, I have to reset my circuit.
>
>I'm only a hobbyist and i'm struggling to work out what the cause is.

You say you are using a 'Hitachi compatible' chip set. It is known that not
all chip sets work as fast as the Hitachi ones, so I suspect you may need to
lengthen some delays between operations on the LCD.

2010\01\20@052805 by slippyr4

picon face
>
> Does it do this by itself or is it corrupting data you send ?
>

Actually, i'm not sure. I refresh the display every .5 seconds approx, i've
not checked it it's associated with this. I guess i should have!


>
> > To get it working again, I have to reset my circuit
>
> Are you resetting the PIC or the power ?
>

a full power cycle to the entire circuit. Incidentally, if i plug/unplug too
quickly (ie < 1second), the display fails to reinitialise properly (although
the rest of my circuit seems to work fine). I put this down to a "brown out"
on the lcd perhaps from residual power in the output cap on the 7805 or the
decoupling cap on the lcd itself, and i wasn't unduly concerned by that.


>
> > I'm only a hobbyist and i'm struggling to work out what the cause is
>
> Do you have any access to an oscilloscope ? Can you put LEDs on the
> LCD lines to detect any unwanted activity, particularly Enable, which is
> the only line which signals the LCD to process data
>

yes, i have an old DSO but i'm not too good with it.


{Quote hidden}

yes. the psu part of my circuit is basically wouter's wall wart psu - a big
cap on the input and a smaller one on the output. not sure of the values
right now, i don't have the circuit with me this moment.


>
> > I've tried massively increasing the time delays
>
> If it really is 44780-compatible then commands should take 40us for most.
> Set-up times as short as 1us should work
>

absolutely. but the only displays i've found are very generic chinese ones
usually with no datasheet - the only info you get is pinout silkscreened on
the back of the module. The only decent one i ever had was a "truly lcd"
one, but that got destroyed (a long story).


>
> > I'm not sure whether its a software or electrical problem
>
> Is there anything else in the circuit like a relay or solenoid or something
> that might cause power spikes ? That can make an LCD go crazy
>


There is a relay, but the problem occurs irrespective of whether the relay
is in use or not.



i think i need to disable the automatic screen refresh part of my code and
retest the problem. silly of me not to consider this previously.

thanks for the pointers.

2010\01\20@052903 by slippyr4

picon face
> You say you are using a 'Hitachi compatible' chip set. It is known that not
> all chip sets work as fast as the Hitachi ones, so I suspect you may need
> to
> lengthen some delays between operations on the LCD.
>
> --
>

my delays are already extremely long in comparison to what they ought to be
for a proper hitachi chipset.

2010\01\20@062959 by Isaac Marino Bavaresco

flavicon
face
Em 20/1/2010 08:28, slippyr4 escreveu:
>> You say you are using a 'Hitachi compatible' chip set. It is known that not
>> all chip sets work as fast as the Hitachi ones, so I suspect you may need
>> to
>> lengthen some delays between operations on the LCD.
>>
>> --
>>
>>    
> my delays are already extremely long in comparison to what they ought to be
> for a proper hitachi chipset.
>  


Pay attention also to the delays inside each access cycle, like setup
and hold times and minimum Enable low and high times.

The Enable low and high times must be over 500ns each.

Best regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2010\01\20@063425 by Ruben Jönsson

flavicon
face
Make sure that you don't have any interrupts that interfere with the LCD
writing. Especially if the interrupt uses bits in the same port that is used by
the LCD. Also make sure that you don't have any read modify write (RMW)
problems.

/Ruben

{Quote hidden}

> -

2010\01\20@065941 by slippyr4

picon face
>
> The Enable low and high times must be over 500ns each.
>
> the code shows a call to DelayFor18TCY() function (which I have to provide)
after making E high, then again after making E low.

My current implementation of that function actually delays for 100
instruction cycles (which on 20 MHz clock equates to 20 microseconds, which
ought to be sufficient.

2010\01\20@070717 by slippyr4

picon face
2010/1/20 Ruben Jönsson <spamBeGonerubenspam@spam@pp.sbbs.se>

> Make sure that you don't have any interrupts that interfere with the LCD
> writing. Especially if the interrupt uses bits in the same port that is
> used by
> the LCD. Also make sure that you don't have any read modify write (RMW)
> problems.
>
>
Maybe there's a problem here.

I use RB5, RB6, RB7 for E, RW, RS.

I'm using some of the lower bits in port B for other things.

All of my reads and writes to port B are in the form:-

PORTBbits.RB2 = 1;

I'm not sure if the compiler generates "safe" code for that, or not.

I guess in a future hardware revision I should change ports that i'm using,
so I can get the LCD on it's own unique port. I think i'll need to change to
a 40 pin part to do that though, i'm running out of capacity on the 28 pin
parts.

2010\01\20@072412 by Jan-Erik Soderholm

face picon face
slippyr4 wrote:
{Quote hidden}

At 20 MHz you might have to add one or two NOP's between each
direct bit-instruction on a PORT reg. That should nornmaly be enough
if there isn't some un-normal capacitive load on the pins.

And, what do you do with RW ? Do you ever *read* from the LCD ?
If not, just tie it low and save a pin...

2010\01\20@075245 by Dario Greggio

face picon face
slippyr4 ha scritto:
> All of my reads and writes to port B are in the form:-
>
> PORTBbits.RB2 = 1;

use LATB to write.

And, if your PIC is old enough, do check for Fast interrupts Errata.


--

Ciao, Dario
--
Cyberdyne

2010\01\20@075633 by ivp

face picon face
> I use RB5, RB6, RB7 for E, RW, RS.
>
> I'm using some of the lower bits in port B for other things.

Slip, below is working code for an 18F2520. The upper nybble of
PortB is for 4-bit LCD data in W, with the lower 4 bits used for
other I/O. Depending on how dynamic those other I/O are and how
important it is to preserve/record them something like this may work
for you. If you're getting short on pins you might tie R/W to Vss and
use fixed write times. R/W is for reading Busy and transfers out of
the LCD's RAM, if you want to use it. Fixed write timing and not
using that off-PIC RAM will save a pin

Get it working your way first of course ;-))

wbr

        movwf  d_temp        ;store data
        movfw  portb
        andlw  b'00001111'   ;read port, preserve low nybble
        movwf  b_shadow

        movlw  b'11110000'   ;add data MSN to port
        andwf  d_temp,w
        clrc
        addwf  b_shadow,w
        movwf  latb
        bsf    en
        usec
        bcf    en
        usec

        swapf  d_temp,w      ;add data LSN to port
        andlw  b'11110000'
        clrc
        addwf  b_shadow,w
        movwf  latb
        bsf    en
        usec
        bcf    en

2010\01\20@091152 by slippyr4

picon face
> use LATB to write.
>
>
That's a good point. To clarify, what is the impact of me using PORTB not
LATB?



> And, if your PIC is old enough, do check for Fast interrupts Errata.
>
>
I'll look into that, thanks.

2010\01\20@093115 by Jan-Erik Soderholm

face picon face


slippyr4 wrote:
>> use LATB to write.
>>
>>
> That's a good point. To clarify, what is the impact of me using PORTB
> not LATB?
>

Higher risk for read-modify-write related problems.


2010\01\20@164206 by Ruben Jönsson

flavicon
face
>
>
> slippyr4 wrote:
> >> use LATB to write.
> >>
> >>
> > That's a good point. To clarify, what is the impact of me using PORTB
> > not LATB?
> >
>
> Higher risk for read-modify-write related problems.
>

Put in another way - Using LATX instead of PORTX gives you no risk for the RMW
problem.

The RMW problem is caused by a combination of two things:

1. An instruction that is changing just one bit in a register (bsf, bcf)
actually first reads the whole register, changes the bit and then writes back
the whole register (thus the name Read - Modify - Write).

2. When the register is a PORT register, the value read is actually the logic
levels of the physical pins and not necessarily the value that has previously
been written to the port.

This can become a problem if the capacitive load on a port pin is relatively
high (like the gate on a MOSFET for example) and there are two (or more) bit
changes on the same port right after each other. For example:

BSF RB,0
BSF RB,1

If RB0 initially was 0, BSF RB,0 now starts to change it to a 1. If the
capacitive load on that pin is high it will take some time for it to rise the
voltage to a logic high level. If this time is longer than the time until
another bit in RB is changed, the value that is read back for RB0 will still be
a 0 (as seen by the port logic) and when the whole byte is written back RB0 has
unintentionally been reset back to a 0 again.

Newer PICs actually have two registers for one port - The PORT register and the
LAT register. The LAT register is a latch (or buffer) between the CPU and the
PORT register. So if you write a value to the LAT register it is also written
to the PORT register but it is always read back as the same value that was
written independent of how long the PORT register actually takes to change.

/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
rubenspamspampp.sbbs.se
==============================

2010\01\20@172043 by Wouter van Ooijen

face picon face
> This can become a problem if the capacitive load on a port pin is relatively
> high (like the gate on a MOSFET for example) and there are two (or more) bit
> changes on the same port right after each other. For example:

That could be solved by a delay. It can also be a problem with a
moderate (well within the allowed range) *static* load, like a 330 ohm
resistor and a LED.

Summary: unless you are sure what you are doing, always use a show
register (on 12 and 14 bit cores, on 18Fs you can use the LATx registers).

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2010\01\20@173415 by Jan-Erik Soderholm

face picon face
Ruben Jönsson wrote:
{Quote hidden}

And apart from timing beeing a potential cause there is another
cause which might be more common (for somene new to PICs),

1. Bit manipulating pins on an output port that is configured
for analog input. You can set any pin to 0 or 1 and see the
result on the pin, but it will always be reset to 0 as soon as
you set/clear another pin on the same port (since an analog
input-pin always is digitaly read as "0"). This is tricky since
all pins works just fine alone.

More... (looser matching)
- Last day of these posts
- In 2010 , 2011 only
- Today
- New search...