A good buddy of mine is working on his final project in electrical engineering. He has been using a Motorolla Microprocessor in a Serial I/O configuration. He just found out that even though his team had split the Input code from the output code, the Input code just won't fit into the 512 MB of memory he has available.

Its way too late to switch to another microprocessor, or switch it over to parallel. His team has tried its best to make the input code as small as possible and still a no go. He has a week left to figure out how to get it to work if it can.

Does anyone have ANY suggestions whatsoever as to what can be done (ie. add ons, cheats, etc.) to make it work or is he just SOL?

 

Can I assume by 512 MB, you mean 512 Megabits?

hgmjr

 

yep, as far as I know at least

 

512 Megabits equals 64KBytes. What motorola microprocessor is the design based on?

hgmjr

 

68HC12 microprocessor, and I also stand corrected, 512 bytes.

Debug 12 is taking the rest of the 32 kilobytes available.

 

Well, then dump the debugger.

Strip out any code that isn't absolutely essential to the task.

Look for redundant code; things that should've been subroutines or function calls.

Table look-ups instead of lots of comparisons.

Look for more elegantly simplistic ways of handling arithmetic functions, if used.

Fight for every byte.

If they're programming in a high-level language, they need to drop to a lower level, like Assembler. They probably don't have time to do that. The learning curve is rather steep. They should see if they can perhaps find an optimizer for the language they're programming in. Turn off options, turn off debuggers (debuggers can add a LOT of code)

Check out this Wikipedia entry:
http://en.wikipedia.org/wiki/Freescale_68HC12
There's a link to a discussion group on this particular processor near the bottom.

Years ago, I was involved in a project to re-write a heavily-used mainframe computer program; the original was written in a hybrid COBOL/Assembly Language module, and was compiled using an optimizer. Even after being optimized, the original program still took up around 250 kilobytes of main storage.

My re-write in Assembler took just 8 kilobytes of storage, or two pages.

It may be that their project can be accomplished.

It's up to them.

I have NO experience with that processor at all, so I will be of no further help.

 

Thanks a lot. They are already writing it in assembler. I will make sure to tell them to get cracking on those procedure calls. Another good idea on the table lookups. Hopefully they can get it working within the next week.

I can only say thank goodness I am not working on that final project. Instead I have the wonderful final project of making an old robot play tic tac toe. The robot also runs off of a microprocessor, but we really don't have to get all that intimate with it (yay-ness!).

I have about 10 more hours left of coding for it, part of which we have to read 4 bits from the microprocessor split between 2 registers (just cause my teacher felt like being mean) to interpret which button the user has pushed. Based upon that (and one of three modes of difficulty) dictates the robots move.

However, I came across the problem that I can only tell the robot to move up to 90 degrees, unless I want I want to lock it up. I have to constantly keep telling it to move 90 degrees until the value that is left is less than 90 degrees. Bundles of fun.

Its even hooked up to a database to record moves made and then you can select which game you want to see replayed and the robot will replay it. It will clear the board, move the pieces for you, check to see who won, etc. I have spent over 70 hours programming this thing to present on Thursday. If it does not work perfectly when I present it, I fail. *sigh*... Wish me luck! And thanks again!