Написание прошивки: сборка или высокий уровень?

Ответ 1

Несколько комментариев:

1) Абсолютно не, если это не оправдывает ограничения производительности или оптимизации. Следующие метрики проходят через крышу со сборкой:

• время, чтобы закодировать его
• время для его отладки
• время для тестирования
• время для его документирования
• время для выяснения (через 1 год), что именно вы делали, когда вы его закодировали.
• вероятность совершения ошибки

2) Моим преимуществом был бы С++, а не C для его инкапсуляции пространства имен и его упрощение объектно-ориентированных методов компиляции. C имеет слишком много возможностей для глобальных переменных и конфликтов пространства имен. (Java в режиме реального времени будет приятным, но из того, что я понимаю, его требования все еще довольно высоки)

Или, скорее, подмножество С++: исключение исключений, виртуальных функций, идентификация типа во время выполнения, а также динамическое распределение памяти в большинстве случаев - в основном все, что осталось во время компиляции, поскольку для этого обычно требуется много дополнительных ресурсов во время выполнения. Это "раздувание" С++.

Я использовал компиляторы TI и IAR для С++, для микроконтроллеров TMS320 и MSP430 (соответственно) и с правильными настройками оптимизации, они делают фантастическую работу по сокращению накладных расходов, которые можно ожидать от С++. (Особенно, если вы поможете в разумном использовании ключевого слова inline)

Я даже использовал шаблоны для некоторых своих преимуществ во время компиляции, которые способствуют хорошему повторному использованию кода: например. запись одного исходного кода для обработки 8-битных, 16-битных и 32-битных CRC; и полиморфизм времени компиляции, чтобы вы могли указать обычное поведение класса, а затем повторно использовать это, но переопределить некоторые его функции. Опять же, у TI-компилятора были чрезвычайно низкие накладные расходы с соответствующими настройками оптимизации.

Я искал компилятор С++ для PIC Microchip; единственная компания, которую я нашел, которая производит один, - IAR. ($$$ было препятствием, но я надеюсь купить копию когда-нибудь). Компиляторы Microchip C18/C30 довольно хороши, но они C, а не С++.

3) Конкретная оговорка о оптимизации компилятора: она может/сделает отладку очень сложной; часто невозможно одноэтапно с помощью оптимизированного кода C/С++, и ваши окна часов могут отображать переменные, которые не имеют корреляции с тем, что, по их мнению, они должны содержать с неоптимизированным кодом. (Хороший отладчик предупредил бы вас, что определенная переменная была оптимизирована из-за существования или в регистр, а не в памяти. Многие отладчики этого не делают. > :(

Также хороший компилятор позволит вам выбрать/выбрать оптимизацию на уровне функции через #pragmas. Те, которые я использовал, позволяют указывать оптимизацию на уровне файлов.

4) Взаимодействие кода C с сборкой: обычно это сложно. Самый простой способ - сделать функцию заглушки, у которой есть подпись, которую вы хотите, например. uint16_t foo(uint16_t a, uint32_t b) {return 0; }, где uint16_t= unsigned short, мы обычно делаем # разрядов явным. Затем скомпилируйте его и отредактируйте создаваемую им сборку (просто убедитесь, что вы оставите части начала и выхода кода) и будьте осторожны, чтобы не сбивать любые регистры, не восстанавливая их после того, как вы закончите.

Встроенная сборка обычно может иметь проблемы, если вы не делаете что-то очень простое, как включение/отключение прерываний.

Подход, который мне больше всего нравится, - это синтаксис компилятора intrinsics/ "extended ASM". Компилятор Microchip C основан на компиляторе GNU C и имеет " расширенный ASM", который позволяет вам кодировать бит встроенной сборки, но вы можете дать ей много подсказок, чтобы указать, какие регистры/переменные вы ссылаетесь, и будет обрабатывать все сохранение/восстановление регистров, чтобы убедиться, что ваш код сборки "играет хорошо" с компилятором C. TI для DSP TMS320 не поддерживает их; он имеет ограниченный набор функций, которые могут быть использованы.

Я использовал сборку для оптимизации некоторого кода цикла управления, который часто выполнялся, или для вычисления значений sin(), cos() и arctan(). Но в противном случае я бы держался подальше от сборки и придерживался языка высокого уровня.

Ответ 2

Большинство производителей микроконтроллеров предоставляют какой-то кросс-компилятор, где вы можете скомпилировать код на своем ПК, а затем передать его на микроконтроллер.

Почему C?
Преимущество C заключается в том, что ваш код будет легче переносить на другие микроконтроллеры в будущем. История вычислений показала, что код обычно превзошел аппаратные реализации.
Второе преимущество - структуры управления (если, для, while), которые делают код более читабельным и поддерживаемым.

Почему язык сборки?
Вы можете использовать оптимизацию судов.

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

Конкретно для оборудования PIC
Он кажется, что у вас нет возможности GCC с большинством оборудования PIC. С другой стороны, как отметил комментатор, компилятор Microchip C30 для 16-разрядных PIC24 и dsPIC33 - gcc.
PIC также пока не поддерживается SDCC.
Новая информация: согласно комментарию, SDCC имеет работоспособную поддержку ПОС.
Есть и другие источники с открытым исходным кодом, но у меня нет опыта с ними.

Ответ 3

Лучшим вариантом, вероятно, является код на C, а затем для очень немногих случаев, когда вам нужно оптимизировать работу и выполнять лучшую работу, чем компилятор, вы должны закодировать сборку в своих c файлах.

Ответ 4

Абонентское кодирование ушло в прошлое для ПК, но очень актуально во встроенном.

Встраивание записи во встроенном языке отличается от записи сборки на ПК. Компиляторы ПК "лучше людей" при создании оптимизированных инструкций. Встраиваемые системы часто имеют странные архитектуры, а их оптимизирующие компиляторы не так зрелы, как компилятор, оптимизирующий ПК.

Ответ 5

Одна проблема, с которой я столкнулся с записью сборки для микроконтроллера, - это необходимость очень осторожно относиться к тому, как был составлен ваш код. Наличие перекрестной границы перекрестных границ памяти и выведение вашего кода в действительно странные места вызывает беспокойство. Кодирование в C, компилятор покрывает эту базу для вас.

Ответ 6

Я бы определенно пошел с C. Это быстрее и создает более надежное программное обеспечение. Ассамблея имеет очень мало предложений и в редких случаях. Имейте в виду, что в C:

• Вы сможете легко переносить код с существующих платформ, даже с ПК.
• Вы можете разрабатывать язык высокого уровня без ущерба для скорости выполнения или размера кода. При условии наличия качественного компилятора (существует много вариантов для PIC18), они, скорее всего, будут лучше с C, чем сборка вручную.
• Намного проще отлаживать, тестировать и поддерживать код. C создает более надежный код.

Другое, что конкретно связано с PIC18. Вам не придется иметь дело с неинтуитивной архитектурой PIC и такими вещами, как БАНКИ памяти.

Ответ 7

У меня был хороший опыт работы с IAR Компиляторы C для 8051 в прошлом.

Мой недавний подход всегда был таким: -

Запишите его на C с хорошим оптимизирующим компилятором и ТОЛЬКО, если есть проблема с размером или скоростью, рассмотрите возможность перезаписи некоторых частей в ассемблере.

Однако, учитывая этот подход, я никогда не нуждался в , чтобы написать одну строку ассемблера...

Ответ 8

Перейдите на c!

Я работал на крупного производителя CE. Последний раз, когда я видел сборку, было около 1996 года в некоторых небольших процедурах обслуживания прерываний для алгоритмов декодирования RC5 и RC6 и ТВ-тюнинга. После этого всегда используются c и С++ (используются только классы, stl, exceptions или rtti). У меня есть хороший опыт работы с старым компилятором KEIL для 8051 и с компилятором Greenhills (MIPS) и набором инструментов VxWorks (на базе PowerPC).

Как говорит Родди, сначала напишите на C, а позже оптимизируйте в сборке (при необходимости).

Ответ 9

Сборка во многих случаях может быть быстрее; когда вы находитесь на рабочем столе, компиляторы, как правило, оптимизируются до такой степени, что сборка вручную редко необходима, но в мире UC это часто бывает. Кроме того, если вам нужно писать процедуры обработки прерываний и т.д., Вы часто не можете делать это на C.

Как для компиляции, google вокруг для компилятора C для вашей цели.

Ответ 10

Определенно C, за исключением случаев, когда

• Программная память крайне ограничена. Скажите после кропотливой ручной оптимизации вашего кода ассемблера, который вам подходит, чтобы соответствовать вашей программе в 1024 байтах Flash, с оставленными 0 байтами. В этом случае компилятор C не будет хорош.

• вы хотите иметь абсолютный контроль времени. Если время задержки прерывания слишком велико, вам придется полагаться на ассемблер.

Ответ 11

В наши дни проблема заключается в том, что встроенный может быть чем угодно: от ATTiny с 6 выводами и несколькими байтами ОЗУ до многоядерного SBC, запускающего встроенную ОС, которая может позорить некоторых пользователей настольных компьютеров.

Таким образом, выбор среды langauge/development должен учитывать то, насколько эффективно вам нужно, насколько сложна система.

Во-первых - C работает повсюду и хорошо масштабируется, чем выше вы идете, тем больше вы будете обращаться к внешним библиотекам и т.д., чтобы справиться со сложностью.

Для очень маленьких микросхем (измерение вспышки/бара в байтах) вам лучше всего использовать ASM, когда вы подходите к диапазону kb, C или любой другой традиционный язык можно использовать, так как вам не нужно считать каждый байт. Когда у вас есть мегабайты для игры, у вас есть как способность, так и, скорее всего, необходимость использования RTOS, чтобы заботиться обо всем и сократить время разработки. К тому времени, когда у вас есть аппаратное обеспечение, вы можете запустить полномасштабную ОС, вы можете, возможно, отвлечь себя от аппаратного обеспечения и просто написать все в дополненной ячейке, такой как Java, или что-то подобное, не слишком беспокоясь о том, насколько ужасно расточительно это все и как вы не настоящий программист больше...;)

Исключение из вышеизложенного - это когда вам нужна вся производительность, которую вы можете вырвать из аппаратного обеспечения, после чего вам может потребоваться сбросить уровень или два, чтобы сохранить эффективность.

Ответ 12

Есть еще один момент, когда может понадобиться запись в сборке: если вам нужно выполнить какой-то тест низкого уровня или аналогичный, что требует абсолютного контроля над хранением данных.

Например, программное обеспечение, которое подтверждает SIL -2 (уровень целостности безопасности) и выше, может потребовать постоянных проверок ОЗУ, чтобы обнаружить любое возможное повреждение данных. Область проверки, которую вы проверяете, не может меняться во время ее проверки, поэтому запись теста на ассемблере позволяет убедиться, что это верно, например, путем хранения любых локальных переменных в определенных регистрах или в другой области ОЗУ, Это было бы трудно, если не невозможно, в C.

Код запуска, который обнуляет ОЗУ и инициализирует ненулевые статические переменные, также может быть написан на ассемблере для того же написанного, хотя обычно этот тип кода предоставляется.

Ответ 13

Если вы пишете код, сильно зависящий от периферийных устройств, и используемая цепочка инструментов не обеспечивает необходимые возможности для их эффективного использования (например, crappy Freescale DSP563CC компилятор), то используйте сборку.

Кроме того, я думаю, что неписанные правила использования сборки и языка высокого уровня более или менее такие же, как и для разработки настольных программ: держите код в чистоте, поддерживаемом и оптимизируя горячий код с машинным языком.

Ответ 14

Это нижняя строка, если вы используете C, вы можете вручную оптимизировать позже, я бы не использовал ничего, кроме C или ассемблера (без С++ и т.д.).

Ключом является набор инструкций микроконтроллера, если вы используете PIC или даже 8051, я бы использовал только ассемблер. Если это компилятор дружественный isa, как arm или avr или msp430, то используйте C, чтобы сохранить некоторую типизацию, но вы, вероятно, будете иметь некоторые подпрограммы в ассемблере по разным причинам. Точно так же вы, вероятно, хотите избежать библиотеки C, даже newlib может быть слишком громоздким, заимствовать у него код или идеи, но просто не свяжите его. О, вернемся к вопросу, посмотрите, какие компиляторы C доступны для цели, снова рука и avr вы не будете иметь никакие проблемы. Вероятно, msp в порядке. Просто потому, что Keil или Iar ПРОДАЮТ вам, что компилятор не означает, что вы должны его купить или использовать, выход платы за, а также бесплатные компиляторы могут быть ужасными. В любом случае вам нужно хорошо разбираться в asm и изучить результат (вам, вероятно, придется написать дизассемблер, чтобы это сделать).

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

Ответ 15

Слишком плохо, что пока никто не упомянул Forth или Scheme. Оба могут быть подходящими для небольших сред и могут приносить впечатляющие результаты.

Ответ 16

Обычная C или Pascal, Modula2. Но из-за доступности компилятора это означает C.

Дополнительные С++ и аналогичные материалы интересны только в стиле, поскольку динамическое распределение и размер программы обычно очень ограничены.

Кроме того, более сложное время выполнения может быть больно, если ваши приложения становятся жесткими.

Ассемблер может быть полезен, но только если вы продаете действительно гигантские количества, а меньшая прошивка означает меньший, более дешевый чип (меньше вспышки), а размер программы контролируется (читайте: есть вероятность, что вы его получите без ошибок во времени)

Ответ 17

Код на языке ассемблера действительно быстр с небольшим размером, но код, написанный на языке ассемблера, не является кодом многократного использования. Эта возможность повторного использования для кода является наиболее важной функцией при разработке программного обеспечения. Например, если у вас есть код проекта на ассемблере для процессора x86, его можно использовать только для процессора x86, а не для процессора ARM. Но если у вас есть код проекта C/C++ для процессора x86, вы можете использовать этот код для процессора ARM. Итак, лучше избегать ассемблера для разработки программного обеспечения.