• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

UDK: Общие разговоры

pvvx

Активный участник сообщества
А что именно не транслируется?
Не берет pointer + offset в обращениях к адресному пространству... в случае если в процедуре указан абсолютный адрес... Вот так не делает: s32i a6, a4, 0x304, а вместо этого на каждое обращение грузит указатель: l32r a3, 40100190 - итог размер и тормоз и миллионы reallocation. + как итог этого получаем коду на каждое обращение 7 байт вместо 3-х и невозможность объединения загружаемых констант (этих указателей).
 
Последнее редактирование:

anakod

Moderator
Команда форума
  1. Можно попробовать организовать код по другому, возможно до компилятора "дойдет" (что разумеется не факт)
  2. Можно пока забить, т.к. оптимизировать производительность всегда успеем, пока бы хотя бы заработало.

    Т.е. если мы будем иметь на руках работающий Си код, его всегда можно прогнать через другой компилятор\подождать пока обновят этот\обновить самим\перевести в критических узких местах на АСМ и т.д.
 

pvvx

Активный участник сообщества
если мы будем иметь на руках работающий Си код,
А мне надо короткие загрузчики, а не килобайтные. И я ошибся - вместо 3-х байт получаем 3+3+4.
его всегда можно прогнать через другой компилятор...
Это сделать проще сразу и навсегда :) Xtensa Compiler это хорошо делает, но у него другое и надо приспособиться...
 
Последнее редактирование:

sharikov

Active member
Обрасти плагинами к Eclipse. А то народу сложно создавать новые проекты - надо что ковырять в данном, патчить какие-то файлы.
НЕЕЕТ!!!
Не надо говноплагинов!
с makefile все просто - как написал, так оно и работает. А с плагинами гарантированы чудеса и подземный стук вместе взятые, проходили знаем.
Кому сложно создавать проекты пусть используют lua.

Похоже придется отказываться в OpenSDK от данного UDK...
Попозже ещё покопаю опции транслятору и линковщику, но пока не выходит, вроде всё уже испробовал...
На что вы замените udk ?
Использовать крякнутый компилер не вариант потому что это поставит жирный крест на проекте OpenSDK.
 

anakod

Moderator
Команда форума
Не надо говноплагинов!
с makefile все просто - как написал, так оно и работает. А с плагинами гарантированы чудеса и подземный стук вместе взятые, проходили знаем.
Может все же проблема в таких плагинах?

Использовать крякнутый компилер не вариант потому что это поставит жирный крест на проекте OpenSDK.
Мне кажется SDK вообще не должен быть завязан на компилятор. Makefile к нему еще теоретически может, а SDK не должен.
 

pvvx

Активный участник сообщества
НЕЕЕТ!!!
Не надо говноплагинов!
Плагины официальные, как и всё в Eclipse.
Использовать крякнутый компилер не вариант потому что это поставит жирный крест на проекте OpenSDK.
Тут походу только в данной версии такое. А вариантов у GNU GCC масса.
Я указал только самые явные, которые могут не дать создавать оверлеи. Скоро проверю - будут либы оверлеев xtensa работать в данном UDK...
Такая бяка не может быть у всех версий сборок GCC. Просто кто-то поставил запрет на использование смещений и он работает только по нулевому смещению, каждый раз загружая указатель и плодя их в памяти с невозможностью объединения.
 
Последнее редактирование:

CHERTS

Moderator
Команда форума
с makefile все просто - как написал, так оно и работает. А с плагинами гарантированы чудеса и подземный стук вместе взятые, проходили знаем.
Кому сложно создавать проекты пусть используют lua.
Я тоже обеими руками за Makefile'ы, в UDK есть масса примеров проектов с разными Makefile.
Есть простые примеры для Си (hello_world), для C++ (hello_world_cpp), есть сложные с иерархией каталогов (nodemcu-firmware), есть примеры библиотеки (lwip_lib), есть даже пример программы под windows (nodemcu-spiffy).

Но как показала практика, не все понимают как это все работает. :(
 

pvvx

Активный участник сообщества
Я тоже обеими руками за Makefile'ы, в UDK есть масса примеров проектов с разными Makefile.
Есть простые примеры для Си (hello_world), для C++ (hello_world_cpp), есть сложные с иерархией каталогов (nodemcu-firmware), есть примеры библиотеки (lwip_lib), есть даже пример программы под windows (nodemcu-spiffy).

Но как показала практика, не все понимают как это все работает. :(
А я против - мне в проекте на каждый си файл в 1 кило писать собственный 10 кило makefile? На драйвер одни опции, на .. другие... В обычной среде Eclipse с нормальной обвязкой тыкаем мышкой на файл и говорим что хотим изменить, хоть выключить в данной конфигурации из трансляции. А так- же конфигураций может быть десяток для проекта....
Всё это прекрасно работает в Xplorer, а тут, в UDK, Eclipse почему-то идет с плагином авто-конфига для трансляции GNU-linux подобных сред, а всё что связано с МСU и задание его потрохов пообрезано в xtensa-lx106-elf каталоге. Зачем там обрывки?
 
Последнее редактирование:

sharikov

Active member
А я против - мне в проекте на каждый си файл в 1 кило писать собственный 10 кило makefile? На драйвер одни опции, на .. другие... В обычной среде Eclipse с нормальной обвязкой тыкаем мышкой на файл и говорим что хотим изменить, хоть выключить в данной конфигурации из трансляции. А так- же конфигураций может быть десяток для проекта....
Вот сейчас пишу под винду где надо опции расставлять мышкой. В проекте используется N сторонних библиотек в исходниках и M конфигураций.
Задолбался жмакать мышкой по галочкам опций для всех проектов во всех конфигурациях.
Для маргинального Esp8266 не стоит ждать"нормальной" обвязки потому что ее некому писать и некому тестировать.
 

pvvx

Активный участник сообщества
Вот сейчас пишу под винду где надо опции расставлять мышкой. В проекте используется N сторонних библиотек в исходниках и M конфигураций.
Задолбался жмакать мышкой по галочкам опций для всех проектов во всех конфигурациях.
Для маргинального Esp8266 не стоит ждать"нормальной" обвязки потому что ее некому писать и некому тестировать.
Ну да - проще было закинуть:
/* Default linker script, for normal executables */
SEARCH_DIR("/d/Neo/Project/ESP8266/DevKit/build/compiler/xtensa-lx106-elf/xtensa-lx106-elf/lib");
В UDK и не думать :)
Т.е. вы говорите, что можете работать только с Lua? Закачал, нахал кнопочку "трансляйте" и всё? :)
Так в MCU не бывает. Там каждый байт специфичен.
---------
Пример:
Вот всё что надо ткнуть мышкой, чтобы скомпилить проект для ESP8266 в Xplorer-6:
Xplorer6cfg.gif
 
Последнее редактирование:

pvvx

Активный участник сообщества
Как в данном UDK сказать линковщику, что всё это:
Код:
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 );
уже есть в ROM-BIOS и незачем занимать ещё дублями в 5 килобайт в и так малой памяти IRAM + сотни байт в RAM только из либы libgcc.a:
.text 0x40106508 0x33a c:/espressif/xtensa-lx106-elf/bin/../lib/gcc/xtensa-lx106-elf/4.8.2\libgcc.a(_umoddi3.o)
0x366 (size before relaxing)
0x40106508 __umoddi3
...

?
 
Последнее редактирование:

pvvx

Активный участник сообщества
Уже решил вопрос. Избавился от лишних кодов - много высвободилось в памяти ESP8266. Пересобрал либы...
Libgcc.a в основном используется из других либ SDK Espressif.
Текущие стандартные либы (4.8.2\libgcc....) в UDK, как всегда, собраны с ужасными опциями.... :)
Модификация только части libgcc.a и Web-свалка с SDK 1.0.1 (b2):
Код:
   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
Free IRam : 9617 - т.е. уже есть 8 кило для оверлеев.
Скоро ещё выужу...
Libc.a
Free IRam : 10241 :)
Found free IRAM size:10220 bytes
System memory:
data : 0x3ffe8000 ~ 0x3ffe8ac0, len: 2752
rodata: 0x3ffe8ac0 ~ 0x3ffe9a60, len: 4000
bss : 0x3ffe9a60 ~ 0x3fff2650, len: 35824
heap : 0x3fff2650 ~ 0x3fffc000, len: 39344
Current 'heap' size: 39072 bytes
 
Последнее редактирование:

pvvx

Активный участник сообщества
Отключение никчемных memw в GCC:
-mserialize-volatile
-mno-serialize-volatile
When this option is enabled, GCC inserts MEMW instructions before volatile memory references to guarantee sequential consistency. The default is -mserialize-volatile. Use -mno-serialize-volatile to omit the MEMW instructions.
 

sharikov

Active member
Отключение никчемных memw в GCC:
-mserialize-volatile
-mno-serialize-volatile
When this option is enabled, GCC inserts MEMW instructions before volatile memory references to guarantee sequential consistency. The default is -mserialize-volatile. Use -mno-serialize-volatile to omit the MEMW instructions.
С отключением memw нужно быть аккуратным. Возможны сюрпризы.
Навеяно этой темой (я отпишусь в ветке про spi)
http://www.esp8266.com/viewtopic.php?f=13&t=2427&start=10#p15607

Судя по документации на Bus Bridges в них есть fifo, поэтому когда мы пишем данные они не сразу достигают места назначения. В случае переменных это не важно а при инициализации аппаратуры fifo может вносить путаницу.
 

pvvx

Активный участник сообщества
С отключением memw нужно быть аккуратным. Возможны сюрпризы.
Навеяно этой темой (я отпишусь в ветке про spi)
http://www.esp8266.com/viewtopic.php?f=13&t=2427&start=10#p15607

Судя по документации на Bus Bridges в них есть fifo, поэтому когда мы пишем данные они не сразу достигают места назначения. В случае переменных это не важно а при инициализации аппаратуры fifo может вносить путаницу.
Fifo не может ничего внести - в него как вошло так и вышло. Последовательность не нарушается. Синхронизация шин - это другая команда.
Без memw всё работает. Тестил уже. Счас ещё перепишу чтение flash в PvSDK (SpiFlashOpResult spi_flash_read(uint32 faddr, void *des, uint32 size).
 

CHERTS

Moderator
Команда форума
Отключение никчемных memw в GCC:
-mserialize-volatile
-mno-serialize-volatile
When this option is enabled, GCC inserts MEMW instructions before volatile memory references to guarantee sequential consistency. The default is -mserialize-volatile. Use -mno-serialize-volatile to omit the MEMW instructions.
jcmvbkbc что скажете, стоит ли пересобрать gcc с этими опциями и включить в UDK? На что это может повлиять?
 

pvvx

Активный участник сообщества
На что это может повлиять?
На скорость выполнения. И это внешняя опция и она работает в вашей сборке. Уже протестировано все обращения к периферии без memw - пока полет нормальный.
А пересобирать надо с исправлением обращений по регистрам со смещением и объединением констант в text секции... Иначе это бардак.
 

CHERTS

Moderator
Команда форума
же решил вопрос. Избавился от лишних кодов - много высвободилось в памяти ESP8266. Пересобрал либы...
Libgcc.a в основном используется из других либ SDK Espressif.
Текущие стандартные либы (4.8.2\libgcc....) в UDK, как всегда, собраны с ужасными опциями....
Можно 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
 

pvvx

Активный участник сообщества
Можно libgcc и libc запихать в IROM, сам я не проверял, но видел такой код в Makefile:
Это тоже кошмар. Как будут работать прерывания, обращающиеся к flash в критических местах?
Просто уберите из либ коды и процедуры которые уже есть в ROM-BIOS. Заголовки (т.е. названия) к ним даны в eagle.rom.addr.v6.ld. Освободит десяток кило в памяти. Проверено уже.
Варварски исправленные либы лежат в моей свалке. Но это не правильно, хотя и работает. У другого компилятора другие либы - с ними я и возился, а эти просто обгрыз путем удаления объектников из сборки либы...
А для тех кому нy очень нужны дубли в памяти устройства - положите в отдельную либу. Пусть переносят в flash :)
Пример "обгрызания" того что есть в UDK:
new_libmgcc.bat:
Код:
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
libmgcc_list_files.txt:
Код:
__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
 
Последнее редактирование:

CHERTS

Moderator
Команда форума
На скорость выполнения. И это внешняя опция и она работает в вашей сборке. Уже протестировано все обращения к периферии без memw - пока полет нормальный.
На скорость в положительную сторону или отрицательную? Добавлю эти опции в отдельный пример для DevKit с пометкой "Оптимизация скорости и размера доступного IRAM"
 
Сверху Снизу