Как стать автором
Обновить

Сборка и отладка прошивки IoT-модуля: Python, make, апельсины и чёрная магия

Уровень сложностиПростой
Время на прочтение22 мин
Количество просмотров2.6K
Всего голосов 15: ↑14 и ↓1+13
Комментарии19

Комментарии 19

Надо в серию запускать и продавать пока пиндосы не присвоили

ЗЫ: а чисто теоретически можно сделать так чтоб все самокаты разом взяли и поехали куда глаза глядят?

Куда глаза глядят всё-таки не получится. Органы управления самоката так устроены, что сам он не решает куда ему ехать - решает пользователь. Самокат может лишь сопротивляться (снижать скорость), ну или вообще не ехать (если случилась поломка).
Хотя я как-то встречал похожее решение у коллег, но сомневаюсь, что оно пойдёт дальше концепта, по крайней мере в рамках кикшеринга.

Сколько .с файлов в проекте?
Что-то странный разброс времени компиляции под разными ОС


Чуть больше трёх сотен...

На такое количество файлов ушло бы 9 сек в IAR.

Ну вот у нас на линуксе и на маке получается примерно в пределах 10 секунд на полную сборку одной прошивки. Бегло почитал про IAR, боюсь при такой стоимости лицензии, проще действительно пересесть всем отделом на линукс или мак)
Впрочем, может я не знаю каких-то деталей.
Я так понимаю, у вас был какой-то опыт с IAR? Можете поделиться вкратце?

Как я использую J-Link в IAR писал здесь - https://habr.com/ru/articles/574088/

Ваш проект довольно маленький, видимо там нет RTOS. Но если бы была, то в IAR очень удобные add-on-ы для отладки разных RTOS. Позволяют наблюдать состояние любых объектов RTOS.
У вас микроконтролеры поддерживающие трассировку. Трассировка на порядок сокращает время поиска багов и исследование работы периферии. Но она хороша только в J-Link в IAR под Windows. А тут вы взяли и при таком роскошном бизнесе сэкономили буквально на спичках.

У нас FreeRTOS.

Ознакомлюсь с вашей статьей, спасибо.

Компилятор и компоновщик Iar (а) по хорошему тоже надо вызывать из Makefile ов.

Zephyr и ESP-IDF живут так, что питон над CMake над Make (или что-то другое). Почти всё необходимое для разработки, отладки и сборки есть, вызывается простыми командами. Легко тромбуется в контейнер. Там есть что подчерпнуть.

Единственное, что приходится делать самому - сервер OTA прошивок.

Zephyr Project по умолчанию использует не Make a ninjia.

Devops это хорошо.

Вот только как программисту микроконтроллеров объяснить начальнику - схемотехнику, что нужно все это фреймворкостроительство?

Думаю, достаточно будет показать ему парочку заклинаний) Только нужно быть аккуратнее, вдруг ему понравится и он бросит схемотехнику и уйдёт в DevOps)

А вообще, развести плату - это ведь лишь пол дела. Важно же ещё как она будет поддерживаться и эксплуатироваться. И, конечно, это зависит от спектра обязанностей конкретного начальника, но минимальное погружение в детали всё-таки должно присутствовать. И если для тех сотрудников, кто занимается написанием прошивки, наличие CICD экономит уйму времени, то почему бы его не внедрить?)

А кто сказал, что у программиста МК начальник-схемотехник?

Всё начальство программистов микроконтроллеров в российских организациях в пяти случаях из шести - это в прошлом схемотехники, чертежники или вовсе конструкторы механики.

О программировании они знать ничего не хотят из принципа, они из тех кто просто ненавидит программировать еще с института.

Начальник-схемотехник даже программирование называет "программизмом", прошивание называет "прожиганием", а самих программистов-микроконтроллеров "софтописцами".

Убедить их развернуть DevOps просто нереально. Не поймут об чём речь.

У Вас в телематических платах есть интерфейс командной строки поверх UART?

С cli(шкой) можно найти причину любого бага, если это не глухой зависон.

Да, у нас есть свой cli, правда он сделан через usb cdc. Очень удобная штука и мы её активно развиваем. Вполне вероятно, как-нибудь напишем об этом отдельно.

Вообще usb это слишком сложный интерфейс для того, чтобы гонять поток shell.

Если зависнет что- то из многочисленных зависимостей usb, то cli отрубится.

Отладочную cli надо запускать именно на uart, так как в uart нечему ломаться и cli будет всегда живая.

Для того чтобы сделать индикатор прогресса сборки вовсе не обязательно прикручивать Python.

Это можно сделать встроенными функциями GNU Make: eval, words, shell

# build the application
# list of objects
OBJECTS = $(addprefix $(BUILD_DIR)/,$(notdir $(SOURCES_C:.c=.o)))
vpath %.c $(sort $(dir $(SOURCES_C)))
# list of ASM program objects
OBJECTS += $(addprefix $(BUILD_DIR)/,$(notdir $(SOURCES_ASM:.S=.o)))
vpath %.S $(sort $(dir $(SOURCES_ASM)))
NO_OF_FILES := $(words $(OBJECTS))
$(info NO_OF_FILES:$(NO_OF_FILES) )

$(BUILD_DIR)/%.o: %.c Makefile | $(BUILD_DIR) 
	$(eval FILE_PROGRESS=$(shell echo $$(($(FILE_PROGRESS)+1))))
	@echo Making $(FILE_PROGRESS)/$(NO_OF_FILES) $@
	@$(CC) -c $(CFLAGS) -Wa,-a,-ad,-alms=$(BUILD_DIR)/$(notdir $(<:.c=.lst)) $< -o $@

Вот так это выглядит в консоли

Зарегистрируйтесь на Хабре, чтобы оставить комментарий