2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

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



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

----- Original Message -----
From: "radim100" <radim100@radi...>
To: <lpc2000@lpc2...>
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@leon...
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. ]



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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@radi...>
>To: <lpc2000@lpc2...>
>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@leon...
>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




(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

----- Original Message -----
From: "Onestone" <onestone@ones...>
To: <lpc2000@lpc2...>
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. ]



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> 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@ones...>
> >To: <lpc2000@lpc2...>
> >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 >





(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> 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





(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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




(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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@lpc2..., 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
>



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In lpc2000@lpc2..., "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 !!



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Could you possibly use LPCs PWM for vertical and horizontal sync
generation ?

bob --- In lpc2000@lpc2..., "donhamilton2002" <hamilton@d...>
wrote:
>
> --- In lpc2000@lpc2..., "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 !!




(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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@lpc2..., "donhamilton2002" <hamilton@d...>
> wrote:
> >
> > --- In lpc2000@lpc2..., "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 !!
>




(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

The PutQueue procedure uses a Count Type of Integer.
Arrays that start at 1 are treated differently than arrays that start with 0.
Manual says, "If the queue is full, PutQueue will suspend the task until there is enough room to insert the data."
Keep trying to fix it, and let us know what happens.

Eric
----- Original Message -----
From: wurlitzer28

Subject: [BasicX] BX24 Comm1 should send 3 bytes but only 2 received I have fought this for the last 2 days. This routine looks for a bit
or bits that have changed since the last time the program read a word
from PortA.

[Non-text portions of this message have been removed]



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )