Привет, ЛОРчане!
А вам не кажется, что со средствами разработки в последнее время творится что-то странное или даже страшное?
В общем делюсь своей историей «успеха».
Не так давно создатели SDCC добавили новый стандарт вызова процедур, ломающий обратную совместимость со старым ассемблерным кодом. Причем добавили они его в версии SDCC 4.2.0, то есть сломали совместимость в минорщине…
И вот 29 декабря прошлого года я решил, что на текущих выходных не буду заниматься проприетарщиной на фрилансе, а внесу соответствующие изменения в порт BuguRTOS на stm8/sdcc. Сами ассемблерные вставки я поправил ещё 29-го перед корпоративом, а вчера решился внести изменения в код ОС, поднять всё, что нужно для разработки и тестирования имбедов на своём ноуте с debian bullseye (inb4 некрофилия), и протестировать BuguRTOS на реальном железе, ибо грядёт релиз.
В общем, включил ноут, запустил git-gui, чтобы склонировать репу с Гитхаба и…
Тут меня ждали первые грабли
Название ветки master по дефолту депрекейтед и вообще не политкорректно, меняй дефолтное название ветки, ибо белые цисгендерные гетеросексуальные шовинистические членомрази должны страдать!
Ладно, сделал git clone из консоли, начал ставить инструметы для разработки и тестить.
Под AVR все тесты удачно собрались штатными avr-gcc и avr-binutils, запустились на штатном simavr с отладкой через штатный avr-gdb, загрузились штатным avrdude и удачно отработали на старенькой Arduino(tm) nano.
Отладка работает быстро.
На Cortex-Mх меня ждали следующие грабли
Пакет stlink в debian oldstable оказался стабильно глючный: точки останова не ставятся, дисасм не работает и т.д.
Пол дня пытался подобрать команды gdb в попытках заставить отладку работать. В итоге скачал с GitHub васянскую сборку от создателей пакета, поставил, отладка заработала сразу же со старыми проверенными командами gdb!
Третьи грабли встретились мне на rp2040
Использую VSCodium вместо VSCode, дабы избежать «телеметрии». Установка cortex-debug и ms-vscode.cmake-tools прошла успешно, а вот комада:
codium --install-extension ms-vscode.cpptools
выдала
Installing extensions...
Extension 'ms-vscode.cpptools' not found.
Make sure you use the full extension ID, including the publisher, e.g.: ms-dotnettools.csharp
Failed Installing Extensions: ms-vscode.cpptools
и такая проблема не только у меня.
Ладно, на сборку и отладку это не повлияло, но осадочек остался.
Да, кстати
Отдадка на rp2040 через старую версию picoprobe под vscodium работает гораздо быстрее, чем на любом stm32 через stlink под Code::Blocks.
Четвёртые грабли ждали меня… правильно на stm8 и sdcc
В debian bullseye стоит SDCC-4.0.0 и нет пакета stm8flah.
В общем, stm8flash собрал из исходников, протестил ОС на старой версии компилятора.
Дальше скачал SDCC-4.3.0 и Code::Blocks под Офтопик, и перешёл в виртуалку с офтопиком 10, поставил тулчейн, IDE, st-toolset для прошивки, стал собирать и «заливать» тестовые проекты на Discovery…
И один из проектов не собирается ни в какую, т.е. на SDCC-4.0.0 в debian собирался, а тут sdccld посчитал, что мои статики не статики и ругается на множественные определения функций!
Все остальные тестовые проекты, отличающиеся только файлом main.с, собрались и успешно отработали, т.е. ассемблерные вставки были написаны без ошибок в слепую перед корпоративом.
Итого
Вместо того, чтобы поставить средства разработки и протестировать BuguRTOS за ПОЛ дня я протахался ДВА!!!
Из-за множественных ошибок в средствах разработки!
Кто из вас сталкивался с чем-то подобным?
Напишите в комментариях, что вы на этот счёт думаете, и поделитесь своими историями «успеха».
