Куда уехал цирк, т.е. память....

Недавно портировал свой проект c AVR на STM32 в CooCox 1.41 и получил весьма интересный результат по использованию оперативки… Если по флешу с оптимизацией -O2 разница ~15% в пользу AVR, то с оперативкой чето какойто косяк, если на AVR было 3963байт то на STM32 5336байт…
Итак Mega128:

STM32:

Сразу оговорюсь в STM32 я немного увеличил массивы и не выровнял пару структур, но это дало прибавки байт около 300.
Посмотрел в map файлы — у AVR все сошлось по переменным, а вот у STM32 нифига разница более 1кБ…
Чтобы это значило?
зы Прилагаю мап файлы как оригинальные так и переведенные в ексель секции переменных.

UPDATE:
startup_stm32f10x_hd.c

/*----------Stack Configuration-----------------------------------------------*/  
#define STACK_SIZE       0x00000100      /*!< Stack size (in Words)           */
__attribute__ ((section(".co_stack")))
unsigned long pulStack[STACK_SIZE]; 

собственно разница 0x400 это стэк — который показывается и учитывается при компиляции
Спасибо steel_ne за помощь!

  • 0
  • 06 мая 2012, 17:37
  • GYUR22
  • 1
Файлы в топике: ram_usage_avr_stm32.zip

Комментарии (21)

RSS свернуть / развернуть
процессор-же 32 битный.
-2
Файлы не смотрел, но пара очевидных соображений: на avr (в известном мне компиляторе) sizeof(int) = 2, здесь 4. Аналогично с указателями, size_t и т. п.
+1
типа я не совсем вроде уж тупой :) uint16_t
0
Вот ваша оперативка, смотрите сами какие переменные сколько занимают:


 COMMON         0x2000003c     0x1060 ..\obj\io_hardware.o
                0x2000003c                rldtmr
                0x2000003e                BO
                0x20000040                AI
                0x2000004e                BD_beg
                0x20000050                uart1
                0x20000158                ADC_CAL
                0x2000015f                mod_pos
                0x20000160                ADI_beg
                0x20000161                BI
                0x20000164                uart3
                0x2000026c                btns
                0x20000270                AO
                0x2000027c                res_table
                0x200004c0                SET_PAR
                0x200004c4                run_programm
                0x200004c5                ADF_beg
                0x200004c8                CNTRL_MEM
                0x20001091                ADI_q
                0x20001094                DAC_CAL
                0x20001099                ADF_q
                0x2000109a                CS
                0x2000109b                BD_q
 COMMON         0x2000109c       0x15 ..\obj\n2_slave.o
                0x2000109c                ovrd
                0x200010a0                pos
                0x200010a4                RTC_CLNDR
                0x200010ac                Cmd
 *fill*         0x200010b1        0x3 00
 COMMON         0x200010b4       0x1c ..\obj\main.o
                0x200010b4                run_cycle1
                0x200010b8                led7_array
                0x200010bc                val_ind
                0x200010c0                run_cycle
                0x200010c2                tmr_key
                0x200010c4                tmr_led
                0x200010c8                par_ind
                0x200010cc                ind_mode
                0x200010ce                tmr_1s
 COMMON         0x200010d0        0x5 ..\obj\led_key.o
                0x200010d0                key_timer
                0x200010d2                val_type
                0x200010d3                read_only
                0x200010d4                next_ind
                0x200010d8                . = ALIGN (0x4)
0
тут все хорошо 4252
0
про стек наверное забыли…
0
  • avatar
  • ZiB
  • 06 мая 2012, 18:33
там есть еще коварное место:
*(.co_stack .co_stack.*)
 .co_stack      0x200010d8      0x400 ..\obj\startup_stm32f10x_hd.o
                0x200010d8                pulStack
                0x200014d8                . = ALIGN (0x4)
                0x200014d8                _end = .


как раз на нехватающие 0x400 байт. Судя по всему какой-то внутренний стек кокоса.
+1
да это оно
10d8 -3с = 109c
+0x400
— 149c = 5276

но что это за стэк?
его же не видно при компиляции он с другой стороны растет?
0
Я не знаток кокоса, но судя по всему у него стек описывается явно. Посмотри где-то в районе файлов Startup и дефайна STACK_SIZE
+1
Слегка погуглил — это и есть стек. У АВР стек не учитывается в выводе Program size
0
/*----------Stack Configuration-----------------------------------------------*/
#define STACK_SIZE 0x00000100 /*!< Stack size (in Words) */
__attribute__ ((section(".co_stack")))
unsigned long pulStack[STACK_SIZE];

это вроде не 0x400. а 0x200?
0
блин он же long…
0
вот и разобрались )
0
Допустим gcodetools идет по минимуму — согласно даташита
After this startup delay has elapsed, the CPU fetches the top-of-stack value from address 0x0000 0000, then starts code execution from the boot memory starting from 0x0000 0004.

То есть камень автоматом берет значение top-of-stack и заполняет указатель стека. Это значение задается при линковке (в скрипте .ld), дальше срыв стека — на совести программера.
В кокосе, судя по всему, есть контроль переполнения стека, но платим статическим выделением памяти под него.
0
При использовании newlib можно контролировать переполнение стека при помощи модифицированной фукции sbrk: пример newlib stubs. Так, если мы попытаеммся выделить больше памяти, чем доступно, мы получем в терминале сообщение «Heap and stack collision».
0
какой смысл считать байты?
0
шоб места хватило
0
в СТМ32 хватит
-1
как вам сказать…
в value серии stm32F100 оперативки увы не очень много точнее в STM32F100RBT6 — 8кб RAM и 128кб FLASH. Портирование проекта имело цель не просто пересесть с AVR (со всеми вытекающими плюсами) но имея недорогой, маложрущий проц, получить больше памяти под буфера и объекты раза в 2 больше, а на вышеуказанном проце получается примерно всего 70% увеличение по объектам.
Конечно есть и более жирные процы, но и жрать они будут поболее помех будет больше, и все будет отражаться на АЦП (уже проверено)
0
Это еще не самый дешевый проц, на самом дешевом ЕМНИП 4/16 RAM/ROM.
Но бороться с этим можно — уменьши стек в стартапе кокоса или вообще перейди на другую среду.
0
пока еще с размером стэка не разбирался особо (пока все по дефолту) — может конечно чето и выиграется, но смысл в том что те процы где дофига памяти стоят поболее денег и жрут больше, а кокос мне пока очень даже нравится
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.