Maximun Cable Length for PIC to LCD

[skimask]

Question from the sidelines...maybe an idea...not sure...haven't looked into it yet...

Couldn't the LCDOUT command itself be 'hi-jacked' inside on of the macros to change the E line assignment dynamically? As far as I know, LCDs won't do squat unless the E line is pulsed.
Maybe something like:
LCDOUT $fe , $fe , 0 , "First LCD"
LCDOUT $fe , $fe , 1 , "Second LCD"
LCDOUT $fe , $fe , 2 , "Third LCD"
....and so on and so on...
As far as I know, there aren't any character LCDs any wider than 40 characters. If the second character in the 'string' was anything above $FC, it could be a 'hijack' command...
or something like that anyways...
As for myself, like I said before, I'm running 3 different types of LCDs on my OBD interface right now (16x2 parallel, 122x32 graphic mode, and a 130x130 Nokia color knockoff).
Guess which one is the easiest to interface with?

[Darrel Taylor]

Maybe something like:
LCDOUT $fe , $fe , 0 , "First LCD"
LCDOUT $fe , $fe , 1 , "Second LCD"
...

Sure,

With complete control of the LCDOUT command, you can do pretty much whatever you want.

And, It's not a bad idea.

So, with the existing code from this thread.
Changing the LCDsend routine like this ...

;----[Send a byte to the Virtual LCD PORT]------------(DO NOT Change)---------
TempChar        var  byte
Char            VAR  Byte
LCD_Initialized VAR  FLAGS.1
RSS             VAR  FLAGS.0                ; LCD RS State
HJ_Command      VAR  BIT

;----[ This routine is called once for every character sent by LCDOUT ]-------
LCDsend:
      @  MOVE?AB  _TempChar                 ; Get char sent by LCDOUT, in WREG
      if !LCD_Initialized then LCD_Init     ; Make sure LCD was Initialized 
  LCDAfterInit:

      IF HJ_Command then LCDEN = TempChar : HJ_Command = 0 : goto LCDsendDone
      IF RSS then NO_HJcheck
      IF TempChar = $FE then RSS = 1 : HJ_Command = 1 : goto LCDsendDone
  NO_HJcheck:

      if TempChar = $FE then RSS=0 : goto LCDsendDone ; next char is Command 
      Char = TempChar
  LCDsendCOM:
      @  WritePort   _Char, LCD_Port_HNIB   ; send the High Nibble
  LCDsendShortCOM:
      @  WritePort   _Char, LCD_Port_LNIB   ; send the Low Nibble

      IF RSS = 0 then                    ; Is a Command
          IF Char = 1 then CommandDelay     ; Long delay for Clear Screen
          IF Char = 2 then CommandDelay     ; Long delay for Home
          @  DelayUS   _LCD_DATAUS          ; Short delay for everything else
          goto DelayDone
      else                                  
          @  DelayUS   _LCD_DATAUS          ; Short delay for Data
          goto DelayDone
      endif
  CommandDelay:
      @  DelayUS   _LCD_COMMANDUS
  DelayDone:
    if LCD_Initialized then RSS = 1       ; Set RS to Data next time
  LCDsendDone:
return

Then you can embed the LCD selection inside the LCDOUT statements...

    LCDOUT $FE,$FE,%001, $FE,$80, "Display 1"
    LCDOUT $FE,$FE,%010, $FE,$80, "Display 2"
    LCDOUT $FE,$FE,%100, $FE,$80, "Display 3"
    LCDOUT $FE,$FE,%111, $FE,$C0, "ALL Displays"

And it still works the original way too. (Choices)

    LCDEN = %001
    LCDOUT $FE,$80, "Display 1"
    
    LCDEN = %010
    LCDOUT $FE,$80, "Display 2"

    LCDEN = %100
    LCDOUT $FE,$80, "Display 3"
    
    LCDEN = %111
    LCDOUT $FE,$C0, "ALL Displays"

Now I really gotta go to bed.

[skimask]

And, It's not a bad idea.

I get 'em once in a great while...

So, with the existing code from this thread.................

and here I spent the better part of a few hours last night messing with the core macros.
I'm digging this idea much better. (Yes, I said 'digging' )

[Darrel Taylor]

Maybe you'll Dig this idea too.

GLCD's using LCDOUT.
<br>

[skimask]

Maybe you'll Dig this idea too.

GLCD's using LCDOUT.
<br>

Well, I don't exactly use LCDOUT for the GLCD, but I do the 'printstr' from awhile back to do the display with it, and I modified a version for the Nokia ('printstr2', original eh?), and I used that 'copystr' from awhile back, modified another couple of versions into 'printvar' and 'printvar2', defined a dedicated string, use it only with those macros, handle it outside of the printvar routines, and send it out when I want it, along with the x,y. Works for me...

I suppose it wouldn't be that hard, relatively speaking anyways, to hijack the lcdout command further...maybe a predefined types (i.e. DEFINE LCDTYPE $00 ; low nybble = lcd number, high nybble = lcd type, this case, first lcd, parallel, another case DEFINE LCDTYPE $11; low nybble = second lcd, high nybble = 122x32,SED1520 type, and so on...).

Great...more crap to do...

Question: How would one go about turning this sort of thing into a 'One Stop Shop' solution for extending PBP's capabilities? One that wouldn't involve modifying libraries, macro sets, or other files... A single include file or would this involve some sort of remaking the compiler itself? Those printstr and printvar macros I've got are all in-line with my normal code in all my programs. Yes, those could easily be done with a single 'include' file. But, would there be an easy way to add these 'extensions' by default? Not only for this LCD modification, but for the matrix keypad, SD card access, IDE access, '1820 reading, etc?

[mister_e]

that would be really nice indeed... i think it's more a pre-compiler option, not sure how Melabs could give such compiler access... i know an automated solution, but, it's still in stage.

Yeah, there's a lot of new things in MisterE land to come in 2008.