24LC512 vs 24LC256

shmow

Hey all,
this question seems kind of obvious - but I'm a novice on the subject. I've run out of room with the size of my code. If I replace my existing 24LC256 with the 24LC512. Will I get more storage space for my program?
Regards,
Shmow

Oldbitcollector (Jeff)

Only in the sense that you will have room for outside variables, other binaries, etc.

I'm afraid that you won't get more than the 32K of run-time memory by increasing your EEPROM.

Any chance you can break your code into two binary sections? Then you could store half of your program
as one program in the extra memory provided in the EEPROM you want to use.

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Feature Projects: PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.

jazzed

shmow said...
If I replace my existing 24LC256 with the 24LC512. Will I get more storage space for my program?

Not unless you plan to sky-dive through 1000 flaming hoops [noparse]:)[/noparse]

For Java, the Propeller JVM can use the bigger EEPROMs up to 128KB for having larger programs ... I just haven't released that version yet.

For Spin, if you are using COG drivers, it is possible to reclaim the space normally taken by the COG code. There are a few ways to do that. Mike Green wrote an O/S that allows reclaiming space, but I can't remember the details. This is similar to what OBC mentions. Too bad there isn't a package in OBEX to do this in simplest possible terms.

In Spin, I've experimented with running code directly from EEPROM. While this could effectively double the Propeller footprint in by saving HUB RAM for things like video buffers instead of code, there are many issues making the system impractical without Spin compiler changes.

For C, RossH has a mode in Catalina that will use bigger EEPROM and allow for relatively bigger C programs. I've discussed using even bigger EEPROM with him (using a cache the same way Propeller JVM can), but have not had time to implement it.

Cheers,
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

Timothy D. Swieter

Shmow - tell us more about your software, maybe we can help you find ways to optimize it to allow it to fit in the 32K limit.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com

shmow

Hey Y'all,
thanks for the help.
I've found some wiggle room; I wanted to use Mike Green's minimal I2C driver (now I have to figure how to make it work with what I have).
Cheers,
Shmow

PS - 1000 flaming hoops...that was a good one, made my day.

ericball

jazzed said...
For Spin, if you are using COG drivers, it is possible to reclaim the space normally taken by the COG code. There are a few ways to do that. Mike Green wrote an O/S that allows reclaiming space, but I can't remember the details. This is similar to what OBC mentions. Too bad there isn't a package in OBEX to do this in simplest possible terms.

COGNEW( @cogstart, @parmptr )
LONG[noparse][[/noparse]@cogstart][noparse][[/noparse]0...495] := data

Just be aware that some cog drivers also use this space.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

John Abshier

Does a DAT section always take 496 longs of hub ram?

John Abshier

Mike Green

John,
No. The Propeller always loads 512 longs from hub memory to the cog's memory. If the DAT section is shorter than that, the portion of hub memory that follows the DAT section is copied to the cog whatever happens to be contained there. The last 16 longs are copied to "shadow cog ram" that is "overlaid" by the special registers of the cog.