video conflicts with ADC code

Branmuffin Industries

Hey everyone,

I'm having some trouble getting pieces of code to work together. I have an ADC0838 object that works great with the TV and graphics objects in one application.

However, in my other set of code, it seems the video display stops outputting or gives me scrambled junk on the screen whenever I load additonal objects or pieces of code. There must be a conflict somewhere, because these pieces work well in isolation. They just don't get along. These two objects are using separate I/O pins, and I don't think I'm running out of memory. I don't think there are any conflicts with temp variable names either.

Has anyone else had problems with a video output in conflict with otherwise working code?

Let me know where I should look next on this.

Thanks

StefanL38

Hello,

this might be an problem of mixed up pointers or of a too small stacksize for one of the objects.

Please post your code that's working and code that shows the error

otherwise you might have to wait for YEARS until somebody else has exact your problem

best regards

Stefan

Rayman

you have to be carefull with "graphics" because it uses large spaces of memory as undeclared arrays.·

I have some notes here:
http://www.rayslogic.com/propeller/Programming/GraphicsDemo.htm

I imagine that you're using memory that needs to be free for graphics...

Branmuffin Industries

Thanks, Rayman. I've read your notes and they help a lot.

Even though I may go to Object Info and see tons of available stack space, in runtime the Graphics Objects take up most of the 32kB of hub RAM. This explains why I am getting artifacts (weird symbol garbage start to show up in the upper left corner of my graphics display) and then if I add more code, the screen shuts off entirely.

The next question is: are there auxiliary RAM chips that can be used to overcome this hardware limitation, or do I have to find a way to further optimize my code?

-Ryan

Branmuffin Industries

Well, I finally am beginning to understand that the video stack uses up 6100 of my 6167 available longs. This seems to be a frustrating limitation of the propeller. The RAM is too small to accomodate the complexity of the program I'd like to build.

I am attaching my code as a .zip file, in hopes that the folks in Parallax tech support can help me find a way to make it smaller. If not, I might have to move to another platform that has more than 32 kb of hub RAM.

This might be a rather ignorant statement, but in this day and age of gigabytes and gigahertz, where is the "superpropeller" with 32 MB of ram? I've spent hours learning spin code... has it been worth it?

-Ryan Brandys
Branmuffin Industries

Rayman

If you can forego the double buffering, you can half the memory requirements of Graphics. But, can cause screen flicker for fast changing screens...

Branmuffin Industries

I can handle a little screen flickering. What do I have to do to turn double buffering off?

Is there a way to use a black and white screen instead of four color screen? that would half the memory requirements too.

Rayman

As I recall, (search this forum for more info) to get rid of double-buffering, just replace every instance of "bitmap_base" with "display_base".
Then, remove the line that used to copy bitmap_base into display_base...

hippy

Branmuffin Industries said...
I might have to move to another platform that has more than 32 kb of hub RAM ... I've spent hours learning spin code... has it been worth it?

Unless you can find a solution which has the RAM you need and video on board you'll be up to a dual chip solution as a minimum, and in that case a dual Propeller solution will give you what you need keeping all the advantages of the Propeller and Spin/PASM.

It means some additional work and cost effectiveness would be application and quantity dependent.

Removing double-buffering ( I don't know how but there are previous posts on how to do that ) would be the first step towards keeping a single-chip solution but I personally wouldn't be adverse to using a Propeller as an additional standalone VGA / Video interface.

Branmuffin Industries

i tried making two simple modification to the CON block to turn off double buffering. this modified code works fine but the display flickers some.

i wil try adding more code at this point and see if it crashes the display, as it did before when double buffering was on.

CON

_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
'_stack = ($3000 + $3000 + 100) >> 2 'accomodate display memory and stack
_stack = ($3000 + 100) >> 2 'accomodate display memory and stack

x_tiles = 16
y_tiles = 12

paramcount = 14
bitmap_base = $2000
display_base = $2000
'display_base = $5000

lines = 5
thickness = 2

Rayman

I think you may want bitmap_base at $5000 instead of $2000....

Branmuffin Industries

what i did with my code revisions is I shortened the stack from 6100 to 3100, and I made bitmap base and display base occupy the same space by giving them the same pointer. you're saying that i should push both of them to $5000, which is nearer to the end of RAM? So it would look like this (note the apostrophes for commented out lines)

_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
'_stack = ($3000 + $3000 + 100) >> 2 'accomodate display memory and stack
_stack = ($3000 + 100) >> 2 'accomodate display memory and stack

x_tiles = 16
y_tiles = 12

paramcount = 14
'bitmap_base = $2000
bitmap_base = $5000
display_base = $5000

lines = 5
thickness = 2

Branmuffin Industries

that worked great! and, as an extra added bonus, it solved my artifacting problem. I can now continue to add code to my heart's content. rock on. Thanks all.

-Ryan

Rayman

Glad you got it. In principle, the _stack directive should have prevented the problem you had... The compiler should have given an error... Wonder why it didn't...

Ale

I'm developing an application with graphics and ADCs, so I resolved to use two propellers, one for ADC and one for the LCD, comm, user interface and so on. If you can cram everything in one propeller, do it. Two props are quite a nightmare to work with. I have some problems because the ADC stops working. I simulated the code and it should not happen... but it does. The inter-prop link works great, though. i will look closer into it today.