Cutting down on space while generating code.

I am doing some on target rapid prototyping with some pretty tight space restrictions. A new release of control software is about to be released and space is going to be at an even greater premium. So may question to the Matlab community is are there any tips or tricks for cutting down on the size of the code generated for our bypassed system? I have already switched to an embedded coder .tlc and enabled inline parameters.

[Jan]

Which space is limited? Memory to store the program or RAM for the data? Diskspace?

[Michael Joslin]

Memory to store the program onto the microcontroller RAM. If the code takes up too much space then we will have to switch to external bypass, while not being impossible it is still difficult and time consuming.

[Sven]

I think you'll need to clarify exactly what you mean by "memory to store the program". It might just be that I don't work with microcontrollers, but I'm afraid I still don't know what you mean. Can you give an example of a "heavy" program vs. a "light" program?

[Fangjun Jiang]

Just get it to the point, refer it as either ROM, RAM or Chronometrics.

[Walter Roberson]

Chronometrics ??

Sven: microcontrollers often have a Modified Harvard Architecture in which the program area is distinct from the data area. This has the nice security and stability feature that writing to data can seldom corrupt the program; it also offers timing advantages in that the program memory can be on a different bus working simultaneously with data memory. Furthermore, the program area can be written to ROM or EEPROM, reducing boot time and electrical requirements. And of course the arrangement has the obvious advantage of allowing more total memory without increasing the address register widths (and thus the instruction widths.)

However, it is common in microcontrollers that the amount of memory supported is fairly limited. I was just looking at the specifications on some of the Texas Instrument microcontrollers, and some of them only permit program memory on the order of 6 Kb to 20 Kb. Any "operating system" requirements (even if only boot-level code to allow the program memory to be reprogrammed) eats in to the limited program memory supported by the chip (or the architecture itself.) Thus, the size of the code (and any constants stored in program memory) can be quite important, even in cases where there is spare available RAM. Program vs data tradeoffs have notably different impacts on Modified Harvard Architectures.

[Sven]

@Walter: Thanks for the 101 - it's helpful as I've never really gotten my hands dirty with microcontrollers... excuse the newbie. What I don't quite get is how any of this translates back to a MATLAB program that the original question is about.

I imagine that:

1. MATLAB code is written. (.m? simulink?)

2. MATLAB code gets compiled into executable code and dumped onto the device as a program.

3. Device runs the program.

It's still unclear to me what step Michael is talking about (my guess is step 2, although my simplification might be wrong in the first place), and I would imagine that regardless of which step, any advice would vary wildly based on the actual program/data involved. I mean, for some programs "use loops not matrices" might be a general tip... for others "use matrix multiplication, avoid loops" might be good advice.

Can you tell what is wanted?

@Michael: Sorry for hijacking your question... it's mostly just curiosity.

[Fangjun Jiang]

The OP's use case is most likely generating C code from a Simulink model. When you generate code, there are many optimization options and trade-off options to choose from. For example, choosing in-line function rather than re-usable function calls will increase the ROM size but reduce the RAM usage. Using in-line parameters will reduce ROM and RAM but lacks the calibration capability. There are also options that might affect the chronometrics (CPU usage). The problem with the OP's question is it didn't clearly explain or didn't indicate a clear understanding of these terms. "Memory to store the program onto the microcontroller RAM" is confusing.

[Walter Roberson]

I would suggest that anyone who is programming at the TLC level probably has a fairly good idea of what they mean by "size of the generated code".

Executable images generated for embedded systems do not usually have much in the way of structure or overhead. The files are often not that much more than some magic numbers followed by a series of "Start at address X and copy in the following Y bytes", though some might be sophisticated enough to mark some areas as being intended for ROM, some areas for EEPROM, some for Flash memory, some for FPGA, and so on (as the loader that reprograms the embedded system might need to know which hardware treatment to use for which section)

Michael needs to know how to minimize the number of bytes generated to go in to EEPROM (or flash, or some other kind of non-volatile memory that the program will reside in.)

The most appropriate techniques probably depend upon the specific embedded board, and on the compiler being used, we do not have information about at present (and most of us probably won't happen to have had hands-on experience with.)

[Fangjun Jiang]

@Walter, I don't recommend making things complicated. The OP is asking for "cutting down on space". It's just that it is not clear whether it refers to ROM or RAM. And the comment "Memory to store the program onto the microcontroller RAM" is self-conflicting.

Answer 1

[Fangjun Jiang]

I assume you are using RTW. Follow the documentation Real-Time Workshop->User's Guide->Preparing Models for Code Generation->Configuring a Model for Code Generation->Configuring Code Generation Objectives

Once you select the ert.tlc, you will see the "Set objectives ..." and "Check model ..." buttons in the Real-Time Workshop panel.

Click "Set objectives ...", you will see the options for "Execution efficiency", "ROM efficiency", "RAM efficiency" and etc. I assume you want the ROM efficiency most so select that option, don't select the "Traceability" and "Debugging" as they might increase ROM.

Then you can click the button "Check model ...". It might give you some advice on how to modify your model to achieve your goals. Many times, the effect of choosing code generation options is limited. The way the model is constructed has the most impact on code generation.