FSMC provides fast and flexible connection to external memory on high density STM32 processors.
FSMC is also suitable for connection to parallel interface TFT displays;
some STM32 boards have a FSMC TFT connector, e.g. Blue STM32F103VE or Black STM32F407VE/ZE/ZG boards.
Using of these libraries choised ILI9481 or HX8357 driver and "stm32f4 boards/generic stm32f407v series" board working fine. I manage to run the graphicstest.
If I use other tft library from steve I manage to upload the code but there is no works. What I noticed that the screen is fully white, and after uploading the code there is a screen for a short time ~ 100ms show some register data or someting, and the screen is again just fully white. In the serial monitor I can see the result times of lines, rectangles..
I noticed the previous statement If I use GXTFT lib with other hardvare lib from danieleff also with working serial monitor, coised stm32generic for stm32 boards/ black f407ve/ze/zg boards
I do not understand your question. Please state clearly each combination your tried and if it works or not.
There is a button to insert links, use it, so the link can be clicked.
Attach a picture of your wiring, as your display is for Arduino Mega and does not match directly to the STM32 board.
You sent me a personal message with a similar but different question, it was a bit clearer:
Hello
Maybe you can help Me. I purchased black stm32f407vet6 board and 16bit mega shiled tft.
I downloaded your gxtft library and use the danieleff/STM32GENERIC hardware library. I managed to upload the GxTFT_FSMC_BlackSTM32F407V.ino test file after some modification. Choised Black f407VE/GE/GZ board. When the uploading is done the tft show some register data for a very short time ~100ms and after it is white than before programing. At the serial monitor list also some register data and the time of benchmark. What would be the problem in this case?
Using of other hardware library rogerclarkmelbourne and choise f407v board the tft and serial port also works with GxTFT_graphicstest.ino file.
The hardware and wiring is the same in both cases
The difference between the two test ino file
first case just white #include <GxIO/STM32GENERIC/GxIO_STM32F4_FSMC/GxIO_STM32F4_FSMC.cpp> #include <GxIO/GxIO.cpp>// #include <GxCTRL/GxCTRL.cpp> //
second case working #include <GxIO/GxIO_STM32F407V_P16/GxIO_STM32F407V_P16.h> #include "GxTFT_IncludeCpp.h"
For this question I assume that your display can't take the fast timing of the FSMC version.
Maybe someone else can answer for the question with the Adafruit library.
Sorry for my bad english and difficult description. Now I know a litte bit more.
The connection in my case is same like in your description. My TFT has different pin out to using directly on the board but I prepared a cord to connect them easily. One difference is that my TFT dont has RD pin.
I use roger repo for dunio and danieleff for generic board.
My tft working well with arduino mega and original bodmer library. It is super fast compared to Mcufriend lib.
You mentioned in the description the HX8357 libs ar not tested yet. Unfortunatelly there is a little problem with them. I dont know what but I can not upload the sketch I got error message. Choised ILI9481 there is no this porblem.
My configuration in the graphics test was:
roger repo #include "../GxIO/GxIO_STM32F407V_P16/GxIO_STM32F407V_P16.h" #include <GxCTRL/GxCTRL_ILI9481/GxCTRL_ILI9481.cpp>
TFT_Class tft(io, controller, 320, 480); // landscape 480x320
In this case I can upload the sketch and the screen works but were miroring and rotating problem...
I modified the ILI9481 driver files (because of the upload problem of your HX8357 driver) added HX8357C registers. Now I can choise what kind of tft want to use ILI9481 or HX8357C inside the ILI9481 driver.
The screen with these modification is perfect.
But If I understand well these configuration just use 16bit mode on FSMC pins
If I want to use FSMC mode I have to use these lines. #include <GxIO/STM32DUINO/GxIO_STM32F4_FSMC/GxIO_STM32F4_FSMC.h> #include <GxCTRL/GxCTRL_ILI9481/GxCTRL_ILI9481.cpp>
TFT_Class tft(io, controller, 320, 480); // landscape 480x320
If I upload this sketch I can see some register data for a moment and the screen white but in serial monitor the bencmark is running.
Changing of DATAST and ADDSET values did not help.
I think If the 16bit mode works the connection between the TFT and board are OK. Am I right?
Is there any effect for the tft driver If I use 16bit mode or FSMC mode? I mean If the driver is Ok in 16bit mode I can it also use to FSMC mode.
Any effect missing of RD pin?
There are 2 informations missing: a picture of your hardware wiring, and the error message of your upload issue.
I do have this display, as you can see in the directory myTFTs, but I have not tried to use it with any STM32 board, as far as I remember, because of the need for special physical wiring, and because I am more interested in bigger displays. The HVGA 480x320 was just my starting point for creating my GxTFT library.
The issue is interesting enough, and I now have enough DuPont wires around, so I will investigate myself. But currently my main field of activity is e-paper displays.
You have already experimented with DATAST and ADDSET; this was the suggestion I intended to make.
The missing RD pin should make no difference; only the register values will be meaningless.
Please report any of your findings, or additional questions. I will report my findings as soon as available.
Thank you
Jean-Marc
There may be a simple reason for the FSMC issue on these displays:
FSMC activates the CS line once per transfer, as you would expect for memories.
Some display controllers expect multi-byte transfers with constant CS activation.
As far as I remember, this is so for the HVGA display.
There is e.g. the writeAddrMSBfirst(uint16_t d) method used in setAddrWindow() for this reason.
Don't know if it makes sense to do special GxIO_xxx_FSMC classes for this.
If I use your original HX8357C driver
error: default argument given for parameter 2 of 'uint32_t GxCTRL_HX8357C::readRegister(uint8_t, uint8_t, uint8_t)' [-fpermissive]
As I aspected the error code related to the file name. If I rename the working ILI9481 driver's folder name, C and H file name and these three lines in the files #include "GxCTRL_ILI9481.h" #ifndefGxCTRL_ILI9481_H #defineGxCTRL_ILI9481_H
the same error come up.
Regarding these values DATAST and ADDSET I will try check them in the datasheet and use the largest value. In the driver file there are some delay line among the register data lines I will try increase them also.
Obviously I did not check-compile all combinations; there are so many.
This typical copy/paste - related error happens to me all the time, but usually I discover it.
Did you notice my addition regarding the most likely cause of the FSMC issue?
If you really want to use this display with FSMC, I can provide modified IO classes with alternate CS handling for FSMC. I think I will do that in any case, sometime.
ZinggJM:
There may be a simple reason for the FSMC issue on these displays:
FSMC activates the CS line once per transfer, as you would expect for memories.
Some display controllers expect multi-byte transfers with constant CS activation.
As far as I remember, this is so for the HVGA display.
There is e.g. the writeAddrMSBfirst(uint16_t d) method used in setAddrWindow() for this reason.
Don't know if it makes sense to do special GxIO_xxx_FSMC classes for this.
The question is, do you want to use it with FSMC, or is the _P16 IO class good enough for your purpose?
Actually the speed in 16bit mode not too fast. Therefore I prefer using FSMC
I want to display some picture on the tft reading from SD card or SPI flash.
In the meantime you can use the _P16 IO class. Or use a Arduino MEGA, or Arduino DUE with adapter shield for speed.
FSMC or _P16 are not different modes; both use 16bit data lines.
FSMC is a feature of the processor, and it maps data and address lines to GPIO pins, so that lines are in a sequence to easily connect to memory chips or IO connectors, e.g. TFTs.
The _P16 class for STM32 uses bit mangling to achieve the same mapping, which is slower.
The _P16 class for MEGA does not need bit mangling, because this TFT is made for the MEGA connector.
The _P16 class for Due also uses bit mangling, as the Due GPIO pins are in a different sequence.
In the Arduino ecosystem you find TFTs as shields or shields for TFTs that match with Arduino connectors, to make your life easy.
In the STM32 world you can find development boards or systems with matching displays, but you have less options.
Creating your own wiring is always an option, as is bit mangling in SW, but is time-consuming and error-prone.
Thanks for your help!
Bodmer/TFT_HX8357 lib use 2x8bit data lines for Arduino mega with good performance
What do you think this lib is can be implement to one port of stm? Port E did not used for any special I think it would be suitable. D0-PE0, D1-PE1...D15-PE15
I dont know how many times will be faster because of below reasons
mega 8bit, stm 32bit
mega 16Mhz, stm168Mhz
mega 2x8bit port , stm 1x16bit port
I will not try to guess for a number, but it will be fast as lightning.
But this library is specific for MEGA, as far as I remember, and maybe not easy to adapt.
The version for DUE uses bit mangling (I copied from there), but is still very fast on DUE.
For speed reason GPIO access is dispersed all over the code.
My IO class GxIO_MEGA_P16_MEGASHIELD is also for mega, but may be easier to adapt.
It will be slightly slower, but less than a factor of 2.
And you should also look at MCUFriend_kbv. I assume it supports STM32.
Both libraries provide many examples and excellent support.
If I understand well FSMC is a 16 bit mode. FSMC pins are in different pins but in the processor the FSMC feature makes these different pins virtually in one port. This is a hardvare feature therefore transported the pins to one port not load the processor like as bit banging.
And mainly the data pins (D0-D15) needed this feature. The control pins can work with any pins.
16 bit mode without FSMC need to conned D0-portX0....D15-portx15, such way no need for bit banging and provided ~ same speed like as the FSMC.
Yes, FSMC can do it all in one 16 bit write to an address location. It produces the CS select signal, the C/D as address selection, and the data output in one processor instruction.
I do not understand if you have a question, or if you are just trying to find out what you want to do.
If you need any help with GxTFT, let me know.
Thank you for reporting the syntax error in those 2 classes; I have fixed it.
I am curious. Using the FSMC control pins for control but not in FSMC mode
And use full portE for data lines. On the 407 black board just two switches are connected to PE3 and PE4, its no problem.
Unfortunatelly my programing knowledge is not enough to make this changing.
Yes, you can use any pins of the FSMC TFT connector as GPIO pins for control, and 16 port bits for data. This will still be extremely fast on STM32F7xx.
From your last posts I thought you intend to connect your display to some other ports instead of the FSMC connector.
Using FSMC with the HVGA display is still of some interest for me, time will come to play with it, but my focus is currently on e-paper displays. There seems to be a growing interest for my GxEPD library.
I prefer bit-mangling in software over connection mangling in hardware.
But I finally got a working connection of my HVGA 480x320 3.2" TFT to my black STM32F407VET6 board.
The initial test with GxIO_STM32F407V_P16 produced this result:
The display works, but with distortions. The distortions are random, which means most likely caused by too high speed or too long wires for this speed, rather than wiring error.
I will try to repeat the test with a blue STM32F103ZET6 board (not used yet), which will be slower.
But I will postpone any attempts to use FSMC with this display, as it looks like it can't take the speed anyway.
Efforts to improve speed are justified for bigger TFTs, but for small TFTs there are enough libraries available with excellent speed.
