MCUFriend & 1284 Bobuino Pin re-assignment

Hi,

I'm having some problems reassigning the control pins and could use some help.

Setup is a 240x320 ST7789v display with a 1284 Bobuino pinout from Crossroads.

It works great using the standard shield pinout:

#define LCD_RD A0         //MCU pin 30, Crossroads D14 LCD Read goes to Analog 0
#define LCD_WR A1        //MCU pin 31, Crossroads  D15 LCD Write goes to Analog 1
#define LCD_CD A2        //MCU pin 32, Crossroads  D16 Command/Data goes to Analog 2
#define LCD_CS A3        //MCU pin 33, Crossroads  D17 Chip Select goes to Analog 3
#define LCD_RESET A4     //MCU pin 34, Crossroads  D18 Can alternately just connect to Arduino's reset pin

I want to re-assign these to the following:

#define LCD_RD   ?            //Crossroads D29
#define LCD_WR   ?            //Crossroads D28
#define LCD_CD   ?            //Crossroads D27
#define LCD_CS   ?            //Crossroads D26
#define LCD_RESET   ?         //Crossroads D25

I've tried a number of assignments with no success:

#define LCD_RD D29 //PC3 1284p pin26
#define LCD_WR D28 //PC4 1284p pin25
#define LCD_CD D27 //PC5 1284p pin23
#define LCD_CS D26 //PC6 1284p pin24
#define LCD_RESET D25 //PC7 1284p pin22

and

#define LCD_RD PC7
#define LCD_WR PC6
#define LCD_CD PC5
#define LCD_CS PC4
#define LCD_RESET PC3

and

//#define LCD_RD PCINT23
//#define LCD_WR PCINT22
//#define LCD_CD PCINT21
//#define LCD_CS PCINT20
//#define LCD_RESET PCINT19

Would appreciate any help in figuring this out!!

THanks ahead of time.

From mcufriend_shield.h

//################################### UNO SHIELD on BOBUINO ##############################
#elif defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644P__) //UNO shield on BOBUINO
#warning regular UNO shield on BOBUINO
#define RD_PORT PORTA
#define RD_PIN  7
#define WR_PORT PORTA
#define WR_PIN  6
#define CD_PORT PORTA
#define CD_PIN  5
#define CS_PORT PORTA
#define CS_PIN  4
#define RESET_PORT PORTA
#define RESET_PIN  3
...

you would want to make SPECIAL with:

#elif defined(__AVR_ATmega1284P__) && defined(USE_BOBUINO_BWANNA)
#warning using USE_BOBUINO_BWANNA
#define RD_PORT PORTC
#define RD_PIN  3
#define WR_PORT PORTC
#define WR_PIN  4
#define CD_PORT PORTC
#define CD_PIN  5
#define CS_PORT PORTC
#define CS_PIN  6
#define RESET_PORT PORTC
#define RESET_PIN  7
...

David.

David,

Thank you very much!!

Just to verify (still learning) to invoke the "mcufriend_special.h" I'll need to uncomment the "//#define USE_SPECIAL" in the "mcufriend_shield.h" file?

Not sure if this matters, but I've been calling the "MCUFRIEND_kbv.h" and not "mcufriend_shield.h". Does this change your recommendations? Do I just need to add defining the shield.h file?

VMA

Steve

There are many ways that you can skin a cat. video

I recommend one method. I suggest that you stick to it.

David.

david_prentice:
There are many ways that you can skin a cat. video

I recommend one method. I suggest that you stick to it.

David.

david_prentice:
There are many ways that you can skin a cat. video

I recommend one method. I suggest that you stick to it.

David.

Sorry I don't understand. As mentioned I'm still learning, so still figuring out how to skin the cat in the first place, much less in different ways! :slight_smile:

  1. Do I no longer call for the "MCUFRIEND_kbv.h" and instead use the MCUFRIEND_shield.h?
  2. How does the "mcufriend_special.h" get called? (That's why I asked about uncommenting the line.)
    OR, do I add "#define mcufriend_special.h" to my program?

Thanks,
Steve

From the how_to file:

17. If you do not have a standard Uno Shield, you can add a SPECIAL to the mcufriend_special.h
    Edit mcufriend_shield.h:  #define USE_SPECIAL
    Edit mcufriend_special.h: e.g. #define USE_MEGA_16BIT_SHIELD
    If your "special" is write-only,  the library can not read the ID.  It always returns 0xD3D3
	
...

19. OPEN-SMART Shields have different wiring to regular Uno Shields:
    Edit utility/mcufriend_shield.h:  #define USE_SPECIAL
    Edit utility/mcufriend_special.h: #define USE_OPENSMART_SHIELD_PINOUT
    Edit MCUFRIEND_kbv.cpp:           #define SUPPORT_8352B

You can see the style.
You add a #define USE_BOBUINO_BWANNA to the special.h
You add the suitable special block to the special.h

The special.h file is only included when you #define USE_SPECIAL in the shield.h

Tip. You can copy the whole BOBUINO block from shield.h and edit the changes that I suggested.

Life is much easier if you just stick to the "official" wiring in the first place. The original idea behind the library was to support display shields that mate with Arduino headers as Nature intended.

David.

David,

That helps alot. Thank you! BTW< apologies, I completely glazed over seeing the 'how to' file... was actually looking for it. (it's been a week.)

This is a custom PCB project with most of the Analog pins being used for other things, thus the need to re-assign the display control pins. I did first try to write the .h and .cpp files myself (learning from yours and others' work), but it was beyond my current capability. Again still learning and this old brain doesn't do it quite as fast as it used to! Along the lines of 'not reinventing the wheel', your MCUFriend provides all that I needed for the ST7789V display running 8-bit with only having to change 5 assignments.

Thanks for the walk-through and code!! I actually did copy the Bobuino section to the special.h and added your changes. Will test that out later when I get home.

TYVM!

Changing the control pins is trivial.

Using random pins for the data bus is really fiddly.

Did you like the cat video?
It is just as well that YouTube does not come with smell.

David.

david_prentice:
Changing the control pins is trivial.

Using random pins for the data bus is really fiddly.

Did you like the cat video?
It is just as well that YouTube does not come with smell.

David.

Agreed! that's why I didn't mess with re-assigning the digital pins. Leave well enough alone!

Yeah, the video brought back grade school memories... especially the formaldehyde!

David,

The good news is the Display is ALIVE! The more... challenging... news is that the colors are not matching.

Green > Magenta
Red > Light Blue
Blue > Light Red

This occurs with all of the example sketches.
I do get "ID = 0x7789" each time.

As discussed I copied the entire Bobuino section into the Special.h and substituted your reassignments for the control pins.

Thoughts?

You have inverted colours. Call tft.invertDisplay(1);

Panels vary. If you are using the same panel it should still work the same when you change the control pin wiring.
If you have a panel from a different supplier you can change the behaviour for all 0x7789 screens by changing the REV_SCREEN attribute for 0x7789

You have probably made some bad edits when you were experimenting.
I suggest that you start again with a fresh install of your libraries.
Then make your edits to add and configure your SPECIAL.

David.

The call tft.invertDisplay(1); seems to have fixed it. I had done a fresh install when I first encountered this. Didn't think to call this command.

Thanks!

Have you used a different ST7789 ?

Panels do vary.

David.

david_prentice:
Have you used a different ST7789 ?

Panels do vary.

David.

I've been testing two panels of the same model that I got directly from Startek and substitute each into with the tests. So far all results are identical.

Running the Bobuino at 3v3 and 16mhz MightyCore (sorry, forgot to mention that earlier)

All of the MCUfriend graphics test sketches come out fine as long as I CALL tft.invertDisplay(1);... otherwise the colors are reversed.

Unfortunately, when I go to run my code some quirky stuff is occurring. striations 1-pixel lines within the space of characters, random patchwork of colors, etc. I have to recheck everything and see what I can find.

Will keep you posted and thanks for inquiring!

Are they Mcufriend shields?
Or bare modules that you run at 3.3V ?

My ST7789 shield displays the correct colours. I do not need invertDisplay()

I am quite happy running AVRs at 3.3V and 16MHz. I would expect your AVR to run fine.
Do you have proper soldered wires or soldered headers?

David.

david_prentice:
Are they Mcufriend shields?
Or bare modules that you run at 3.3V ?

My ST7789 shield displays the correct colours. I do not need invertDisplay()

I am quite happy running AVRs at 3.3V and 16MHz. I would expect your AVR to run fine.
Do you have proper soldered wires or soldered headers?

David.

David,

These are just bare displays: KD024QVRMA041-RT directly breadboarded to the crossroads bobuino at 3v3. Here's the datasheet
KD024QVRMA041-RT

My pinout is the following:
8-bit Digital pins
Display pin > Bobuino pin
11 > D7
12 > D6
13 > D5
14 > D4
15 > D3
16 > D2
17 > D1
18 > D0

Control pins
34 > D29 (RD)
35 > D28 (WR)
36 > D27 (CD)
35 > D26 (CS)
34 > D25 (RST)

Conf display pins
39 > Vcc (IM0)
40 > Gnd (IM1)
41 > Gnd (IM2)

Out of curiosity I did try and reverse the digital pins. Of course this didn't produce any output.

My limited experience does tell the that inverse colors means something isn't right, but I just figure out what it could be?

What's especially weird are these thin 1-pixel lines that appear in the printing to the TFT. They tend to coincide with the individual characters. I'm thinking it's electrical noise from the breadboarding.

Also, Red produces this course mixture of red and blue pixels.

Lines in tft

Thanks,
Steve

There is nothing wrong.
Panels vary. Some LCD are natural White. Some are natural Black. Some drive the scan lines differently, ...

You just need to add the REV_SCREEN attribute. e.g.

    case 0x7789:
        _lcd_capable = AUTO_READINC | MIPI_DCS_REV1 | MV_AXIS | READ_24BITS | REV_SCREEN;

I have no idea what your code is.
I have no idea how well you have layed out your pcb traces and external wiring.

My ST7789 Shield works fine.
And I have an SPI ST7789 which works fine too.

David.

david_prentice:
You just need to add the REV_SCREEN attribute. e.g.

    case 0x7789:

_lcd_capable = AUTO_READINC | MIPI_DCS_REV1 | MV_AXIS | READ_24BITS | REV_SCREEN;




David.

Thanks. This helps and it's good to know that screens can vary... i.e. that I'm not crazy. BTW, where should I place this line of code... in the Special file I'm figuring?

The project code has actually been working for a number of years on an active project that uses a smaller 9341 TFT. I'm upgrading the display only to this transflective type to accommodate the outdoor challenges. The project is for my motorcycle.

I really appreciate the help!

Thanks,
Steve

You would change attributes in the .CPP file

If someone posts a snippet of code as a suggested edit, you simply search for some matching text.
e.g. I would search the library CPP file for "case 0x7789:"
If you searched for "0x7789" you would get more hits. Only one "hit" would appear to be valid.

Since you are not using this as a general purpose display, I suggest that you just use invertDisplay() in the custom sketch.

David.

David, Sound advice. Again thank you for helping me with this. I like the display and it does present well, so it's nice to have it working.

Cheers,
Steve