Propeller With TV+Graphics... Memory Issue

sobakava

Hi,

I'm relatively new to Parallax Propeller and I'm trying to develop a system using Propeller.

System consists of

P8X32A QFN44 IC + I2C EEPROM,
nRF9E5 433/868MHz RF Transceiver/8051 IC ( I implemented a basic SPI protocol between Parallax and nRF9E5)
TV Output ( 7" color PAL/NTSC TFT screen )
Microchip SPI SRAM + SPI EEPROM ( For future use )


I'm using the TV driver and Graphics driver came with Spin tool and I'm drawing some boxes, lines and print text menu on the screen. I don't use mouse, keyboard or any other driver.


I already completed and tested most of the firmware. But at the end, I faced with a major problem: Memory!

While trying to complete the design I realized I need to save some parameters to EEPROM. I decided to write them into empty space in the I2C boot EEPROM and started to play with I2C drivers from Propeller Object Exchange.

Unfortunately when I try to ad a simple I2C driver, Spin tool can not compile the code anymore because of insufficient memory. Then I tried to ad I2C routines to main code line by line.

First I thought I've a lot of space left for such kind of "simple" and "small" operations because Spin Tool shows 6169Longs are free and this fairly enough to complete my design.

Then I realized this space is already reserved by TV driver using this line:

_stack = ($3000+$3000+100)>>2

I tried to reduce this space to $3000+ $2900 + 100 without getting into details of the TV driver but application started to crash while changing menus etc.


I estimate, I just need 300-400 longs more to complete my design and somehow I need to get more memory.

In the forum I read, some people recommends not to use double buffer mode to save memory. I don't know what does it mean. Is it a solution for me?

Is there a more optimized TV or Graphics driver? I deleted all of the unused graphics routines ( drawing arcs etc ) from graphics driver.

Is it possible to use external SPI RAM for code execution or frame buffer storage? I 'm working with static graphics, there is no animation etc on the screen. So speed is not the most important thing for me.

Regards

Sobak Ava

MagIO2

The graphics driver is using 2 buffers. The first is displayed while the other one is used to draw the next image. This avoids flickering.

_stack = ($3000+$3000+100)>>2 is reserving $3000 bytes for buffer 1, $3000 for buffer 2 plus $100 for all the parameters needed by the graphics driver. >>2 converts the numbers from bytes to long (it's equal to /4 )

So, simply removing some bytes does not help because the graphics driver is still completely using both buffers!


What I foud is:
http://obex.parallax.com/objects/559/
http://forums.parallax.com/showthread.php?130737-How-to-fix-tv-flicker-without-using-double-buffering&highlight=double+buffer
http://forums.parallax.com/entry.php?86-Ripple-Draw

I remember there are more drivers out there which avoid double buffering ... one for example uses XOR operations to draw. So, drawing a line once will really draw it, drawing the same line again will delete it.

What are the lines used for that you draw? Is it only for drawing windows? Then you could also switch to TV_Text and do the boxes with the special characters available in the propeller font.

Tharkun

Hi and welcome to the forum Sobak Ave,

when you only need a few longs more, remove all the functions in graphics.spin that are not nessesary for you program, to do this you could also use Brad's Spin Tool (BST)
which do this automatically.

potatohead

Welcome to the forum!

http://forums.parallax.com/entry.php?381-Much-better-single-buffer-graphics

If you are going to attempt the methods linked above, use the code you find at the link above. The technique is demonstrated best. In simple terms, you keep 1/4 of the screen as a buffer, and use that buffer repeatedly to update the main screen. It's not really single buffer, but partial buffer.

Another method is to treat the graphics screen as several screens. I'll try to knock out an example, but the tools are there in the code linked. The tiles do not need to be sequentially stacked to form the screen. Plan out your tile addresses to fill the zones that need graphics, using a single blank tile to occupy empty areas. Think small rectangular areas. Then, to draw in any one area, you run gr.setup with the pixel value and bitmap address for that area, do your drawing. If it's a lot of drawing, you draw to a small off-screen buffer first, then use gr.copy to get things onto the main display.

Switch to the next area to be drawn, and repeat as needed.