Tips for moving buffers, saving memory, Re Object exceeds runtime memory limit by.. ?
Chris B.
Posts: 18
I'm trying to use Graphics and TV library, plus some serial routines, and running out of main memory. I'm doing text and graphics (user display for numerical info dashboard type), receiving data from one-wire probes and from a serial peripheral.
The screen buffers are so huge that they can only reside in main memory. First thing I did was turn off the mirror display for the graphics package, suffering the terrible flicker. Wondering how slow the screen update code really is, can screen repaints be done while the raster is not visible? I might also try XOR type updates or small erasures writing over old object before redrawing instead of actually clearing the screen. Also curious about using lower resolution, fewer tiles, etc.
Is there another nice graphics library?
The serial routines use buffers in main memory when it seems like since they're firing off their own cog, they could notionally use cog memory to buffer incoming and outgoing serial data. The main program can't see cog memory, but could fetch byte or bytes using single char or smaller local buffer for transfers (double buffer). Can I get the serial buffers into their cogs somehow? Has anyone done this already? getch() and putch() could be done in assembler for instance to enqueue and dequeue from the tx and rx buffers if the buffers are in the cog memory. This brings back memories, in college I had to write a full duplex serial handler in x86 assembler for the 8250 UART.
Another question, since a cog executes out of cog memory after being copied from main memory, then that should free up 496 longs in main memory after the cog fires off, to potentially be reused? Such as do a "union" of the cog DAT and the needed serial buffers, so that after calling Start/cognew() to launch the assembly language program, treat the @asmaddress pointer as a 496x4 byte buffer?
Best regards,
Chris
The screen buffers are so huge that they can only reside in main memory. First thing I did was turn off the mirror display for the graphics package, suffering the terrible flicker. Wondering how slow the screen update code really is, can screen repaints be done while the raster is not visible? I might also try XOR type updates or small erasures writing over old object before redrawing instead of actually clearing the screen. Also curious about using lower resolution, fewer tiles, etc.
Is there another nice graphics library?
The serial routines use buffers in main memory when it seems like since they're firing off their own cog, they could notionally use cog memory to buffer incoming and outgoing serial data. The main program can't see cog memory, but could fetch byte or bytes using single char or smaller local buffer for transfers (double buffer). Can I get the serial buffers into their cogs somehow? Has anyone done this already? getch() and putch() could be done in assembler for instance to enqueue and dequeue from the tx and rx buffers if the buffers are in the cog memory. This brings back memories, in college I had to write a full duplex serial handler in x86 assembler for the 8250 UART.
Another question, since a cog executes out of cog memory after being copied from main memory, then that should free up 496 longs in main memory after the cog fires off, to potentially be reused? Such as do a "union" of the cog DAT and the needed serial buffers, so that after calling Start/cognew() to launch the assembly language program, treat the @asmaddress pointer as a 496x4 byte buffer?
Best regards,
Chris
Comments
One quick way to get memory back is to remove the double buffering.
The screen will flicker when updated, but you get a ton of memory back...
There's no convenient way to re-use the space used to load the cogs. Each object that uses a cog would need to have a method that returns the starting address and length of the code area and some other object would need to be designed to make use of these areas. Some objects in the ObEx already reuse the code area for buffers like the 4-port serial driver.
My favorite for this is JDcogSerial. It keeps the buffer in the cog and has a very small spin-interface and a very nice pasm interface so also easy to call from another pasm-cog. see attachment.
JDCogSerial-09.03.19-Autodoc.zip
the next thing you can do is reuse the space used by the pasm part of objects, if you do not need to restart them again. (except reboot)
But this is tedious since you have multiple blocks in memory, not one big one. And the size is fixed by the actual pasm dat block.
Next thing you can do is removing unused methods in spin by commenting them out. BST has some options to do this but with the proptool you are on your own there.
Well and optimizing code is another way. Spin is quite small bytecode so even if you have just 2 lines of code more then 3 times in your code - make a method out of it. Saves already one long...
Enjoy!
Mike
.
Yes, the flicker was totally unacceptable. But I'm already working on a fix. I'm going to only redraw the elements that change instead of wiping and re-painting the entire screen. I already did a rough hack to my demo and it worked. I just write the previous text in background color then write the new text, and same concept for graphics, which flicker a little when repainting.
I really like the graphics library, but it is also confusing. I don't get what's going on with the rainbow of color bars for one of the colors. It would be nice to be able to configure those color bars differently, such as a few thick bars of just a few colors. Also don't know what's going on with the 64 color definitions. By randomly changing the constant, I was able to make color 0 to be white instead of black, and I liked that and kept it.
Need to find that variable that indicates when the retrace starts. I was doing a repeat while tv_status<2 right before the flickering graphics redraw, but that didn't seem to reduce flicker.
Anyhow, need to get this working fast and while also juggling other things. Can't finesse it too much.
Thanks!
Bingo, this serial driver rocks. This is what I'll use.
I suppose the pasm block can be padded at the end to make it longer if needed. How do I figure out how long a DAT block is?
I keep seeing shout outs for BST, I should look at it. And you're right, there are a bunch of methods I can strip out.
I am enjoying. I don't mind spin, but if this isn't my only Propeller project ever, I'll take a look at Prop C. Right now it's not worth the bother. Thanks to JDCogSerial, combined with getting rid of the video double buffer, I should be done with my project by the end of the week.
Thanks!
Chris
If you only need graphics in small areas of the screen, you can save a lot by making several smaller graphics windows...