GDISP driver

[colombo]

Hi Abhishek,

thank you for your reply.

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

Good

The Address pin is connected to RS which is the A16 pin on the F4

I was lost D11 pin alternate and the comment /* Using FSMC A16 as RS */

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.

Thank you for this work.

I see in STM32F4Discovery some pins of FSMC is shared with other peripherals, for example PD4/FSMC_NOE is connected to Audio_Rst and has a 10K(R43) pull-down.
Does not create problems?

Another doubt

Code: Select all

/* Using FSMC A16 as RS */
#define LCD_REG (*((volatile uint16_t *) 0x60000000)) /* RS = 0 */
#define LCD_RAM (*((volatile uint16_t *) 0x60020000)) /* RS = 1 */


0x60020000 => 1100000000000100000000000000000
Does set A17? Is it correct?

Best Regards
colombo

[Badger]

I see in STM32F4Discovery some pins of FSMC is shared with other peripherals, for example PD4/FSMC_NOE is connected to Audio_Rst and has a 10K(R43) pull-down.
Does not create problems?

On my board I removed the chips, resistors etc that had shared features with FSMC. I'm not sure if it was necessary, I did it as part of troubleshooting whilst implementing the FSMC code and found the problem to be elsewhere, but didn't bother putting the chips back.

Another doubt

Code: Select all

/* Using FSMC A16 as RS */
#define LCD_REG (*((volatile uint16_t *) 0x60000000)) /* RS = 0 */
#define LCD_RAM (*((volatile uint16_t *) 0x60020000)) /* RS = 1 */


0x60020000 => 1100000000000100000000000000000
Does set A17? Is it correct?

I was also somewhat confused by this convention, but it does indeed seem to be correct, even if it goes against intuition.

[mobyfab]

I only removed the USB over current resistor

The address pin is A16.

[Tectu]

Thanks for your contribution, Mobyfab!!!

[mobyfab]

Thanks for your contribution, Mobyfab!!!

You're welcome

Now working on GWEN

[colombo]

I only removed the USB over current resistor

47K R51 Pull-up 3V. Rigth?

[mobyfab]

Don't remember, check on the discovery datasheet

Otherwise I have started integrating GWEN to ChibiOS: http://github.com/mobyfab/ChibiOS-Gwen

It compiles but does nothing as I haven't really started to port it.
it *should* not be too complicated to port.

There is an example here: https://github.com/mobyfab/ChibiOS-Examples/tree/master/STM32F4-LCD-GWEN

FYI the code is around 308k with GWEN displaying a skinned button.
The gdisp demo is 14k in C, 245k in C++. So the GWEN overhead is around 63k.

[miguelmoreto]

To Badger and colombo:

0x60020000 => 1100000000000100000000000000000
Does set A17? Is it correct?

This address sets A16. FSMC controller shifts it right by 1 when FSMC is used to address data of 16bits. See Table 164, page 1227 of STM32F407VG reference manual (document DM00031020).

I had the same doubt until reading this FSMC documentation.

Best regards,

Miguel

[Badger]

This address sets A16. FSMC controller shifts it right by 1 when FSMC is used to address data of 16bits. See Table 164, page 1227 of STM32F407VG reference manual (document DM00031020).

I spent a little while trying to understand what was going on, thanks for the explanation

[mobyfab]

Found out the string class is taking up around 120k of code

I'll try to find an alternative, much lighter class.

The C++ example takes 18K of code without the string class or using new.
with new it goes up to 90K of code.