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

[Demon]

Спасибо, чет пока не получается , перевожу, передергиваю, наверное не во время хотя что то там происходит, потому что АТ прошивка слетела, но ничего не появилось, буду разбираться, заказал адаптер многоногий,
можно же прошивку полученную в АЛЛ залить XTCOMом каким нибудь?

 

[pvvx]

Добавлю эту опцию в пример hello_world_optimized, что про эту опцию думает многоуважаемый pvvx ?

Ничего не меняет. Разница в размере кода и занимаемых сегментов памятей не отличается, что свидетельствует о том что никаких изменений нет.
"Исправить" работу транслятора в UDK можно таким ухищрением:
В eagle.rom.addr.v6.ld:

PROVIDE ( dport_    = 0x3ff00000);
PROVIDE ( io2_regs_    = 0x3ff20000);
PROVIDE ( uart0_    = 0x60000000);
PROVIDE ( spi1_        = 0x60000100);
PROVIDE ( spi0_        = 0x60000200);
PROVIDE ( gpio_        = 0x60000300);
PROVIDE ( timer_    = 0x60000600);
PROVIDE ( rtc_        = 0x60000700);
PROVIDE ( iomux_    = 0x60000800);
PROVIDE ( wdt_        = 0x60000900);
PROVIDE ( uart1_    = 0x60000F00);
PROVIDE ( rtc_ram_    = 0x60001000);
PROVIDE ( rtc_mem_    = 0x60001100);
PROVIDE ( io4_regs_    = 0x60009800);

extern volatile uint32 dport_[64];        // 0x3ff00000
extern volatile uint32 io2_regs_[1536]; // 0x3ff20000
extern volatile uint32 uart0_[64];        // 0x60000000
extern volatile uint32 spi1_[64];        // 0x60000100
extern volatile uint32 spi0_[64];        // 0x60000200
extern volatile uint32 gpio_[64];        // 0x60000300
extern volatile uint32 timer_[64];        // 0x60000600
extern volatile uint32 rtc_[64];        // 0x60000700
extern volatile uint32 iomux_[64];        // 0x60000800
extern volatile uint32 wdt_[64];        // 0x60000900
extern volatile uint32 sar_[64];        // 0x60000D00
extern volatile uint32 uart1_[64];        // 0x60000F00
extern volatile uint32 rtc_ram_[64];    // 0x60001000
extern volatile uint32 rtc_mem_[192];    // 0x60001100
extern volatile uint32 io4_regs_[384];    // 0x60009800

И преписыванием всех [HASHTAG]#define[/HASHTAG] и процедур работы с I/O. Я это уже проделал с в своем "SDK".
Это значительно улучшает работу транслятора, но только с I/O регистрами. При таком подходе мы имеем всего только описанные константы адресов баз областей регистров и они объединяются в прошивке. А доступ к регистрам I/O вынуждает транслятор производить со смешением от этих базовых адресов и выходит, что ему не требуется загрузка каждый раз в одной процедуре перед обращением к регистру I/O его непосредственного адреса для работы с ним по нулевому смещению и заполнению кода программ этими константами и загрузками регистров, а он берет уже загруженный регистр (из прошлого обращения, где грузился базовый адрес блока) и транслирует команду обращения по нему со смещением. По другому ему никак, т.к. адрес знает только линковщик, а вычислять смещения UDK транслятор умеет плохо, только если указан однородный массив - ему такие опции задал сборщик UDK - использовать при обращении только нулевое смещение и каждый раз грузить указатели на адрес обращения Но тут ничего не поделать - сборщик UDK говорит, что он не будет исправлять ничего пока ему в рот не положат что и как у него лично в его компе исправить при трансляции компилятора и не доплатят. Выходит, что UDK платный и проще использовать от xtensa.
Разница Итого в драйверах по скорости и размеру кода выходит огромная.

 

[sherr]

Ну и там шьется же не 1, а 2 части при обычной прошивке. Не знаю точно, но есть вероятность, что и Reset нужно дергать дважды. Хотя тут могу врать...

Не нужно, шьёт обе части сразу, потом надо GPIO0 вернуть в <1> и опять ресет .

 

[nikolz]

Добрый день,
я правильно понял следующие результаты:
------------------------------
собираю пример help_word_cpp, получаю:
Total Used RAM : 39104 Free RAM : 42816 Free IRam : 6392
----------------------------
теперь собираем help_word_cpp_irom
-- это пример с оптимизацией - верно? получаю:
Total Used RAM : 39104 Free RAM : 42816 Free IRam : 6592
----------------------------------
Вопрос:
В результате оптимизации освободилось 200 байт. Правильно я понял?
Не могу понять сколь значимы такие ресурсы.
Буду признателен, если кто-нибудь придумает пример,
когда этих 200 байт не хватает либо на что их теперь хватит.
Спасибо

 

[CHERTS]

Добрый день,
я правильно понял следующие результаты:
------------------------------
собираю пример help_word_cpp, получаю:
Total Used RAM : 39104 Free RAM : 42816 Free IRam : 6392
----------------------------
теперь собираем help_word_cpp_irom
-- это пример с оптимизацией - верно? получаю:
Total Used RAM : 39104 Free RAM : 42816 Free IRam : 6592
----------------------------------
Вопрос:
В результате оптимизации освободилось 200 байт. Правильно я понял?
Не могу понять сколь значимы такие ресурсы.
Буду признателен, если кто-нибудь придумает пример,
когда этих 200 байт не хватает либо на что их теперь хватит.
Спасибо

help_word_cpp и help_word_cpp_irom это по сути не оптимизация, просто в help_word_cpp_irom все по-умолчанию ложиться в IROM, в отличии от help_word_cpp, тем самым мы освобождаем IRAM для другого кода.
Для help_word_cpp 200 байт кажется мелочью, но для более существенных проектов выгода может быть гораздо больше.

 

[CHERTS]

Но тут ничего не поделать - сборщик UDK говорит, что он не будет исправлять ничего пока ему в рот не положат что и как у него лично в его компе исправить при трансляции компилятора и не доплатят. Выходит, что UDK платный и проще использовать от xtensa.

pvvx Вы меня конечно простите, но Вы задолбали нести ахинею, что я только собираю бабло... Завидуйте молча, я Вам уже это говорил неоднократно.

Скажите конкретно, что исправить и я исправлю, скажите с какими опциями пересобрать GCC и я пересоберу, проблем в этом нет. Если Вы хотите часть пирога от пожертвования - нет проблем, пишите в личку, обсудим, договоримся, но вначале внесите изменения и опубликуйте их в официальном репозитарии.
Не хотите, не публикуйте, Выше право, но не нужно нести ахинею про платность UDK.

 

[pvvx]

pvvx Вы меня конечно простите, но Вы задолбали нести ахинею, что я только собираю бабло... Завидуйте молча, я Вам уже это говорил неоднократно.

Чему завидовать то? Кривому транслятору и 100 рупь пожертвований?

Скажите конкретно, что исправить и я исправлю, скажите с какими опциями пересобрать GCC и я пересоберу, проблем в этом нет..

Сборкой UDK я не занимаюсь. Что он делает не совсем правильно - указано до битика. Обходные решения тоже. Далее - шаг того, кто собирает UDK.

Если Вы хотите часть пирога от пожертвования - нет проблем, пишите в личку, обсудим, договоримся, но вначале внесите изменения и опубликуйте их в официальном репозитарии.
Не хотите, не публикуйте, Выше право, но не нужно нести ахинею про платность UDK.

Про платность вы сами писали - типа никто не платит... с напрашивающимся выводом (по контексту где про это писалось), что пока не оплатят ничего нового не будет

 

[pvvx]

Если возможно, поясните каким образом я могу реализовать эту оптимизацию в произвольном проекте.
Что для этого надо делать.
Спасибо

Если libc.a и libgcc.a заменены правильно (к примеру из моей свалки на libmc.a и libmgcc.a) то получаем так:
Free RAM : 39296
Free IRam : 10593
При стандартных либах libc.a и libgcc.a:
Free RAM : 39196
Free IRam : 5274
Т.е. разница в 10593 - 5274 + 39296 - 39196 = 5419 байт - это + 14% от доступной приложению памяти. При этом libc.a и libgcc.a используют другие библиотеки из SDK, а не ваш код. И в данном случае используется только минимальный комплект "очищенных" либ из SDK. При использовании стандартных либ от SDK разница будет ещё больше.
Если заменить libc.a и т.д. на библиотеку microc, то освобождается ещё больше и скорость исполнения кода увеличивается. Но с microc anakod ещё работает...
Libc.a - это для CИ, при С++ другая либа...
А что там в примере help_word_cpp в UDK - это соображения его создателя. При С++ оптимизация делается ещё больше, но уже для кода самого приложения. Часть есть и развивается в проекте ардуино-Sming
Некоторые проекты в UDK уже не влезают в IRAM без специальной libmgcc.a - пример
Перемещать коды либ libc.a, libgcc.a, ... в Flash нельзя - они используются (к примеру процедуру деления и т.д.) при запрете прерываний и "кеширования" flash в кодах помещаемых в IRAM из библиотек SDK Espressif. В связи с этим, такие предложения ведут к сложно уловимым глюкам...

Оптимизация самого транслятора, которую не хочет делать сборщик UDK дает ещё 10..20% уменьшения объему по коду и от 30% по скорости для драйверов... Он будет ссылаться на что угодно, но делать этого не станет Он жаждет, чтобы кто-то сделал альтернативную сборку нового UDK и все отказались от данного UDK
На что я сопротивляюсь и уже не знаю как ему ещё это донести, но он ссылается на какую-то “зависть”...