STM32F103C8 & TFT (ili9325)

Working libraries, libraries being ported and related hardware
mausi_mick
Posts: 129
Joined: Fri Aug 12, 2016 1:40 pm

Re: STM32F103C8 & TFT (ili9325)

Post by mausi_mick » Thu Nov 24, 2016 2:47 am

no success,

I changed the lib and modified
The address for TFT_CS, TFT_RD ... in the sketch.

the errors:
Error_MCUFRIENDS_graphictest.ino
(34.3 KiB) Downloaded 40 times

stevestrong
Posts: 1130
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: STM32F103C8 & TFT (ili9325)

Post by stevestrong » Thu Nov 24, 2016 8:08 am

Have you tried my lib with forced ID = 0x9325 ?

david.prentice
Posts: 78
Joined: Wed Nov 16, 2016 8:52 am

Re: STM32F103C8 & TFT (ili9325)

Post by david.prentice » Thu Nov 24, 2016 9:49 am

@mausi_mick,

My apologies. I tested STM32 with my private sketch and not the example from the library.

Yes, sure enough, STM32 barfs on icons.c i.e. a C file
My private version of icons.c has:

Code: Select all

#if defined(__STM32F1__)
#define PROGMEM
#else
#include <Arduino.h>
#endif
If you change the file type to INO or CPP, the STM32 has no problem.
I suspect that somewhere in the STM32 structure the headers are not C /C++ compliant.

Which explains why the simple kludge of avoiding Arduino.h "works" !!

@stevestrong,

I found your repository on GitHub. Changed the write8() etc macros in the H file for my Nucleo.
And changed the control pins setMode() in the constructor.

I have not got your library working on the Nucleo yet. I will have another look.
Oh, I am using an ILI9341 shield.

Incidentally, the ILI9327 is VERY different to the 9325, 9341, 8347, ...

David.

stevestrong
Posts: 1130
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: STM32F103C8 & TFT (ili9325)

Post by stevestrong » Thu Nov 24, 2016 10:17 am

david.prentice wrote: Incidentally, the ILI9327 is VERY different to the 9325, 9341, 8347, ....
@David, yes I know, I looked in your repo and only could find 2 places where 9327 is treated specially, but could not find any dedicated init sequence for this type.
Which settings of the alternatives (9341, 932x) are the best to initialize with?
I am trying to make my lib as universal as possible, each variant has its own file, but keeping the original functionality from Adafruit.
That's why I could add this variant (9327) to my repo in a very simple way.

david.prentice
Posts: 78
Joined: Wed Nov 16, 2016 8:52 am

Re: STM32F103C8 & TFT (ili9325)

Post by david.prentice » Thu Nov 24, 2016 10:55 am

MIPI compliant controllers use a standard set of registers and commands for writing to the display.
User applications can work with different makes, models without any changes (except for Width and Height)

However the "Manufacturer commands" vary greatly. But as a general rule, you only use these commands at the start of an App. In fact, most displays will start up by themselves without the User touching any Manufacturer commands.

The older non-MIPI controllers like the ILI9325 are vastly different in registers, commands, initialisation, ...

If you look at my Repo, you will see that there are minor differences for reading GRAM, setting orientation for MIPI controllers. i.e. "compliant" is not a magic bullet.

In practice, most Apps will only use one particular orientation and probably never read GRAM or even registers.
That is why UTFT is so effective. (and easy to add a new controller)

My Repo is due for a significant "tidy up" and a proper new Release.
If you strip out the conditional code, the basic readGRAM(), drawPixel(), setWindow(), setRotation(), vertScroll() ... are fairly simple.

Maintaining separate files for 25 controllers would be a nightmare.
OTOH, if you only possess a single controller, you don't need any conditional code.

David.

stevestrong
Posts: 1130
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: STM32F103C8 & TFT (ili9325)

Post by stevestrong » Thu Nov 24, 2016 12:10 pm

Thank you, David.
But, again, which initial settings of the alternatives (9341, 932x) are the best to use for 9327? Is any initial register setting needed at all?
Or is the 9327 a MIPI compliant controller which does not need any init sequence?

david.prentice
Posts: 78
Joined: Wed Nov 16, 2016 8:52 am

Re: STM32F103C8 & TFT (ili9325)

Post by david.prentice » Thu Nov 24, 2016 1:58 pm

@Steve

ILI9327 is MIPI compliant 240x432 controller.
But it does have a few problems when you use PORTRAIT_REV or LANDSCAPE_REV with a 240x400 panel.

You can alter the Manufacturer registers to suit your Panel. Ilitek produce App Notes with initialisations for different Panels.

I feel really stupid. I was trying to run your library with an ILI9341. And had not looked closely at the "Adafruit" code.
It is reading the ID wrong. It is initialising wrong.

So I plugged in an ILI9325 Shield. Worked first time !!

David.

p.s. it is attempting identify a HX8357D correctly, but this code is wrong too. Where did you get your original code from?

stevestrong
Posts: 1130
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: STM32F103C8 & TFT (ili9325)

Post by stevestrong » Thu Nov 24, 2016 2:53 pm

david.prentice wrote:Where did you get your original code from?
Adafruit github repo, so don't blame me, I have only adapted the 9325 part, as this is what I have. It may work for other controllers well or not, but I am open to fix/adapt the code for other controllers if needed.

david.prentice
Posts: 78
Joined: Wed Nov 16, 2016 8:52 am

Re: STM32F103C8 & TFT (ili9325)

Post by david.prentice » Thu Nov 24, 2016 3:43 pm

I found https://github.com/stevstrong/Adafruit_ ... _STM32.cpp with Google.
It contains:

Code: Select all

uint16_t readReg(uint8_t r)
From your link, the Adafruit Github Repo has:

Code: Select all

uint32_t Adafruit_TFTLCD::readReg(uint8_t r) {
Adafruit write some excellent libraries. Unfortunately, many people "adapt" the code and keep the same class name.
So it is difficult to know where and how code has evolved.

David.

stevestrong
Posts: 1130
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: STM32F103C8 & TFT (ili9325)

Post by stevestrong » Thu Nov 24, 2016 3:57 pm

@David
Sure, your right.
But if you have a closer look, you will notice that this function is used only in one place in the original code, and at that place the return value of this function is compared with a 16 bit value.
So why to have 32 bits return value of readReg() if only 16 bits are used?
This I call code transparency and optimization.

Anyway, in your code you are using functions with return values of 24 and 40 bit width, too.
This, although it may be necessary, but is also not quite "usual" and conforming to any standard, isn't it?
I don't want to be picky, just to point out that one adapt the software to the actual needs. This is the basis for evolution :)

I would be more than happy if you would send me some PRs to fix some bugs or suggest improvements for the lib a forked and adapted from Adafruit.
Btw, I really appreciate your work with MCUFRIEND_kbv lib, but I wanted to keep being somehow "compliant" with original Adafruit lib.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest