I have a working LCD using hardware SPI and would like it to appear as a frambuffer.
Anybody know a lot about this sort of thing willing to help?
Currently I have to modify each program to put the LCD driver into it, if I had a working framebuffer I could simply port SDL and run any SDL code on the VoCore.
LCD Framebuffer
- Pyrofer
- Posts: 61
- Joined: Tue Oct 21, 2014 11:35 am
Re: LCD Framebuffer
So a little update.
I used the virtual frame buffer driver on VoCore to get /dev/fb0.
I fbset the screen size colour etc to match my LCD and wrote a userspace app to copy the contents of fb0 to the LCD over hardware SPI.
This has the advantage of no kernel hackery and it's easy to write a different app for each LCD that people want to use.
So I now have a working framebuffer on the VoCore that is displayed on the LCD.
Ok, so the CPU is 100% all the time but if anybody wants to help with dirty page detection I would appreciate it!
I used the virtual frame buffer driver on VoCore to get /dev/fb0.
I fbset the screen size colour etc to match my LCD and wrote a userspace app to copy the contents of fb0 to the LCD over hardware SPI.
This has the advantage of no kernel hackery and it's easy to write a different app for each LCD that people want to use.
So I now have a working framebuffer on the VoCore that is displayed on the LCD.
Ok, so the CPU is 100% all the time but if anybody wants to help with dirty page detection I would appreciate it!
- CodeAsm
- Posts: 3
- Joined: Tue Oct 21, 2014 9:55 am
Re: LCD Framebuffer
Sounds awesome, i will definitly take a look. But my coding skills especialy in linux are still baby steps from zero. Noob question, is it in c / cpp?
- Pyrofer
- Posts: 61
- Joined: Tue Oct 21, 2014 11:35 am
Re: LCD Framebuffer
And another update.
SDL and SDL_Image running along with /dev/fb0
I compiled a small image viewer SDL app and popped some jpgs into it,
I need to get a second CS pin on the SPI to get touch screen working next.
SDL and SDL_Image running along with /dev/fb0
I compiled a small image viewer SDL app and popped some jpgs into it,
I need to get a second CS pin on the SPI to get touch screen working next.
- ReeseNator
- Posts: 1
- Joined: Fri Oct 24, 2014 11:50 pm
Re: LCD Framebuffer
Wow, thats really cool! I'd like to help (I also have some ideas as to how that can be used)
- pezze
- Posts: 2
- Joined: Thu Nov 06, 2014 1:38 pm
Re: LCD Framebuffer
Cool! I've the same LCD screen. Can you post scheme and code of your work somewhere please?
So I can start to help you. I'm not good in electronics ma can help you in develop some applications.
Thanks.
So I can start to help you. I'm not good in electronics ma can help you in develop some applications.
Thanks.
- pezze
- Posts: 2
- Joined: Thu Nov 06, 2014 1:38 pm
Re: LCD Framebuffer
Cool! Could you please post scheme and drivers somewhere, i.e. github? I've the same LCD screen.
So I can help you to develop some new software (I'm not as good in electronic).
Thanks.
Alessandro
So I can help you to develop some new software (I'm not as good in electronic).
Thanks.
Alessandro
- Pyrofer
- Posts: 61
- Joined: Tue Oct 21, 2014 11:35 am
Re: LCD Framebuffer
First step is to get virtual Framebuffer working. Then I have a binary that will dump the fb0 onto the LCD over SPI.
Hooking up the SPI is easy. You need to set the LCD into 4wire SPI mode so there is a data/command line as well as chip select and reset.
I compiled fbset in so I could set the framebuffer to 320 x 240 x 16 rgb565
I got my full VoCore (non-alpha) today so as soon as I hook that up to a breakout board I will try getting SPI+Touch screen working. As there is only one CS I will need to manually bitbang the LCD control again, which drops the framerate
I have ordered another cheap LCD from ebay and am planning on making a native framebuffer driver for it as it's easily available right now for people with the vocore.
Hooking up the LCD is as easy as connecting the SPI clk/dat/cs as well as a couple GPIO for rst and d/c. I think I used GPIO 19 and 20.
When the LCD is running it thrashes the SPI bus constantly so read/write from the flash chip is diabolically slow. I run everything from /tmp in ram to avoid that problem.
Hooking up the SPI is easy. You need to set the LCD into 4wire SPI mode so there is a data/command line as well as chip select and reset.
I compiled fbset in so I could set the framebuffer to 320 x 240 x 16 rgb565
I got my full VoCore (non-alpha) today so as soon as I hook that up to a breakout board I will try getting SPI+Touch screen working. As there is only one CS I will need to manually bitbang the LCD control again, which drops the framerate
I have ordered another cheap LCD from ebay and am planning on making a native framebuffer driver for it as it's easily available right now for people with the vocore.
Hooking up the LCD is as easy as connecting the SPI clk/dat/cs as well as a couple GPIO for rst and d/c. I think I used GPIO 19 and 20.
When the LCD is running it thrashes the SPI bus constantly so read/write from the flash chip is diabolically slow. I run everything from /tmp in ram to avoid that problem.
- evilbluechickens
- Posts: 1
- Joined: Fri Nov 14, 2014 2:07 am
Re: LCD Framebuffer
You are magical sir. I'm going to try and get this working: http://www.dx.com/p/bonatech-0-96-inch- ... lue-295842
- Pyrofer
- Posts: 61
- Joined: Tue Oct 21, 2014 11:35 am
Re: LCD Framebuffer
For a screen that tiny you can probably manually bitbang the GPIO fast enough. Even my 128x128x8 screen runs Doom more than full speed with manual GPIO SPI.
Of course there is no real reason NOT to use hardware SPI for the screen as long as you don't just keep thrashing the data out like my drivers. If you hog the bus the flash chip read/write goes down the pan and doing anything is painful.
So you should look at only updating parts of the screen that are changed and only when they change, that way the SPI bus should be more free for IO on other devices.
Of course there is no real reason NOT to use hardware SPI for the screen as long as you don't just keep thrashing the data out like my drivers. If you hog the bus the flash chip read/write goes down the pan and doing anything is painful.
So you should look at only updating parts of the screen that are changed and only when they change, that way the SPI bus should be more free for IO on other devices.
Who is online
Users browsing this forum: No registered users and 113 guests