Не берет pointer + offset в обращениях к адресному пространству... в случае если в процедуре указан абсолютный адрес... Вот так не делает: s32i a6, a4, 0x304, а вместо этого на каждое обращение грузит указатель: l32r a3, 40100190 - итог размер и тормоз и миллионы reallocation. + как итог этого получаем коду на каждое обращение 7 байт вместо 3-х и невозможность объединения загружаемых констант (этих указателей).
А мне надо короткие загрузчики, а не килобайтные. И я ошибся - вместо 3-х байт получаем 3+3+4.
Это сделать проще сразу и навсегда
Xtensa Compiler это хорошо делает, но у него другое и надо приспособиться...НЕЕЕТ!!!
На что вы замените udk ?
Может все же проблема в таких плагинах?
Мне кажется SDK вообще не должен быть завязан на компилятор. Makefile к нему еще теоретически может, а SDK не должен.
Плагины официальные, как и всё в Eclipse.
Тут походу только в данной версии такое. А вариантов у GNU GCC масса.
Я тоже обеими руками за Makefile'ы, в UDK есть масса примеров проектов с разными Makefile.
А я против - мне в проекте на каждый си файл в 1 кило писать собственный 10 кило makefile? На драйвер одни опции, на .. другие... В обычной среде Eclipse с нормальной обвязкой тыкаем мышкой на файл и говорим что хотим изменить, хоть выключить в данной конфигурации из трансляции. А так- же конфигураций может быть десяток для проекта....Я тоже обеими руками за Makefile'ы, в UDK есть масса примеров проектов с разными Makefile.
Есть простые примеры для Си (hello_world), для C++ (hello_world_cpp), есть сложные с иерархией каталогов (nodemcu-firmware), есть примеры библиотеки (lwip_lib), есть даже пример программы под windows (nodemcu-spiffy).
Но как показала практика, не все понимают как это все работает.
Вот сейчас пишу под винду где надо опции расставлять мышкой. В проекте используется N сторонних библиотек в исходниках и M конфигураций.
Ну да - проще было закинуть:
PROVIDE ( __adddf3 = 0x4000c538 );
PROVIDE ( __addsf3 = 0x4000c180 );
PROVIDE ( __divdf3 = 0x4000cb94 );
PROVIDE ( __divdi3 = 0x4000ce60 );
PROVIDE ( __divsi3 = 0x4000dc88 );
PROVIDE ( __extendsfdf2 = 0x4000cdfc );
PROVIDE ( __fixdfsi = 0x4000ccb8 );
PROVIDE ( __fixunsdfsi = 0x4000cd00 );
PROVIDE ( __fixunssfsi = 0x4000c4c4 );
PROVIDE ( __floatsidf = 0x4000e2f0 );
PROVIDE ( __floatsisf = 0x4000e2ac );
PROVIDE ( __floatunsidf = 0x4000e2e8 );
PROVIDE ( __floatunsisf = 0x4000e2a4 );
PROVIDE ( __muldf3 = 0x4000c8f0 );
PROVIDE ( __muldi3 = 0x40000650 );
PROVIDE ( __mulsf3 = 0x4000c3dc );
PROVIDE ( __subdf3 = 0x4000c688 );
PROVIDE ( __subsf3 = 0x4000c268 );
PROVIDE ( __truncdfsf2 = 0x4000cd5c );
PROVIDE ( __udivdi3 = 0x4000d310 );
PROVIDE ( __udivsi3 = 0x4000e21c );
PROVIDE ( __umoddi3 = 0x4000d770 );
PROVIDE ( __umodsi3 = 0x4000e268 );
PROVIDE ( __umulsidi3 = 0x4000dcf0 ); Section| Description| Start (hex)| End (hex)|Used space
------------------------------------------------------------------------------
data| Initialized Data (RAM)| 3FFE8000| 3FFE8AC0| 2752
rodata| ReadOnly Data (RAM)| 3FFE8AC0| 3FFE9A60| 4000
bss| Uninitialized Data (RAM)| 3FFE9A60| 3FFF2650| 35824
text| Cached Code (IRAM)| 40100000| 40105A81| 23169
irom0_text| Uncached Code (SPI)| 40240000| 4026FFC0| 196544
Total Used RAM : 42576
Free RAM : 39344
Free IRam : 9617С отключением memw нужно быть аккуратным. Возможны сюрпризы.
Fifo не может ничего внести - в него как вошло так и вышло. Последовательность не нарушается. Синхронизация шин - это другая команда.
jcmvbkbc что скажете, стоит ли пересобрать gcc с этими опциями и включить в UDK? На что это может повлиять?
На скорость выполнения. И это внешняя опция и она работает в вашей сборке. Уже протестировано все обращения к периферии без memw - пока полет нормальный.
Можно libgcc и libc запихать в IROM, сам я не проверял, но видел такой код в Makefile:
TOOLS_ROOT ?= c:/Espressif
...
LIBS = cirom gccirom hal phy pp net80211 wpa main
...
OBJCOPY := $(XTENSA_TOOLS_ROOT)/xtensa-lx106-elf-objcopy
...
V ?= $(VERBOSE)
ifeq ("$(V)","1")
Q :=
vecho := @true
else
Q := @
vecho := @echo
endif
....
.PHONY: all checkdirs iromlibs .....
...
# create libgccirom.a from libgcc.a
# create libcirom.a from libc.a
iromlibs:
@echo "Creating irom version of libgcc and libc..."
$(Q) $(OBJCOPY) --rename-section .text=.irom0.text --rename-section .literal=.irom0.literal $(TOOLS_ROOT)/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/4.8.2/libgcc.a $(TOOLS_ROOT)/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/4.8.2/libgccirom.a
$(Q) $(OBJCOPY) --rename-section .text=.irom0.text --rename-section .literal=.irom0.literal $(TOOLS_ROOT)/xtensa-lx106-elf/xtensa-lx106-elf/lib/libc.a $(TOOLS_ROOT)/xtensa-lx106-elf/xtensa-lx106-elf/lib/libcirom.aЭто тоже кошмар. Как будут работать прерывания, обращающиеся к flash в критических местах?
del libmgcc.a
md libgcc
cd libgcc
C:\Espressif\xtensa-lx106-elf\bin\xtensa-lx106-elf-ar x ..\libgcc.a
@rem delete:
@rem _fixunsdfsi.o _umoddi3.o _umodsi3.o _extendsfdf2.o _fixdfsi.o _divsi3.o _divdf3.o _divdi3.o _fixunssfsi.o
@rem _floatsidf.o _floatsisf.o _floatunsidf.o _floatunsisf.o _muldf3.o _muldi3.o _mulsf3.o _truncdfsf2.o
@rem _udivdi3.o _udivsi3.o _umulsidi3.o _addsubdf3.o _addsubsf3.o
C:\Espressif\xtensa-lx106-elf\bin\xtensa-lx106-elf-ar ru ..\libmgcc.a @..\libmgcc_list_files.txt
cd ..
rd /q /s libgcc__gcc_bcmp.o __main.o _absvdi2.o _absvsi2.o _addvdi3.o _addvsi3.o _ashldi3.o _ashrdi3.o _bswapdi2.o _bswapsi2.o _clear_cache.o _clrsbdi2.o _clrsbsi2.o _clz.o _clzdi2.o _clzsi2.o _cmpdf2.o _cmpdi2.o _cmpsf2.o _ctors.o _ctzdi2.o _ctzsi2.o _divdc3.o _divsc3.o _divsf3.o _divtc3.o _divxc3.o _eprintf.o _ffsdi2.o _ffssi2.o _fixdfdi.o _fixsfdi.o _fixsfsi.o _fixtfdi.o _fixunsdfdi.o _fixunssfdi.o _fixunstfdi.o _fixunsxfdi.o _fixunsxfsi.o _fixxfdi.o _floatdidf.o _floatdisf.o _floatditf.o _floatdixf.o _floatundidf.o _floatundisf.o _floatunditf.o _floatundixf.o _lshrdi3.o _moddi3.o _modsi3.o _muldc3.o _mulsc3.o _mulsi3.o _multc3.o _mulvdi3.o _mulvsi3.o _mulxc3.o _negdf2.o _negdi2.o _negsf2.o _negvdi2.o _negvsi2.o _paritydi2.o _paritysi2.o _popcount_tab.o _popcountdi2.o _popcountsi2.o _powidf2.o _powisf2.o _powitf2.o _powixf2.o _subvdi3.o _subvsi3.o _trampoline.o _ucmpdi2.o _udiv_w_sdiv.o _udivmoddi4.o emutls.o enable-execute-stack.o lib2funcs.o unwind-c.o unwind-dw2.o unwind-dw2-fde.o unwind-sjlj.oНа скорость в положительную сторону или отрицательную? Добавлю эти опции в отдельный пример для DevKit с пометкой "Оптимизация скорости и размера доступного IRAM"