Функциональное программирование с MCU


12

Функциональные языки, такие как Haskell, LISP или Scheme, позволяют программисту быстро работать с использованием парадигмы функционального программирования . У них есть свои недостатки , но мое приложение придает большее значение эффективности работы программиста, чем эффективности самой программы.

Я хотел бы использовать функциональное программирование на микроконтроллере для управления машиной и т. Д.

Какие существуют ограничения, такие как минимальные системные ресурсы?
Какие примеры реализации этих языков доступны?


1
Если ваш вопрос «Не стоит ли программировать какую-либо машину с помощью самого мощного языка программирования, на который вы способны» , рекомендуется прочитать вопросы по C ++ и Java (об ООП, а не о функциональном программировании).
Кевин Вермеер

1
Ваш первый абзац выглядит как аргументированный, который принес вам несколько близких голосов. Попробуйте переписать что-то более пассивное («Я заинтересован в использовании функционального программирования для управления машиной, какие есть примеры реализаций Haskell / LISP / Scheme для встроенных систем») или полностью исключить его.
Кевин Вермеер

2
Я не покупаю ваше "неэффективное" утверждение. Вы, кажется, демонстрируете крайнюю предвзятость к стороне любителя / прототипа - низкий объем (он же: 1). C / C ++ / asm дает меньший, более быстрый код, который усиливается тысячи или миллионы раз, когда вы можете использовать процессоры с достаточной скоростью и пространством. Встроенный встроен. Вы не программируете на ОС общего назначения.
Ник Т

4
@ Ник Т - «C / C ++ / asm приводит к меньшему, более быстрому коду, который усиливается тысячи или миллионы раз, когда вы можете использовать процессоры с достаточной скоростью и пространством» - как насчет обслуживания? Функциональный язык может часто делать в одной строке то, что для C-программы требуется 10 секунд, что означает меньше места для ошибок. Кроме того, они могут быть выполнены (например, Haskell), и заставить работать на цели, что быстрее, чем переводчики. Я хотел немного изучить эту тему, потому что скомпилированный Haskell мог бы быть таким же быстрым, но быстрее разрабатывать, чем, скажем, приложение на Си. Хотел немного усомниться в статус-кво.
Дж. Полфер

1
@Sheepsimulator К сожалению, комментарии, подобные вашему последнему, вызывают такие спорные вопросы.
Келленжб

Ответы:


11

ARMPIT SCHEME - интерпретатор языка Scheme (лексически ограниченный диалект Lisp), который работает на микроконтроллерах RISC с ядром ARM. Он основан на описании в пересмотренном отчете об алгоритмической языковой схеме (r5rs), с некоторыми расширениями (для ввода-вывода) и некоторыми упущениями (для размещения в памяти MCU). Он также предназначен для поддержки многозадачности и многопроцессорности. Ожидается, что схема подмышек будет хорошо подходить для образовательных учреждений, включая студенческие проекты на курсах по управлению и контрольно-измерительным приборам, или на курсах по разработке замкового камня, где необходимы микроконтроллеры. Он предназначен для обогащения спектра интерпретируемых языков, доступных для MCU (например, BASIC и FORTH), и может быть альтернативой интерпретаторам байт-кода на основе MCU (например, для Scheme или Java) и компилируемым языкам (например, C).

http://armpit.sourceforge.net/

Ты говоришь:

Использование C, C ++, сборок и т. Д. Довольно неэффективно по сравнению с такими языками, как Haskell, LISP или Scheme.

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



5

C, C ++ и Assembly очень близки к машинному языку. Используя язык более высокого уровня, вы добавляете дополнительные накладные расходы в обмен на более быструю / легкую / и т.д. разработку.


3
-1: я не очень согласен с этим ответом. Хотя вы правы в том, что Assembly близко к машинному языку, C и C ++ очень разные языки высокого уровня.
BG100

1
@ BG100, я бы на самом деле нарисовал линию «высокий уровень / низкий уровень» где-то внутри C, а не просто назвал бы это языком высокого уровня. При выполнении арифметических, указательных (строковых) операций и других общих базовых задач обычно выполняемые компилятором инструкции имеют ЦП, непосредственно манипулирующий данными без каких-либо уровней абстракции.
Ник Т

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

@ BG100: одна и та же инструкция на ассемблере может выполнять разное количество циклов в зависимости от операндов и их режимов адресации. Хотя в C, после компиляции вы получаете статический код, который не может (не может) меняться. Правда, это несколько сомнительный аргумент, но если мы собираемся спорить по мелочам, чтобы попытаться нарисовать большую красную линию ...
Ник Т

3

Я недавно программировал ARM-доску на Python, и я думаю, что это здорово. Это плохо для контроля в реальном времени, но я делаю больше вещей, связанных с сетью, что гораздо приятнее на языке высокого уровня, чем на C.


3

Большинство микроконтроллеров по-прежнему являются 8- и 16-разрядными устройствами (хотя это постепенно меняется). Два экземпляра языков высокого уровня (Scheme и Python), упомянутые в других ответах, до сих пор работают на 32-битных ядрах ARM. Меньшие 8- и 16-разрядные устройства (которые могут стоить всего пару долларов) не имеют достаточно ОЗУ для поддержки упомянутых языков - обычно они имеют только несколько КБ ОЗУ.

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


1
Схема была разработана в середине-конце 70-х и в начале 80-х годов. Схема ни в коем случае не требует 32-битного процессора или мегабайт памяти. Схема была доступна для ПК класса AT в середине 80-х годов. Недавние реализации могут быть оптимизированы для более богатых ресурсами сред, но есть наглядные примеры схем, которые работают на современных «крошечных» вычислительных платформах.
Фотон

@ThePhoton Я стою исправлено. Хотя мне было известно о проекте BIT, который нацелен на процессоры с десятками КБ памяти (больше, чем доступно на большинстве небольших микроконтроллеров), я только что обнаружил PICBIT , разработанный двумя студентами в Университете Монреаля и Университете Лаваль, который позволяет программам реального Scheme работать на процессорах PIC с всего лишь 2K RAM. Довольно удивительно.
tcrosley

3

Возможно сделать функциональное программирование на языке Lua. На самом деле, Lua - это язык многопарадигмы; Википедия утверждает, что это «скриптовый, императивный, функциональный, объектно-ориентированный, основанный на прототипах» язык. Язык не обеспечивает единой парадигмы, но достаточно гибок, чтобы позволить программисту реализовать любую парадигму, применимую к ситуации. Это было под влиянием Схемы.

Возможности Lua включают в себя первоклассные функции , лексическую область видимости, замыкания и сопрограммы , которые полезны для функционального программирования. Вы можете увидеть, как эти функции используются на вики-сайте Lua для пользователей, где есть страница, посвященная функциональному программированию . Я также сталкивался с этим проектом Google Code , но я не использовал его (он утверждает, что находится под влиянием Haskell, другого языка, который вы упомянули).

eLua - это реализация, которая настроена для ряда плат разработки для архитектур ARM7TMDI, Cortex-M3, ARM966E-S и AVR32 и имеет открытый исходный код, так что вы можете настроить ее для своей собственной платформы. Lua реализован на ANSI C, и весь исходный код весит менее 200 КБ, поэтому вы должны иметь возможность собрать его для большинства платформ с компилятором C. Рекомендуется не менее 128 КБ флэш-памяти и 32 КБ ОЗУ. Я работаю над портом PIC32 для него (все еще на стадии «Получить плату PIC32», хотя) в данный момент.

Самое замечательное в Lua состоит в том, что он был разработан как склеивающий язык, поэтому очень легко писать расширения C для вещей, которые должны быть быстрыми (например, прерывания и т. Д.), И использовать динамические, интерпретируемые функции языка для быстрой работы. развитие в логике программы.

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


1

«Есть ли способы сделать функциональное программирование с функциональным языком на MCU для решения сложных проблем?»

Да, есть способы. Но недостатком является то, что вам нужен 32-разрядный процессор, MMU, 128 МБ ОЗУ, SSD, RTOS и $$$.

Микроконтроллеры отличаются от микропроцессоров. Микроконтроллер может быть только 8-битным процессором, 1K RAM, 8K ROM, но он имеет встроенный UART, PWM, ADC и т. Д. И стоит всего 1,30 доллара.

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


2
Я думаю, вам нужно пересмотреть определение микроконтроллера. Многие микроконтроллеры теперь имеют 128 КБ или более Flash и 64 КБ или более RAM, достаточно места для запуска интерпретатора для некоторых небольших языков. Похоже, вы даете спецификации для встроенного устройства Linux; Я думаю, что ОП просил выделенный порт.
Кевин Вермеер

1
Если вы платите $ 1,30 за 8-битный MCU, то есть несколько 32-битных MCU, которые дешевле. Кроме того, примите во внимание, что большинство 8-битных микроконтроллеров на рынке представляют собой ужасно неэффективные архитектуры кода, а проекты унаследованы с начала 80-х годов.
Лундин

0

Эта книга предоставляет некоторый способ сделать программирование с легким ощущением FP. http://www.state-machine.com/psicc2/

Но настоящие FP требуют способности создавать функции во время выполнения и передавать их через вашу программу. Здесь у нас есть проблема: как мы можем представить эту построенную функцию? и как мы можем эффективно выполнить эту функцию? В большой системе мы можем использовать динамическую компиляцию, которая генерирует реальный машинный код в первом приложении функции. На MCU у нас есть только RAM для реализации очень примитивных компиляторов, таких как ядро ​​языка Forth.

Единственный способ, которым вы можете использовать FP или OOP, если предпочитаете, - это метапрограммирование : писать сложные функциональные / OOP- программы, которые генерируют программы для MCU (например, исходный код на C или LLVM IL). В этом варианте вы не ограничены ни парадигмой, ни сложностью методов программирования.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.