Запись встроенного микропрограммного обеспечения: уровень ассемблера или высокий уровень?

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

Если Вы - написание кода, которое очень зависит от определенных для устройства периферийных устройств, и набор инструментальных средств, который Вы используете, не обеспечивает необходимый intrinsics для использования их эффективно (как дрянной компилятор Freescale DSP563CC), то использует блок.

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

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

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

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

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

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

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

Определенно C, кроме тех случаев, когда

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

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

Пойдите для c!

я работал на крупного производителя CE. В прошлый раз, когда я видел, блок был было приблизительно в 1996 в некоторых маленьких сервисных стандартных программах прерывания для RC5 и декодирования RC6 и телевизионных настраивающих алгоритмов. После этого всегда используемый c и C++ (только используемые классы, никакой stl, исключения или rtti). У меня есть хороший опыт со старым компилятором KEIL для 8 051 и с greenhills компилятором (MIPS) и набор инструментов VxWorks (базирующийся PowerPC).

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

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

Моим недавним подходом всегда была Запись this:-

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

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

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

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

Другая вещь, которая конкретно имеет отношение к PIC18. Вы не должны будете иметь дело с неинтуитивной архитектурой PIC и вещами как сегменты памяти.

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

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

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

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

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

Что касается компиляции, Google вокруг для компилятора C для Вашей цели.

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

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

, Почему Ассемблер?
можно вручить оптимизацию ремесла.

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

Характерный для аппаратных средств PIC
Это кажется , что у Вас нет опции GCC с большинством аппаратных средств PIC. С другой стороны, как комментатор отметил, Микрочип, компилятор C30 для 16-разрядного PIC24 и dsPIC33 является gcc.
PIC также еще не поддерживается SDCC.
Новая Информация: согласно комментарию, SDCC имеет осуществимую поддержку PIC.
существуют некоторые другие опции открытого исходного кода , но у меня нет опыта с ними.

Plain C or Pascal, Modula2. But due to compiler availability that means C.

The extra's of C++ and similars are only interesting out of style grounds, since dynamic allocation and program size is usually very limited.

Also a more complicated runtime can be a pain if your apps get tight.

Assembler can be useful too, but only if you sell really gigantic quantities, and a smaller firmware means a smaller, cheaper chip (less flash) and the program's size is overseeable (read: there is some chance that you will get it bugfree in time)