ILI9320 LCD - possible to define data pins instead of data port?

[SCV]

I am trying to add an ILI9341 LCD display using the ILI9320 include, but my hardware connection to the data bus has the data pins out of order. Is there a define to allocate data pin to port.pin?
If not, could I replace part of the ILI9320.inc code with a bit bash, something like code below or will this upset something else?

Code Select Expand


'-------------------------------------------------------------------------------------------
' Helper routine that writes data to the LCD's data port
' Input     : pData holds the data to send to the LCD
' Output    : None
' Notes     : Reverses the bits sent to the LCD's data port if using an Amicus24 board
'
$IFDEF _Using_Amicus24_
$DEFINE Glcd_hWriteDataPort(pData)   '
    PUSH.d W12                       '
    WREG12.BYTE0 = pData             '
    WREG13 = 8                       '
    REPEAT                           '
        ROL WREG12.BYTE0             '
        ROR WREG12.BYTE1             '
        DEC WREG13                   '
    UNTIL SRbits_Z = 1               '
    __LCD_DTPort.BYTE = WREG12.BYTE1 '
    POP.d W12
$ELSE
'$DEFINE Glcd_hWriteDataPort(pData) __LCD_DTPort.BYTE = pData
$DEFINE Glcd_hWriteDataPort(pData)
     __LCD_DTPin7 = pData.7
     __LCD_DTPin6 = pData.6
     __LCD_DTPin5 = pData.5
     __LCD_DTPin4 = pData.4
     __LCD_DTPin3 = pData.3
     __LCD_DTPin2 = pData.2
     __LCD_DTPin1 = pData.1
     __LCD_DTPin0 = pData.0

$ENDIF


Adding to my main programme:-
 SYMBOL LCD_DTPin7 = PORTB.5
 SYMBOL LCD_DTPin6 = PORTB.4
 SYMBOL LCD_DTPin5 = PORTB.3
 SYMBOL LCD_DTPin4 = PORTB.2
 SYMBOL LCD_DTPin3 = PORTB.1
 SYMBOL LCD_DTPin2 = PORTB.0
 SYMBOL LCD_DTPin1 = PORTB.6
 SYMBOL LCD_DTPin0 = PORTB.7

Device is a dsPIC33EP512MC806 so using P24.
If anyone is aware of any differences between an ILI9320 & ILI9341 then this would be hugely appreciated!

Thanks,
Tim.

[top204]

Untested because I do not have an ILI9320 LCD anymore. But you can use the Declares for an Alphanumeric LCD that seperates the pins, then use the constants the compiler creates for them in the source code for the ILI9320 library. i.e. "ILI9320.inc"

For example:

Code Select Expand

Declare LCD_Data0_Pin PORTB.7 ' Connect PORTB.7 to the LCD's D0 line
Declare LCD_Data1_Pin PORTB.6 ' Connect PORTB.6 to the LCD's D1 line
Declare LCD_Data2_Pin PORTB.5 ' Connect PORTB.5 to the LCD's D2 line
Declare LCD_Data3_Pin PORTB.4 ' Connect PORTB.4 to the LCD's D3 line
Declare LCD_Data4_Pin PORTB.3 ' Connect PORTB.3 to the LCD's D4 line
Declare LCD_Data5_Pin PORTB.2 ' Connect PORTB.2 to the LCD's D5 line
Declare LCD_Data6_Pin PORTB.1 ' Connect PORTB.1 to the LCD's D6 line
Declare LCD_Data7_Pin PORTB.0 ' Connect PORTB.0 to the LCD's D7 line

Make sure you copy the "ILI9320.inc" file from the "C:\Users\User Name\PDS\Includes" folder to the folder where your main BASIC program is, otherwise, other programs will use a modified "ILI9320.inc" file as well, and it will not work as standard for them.

Open the moved  "ILI9320.inc" file, and change the code within it. From:

Code Select Expand

$ifdef _Using_Amicus24_
$define Glcd_hWriteDataPort(pData)   '
    Push.d W12                       '
    WREG12.Byte0 = pData             '
    WREG13 = 8                       '
    Repeat                           '
        Rol WREG12.Byte0             '
        Ror WREG12.Byte1             '
        Dec WREG13                   '
    Until SRbits_Z = 1               '
    __LCD_DTPort.Byte = WREG12.Byte1 '
    Pop.d W12
$else
$define Glcd_hWriteDataPort(pData) __LCD_DTPort.Byte = pData
$endif

To:

Code Select Expand

$define Glcd_hWriteDataPort(pData)             '   
    WREG0 = pData                              '
    __lcd_data0_port.__lcd_data0_pin = WREG0.0 '
    __lcd_data1_port.__lcd_data1_pin = WREG0.1 '
    __lcd_data2_port.__lcd_data2_pin = WREG0.2 '
    __lcd_data3_port.__lcd_data3_pin = WREG0.3 '
    __lcd_data4_port.__lcd_data4_pin = WREG0.4 '
    __lcd_data5_port.__lcd_data5_pin = WREG0.5 '
    __lcd_data6_port.__lcd_data6_pin = WREG0.6 '
    __lcd_data7_port.__lcd_data7_pin = WREG0.7

Can you see what it is doing?

For each Declare created in the BASIC listing, the compiler creates, underlying, constants that can be used by an Asm routine or the BASIC listing. These can be seen in the Assembler listing if you press the F2 button. For example, the Declare LCD_Data0_Pin directive produces the constants; __lcd_data0_port and __lcd_data0_pin.

So the above routine is using each bit from the operand parameter(pData), to load into the bits of the LCD's Data port. The WREG0 SFR has had to be used as an itermediate because sometimes the $define is called with High or Low byte casting, and the compiler does not "yet" support a casting such as MyWord.Byte0.0 etc...

As I said, untested, but that is, exactly how the Alphanumeric LCD operates when the compiler sees the LCD_DataX_Pin declares, and switches its internal library over to use them instead of a single Port.

You will also need to alter some code in the "Glcd_Initialise()" routine, to make each of the pins chosen to Outputs. For example, instead of:

Output __LCD_DTPort.Byte                        ' Set Data Bus as output

Use:

Code Select Expand

    Output __lcd_data0_port.__lcd_data0_pin
    Output __lcd_data1_port.__lcd_data1_pin
    Output __lcd_data2_port.__lcd_data2_pin
    Output __lcd_data3_port.__lcd_data3_pin
    Output __lcd_data4_port.__lcd_data4_pin
    Output __lcd_data5_port.__lcd_data5_pin
    Output __lcd_data6_port.__lcd_data6_pin
    Output __lcd_data7_port.__lcd_data7_pin

You will need to scan through the rest of the "ILI9320.inc" file and change any other references to the "__LCD_DTPort.Byte", in order to use the seperated pins, because they are cleared and made inputs etc, elsewhere in the library, but you should get the concept of what to do from the above explanation.
 
These are the types of underlying concepts of the compilers that I am hoping to add to an eBook on "Mastering the Positron Compilers". There are many "secrets" to the compilers that simply do not fit in their manuals, otherwise they become mainstream and if not used correctly can cause havok in a program's operation, thus, do "not" fit in the official manual. LOL But they offer a lot of flexability to the languages, and optimisations of code, for the user who knows what to do, and understands that things can go wrong if they are not used appropriately. :-)

The ILI93XX LCDs do have a commonality, however, their start-up command sequences are different and their internal registers.

[SCV]

Thankyou Les,

I copied the include as you say and have renamed it suffix _pins so as not to confuse me later.

Will any changes be needed for other operations on data bus?
eg: CLEAR __LCD_DTPort.BYTE                 ' Write $00 to the LCD
becomes: CLEAR __lcd_data0_port.__lcd_data0_pin
         CLEAR __lcd_data1_port.__lcd_data1_pin



 OUTPUT __LCD_DTPort.BYTE                        ' Set Data Bus as output
becomes: OUTPUT __lcd_data0_port.__lcd_data0_pin
         OUTPUT __lcd_data1_port.__lcd_data1_pin


 INPUT __LCD_DTPort.BYTE                 ' Make the data port an input
becomes: INPUT __lcd_data0_port.__lcd_data0_pin
         INPUT __lcd_data1_port.__lcd_data1_pin


How would the read command be implemented like this
    Glcd_hEnableRead()                      ' \
    WREG4.BYTE1 = __LCD_DTPort.BYTE         ' | First Read cycle to get high data from Read Data Latch
    Glcd_hDisableRead()                     ' /
    Glcd_hEnableRead()                      ' \
    WREG4.BYTE0 = __LCD_DTPort.BYTE         ' | Second Read cycle to get low data from Read Data Latch
becomes:
    Glcd_hEnableRead()                      ' \
    WREG4.8 = __lcd_data0_port.__lcd_data0_pin
    WREG4.9 = __lcd_data1_port.__lcd_data1_pin
    Glcd_hDisableRead()                     ' /
    Glcd_hEnableRead()                      ' \
    WREG4.0 = __lcd_data0_port.__lcd_data0_pin
    WREG4.1 = __lcd_data1_port.__lcd_data1_pin

Only bits 0 & 1 are shown for brevity.
I won't pretend to understand why or how using the SFR is necessary, mastering the Positron sounds like just what I need!

Cheers,
Tim.