Programação Funcional com MCU (s)

12

Linguagens funcionais como Haskell, LISP ou Scheme permitem que um programador trabalhe rapidamente usando o paradigma de programação funcional . Eles têm suas ineficiências , mas meu aplicativo enfatiza mais a eficiência do programador do que a eficiência do próprio programa.

Eu gostaria de usar a programação funcional em um microcontrolador para fazer o controle da máquina, etc.

Que limitações existem, como recursos mínimos do sistema?
Quais exemplos de implementações desses idiomas estão disponíveis?

J. Polfer
fonte
1
Se sua pergunta for "Não vale a pena programar qualquer máquina com a linguagem de programação mais poderosa possível?", As perguntas sobre C ++ e Java são leitura recomendada (sobre OOP em vez de programação funcional).
Kevin Vermeer
1
Seu primeiro parágrafo aparece como argumentativo, o que lhe rendeu alguns votos íntimos. Considere reformular algo mais passivo ("Estou interessado em usar a programação funcional para controle de máquina, que exemplos existem das implementações Haskell / LISP / Scheme para sistemas embarcados") ou removê-lo totalmente.
Kevin Vermeer
2
Não compro sua declaração "ineficiente". Você parece exibir um viés extremo em relação ao lado do hobby / protótipo - baixo volume (aka: 1). C / C ++ / asm resulta em código menor e mais rápido, que é amplificado milhares ou milhões de vezes quando você pode usar processadores com velocidade e espaço suficientes. Incorporado está incorporado. Você não está programando em um sistema operacional de uso geral.
Nick T
4
@Nick T - "C / C ++ / asm resulta em código menor e mais rápido que é amplificado milhares ou milhões de vezes quando você pode usar processadores com velocidade e espaço suficientes" - e a manutenção? Uma linguagem funcional pode frequentemente fazer em uma única linha o que um programa C exige 10s, o que significa menos espaço para erros. Além disso, eles podem ser cumpridos (por exemplo, Haskell) e executados no alvo, o que é mais rápido que os intérpretes. Eu queria explorar esse tópico um pouco porque um Haskell compilado pode ser tão rápido, mas mais rápido de desenvolver do que um aplicativo C. Queria questionar um pouco o status quo.
J. Polfer 27/01
1
@ Sheepsimulator Infelizmente, comentários como o seu último fazem perguntas como essa.
precisa saber é o seguinte

Respostas:

11

O ARMPIT SCHEME é um intérprete para a linguagem Scheme (dialeto do Lisp com escopo lexicamente) que roda em microcontroladores RISC com núcleo ARM. Baseia-se na descrição do Relatório revisado sobre o esquema de linguagem algorítmica (r5rs), com algumas extensões (para E / S) e algumas omissões (para caber na memória do MCU). Ele foi desenvolvido para oferecer suporte a multitarefa e multiprocessamento. Espera-se que o esquema de axilas seja adequado para ambientes educacionais, incluindo projetos de estudantes em cursos de controle e instrumentação ou cursos de design de capstone onde são necessários microcontroladores. Destina-se a enriquecer o espectro de linguagens interpretadas disponíveis para MCUs (por exemplo, BASIC e FORTH) e pode ser uma alternativa aos intérpretes de bytecode baseados em MCU (por exemplo, para Scheme ou Java) e a linguagens compiladas (por exemplo, C).

http://armpit.sourceforge.net/

Você diz:

Usar C, C ++, assembly etc. é bastante ineficiente em comparação com linguagens como Haskell, LISP ou Scheme

O uso de linguagens de alto nível é um uso mais eficiente do tempo do programador, mas geralmente pode ser um uso menos eficiente dos recursos de computação. Para sistemas embarcados fabricados em volume, o custo e o desempenho geralmente são uma prioridade mais alta que o esforço de desenvolvimento.

Toby Jaffey
fonte
5

C, C ++ e Assembly são todos muito próximos da linguagem de máquina. Ao usar um idioma de nível superior, você está adicionando uma sobrecarga adicional em troca de um desenvolvimento mais rápido / fácil / etc.

pfyon
fonte
3
-1: Eu realmente não concordo com esta resposta. Embora você esteja certo sobre o Assembly estar próximo da linguagem de máquina, C e C ++ são linguagens de alto nível muito diferentes.
BG100 27/01
1
@ BG100, eu realmente desenhava a linha "alto nível / baixo nível" em algum lugar dentro de C, em vez de chamá-la de linguagem de alto nível. Ao executar operações aritméticas, de ponteiro (string) e outras tarefas básicas comuns, as instruções que os compiladores geralmente produzem têm a CPU manipulando diretamente os dados sem nenhuma camada de abstração.
Nick T
@ Nick T: Entendo o seu ponto, mas considere o seguinte: se você escrever uma rotina de interrupção que geralmente precisa ser executada o mais rápido possível, em C você não terá idéia de quanto tempo levará para executar, mas no assembler você poderá apenas conte as instruções. Eu acho que o nível baixo é saber EXATAMENTE estava acontecendo no seu programa, você não sabe ao certo se está usando C.
BG100
@ BG100: a mesma instrução assembler pode levar diferentes números de ciclos para executar com base nos operandos e seus modos de endereçamento. Embora em C, depois de compilar, você obtém um código estático que não muda (não pode). É verdade, este é um argumento um tanto tênue, mas se vamos discutir as minúcias para tentar desenhar uma linha vermelha grande ...
Nick T
3

Estive programando uma placa ARM em Python recentemente e acho ótimo. Não é bom para o controle em tempo real, mas estou fazendo mais coisas relacionadas à Web, o que é muito mais agradável em uma linguagem de alto nível do que em C.

pingswept
fonte
3

A maioria dos microcontroladores ainda são dispositivos de 8 e 16 bits (embora isso esteja mudando lentamente). As duas instâncias de linguagens de nível superior (Scheme e Python) mencionadas em outras respostas até agora estão sendo executadas em núcleos ARM de 32 bits. Os dispositivos menores de 8 e 16 bits (que podem custar apenas alguns dólares) não têm RAM suficiente para suportar os idiomas mencionados - normalmente eles têm apenas alguns KB de RAM.

Além disso, esses idiomas de nível superior não foram projetados para escrever manipuladores de interrupção de baixa latência e similares. Não é incomum que um manipulador de interrupções por microcontrolador seja chamado centenas ou milhares de vezes por segundo, e cada vez é necessário executar sua tarefa em dezenas de microssegundos ou menos.

tcrosley
fonte
1
O esquema foi desenvolvido em meados dos anos 70 e início dos anos 80. De maneira alguma o Scheme exige um processador de 32 bits ou megabytes de memória. O esquema estava disponível para PCs da classe AT em meados dos anos 80. As implementações recentes podem ser otimizadas para ambientes mais ricos em recursos, mas há exemplos claros de esquemas executados no que hoje são plataformas de computação "minúsculas".
O Photon
@ThePhoton Estou corrigido. Embora eu estivesse ciente do projeto BIT, que tem como alvo processadores com dezenas de KB de memória (mais do que o que está disponível na maioria dos microcontroladores pequenos), acabei de descobrir o PICBIT , projetado por alguns estudantes da Université de Montréal e Université Laval, que permite que programas reais do Scheme sejam executados em processadores PIC com apenas 2K de RAM. Muito incrível.
tcrosley
3

É possível fazer alguma programação funcional com a linguagem Lua. Realmente, Lua é uma linguagem de paradigma mútuo; A Wikipedia afirma que é uma linguagem de 'script, imperativa, funcional, orientada a objetos e baseada em protótipo'. A linguagem não impõe um único paradigma, mas é flexível o suficiente para permitir que o programador implemente qualquer paradigma aplicável à situação. Foi influenciado pelo Scheme.

Os recursos de Lua incluem funções de primeira classe , escopo lexical e fechamentos e corotinas , úteis para programação funcional. Você pode ver como esses recursos são usados ​​no wiki de usuários do Lua, que possui uma página dedicada à programação funcional . Também me deparei com esse projeto do Google Code , mas não o usei (ele afirma ter sido influenciado pelo Haskell, outro idioma que você mencionou).

eLua é uma implementação disponível configurada para várias placas de desenvolvimento para as arquiteturas ARM7TMDI, Cortex-M3, ARM966E-S e AVR32, e é de código aberto para que você possa configurá-lo para sua própria plataforma. Lua é implementada no ANSI C e a fonte inteira pesa menos de 200kB, portanto, você poderá construí-lo para a maioria das plataformas com um compilador C. Recomenda-se pelo menos 128k de Flash e 32k de RAM. No momento, estou trabalhando em uma porta PIC32 (ainda no estágio 'Get the PIC32 board').

O melhor de Lua é que ele foi projetado como uma linguagem de cola, por isso é muito fácil escrever extensões C para as coisas que precisam ser rápidas (como interrupções etc.) e usar os recursos dinâmicos e interpretados da linguagem para executar rapidamente desenvolvimento na lógica do programa.

Lua não é uma linguagem puramente funcional, mas você pode fazer muita programação funcional, é rápida e pequena (em comparação com outras linguagens de script ) e não precisa atualizar o dispositivo novamente para experimentar um programa. Existe até um intérprete interativo!

Kevin Vermeer
fonte
1

"Existem maneiras de fazer programação funcional com uma linguagem funcional em um MCU para resolver problemas difíceis?"

Sim, existem maneiras. Mas o lado negativo é que você precisa de um processador de 32 bits, MMU, 128MB de RAM, SSD, um RTOS e $$$.

Microcontroladores são diferentes dos microprocessadores. O microcontrolador pode ser apenas uma CPU de 8 bits, 1K RAM, 8K ROM, mas possui UART, PWM, ADC, etc. embutidos, e custa apenas US $ 1,30.

Portanto, você pode ter todas as linguagens de alto nível em execução, mas custa muito mais.

Robert
fonte
2
Eu acho que você precisa revisitar sua definição de microcontrolador. Muitos microcontroladores agora têm 128kB ou mais de Flash e 64kB ou mais de RAM, muito espaço para executar um intérprete para alguns idiomas pequenos. Parece que você está fornecendo especificações para um dispositivo Linux incorporado; Eu acho que o OP estava pedindo uma porta dedicada.
Kevin Vermeer
1
Se você está pagando US $ 1,30 por uma MCU de 8 bits, existem várias MCUs de 32 bits mais baratas. Além disso, leve em consideração que a maioria dos MCUs de 8 bits no mercado são arquiteturas horrivelmente ineficazes em código, com projetos herdados do início dos anos 80.
Lundin
0

Este livro fornece uma maneira de programar com uma leve sensação do FP. http://www.state-machine.com/psicc2/

Mas o FP real precisa ter a capacidade de construir funções em tempo de execução e transmiti-las pelo seu programa. Aqui temos um problema: como podemos representar essa função construída? e como podemos efetivamente executar essa função? Em um sistema grande, podemos usar a compilação dinâmica que gera código de máquina real em um aplicativo de primeira função. No MCU, temos apenas RAM para implementar compiladores muito primitivos, como o núcleo da linguagem Forth.

A única maneira de usar FP ou OOP, se preferir, é a metaprogramação : escreva programas funcionais / OOP complexos que geram programas para MCU (código-fonte C, por exemplo, ou LLVM IL). Nesta variante, você não está limitado pelo paradigma ou pela complexidade dos métodos de programação.

Dmitry Ponyatov
fonte