Ran out of memory space-MC68HC912D60

[vinithaanand]

I ran out of memory space(RAM) while using the MC68HC912D60, what are my options. The code was inherited and very large hence I cannot go over it to see if I can improve it. I was looking into replacing the processor with one with more memory space. Realistically, how easy would it be to port the code if I chose a micro from the same family/form factor/pinout etc ( eg MC68HC912DT128A)?

[vinithaanand]

This is a follow-up to my initial quest. So based on your inputs, I did rewrite the code and optimized it to the best of my ability. It still doesn't help me with future expansion projects. Hence, without having to redesign the board completely (the peripherals  are too complicated and will be extremely time consuming to rebuild) , I am trying to look into using another microcontroller from the same family. Going over the 2 microcontrollers (MC68HC912D60A AND MC68HC912DT128A), register mapping, I found that for 60A and 128A micro at location $013E the PORTCAN and PORTCAN0 have been defined resp..to me they look identical. When I go to their pin-out 98-105, 60A has the PCAN0-7 where as 128A has it listed as RX/TX, SCL,SDA. In my original design pins 98-105 have been used as I/Os hence I will need to do the same with the new. Is there any way I can make it work? Almost all the other pins are a 1-1 match. appreciate any inputs. I have begun to work on my code to incorporate the changes required such as headers files/port declaration changes, mem etc to use the new micro. TIA

[TomE]

This isn't the right forum for your question unless you're considering changing to a Coldfire chip. You should post in the right forum. Which is the 8-bit one. There's a "Move" option under the "Other Actions" somewhere that lets YOU move it to the right place. Which is the "16 bit forum":

S12 / MagniV Microcontrollers 

How easy it is to port to a different model of that chip, or even to a Coldfire or Kinetis part depends on whether the code is written in Portable C or in Assembly.

If you don't want to even READ the code to see if you can make it better, you certainly don't want to port it to a different architecture.

You're lucky that you've run out of RAM and not ROM. All you have to do is to look at the generated MAP file and see if there are any large arrays or buffers in there that don't need to be that big. Also arrays of bytes or words that could be converted to arrays of bits.

This is standard software engineering. Everybody has to do that at some time or other.

> Realistically, how easy would it be to port the code if I chose a micro from

> the same family/form factor/pinout etc ( eg MC68HC912DT128A)?

Depends entirely on what peripherals the chip provides and what ones you're using. If the peripherals match, it should be very easy. The DT128A looks like a superset of the one you're using, with more memory and more peripherals. As for the pinout, you'll have to compare them yourself be getting the data sheets and reference manuals and comparing them side by side. Given there are more peripherals, they may be at different addresses (should be easy to change if the code is well written). Some of the control registers may have changed to deal with the extra peripherals (3 CAN controllers versus 1 and so on).

Tom

[vinithaanand]

Tom,

Thanks for your reply. I have moved it into the 8bit micro forum.

Regarding the code, I did begin to go through it, but it has about 109 files and hence I lost interest very soon in improving the code. The .map file was really helpful. I started working on that and hopefully that will help me trim the code a bit.

I did compare the 2 microprocessors I have listed and find a good match as far pin-out is concerned, hence that is good. The code is written in Portable C.

Thanks for your help.

VA

[TomE]

Sorry, I guessed the forum, then searched, then edited and didn't do that properly. This is a 16-bit part. The link in my post is to the proper forum.

If you've run out of memory then I assume you're editing code and adding some functions. So the new code took too much RAM. That's the place to start to see if the function can be written to use less RAM, or use it more wisely.

If you allocated an array or a buffer in your new code, see if you can find another buffer (from the map file or by searching for keywords or even looking for all "[]" characters) that isn't used at the same time as your new code. You can save a lot of storage by sharing it between functions.

Temporary RAM should be allocated on the stack. As long as that doesn't exceed the stack limits. Making sure the stack doesn't overflow is very difficult on small CPUs and you have to be very careful. You shouldn't put arrays on small stacks unless you know exactly how deep in the stack you are. Then you have to add the worst-case interrupt usage of the stack.

Look for all storage that is really CONSTANT. If the compiler is set up right, then declaring variables, strings and arrays as "const" should put them in ROM and free up RAM. Likewise all constant strings shouldn't take up RAM.

Tom