|
|
  |
Освоение ARM контроллеров |
|
|
|
Apr 5 2016, 17:26
|
Частый гость
 
Группа: Участник
Сообщений: 107
Регистрация: 13-05-09
Пользователь №: 49 008

|
Цитата(jcxz @ Apr 5 2016, 19:37)  Как Вы смотрите бинарник? Как там видите адреса? Не адреса я смотрю в отладчике, а в бинарнике вижу что он совсем отличается от того что выдаёт отладчик. Данные с бинарника похожие на то что в отладчике только когда я собираю проект без смещения.
Сообщение отредактировал maxntf - Apr 5 2016, 17:32
|
|
|
|
|
Apr 9 2016, 07:36
|
Частый гость
 
Группа: Участник
Сообщений: 107
Регистрация: 13-05-09
Пользователь №: 49 008

|
Цитата(scifi @ Apr 5 2016, 18:10)  Я отлаживаю в кейле. Там можно подключить скрипт отладчика. В скрипте пишу Код SP = *(int*)0x08001000; PC = *(int*)0x08001004; И всё. А где именно это можно сделать, можно подробнее?
|
|
|
|
|
Apr 12 2016, 15:09
|
Частый гость
 
Группа: Участник
Сообщений: 107
Регистрация: 13-05-09
Пользователь №: 49 008

|
Подключил FreeRTOS, пока практически пустой проект 3 задачи для теста - 1-я контроль кнопки, 2-я передача строки "Hello World" в UART и 3-я мигание индикаторами. Хотя в FreeRTOSConfig.h и стоит #define configTOTAL_HEAP_SIZE ( ( size_t ) ( 75 * 1024 ) ) , но в SRAM забрало очень много места, почти 60% всей ОЗУ. Цитата Program Size: 12440 28 79288 91756 1666c main.elf text data bss dec hex filename Подскажите почему так? Смотрел в map файле я так понимаю что все жрет heap_2.c Цитата *fill* 0x200001aa 0x6 .bss 0x200001b0 0x12c14 ..\obj\heap_2.o *(COMMON) COMMON 0x20012dc4 0xe ..\obj\main.o
|
|
|
|
|
Apr 12 2016, 17:14
|
Частый гость
 
Группа: Участник
Сообщений: 182
Регистрация: 16-10-15
Пользователь №: 88 894

|
Цитата(zltigo @ Apr 12 2016, 23:13)  Следует слегка постараться и отдавать хипу всю память от конца статически распределенной компилятором до конца памяти контроллера. Интересно, каким способом??? Я например точно знаю что GCC не умеет считать размер стека прерываний в режиме перепроцессора. Уже потом в отладке, фоновым процессом самого отладчика контролируется нижняя граница, и только в одном режиме ядра - для ос это уже недоступно. Копал долго и упорно, но возможно что-то упустил. Для себя эту проблему решил простым способом: heap условно растёт в верх, на встречу стеку. Условно, потому-что свой heap, для gcc он нулевой, используется только точка старта. При заполнении всей памяти - новые задачи и новый маллок морозится, пока жирность не спадёт. Очень удобно однако.
|
|
|
|
|
Apr 12 2016, 18:49
|

Гуру
     
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244

|
Цитата(AVI-crak @ Apr 12 2016, 20:14)  Интересно, каким способом??? Как и любое выделение памяти. Цитата Я например точно знаю что GCC не умеет считать размер стека прерываний в режиме перепроцессора. Уже потом в отладке, фоновым процессом самого отладчика контролируется нижняя граница, и только в одном режиме ядра - для ос это уже недоступно. Копал долго и упорно, но возможно что-то упустил. Подумате головой и выделите именно стеку фиксированный размер памяти. Отдавать стеку ВСЕ свободное пространство, причем НИКАК его размер не контролировать в надежде, что хватит, это безумие. Цитата Для себя эту проблему решил простым способом: heap условно растёт в верх, на встречу стеку. Навстречу чему, это уже зависит только от Вас, поскольку где Вы расположите стеки(и) там они они и будут. У меня системные стеки внизу. Цитата Условно, потому-что свой heap, для gcc он нулевой, используется только точка старта. Нулевой это перебор. Можно указать в для статической линковки какой-то минимальный размер для старта системы. Потом уже при запуске узанать верхнюю границу памяти и сказать мереждеру, что от начала статически слинковоного блока и до конца свободной памяти все его. Пример распределения памяти для ARM7 CODE define symbol Code_start = 0x00000000;
// Memory Regions ----------------------------------------------------------- // 256K ROM memory define symbol ROM_start = 0x00000000; define symbol ROM_end = 0x00007FFF; // 16K RAM memory define symbol RAM_start = 0x40000000; define symbol RAM_end = 0x40001FFF;
// Memory Block Sizes define symbol SIZE_CSTACK = 0x20; // Dummy System/User Stack Size (Not Used!) define symbol SIZE_SVCSTACK = 0x180; // Supervisor Mode (Main Work Mode) define symbol SIZE_IRQSTACK = 0x200; define symbol SIZE_FIQSTACK = 0x40; // define symbol SIZE_XXXSTACK = 0x20; // 32bytes Shared Stack for Abort/Undefined Instruction and IAP Buffer define symbol SIZE_HEAP_RTOS = 0x400; // 1Kb - Dummy _minimal_ space for Memory Manager
define memory mem with size = 4G; define region ROM = mem:[from ROM_start to ROM_end]; define region RAM = mem:[from RAM_start to RAM_end - SIZE_XXXSTACK]; define region RAM_endblock = mem:[from RAM_end - SIZE_XXXSTACK + 1 to RAM_end];
define block CSTACK with alignment=8, size = SIZE_CSTACK { }; define block SVC_STACK with alignment=8, size = SIZE_SVCSTACK { }; define block IRQ_STACK with alignment=8, size = SIZE_IRQSTACK { }; define block FIQ_STACK with alignment=8, size = SIZE_FIQSTACK { }; define block HEAP_RTOS with alignment=8, size = SIZE_HEAP_RTOS { }; define block XXX_BLOCK with alignment=8, size = SIZE_XXXSTACK { }; define block CHECKSUM { readonly section .checksum };
initialize by copy { readwrite }; do not initialize { section .noinit };
place in ROM { readonly section .intvec }; place in ROM { readonly }; place in ROM { block CHECKSUM };
place in RAM { readwrite, block CSTACK, block SVC_STACK, block IRQ_STACK, block FIQ_STACK }; place in RAM { block HEAP_RTOS };
place in RAM_endblock { block XXX_BLOCK };
Сообщение отредактировал IgorKossak - Apr 12 2016, 20:01
Причина редактирования: [codebox] для длинного кода, [code] - для короткого!!!
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
Apr 12 2016, 21:39
|
Частый гость
 
Группа: Участник
Сообщений: 182
Регистрация: 16-10-15
Пользователь №: 88 894

|
Цитата(zltigo @ Apr 13 2016, 01:49)  Как и любое выделение памяти.
Нулевой это перебор. Можно указать в для статической линковки какой-то минимальный размер для старта системы. Потом уже при запуске узанать верхнюю границу памяти и сказать мереждеру, что от начала статически слинковоного блока и до конца свободной памяти все его. Ну я и вижу как вы мучаетесь, в ручном режиме считая байты. Нижняя граница свободной памяти равна стартовому адресу heap, этого более чем достаточно для моего менеджера памяти. Хотя я надеялся увидеть хитрую трёхэтажную запись мнемониками перепроцесора самого GCC.
|
|
|
|
|
Apr 12 2016, 21:52
|

Гуру
     
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244

|
QUOTE (AVI-crak @ Apr 13 2016, 00:39)  Ну я и вижу как вы мучаетесь, в ручном режиме считая байты. Это Вы маятесь дурью НЕ задавая размера стека в безосновательной надежде, на то, что он не наедет на кучу. QUOTE Хотя я надеялся увидеть хитрую трёхэтажную запись мнемониками перепроцесора самого GCC. Надежды на чудесные, но нереальные решения и прочие авось, не к лицу инженерам. Размеры стеков придется придется оценивать, указывать и контролировать.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
Apr 13 2016, 00:41
|
Частый гость
 
Группа: Участник
Сообщений: 182
Регистрация: 16-10-15
Пользователь №: 88 894

|
Цитата(zltigo @ Apr 13 2016, 04:52)  Это Вы маятесь дурью НЕ задавая размера стека в безосновательной надежде, на то, что он не наедет на кучу. Желаю вам научится читать чужие сообщения.
|
|
|
|
|
Apr 13 2016, 05:30
|

Гуру
     
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244

|
QUOTE (AVI-crak @ Apr 13 2016, 03:41)  Желаю вам научится читать чужие сообщения. Именно по тому, что не только читал, но и ПОНЯЛ, и написал, что Ваш "метод" не решает ничего. И в примере своем не просто так ARM7 привел с его множеством стеков (то же самое и старшие кортексы) при котрых Ваша идея, что размер стека сам собой устаканитися и думать о его размере не надо, вообще не пригодна в принципе. Собственно все у Вас работает только по причине что У Вас пока явный избыток памяти всегда.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|