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

UDK: Запрос/обсуждение нового функционала

pvvx

Активный участник сообщества
еще раз повторю медленно
хорошо бы по умолчанию отключить
1) автоматическую сборку всех проектов (приходится отключать вручную)
так как при загрузке примеров автоматически устанавливается флаг bluild Avto (см меню Project)
Не устанавливается. Это что-то у вас. Наверное XP или ещё что натворили в Eclipse (наставили несовместимых или лишних плагинов). Может попробуете запустить Eclipse x64 на win3.11 ? :)
https://www.eclipse.org/downloads/ --> Eclipse IDE for C/C++ Developers
 
Последнее редактирование:

CHERTS

Moderator
Команда форума
1) автоматическую сборку всех проектов (приходится отключать вручную)
Что это за опция и что вы подразумеваете под "автоматическую сборку всех проектов", если это опции Eclipse то DevKit тут не при делах, я никак не влияю на работу Eclipse.
 

nikolz

Well-known member
Что это за опция и что вы подразумеваете под "автоматическую сборку всех проектов", если это опции Eclipse то DevKit тут не при делах, я никак не влияю на работу Eclipse.
В меню Eclipse есть подменю Project в нем строка Build Automatically.
когда устанавливаешь примеры или весь пакет, то появляется галка в этой строке и Eclipse при запуске начинает собирать все примеры которые есть в workspace. Если ее убрать руками то сборку не делает.
Кроме того, еслипс автоматом запускает C/C+ indexer хорошо бы, если возможно не делать это для все примеров.
Я не силен в еклипсе, поэтому не знаю, Вы это установили или это так задумано изначально.
Просто хотелось бы это изменить.
 

nikolz

Well-known member
предлагаю изменить все маке файлы.
Данное изменение позволяет сильно упростить и систематизировать вносимые изменения в майки и создание новых проектов.
Изменения следующие:
Майк файл разрезается на несколько по их назначению
Я разрезал его на следующие:
------------------
1) Главный makefile - он распологается в каталоге проекта(примера) и в общем случает имеет такой вид:
ROOT =../..
MODULES += $(ROOT)/dev/driver
include $(ROOT)/Makefile.common
-------------------------
2) в каталог dev/drive я вынес все драйверы перефирии ESP
Т е если изменяется какой-то драйвер, то его надо изменить лишь один раз, а не во всех примерах.
Далее файл Makefile.common - общий для примеров на СИ (для nodemcu я сделал немного другой майк)
------------------------------
3) Остальные части майк файла можно понять из содержимого Makefile.common
BUILD_BASE = build
FW_BASE = $(BUILD_BASE)
# base directory of the ESP8266 SDK package, absolute
SDK_BASE ?= $(ROOT)/ESP8266_SDK
# esptool path and port
SDK_TOOLS ?= $(ROOT)/utils
ESPTOOL ?= $(SDK_TOOLS)/esptool.exe
include $(ROOT)/Makefile.port
include $(ROOT)/Makefile.boot

# include dev включение устройств
DEVS := $(ROOT)/dev/driver $(ROOT)/dev/utils
include $(ROOT)/Makefile.spi
include $(ROOT)/Makefile.comp

V ?= $(VERBOSE)
ifeq ("$(V)","1")
Q :=
vecho := @true
else
Q := @
vecho := @echo
endif

vpath %.c $(SRC_DIR)

define compile-objects
$1/%.o: %.c
$(vecho) "CC $$<"
$(Q) $(CC) $(INCDIR) $(MODULE_INCDIR) $(EXTRA_INCDIR) $(SDK_INCDIR) $(CFLAGS) -c $$< -o $$@
endef

.PHONY: all checkdirs clean flash flashinit flashonefile rebuild

all: checkdirs $(TARGET_OUT)

$(TARGET_OUT): $(APP_AR)
$(vecho) "LD $@"
$(Q) $(LD) -L$(SDK_LIBDIR) $(LD_SCRIPT) $(LDFLAGS) -Wl,--start-group $(LIBS) $(APP_AR) -Wl,--end-group -o $@
$(vecho) "------------------------------------------------------------------------------"
$(vecho) "Section info:"
$(Q) $(OBJDUMP) -h -j .data -j .rodata -j .bss -j .text -j .irom0.text $@
$(Q) $(OBJDUMP) -t -j .data $@ > map.txt
$(Q) $(OBJDUMP) -t -j .rodata $@ >> map.txt
$(Q) $(OBJDUMP) -t -j .bss $@ >> map.txt
$(Q) $(OBJDUMP) -t -j .text $@ >> map.txt
$(Q) $(OBJDUMP) -t -j .irom0.text $@ >> map.txt
$(vecho) "------------------------------------------------------------------------------"
$(Q) $(SDK_TOOLS)/memanalyzer.exe $(OBJDUMP).exe $@
$(vecho) "Run objcopy, please wait..."
$(Q) $(OBJCOPY) --only-section .text -O binary $@ eagle.app.v6.text.bin
$(Q) $(OBJCOPY) --only-section .data -O binary $@ eagle.app.v6.data.bin
$(Q) $(OBJCOPY) --only-section .rodata -O binary $@ eagle.app.v6.rodata.bin
$(Q) $(OBJCOPY) --only-section .irom0.text -O binary $@ eagle.app.v6.irom0text.bin
$(vecho) "objcopy done"
$(vecho) "Run gen_appbin.exe"
ifeq ($(app), 0)
$(Q) $(SDK_TOOLS)/gen_appbin.exe $@ 0 $(mode) $(freqdiv) $(size)
$(Q) mv eagle.app.flash.bin $(FW_BASE)/eagle.flash.bin
$(Q) mv eagle.app.v6.irom0text.bin $(FW_BASE)/eagle.irom0text.bin
$(Q) rm eagle.app.v6.*
$(vecho) "No boot needed."
$(vecho) "Generate eagle.flash.bin and eagle.irom0text.bin successully in folder $(FW_BASE)."
$(vecho) "eagle.flash.bin-------->0x00000"
$(vecho) "eagle.irom0text.bin---->$(addr)"
else
ifeq ($(boot), new)
$(Q) $(SDK_TOOLS)/gen_appbin.exe $@ 2 $(mode) $(freqdiv) $(size)
$(vecho) "Support boot_v1.3 and +"
else
$(Q) $(SDK_TOOLS)/gen_appbin.exe $@ 1 $(mode) $(freqdiv) $(size)
$(vecho) "Support boot_v1.1 and +"
endif
$(Q) mv eagle.app.flash.bin $(FW_BASE)/upgrade/$(BIN_NAME).bin
$(Q) rm eagle.app.v6.*
$(vecho) "Generate $(BIN_NAME).bin successully in folder $(FW_BASE)/upgrade."
$(vecho) "boot_v1.x.bin------->0x00000"
$(vecho) "$(BIN_NAME).bin--->$(addr)"
endif
$(vecho) "Done"

$(APP_AR): $(OBJ)
$(vecho) "AR $@"
$(Q) $(AR) cru $@ $^

checkdirs: $(BUILD_DIR) $(FW_BASE)

$(BUILD_DIR):
$(Q) mkdir -p $@

$(FW_BASE):
$(Q) mkdir -p $@
$(Q) mkdir -p $@/upgrade

include $(ROOT)/Makefile.flash
$(foreach bdir,$(BUILD_DIR),$(eval $(call compile-objects,$(bdir))))

Можно и дальше по такому принципу разрезать этот файл.
Что это дает:
Внесение изменения в процесс компиляции прошивки настройки портов и т д
делается лишь один раз для всех примеров.
Упрощается создание новых проектов.
нет дублирования общих драйверов
----------------------------
Я также убрал дублирование общих модулей из примеров и поместил их в каталог dev/utils.
 

Victor

Administrator
Команда форума
MicroPython для ESP8266 вышли на Kickstarter и собрали уже 18k фунтов.
Причем при достижении goal в 12k обещали зарелизить прошивку к концу сбора средств, а это значит что мы уже через пару недель получим новую прошивку (кстати, коммиты уже идут и WiFi уже заработал)
Было бы неплохо иметь возможность собирать micropython прошивку для ESP8266 в DevKit
 

CHERTS

Moderator
Команда форума
Было бы неплохо иметь возможность собирать micropython прошивку для ESP8266 в DevKit
У них вроде кросс-платформенная сборка, можно собирать и под windows, правда если верить описанию то для сборки прошивки они используют GitHub - pfalcon/esp-open-sdk: Free and open (as much as possible) integrated SDK for ESP8266 chips, но для сборки esp-open-sdk собственно и через devkit требуется лишь указать нужные пути в path и можно запускать make хоть откуда, например так:

Код:
@set PATH=c:\Espressif\xtensa-lx106-elf\bin;C:\MinGW\bin;C:\MinGW\msys\1.0\bin;%PATH%
а дальше make из любого каталога
 

CHERTS

Moderator
Команда форума
значит не будет проблемой включить MicroPython в примеры UDK?
Зачем? MicroPython - это отдельный достаточно большой проект, у которого свои разработчики. Примеры в UDK - это набор маленьких проектов, которые писал я или искал и адаптировал с github, ключевое слово ПРИМЕРЫ кода, а не набор огромных самодостаточных проектов. Проект nodemcu в UDK единственный большой и самодостаточный проект, я поместил его в UDK только как пример сборки крупного проекта, не более.
 

vad7

Active member
Какой там Python, в UDK бы отладку прикрутить... Тяжко без нее.
 

pvvx

Активный участник сообщества
@SHERTZ не планируется ли UDK на RTL8710 ?
arm-none-eabi-gcc куча, OpenOCD работает, но нет общей сборки. Китайцы пока жмут RTL8710 Windows & Linux GCC SDK
Оф. sdk-ameba1-v3.4b3_without_NDA пока доступна только для IAR, но уже есть http://esp8266.ru/forum/threads/realtek-ameba-gcc-build.1593/
'Сообщество' что-то пилит:
GitHub - eggman/rtl_ameba_gcc_sample
GitHub - eggman/ameba-gcc-sample-rtos
rebane — Bitbucket
Но UDK пока нет.
Я уже всё, что нашел, кроме Амёбы, перенес на win(mingw) + Eclipse...
 

sharikov

Active member
А зачем?
Фтопку всяческие OpenOCD и пр...
Чем IAR не угодил?
IAR не угодил законностью использования. Открытые проекты обязаны быть абсолютно белыми и 100% пушистыми как для российского так и для международного законодательства.
 

pvvx

Активный участник сообщества
А он реально убийца ESP? У меня просто нет ни модуля с RTL, ни j-tag какого нить, кините плиз ссылки на проверенных продавцов модуля, закажу, погляжу на него.
Реально на лопатки ESP8266. Соперник ESP32. Но если Espressif не поменяет политику, то убъет и ESP32. При выходе RTL87xx с 2.5 Мегабайта RAM - ESP вообще не конкурент.
JTAG на ali для RTL87xx стоит до 130 руб. Сами модули - ~200.
 
Последнее редактирование:

CHERTS

Moderator
Команда форума
Реально на лопатки ESP8266. Соперник ESP32. Но если Espressif не поменяет политику, то убъет и ESP32. При выходе RTL87xx с 2.5 Мегабайта RAM - ESP вообще не конкурент.
Заказал RTL8710 (RTL-00) и J-tag ST-LINK V2, посмотрим, пощупаем через 2-3 недели.
 

nikolz

Well-known member
Реально на лопатки ESP8266. Соперник ESP32. Но если Espressif не поменяет политику, то убъет и ESP32. При выходе RTL87xx с 2.5 Мегабайта RAM - ESP вообще не конкурент.
JTAG на ali для RTL87xx стоит до 130 руб. Сами модули - ~200.
Тогда объясните, почему все еще живы 8 битные контроллеры?
По Вашей логике все что ниже 32 бит должны давно умереть, а они живут.
Пример 8051.
Поэтому и у ESP есть своя ниша.
 

pvvx

Активный участник сообщества
Тогда объясните, почему все еще живы 8 битные контроллеры?
По Вашей логике все что ниже 32 бит должны давно умереть, а они живут.
Пример 8051.
Поэтому и у ESP есть своя ниша.
Да. Некоторые используют ещё 155ЛА3 и паяют ламповые схемы... Каждому - своё. А разговор идет о сравнении по TTX.
 

CHERTS

Moderator
Команда форума
1) Ваше решение с типом мейкфайлов считаю неудачным.
Тип mk - это тип MSVC. И зачем нам это?
Надо делать эти файлы с типом txt.
TXT файлы тоже можно открывать в VS Code к примеру, есть у меня такие знакомые и что теперь, давайте будем городить другие расширения чтобы они не пересекались с миллионом уже придуманных? По моему - это бред. Расширение MK - это сокращение от make и пришло оно из мира unix как и утилита make и городить txt для сценария make - простите, но это бред, вы еще bin или exe скажите.

2) считаб неудачным создание лишнего каталог ESP8266 в каталоге examples.
В последнем нет других каталогов, зачем это масло масленное.
А вы поставьте UDK for ESP32 и будут, именно для совместимости с UDK for ESP32 этого и произошло.

1) Предлагаю выделить каталог xtensa-lx106-elf вне Espressif и устанавливать отдельно как это делаем для Eclipse или mingw.
Этот пакет не имеет отношения к ESP. Он самостоятельный. Зачем его каждый раз сносить и ставить.
Если он обновляется, то ставим новый, если обновляется UDK то ставим Espressif.
Учитывая, что xtensa-lx106-elf составляет 80% объема Espressif , последний сразу полегчает.
Здрасте приехали, а что же такое в каталоге xtensa-lx106-elf? Это как раз то, что собирает прошивку - то есть компилятор и он имеет прямое отношение к ESP8266 и удалять его из UDK значит изменить сам смысл cлова Development Kit (Комплект разработчика), какой же это комплект если все будет отдельно? Я делал UDK именно для того, чтобы все инструменты необходимые для сборки пошивки были в одном месте и не нужно было что то искать в интернете, компилировать и т.д.

2) добавить в маке сборку программ из каталога driver в библиотеку перед их сборкой в прошивку.
Это позволить автоматом убирать мусор (не используемые функции), который может быть в driver из конечной
сборки.
Не понял, что куда добавить, расскажите поподробней.

В Makefile если использовать common_nonos.mk, то есть опция
MODULES = driver user
она как раз говорит в каких каталогах будут исходники для сборки, можете сделать каталог src и include/src и указать MODULES = src и прошивка будет собрана.
 
Сверху Снизу