Shop OBEX P1 Docs P2 Docs Learn Events
runtime memory constraints — Parallax Forums

runtime memory constraints

grouchygrouchy Posts: 16
edited 2010-01-11 10:45 in Propeller 1
I'm not much of a programmer, so I could use some help from someone with patience.
I got the hm55b compass module and a ping sensor, and I thought I'd put together a program to use them.
I started with the graphics demo on the object exchange as a guide, and I draw a circle on the tv display, and rotating crosshairs around the circle, this to display the compass heading. I also draw a bar with tick marks to display the ping range. Then I add the fullduplexserial object so that I can send the heading and range info to my pc (which runs a vb program to display the same thing).

Once I add fullduplexserial, the program is too big by 197 longs.
Fullduplexserial, tv, and graphics run in their own cogs. I haven't even put in the ping yet.

Why is my program so big that it won't run?



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Rudy's CNC Freeware·· http://www.enter.net/~schleinkofer
spin
spin
compass dial.spin
21K

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2010-01-11 01:53
    Graphics takes a huge amount of memory for the screen bitmap buffer. In addition, to make the graphics look nicer when it's changed, the graphics buffer is double-buffered.
  • BradCBradC Posts: 2,601
    edited 2010-01-11 01:56
    You are using 24k of the available 32k just for screen buffers.

    You write all your graphics to bitmap_base and then copy it to display_base when you are done.
    This is nice and ensures you don't get screen flicker, but it means your graphics bitmap space consumes most of your available ram.

    You might have to come up with a way to share the same buffer. This would really mean not clearing the display at the start of each run through, but looking at what has changed since the last pass, erasing and re-drawing only what has changed.

    If you can manage this, you free up stacks of space.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Life may be "too short", but it's the longest thing we ever do.
  • MagIO2MagIO2 Posts: 2,243
    edited 2010-01-11 06:12
    I could swear that there was a demo including a driver which used single buffered graphics with XOR operations for drawing. So, when you draw once in one color then you really draw, if you draw again in the same color it's like deleting.

    Can't find it currently on my EEE, have to look at the desktop when I'm back home in 12 hours. Or maybe someone else remembers as well and can help.
  • BradCBradC Posts: 2,601
    edited 2010-01-11 09:36
    MagIO2 said...
    I could swear that there was a demo including a driver which used single buffered graphics with XOR operations for drawing. So, when you draw once in one color then you really draw, if you draw again in the same color it's like deleting.

    Have a look at the XOR graphics driver and demo by Steven Messenger and DeSilva. It does precisely what you are looking for.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Life may be "too short", but it's the longest thing we ever do.
  • AribaAriba Posts: 2,690
    edited 2010-01-11 10:45
    The XOR version of the graphics object is in the object exchange.

    This question about memory problems whith the graphics object cames again and again and again in this forum.
    I think Parallax should place a big warning at begin of the Graphics-Demo which says that this is a demo for flicker free animation and should not be used as a template for real applications.
    And even better they should also include a demo with single buffer graphics, which can be used as template.

    Andy
Sign In or Register to comment.