Conceito Multi-Tarefas !!!!!!

[mega.rod]

Ola pessoal, ouvi falar de um tal de "Conceito Multi-Tarefa" que consiste em uma forma diferente de escrita do programa possibilitando a execução de varias tarefas de forma simultânea que é utilizado nos Microcontroladores PIC, eu mesmo nunca tinha ouvida nada a este respeito, até conversei com o Engenheiro da empresa que compro Freescale mas ele parece não conhecer muita a fundo do assunto...

Alguns conhece algo a respeito ?

Fico no aguardo...
Obrigado...

[mastk]

imagine o seguinte:

Seu programa esta rodando com um PC (contador de programa).

Periodicamente acontece uma interrupção que salva o PC e execulta a rotina de interrupção. Nessa rotina será selecionada a proxima tarefa. Um outro PC e assim vai...

Basicamente, não sei muita coisa sobre...

[Fábio Pereira]

Multi-tarefa é um conceito normalmente relacionado a sistemas operacionais.

Existem basicamente dois tipos de multi-tarefa:

Cooperativa: o sistema operacional não tem domínio completo sobre as tarefas, cabe a cada tarefa chamar o sistema operacional para efetuar a troca de contexto e a execução de uma nova tarefa.

Preemptiva: o sistema operacional (através de um agendador de tarefas) executa cada tarefa por um determinado período de tempo. Uma vez ultrapassado o tempo, o agendador de tarefas suspende a tarefa em execução e executa a próxima tarefa na fila de execução.

Lembrando: ambos os conceitos se utilizam do time-sharing da CPU.

T+

[Wagner de Queiroz]

o exemplo da interrupção é o mais proximo que conheco de multitarefa num mcu, pq o mcu é monotarefa, a nao ser que voce faça um escalonador de tarefas onde vc conta o tempo, passa o controle para um processo, depois de findo este tempo, passa o controle da cpu para outro processo.
De toda forma o escalonador de processos tb é um processo rodando na cpu, ou seja,

Programa A
Programa B
Programa C
Escalonador

O escalonador deixa uma fatia de tempo igual para cada Programa, digamos que 100 ms. Durante 100ms, o programaA roda, findo este tempo, o escalonador congela o PRograma A, e passa para o Programa B executar, isso vai ocorrendo até vencer o tempo de B, dai o escalonador iria para o Progrma C. O processo iria se repetindo por tempo indefinido.

Problemas disso num MCU pequeno tipo HC08.

Vc precisa de uma pilha distinta para cada Programa.
Vc precisa arrumar um jeito do escalonador ser o dono da bola, pois se B nao entregar o controle para o escalonador (Diga-se Multitarefa Cooperativa) os outros programas se lascam.

O escalonador tb vai precisar de uma pilha.

To certo ou to Errado?

[pbernardi]

Não vejo muita lógica em usar multitarefa em uC de 8 bits. Acho que o mais próximo que dá pra implementar sem sofrer muito eh um timer otimizado para não usar os delay() da vida, e otimizar as chamadas de funções. Implementar mais do que isso, geralmente tem um custo de código muito grande, como o Wagner explicocu.

Se quiser ir mais a fundo no assunto, acho que o ideal é usar um uP ou uC de 32 bits, como um ARM ou um Coldfire. Dá pra instalar um uClinux e brincar bastante.

[Fábio Pereira]

Ainda acredito que a melhor solução para uma pseudo-multi-tarefa é a utilização de máquinas de estado para controlar os processos de uma aplicação.

Desta forma, basta inserir estados "wait" nas máquinas quando for necessário aguardar um tempo naquele processo.

Eu utilizo muito este conceito nos meus projetos e o meu último livro também trás alguns exemplos.

T+

[EDSONCAN]

Somente para ilustrar a discussão a unica vez que fiz um multitarefa em 8 bits foi em 89c52.
Era um PABX que usava um Kernel que escalonava o processo em função de uma tabela de prioridade e de recursos disponiveis x necessarios.
Fone fora do gancho era um processo, pois tinha que ler telefones decadicos e telefone DTMF, portanto o recurso MT8870, tinha que estar disponivel.
Ao encaminhar uma ligação para um ramal o recurso ramal tinha que estar disponivel e assim por diante.

SDS
Edson

[msamsoniuk]

depende muito do que vc quer fazer e dos recursos q vc tem disponivel, em principio, existem 2 formas principais de multi-tarefa:

preemptiva: uma interrupcao de hardware para a execucao da tarefa atual e eh forcado um escalonamento para a proxima tarefa, de modo que uma tarefa soh roda em uma determinada fatia de tempo. exemplos: unix de forma geral.

cooperativa: as tarefas rodam tranquilamente ateh que precisam de algum recurso do kernel, entao quando o recurso eh chamado eh feito um escalonamento para a proxima tarefa. exemplos: mac os e windows antigos.

normalmente processadores modernos estao partindo para a primeira opcao, que eh mais avancada, mas a segunda opcao eh interessante para casos mais simples. bom, isso para processadores que podem sustentar multiplos contextos diferentes, ou seja, que possuem muita memoria. no caso de um microcontrolador, com pouca memoria, eh mais interessante manter poucos contextos, de preferencia apenas dois: um loop principal e uma interrupcao. entao vc poderia pensar em 2 abordagens mais extremas:

- tudo no loop principal: todas as tarefas sao disparadas por um loop principal, que consulta uma queue de eventos e essa queue eh alimentada por interrupcoes curtas e rapidas, que podem ser chamadas normalmente enquanto uma tarefa esta rodando (se a queue estiver vazia, o sistema esta em idle).

- tudo nas interrupcoes: todas as tarefas sao disparadas por interrupcoes. cada tarefa eh escrita de modo a fazer o que precisa e tentar retornar o mais rapido possivel. enquanto uma tarefa esta rodando, todas as outras interrupcoes estao pendentes e tem que esperar o sistema voltar para idle para rodarem.

qual eh mais vantagem ? depende do caso, vc pode ateh usar um misto das duas coisas, mas a primeira forma eh quase uma multitarefa cooperativa e a segunda certamente eh muito mais simples.

[danielvaz]

No código de soft_uart http://framework.sourceforge.net/hc908s ... 908_uart.c é usado um misto das duas soluções né?

abraços

[mastk]

Ai que tá uma coisa é vc programar pensado em mult-tarefa, outra coisa é um sistema operacional, certo?

Tipo assim, todo mundo se depara com a nescessidade de um software que tem n coisas a serem feitas e organiza como faze-las, como sam descreveu. Tudo num loop principal, interrupção ou misto.

Apartir do momento que se troca de contesto, pode-se chamar isso de sistema operacional, certo? Já que tem essa comada superior, que determina qual é a proxima tarefa a ser realizada. E para a tarefa que esta sendo execultada, tudo fica transparente certo, disso coloca-se esse programa numa região limitada da memoria, não permitindo que esse codigo zoe o sistema, caso de tentar escrever em fora da região permitida. Agora como colocar isso em pratica num 8051 por exemplo

[CCandido]

rodando 2tarefinhas, forum anterior.....
http://www.asm51.eng.br/forum/topic.asp?TOPIC_ID=10809

[mastk]

Sei, mas digo, vc faz isso para facilitar, se para distribuir recurso x tarefa, software corrido para mcu é bem melhor...

[msamsoniuk]

Ai que tá uma coisa é vc programar pensado em mult-tarefa, outra coisa é um sistema operacional, certo?

Tipo assim, todo mundo se depara com a nescessidade de um software que tem n coisas a serem feitas e organiza como faze-las, como sam descreveu. Tudo num loop principal, interrupção ou misto.

Apartir do momento que se troca de contesto, pode-se chamar isso de sistema operacional, certo? Já que tem essa comada superior, que determina qual é a proxima tarefa a ser realizada. E para a tarefa que esta sendo execultada, tudo fica transparente certo, disso coloca-se esse programa numa região limitada da memoria, não permitindo que esse codigo zoe o sistema, caso de tentar escrever em fora da região permitida. Agora como colocar isso em pratica num 8051 por exemplo

na verdade vc teria q pensar em niveis de complexidade.

- pooling: provavelmente eh o primeiro passo para qq um q mexe com uma mcu, o cara simplesmente faz um loop que testa o que ele quer testar e, conforme os resultados, roda tarefas especificas.

- interrupcao: provavelmente o segundo passo para qq um que mexe com uma mcu, o cara pode programar recursos de hw, por exemplo timers, para disparar tarefas especificas, tornando desnecessario o loop anterior.

- interrupcao com queue: quando o negocio comeca a complicar e vc comeca a perder interrupcoes a primeira saida eh atender o mais rapido possivel elas e sair fora. para isso uma solucao eh montar uma queue para processar a interrupcao mais tarde em um loop de eventos, ou seja, essa solucao eh um misto das duas primeiras.

- multitarefa cooperativa: quando um unico loop de eventos nao dah conta, uma saida eh criar multiplos loops de eventos em tarefas a parte, onde a entrada de cada loop de eventos pode ser uma queue de mensagens. quando uma tarefa vai consultar a queue e ela esta vazia, a proxima tarefa eh escalonada. as queues sao alimentadas tanto por interrupcoes quanto tarefas q se comunicam umas com as outras, ou seja, eh uma versao melhor da solucao anterior.

- multitarefa preemptiva: quando as tarefas se tornam longas o suficiente para que a multitarefa cooperativa deixe de funcionar eficientemente, a multitarefa preemptiva resolve o problema alocando fatias de tempo para cada tarefa. obviamente as solucoes anteriores estao embutidas dentro desta.

- virtualizacao: quando os diferentes componentes do sistema se tornam complexos e comecam a interferir fortemente uns com os outros, a solucao eh virtualizar. para isso sao criadas solucoes de virtualizacao que separam as tarefas do kernel, de modo que cada tarefa pensa q tem uma maquina completa para si, mas na realidade ela roda em uma fatia de tempo, com memoria e perifericos virtualizados.

o que muda entre uma e outra eh o grau de complexidade. agora se eh um sistema operacional ou nao, depende. se vc consegue reaproveitar a base e soh adicionar novas tarefas de forma relativamente simples, pode ateh dizer que eh um sistema operacional, mesmo que seja apenas um loopzao para pooling.

nao eh o nivel de complexidade que vai dizer se eh um sistema operacional ou nao, mas sim o nivel de reaproveitamento e utilidade.