ASM51

Boa tarde pessoal,

Estou desenvolvendo um projeto para conclusão de curso que basicamente trata-se da definição de uma linguagem de baixo nível universal (semelhante a um assembly ou bytecode) e da criação de uma máquina virtual para interpretação deste código (cada arquitetura de microcontrolador terá sua máquina virtual dedicada). A ideia é deixar a lógica dos produtos independente do microcontrolador utilizado, facilitando assim upgrades de hardware e possibilitando o desenvolvimento de interfaces de programação em diversas linguagens (fluxograma, ladder, blocos, etc) que sejam comuns a todos os microcontroladores.
Não sei se minha especificação acima ficou clara, segue abaixo uma imagem que descreve a ideia.

A pergunta que gostaria de fazer é: Vocês conhecem algo do gênero já desenvolvido?
Já vi especificações de maquinas virtuais java para uC, mas não é bem esse meu objetivo.

Jonas Rekowsky.

Já vi especificações de maquinas virtuais java para uC, mas não é bem esse meu objetivo.

Eu iria sugerir algo assim

Jonas ,


Me parece uma ideia bem interessante, se entendi direito.

Seria uma espécie de uma camada de baixo nível para lidar com os dispositivos de hardware embutidos, permitindo portar para qualquer uC ? Tipo, a idéia seria não ter de se preocupar com a configuração de qualquer registrador do uC em C, mas estando tudo em API ?

andre_teprom escreveu:Jonas ,


Me parece uma ideia bem interessante, se entendi direito.

Seria uma espécie de uma camada de baixo nível para lidar com os dispositivos de hardware embutidos, permitindo portar para qualquer uC ? Tipo, a idéia seria não ter de se preocupar com a configuração de qualquer registrador do uC em C, mas estando tudo em API ?

Exatamente André, a ideia é ficar totalmente independente de microcontrolador.

jonowsky escreveu:Estou desenvolvendo um projeto para conclusão de curso...

Se o seu orientador abraçar essa ideia seria fantastico, pois a cada periodo ele poderia colocar mais alunos incluindo outros cores na biblioteca, de modo a conquistar o público profissional.

É justamente oq meu aluno de tccii
esta fazendo.
Um ambiente ladder que gera uma
linguagem intermediária que pode
ser convertida para qualquer outra.
Hoje sera para C pra rodar em
embedded linux num g25

Para quê re-inventar a roda cambda? C já faz isso desde a década de 70 quando foi criado para substituir o assembly!!!

Pelo que entendi, o C não é a linguagem intermediária, diferentemente da proposta do trabalho acima.

andre_teprom escreveu:

jonowsky escreveu:Estou desenvolvendo um projeto para conclusão de curso...

Se o seu orientador abraçar essa ideia seria fantastico, pois a cada periodo ele poderia colocar mais alunos incluindo outros cores na biblioteca, de modo a conquistar o público profissional.

O orientador achou legal e esta comigo! Quanto a essa idéia de desenvolver para outros cores, se achasse mais alguns malucos pra abraçar a idéia, a coisa poderia ficar bacana! Minha idéia é depois do Tcc desenvolver também a interface gráfica, que pode ser em uma linguagem bem alto nível, tipo fluxograma ou blocos...
A linguagem intermediária que vou desenvolver já será em um nível mais alto, basicamente vai ser uma linguagem baseada em serviços, que utilizará serviços providos pela máquina virtual, desta maneira quem vai fazer o trabalho pesado vai ser a vm mesmo. A linguagem intermediária vai ser responsável por configurar o serviço e utilizar...

Tcpipchip, o trabalho do teu orientando me parece similar ao desenvolvido nesta tese de doutorado :
http://www.bibliotecadigital.unicamp.br ... s000188765

Se for, talvez ele possa utilizar como referencial teórico.

Isso tá parecendo com as linguagens gerenciadas e interpretadas mas com interface gráfica

Olha, mesmo que você não vá por essa linha, recomendo dar uma olhada no projeto LLVM, que é um projeto antigo e que resultou em muitos produtos comerciais (e em uma tonelada de papers acadêmicos).

Basicamente, eles desenvolveram um port do GCC que ao invés de ter o assembly para uma arquitetura específica, gera como saída o que eles chamam de "saida intermediária" (LLVM-IR).

Esta saída intermediária pode ser:

a) (re)Compilada para gerar um executável/biblioteca para qualquer uma das arquiteturas em que exista um port LLVM-IR -> nativo
b) Interpretada por um interpretador LLVM-IR
c) Compilada em tempo de execução por um interpretador JIT.
d) etc. <- o que a sua imaginação permitir.

O bacana desse projeto é que eles focaram em dois aspectos: portabilidade e otimização.

Um exemplo de uma tecnologia que usa isso é o Portable Native Client Executable do Google Chrome: você pode estar rodando o google chrome em 32 bits no windows, mac, linux, em Intel x86, ou nativo em 64 bits (x86-64) onde há port para tal (acho que exceto o windows, que mesmo neste caso roda em 32 bits, as demais arquiteturas), ou até no smartphone com processador ARM: quando o goole chrome baixa um executável portável (ele roda como uma espécie de plugin), ele internamente recompila (Just in time ou Ahead of time) para a arquitetura nativa e carrega como uma biblioteca, dando acesso a uma montanha de recursos. Como isso tudo roda numa sandbox (na verdade é uma sandbox dentro de outra, se lembro bem), a biblioteca sequer tem acesso a chamadas de sistema, embora rode código nativo. O executável portável usa LLVM-IR.

Se além de abstrair a arquitetura (ARM vs MIPS por exemplo) você quiser mascarar a API de baixo nível específica a cada µC (cada um usa uma forma de acessar os periféricos de porta serial, por exemplo), terá que criar uma API específica para isso. Não é muito diferente do que faz a maioria dos ports de RTOS, como o FreeRTOS.

Neste sentido tbm dê uma olhada no projeto µC-LUA, que basicamente faz a mesma coisa (não é a implementação mais linda que já vi na vida, mas funciona), mas usa um interpretador p/ linguagem Lua.

São bons pontos de referência para refinar tua ideia, ainda que você opte por algo completamente diferente.

Muito obrigado pelas indicações polesapart, achei bem interessante o Projeto Lua.
Quanto ao LLVM, eh gigante e estou estudando também.

Abraço


Enviado do meu iPhone usando Tapatalk

Pelo amor de Deus, longe de mim que me interprete mal.

Más, a cada ano que passa eu preciso e me aprofundo mais no núcleo de RTLOS, e Linux, e até mesmo aprendendo novas coisas com o ANSI C.

E a ideia sua é criar uma pseudo linguagem, orientada a objetos virtuais gráficos, onde cada qual terá o seu object inspector etc etc ?
Ou seja, fazer uma abstração total do Target !?

Hoje em dia, cada vez menos vejo pessoas aprendendo cada vez menos sobre muito mais coisas !!
Pessoas que não sabem nem mesmo interpretar a explicação de pseudo código estruturado em curso de engenharia !!

E você meu amigo, quer criar algo para jogar o nível de conhecimento ainda mais para baixo ?


Que tal criar um NET RULES digamos assim, onde de um lado fica a sua idéia, e do outro lado fica a pessoa, onde será necessário ela estudar aprender e entender como o target funciona, e desta forma ir aumentando uma biblioteca, e fazendo reaproveitamento de código em caso de ASM para pic, 51, arm, etc...

Me perdoe pela critica, mais eu fico muito triste quando vejo alguém que paga 1300R$ por mês de curso de engenharia, vir me pedir ajuda para entender como funciona um pseudo código, e pra eu explicar para ele colocar no trabalho qual a diferença principal entre linguagem de baixo e alto nível !!!


ABÇS !! E da uma engordada na sua idéia !!

Fabim,

Até onde entendi a ideia do colega, não se trata disso. Ao menos não precisa se tratar: Se você dar uma olhada no clang do LLVM e no Portable Native Executable do chrome, vai ver que o grau de dificuldade e a ordem de complexidade da abstração não diferem muito do que você está acostumado a encontrar no hardware nativo. Você pode continuar programando em C ou C++, e a linguagem NÃO será um subset ou simplificação (a menos que isto seja desejado).

*Se* e somente *se* o desenvolvedor de uma plataforma destas tiver um bom trabalho de composição das APIS, ele pode adicionalmente criar um *mínusculo* HAL (Hardware Abstraction Layer) que permita fazer o seguinte: Ao invés de você usar a API especializada, você usa uma genérica, e a plataforma a traduz para a API específica ao µC. Por exemplo, você usa uma certa rotina para programar UARTs e controladores de IRQ, ao invés de passar horas estudando o datasheet do novo µC da fabricante marciana que resolveu usar um Cortex-M3 mas por qualquer razão usou periféricos proprietários... (em verdade, *você* vai ter que fazer isso, mas uma vez só. Quem usar sua plataforma não vai precisar fazer isso. É muito diferente trabalhar em grupo do que individualmente, pois não dá pra fazer pipeline com um estágio só ).

Eu nunca cheguei neste grau de abstração, mas meu firmware é geralmente escrito com portabilidade em mente desde o começo. Recentemente adaptei drivers de periféricos do lpc17xx para o lpc213x, e como já usava uma série de macros/funções de alto nível, alterar o firmware para rodar em uma placa legado foi questão de algumas horas de trabalho e testes, ao invés de dias ou semanas, como normalmente seria o caso.

fabim escreveu:Pelo amor de Deus, longe de mim que me interprete mal.

Más, a cada ano que passa eu preciso e me aprofundo mais no núcleo de RTLOS, e Linux, e até mesmo aprendendo novas coisas com o ANSI C.

E a ideia sua é criar uma pseudo linguagem, orientada a objetos virtuais gráficos, onde cada qual terá o seu object inspector etc etc ?
Ou seja, fazer uma abstração total do Target !?

Hoje em dia, cada vez menos vejo pessoas aprendendo cada vez menos sobre muito mais coisas !!
Pessoas que não sabem nem mesmo interpretar a explicação de pseudo código estruturado em curso de engenharia !!

E você meu amigo, quer criar algo para jogar o nível de conhecimento ainda mais para baixo ?


Que tal criar um NET RULES digamos assim, onde de um lado fica a sua idéia, e do outro lado fica a pessoa, onde será necessário ela estudar aprender e entender como o target funciona, e desta forma ir aumentando uma biblioteca, e fazendo reaproveitamento de código em caso de ASM para pic, 51, arm, etc...

Me perdoe pela critica, mais eu fico muito triste quando vejo alguém que paga 1300R$ por mês de curso de engenharia, vir me pedir ajuda para entender como funciona um pseudo código, e pra eu explicar para ele colocar no trabalho qual a diferença principal entre linguagem de baixo e alto nível !!!


ABÇS !! E da uma engordada na sua idéia !!

Beleza fabim?

De nenhuma maneira minha intenção é facilitar a vida dos desenvolvedores, estou colocando em anexo minha proposta de desenvolvimento, e abaixo vou tentar clarear um pouco o objetivo dela:

Imagina você, fabim, desenvolveu um CLP! show de bola, com seu super conhecimento em Linux, RTLOS e ainda por cima programado em C! Para isso, utilizou o LPC 2368, com o código todo estruturadinho, para ler entradas, acionar saídas, escrever no display...
Eis que surge sua primeira aplicação, vai automatizar a lógica de uma pequena máquina com seu CLP! La vai você, com o código bem estruturado, e faz a lógica da maquininha!
Mas não é que seu CLP ficou bom mesmo! todo mundo agora quer usar ele pra automatizar as máquinas, você cria inúmeras lógicas para inúmeros clientes e ganha uma bela grana com isso!

Só que o tempo passa, o LPC2368 é descontinuado ou você descobre uma maneira de reduzir custo colocando um ARM 0 por exemplo... E eis que você faz um upgrade no seu CLP, deixando-o mais barato, mais bonito e mais esperto e aposenta o velho 2368!

Oque fazer se aquele seu primeiro cliente ligar pra você pedindo mais um CLP, ou uma peça de reposição? refazer a lógica para o ARM 0 que usa outra estrutura de registradores? É o que resta!

Fim.

Minha proposta é criar um código intermediário, onde o seu cliente que não é um profundo conhecedor de C, Linux ou RTLOS possa fazer a lógica, em leader, fluxograma, blocos ou qualquer outra linguagem e converter para esse código intermediário.
Esse código intermediário será interpretado por uma maquina virtual que conhece os periféricos do LPC2368.
Quando você resolver trocar o microcontrolador, simplesmente desenvolve a máquina virtual para esse novo e eureka! os códigos das lógicas antigas vão rodar bonitinho nesse novo CLP!

Espero não ter criado mais confusão com essa explicação.

Abraço e muito obrigado pelo comentário! Já ajudou pra me mostrar que não estou sendo tão claro como deveria.

Jonas