Обычная скорость объектов из пояса астероидов до 20 км/с при столкновении, из облака Оорта под 50, здесь же при ускорении Солнцем может быть и все 100. Так что 5 км согласно легко превращаются в 25. Так что достаточно небольшой межзвёздный метеорит может вызвать последствия, завершившие эволюцию не птичьих динозавров.
Совершенно верно. В этой концепции в принципе нет разделения на тип хранилища объектов. Это может быть облако сервер:порт, сайт https, запрос к БД, к диску C: или по UART к контроллеру. Система управления версий изначально была заточена под управление именно файлами а не непосредственно программными элементами. В этом и есть главная беда. Потенциально в новых подходах указывается источник данных и необходимые атрибуты, такие как версия, хеш, дата, некое имя/ID (например, обозначающее ветку), и указывается для конкретно того что нужно - пространства имён, функции или класса. Нет смысла тянуть файл который на усмотрение разработчиков может содержать пиктограммку в Base64 просто потому что так захотелось. Также на уровне линковки в elf/so/dll уже давным давно должны появиться атрибуты версий объектов, идентификаторы, контрольные суммы. Поэтому посреди бинарников всегда можно выбрать только то что необходимо а не дублировать всё по папкам или релизить вместе с программой, также это позволяет инкапсулировать то что является условно read-only как системная библиотека, что-то в локалях у пользователя что-то вместе с программой. Указывая эти идентификаторы практически полностью можно исключить ошибки линковки при встрече двух файлов, т к. линкёр уже будет знать что именно из них вытягивать, в противном случае надо играться с path который будет показывать откуда что брать, это вечная проблема когда необходимо держать локальный зоопарк из нескольких версий. Более того, если в объектнике, формат которого не менялся с середины 80-х будут уже более современные атрибуты, связанные с управлением версиями а не просто 64 бит этикетка, их можно объединять и укрупнять а имя файла или либы уже значения иметь не будет, содержимое может быть индексировано уже на уровне ОС, плюс взаимосвязь с объектами включения, чтобы заголовочники были также синхронизированы с dll/so (это отдельная боль), в этом случае добавляется инструкция с идентификатором, позволяющая точно согласовать версию заголовочника и двоичника.
Так все новые фичи для компилятора могут быть инициированы как внутри исходника, например, какой-либо прагмой зависящей от версии а также явным указанием. Например gcc поддерживает опции -std=c23 или что-то вроде -std=iso9899:2023. При компиляции можно указать какой именно стандарт и расширение использовать. Вообщем в любом случае все эти свистки командной строки должны уйти внутрь кода и самого языка и убрать файл как структурную единицу проекта, это ведь просто именованная запись а не сам код так сказать. Иными словами проблему путей, линковок, зависимостей, символических ссылок, всяких copy/rm/ls и прочих песен с файлопапками искоренить на уровне идентификаторов и пространств имён в самом языке. Компилятор будет понимать файлы и подкаталоги как единое целое, но внутри вполне всё может быть разбито на проекты, например, ключевым словом project, нечто вроде архива, производить индексацию библиотек, синхронизацию итд. Вообщем это уже комбайн для сборки, но один, без распыления на отдельные утилиты со своими капризами и запросами. То есть меняется мировоззрение по самому представлению проекта уже вне файловой системы на языке предметной области. Конечно все привыкли к тому чему учили, но это не может уже продолжаться полвека.
Механизм Enter-Exit создаёт блокировку "прерываний" внутри процесса, это выглядит как некий аналог GIL или Enable/Disable interrupt в контроллере или Enter/LeaveCriticalSection, поэтому, должна быть гарантия что внутри этого процесса код будет выполнен за фиксированное время и не возникнет таймаутов. Чистое многопроцессорное (не просто многопоточное) исполнение позволяет делать некий эквивалент вложенных прерываний. Поэтому конечно хотелось бы чтобы общение с процессом шло через FIFO или SharedMemory (с управлением оной), это позволит избежать дублирования внешних стеков данных, которые должны как-то ещё обрабатывать критические секции (привет всевозможным флажкам состояний) особенно если там динамическая аллокация памяти без специальных Interprocess-средств и управление кучей.
Интересно, в принципе в зависимостях более чем достаточно для GUI всяческих libGL*, но зачем там столько дополнительных libX11 (GLX), а как же Wayland, который EGL? Хотя вроде как Mesa тоже имеется.
Вот, потихоньку всё начинает приходить к общему знаменателю, который ещё вывел Ван Россум для Python-а в далёком 91м году на основе ОС Амёба. Там в конце довольно интересная публикация от 88 года на предмет Parallel make. Так вот тогда ещё предполагалось что среда разработки и язык могут стать единым целым и помогать друг другу. Это к вопросу к табуляциям которые фактически и являются атрибутами вложенности и области видимости. Также можно было бы точно такие же фичи сделать для комментариев и иных вещей. Вообщем спустя 40 лет похоже будет очередной виток.
Feb1991: X\Python\ does not (yet!) provide an intelligent input line editing
Xfacility, so you have to type a tab or space(s) for each indented line.
XIn practice you will prepare more complicated input for \Python\ with a
Это уже другой вопрос что сложность понимания кода дополняется сложностью понимания вспомогательных инструментов - помимо языка надо знать bash/bat/git/флажки компилятора, различные прагмы-макросы, непосредственно make-языки. Иными словами количество вбираемой информации не изменится если её часть переместится внутрь языка и станет его атрибутом, то есть можно использовать можно нет. Ну это как С++ вместо ООП и прочего синтаксического сахара можно вполне использовать как С с классами или просто как процедурный. Бывало даже видел программы состоящие прямиком из asm-вставок, компилятор нужен был только для аргументов функции и возврата. Поэтому код, который удобно отлаживать, делать опции при сборке для тех или иных компонент кода, а не файлов, будет гораздо лучше чем если это дело отдельно отдать управлять внешним инструментом который просто сложился исторически а не был создан изначально, плюс набегают ошибки, когда действие делается не одним инструментом а двумя и более, много синхронизируемых сущностей, там один флажок, здесь другой, там имя файла не совпадает там ещё что-то, часовой пояс поменяли до уровня up to date, переменную среды не прописали, path не туда. То есть за кодом тянется дополнительная вереница исключительно системных дел. Если это уйдёт в код то он станет самособираемым и практически исчезнет необходимость во внешнем инструменте. Там на самом деле не так много необходимо будет выучить. Думаю ключевых слов version, debug, link, map, control, request, exclude, update, hash, options, optimize, code_id, testfunc и что то в этом роде будет не так много, которые практически полностью позволят настроить как и что собирать если что-то не нравится по умолчанию. Движение на этот счёт имеется в виде танцев с бубном но как-то слабо из за гигантского легаси и разросшихся вспомогательных инструментов, что пора бы уже комитету C++26 уже сделать более дружелюбным к системам сборки и версионирования наравне с другими языками.
Именно так. Что изменение коммента не есть изменение кода что не нужно перекомпилировать весь мир или обходить это с использованием иных абстракций. То есть в самом коде начинают присутствовать элементы версий, git, контрольные суммы, даты/дескрипторы создания, модификаций функций и классов, включая всевозможные фичи для отладки вроде лишних assertion, опций оптимизации конкретного фрагмента кода начиная от -O0 и заканчивая -O3, когда необходимо отладить только вот какой-то конкретный кусочек функции без её вытаскивания в отдельный файл, прагмы станут уже нормальными опциями для статического динамического размещения, map/ld-файл уже как-то ближе к коду а не отдельная сущность, включая настройки, нормальные унифицированные интрисики как стандартное расширение языка и многие другие фишки. Вообщем система сборки должна уже давным давно проникнуть внутрь компилятора и стать его частью а не костылём снаружи, включая управление precompiled headers, опций изменений, макрорасширений/шаблонов, внешние ссылки на линковку по идентификаторам а не по файловой мешанине, избежать дублирование зависимостей итд итп.
Для эмбеддера если нет пина для подключения осциллографа, особенно петельки для земли из печатной платы, то это уже не отладочный комплект. Если по бокам был бы угловой PLD со всей периферией, расфасованной по функциям а не по номеру GPIO, то отлично, если с другого бока JTAG - вдвойне.
Что касается сборки на С, когда надоело каждый раз переписывать в h-файлах прототипы функций, смотреть на ворнинги и эрроры, сделал perl-скрипт, который сканирует все C, достаёт оттуда прототипы структур/функций (написанных в едином стиле дабы не усложнять парсер до уровня bison/flex) и кладёт в единый заголовочник. Перед сборкой выполняется этот скрипт который вытаскивает из исходников необходимое. Для идентификатора функции использовал пустой макрос DEFUN. Именно в этом русле языки программирования до сих пор не обзавелись встроенными средствами для системы построения. Ничего кроме #pragma и /*-*тут мои настройки-*-*/, всяких __меня_не_трогать__ не подвезли. Хотя вполне могли были быть ключевые слова вроде link, make, debug, version, compile_unit с указанием что эту функцию оптимизировать, эту для отладки, у той одна версия, у этой другая, вот там имя функции юнит теста (а не файла) итд
Как-то так
my ($statick, $curlopenbr) = (0,0,0,0,0,0,0);
my $strtag = "";my $strname = "";my $curlword = ""; my $curlclword = "";
my @statarr = ();
my $str;
my $stracc;
foreach my $stra (@raws)
{
$str = $stra;
#search for DEFUN keyword
#skip definition
if ($str =~ /DEFUN.+\;/g)
{
$statick = 0;
$stracc = "";
next;
}
if ($str =~ s/(DEFUN.+)\{// and $statick eq 0)
{
$str = $1;
push @statarr,$str;
$statick = 0;
$stracc = "";
}
if ($str =~ s/(DEFUN.+)// and $statick eq 0)
{
$statick = 1;
$stracc = $1." ";
next;
}
if ($str =~ s/(.*)\{// and $statick eq 1)
{
$stracc = $stracc." ".$1;
push @statarr,$stracc;
$statick = 0;
$stracc = "";
}
#accumulate brackets and DEFUN content
if ($statick eq 1)
{
$stracc = $stracc.$str." ";
}
}
Тут возникает довольно серьёзная проблема, когда скомпилированный пакет не имеет каких-либо идентификаторов от системы сборки. И нет никаких средств проверить целостность, атрибуты и единство пакета, который был собран самостоятельно и внедрён в систему или локальное окружение помимо репозитория. В основном упор идёт на дату и номер версии, а также то что если изменить 1 байт - это уже новый пакет. Поэтому в системе разрастается зоопарк версий, особенно весело когда программа тянет за собой двоичники необходимых зависимостей, что для .NET что для MSVC redistributable, .deb/.rpm могут притянуть различные только им нужные .so, Python 2.7/3 - уже стало именем нарицательным, если песочница использует символические ссылки - уже достижение. В подавляющем большинстве случаев весь этот довесок летит в Program Files или bin. Вообщем по-всей видимости без инфраструктурных изменений вряд ли что-то можно улучшить существенным образом.
Проблема в CubeIDE и прочих визуалках без обратной связи из исходного кода "наверх" - невозможность динамической реконфигурации. Иными словами, допустим, в какой-то момент необходимо переключить ШИМ в шестишаговый режим, пробросить UART сделав Remap пинов, по ходу дела менять режимы DMA например. То есть система программируется изначально как нечто статическое. Конечно для большинства простых задач этого хватает но на специализированных применениях это может создать больше проблем. Плюс HAL/LL вместо регистров это отдельная тема, попытка языковыми средствами из 70-х с надеждой на упорство компилятора создать абстракцию, вроде как ООП на С, и да и нет, в итоге проще сделать какой-нибудь кодогенератор и единственный заголовочник.
Имеется в виду то что до сих пор в качестве аргументов используются различного рода вещи, которые тянутся из того что нужно собрать в систему сборки, не важно какого высокого она уровня. Иными словами включить/выключить CUDA/AVX/SSE, сделать море #define-ов, сгенерировать какой-либо .pm итд. То есть до сих пор нет каких-то встроенных в сам язык средств, поддерживающих сборку, иными словами требуется пересмотр самого принципа текст-компилятор-редактор связей-отладчик с наличием утилиты в этом механизме, отвечающей за сборку, включая данные о распределении памяти, опции подключаемых библиотек, версий, причём, инвариантно к именам/расширениям файлов, собирая непосредственно объекты и функции но это уже не задача make. До сих пор системы сборки и контроля версий по-сути обёртка на принципы работы и тулкиты, которые были ещё с середины 80-х. В даже в настоящее время проект - это просто папки и набор файлов в них с описанием того что нужно с этим сделать, вместо указания того, что нужно сделать непосредственно с их содержимым.
CMake медленно но верно как было замечено превращается в уже почти в графическое IDE. Наверняка уже завезли вещи связанные с Git, проверкой версий пакетов онлайн, среды окружения, тестирование самого компилятора на правильность. Но опять-таки краеугольный камень - что он не заходит внутрь файла забрать пользовательские идентификаторы, ориентируется на время/дату и прочие системные штуки при обновлении, не создаёт атрибутов файлов или дампов этапов построения с обработкой исключений при ошибках компиляции с целью не прервать процесс а максимально скомпилировать всё что без ошибок. Ну и разумеется танцы с макросами и зависимыми переменными. Вообщем скорее всего этот инструмент поглотит некий perl/python с явной кодогенерацией по шаблону из мета-языка, пригодного для конкретного применения, включая тот же bash/bat для сборки (локальной/тест/релиз). CMake же пытается объять необъятное и уже требует ненулевой порог входа для обучения.
Turbo C также мог по Ctrl+F9 собрать и запустить, подсветив код не хуже чем сейчас. Это был где-то 1998й год, всё влезало на дискету 1.44. Тогда были обычные make, и сейчас тоже самое, главное чтобы батарейка у биоса не села и не сбросила незаметно время. В качестве пакета - lib с заголовочниками, директория с датой - версия, bat-файл для всего остального. Практически за 30 лет лишь косметические изменения. Если бы тогда спросили у будущего: до сих пор используете файловые системы для структурирования проекта? Представлен очевидный ответ. Интересно, есть ли у этого процесса хоть какая-то интегрированная прямая поддержка со стороны IDE.
Кроме этого добавить ещё гамма- и радио-всплески (видимые в электромагнитном спектре), слияния чёрных дыр (видимые в спектре гравитационных волн), частицы сверхвысоких энергий в тераэлектронвольт из точечного источника (в спектре корпускулярного взаимодействия), детектирование всплесков нейтрино (спектр косвенного взаимодействия с веществом) скорее тут даже можно расширить на саму природу возникновения вспышки. Вот бы ещё выявить изменение или вспышку на фоне реликтового излучения, это самое интригующее было бы, некое событие эпохи рекомбинации.
Навскидку, поправьте ели не так, есть разница между nova и supernovae. Нова - это в принципе яркое астрономическое явление, а далее его классифицируют как переменную "катаклизмическую" звезду (бывает и такое что звезда блекнет, как Бетельгейзе, помнится зимой 2020 стала заметно тусклее) или сверхновую, для белого карлика Ia при превышении предела Чандрасекара аккрецией вещества.
Также, не задавайте в моделях параметры из разряда фемтофарад , наногенри, тераомы и др, что частенько приводит к singular matrix error, или к зависаниям на коммутациях. И шаг счёта для лучшей сходимости и устойчивости решения по порядку величины равной минимальной постоянной времени схемы, как раз определяемой этими параметрами вроде итд, иными словами, обусловленность системы. Деление практически на 0 делает большую величину, из-за нелинейной разрядной сетки даже для double сумма с большим числом есть само число. Адаптивный шаг счёта, определяемый этими постоянными времени и LC-контурами приводит к уточнению reltol на уровне сотен МГц для схемы в 50 Гц при каждой коммутации.
Раньше были обычные справочники для основных параметров, которые определяют скажем так основное назначение. Особенно про транзисторы из разряда КТ315 или МП42Б. Давались только минимальная бета, ёмкости, обратный ток, температурное сопротивление кристалл-корпус/корпус-среда и другая мелочёвка. Из этого уже можно было построить малосигнальную или нелинейную модель для расчётов "вручную". Из предельных характеристик также, напряжение пробоя, максимальное напряжение база-эмиттер обратное косвенно вытягиваются остальные параметры. Вообщем фактически воссоздать характеристики по их кусочно-линейным аппроксимациям.
Лучше исключить Is сразу же, используя предел , так как действительно чувствительность к прямой ветке слишком высокая и использовать его как параметр.
Ещё бы дополнительно сравнить температурные зависимости ВАХ, особенно для расчётов тепловых потерь, увеличивающихся с ростом температуры. В даташитах обычно приводят для -40, 25 и 85/105/125). В принципе можно параметр неидеальности n вынести в числитель как и можно будет использовать линейный МНК.
Также можно использовать аналитическое решение для МНК с уравнением прямой, раз уж используется Maple/Maxima. Аппроксимацию сделал сразу для "ступеньки" функции ВАХ в общем виде, используя точку Vce0.
Как-то строил для транзистора получается примерно следующее
А для анализа характеристик обратного восстановления - включить в ЭДС небольшие катушки (процентов 5-10, обычно равные напряжению к.з. трансформатора/сети. ), чтобы они создавали угол коммутации .
Также, по заряду обратного восстановления можно ориентировочно вписать в параметр ёмкость диода. Помимо этого конечно есть ещё эффект варикапа но для силовых диодов это не актуально.
Обычная скорость объектов из пояса астероидов до 20 км/с при столкновении, из облака Оорта под 50, здесь же при ускорении Солнцем может быть и все 100. Так что 5 км согласно
легко превращаются в 25. Так что достаточно небольшой межзвёздный метеорит может вызвать последствия, завершившие эволюцию не птичьих динозавров.
Совершенно верно. В этой концепции в принципе нет разделения на тип хранилища объектов. Это может быть облако сервер:порт, сайт https, запрос к БД, к диску C: или по UART к контроллеру. Система управления версий изначально была заточена под управление именно файлами а не непосредственно программными элементами. В этом и есть главная беда. Потенциально в новых подходах указывается источник данных и необходимые атрибуты, такие как версия, хеш, дата, некое имя/ID (например, обозначающее ветку), и указывается для конкретно того что нужно - пространства имён, функции или класса. Нет смысла тянуть файл который на усмотрение разработчиков может содержать пиктограммку в Base64 просто потому что так захотелось. Также на уровне линковки в elf/so/dll уже давным давно должны появиться атрибуты версий объектов, идентификаторы, контрольные суммы. Поэтому посреди бинарников всегда можно выбрать только то что необходимо а не дублировать всё по папкам или релизить вместе с программой, также это позволяет инкапсулировать то что является условно read-only как системная библиотека, что-то в локалях у пользователя что-то вместе с программой. Указывая эти идентификаторы практически полностью можно исключить ошибки линковки при встрече двух файлов, т к. линкёр уже будет знать что именно из них вытягивать, в противном случае надо играться с path который будет показывать откуда что брать, это вечная проблема когда необходимо держать локальный зоопарк из нескольких версий. Более того, если в объектнике, формат которого не менялся с середины 80-х будут уже более современные атрибуты, связанные с управлением версиями а не просто 64 бит этикетка, их можно объединять и укрупнять а имя файла или либы уже значения иметь не будет, содержимое может быть индексировано уже на уровне ОС, плюс взаимосвязь с объектами включения, чтобы заголовочники были также синхронизированы с dll/so (это отдельная боль), в этом случае добавляется инструкция с идентификатором, позволяющая точно согласовать версию заголовочника и двоичника.
Так все новые фичи для компилятора могут быть инициированы как внутри исходника, например, какой-либо прагмой зависящей от версии а также явным указанием. Например gcc поддерживает опции -std=c23 или что-то вроде -std=iso9899:2023. При компиляции можно указать какой именно стандарт и расширение использовать. Вообщем в любом случае все эти свистки командной строки должны уйти внутрь кода и самого языка и убрать файл как структурную единицу проекта, это ведь просто именованная запись а не сам код так сказать. Иными словами проблему путей, линковок, зависимостей, символических ссылок, всяких copy/rm/ls и прочих песен с файлопапками искоренить на уровне идентификаторов и пространств имён в самом языке. Компилятор будет понимать файлы и подкаталоги как единое целое, но внутри вполне всё может быть разбито на проекты, например, ключевым словом project, нечто вроде архива, производить индексацию библиотек, синхронизацию итд. Вообщем это уже комбайн для сборки, но один, без распыления на отдельные утилиты со своими капризами и запросами. То есть меняется мировоззрение по самому представлению проекта уже вне файловой системы на языке предметной области. Конечно все привыкли к тому чему учили, но это не может уже продолжаться полвека.
Механизм Enter-Exit создаёт блокировку "прерываний" внутри процесса, это выглядит как некий аналог GIL или Enable/Disable interrupt в контроллере или Enter/LeaveCriticalSection, поэтому, должна быть гарантия что внутри этого процесса код будет выполнен за фиксированное время и не возникнет таймаутов. Чистое многопроцессорное (не просто многопоточное) исполнение позволяет делать некий эквивалент вложенных прерываний. Поэтому конечно хотелось бы чтобы общение с процессом шло через FIFO или SharedMemory (с управлением оной), это позволит избежать дублирования внешних стеков данных, которые должны как-то ещё обрабатывать критические секции (привет всевозможным флажкам состояний) особенно если там динамическая аллокация памяти без специальных Interprocess-средств и управление кучей.
Интересно, в принципе в зависимостях более чем достаточно для GUI всяческих libGL*, но зачем там столько дополнительных libX11 (GLX), а как же Wayland, который EGL? Хотя вроде как Mesa тоже имеется.
Вот, потихоньку всё начинает приходить к общему знаменателю, который ещё вывел Ван Россум для Python-а в далёком 91м году на основе ОС Амёба. Там в конце довольно интересная публикация от 88 года на предмет Parallel make. Так вот тогда ещё предполагалось что среда разработки и язык могут стать единым целым и помогать друг другу. Это к вопросу к табуляциям которые фактически и являются атрибутами вложенности и области видимости. Также можно было бы точно такие же фичи сделать для комментариев и иных вещей. Вообщем спустя 40 лет похоже будет очередной виток.
Feb1991: X\Python\ does not (yet!) provide an intelligent input line editing Xfacility, so you have to type a tab or space(s) for each indented line. XIn practice you will prepare more complicated input for \Python\ with a
Это уже другой вопрос что сложность понимания кода дополняется сложностью понимания вспомогательных инструментов - помимо языка надо знать bash/bat/git/флажки компилятора, различные прагмы-макросы, непосредственно make-языки. Иными словами количество вбираемой информации не изменится если её часть переместится внутрь языка и станет его атрибутом, то есть можно использовать можно нет. Ну это как С++ вместо ООП и прочего синтаксического сахара можно вполне использовать как С с классами или просто как процедурный. Бывало даже видел программы состоящие прямиком из asm-вставок, компилятор нужен был только для аргументов функции и возврата. Поэтому код, который удобно отлаживать, делать опции при сборке для тех или иных компонент кода, а не файлов, будет гораздо лучше чем если это дело отдельно отдать управлять внешним инструментом который просто сложился исторически а не был создан изначально, плюс набегают ошибки, когда действие делается не одним инструментом а двумя и более, много синхронизируемых сущностей, там один флажок, здесь другой, там имя файла не совпадает там ещё что-то, часовой пояс поменяли до уровня up to date, переменную среды не прописали, path не туда. То есть за кодом тянется дополнительная вереница исключительно системных дел. Если это уйдёт в код то он станет самособираемым и практически исчезнет необходимость во внешнем инструменте. Там на самом деле не так много необходимо будет выучить. Думаю ключевых слов version, debug, link, map, control, request, exclude, update, hash, options, optimize, code_id, testfunc и что то в этом роде будет не так много, которые практически полностью позволят настроить как и что собирать если что-то не нравится по умолчанию. Движение на этот счёт имеется в виде танцев с бубном но как-то слабо из за гигантского легаси и разросшихся вспомогательных инструментов, что пора бы уже комитету C++26 уже сделать более дружелюбным к системам сборки и версионирования наравне с другими языками.
Именно так. Что изменение коммента не есть изменение кода что не нужно перекомпилировать весь мир или обходить это с использованием иных абстракций. То есть в самом коде начинают присутствовать элементы версий, git, контрольные суммы, даты/дескрипторы создания, модификаций функций и классов, включая всевозможные фичи для отладки вроде лишних assertion, опций оптимизации конкретного фрагмента кода начиная от -O0 и заканчивая -O3, когда необходимо отладить только вот какой-то конкретный кусочек функции без её вытаскивания в отдельный файл, прагмы станут уже нормальными опциями для статического динамического размещения, map/ld-файл уже как-то ближе к коду а не отдельная сущность, включая настройки, нормальные унифицированные интрисики как стандартное расширение языка и многие другие фишки. Вообщем система сборки должна уже давным давно проникнуть внутрь компилятора и стать его частью а не костылём снаружи, включая управление precompiled headers, опций изменений, макрорасширений/шаблонов, внешние ссылки на линковку по идентификаторам а не по файловой мешанине, избежать дублирование зависимостей итд итп.
Для эмбеддера если нет пина для подключения осциллографа, особенно петельки для земли из печатной платы, то это уже не отладочный комплект. Если по бокам был бы угловой PLD со всей периферией, расфасованной по функциям а не по номеру GPIO, то отлично, если с другого бока JTAG - вдвойне.
Что касается сборки на С, когда надоело каждый раз переписывать в h-файлах прототипы функций, смотреть на ворнинги и эрроры, сделал perl-скрипт, который сканирует все C, достаёт оттуда прототипы структур/функций (написанных в едином стиле дабы не усложнять парсер до уровня bison/flex) и кладёт в единый заголовочник. Перед сборкой выполняется этот скрипт который вытаскивает из исходников необходимое. Для идентификатора функции использовал пустой макрос DEFUN. Именно в этом русле языки программирования до сих пор не обзавелись встроенными средствами для системы построения. Ничего кроме #pragma и /*-*тут мои настройки-*-*/, всяких __меня_не_трогать__ не подвезли. Хотя вполне могли были быть ключевые слова вроде link, make, debug, version, compile_unit с указанием что эту функцию оптимизировать, эту для отладки, у той одна версия, у этой другая, вот там имя функции юнит теста (а не файла) итд
Как-то так
Тут возникает довольно серьёзная проблема, когда скомпилированный пакет не имеет каких-либо идентификаторов от системы сборки. И нет никаких средств проверить целостность, атрибуты и единство пакета, который был собран самостоятельно и внедрён в систему или локальное окружение помимо репозитория. В основном упор идёт на дату и номер версии, а также то что если изменить 1 байт - это уже новый пакет. Поэтому в системе разрастается зоопарк версий, особенно весело когда программа тянет за собой двоичники необходимых зависимостей, что для .NET что для MSVC redistributable, .deb/.rpm могут притянуть различные только им нужные .so, Python 2.7/3 - уже стало именем нарицательным, если песочница использует символические ссылки - уже достижение. В подавляющем большинстве случаев весь этот довесок летит в Program Files или bin. Вообщем по-всей видимости без инфраструктурных изменений вряд ли что-то можно улучшить существенным образом.
Проблема в CubeIDE и прочих визуалках без обратной связи из исходного кода "наверх" - невозможность динамической реконфигурации. Иными словами, допустим, в какой-то момент необходимо переключить ШИМ в шестишаговый режим, пробросить UART сделав Remap пинов, по ходу дела менять режимы DMA например. То есть система программируется изначально как нечто статическое. Конечно для большинства простых задач этого хватает но на специализированных применениях это может создать больше проблем. Плюс HAL/LL вместо регистров это отдельная тема, попытка языковыми средствами из 70-х с надеждой на упорство компилятора создать абстракцию, вроде как ООП на С, и да и нет, в итоге проще сделать какой-нибудь кодогенератор и единственный заголовочник.
Имеется в виду то что до сих пор в качестве аргументов используются различного рода вещи, которые тянутся из того что нужно собрать в систему сборки, не важно какого высокого она уровня. Иными словами включить/выключить CUDA/AVX/SSE, сделать море #define-ов, сгенерировать какой-либо .pm итд. То есть до сих пор нет каких-то встроенных в сам язык средств, поддерживающих сборку, иными словами требуется пересмотр самого принципа текст-компилятор-редактор связей-отладчик с наличием утилиты в этом механизме, отвечающей за сборку, включая данные о распределении памяти, опции подключаемых библиотек, версий, причём, инвариантно к именам/расширениям файлов, собирая непосредственно объекты и функции но это уже не задача make. До сих пор системы сборки и контроля версий по-сути обёртка на принципы работы и тулкиты, которые были ещё с середины 80-х. В даже в настоящее время проект - это просто папки и набор файлов в них с описанием того что нужно с этим сделать, вместо указания того, что нужно сделать непосредственно с их содержимым.
CMake медленно но верно как было замечено превращается в уже почти в графическое IDE. Наверняка уже завезли вещи связанные с Git, проверкой версий пакетов онлайн, среды окружения, тестирование самого компилятора на правильность. Но опять-таки краеугольный камень - что он не заходит внутрь файла забрать пользовательские идентификаторы, ориентируется на время/дату и прочие системные штуки при обновлении, не создаёт атрибутов файлов или дампов этапов построения с обработкой исключений при ошибках компиляции с целью не прервать процесс а максимально скомпилировать всё что без ошибок. Ну и разумеется танцы с макросами и зависимыми переменными. Вообщем скорее всего этот инструмент поглотит некий perl/python с явной кодогенерацией по шаблону из мета-языка, пригодного для конкретного применения, включая тот же bash/bat для сборки (локальной/тест/релиз). CMake же пытается объять необъятное и уже требует ненулевой порог входа для обучения.
Turbo C также мог по Ctrl+F9 собрать и запустить, подсветив код не хуже чем сейчас. Это был где-то 1998й год, всё влезало на дискету 1.44. Тогда были обычные make, и сейчас тоже самое, главное чтобы батарейка у биоса не села и не сбросила незаметно время. В качестве пакета - lib с заголовочниками, директория с датой - версия, bat-файл для всего остального. Практически за 30 лет лишь косметические изменения. Если бы тогда спросили у будущего: до сих пор используете файловые системы для структурирования проекта? Представлен очевидный ответ. Интересно, есть ли у этого процесса хоть какая-то интегрированная прямая поддержка со стороны IDE.
Кроме этого добавить ещё гамма- и радио-всплески (видимые в электромагнитном спектре), слияния чёрных дыр (видимые в спектре гравитационных волн), частицы сверхвысоких энергий в тераэлектронвольт из точечного источника (в спектре корпускулярного взаимодействия), детектирование всплесков нейтрино (спектр косвенного взаимодействия с веществом) скорее тут даже можно расширить на саму природу возникновения вспышки. Вот бы ещё выявить изменение или вспышку на фоне реликтового излучения, это самое интригующее было бы, некое событие эпохи рекомбинации.
Навскидку, поправьте ели не так, есть разница между nova и supernovae. Нова - это в принципе яркое астрономическое явление, а далее его классифицируют как переменную "катаклизмическую" звезду (бывает и такое что звезда блекнет, как Бетельгейзе, помнится зимой 2020 стала заметно тусклее) или сверхновую, для белого карлика Ia при превышении предела Чандрасекара аккрецией вещества.
Также, не задавайте в моделях параметры из разряда фемтофарад
, наногенри, тераомы и др, что частенько приводит к singular matrix error, или к зависаниям на коммутациях. И шаг счёта для лучшей сходимости и устойчивости решения по порядку величины равной минимальной постоянной времени схемы, как раз определяемой этими параметрами вроде 
итд, иными словами, обусловленность системы. Деление практически на 0 делает большую величину, из-за нелинейной разрядной сетки даже для double сумма с большим числом есть само число. Адаптивный шаг счёта, определяемый этими постоянными времени и LC-контурами приводит к уточнению reltol на уровне сотен МГц для схемы в 50 Гц при каждой коммутации.
Раньше были обычные справочники для основных параметров, которые определяют скажем так основное назначение. Особенно про транзисторы из разряда КТ315 или МП42Б. Давались только минимальная бета, ёмкости, обратный ток, температурное сопротивление кристалл-корпус/корпус-среда и другая мелочёвка. Из этого уже можно было построить малосигнальную или нелинейную модель для расчётов "вручную". Из предельных характеристик также, напряжение пробоя, максимальное напряжение база-эмиттер обратное косвенно вытягиваются остальные параметры. Вообщем фактически воссоздать характеристики по их кусочно-линейным аппроксимациям.
Лучше исключить Is сразу же, используя предел
, так как действительно чувствительность к прямой ветке слишком высокая и использовать его как параметр.
Ещё бы дополнительно сравнить температурные зависимости ВАХ, особенно для расчётов тепловых потерь, увеличивающихся с ростом температуры. В даташитах обычно приводят для -40, 25 и 85/105/125). В принципе можно параметр неидеальности n вынести в числитель как
и можно будет использовать линейный МНК.
Также можно использовать аналитическое решение для МНК с уравнением прямой, раз уж используется Maple/Maxima. Аппроксимацию сделал сразу для "ступеньки" функции ВАХ в общем виде, используя точку Vce0.
Как-то строил для транзистора получается примерно следующее
А для анализа характеристик обратного восстановления - включить в ЭДС небольшие катушки (процентов 5-10, обычно равные напряжению к.з. трансформатора/сети.
), чтобы они создавали угол коммутации 
.
Также, по заряду обратного восстановления можно ориентировочно вписать в параметр ёмкость диода
. Помимо этого конечно есть ещё эффект варикапа но для силовых диодов это не актуально.