Yahoo Groups archive
Thread
2005-10-28 by radim100
Hi , I was just wondering did anybody used any of LPC21XX chips to generate OSD ( On Screen Display) video overlay. I mean without external video OSD chip ( like STV5730 ) , directly from LPC21XX. And if yes could you share experience or some docs. Thanks Radim. http://www.micronix.ca
2005-10-28 by Leon Heller
----- Original Message -----
From: "radim100" <radim100@...> To: <lpc2000@yahoogroups.com> Sent: Friday, October 28, 2005 7:48 PM Subject: [lpc2000] LPC21XX as OSD Generator > Hi , > I was just wondering did anybody used any of LPC21XX chips to generate > OSD ( On Screen Display) video overlay. I mean without external > video OSD chip ( like STV5730 ) , directly from LPC21XX. > And if yes could you share experience or some docs. I think it might be difficult, given the I/O speed limitation. Leon -- Leon Heller, G1HSM leon.heller@... http://www.geocities.com/leon_heller --- [This E-mail has been scanned for viruses but it is your responsibility to maintain up to date anti virus software on the device that you are currently using to read this email. ]
2005-10-28 by Onestone
There used to be a very old Microchip app note that showed it being done with one of the very old PIC16c5x parts, so, even though slow, if a PIC can do it I'm pretty certain the LPC2 could. I don't know if it is still around, it was possibly one of their old competition winners. It was published in the enormous applications handbook of a few years ago. Cheers Al Leon Heller wrote:
>----- Original Message ----- >From: "radim100" <radim100@...> >To: <lpc2000@yahoogroups.com> >Sent: Friday, October 28, 2005 7:48 PM >Subject: [lpc2000] LPC21XX as OSD Generator > > > > >>Hi , >>I was just wondering did anybody used any of LPC21XX chips to generate >>OSD ( On Screen Display) video overlay. I mean without external >>video OSD chip ( like STV5730 ) , directly from LPC21XX. >>And if yes could you share experience or some docs. >> >> > > I think it might be difficult, given the I/O speed limitation. > >Leon >-- >Leon Heller, G1HSM >leon.heller@... >http://www.geocities.com/leon_heller >--- >[This E-mail has been scanned for viruses but it is your responsibility >to maintain up to date anti virus software on the device that you are >currently using to read this email. ] > > > > > >Yahoo! Groups Links > > > > > > > > > >
2005-10-28 by Leon Heller
----- Original Message -----
From: "Onestone" <onestone@...> To: <lpc2000@yahoogroups.com> Sent: Friday, October 28, 2005 8:21 PM Subject: Re: [lpc2000] LPC21XX as OSD Generator > There used to be a very old Microchip app note that showed it being done > with one of the very old PIC16c5x parts, so, even though slow, if a PIC > can do it I'm pretty certain the LPC2 could. I don't know if it is still > around, it was possibly one of their old competition winners. It was > published in the enormous applications handbook of a few years ago. I tried it several years ago. It was very crude - large time display and it couldn't do anything else. The LPC could manage something like that, but it probably isn't much use. Leon --- [This E-mail has been scanned for viruses but it is your responsibility to maintain up to date anti virus software on the device that you are currently using to read this email. ]
2005-10-28 by Onestone
I don't remember the details, but I have seen several reasonable (25-40 character/line) OSD displays as magazine projects over the years. IIRC even BYTE did one in its heyday, and I'd bet that Circuit Cellar probbaly has one. Yep here's one of the few that turned up on byte:- http://www.circuitcellar.com/library/print/1199/Baptiste112/2.htm Not too bad resolution wise, and it uses a PIC Cheers Al Leon Heller wrote:
>----- Original Message ----- >From: "Onestone" <onestone@...> >To: <lpc2000@yahoogroups.com> >Sent: Friday, October 28, 2005 8:21 PM >Subject: Re: [lpc2000] LPC21XX as OSD Generator > > > > >>There used to be a very old Microchip app note that showed it being done >>with one of the very old PIC16c5x parts, so, even though slow, if a PIC >>can do it I'm pretty certain the LPC2 could. I don't know if it is still >>around, it was possibly one of their old competition winners. It was >>published in the enormous applications handbook of a few years ago. >> >> > >I tried it several years ago. It was very crude - large time display and it >couldn't do anything else. The LPC could manage something like that, but it >probably isn't much use. > >Leon > >--- >[This E-mail has been scanned for viruses but it is your responsibility >to maintain up to date anti virus software on the device that you are >currently using to read this email. ] > > > > > >Yahoo! Groups Links > > > > > > > > > >
2005-10-28 by Doug Sutherland
This is using the STV5730A video overlay chip, the micro is not doing any video at all. The question was how can this be done on the micro without STV5730A or equivalent. -- Doug Onestone wrote:
> I don't remember the details, but I have seen several reasonable (25-40 > character/line) OSD displays as magazine projects over the years. IIRC > even BYTE did one in its heyday, and I'd bet that Circuit Cellar > probbaly has one. > > Yep here's one of the few that turned up on byte:- > > http://www.circuitcellar.com/library/print/1199/Baptiste112/2.htm > > Not too bad resolution wise, and it uses a PIC > > Cheers > > Al > > Leon Heller wrote: > > >>----- Original Message ----- >>From: "Onestone" <onestone@...> >>To: <lpc2000@yahoogroups.com> >>Sent: Friday, October 28, 2005 8:21 PM >>Subject: Re: [lpc2000] LPC21XX as OSD Generator >> >> >> >> >> >>>There used to be a very old Microchip app note that showed it being done >>>with one of the very old PIC16c5x parts, so, even though slow, if a PIC >>>can do it I'm pretty certain the LPC2 could. I don't know if it is still >>>around, it was possibly one of their old competition winners. It was >>>published in the enormous applications handbook of a few years ago. >>> >>> >> >>I tried it several years ago. It was very crude - large time display and it >>couldn't do anything else. The LPC could manage something like that, but it >>probably isn't much use. >> >>Leon >> >>--- >>[This E-mail has been scanned for viruses but it is your responsibility >>to maintain up to date anti virus software on the device that you are >>currently using to read this email. ] >> >> >> >> >> >>Yahoo! Groups Links >> >> >> >> >> >> >> >> >> >> > > > > > > > Yahoo! Groups Links > > > > > > > > >
2005-10-28 by Eric Rullens
> I don't remember the details, but I have seen several > reasonable (25-40 > character/line) OSD displays as magazine projects over the > years. IIRC > even BYTE did one in its heyday, and I'd bet that Circuit Cellar > probbaly has one. > > Yep here's one of the few that turned up on byte:- > > http://www.circuitcellar.com/library/print/1199/Baptiste112/2.htm > > Not too bad resolution wise, and it uses a PIC You may want to read that again... "Using an off-the-shelf OSD module saved me development time and aggravation, and enabled me to concentrate on features instead of core operations of the character display." I think you can forget about bit-banging anything above low (/medium with the improved chips) resolution with a LPC. Eric
> Leon Heller wrote: > > >----- Original Message ----- > >From: "Onestone" <onestone@...> > >To: <lpc2000@yahoogroups.com> > >Sent: Friday, October 28, 2005 8:21 PM > >Subject: Re: [lpc2000] LPC21XX as OSD Generator > > > > > > > > > >>There used to be a very old Microchip app note that showed > it being done > >>with one of the very old PIC16c5x parts, so, even though > slow, if a PIC > >>can do it I'm pretty certain the LPC2 could. I don't know > if it is still > >>around, it was possibly one of their old competition winners. It was > >>published in the enormous applications handbook of a few years ago. > >> > >> > > > >I tried it several years ago. It was very crude - large time > display and it > >couldn't do anything else. The LPC could manage something > like that, but it > >probably isn't much use. > > > >Leon > > > >--- > >[This E-mail has been scanned for viruses but it is your > responsibility > >to maintain up to date anti virus software on the device that you are > >currently using to read this email. ] > > > > > > > > > > > >Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > ------------------------ Yahoo! Groups Sponsor > --------------------~--> > Fair play? Video games influencing politics. Click and talk back! > http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/dN_tlB/TM > -------------------------------------------------------------- > ------~-> > > > Yahoo! Groups Links > > >
2005-10-28 by Onestone
I must admit I didn't see that, it's 06:10 here and my eyes are going fuzzy. Al Doug Sutherland wrote:
>This is using the STV5730A video overlay chip, the micro is not doing >any video at all. The question was how can this be done on the micro >without STV5730A or equivalent. > > -- Doug > > >Onestone wrote: > > >>I don't remember the details, but I have seen several reasonable (25-40 >>character/line) OSD displays as magazine projects over the years. IIRC >>even BYTE did one in its heyday, and I'd bet that Circuit Cellar >>probbaly has one. >> >>Yep here's one of the few that turned up on byte:- >> >>http://www.circuitcellar.com/library/print/1199/Baptiste112/2.htm >> >>Not too bad resolution wise, and it uses a PIC >> >>Cheers >> >>Al >> >>Leon Heller wrote: >> >> >> >> >>>----- Original Message ----- >>>From: "Onestone" <onestone@...> >>>To: <lpc2000@yahoogroups.com> >>>Sent: Friday, October 28, 2005 8:21 PM >>>Subject: Re: [lpc2000] LPC21XX as OSD Generator >>> >>> >>> >>> >>> >>> >>> >>>>There used to be a very old Microchip app note that showed it being done >>>>with one of the very old PIC16c5x parts, so, even though slow, if a PIC >>>>can do it I'm pretty certain the LPC2 could. I don't know if it is still >>>>around, it was possibly one of their old competition winners. It was >>>>published in the enormous applications handbook of a few years ago. >>>> >>>> >>>> >>>> >>>I tried it several years ago. It was very crude - large time display and it >>>couldn't do anything else. The LPC could manage something like that, but it >>>probably isn't much use. >>> >>>Leon >>> >>>--- >>>[This E-mail has been scanned for viruses but it is your responsibility >>>to maintain up to date anti virus software on the device that you are >>>currently using to read this email. ] >>> >>> >>> >>> >>> >>>Yahoo! Groups Links >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >>Yahoo! Groups Links >> >> >> >> >> >> >> >> >> >> >> > > > > > >Yahoo! Groups Links > > > > > > > > > >
2005-10-28 by radim100
--- In lpc2000@yahoogroups.com, Onestone <onestone@b...> wrote: > > I must admit I didn't see that, it's 06:10 here and my eyes are going > fuzzy. > > Al > > Doug Sutherland wrote: > > >This is using the STV5730A video overlay chip, the micro is not doing > >any video at all. The question was how can this be done on the micro > >without STV5730A or equivalent. > > > > -- Doug > > > > > >Onestone wrote: > > > > > >>I don't remember the details, but I have seen several reasonable (25-40 > >>character/line) OSD displays as magazine projects over the years. IIRC > >>even BYTE did one in its heyday, and I'd bet that Circuit Cellar > >>probbaly has one. > >> > >>Yep here's one of the few that turned up on byte:- > >> > >>http://www.circuitcellar.com/library/print/1199/Baptiste112/2.htm > >> > >>Not too bad resolution wise, and it uses a PIC > >> > >>Cheers > >> > >>Al > >> > >>Leon Heller wrote: > >> > >> > >> > >> > >>>----- Original Message ----- > >>>From: "Onestone" <onestone@b...> > >>>To: <lpc2000@yahoogroups.com> > >>>Sent: Friday, October 28, 2005 8:21 PM > >>>Subject: Re: [lpc2000] LPC21XX as OSD Generator > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>There used to be a very old Microchip app note that showed it being done > >>>>with one of the very old PIC16c5x parts, so, even though slow, if a PIC > >>>>can do it I'm pretty certain the LPC2 could. I don't know if it is still > >>>>around, it was possibly one of their old competition winners. It was > >>>>published in the enormous applications handbook of a few years ago. > >>>> > >>>> > >>>> > >>>> > >>>I tried it several years ago. It was very crude - large time display and it > >>>couldn't do anything else. The LPC could manage something like that, but it > >>>probably isn't much use. > >>> > >>>Leon > >>> > >>>--- > >>>[This E-mail has been scanned for viruses but it is your responsibility > >>>to maintain up to date anti virus software on the device that you are > >>>currently using to read this email. ] > >>> > >>> > >>> > >>> > >>> > >>>Yahoo! Groups Links > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > >> > >>Yahoo! Groups Links > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > > > > > > > > > >Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > Hi, Yah , there is lots of projects with STV5730 which is probably best solution,but it was discontinued last year. Does anybody knows some good replacement for this chip ? Radim.
2005-10-29 by Eric Engler
> I think it might be difficult, given the I/O speed limitation. > That's true. Prior to the new high speed GPIO, most ARM chips could only toggle at a speed under 4 Mhz. The new 2148 can toggle around 15 Mhz, but it's still going to be a challenge. Might be wise to get one of the PIC-like devices from Ubicom to do this kind of thing. Eric
2005-10-29 by Onestone
The very early PICs mostly ran with a 4MHz clock, 1MHz Internal. if low/medium rs OSD is possible on a PIC16C54 then I'm sure that the 4MHz I/O speed of the LPC could only improve on this. Although it doesn't look like that particular app note is around anymore, unless someone has an old version or the monster applications handbook. Al Eric Engler wrote:
>> I think it might be difficult, given the I/O speed limitation. >> >> >> > >That's true. Prior to the new high speed GPIO, most ARM chips could >only toggle at a speed under 4 Mhz. The new 2148 can toggle around 15 >Mhz, but it's still going to be a challenge. > >Might be wise to get one of the PIC-like devices from Ubicom to do >this kind of thing. > >Eric > > > > > > > >Yahoo! Groups Links > > > > > > > > > >
2005-10-29 by rodboyce70
All, Look it is relativly easy to do the micro must sync up with the horizontal and vertical sync pulses. Then it is a simple matter of timming and interrupting the original video with your own. If you only wnat white text then you only need one output pin. Toggle it high when you want white and low when you want the original video to pass through. I know PAL the best and it has been a long time but I'll try and use the correct numbers. There are 50 frames a second transmitted but each frame is an interlace. So video output is even number scan lines in the frame then odd numbered scan lines. A video scan line is 62.5uS including the sync-pluse. I think that from memory the total sync pulse width in 12.5uS this leave 50uS of screen data. So by dividing this 50uS into as many sections is you like you get a pixel width. There are 625 lines in a frame and I think 100 or so of them are take up with vertial refresh this leaves 525 for display. So a counter that countes these lines will provide you with a pixel height. With all this info a simple B&W OSD should be possible. If you want different collours then you will have to split the video stream into RGB and use three outputs to toggle each of the colours but you still need to do the timing of the video frame. Hope this helps and that my infomation is not too incorrect. The video bandwidth of a composite video stream is either 5.5MHz or 6.5MHz (for pal a least) Toggeleing a pin at 15MHz would be more than fast enough. The rest is timming and I'm guessing that if a PIC @ 12MHz can produce video http://www.web-ee.com/Schematics/PICTetris/PICTetris.htm & http://www.brouhaha.com/~eric/pic/picpong.html then a LPC @ 60MHz should be more than capable of doing the same thing. Hope this helps, Rod --- In lpc2000@yahoogroups.com, Onestone <onestone@b...> wrote: > > The very early PICs mostly ran with a 4MHz clock, 1MHz Internal. if > low/medium rs OSD is possible on a PIC16C54 then I'm sure that the 4MHz > I/O speed of the LPC could only improve on this. Although it doesn't > look like that particular app note is around anymore, unless someone has
> an old version or the monster applications handbook. > > Al > > Eric Engler wrote: > > >> I think it might be difficult, given the I/O speed limitation. > >> > >> > >> > > > >That's true. Prior to the new high speed GPIO, most ARM chips could > >only toggle at a speed under 4 Mhz. The new 2148 can toggle around 15 > >Mhz, but it's still going to be a challenge. > > > >Might be wise to get one of the PIC-like devices from Ubicom to do > >this kind of thing. > > > >Eric > > > > > > > > > > > > > > > >Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > >
2005-10-29 by Michael Rubitschka
I already built an OSD generator based on Ulrich Radigs design. The idea was to display you got email and other pc relevant messages via rf link on a tv.But for the OSD I used an AVR. I think an ARM is overkill for this project. see http://www.ulrichradig.de/ AVR Projekte Videotext Cheers Michael
2005-10-29 by Alex Gibson
>>> > Hi, > Yah , there is lots of projects with STV5730 which is probably best > solution,but it was discontinued last year. Does anybody knows some > good replacement for this chip ? > Radim. Easiest is an fpga. Should be able to do a bit in a larger cpld like a coolrunner2-256. www.xess.com has some nice docs and hdl for fpga Maybe able to find some c code here http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/ http://instruct1.cit.cornell.edu/courses/ee476/ http://instruct1.cit.cornell.edu/courses/ee476/video/index.html These are for avr. Alex
2005-10-29 by donhamilton2002
--- In lpc2000@yahoogroups.com, "rodboyce70" <rodboyce70@y...> wrote: > <snip> > > There are 50 frames a second transmitted but each frame is an > interlace. So video output is even number scan lines in the frame > then odd numbered scan lines. A video scan line is 62.5uS including > the sync-pluse. I think that from memory the total sync pulse width > in 12.5uS this leave 50uS of screen data. So by dividing this 50uS > into as many sections is you like you get a pixel width. There are AFAIR this is correct. Pixel width is the main factor in a project like this. For the sake of argument, lets say the display is 50 pixels across. That means every one uSec a transition may accure. Using an interrupt set to one uSec would make the cpu very busy. No time left to do much of anything. Software loop means nothing else will ever be done. Even at 60 Mhz what would be the overhead ? So unless you want a seperate LPC cpu to control just the video (overkill as stated in another post) just use a seperate controller ( pick your favrite design). This is a great academic question, but has little practical value. donhamilton > 625 lines in a frame and I think 100 or so of them are take up with > vertial refresh this leaves 525 for display. So a counter that PS: Your software can not stop, ever !!
2005-10-29 by bobtransformer
Could you possibly use LPCs PWM for vertical and horizontal sync generation ? bob --- In lpc2000@yahoogroups.com, "donhamilton2002" <hamilton@d...> wrote: > > --- In lpc2000@yahoogroups.com, "rodboyce70" <rodboyce70@y...> wrote: > > <snip> > > > > There are 50 frames a second transmitted but each frame is an > > interlace. So video output is even number scan lines in the frame > > then odd numbered scan lines. A video scan line is 62.5uS including > > the sync-pluse. I think that from memory the total sync pulse width > > in 12.5uS this leave 50uS of screen data. So by dividing this 50uS > > into as many sections is you like you get a pixel width. There are > > AFAIR this is correct. > > Pixel width is the main factor in a project like this. > > For the sake of argument, lets say the display is 50 pixels across. > That means every one uSec a transition may accure. Using an interrupt > set to one uSec would make the cpu very busy. No time left to do much > of anything. Software loop means nothing else will ever be done. Even > at 60 Mhz what would be the overhead ? > > So unless you want a seperate LPC cpu to control just the video > (overkill as stated in another post) just use a seperate controller ( > pick your favrite design). > > This is a great academic question, but has little practical value. > > donhamilton > > > > 625 lines in a frame and I think 100 or so of them are take up with
> > vertial refresh this leaves 525 for display. So a counter that > > PS: Your software can not stop, ever !! >
2005-10-29 by Richard Duits
Maybe you can use a SSP unit to generate a constant bit stream. It takes only 1 write to generate 16 bits, and the FIFO should make it possible to generate a constant bit stream. If you use the PWM to generate the sync signals, you may have some processing power left for a UART or USB routine that can communicate with the user. I never used the SSP, so I'm not completly sure that it is possible. You also need to find a way to synchronize the bit stream of the SSP to the sync signals. Richard. bobtransformer wrote:
> > Could you possibly use LPCs PWM for vertical and horizontal sync > generation ? > > bob > > > --- In lpc2000@yahoogroups.com, "donhamilton2002" <hamilton@d...> > wrote: > > > > --- In lpc2000@yahoogroups.com, "rodboyce70" <rodboyce70@y...> > wrote: > > > <snip> > > > > > > There are 50 frames a second transmitted but each frame is an > > > interlace. So video output is even number scan lines in the frame > > > then odd numbered scan lines. A video scan line is 62.5uS > including > > > the sync-pluse. I think that from memory the total sync pulse > width > > > in 12.5uS this leave 50uS of screen data. So by dividing this > 50uS > > > into as many sections is you like you get a pixel width. There > are > > > > AFAIR this is correct. > > > > Pixel width is the main factor in a project like this. > > > > For the sake of argument, lets say the display is 50 pixels across. > > That means every one uSec a transition may accure. Using an > interrupt > > set to one uSec would make the cpu very busy. No time left to do > much > > of anything. Software loop means nothing else will ever be done. > Even > > at 60 Mhz what would be the overhead ? > > > > So unless you want a seperate LPC cpu to control just the video > > (overkill as stated in another post) just use a seperate controller > ( > > pick your favrite design). > > > > This is a great academic question, but has little practical value. > > > > donhamilton > > > > > > > 625 lines in a frame and I think 100 or so of them are take up > with > > > vertial refresh this leaves 525 for display. So a counter that > > > > PS: Your software can not stop, ever !! > >
2005-10-29 by Eric Engler
--- In lpc2000@yahoogroups.com, "rodboyce70" <rodboyce70@y...> wrote: > Look it is relativly easy to do the micro must sync up with the > horizontal and vertical sync pulses. Then it is a simple matter of > timming and interrupting the original video with your own. If you > only wnat white text then you only need one output pin. Toggle it > high when you want white and low when you want the original video to > pass through. You reminded me of a book that came out in the late 70's by Don Lancaster. It was called "The Cheap Video Cookbook". He used a 1 Mhz 6502 to generate an NTSC video signal. During horizontal retrace the chip would get the text lined up for the next scan line, and he had enough free cycles to do some other work. He took advantage of a brilliant deduction. He wanted to use the address bus to clock out character pixels from an external shift register. This meant that he didn't have to send out pixels individually - he'd only need to send out the address of one complete character each microsecond. He thought of executing a string of NOPs to get the addresses to increment. However, the 6502 could only execute one NOP every 2 clock periods, and this wasn't fast enough. Then a stroke of genious set in: he could give it a series of LDA $xx commands. The 6502 would execute the opcode fetch on one clock, then it would fetch the immediate data from the following memory address with the next clock cycle. This gave him a stream of character adresses at one per microsecond, which was good enough to meet his needs. The hard part is to support colors and to lock it to an external signal and superimpose your characters over the other video signal. This is harder than it sounds. You can easily get ghosting and noise problems due to circuit layout issues. Eric