Нет прямой научной причины для этого. Во многих случаях это связано с управлением и политикой конкретной компании.
Некоторые компании вынуждены создавать систему «под ключ» и заставлять вас покупать эту систему и оплачивать техническое обслуживание. Он блокирует отдельных разработчиков, но есть много компаний и особенно правительственных учреждений, которые предпочитают эту модель, потому что поддержка часто намного лучше, и вы можете часто определять направление их продуктов в соответствии с вашими потребностями.
Другие компании не имеют персонала или таланта и используют решение на стороне и иногда берут все, что могут получить. И у вас может получиться одноразовый инструмент, который после увольнения подрядчика никогда не обновляется и не исправляется, или, если он исправлен, это кто-то другой - исправление. Чтобы заработать деньги, нужны деньги, но если у вас закончились деньги, прежде чем вы сможете продать свой продукт, у вас все равно не получится.
Иногда у вас есть компании, в которых есть сотрудники, которые имеют свой штат, должны покупать у них инструмент И есть люди, которые также участвуют в открытых инструментах, таких как gcc.
Иногда в политике или руководстве компании есть люди, которые твердо убеждены в том, каким должен быть мир, и позволяют разрабатывать инструменты только для конкретного языка. Или, возможно, они принадлежат или являются партнером или просто компанией, у которой есть определенный язык, и этот чиповый продукт просто предназначен для поддержки этого языка.
Вдобавок ко всему этому у вас есть очень реальные технические проблемы с объемом памяти, качеством и эффективностью набора команд, а также с тем, насколько он удобен для компилятора. Некоторые архитектуры могут подойти ассемблеру, но скомпилированный код более высокого уровня слишком быстро уничтожает ограниченные ресурсы памяти.
В частности, у Gcc много внутренних проблем (не как людей, а как самого программного обеспечения / исходного кода). Я призываю вас написать бэкэнд, даже с учебниками, которые есть. Компании требуются специальные таланты для того, чтобы год от года создавать и поддерживать gcc-сервер, в противном случае вас бросают. если ваша архитектура чипов не 32-битная или больше, вы уже сражаетесь с gcc, ваша архитектура чипов может быть дружественной к компилятору, но просто не дружной с популярной конструкцией компиляторов.
В ближайшем будущем llvm будет светить как кросс-компилятор по отношению к gcc, потому что он еще не создал эту внутреннюю массу, и, возможно, поскольку внутренние кишки сами по себе являются определенным языком / системой, он может никогда не пострадать от того, что случилось с НКА. По мере того, как все больше людей будут чувствовать себя комфортно с llvm, мы увидим несколько архитектур, перенесенных на него. Серверная часть msp430 была сделана специально, чтобы продемонстрировать, что вы можете добавить цель буквально во второй половине дня. К концу следующего месяца у некоторых мотивированных людей все цели, о которых большинство из нас когда-либо слышали, были перенесены на llvm. И вам не нужно создавать кросс-компилятор, это всегда кросс-компилятор. Я упоминаю llvm только потому, что теперь дверь открыта для целей, которые пострадали от плохих инструментов для восстановления.
Некоторые компании, в частности микроконтроллеры, могут и будут делать интерфейс программирования проприетарным, чтобы вы могли использовать их инструмент программирования (или взломать его и рискнуть, публикуя эти результаты, или или просто изменить их на победить тебя). И они, возможно, сделали только инструменты для Windows, оставив людей Linux и Apple зависшими на ветру. Или они делают так, чтобы единственные загружаемые им двоичные файлы были сгенерированы их инструментами, и здесь вы снова можете взломать двоичный формат, разрешив альтернативный компилятор, и они могут или не могут победить вас.
Несмотря на технические проблемы, самая большая из них - это политика компаний, менеджмент, маркетинговые команды, а также наличие или недостаток талантов в инженерном персонале.В итоге, следуйте долларам, а не технологиям или науке, чтобы понять, почему этот язык поддерживается, а не тот, или поддержка этого языка хорошая, плохая или незначительная.
Какой язык выучить в результатевсего этого?Начните с ассемблера как минимум на трех разных архитектурах.Затем C и C ++, если вы чувствуете, что вам это действительно нужно.C и ассемблер являются вашими основными языками для встроенных (в зависимости от вашего определения встроенного).Нет, мы пишем ассемблер в основном для начального загрузочного кода и для поддержки C, прерываний или специальных инструкций, которые необходимы компилятору.В таких местах, как микроконтроллеры, вполне может иметь смысл использовать ассемблер по разным причинам, таким как инструменты, ограниченные ресурсы микросхем и т. Д. Даже если вы не используете ассемблер, зная, что это делает вас гораздо лучшим программистом высокого уровня.
Вам нужно решить, каково ваше определение встроенного.Будут ли API и библиотечные вызовы приложения в (n встроенной) системе Linux (неотличимы от той же программы / вызовов в настольной системе).Или на другом конце спектра вы говорите о микроконтроллере с 256 или 1024 байтами (не мега или гига, а байтами) программного пространства?Или что-то посередине?Большинство «встраиваемых» людей ближе к API-вызовам для приложений в операционной системе (rtos, linux, wince и т. Д.), Чем глубоко внедренные, так что это означает C, может быть C ++ (всегда может падатьвернемся к C), пытаясь избежать Python и других языков сценариев, которые являются боровами ресурсов.