RTFM is the universal answer for all of this. There may be some tutorials, = but they likely won't cover the particular LCD you are using - that said, t= ry Googling. The "M"'s in "RTFM" are the datasheets for the LCD and the FPG= A. Don't get overwhelmed by the size of the datasheets/manuals - odds are that= you don't need 90% of what's in them - stick with the basics. - First start electrically - what does the data sheet for the LCD say is th= e electrical format of the signals it accepts? (3.3V TTL? LVDS? 1.8V logic?= etc.). Then see the FPGA data sheet to see if you can find an IO standard = that matches. Hook the two up accordingly. - Next, write some basic VHDL/verilog/UCF files for the FPGA to instantiate= the signals to the LCD in your FPGA and set everything to the appropriate = IO standard. - Then dig into the LCD datasheet again and figure out what commands or dat= a formating it needs and get cracking on a VHDL/verilog state machine or da= ta formatter that accomplishes whatever it is that you want to do with the = LCD. Depending on the application it was meant for, most LCDs are either co= mmand and buffer based (that is, you write some commands to it, then write = to a frame buffer on the LCD controller), or they are video stream based (i= .e. no commands necessary, just send raw RGB data continuously). Hope that helps. Chris
Re: tft lcd with xilinx fpga
Started by ●January 25, 2011
Reply by ●January 25, 20112011-01-25
On Jan 25, 8:44=A0am, Chris Maryan <kmar...@gmail.com> wrote:> RTFM is the universal answer for all of this. There may be some tutorials=, but they likely won't cover the particular LCD you are using - that said,= try Googling. The "M"'s in "RTFM" are the datasheets for the LCD and the F= PGA.> > Don't get overwhelmed by the size of the datasheets/manuals - odds are th=at you don't need 90% of what's in them - stick with the basics.> > - First start electrically - what does the data sheet for the LCD say is =the electrical format of the signals it accepts? (3.3V TTL? LVDS? 1.8V logi= c? etc.). Then see the FPGA data sheet to see if you can find an IO standar= d that matches. Hook the two up accordingly.> > - Next, write some basic VHDL/verilog/UCF files for the FPGA to instantia=te the signals to the LCD in your FPGA and set everything to the appropriat= e IO standard.> > - Then dig into the LCD datasheet again and figure out what commands or d=ata formating it needs and get cracking on a VHDL/verilog state machine or = data formatter that accomplishes whatever it is that you want to do with th= e LCD. Depending on the application it was meant for, most LCDs are either = command and buffer based (that is, you write some commands to it, then writ= e to a frame buffer on the LCD controller), or they are video stream based = (i.e. no commands necessary, just send raw RGB data continuously).> > Hope that helps. > > ChrisOK posting directly here since I kept screwing it up on FPGARelated.com I think I have gotten it...well sort of. I found a good VHDL example for driving a VGA monitor and have modified it to work with the LCD... I got it working and changing the colors on the screen. I have modified it further, but I keep getting the following errors now: Line 32. The type of the element in aggregate does not correspond to any array type. Line 44. The type of the element in aggregate does not correspond to any array type. Line 32 is: if (h_counter =3D> "0111100010") and (h_counter <=3D "1000001011") then Line 44 is: if (v_counter =3D> "0100010010") and (v_counter <=3D "0100011100") then What am I doing wrong? I am still learning VHDL so bear with me...
Reply by ●January 25, 20112011-01-25
On Jan 25, 12:39=A0pm, Lou <lciot...@gmail.com> wrote:> On Jan 25, 8:44=A0am, Chris Maryan <kmar...@gmail.com> wrote: > > > RTFM is the universal answer for all of this. There may be some tutoria=ls, but they likely won't cover the particular LCD you are using - that sai= d, try Googling. The "M"'s in "RTFM" are the datasheets for the LCD and the= FPGA.> > > Don't get overwhelmed by the size of the datasheets/manuals - odds are =that you don't need 90% of what's in them - stick with the basics.> > > - First start electrically - what does the data sheet for the LCD say i=s the electrical format of the signals it accepts? (3.3V TTL? LVDS? 1.8V lo= gic? etc.). Then see the FPGA data sheet to see if you can find an IO stand= ard that matches. Hook the two up accordingly.> > > - Next, write some basic VHDL/verilog/UCF files for the FPGA to instant=iate the signals to the LCD in your FPGA and set everything to the appropri= ate IO standard.> > > - Then dig into the LCD datasheet again and figure out what commands or=data formating it needs and get cracking on a VHDL/verilog state machine o= r data formatter that accomplishes whatever it is that you want to do with = the LCD. Depending on the application it was meant for, most LCDs are eithe= r command and buffer based (that is, you write some commands to it, then wr= ite to a frame buffer on the LCD controller), or they are video stream base= d (i.e. no commands necessary, just send raw RGB data continuously).> > > Hope that helps. > > > Chris > > OK posting directly here since I kept screwing it up on > FPGARelated.com > > I think I have gotten it...well sort of. =A0I found a good VHDL example > for driving a VGA monitor and have modified it to work with the LCD... > I got it working and changing the colors on the screen. =A0 I have > modified it further, but I keep getting the following errors now: > > Line 32. The type of the element in aggregate does not correspond to > any array type. > > Line 44. The type of the element in aggregate does not correspond to > any array type. > > Line 32 is: > > if (h_counter =3D> "0111100010") and (h_counter <=3D "1000001011") then > > Line 44 is: > > if (v_counter =3D> "0100010010") and (v_counter <=3D "0100011100") then > > What am I doing wrong? I am still learning VHDL so bear with me...VHDL does not understand ">=3D" for vectors - vectors are just a pile of bits to VHDL - it doesn't know if the left or right bit is the most significant bit. You need to convert them to numbers to test for larger or smaller. There are standard packages to do this. Try looking here: <http://www.cs.umbc.edu/portal/help/VHDL/ stdpkg.html> RK
Reply by ●January 26, 20112011-01-26
On Tue, 25 Jan 2011 13:31:46 -0800 (PST), d_s_klein <d_s_klein@yahoo.com> wrote:>On Jan 25, 12:39�pm, Lou <lciot...@gmail.com> wrote: >> On Jan 25, 8:44�am, Chris Maryan <kmar...@gmail.com> wrote: >> >> > RTFM is the universal answer for all of this. There may be some tutorials, but they likely won't cover the particular LCD you are using - that said, try Googling. The "M"'s in "RTFM" are the datasheets for the LCD and the FPGA. >> >> > Don't get overwhelmed by the size of the datasheets/manuals - odds are that you don't need 90% of what's in them - stick with the basics. >> >> > - First start electrically - what does the data sheet for the LCD say is the electrical format of the signals it accepts? (3.3V TTL? LVDS? 1.8V logic? etc.). Then see the FPGA data sheet to see if you can find an IO standard that matches. Hook the two up accordingly. >> >> > - Next, write some basic VHDL/verilog/UCF files for the FPGA to instantiate the signals to the LCD in your FPGA and set everything to the appropriate IO standard. >> >> > - Then dig into the LCD datasheet again and figure out what commands or data formating it needs and get cracking on a VHDL/verilog state machine or data formatter that accomplishes whatever it is that you want to do with the LCD. Depending on the application it was meant for, most LCDs are either command and buffer based (that is, you write some commands to it, then write to a frame buffer on the LCD controller), or they are video stream based (i.e. no commands necessary, just send raw RGB data continuously). >> >> > Hope that helps. >> >> > Chris >> >> OK posting directly here since I kept screwing it up on >> FPGARelated.com >> >> I think I have gotten it...well sort of. �I found a good VHDL example >> for driving a VGA monitor and have modified it to work with the LCD... >> I got it working and changing the colors on the screen. � I have >> modified it further, but I keep getting the following errors now: >> >> Line 32. The type of the element in aggregate does not correspond to >> any array type. >> >> Line 44. The type of the element in aggregate does not correspond to >> any array type. >> >> Line 32 is: >> >> if (h_counter => "0111100010") and (h_counter <= "1000001011") thenif h_counter>=482 and h_counter<=523... Although probably more efficient to generate a latched signal that is set on the values than do a greater/less than comparison : if h_counter=482 then window<='1'; elsif h_counter=523 then window<='0'; end if;>RK
Reply by ●January 26, 20112011-01-26
I am using the following standard libraries: use IEEE.std_logic_1164.all; use IEEE.std_logic_arith.all; use IEEE.std_logic_unsigned.all; I tried going from binary to decimal, and still get the same error....
Reply by ●January 26, 20112011-01-26
On Jan 26, 8:05=A0am, Lou <lciot...@gmail.com> wrote:> I am using the following standard libraries: > > use IEEE.std_logic_1164.all; > use IEEE.std_logic_arith.all; > use IEEE.std_logic_unsigned.all; > > I tried going from binary to decimal, and still get the same error....I changed the =3D> to <=3D and it worked... stupid error... Of course now I get nothing dispaying again... Part of my problem is I cannot locate the datasheet for this display. It is a TFT plug in module from HUINS (www.huins.com). Website does not contain any datasheets. Tried to e-mail them and got no response.
Reply by ●January 26, 20112011-01-26
OK. I finally got the display working. WOOO HOOO... Now my understanding is that to get characters on the display I have to create a character rom, and a frame buffer. The character rom I understand. I plan on making a rom that bisically contains 1's where ever a pixel is on for each character. I plan on a 8x8 font. This should give me 34 lines with 60 characters. I am a little confused on the frame buffer portion. Any pointers on where to look for information on this?
Reply by ●January 27, 20112011-01-27
On Wed, 26 Jan 2011 12:40:54 -0800 (PST), Lou <lciotti1@gmail.com> wrote:>OK. I finally got the display working. WOOO HOOO... > >Now my understanding is that to get characters on the display I have >to create a character rom, and a frame buffer. The character rom I >understand. I plan on making a rom that bisically contains 1's where >ever a pixel is on for each character. I plan on a 8x8 font. This >should give me 34 lines with 60 characters. > >I am a little confused on the frame buffer portion. Any pointers on >where to look for information on this?Your frame buffer holds the character for each display position. Typically using dual port BlockRAM - a read port feeding data to the display and a write port to update the display contents. Use initialisation data to put something in it to start with so you can get the display part working before worrying about the writing to it. The buffer read address is derived from your X/Y character position counts, and the output goes to the address input of your character ROM to select the character displayed at each position. The lower-order addresses of X/Y determine the address within each character definition. .
Reply by ●January 27, 20112011-01-27
On Jan 27, 4:18=A0am, Mike Harrison <m...@whitewing.co.uk> wrote:> On Wed, 26 Jan 2011 12:40:54 -0800 (PST), Lou <lciot...@gmail.com> wrote: > >OK. =A0I finally got the display working. =A0WOOO HOOO... > > >Now my understanding is that to get characters on the display I have > >to create a character rom, and a frame buffer. =A0The character rom I > >understand. =A0I plan on making a rom that bisically contains 1's where > >ever a pixel is on for each character. =A0I plan on a 8x8 font. =A0This > >should give me 34 lines with 60 characters. > > >I am a little confused on the frame buffer portion. =A0Any pointers on > >where to look for information on this? > > Your frame buffer holds the character for each display position. Typicall=y using dual port BlockRAM> - a read port feeding data to the display and a write port to update the =display contents. Use> initialisation data to put something in it to start with so you can get t=he display part working> before worrying about the writing to it. > > The buffer read address is derived from your X/Y character position count=s, and the output goes to> the address input of your character ROM to select the character displayed=at each position. The> lower-order addresses of X/Y determine the address within each character =definition.> .Hmmm...I am still lost. All this digital stuff is new to me, and I am trying to learn this as fast as possible. (BTW I am not a student, this is just my hobby, if you can call this a hobby... lol, so I am not looking for homework answers lol... Only been playing with FPGAs for about 1 month) So lets see... I dicided to go with a 6x8 font.. that will give me 80 characters across rather than the 60. (Tell me if this complicates things) My understanding is that the frame buffer will contain all the data for each pixel. So with 480x272 TFT, that is a total of 130560 pixels or bits I have to somehow load into memory. I have a working block for the Character Rom, basically organized as an array of std_logic_vector values for each character, accessed by an address value corresponding to 1 row of pixels (6 bits). Now to get this into the FrameBuffer, I need the following to somehow map these rows of pixels to the correct location. I just can't picture how to store this in RAM, and be easily addressable.
Reply by ●January 27, 20112011-01-27
Lou <lciotti1@gmail.com> wrote: (snip)> So lets see... I dicided to go with a 6x8 font.. that will give me 80 > characters across rather than the 60. (Tell me if this complicates > things)> My understanding is that the frame buffer will contain all the data > for each pixel. So with 480x272 TFT, that is a total of 130560 pixels > or bits I have to somehow load into memory.Tradition, going back many years now, is to do the character ROM lookup on the fly, storing the character codes in RAM. When your PC starts up it will usually be in a character display mode that works that way.> I have a working block for the Character Rom, basically organized as > an array of std_logic_vector values for each character, accessed by an > address value corresponding to 1 row of pixels (6 bits).If you need both characters and graphics on the screen at the same time, though, it is usual to store the character pixels in display RAM.> Now to get this into the FrameBuffer, I need the following to somehow > map these rows of pixels to the correct location. I just can't > picture how to store this in RAM, and be easily addressable.-- glen
