Out of RAM!

So, i've been making a program for PIC12F629 in mikroC. Yesterday i finished my soft_usart_putstr function (sends a char* through uart). Here's the code: . But I have only 64 bytes of ram, and only 30 of them are free. So if I do: I am out of ram because each symbol is a byte. I tried to make a second function like that, especially for constant strings as the above, with "const char* str" instead of "char* str" as a parameter, but strlen() does not accept it. Do I have to take a second parameter "length" or I can do it in a better way? Thanks in advance!

if that string is a "constant" you can store it in EEPROM instead in ram (add const before char) but the pic you are using (64b ram, 128b rom) ain't really the one for storing data (text) and if you look at how much it cost, for the same price you can get a 18f* chip, or at least 16F629

Yes, i got the idea for the eeprom in mind, and I got a gient "OUT OF EEPROM" message.

I am not looking at the price, but thia is a rocketry timer and I can't put a big controller. So I decided to make the things simple, and I'll write a program in java for the PC, so I won't make a user-friendly usart dialog. Thanks for the reply anyway.

I don't know MicroC but wonder if making it a ROM constant would help. Something like,


and

Note, this is not the EEPROM area but the program area and so you will have a lot more space. Check the manual for rom constants.

Mike.

Also, you can save a lot of ram by not using the strlen function and just using the pointer,

Mike.

Syntax is:

(const char) "ccc"

that will put "ccc" into programming memory (not much of those too on this pic)

with regards to "can't put a big controller" 12F629 is 8 pins, if you can go to 14legs you can get much better uC but, if 8 is your limit not much better there ...

EDIT: just checked you can go with 683 it has:

it also have 1 8bit timer more, 1 A/D, 4x10-bit @ 30ksps more, internal osc at 32K...

so .. double the ram, double the eeprom, double the program memory, same package (8pins)

Perhaps a bit obvious?, but why not write the program in assembler which is far lees taxing on resources.

Nigel Goodwin said:

Perhaps a bit obvious?, but why not write the program in assembler which is far lees taxing on resources.

Click to expand...

Once you get familiar with the way C allocates resources, it's not that bad. It will always use more ram than assembler but as most project only use a fraction of the ram available this is not a problem. Even if it is a problem the next size chip is only a few cents more. The great advantage is that C is less taxing on your time.

Mike.