|
||
The resolution of the graphic window, fenced by the blue frame, is 170x170, and each pixel from the video memory is represented by 3x3 pixels on the screen (in 800x600 resolution @ 60 Hz). Here is the sequence which draws one scan line of the graphic portion on the screen:
mov.b WREG,LATD You can see that, in this case, PIC @ 40 MIPS was too fast for video signal generation and it had to be slowed by adding one nop at each pixel of the routine. The low byte of PORTD is used for green signal generation, but there are no active components - there is only the R-2R resistor network on bits 0...4, so the video stage is capable of displaying 25=32 levels of green. Bits 5, 6 and 7 in the video memory are not displayed, as they are used during picture processing and analyzing. But, in some cases, when I wanted to see those bits during program development, I just had to replace nop with swap.b w0 , and those special function bits became visible on the screen. The attached picture demonstrates such case, as the brighter pixels (visible as white at the center of each dice dot) were not captured by the camera, but they represent the calculated coordinates of each dice dot, ready for further processing. The whole video memory takes 170x170=28900 bytes, and the microcontroller dsPIC33FJ256GP710 has 30K of Data RAM, so more than 1K is left for housekeeping. A part of that memory is always displayed in hex code at the right of the screen, which is also very useful during software debugging. Those hex digits are, of course, not a part of video memory, but a contents of regular Data RAM, displayed as memory dump in the similar way (and in the same resolution) as the text-based video. The only difference is that there is no line buffer, as the spacing between hex digits gave enough time to the processor for real time rendering. Character set contains only 16 hex digits (0...F), and the character set for the large characters (orange digits at the top of the screen) contain only six digits, 1...6, and a few special ASCII letters used for error reports, as they have only to display the final result of dice recognition algorithm. SOME MORE POSSIBILITIES There are some applications in which such system enables a good price/performance ratio. For instance, small touch screen systems for light control, burglar alarm systems or some industrial applications. Most of them could be realized by the combination of text and some small graphics areas on the screen, which will not occupy a lot of memory, such as buttons, indicators or icons. Those systems have some advantages compared to PC-based controllers: -
Low failure rate In some applications, there is no need for colour displaying, so the resolution can be increased with the existing amount of Data RAM. So, with the microcontroller which contains 30K of Data RAM, you can get full-screen B&W graphics with 600x400 resolution in 1280x768 mode (with the very small unused border) or 512x384 resolution in 1024x768 mode. There is one more way to get the very simple block-graphics (with 120x75 resolution), with the small modifications in the existing software. You can rearrange 64 characters (e.g. codes 192-256) in the character set as block-graphics characters, with 3x2 pixels each, something like this: Yellow areas represent "ones" in the character set (and those areas will take the foreground colour on the screen), and the blue areas "zeros" (background colour). With those 64-characters and a little mathematics in the drawing subroutine, you can get the very simple full graphics in 120x75 resolution, which can be used in combination with text. The routine must operate in full screen mode (bit FLAG,#0 reset). This is the monochromatic resolution, but the colour resolution is lower, as you can select the foreground and background colour for six blocks at a time. The last idea is for speculation only: this project makes the old computer enthusiast's dream come true - the single-chip computer. Who knows what computers were some 25 years ago, will know what do I mean... but this idea is, of course, obsolete now. But, for some very specific applications, it may still be actual. |
||