Programming assistance requested

firestorm.v1 · 2007-05-15 12:01

I'm sorry for the multiple posts, I promise that all the information that you all have been providing me has been helping tremendously!

I was hours into a mad coding session and accomplishing a TON of good stuff, when I ran into the dreaded out of memory error.

Unfortunately, this means that either I need to re-evaluate my code or I need to get another chip that has more program space.

I'm using a HomeWork board Rev B, and am looking to solicit information on coding techniques that I can use to minimize code space while maximizing what all I want to do.

Here's the code, I appreciate any suggestions! Keep in mind that this is still unfinished, some features work, but many still have yet to be written.

Thank you.

Mike Green · 2007-05-15 14:21

Your debug messages are quite wordy and take up a lot of room (figure at least the amount of text involved). You'll get some room by using shorter, more terse messages. I suspect you'll run out of the space gained pretty soon.

You could move to a different Stamp. The BS2 has only 2K for program storage. Most of the others have at least 16K (like a BS2p), but the 16K is divided up into 2K "slots" which can each contain a program. You can transfer control to the beginning of another slot and you can share variables, but it's not like you can just write a larger program. People have written significant multi-slot programs when they're easily "compartmentalized". Think of slots as overlays.

It sounds like you have big plans and they're probably too big for the Stamp. You may want to consider switching to the Propeller, mostly for its monolithic Spin program memory (32K). You can also use the SX processor and the SX/B Basic compiler which takes a version of Basic very close to that used by the Stamps.

firestorm.v1 · 2007-05-15 14:35

Hmm, thanks for the tips and the information about the SX/B. That sounds like something to blow my quarterly earnings bonus on.. :P (these things are addictive)

Talking about the BS2p, is it possible to take the big CASE statement and delegate control to those other "slots" for execution? E.g. Slot 0 is the main program, Slot 1 can control LCD0, Slot 2 can control LCD1, Slot3 can control the behavior of the device, Slot 4 can serve for DEBUG messages?

I have been thinking about buying a BOE Bot kit anyways as I was told that the chip-BS2 has more memory than the homework board I have now, but if I can find an SX starter kit, that might be something to think about instead. Do you know if the SX has any kind of serial buffer? (I'm thinking of building a SX-replacement of a common Matrix Orbital display that is based on a PIC controller. :P)

Thank you for your suggestions, I'm going to at least strip out the debug messages and see how much space that saves me in the mean time..

firestorm.v1 · 2007-05-15 14:46

Holy Cats! Cutting out the error messages and replacing it with "E!" cut a significant amount of program space. Before I was up to row 140, column C in the memory map, After changing only DEBUG statements, I recompiled and now the highest (lowest?) used address is 450,3, that's about 310 rows of additional space!

Instead of being 85% full, I'm now more around half! Thank you so much for telling me about the DEBUG statements, I had no idea that they used that much space in memory.

Mike Green · 2007-05-15 14:47

You might be able to split up the program as you mentioned (Slot 1 - LCD0, etc.). Debug message would need to be distributed so they're in the slot where they're needed. The issue is that there's no GOSUB/RETURN. When you transfer control from slot to slot, you always start over at the beginning of the program. Usually you keep some state information in a variable so you can go back to the place you want, but it's not like you can just return to where you left off.

The 24-pin Stamp BS2 is the same functionally as the Homework board. You wouldn't gain anything by switching. It's just that the BOE can take the other Stamp models (and the BOE doesn't come with a specific Stamp).

The SX doesn't "have a serial buffer". Buffering is all done in software and I think there are buffered serial routines available. Ask in the SX forum.

You could vary the debug messages by including a decimal number to identify them (like DEBUG "E",DEC2 5).

Post Edited (Mike Green) : 5/15/2007 2:52:05 PM GMT

firestorm.v1 · 2007-05-16 23:28

I like that method you mentioned with numeric error messages.. I don't think I'll have more than a couple, so I think I have some space to spare. [noparse]:)[/noparse]

Thank you for all your suggestions, I hope to be finishing this within the next week or so. [noparse]:)[/noparse]

Chris Savage · 2007-05-17 01:24

As a side note putting messages into DATA statements and writing a single print routine can save a lot of memory as well. The SEROUT and DEBUG commands are memory intensive not just because of the text but all the parameters associated with them. But if you can stuff one into a subroutine and keep reusing it then you’ll save a lot of space. Messages could be stored zero delimited as shown below and your routine would start at the label address and print until it hit the zero. Take care.

Message1  DATA  "This is message 1", 0
Message2  DATA  "Another Message", 0
Message3  DATA  "Hello", 0

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

firestorm.v1 · 2007-05-17 01:37

If I put the messages in a subroutine per your suggestion, each time the routine is used to say, print Message1, does the READ pointer start at "T" or at the last position from the last read of that data string?

Chris Savage · 2007-05-17 01:46

That depends on whether you reload the label address before calling the print routine. The index variable you use should be offset by the label address. So before you print message one you may do something like:

msgPntr = Message1

Then your print routine may look something like:

DO
READ msgPntr, text
IF text = 0 THEN EXIT
DEBUG text
msgPntr = msgPntr + 1
LOOP
RETURN

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

firestorm.v1 · 2007-05-17 02:36

oh! I see now, The msgPntr moves the start of the read to whatever message I set it to, then it reads till it hits that "0" then it exits the loop?

That's a cool way of doing it, I never knew that the DATA statements worked like that.

Thanks for the tip! Assuming I don't kill myself on storage space, I will put those messages in.

Thank you very much.

Chris Savage · 2007-05-17 03:48

Yes, that’s about it. Even though messages themselves can make up the bulk of storage, I’ve found simply consolidating the printing routine down saves enough space to justify not having to move to another BASIC Stamp Module. The BS2 is more capable than some give it credit for. There are so many ways to save space on an embedded controller. When you think like that it can make you a better, more efficient coder as well because you start thinking in more efficient terms and tend not to bloat the program unnecessarily. I hope this helps. Take care.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support

Programming assistance requested

Comments