Hi all.For the past few weeks I have been working on a personal project in my spare time before I start my first day of college.The project is to develop a high resolution graphical on screen display for PAL, NTSC and possibly SECAM video signals. The intended application in my case is to stick a camera, OSD module and video transmitter on my model plane and fly it away, whilst getting readouts of various statistics.It already works. I have a graphical OSD working, with shapes, fills, lines, text and images working. It works better than I expected. :)The current specifications are:- At the core, a Microchip dsPIC33FJ128GP802 processor. This was mainly chosen because it's got the most amount of RAM/FLASH in a DIP package and I can easily get them on my breadboard. Also because I already have a PICkit 2 programmer. This processor runs off the 7.37 MHz fast RC oscillator with PLL to boost it to just about 39.7 MIPS slightly under its rated 40 MIPS.- Dual buffered 256x192 pixel display; pixels are either transparent or white. 12K of video RAM is used. Dual buffering allows a new display to be written to the DRAW buffer and then swap the buffers; this makes the screen change instantly; no flickering is seen.- An LM1881 is used to syncronise to the signal. I would like to eliminate this, however, it makes the initial design easier. It also improves the stability of the OSD; I found using a comparator has the difficulty of determining the vertical blanking period of the signal.- Has a 5x5 font which is hand designed by me (based off the Silkscreen font but fixed to 5x5 whereas Silkscreen has some non-5x5 chars.) This font is quite small on the screen, so I am considering a 8x14 terminal style font. 256 pixels allows about 50 characters horizontally and 38 characters vertically with the 5x5 font.- Powered from +5V (+3.37V supply for dsPIC33F, using an LM317T.)- All code written in assembly language. The first version used C, but that had too many problems, so I decided to rewrite it in assembler, which made it much faster and fixed many bugs.- Accelerated drawing of horizontal and vertical lines of any length. Accelerated drawing of any line in odd quadrants.- All video processing done during the horizontal blanking interval and vertical blanking interval. Only 3 MIPS out of the 39.7 MIPS are available for processing, so the code has to be fast (see above.) Previous C version reached 10 fps doing a full F-22 OSD, target is at least 20 fps for this version and possibly even 30-40 fps (faster than the video signal!)- Doesn't yet support NTSC... however, this is trivial to add, as all it requires is changing the scaling factors for the display and adjusting some timing parameters. No code changes should be necessary, as NTSC and PAL signals are very similar. SECAM support is being considered but I have seen very few SECAM cameras so this is not planned yet.I'm currently away from my project at the moment, so I can't post any pictures, but I'll have some up soon. So please, everyone let me know what you think, and if you want to see this go further. I'm certainly going to be using it myself on my model plane, and I hope other people can benefit from my 2 weeks or so of work on this project.This will be an open source hardware and software design most likely.
You need to be a member of diydrones to add comments!
@Peter: At the moment, no. The dsPIC DSC was only chosen for four main reasons:
1.) I had a PICkit 2 so no need to invest in other programmers and equipment.
2.) The DSC has 16KB of SRAM. I don't know how many other Arduino processors have 16KB. This amount of memory is critical, because two copies of the video buffer must be stored.
3.) The DSC is 16-bit. Atmel do make 32-bit processors, but 16-bit is a good middle ground between full blown processor and tiny microcontroller, I think. Having a 16-bit address word allows for drawing more pixels at a time in optimised routines (for example, drawing a horizontal line, you can write up to 16 pixels at a time.) Also, the dsPIC architecture is very optimised for this kind of thing. For example, to set a pixel on, you can set a pixel on or off with an OR mask in one cycle: W5 = W5 | W2 operations and similar are all supported in single cycles.
5.) Microchip were very kind to send me two free chips because I asked them nicely and told them I was a student (which is correct.) This may well turn out to be my project for college; I'm doing electronics there.
Also, the code has already been written for the dsPIC (in assembly); it could be written for Atmel processors but I'd have to start from scratch and learn another assembly language.
@Torin: The interface can be anything you like; it's an open source project. The dsPICs have support for I2C, so adding a simple byte level command interface is certainly something I will consider.
@Alex: The cost is right I think! In total it's cost me less than £10 (~$15) in parts to build. As it is open source anyone can build their own from my plans (which I'll have up in a few days after the pics and videos.)
Replies
1.) I had a PICkit 2 so no need to invest in other programmers and equipment.
2.) The DSC has 16KB of SRAM. I don't know how many other Arduino processors have 16KB. This amount of memory is critical, because two copies of the video buffer must be stored.
3.) The DSC is 16-bit. Atmel do make 32-bit processors, but 16-bit is a good middle ground between full blown processor and tiny microcontroller, I think. Having a 16-bit address word allows for drawing more pixels at a time in optimised routines (for example, drawing a horizontal line, you can write up to 16 pixels at a time.) Also, the dsPIC architecture is very optimised for this kind of thing. For example, to set a pixel on, you can set a pixel on or off with an OR mask in one cycle: W5 = W5 | W2 operations and similar are all supported in single cycles.
5.) Microchip were very kind to send me two free chips because I asked them nicely and told them I was a student (which is correct.) This may well turn out to be my project for college; I'm doing electronics there.
Also, the code has already been written for the dsPIC (in assembly); it could be written for Atmel processors but I'd have to start from scratch and learn another assembly language.
Peter
@Torin: The interface can be anything you like; it's an open source project. The dsPICs have support for I2C, so adding a simple byte level command interface is certainly something I will consider.
@Alex: The cost is right I think! In total it's cost me less than £10 (~$15) in parts to build. As it is open source anyone can build their own from my plans (which I'll have up in a few days after the pics and videos.)
-
1
-
2
of 2 Next