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.
GDISP driver
-
- 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
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.
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.
-
- Posts: 15
- Joined: Thu Jun 28, 2012 9:21 pm
- Location: Brazil
- Contact:
Re: GDISP driver
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
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
Re: GDISP driver
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
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
-
- Posts: 15
- Joined: Thu Jun 28, 2012 9:21 pm
- Location: Brazil
- Contact:
Re: GDISP driver
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
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
-
- 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
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.
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.
Re: GDISP driver
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
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
- 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
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
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