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?
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!
Do I no longer call for the "MCUFRIEND_kbv.h" and instead use the MCUFRIEND_shield.h?
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?
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.
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.
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_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.
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.
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.
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.