Sign in
Search 68hc12
Subscribe to 68hc12
68hc12 by Keywords
68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC
Sponsor
Discussion Groups
See Also
Discussion Groups | 68HC12 | OT- Producing a video signal
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
OT- Producing a video signal - Adrian Vos - Oct 27 1:54:00 2004
|
Hi All, Sorry for the off topic post, but I am just after some direction. I want to make a box that has a processor of some description, and can output a PAL/NTSC signal so I can use a TV to present full colour graphical data. Does not need to be HCS12 or even motorola. I basically want to gather data down a serial communications connection and display graphs on a TV screen. Can anyone point me in the direction of where I might find out how to do this. I have never done this before. Ideally I would like a solution where I can just output what I want to a display memory, and the rest of the hard work is done in converting this bitmap image to a video signal. I believe TI have chipsets for this, but all I can see seems to work with MPEG based digital bit streams and convert them to analogue video signal. I am more after something analogous to a video card on a PC with a video memory. I am pretty good with the S12 and micros in general, but just have very limitted knowledge of analogue video signals. If anyone can point me in the direction of a email list or application not or something that can help me, that would be appreciated. Cheers, Adrian |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: OT- Producing a video signal - Robert Rolf - Oct 27 2:49:00 2004
|
Adrian Vos wrote: > Hi All, > > Sorry for the off topic post, but I am just after some direction. > > I want to make a box that has a processor of some description, and can > output a PAL/NTSC signal so I can use a TV to present full colour graphical > data. Does not need to be HCS12 or even motorola. I basically want to gather > data down a serial communications connection and display graphs on a TV > screen. What resolution? What color depth? How many off? At what target cost? There are many turn key solutions depending on your answers to the above questions. The brute force way is the ancient MC6845 CRT controller (as used on old CGA/VGA/EGA cards and some dual port RAM (or appropriately multiplexed) into some shift registers and encoder. Do you have FPGA skills? You can do all the timing with the FPGA and some external RAM for the refresh buffer. You might also want to look at hacking up an old ISA video card. The MC6845 they used is well documented and easy to program. You just need to hang a MC1377 ? RGB to NTSC/PAL encoder chip on it. > Can anyone point me in the direction of where I might find out how to do > this. I have never done this before. Ideally I would like a solution where I > can just output what I want to a display memory, and the rest of the hard > work is done in converting this bitmap image to a video signal. I believe TI > have chipsets for this, but all I can see seems to work with MPEG based > digital bit streams and convert them to analogue video signal. I am more And this is a problem how? 4:2:2 video is relatively easy to synthesize to feed the chip. Temic/Phillips have a number of chips that will take various standard form digital streams an encode them. They also have some decent app notes on what a video signal looks like. > after something analogous to a video card on a PC with a video memory. I am > pretty good with the S12 and micros in general, but just have very limitted > knowledge of analogue video signals. There are a couple of very old books that will get you started. "TV typewriter Cookbook" by Don Lancaster? comes to mind. Circa 1980. "Computer Video Demystified" by?? circa 1995. I am sure there are others that are more current. > If anyone can point me in the direction of a email list or application not > or something that can help me, that would be appreciated. Without a more complete specification for exactly what kind of video you need to produce (resolution and color depth), it's hard to point you at a optimum solution. Many of today's PC video cards can produce NTSC/PAL output, but they are a PITA to program from scratch, assuming that you can get the needed register specifications. I hope you realize that you cannot get much more than 320 color pixels across an NTSC screen because of the color encoding process. The red channel is band limited to about 1.5MHz, and the blue to 0.8 for NTSC. Fine line graphics look horrid in anything but black and white. I'd have to look up PAL specs. Before you invest too much time in this, try drawing the graphs you hope to produce, at the resolution you want, by using a PC video card with TV video out. Take a good look at the output under the conditions you expect to use it. E.G. with the monitor and shielding, etc. it will have. Only THEN will you know if this is the solution you want to pursue. I would suggest using RGB to an RGB monitor rather than encoded video. Hope this helps. Robert |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: OT- Producing a video signal - Nigel Johnson - Oct 27 5:46:00 2004
|
Hi Adrian, you need something like this: http://www.technologicalarts.com/myfiles/specials.html which we sell where I work. It takes SCI data as input and generates video, which it overlays on incoming video. You then just send ascii data! When I say "like", there are two ways that the one we sell doesn't exactly fit the bill: 1) it is only NTSC 2) it generates RS170 (baseband) video - you then need a modulator to get it up to a television channel. Hope it helps, Regards, Nigel At 02:54 2004-10-27, you wrote: >Hi All, > >Sorry for the off topic post, but I am just after some direction. > >I want to make a box that has a processor of some description, and can >output a PAL/NTSC signal so I can use a TV to present full colour graphical >data. Does not need to be HCS12 or even motorola. I basically want to gather >data down a serial communications connection and display graphs on a TV >screen. > >Can anyone point me in the direction of where I might find out how to do >this. I have never done this before. Ideally I would like a solution where I >can just output what I want to a display memory, and the rest of the hard >work is done in converting this bitmap image to a video signal. I believe TI >have chipsets for this, but all I can see seems to work with MPEG based >digital bit streams and convert them to analogue video signal. I am more >after something analogous to a video card on a PC with a video memory. I am >pretty good with the S12 and micros in general, but just have very limitted >knowledge of analogue video signals. > >If anyone can point me in the direction of a email list or application not >or something that can help me, that would be appreciated. > >Cheers, > >Adrian >Yahoo! Groups Links Nigel W. Johnson MCSE, Mem.IEEE VE3ID / G4AJQ Web site: http://nigel.homelinux.net If you want me to have it ready yesterday, you'd better come back the day before and ask me. |
Have a look at the new TI MCU Center on EmbeddedRelated.com!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: OT- Producing a video signal - Adrian Vos - Oct 27 20:03:00 2004
|
Thanks Robert, Nigel, Your advice is valuable, but I have probably hampered it by not giving enough information. The application is for a product I want to develop to allow parameter data to be displayed from our current range of products (which includes S12 based products) on a LCD panel that are now cheaply available for fitment in cars. These displays usually accept a composite PAL or NTSC signal (Does not need to be modulated). The idea is that I would supply a box that has a serial connection that would communicate with our existing products to get data parameters, and it could then display rolling graphs of this data, or represent the data as a guage or bar graph or something on the LCD display. Sooooo..... I need to design a product that can be manufactured in medium quantity, so would prefer to design it from ground up rather than use a 3rd party designed PCB. I want to utilise the best possible quality I can get from a modern display. I know that PAL is 576i, and NTSC is 480i, so realistically, I would be happy to achieve a horizontal resolution of half that since it is interlaced, and may not look good if I try to use the full resolution, although this would depend alot on the display and how it deinterlaces since an LCD display probably displays progressively. In terms of colours... I would be happy with 8bit colour for what I am doing, but if it is not much extra work to stretch it to 16 or 24 bit colour to allow photos quality display of images that I may store in the product, I would prefer that. Target cost.... well as cheap as possible. I would prefer to make the cost higher to reduce the development time....as I said ideally I would utilise some product that allows me to use my knowledge that I have already have to write to a video memory, and then someone has already done the hard stuff in converting this to a PAL or NTSC signal. I would certainly consider producing a digital bit stream and use a MPEG video encoder chip if this is a fairly easy way to go. At the moment I do not have the skills in these bitstreams, but I believe this would be easier than learning the analogue electronics of producing the video signal directly. With the amount of digital cameras and other producs that can be connected to your home TV to display data/images, I would have assumed that there would be some off the shelf solutions to my problem, but maybe not. Also, I have used FPGAs for simple stuff, but would not claim to be an expert. Anyway, I hope that some clarification of what I am trying to do may make it easier to suggest a direction. Thanks for the advice, Adrian ----- Original Message ----- From: "Robert Rolf" <> To: <> Sent: Wednesday, October 27, 2004 5:49 PM Subject: Re: [68HC12] OT- Producing a video signal > > Adrian Vos wrote: > > > Hi All, > > > > Sorry for the off topic post, but I am just after some direction. > > > > I want to make a box that has a processor of some description, and can > > output a PAL/NTSC signal so I can use a TV to present full colour graphical > > data. Does not need to be HCS12 or even motorola. I basically want to gather > > data down a serial communications connection and display graphs on a TV > > screen. > > What resolution? What color depth? How many off? At what target cost? > There are many turn key solutions depending on your answers to the > above questions. > > The brute force way is the ancient MC6845 CRT controller (as used on > old CGA/VGA/EGA cards and some dual port RAM (or appropriately > multiplexed) into some shift registers and encoder. > > Do you have FPGA skills? You can do all the timing with > the FPGA and some external RAM for the refresh buffer. > > You might also want to look at hacking up an old ISA video > card. The MC6845 they used is well documented and easy to > program. You just need to hang a MC1377 ? RGB to NTSC/PAL > encoder chip on it. > > > Can anyone point me in the direction of where I might find out how to do > > this. I have never done this before. Ideally I would like a solution where I > > can just output what I want to a display memory, and the rest of the hard > > work is done in converting this bitmap image to a video signal. I believe TI > > have chipsets for this, but all I can see seems to work with MPEG based > > digital bit streams and convert them to analogue video signal. I am more > > And this is a problem how? 4:2:2 video is relatively easy to > synthesize to feed the chip. Temic/Phillips have a number of > chips that will take various standard form digital streams an > encode them. They also have some decent app notes on what a > video signal looks like. > > > after something analogous to a video card on a PC with a video memory. I am > > pretty good with the S12 and micros in general, but just have very limitted > > knowledge of analogue video signals. > There are a couple of very old books that will get you started. > "TV typewriter Cookbook" by Don Lancaster? comes to mind. Circa 1980. > "Computer Video Demystified" by?? circa 1995. > I am sure there are others that are more current. > > > If anyone can point me in the direction of a email list or application not > > or something that can help me, that would be appreciated. > > Without a more complete specification for exactly what kind of > video you need to produce (resolution and color depth), it's > hard to point you at a optimum solution. > > Many of today's PC video cards can produce NTSC/PAL output, > but they are a PITA to program from scratch, assuming that you > can get the needed register specifications. > > I hope you realize that you cannot get much more than 320 color > pixels across an NTSC screen because of the color encoding > process. The red channel is band limited to about 1.5MHz, and > the blue to 0.8 for NTSC. Fine line graphics look horrid in anything > but black and white. I'd have to look up PAL specs. > > Before you invest too much time in this, try drawing the graphs > you hope to produce, at the resolution you want, > by using a PC video card with TV video out. Take a good look > at the output under the conditions you expect to use it. > E.G. with the monitor and shielding, etc. it will have. > Only THEN will you know if this is the solution you want to > pursue. I would suggest using RGB to an RGB monitor rather than > encoded video. > > Hope this helps. > > Robert > > Yahoo! Groups Links |
|
|
LaunchPad Kit for MSP430 Value Line: Complete open source tool for harnessing 16-bit performance and ultra-low power. Click for Details
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: OT- Producing a video signal - Darren - Oct 27 21:55:00 2004
|
Hi Adrian, I do most of this in a product I designed, I'm using an FPGA to produce RGB in either NTSC or PAL timing and then a AD724 to generate the composite video signal, I also lock it, to the incoming video to overlay my image on the incoming video, this adds a lot of stuff to do that. Easier if you don't need to do that, you maybe able to use a 27Mhz clock as your reference and generate the NTSC and PAL timings from that. This was design was done quite a few years back I would use a ADV7175(6)A now and then drive the encoder with digital data direct. On top of that you may need some external video memory, unless you generate the objects on the fly in the FPGA, which is what I do in my product. Darren Moore > -----Original Message----- > From: Adrian Vos [mailto:] > Thanks Robert, Nigel, > > Your advice is valuable, but I have probably hampered it by not giving > enough information. > > The application is for a product I want to develop to allow > parameter data > to be displayed from our current range of products (which > includes S12 based > products) on a LCD panel that are now cheaply available for > fitment in cars. > These displays usually accept a composite PAL or NTSC signal > (Does not need > to be modulated). The idea is that I would supply a box that > has a serial > connection that would communicate with our existing products > to get data > parameters, and it could then display rolling graphs of this data, or > represent the data as a guage or bar graph or something on > the LCD display. > Sooooo..... I need to design a product that can be > manufactured in medium > quantity, so would prefer to design it from ground up rather > than use a 3rd > party designed PCB. I want to utilise the best possible > quality I can get > from a modern display. I know that PAL is 576i, and NTSC is 480i, so > realistically, I would be happy to achieve a horizontal > resolution of half > that since it is interlaced, and may not look good if I try > to use the full > resolution, although this would depend alot on the display and how it > deinterlaces since an LCD display probably displays > progressively. In terms > of colours... I would be happy with 8bit colour for what I am > doing, but if > it is not much extra work to stretch it to 16 or 24 bit > colour to allow > photos quality display of images that I may store in the > product, I would > prefer that. Target cost.... well as cheap as possible. I > would prefer to > make the cost higher to reduce the development time....as I > said ideally I > would utilise some product that allows me to use my knowledge > that I have > already have to write to a video memory, and then someone has > already done > the hard stuff in converting this to a PAL or NTSC signal. > > I would certainly consider producing a digital bit stream and > use a MPEG > video encoder chip if this is a fairly easy way to go. At the > moment I do > not have the skills in these bitstreams, but I believe this > would be easier > than learning the analogue electronics of producing the video signal > directly. > > With the amount of digital cameras and other producs that can > be connected > to your home TV to display data/images, I would have assumed > that there > would be some off the shelf solutions to my problem, but maybe not. > > Also, I have used FPGAs for simple stuff, but would not claim to be an > expert. > > Anyway, I hope that some clarification of what I am trying to > do may make it > easier to suggest a direction. > > Thanks for the advice, > > Adrian |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: OT- Producing a video signal - Adrian Vos - Oct 28 1:33:00 2004
|
Thanks for the info!! I have spent most of the day searching the net for info on the 4:2:2 format, and how to generate this from a raw video memory, but although there are many links of products that comply to this standard, and I cannot find any information on what the data looks like and how I might go about generating it. I would appreciate any help in this area. I don;t mind buying a book or standard, but do not know where to find it. Thanks again for all the info Cheers, Adrian ----- Original Message ----- From: "Darren" <> To: <> Sent: Thursday, October 28, 2004 12:55 PM Subject: RE: [68HC12] OT- Producing a video signal > > > Hi Adrian, > > I do most of this in a product I designed, I'm > using an FPGA to produce RGB in either NTSC or PAL > timing and then a AD724 to generate the composite > video signal, I also lock it, to the incoming > video to overlay my image on the incoming video, > this adds a lot of stuff to do that. Easier if you > don't need to do that, you maybe able to use a > 27Mhz clock as your reference and generate the > NTSC and PAL timings from that. > > This was design was done quite a few years back > I would use a ADV7175(6)A now and then drive the > encoder with digital data direct. > > On top of that you may need some external video > memory, unless you generate the objects on the > fly in the FPGA, which is what I do in my product. > > Darren Moore > > -----Original Message----- > > From: Adrian Vos [mailto:] > > > > > > Thanks Robert, Nigel, > > > > Your advice is valuable, but I have probably hampered it by not giving > > enough information. > > > > The application is for a product I want to develop to allow > > parameter data > > to be displayed from our current range of products (which > > includes S12 based > > products) on a LCD panel that are now cheaply available for > > fitment in cars. > > These displays usually accept a composite PAL or NTSC signal > > (Does not need > > to be modulated). The idea is that I would supply a box that > > has a serial > > connection that would communicate with our existing products > > to get data > > parameters, and it could then display rolling graphs of this data, or > > represent the data as a guage or bar graph or something on > > the LCD display. > > Sooooo..... I need to design a product that can be > > manufactured in medium > > quantity, so would prefer to design it from ground up rather > > than use a 3rd > > party designed PCB. I want to utilise the best possible > > quality I can get > > from a modern display. I know that PAL is 576i, and NTSC is 480i, so > > realistically, I would be happy to achieve a horizontal > > resolution of half > > that since it is interlaced, and may not look good if I try > > to use the full > > resolution, although this would depend alot on the display and how it > > deinterlaces since an LCD display probably displays > > progressively. In terms > > of colours... I would be happy with 8bit colour for what I am > > doing, but if > > it is not much extra work to stretch it to 16 or 24 bit > > colour to allow > > photos quality display of images that I may store in the > > product, I would > > prefer that. Target cost.... well as cheap as possible. I > > would prefer to > > make the cost higher to reduce the development time....as I > > said ideally I > > would utilise some product that allows me to use my knowledge > > that I have > > already have to write to a video memory, and then someone has > > already done > > the hard stuff in converting this to a PAL or NTSC signal. > > > > I would certainly consider producing a digital bit stream and > > use a MPEG > > video encoder chip if this is a fairly easy way to go. At the > > moment I do > > not have the skills in these bitstreams, but I believe this > > would be easier > > than learning the analogue electronics of producing the video signal > > directly. > > > > With the amount of digital cameras and other producs that can > > be connected > > to your home TV to display data/images, I would have assumed > > that there > > would be some off the shelf solutions to my problem, but maybe not. > > > > Also, I have used FPGAs for simple stuff, but would not claim to be an > > expert. > > > > Anyway, I hope that some clarification of what I am trying to > > do may make it > > easier to suggest a direction. > > > > Thanks for the advice, > > > > Adrian > > Yahoo! Groups Links |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: OT- Producing a video signal - Darren - Oct 28 1:45:00 2004
|
Adrian, I have "Video Demystified" by Keith Jack, if I remember it was quite good. Has a chapter on 4:2:2, sounds like it would fill in lots of gaps for you. Darren > -----Original Message----- > From: Adrian Vos [mailto:] > Thanks for the info!! > > I have spent most of the day searching the net for info on > the 4:2:2 format, > and how to generate this from a raw video memory, but > although there are > many links of products that comply to this standard, and I > cannot find any > information on what the data looks like and how I might go > about generating > it. I would appreciate any help in this area. I don;t mind > buying a book or > standard, but do not know where to find it. > > Thanks again for all the info > > Cheers, > > Adrian |
LaunchPad Kit for MSP430 Value Line: Complete open source tool for harnessing 16-bit performance and ultra-low power. Click for Details
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: OT- Producing a video signal III - Robert Rolf - Oct 28 2:01:00 2004
|
http://www.videotek.com/app40.htm and other pages on the site seems to have a fair bit of info on digital video streams and encoding/decoding. 4:2:2 may be a bit of overkill for your application since it's meant to digitize full color video at professional quality levels. You can probably 'fake it' by replicating pixels from your refresh buffer. e.g. 1 pixel from your frame buffer is sent 4 times. The app notes for the encoder chips (TI/Phillips/ AD) have good technical details on what they require for data format and timing. See this decoder for an idea of what video timing looks like for all formats. http://focus.ti.com/docs/prod/folders/print/tvp5146.html And check to see if the LCD panel you're thinking of using doesn't have an 'RGB' version, since the panel ultimately has to decode the video to that format, it will probably be cheaper without the decoder electronics. You may also be able to directly access the LCD frame buffer with a manufacturer variant that gives you access. It seems silly to encode your digital data into a degraded composite format which the LCD panel then has to work hard decode cleanly. In other words, if you want good resolution, drive the panel directly in RGB at whatever refresh rate it intrinsically wants. And the common QVGA LCD panels take RGB at VGA rates. Robert Adrian Vos wrote: > Thanks for the info!! > > I have spent most of the day searching the net for info on the 4:2:2 format, > and how to generate this from a raw video memory, but although there are > many links of products that comply to this standard, and I cannot find any > information on what the data looks like and how I might go about generating > it. I would appreciate any help in this area. I don;t mind buying a book or > standard, but do not know where to find it. > > Thanks again for all the info > > Cheers, > > Adrian > > ----- Original Message ----- > From: "Darren" <> > To: <> > Sent: Thursday, October 28, 2004 12:55 PM > Subject: RE: [68HC12] OT- Producing a video signal > >> >>Hi Adrian, >> >>I do most of this in a product I designed, I'm >>using an FPGA to produce RGB in either NTSC or PAL >>timing and then a AD724 to generate the composite >>video signal, I also lock it, to the incoming >>video to overlay my image on the incoming video, >>this adds a lot of stuff to do that. Easier if you >>don't need to do that, you maybe able to use a >>27Mhz clock as your reference and generate the >>NTSC and PAL timings from that. >> >>This was design was done quite a few years back >>I would use a ADV7175(6)A now and then drive the >>encoder with digital data direct. >> >>On top of that you may need some external video >>memory, unless you generate the objects on the >>fly in the FPGA, which is what I do in my product. >> >>Darren Moore >> >> >> >>>-----Original Message----- >>>From: Adrian Vos [mailto:] >>> >>> >>>Thanks Robert, Nigel, >>> >>>Your advice is valuable, but I have probably hampered it by not giving >>>enough information. >>> >>>The application is for a product I want to develop to allow >>>parameter data >>>to be displayed from our current range of products (which >>>includes S12 based >>>products) on a LCD panel that are now cheaply available for >>>fitment in cars. >>>These displays usually accept a composite PAL or NTSC signal >>>(Does not need >>>to be modulated). The idea is that I would supply a box that >>>has a serial >>>connection that would communicate with our existing products >>>to get data >>>parameters, and it could then display rolling graphs of this data, or >>>represent the data as a guage or bar graph or something on >>>the LCD display. >>>Sooooo..... I need to design a product that can be >>>manufactured in medium >>>quantity, so would prefer to design it from ground up rather >>>than use a 3rd >>>party designed PCB. I want to utilise the best possible >>>quality I can get >>>from a modern display. I know that PAL is 576i, and NTSC is 480i, so >>>realistically, I would be happy to achieve a horizontal >>>resolution of half >>>that since it is interlaced, and may not look good if I try >>>to use the full >>>resolution, although this would depend alot on the display and how it >>>deinterlaces since an LCD display probably displays >>>progressively. In terms >>>of colours... I would be happy with 8bit colour for what I am >>>doing, but if >>>it is not much extra work to stretch it to 16 or 24 bit >>>colour to allow >>>photos quality display of images that I may store in the >>>product, I would >>>prefer that. Target cost.... well as cheap as possible. I >>>would prefer to >>>make the cost higher to reduce the development time....as I >>>said ideally I >>>would utilise some product that allows me to use my knowledge >>>that I have >>>already have to write to a video memory, and then someone has >>>already done >>>the hard stuff in converting this to a PAL or NTSC signal. >>> >>>I would certainly consider producing a digital bit stream and >>>use a MPEG >>>video encoder chip if this is a fairly easy way to go. At the >>>moment I do >>>not have the skills in these bitstreams, but I believe this >>>would be easier >>>than learning the analogue electronics of producing the video signal >>>directly. >>> >>>With the amount of digital cameras and other producs that can >>>be connected >>>to your home TV to display data/images, I would have assumed >>>that there >>>would be some off the shelf solutions to my problem, but maybe not. >>> >>>Also, I have used FPGAs for simple stuff, but would not claim to be an >>>expert. >>> >>>Anyway, I hope that some clarification of what I am trying to >>>do may make it >>>easier to suggest a direction. >>> >>>Thanks for the advice, >>> >>>Adrian >>> >> >> >> >> >> >>Yahoo! Groups Links >> >> >> >> >> >> > > > Yahoo! Groups Links |
|
|
Have a look at the new TI MCU Center on EmbeddedRelated.com!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: OT- Producing a video signal III - Adrian Vos - Oct 28 2:44:00 2004
|
Thanks Robert, I will go through this info. In regards to my application. I agree with your analysis, but we do not have any particular LCD in mind. The commercial requirement for this product is to be able to display data on a wide range of displays, and for this the most commonly accepted video input type is composite. If we find the right hardware solution, we will endeaveour to provide the component output option also for increased resolution. Cheers, Adrian ----- Original Message ----- From: "Robert Rolf" <> To: <> Sent: Thursday, October 28, 2004 5:01 PM Subject: Re: [68HC12] OT- Producing a video signal III > > http://www.videotek.com/app40.htm and other pages on the site > seems to have a fair bit of info on digital video streams > and encoding/decoding. > > 4:2:2 may be a bit of overkill for your application > since it's meant to digitize full color video at professional > quality levels. You can probably 'fake it' by replicating > pixels from your refresh buffer. e.g. 1 pixel from your > frame buffer is sent 4 times. > > The app notes for the encoder chips (TI/Phillips/ AD) > have good technical details on what they require for > data format and timing. > See this decoder for an idea of what video timing > looks like for all formats. > http://focus.ti.com/docs/prod/folders/print/tvp5146.html > > And check to see if the LCD panel you're thinking of using > doesn't have an 'RGB' version, since the panel ultimately > has to decode the video to that format, it will probably > be cheaper without the decoder electronics. > You may also be able to directly access the LCD frame > buffer with a manufacturer variant that gives you access. > > It seems silly to encode your digital data into a > degraded composite format which the LCD panel then has to > work hard decode cleanly. > > In other words, if you want good resolution, drive the > panel directly in RGB at whatever refresh rate it intrinsically > wants. And the common QVGA LCD panels take RGB at VGA rates. > > Robert > Adrian Vos wrote: > > > Thanks for the info!! > > > > I have spent most of the day searching the net for info on the 4:2:2 format, > > and how to generate this from a raw video memory, but although there are > > many links of products that comply to this standard, and I cannot find any > > information on what the data looks like and how I might go about generating > > it. I would appreciate any help in this area. I don;t mind buying a book or > > standard, but do not know where to find it. > > > > Thanks again for all the info > > > > Cheers, > > > > Adrian > > > > ----- Original Message ----- > > From: "Darren" <> > > To: <> > > Sent: Thursday, October 28, 2004 12:55 PM > > Subject: RE: [68HC12] OT- Producing a video signal > > > > > > > >> > >>Hi Adrian, > >> > >>I do most of this in a product I designed, I'm > >>using an FPGA to produce RGB in either NTSC or PAL > >>timing and then a AD724 to generate the composite > >>video signal, I also lock it, to the incoming > >>video to overlay my image on the incoming video, > >>this adds a lot of stuff to do that. Easier if you > >>don't need to do that, you maybe able to use a > >>27Mhz clock as your reference and generate the > >>NTSC and PAL timings from that. > >> > >>This was design was done quite a few years back > >>I would use a ADV7175(6)A now and then drive the > >>encoder with digital data direct. > >> > >>On top of that you may need some external video > >>memory, unless you generate the objects on the > >>fly in the FPGA, which is what I do in my product. > >> > >>Darren Moore > >> > >> > >> > >>>-----Original Message----- > >>>From: Adrian Vos [mailto:] > >>> > >>> > >>>Thanks Robert, Nigel, > >>> > >>>Your advice is valuable, but I have probably hampered it by not giving > >>>enough information. > >>> > >>>The application is for a product I want to develop to allow > >>>parameter data > >>>to be displayed from our current range of products (which > >>>includes S12 based > >>>products) on a LCD panel that are now cheaply available for > >>>fitment in cars. > >>>These displays usually accept a composite PAL or NTSC signal > >>>(Does not need > >>>to be modulated). The idea is that I would supply a box that > >>>has a serial > >>>connection that would communicate with our existing products > >>>to get data > >>>parameters, and it could then display rolling graphs of this data, or > >>>represent the data as a guage or bar graph or something on > >>>the LCD display. > >>>Sooooo..... I need to design a product that can be > >>>manufactured in medium > >>>quantity, so would prefer to design it from ground up rather > >>>than use a 3rd > >>>party designed PCB. I want to utilise the best possible > >>>quality I can get > >>>from a modern display. I know that PAL is 576i, and NTSC is 480i, so > >>>realistically, I would be happy to achieve a horizontal > >>>resolution of half > >>>that since it is interlaced, and may not look good if I try > >>>to use the full > >>>resolution, although this would depend alot on the display and how it > >>>deinterlaces since an LCD display probably displays > >>>progressively. In terms > >>>of colours... I would be happy with 8bit colour for what I am > >>>doing, but if > >>>it is not much extra work to stretch it to 16 or 24 bit > >>>colour to allow > >>>photos quality display of images that I may store in the > >>>product, I would > >>>prefer that. Target cost.... well as cheap as possible. I > >>>would prefer to > >>>make the cost higher to reduce the development time....as I > >>>said ideally I > >>>would utilise some product that allows me to use my knowledge > >>>that I have > >>>already have to write to a video memory, and then someone has > >>>already done > >>>the hard stuff in converting this to a PAL or NTSC signal. > >>> > >>>I would certainly consider producing a digital bit stream and > >>>use a MPEG > >>>video encoder chip if this is a fairly easy way to go. At the > >>>moment I do > >>>not have the skills in these bitstreams, but I believe this > >>>would be easier > >>>than learning the analogue electronics of producing the video signal > >>>directly. > >>> > >>>With the amount of digital cameras and other producs that can > >>>be connected > >>>to your home TV to display data/images, I would have assumed > >>>that there > >>>would be some off the shelf solutions to my problem, but maybe not. > >>> > >>>Also, I have used FPGAs for simple stuff, but would not claim to be an > >>>expert. > >>> > >>>Anyway, I hope that some clarification of what I am trying to > >>>do may make it > >>>easier to suggest a direction. > >>> > >>>Thanks for the advice, > >>> > >>>Adrian > >>> > >> > >> > >> > >> > >> > >>Yahoo! Groups Links > >> > >> > >> > >> > >> > >> > >> > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > Yahoo! Groups Links |
Have a look at the new TI MCU Center on EmbeddedRelated.com!
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )