GDISP driver

Abhishek
Posts: 266
Joined: Wed May 23, 2012 3:15 pm
Location: India

Re: GDISP driver

Postby Abhishek » Wed Sep 05, 2012 3:20 pm

Here's some useful info:

A C++ abstraction for STM32 HW around the STD_Periphlib:
http://andybrown.me.uk/wk/2011/12/28/st ... velopment/

It contains tips for implementing the new operator - we can use the ChibiOS heap allocator.

mobyfab
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

Postby mobyfab » Wed Sep 05, 2012 4:20 pm

Using some of his code I reduced the C++ example, still using strings, to 33K of code.

The cost of using new/delete went from 78K of code to 1K.

The stringstream class was taking up 150K of code!

I will need to review all includes in Gwen, I guess there are major improvements to be made.

edit: after disabling a couple string<->unicode conversion function, we are down to 120kb from 253kb.

mobyfab
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

Postby mobyfab » Fri Sep 07, 2012 10:08 pm

I updated the C++ example with touchpad support.

Also I added touchpad support to the GWEN port.

miguelmoreto
Posts: 15
Joined: Thu Jun 28, 2012 9:21 pm
Location: Brazil
Contact:

Re: GDISP driver

Postby miguelmoreto » Tue Sep 11, 2012 10:01 pm

Hello,

I compiled ChibiOS/GFX for STM32F4 discovery with SSD1289 driver using FSMC. It works, I just copied the same FSMC pins and registers configuration code from SSD1963 driver.

Unfortunately I cannot use touchpad, changed SPI initialization to use SPI3 (GPIOC, 10, 11 and 12, CS pin 9 and IRQ pin 8). The calibration routine starts and responds to touch but after that the system is showing a very strange behavior. I have to perform more tests, check the SPI config, etc. But not using touchpad, the screen from notepad demo is showing correctly.

Best regards,

Miguel

User avatar
Tectu
Posts: 1226
Joined: Thu May 10, 2012 9:50 am
Location: Switzerland
Contact:

Re: GDISP driver

Postby Tectu » Wed Sep 12, 2012 10:49 am

Hello Miguel,

Do I understand this correctly? You can make the calibration but after that it dosen't work anymore?
When you call tpCalibrate() and you tap the first cross, it does dissappear and the second one shows up?
What exactly is "strange behaviour"? I do have to check the tpCalibrate() routine tonight. There was a change a few days ago and I didn't try after that, but it should work.

Meanwhile, make sure you are in portrait mode.


~ Tectu

mobyfab
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

Postby mobyfab » Wed Sep 12, 2012 11:09 am

FYI, even if SPI is not working, the calibration will execute as if it would work.

It is only checking if the irq pin goes high.

So you better check your SPI ;)

miguelmoreto
Posts: 15
Joined: Thu Jun 28, 2012 9:21 pm
Location: Brazil
Contact:

Re: GDISP driver

Postby miguelmoreto » Wed Sep 12, 2012 2:26 pm

Hello Tectu and Mobyfab,

the calibration routine executes, after pressing the first cross, the second one shows up, like Mobyfab stated, I can only confirm the irq pin is being read. I belive the problem is with SPI, because I am using SPI3. I still have to do more tests, this is the reason why I didn't describe the problem very well. After calibration screen, the LCD is not updated anymore (in the main loop).

I just want to let you know that GDISP work with FSMC and a SSD1289 controller using part of the init code from SSD1963 (FSMC setup and pin configuration).

I will test SPI with more detail, after that, if I don't find out the problem I will describe it better to you.

Best regards and thank you!

Miguel

mobyfab
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

Postby mobyfab » Mon Sep 17, 2012 4:26 pm

Something I was thinking about.

I will try to implement DMA in the fillrect function for the SSD1963.
This function is probably doing 80% of the work so I think it is worth trying to save some CPU cycles.
Same for the bmp drawing function.

I also need to find from which number of pixels DMA is effective against CPU. Drawing a 10px line might not be worth it, but a 10000px+ rectangle is for sure :)

Basically the idea is to start the DMA and wait for it to complete, by putting the thread to sleep. therefor the other threads can use the CPU, and the other requests will not overlap.

User avatar
Badger
Posts: 346
Joined: Mon Apr 18, 2011 6:07 pm
Location: Bath, UK
Contact:

Re: GDISP driver

Postby Badger » Mon Sep 17, 2012 5:31 pm

Mobyfab, I think that is a good idea, I have been planning to do it myself for some time! Maybe the best way to implement it would be to first move all of the 8080 16(/8)bit interface logic into one place, as it appears to be identical amongst various devices. Then any improvements can apply to all supported displays.

I think there should be two modes; one to write a single value in each pixel, and another to write a from a buffer. I will help with this if you don't manage to do it before I get a chance :D

User avatar
Giovanni
Site Admin
Posts: 14455
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1076 times
Been thanked: 922 times
Contact:

Re: GDISP driver

Postby Giovanni » Mon Sep 17, 2012 6:20 pm

Consider that DMA operations are VERY fast, waiting for an interrupt would probably cost more than just transfer. It is also possible to start a DMA operation and *poll* for completion, that would be faster.

Of course it depends on the amount of data to be transferred.

In general:
Small data: use CPU.
Larger: use DMA and poll for completion.
Very Large: use DMA and suspend the thread waiting for completion.

Giovanni


Return to “LCD Driver and Graphic Framework”

Who is online

Users browsing this forum: No registered users and 10 guests