Marcelo Samsoniuk escreveu:
por outro lado, o que temos ainda eh um emaranhado de funcoes chamadas diretamente de um loop principal e algumas interrupcoes. pensando em algumas melhorias operacionais, sera que conceitos de RTOS usados em microcontroladores maiores de 16 e 32 bits sao aplicaveis em microcontroladores menores de 8 bits ?
aparentemente sim, a ideia seria extender alguns conceitos de modulos (viram tasks) e interfaces (fila de mensagens)... mas isso eh mais para frente! eu implementei ateh o momento um sisteminha de escalonamento de processos baseado em uma queue de mensagens. ateh agora esta funcionando relativamente bem, atingindo 5000 mensagens/segundo em um HC908 de 2.5MHz.
provavelmente conforme for colocando mais e mais tasks, a performance deve cair... ou sera que nao ?
Hmm eu li a thread meio por cima, mas acho que como você sugeriu o conceito de filas de mensagens e máquinas de estado mais atrás, e agora a idéia de algo escalavel mesmo pra sistemas pequenos, eu lembrei de um conceito bem interessante que tenho estudado nas horas vagas: um "nano" rtos orientado ao processamento de eventos, através de máquinas de estado recursivas (embora a minha implementação nem seja recursiva hehe).
A idéia original eu descaradamente emprestei de uma plataforma comercial. O nome da encrenca é quantum platform, http://www.state-machine.com/products/index.htm
A idéia deles é muito bacana, voce tem um loop principal que despacha mensagens entre tarefas; Só que estas tarefas não seguem o conceito tradicional: todas elas tem prioridades diferentes. Quando uma tarefa de prioridade superior tenta enviar uma mensagem a uma inferior, a mensagem é colocada numa fila. Quando é inverso, a tarefa superior é ativada para tratar a mensagem, sincronizadamente. Cada mensagem é como um input para uma maquina de estados, e cada passo é processado de modo não preemptivo. O interessante é que a implementação prevê, opcionalmente, um trocador de contexto preemptivo: as interrupções tem prioridades superiores a todas as tarefas, mas ao retorno da interrupção, caso uma tarefa superior a que estava rodando recebeu uma mensagem (ex. do handler de irq), ela é ativada no lugar.
Estas ativações não ocorrem como um salvamento de contexto completo: como uma tarefa superior executa uma mensagem até o final e retorna (ou seja, deixa de existir) para a tarefa inferior, o custo é apenas um ajuste na pilha para o retorno da função e a própria chamada de função. O fato de usar uma só pilha é uma facilidade muito grande para sistemas embarcados onde cada byte de RAM vale ouro.
Eu fiquei surpreso como esta metodologia é produtiva.
A escalabilidade desta solução também é muito boa, o calcanhar de aquiles é que como ela não suporta threads de verdade, não há aproveitamento nativo de múltiplos processadores, quando rodar isto numa plataforma mais avançada. Mas isto pode ser facilmente contornado com pequenas alterações no sistema de envio de mensagens e implementando threads reais como uma camada mais acima, do ponto de vista da abstração, encapsulando um número de "objetos ativos" (o nome que eles dão para estes pseudo-processos) relacionados entre si dentro de threads que seriam totalmente preemptivas e independentes entre si, trocando mensagens com uma fila protegida por semáforos ou outros mecanismos de contenção. O que seria muito escalável, já que um grande problema da maior parte das implementações de programação estruturada usando threads é o abuso de semáforos, grande parte do tempo de cpu de um sistema com muitas threads é perdido fazendo spin locking e há um impacto de I/O muito grande por causa do acesso atômico a memória, que ignora o cache ou força um flush, etc.
Eu tou brincando com uma implementação própria deste conceito, mas ainda não cheguei ao ponto de integrar multiplas threads. O que eu fiz roda em um microcontrolador (qualquer, se duvidar até um pic) e no linux, de forma bastante reduzida, pois manipular o contexto no linux usando sinais não deu muito certo, então a parte preemptiva não funciona
Em cima disto, seria relativamente fácil criar APIs para gerenciar drivers e dispositivos de I/O em geral, usando troca de mensagens, quase exatamente da forma que você sugeriu nesta thread.
Se alguém mais tiver interesse em brincar com este conceito, eu tenho até um projeto aberto na sourceforge, eu só não postei nenhum código pra lá ainda por quê ainda está meio primitivo e por quê como eu descaradamente copiei as *idéias* da quantum platform, embora não tenha usado código, ainda quero averiguar como fica do ponto de vista legal, pois a idéia é colocar a coisa em licença LGPL ou BSD e não ser processado mais tarde por nada disto
