Extended Code Size while migrating from Arduino ProMini board to STM32 Maple-Mini board.

umerocks
Posts: 10
Joined: Mon Sep 19, 2016 9:02 am

Extended Code Size while migrating from Arduino ProMini board to STM32 Maple-Mini board.

Post by umerocks » Thu Oct 20, 2016 10:04 am

Hello every one,
I have got a problem and am unable to sort it out. I have a code on Arduino written for Arduino-ProMini. Code length is 30kb. As I moved my code from Arduino Pro-Mini to STM32 Maple-Mini my code size extended to around 100kb. I want to decrease the code size some what upto 64kb.
Can any one suggest me what should I do??

danieleff
Posts: 300
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: Extended Code Size while migrating from Arduino ProMini board to STM32 Maple-Mini board.

Post by danieleff » Thu Oct 20, 2016 1:25 pm

Find the functions that take the largest space:

Code: Select all

arm-none-eabi-nm --print-size --size-sort --radix=d yourfile.elf
It should put the functions/variables that are largest to the bottom of the list.

umerocks
Posts: 10
Joined: Mon Sep 19, 2016 9:02 am

Re: Extended Code Size while migrating from Arduino ProMini board to STM32 Maple-Mini board.

Post by umerocks » Thu Oct 20, 2016 3:40 pm

Thanx Deniel for ur reply, can u plz guide me where to write those lines
"arm-none-eabi-nm --print-size --size-sort --radix=d yourfile.elf"

zmemw16
Posts: 1262
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

Re: Extended Code Size while migrating from Arduino ProMini board to STM32 Maple-Mini board.

Post by zmemw16 » Thu Oct 20, 2016 5:20 pm

umerocks wrote:Thanx Deniel for ur reply, can u plz guide me where to write those lines
"arm-none-eabi-nm --print-size --size-sort --radix=d yourfile.elf"
as i was curious

Code: Select all

~/builds/workspace/libopencm3-examples/examples/stm32/f1/waveshare-open103r/usbserial$ arm-none-eabi-nm  --print-size --size-sort --radix=d usbserial.elf 
all one line, as i'm currently off in SPL land, it's from libopencm3-examples and as i have one of these boards ... ...
output was fairly long and largest is usb related :D

Code: Select all

134222020 00000136 T st_usbfs_ep_write_packet
134221148 00000144 W reset_handler
134219738 00000146 t usb_standard_set_configuration
134221728 00000176 T st_usbfs_ep_stall_set
134222156 00000180 T st_usbfs_ep_read_packet
134222336 00000224 T st_usbfs_poll
134222560 00000236 T memcpy
536871072 00000252 B st_usbfs_dev
134221368 00000292 T st_usbfs_ep_setup
134217728 00000336 T vector_table
134220210 00000606 t usb_standard_get_descriptor
stephen

danieleff
Posts: 300
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: Extended Code Size while migrating from Arduino ProMini board to STM32 Maple-Mini board.

Post by danieleff » Thu Oct 20, 2016 6:07 pm

umerocks wrote:Thanx Deniel for ur reply, can u plz guide me where to write those lines
"arm-none-eabi-nm --print-size --size-sort --radix=d yourfile.elf"
You can find the commands and the created elf file by checking file/preferences/show verbose output during: both checkboxes, and then compile.
In windows its generally in C:\Users\USERNAME\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1\bin , and C:\Users\USERNAME\AppData\Local\Temp\buildXXXX.tmp\XXX.elf .Move the .elf file to the bin folder, and execute the command in command prompt.

User avatar
RogerClark
Posts: 6114
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Extended Code Size while migrating from Arduino ProMini board to STM32 Maple-Mini board.

Post by RogerClark » Thu Oct 20, 2016 8:43 pm

Almost certainly the code you are compiling will have use the new operator, or something else that means the linker has had to pull in a massive amount of memory management code.

This will still probably fit into the bluepill as most of them are actually 128k flash devices, even though they are sold as 64k.

So the simple solution is to select generic stm32f103cB instead of c8


More complex solution is to change to code to use static instantiation of memory.


The reason the code is small on the AVR, is that it uses customised memory management libs.

I am not an expert in the ARM Gcc libraries, and there may be a smaller lib you could link instead of the one we normally use, but other people have already encountered this problem, and I don't think the solution is to use a different lib ( though I cant remember why not)

umerocks
Posts: 10
Joined: Mon Sep 19, 2016 9:02 am

Re: Extended Code Size while migrating from Arduino ProMini board to STM32 Maple-Mini board.

Post by umerocks » Mon Oct 24, 2016 12:26 pm

Thanks every one for your suggestions and help. Finally I figured out the problem.
There were two static variables which were initialized with a "micros() and a Variable" that were causing an amazing increment in code size. By fixing their initialization, code size reduced to 38KB.
Hope this could help others facing the same problem

edogaldo
Posts: 252
Joined: Fri Jun 03, 2016 8:19 am

Re: Extended Code Size while migrating from Arduino ProMini board to STM32 Maple-Mini board.

Post by edogaldo » Mon Oct 24, 2016 1:29 pm

umerocks wrote:Thanks every one for your suggestions and help. Finally I figured out the problem.
There were two static variables which were initialized with a "micros() and a Variable" that were causing an amazing increment in code size. By fixing their initialization, code size reduced to 38KB.
Hope this could help others facing the same problem
Did you identify them through the method suggested by danieleff? If not, how did you identify them?
Furthermore, could you provide the code snippet related to the initialization of the 2 variable? (I don't know what is "Variable")

Thanks in advance, E.

umerocks
Posts: 10
Joined: Mon Sep 19, 2016 9:02 am

Re: Extended Code Size while migrating from Arduino ProMini board to STM32 Maple-Mini board.

Post by umerocks » Mon Oct 24, 2016 2:44 pm

Sample:
void ABC(void){
uint8_t Value_1 = 0;
static unsigned long Value_2 = micros(); // culprit
static unsigned long Value_3 = Value_1 ; // culprit

//replaced with
static unsigned long Value_2 =0;
static unsigned long Value_3 = 0;
.
.
.
}

When used danieleff's method, only function's code size was printed. As static variable initialization might have included some other internal libraries which didnt show the increased ABC() size. Then i commented out all of the functions being called and uncomment them one by one and compiled the code each time until i came to the fn consuming large memory. Then went thru the fn's code and sorted out the problem

User avatar
RogerClark
Posts: 6114
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Extended Code Size while migrating from Arduino ProMini board to STM32 Maple-Mini board.

Post by RogerClark » Mon Oct 24, 2016 7:58 pm

Please disregard my post (below), as as Rick has pointed out the code is not in global scope

Looking at the code again, perhaps the code is just an example rather than the real code, as the variable names seem strange.
i.e not real names of things.



Interesting, and also quite strange.

I didnt known it was possible to call functions to initialise variables in C.
Initialisation of variables in global scope is always problematic, because the order in which things are setup is not defined in the C specification.

The call to millis() would be a complete waste of time, as its bound to be zero
And its not valid to call millis() before main() as on most processors the hardware needs to be confugured to operate the millis() counter e.g. PLLs need to be setup unless your MCU happens to have a dedicated hardware millisecond counter register.

With the static vars, does the code size jump if you just fix the millis() problem?

It seems odd that just assigning a non static variable to a static variable would cause the linker to require a load of memory management code.

But perhaps the compiler is having to jump through hoops to technically do whats being asked pf the code.

IMHO. I would be a bit worried about the quality of the code you are using.

I would never assign a variable to another variable in global scope. If two variables need to contain the same value during initialisation, I would make a #define for that value ( assuming its not zero) and use the define to init both vars sepately.

Also naming things as "variable1" is bad practice.
And why is variable1 not static? ( relates back to bad naming of variables as there is no way to know by looking at the variable name, precisely what it is used for)
Last edited by RogerClark on Mon Oct 24, 2016 9:54 pm, edited 3 times in total.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest