Printable View
I have seen web sites that provide info on video being generated in realtime by PICs, but the only code they have as an example is in assembly. Honestly, I can't stand looking at assembly. Has anyone tried to generate video with picbasic before? I'm going to try to convert the assembly code to picbasic.
Sorry to say it wont work. Even in assembly with a 40 Mhz PIC it is quite a challenge (although not impossible) to generate decent video resolution. You have to bear in mind that a given horizontal scanline only lasts for about 64 microseconds. On a PIC being clocked at 40 Mhz, even the simplest assembly language instruction (NOP) will take 100 nanoseconds to complete. At first it seems fast, but you need to do more then a NOP instruction to actually display anything of value. When you start looking at shifting out information from memory, and being able to do any of the other housekeeping tasks required, it doesn't take long before you simply run out of time, and your resolution begins to suffer drastically.
Here is a very good website on what is really required:http://www.rickard.gunee.com/project.../pic/howto.php. I would suggest checking it out.
Good luck
Tetris using a PIC16F84 running @ 12MHz:
(NTSC video signal).
http://www.web-ee.com/Schematics/PIC.../PICTetris.htm
http://www.web-ee.com/Schematics/PIC...game_schem.gif
http://www.web-ee.com/Schematics/PICTetris/tetris.jpg
I was afraid that PicBasic would be too high level of a language to work. I guess Ill attempt to learn some assembly. Uhg.
it's not impossible in PICBasic but it will depend of what kind of video signal you want to generate.
Sure the assembly method will provide a better range of possibility if you want a decent/great 'resolution'. Timing issue??? Hard to create Delay? Learn how to use internal Timer or learn or to work with MPLAB stopwatch and assembly loop.
A previous thread => Assembler for dummies => http://www.picbasic.co.uk/forum/show...ssembler+blink
12Mhz, 20Mhz work great for me for OSD... but plain text with plain lines... no 3D and ... of course no colours
The Michael link is a great start point. Maybe you can find out few example on www.epanorama.net
good luck.
Yes I stand corrected (but only slightly :)). You probably can generate video on a PIC and programmed in PicBasic, but I guarantee you it will still be quite a challenge taking this approach. And depending on your needs (which we know very little about), it still might not produce acceptable results. If you are just looking at producing a small number of units with this capability, then I would suggest using something like a BOB3 video board from these guys: http://www.decadenet.com/. Or for something even simpler (and much cheaper) may I suggest the SV1000 chip from: http://www.speechchips.com/shop/item.asp?itemid=7. Of course the BOB3 is much more capable, has 8 color text, hardware scrolling, and video overlay. But it will cost you to get these features.
If you do decide to roll-your-own, I would also suggest doing all the video generation with a separate PIC that communicates with another that runs your main code. This really would be the best approach (and similar to using your PIC with one of the above mentioned products), unless your needs are fairly simple.
Cheers,
I'm not going for somthing with a really high resolution. I was just interested in seeing if I could produce some simple video stuff, possibly even a game or two. I really wanted to use PB instead of ASM. Ill give it a shot in PB and post again when I have some results.
Just a quick question about assember: I'm trying to translate the "white stripe" code from http://www.rickard.gunee.com/project.../pic/howto.php into PicBasic and I came across the ASM statement "DNOP". I know very very little about ASM. What does this do?
DNOP is a macro. (Two NOP instructions).
See instruction NOP.
Luciano
I tried the code that should generate two gray bars on either side of the screen and a white stripe in the middle on a tv and got a nice black picture. According to the info on http://www.rickard.gunee.com/project.../pic/howto.php I need to generate 3 levels between 0v and 1v. I used the setup he had where B0 goes through a 1K resistor and B1 goes through a 470 ohm resistor and I got output voltages of around 2.3 volts. I also think that my code might not be fast enough. I'm using the PAUSEUS command but Im not sure so Im going to hook it up to an oscilloscope tomorow and check it out.
Perfect situation to learn/use MPLAB stop watch. That will teach you, at least, how PAUSEUS is acurate for a specific Xtal. You should have a look to that. Probing with a scope is also an option... for that, i'll prefer MPLAB stopwatch.
Ive been looking around the internet for info on the MPLAB stopwatch and I really have no idea what it is and how to use it. The most helpful thing I found was this code segment (posted by you, mister_e):
' Fine tuned with MPLAB StopWatch to get MainLoop = 1 sec
'
for delay=1 to 307
@ nop
next
Bruce give me a short explanation of it before i wrote those lovely lines ;)
http://www.picbasic.co.uk/forum/show...ruce+stopwatch
There's a few explanation in the MPLAB help-file too.
What is the video standard of your TV-set? (PAL or NTSC)
Nice google
http://www.sparkfun.com/tutorial/ser...al-2-mplab.htm
And of course the MPLAB quick start guide
http://ww1.microchip.com/downloads/e...Doc/51281d.pdf
HTH
EDIT: Oups sorry Luciano :(
Ah Ive almost got it now. I downloaded MPLAB IDE v7.22 and loaded up the .asm file that picbasic pro compiled. I started the stopwatch and ran the program with MPLAB SIM as the tool but it just ends up saying "Time (mSec) 3.276800". How can I use it to measure the time between two points in my program?
My TV is NTSC.
The link below is about PAL and the main power frequency is 50 Hz.
http://www.rickard.gunee.com/project.../pic/howto.php
I based my code on the ASM example given in that link. Since both PAL and NTSC use the same signal structure it should work on my TV. I dont have a vertical synch inserted so it just repeats the same thing (synch, pause, gray, white, gray) over and over again.
I followed the Spark Fun MPLAB Stopwatch tutorial and I understand that now but I can not get it to work with my program. I have started a new project and imported the .asm file created by picbasic pro but when I click build it gives me tons of errors. Shouldnt the .asm file be correct?
You have to download the PBP MPLAB plugin
http://www.microengineeringlabs.com/support/mplab.htm
Then you don't need to use the asm file. Start a new project with the wizard, choose PBP as toolsuite, and set your breakpoint directly in your PBP code lines. That's it :)
I feel like the biggest noob on the face of the earth.
Gold stars for everyone.
EDIT:
ALMOST! Im so close. Only one thing left. When I hit "Build" I get errors that didn't appear in MicroCode Studio. Most of them are like this:
Error[105] C:\PICBASIC PRO\18F252.INC 19 : Cannot open file (Include File "P18F252.INC" not found)
Error[113] C:\PROGRAM FILES\MECANIQUE\MCS\VIDEO\VIDEO_TEST.ASM 86 : Symbol not previously defined (PORTB)
Error[113] C:\PROGRAM FILES\MECANIQUE\MCS\VIDEO\VIDEO_TEST.ASM 88 : Symbol not previously defined (PORTC)
Error[113] C:\PROGRAM FILES\MECANIQUE\MCS\VIDEO\VIDEO_TEST.ASM 90 : Symbol not previously defined (TRISB)
Error[113] C:\PROGRAM FILES\MECANIQUE\MCS\VIDEO\VIDEO_TEST.ASM 92 : Symbol not previously defined (TRISC)
Ok I got it to load P18F252.INC but now the errors all look like this:
Error[152] C:\PROGRAM FILES\MECANIQUE\MCS\VIDEO\VIDEO_TEST.ASM 908 : Executable code and data must be defined in an appropriate section
Error[116] C:\PROGRAM FILES\MECANIQUE\MCS\VIDEO\VIDEO_TEST.ASM 156 : Address label duplicated or different in second pass (Z00011)
Error[152] C:\PROGRAM FILES\MECANIQUE\MCS\VIDEO\VIDEO_TEST.ASM 908 : Executable code and data must be defined in an appropriate section
Error[116] C:\PROGRAM FILES\MECANIQUE\MCS\VIDEO\VIDEO_TEST.ASM 160 : Address label duplicated or different in second pass (Z00012)
Error[116] C:\PROGRAM FILES\MECANIQUE\MCS\VIDEO\VIDEO_TEST.ASM 12 : Address label duplicated or different in second pass (_main)
Error[116] C:\PROGRAM FILES\MECANIQUE\MCS\VIDEO\VIDEO_TEST.ASM 165 : Address label duplicated or different in second pass (Z00013)
Error[152] C:\PROGRAM FILES\MECANIQUE\MCS\VIDEO\VIDEO_TEST.ASM 908 : Executable code and data must be defined in an appropriate section
Error[116] C:\PROGRAM FILES\MECANIQUE\MCS\VIDEO\VIDEO_TEST.ASM 169 : Address label duplicated or different in second pass (Z00014)
I got it to compile in MPLAB!!!
I checked out my program on the oscilloscope and I found that whenever the voltage changed, like from 0v to .33v it jumped for about .1us to 2v. I dont know why but instead of outputting a max of 1v my pic is putting out 2 to 3 volts. I guess I need bigger resistors.
EDIT:
Ive been timing everything down to a science and found this site (http://www.maxim-ic.com/appnotes.cfm/appnote_number/734) which has an excellent timing diagram for NTSC signals and I made my program as close as its going to get (one scanline is supposed to be 63.5us. Mine is 63.4)
Don't worry too much about getting the scanline to be exaxtly to NTSC standards, unless you plan to sync this to another signal and genlock it. heck I used to use an ATARI 8 bit computer back in my younger days and it had a scanline of exactly 64 usec (A nice evenly divided number). It's video worked very well indeed, on any TV you cared to hook it up to.
Thats good. I was afraid that I would have to generate negative voltage because that site says that synch is at negative somthing volts.
in fact that's the way to generate but as i'd experiment in the past, most TV/video/../ will accept 0 volt as sync without too much problem.
Source:
http://www.atmel.com/dyn/resources/P...ga163_3_04.pdf
http://www.kazimages.com/uploads/1919770fb7.jpg
Best regards,
Luciano
When they say SYNC is negative, what is really meant is that it is negative as compared to the black level of the video. So if sync is at 0 volts, you just have to insure that what you want to be black is at about 0.4 volts and what you want to be white is at 1.0 volts. Most all video monitors capacitively couple to the video input, and do some sort of internal clamping to put the black level where they want it to be.
wahoooo!
see the attachment! its a little blury because I had to turn the flash off so the screen wouldnt be all glareish.
I'm not sure where this project will go next, but it will probably be in the form of some portable video game device. I also need to find out why there is a voltage spike whenever the colors change. You can barely see it in the picture but the first pixel of the gray bar is white. Perhaps a capacitor would fix this.
Congratulations :).
Now it'll be interesting to see how far you can go with this PicBasic approach to video.
Congratulations!
Very nice rocking chair! Who is on the couch?
Luciano
RUBiksCUbe,
Before I forget... You should post the code that created that video bar display. Maybe this way you'll get some useful ideas on how to proceed, and/or inspire others in there video related efforts.
Sure the code. BTW noone is on the couch, its just a knitted blanket thats all twisted and some pillows.
I used some really cheap delay methods, like setting the variable i to different things and setting a pin to a value twice to slow the pic down a bit because PAUSEUS actually pauses for about 1.4ish us. Come to think of it, setting a pin twice might create those voltage spikes...
DEFINE OSC 20
'Set them up as outputs
Output PortB.0
Output PortB.1
main:
'Front porch: 1.5us total delay
PortB.1 = 0
PortB.0 = 1
'SIMPLE DELAY
PortB.1 = 0
i = 11
i = i
'Synch: 4.7us total delay time
PortB.1 = 0
PortB.0 = 0
'SIMPLE DELAY
i = 3
i = i + 1
i = i + 1
i = 7
pauseus 3
'NEXT:
'Back Porch: 4.7us total delay time
PortB.1 = 0
PortB.0 = 1
'Simple Delay
PortB.1 = 0
pauseus 4
'SIMPLE DELAY
i = i + 1
'Time to get drawing! 52.6us total time to draw.
'Gray: 4.4us total delay time
PortB.1 = 1
PortB.0 = 0
Pauseus 3
'SIMPLE DELAY
i = i + 1
i = i + 1
i = i + 1
i = i + 1
i = i + 1
i = i + 1
'NEXT:
'Black: 20us total delay time
PortB.1 = 0
PortB.0 = 1
Pauseus 19
'SIMPLE DELAY
i = i + 1
i = i + 1
i = i + 1
'NEXT:
'White: 4us total delay time
PortB.1 = 1
PortB.0 = 1
Pauseus 3
'Black: 20us total delay time
PortB.1 = 0
PortB.0 = 1
Pauseus 19
'SIMPLE DELAY
i = i + 1
i = i + 1
i = i + 1
'NEXT:
'Gray: 4.6us total delay time
PortB.1 = 1
PortB.0 = 0
Pauseus 1
'SIMPLE DELAY
i = i + 1
i = i + 1
i = i + 1
i = i + 1
i = i + 1
i = i + 1
'NEXT:
goto main
And thats the magic. No vertical synch (yet) but it worked on my NTSC TV. Now I just need to fix those stupid i = i + 1 delays and make the video animated.
Ive been trying animated tv signals where the white bar moves back and forth, but it isnt working out. All I see is a white bar in the middle of the screen that gets warped at the top. I guess the vertical synch is important
Yes you will need Vsync, otherwise you'll get that bending affect you are seeing. Also be sure to leave some empty space (0.4 volt black level) of at least 3 scanlines before and after (more is better if it doesn't limit the viewable height of your bars). This is kinda like the front and back porch of the Vsync pulse.
Speaking of which, are your front and back porch adaquate for your Hsync? If you look at the diagram below you will see that you need to maintain at least 1.5 usec of space for the front porch, and about 4.7 usec on the backporch of the Hsync. To be safe, and because most TV's have considerable overscan, I would give it more (figure on only having about 48 usec of viewable active video, the rest just wraps around the CRT).
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=627&stc=1&d=1132554180 ">
For now don't worry about the colorburst, since I presume you are only fooling around with B&W. Also if you didn't already notice, IRE units are the same as volts*100.
When I timed every section of my code in MPLAB I got it as close as the specifications as possible. The front porch was 1.4us and the back porch was 4.6us, which is as close as I could get it without going over. I could try to extend the front porch to 1.6 us and see what happens. I dont think that anything would though.
Thats a good diagram. I wish I had that when I was still coding. Do you have one of those for the vertical synch? I cant find the timing for it anywhere.
RUBiksCUbe:
Here's a link to where I got the Hsync diagram (they also have one for Vsync) http://www.sxlist.com/techref/io/video/ntsc.htmQuote:
Thats a good diagram. I wish I had that when I was still coding. Do you have one of those for the vertical synch? I cant find the timing for it anywhere.
You'll notice if you look at the FLD 4 example, that they show 6 equalizing pulses ocurring before and after the Vsync. Most modern TV's don't need these any more. This was originally used to help the older sets lock in properly, which is also why these sets had horizontal and vertical adjustments, something you also don't see any more. As for the Vsync pulse, instead of it being one long pulse, it is actually made up of both long and short pulses. Essentially it is just hsync turned upside down for 3 scan lines. Therefore the total length of the Vsync pulse is approximately 191 usec, and occurs approximately every 16 msec.
A good way to produce these signals is to use the PIC's internal counters in an interrupt routine. Or if you have an HPWM on board, you can also mimic these sync pulses by properly setting the duty cycle and base frequency (this is easily done via PBP).
Have fun,