Don't use safepoint anymore, It is out of date. Safepoint does support the old glcd structure.
The local master works wonderfully.
~ Tectu
GDISP driver
Re: GDISP driver
After a little talk with inmarket the other week, we decided that GLCD won't be supported since his last commit. The last few contributions of him were always backported to GLCD which took a lot of time. Since GDISP is the way to go, GLCD got now removed. Everything in the halext directory moved one level up.
Please note that with this change, you need to include $(LCDSRC) and $(LCDINC) to your project Makefile again.
If anybody has problems with this big change, you can use the 'safepoint' branch or the tag 'v0.1.0' which were created before the level-up moving.
The directory 'old' contains the console, graph and gui code which will need to be ported.
~ Tectu
Please note that with this change, you need to include $(LCDSRC) and $(LCDINC) to your project Makefile again.
If anybody has problems with this big change, you can use the 'safepoint' branch or the tag 'v0.1.0' which were created before the level-up moving.
The directory 'old' contains the console, graph and gui code which will need to be ported.
~ Tectu
Re: GDISP driver
Hello All,
I've implemented 7-point median filtering into the touchpad driver, this incorporates into GDISP-touch the work I had done on touchpads in my first ChibiOS project in the user projects section [STM32F4 Wave Player GUI demo] - the touch gave me nightmares, and it took me days to get everything right. This helps a lot in noise reduction, screen drawing is more smooth.
The CONVERSIONS high level driver define the parameters for the averaging filter that was already there. But then it works great even with CONVERSIONS set to 1 (pass through - without averaging).
However from now on calibration of the touchpad before use is mandatory. I'll be implementing 3-point calibration, with an abstraction allowing it to read values hardcoded into flash, from external EEPROM or any other non-volatile storage. This may help, as it is not advisable to calibrate a touchscreen everytime before use.
Best Regards
Abhishek
I've implemented 7-point median filtering into the touchpad driver, this incorporates into GDISP-touch the work I had done on touchpads in my first ChibiOS project in the user projects section [STM32F4 Wave Player GUI demo] - the touch gave me nightmares, and it took me days to get everything right. This helps a lot in noise reduction, screen drawing is more smooth.
The CONVERSIONS high level driver define the parameters for the averaging filter that was already there. But then it works great even with CONVERSIONS set to 1 (pass through - without averaging).
However from now on calibration of the touchpad before use is mandatory. I'll be implementing 3-point calibration, with an abstraction allowing it to read values hardcoded into flash, from external EEPROM or any other non-volatile storage. This may help, as it is not advisable to calibrate a touchscreen everytime before use.
Best Regards
Abhishek
Re: GDISP driver
I can confirm that Abhisheks modifications improved the touchpad readout a lot! The noise before was horrible, it was about 5 pixels. Now everything works great!
I will work out a way to provide the user an interface for storing the calibration structure customly.
~ Tectu
I will work out a way to provide the user an interface for storing the calibration structure customly.
~ Tectu
-
- Posts: 483
- Joined: Sat Nov 19, 2011 6:47 pm
- Location: Le Mans, France
- Has thanked: 21 times
- Been thanked: 30 times
Re: GDISP driver
FYI the SSD1963 driver has been included in the main branch
Demo Video: http://www.youtube.com/watch?v=srvM57YTp_U
Running at around 20 millions pixels per second with some tuning. Which is one third of the FSMC max speed.
Demo Video: http://www.youtube.com/watch?v=srvM57YTp_U
Running at around 20 millions pixels per second with some tuning. Which is one third of the FSMC max speed.
Re: GDISP driver
Hi, this is my first message. I like your works. It's great!!!!
I have a STM32F4Discovery and a two LCDs one with SSD1963 driver and another with SSD1289. I would like to try FSMC with driver SSD1963, but I don't understand which connections I need to create to my LCD.
I see the source code of driver SSD1963, I see the alternate for PIN FSMC_D[0-15], FSMC_NWE, FSMC_NOE, FSMC_NE1.
I think D0-D15 is connected to FSMC_D[0-15], but I have doubts on CS, RS, WR and RD. For pin Reset I use a simple pin. Maybe pin RD is not used so it is always High.
FSMC is supported by driver SSD1289? I read comment /* FSMC setup. TODO: this only works for STM32F1 */
I think I can use the init code of driver SSD1963 also in SSD1289, so FSMC is supported for STM32F1 and STM32F4 in driver SSD1289.
I have a STM32F4Discovery and a two LCDs one with SSD1963 driver and another with SSD1289. I would like to try FSMC with driver SSD1963, but I don't understand which connections I need to create to my LCD.
I see the source code of driver SSD1963, I see the alternate for PIN FSMC_D[0-15], FSMC_NWE, FSMC_NOE, FSMC_NE1.
I think D0-D15 is connected to FSMC_D[0-15], but I have doubts on CS, RS, WR and RD. For pin Reset I use a simple pin. Maybe pin RD is not used so it is always High.
FSMC is supported by driver SSD1289? I read comment /* FSMC setup. TODO: this only works for STM32F1 */
I think I can use the init code of driver SSD1963 also in SSD1289, so FSMC is supported for STM32F1 and STM32F4 in driver SSD1289.
Re: GDISP driver
Hi colombo!
First of all, thank you for your appreciation for this lib.
Here's the pin assignment, hope this should clear your confusion:
FSMC_NWE = WR Signal of LCD
FSMC_NOE = RD Signal of LCD
FSMC_NE1 = CS Signal of LCD
The Address pin is connected to RS which is the A16 pin on the F4
And yes, you're right. We'll update the code soon, so that the I/O layer for all the FSMC/GPIO drivers for the QVGA LCDs and SSD1963 is in sync.
Feel free to discuss any further problems/confusions you have.
Best Regards
Abhishek
First of all, thank you for your appreciation for this lib.
Here's the pin assignment, hope this should clear your confusion:
FSMC_NWE = WR Signal of LCD
FSMC_NOE = RD Signal of LCD
FSMC_NE1 = CS Signal of LCD
The Address pin is connected to RS which is the A16 pin on the F4
And yes, you're right. We'll update the code soon, so that the I/O layer for all the FSMC/GPIO drivers for the QVGA LCDs and SSD1963 is in sync.
Feel free to discuss any further problems/confusions you have.
Best Regards
Abhishek
Return to “LCD Driver and Graphic Framework”
Who is online
Users browsing this forum: No registered users and 33 guests