ASM51

Ola pessoal,

Tenho pouco tempo que comecei a estudar o PIC, de lá pra cá foi uma luta des de fazer a cender e piscar um LED kkk

Conseguir escrever no LCD, escrever na serial e ler com o Hyperterminal do Ruwindows, ah detalhe ainda naum conseguir ler na serial do PIC, mas vamos chegar lah.

O meu grande problema hoje é entender como funciona o "thread" que pelo que li e é o que tô precisando é de ser possivel ter um programa multi tarefa, onde posso ler e tratar um bit ao mesmo tempo de outro ..

Gostaria que se possivel me ajudassem nessa...

Des de já agradeço...

rodrigoadachi,

Até onde sei, o PIC faz ou uma coisa ou outra. Você está escrevendo em assemble ou C?

Abraços,
Fábio.

Estou escrevendo em C.

Cara sei q ele faz uma coisa ou outra mas andei lendo algo sobre token ou algo do tipo que ele faz um ciclo de leitura dai da a impressão que é multitarefa.

Por exemplo eu quero soar um beep em uma saida utiliza varios delays dai meu programa todo pararia por causa de um beep?

Talvez eu naum esteja sabendo expresar o q eu tô querendo mas eh tipow isso kk

Valew...

xará.
Tem um detalhe bem antigo, que era chamado de kernel for pic.
É tipo um mult tarefa, com função em interrupção, até mesmo um processador de grande porte faz apenas uma coisa pr vez, o que ajuda ele é o DMA e as IDE´s..
Tipo imagina você gerar interrupção a cada 1mS, igual no pc.
Nestes 1mS, você vai para uma sub, que sai perguntando pra todo mundo se alguem esta precisando de algum processamento, se sim seta um um flag e return;
lá no main ele sai testando os flag´s e executando e sai novamente vai para o condicional de baixo e assim por diante.

Eu sinceramente, com 20mhz em um 877 acho isso totalmente inviável..

Se fosse um 4550 em 48mhz "12mips" ja ia melhorar um tanto bom..

ou seja rodrigoadachi, esquece.. ou você parte para um microcontrolador macho com dma e tudo mais, ou esquece..

fabim

Deu pra entender..



Me fala! Qual PIC vc me recomenda...

Rodrigo, o PIC não é multitarefa. Porém, todos os processadores x86 antes dos dual core também não são multitarefa. O esquema do multitarefa é todo feito em software.

Um esquema muito usado é usar e abusar de interrupções de timer.
Por exemplo, no teu caso, você pode ligar o beep, configurar o timer para gerar uma interrupção depois do tempo de beep que você quer. Daí teu firmware continua, e quando gerar a interrupção, a ISR (interrupt service routine) desliga o beep.

Um kernel como o linux faz mais ou menos isso, com a diferença que o timer gera a int, e o kernel muda de tarefa, e quando estoura de novo, pula prá outra tarefa e assim por diante. Pro usuário, parece que tá fazendo milhares de coisas simultaneamente.

Nota: você consegue fazer isso com qualquer PIC, rodando em qualquer clock.

que eh isso fabim, nao desanima o guri nao... a sun2 com um 68010 de 1MIPS rodava unix, fazia multitarefa preemptiva, suportava memoria virtual e ainda controlava display grafico e interface ethernet. ainda hoje existem produtos novos com 68000 rodando nessa faixa de performance, com bem pouca memoria, mas rodando algum RTOS preemptivo numa boa.

o problema nem eh performance, o grande problema eh limitacao de memoria! isso pq vc precisa trocar contextos entre uma task e outra, entao nao dah para ter muitas tasks pq nao tem onde armazenar os contextos.

eu acho que existem alternativas quanto ao consumo de memoria... eu fiz uma implementacao totalmente experimental de um pequeno RTOS nao-preemptivo (para ficar portavel), com escalonamento cooperativo feito por passagem de mensagens:

http://framework.sourceforge.net/pics/hc908rtos/trunk/

testei em um mcu com 4KB de FLASH e 384 bytes de SRAM e comecei a ficar meio que sem memoria FLASH nesta altura, rodando uma task para a UART, uma para o RTC, um pequeno shell de console e uma aplicacao simples ativada dinamicamente pelo shell.

em essencia, a unica diferenca para uma multitafera preemptiva eh que um bug em uma task *pode* crashear o sistema operacional inteiro... mas para isso existe watchdog. e claro, desenvolver para mcu requer gente mais gabaritada e com mais conhecimento, nao aqueles pacotes de bolacha que desenvolvem software bugado para windows!

fabim escreveu:xará.
Tem um detalhe bem antigo, que era chamado de kernel for pic.
É tipo um mult tarefa, com função em interrupção, até mesmo um processador de grande porte faz apenas uma coisa pr vez, o que ajuda ele é o DMA e as IDE´s..
Tipo imagina você gerar interrupção a cada 1mS, igual no pc.
Nestes 1mS, você vai para uma sub, que sai perguntando pra todo mundo se alguem esta precisando de algum processamento, se sim seta um um flag e return;
lá no main ele sai testando os flag´s e executando e sai novamente vai para o condicional de baixo e assim por diante.

Eu sinceramente, com 20mhz em um 877 acho isso totalmente inviável..

Se fosse um 4550 em 48mhz "12mips" ja ia melhorar um tanto bom..

ou seja rodrigoadachi, esquece.. ou você parte para um microcontrolador macho com dma e tudo mais, ou esquece..

fabim

Oi Fabim
Até uma tartaruga é multitarefa.
Come alface e vai andando, devagarinho mas vai. Quando se vê ja esta bem longe.

.

Então...

Como o xultz mencionou, não podemos confundir multitarefa, com multicore.

Multitarefa, nada mais é do que um SO, em cima do qual os módulos do programa serão executados com alocações de tempo e gerenciamento de memoria distintas.

POREM, certamente um 16F877 terá muito trabalho para fazer isso, haja visto à pouca memoria RAM disponível, além da pilha insignificante de 8bytes.

+++

Entaum cm o 16F877A dá neh? Mas depende da aplicação neh?

Poderia me dar um exemplo de como posso fazer isso?

Em C por favor kk ( Num sou muito fã de ASM naum kk)

Eu uso o PCW

Ola,

Eu aconselho voce usar JAVA para PIC para implementar threads!

Funciona bem.

T+

TCPIPCHIP

PS: para familia 18, ok ?

Ja fiz varios projetos utlizando o 16F877A rodando em mult-tarefa. Fiz um kernel q utilizo em todos os processadores q eu trabalho. Cara em todas as aplicações simples e complexas o PIC conseguio rodar sem problemas , entaum vamos acabar com este MITO q o PIC16F877 no suporta ou coisa deste tipo. Depende muito da sua aplicação.Agora se sua aplicação vai existir varios processos ai SIM o pic16F877 não vai dá conta, por conta de memoria e até mesmo tempo de processamento.. Tudo depende da sua aplicação.

o dureza eh fazer caber a maquina virtual do java nele neh.

tcpipchip escreveu:Ola,

Eu aconselho voce usar JAVA para PIC para implementar threads!

Funciona bem.

T+

TCPIPCHIP

PS: para familia 18, ok ?

O tcpipchip colocou corretamente.
Veja, não quer apenas um kernel ele quer threads.

Agora fica mais difícil sim fazer isto em um pic mesmo 18F. A não ser que você esteja confundindo e querendo apenas uma distribuição de tarefas em nível de kernel e não de software (threads).
Se for um kernel preemptivo restrito dá tranquilo num 18F, agora isto e mais um "taskeamento" no software num pic é dose sim.

Voce nao necessita por uma maquina virtual dentro do PIC, mas pode programar em JAVA para ele sem problema algum. É claro que nesta historia entra um tradutor de bytecode para a linguagem nativa do PIC.
Traduz certinho, classes, objects, heranca, polimorfismo, threads e principalmente exceções.
T+
TCPIPCHIP

PS: rodo num PIC18F6627