Guia CNC Brasil - Tudo sobre CNC, Router, Laser, Torno e 3D Print
ELETRÔNICA / ELÉTRICA => Eletrônica Básica => Microcontroladores => Tópico iniciado por: aguizan em 21 de Junho de 2010, 19:52
-
Senhores,
Sou novato no Forum e também em eletrônica, mas tenho me esforçado muito com o desenvolvimento de um projeto encontrado na internet e que para mim tem sido um verdadeiro desafio. Trata-se de um veículo remotamente controlado. O projeto é bem simples contendo uma placa de controle de motores (três motores) uma placa de comando com Joystick e interruptores de iluminação e comunicação serial entre os dois módulos (comando e controle). Pelas dificuldades encontradas alguns componentes serão substituídos no projeto original e daí a minha dificuldade. Os esquemas do projeto são estes: http://www.ece.uvic.ca/~ece499/2001a/group11/Schematics/rov_tx.jpg
http://www.ece.uvic.ca/~ece499/2001a/group11/Schematics/rov_rx.jpg
Os softwares usados são: http://www.ece.uvic.ca/~ece499/2001a/group11/Software/rov_tx.asm
http://www.ece.uvic.ca/~ece499/2001a/group11/Software/rov_rx.asm
Minha idéia é substituir o Pic do projeto pelo PIC16f628A.
Alguém pode me dar uma ajuda. Desde já agradeço.
-
Olá Anderson,
Apesar de ainda encontrar o PIC16F84 (que é antigo mais caro), é fácil portar o software do processador PIC16F84 para PIC16F628.
E o PIC12C671, que possui conversor A/D? Acho melhor usá-lo, pois ainda se encontra no Brasil.
-
Boa Noite Gil,
Obrigado pelo pronto atendimento as minhas dúvidas.
Com relação ao PIC12C671, aconselharan-me a substituição pelo PIC12F675, por ser memória flash e mais novo, o que acha ?
-
Anderson,
Boa Noite Gil,
Obrigado pelo pronto atendimento as minhas dúvidas.
Com relação ao PIC12C671, aconselharan-me a substituição pelo PIC12F675, por ser memória flash e mais novo, o que acha ?
É melhor, o PIC12F675 atende também no quesito conversor A/D com 4 entradas.
-
minilathe
mestre, a algum tempo não lhe importuno, coisa que o farei agora!! ;D
apesar de me virar em programação com PIC, uma coisa que eu nunca tentei foi modificar o microcontrolador de um firmware já existente (diga-se apenas o .hex) por exemplo mudar um firmware originalmente compilado para um PIC16F84 para um PIC16F628 ?
o mestre sabe me dizer se isso é possível sem converter em assembly?
abrax!
-
Olá Blackmore,
uma coisa que eu nunca tentei foi modificar o microcontrolador de um firmware já existente (diga-se apenas o .hex) por exemplo mudar um firmware originalmente compilado para um PIC16F84 para um PIC16F628 ?
o mestre sabe me dizer se isso é possível sem converter em assembly?
Não vou afirmar categoricamente que não funciona, nunca testei isso, porém...
Apesar do PIC16F628 possuir mais recursos e uma estrutura bastante similar ao PIC16F84, não devem ser 100% compatíveis em termos de linguagem de máquina, pelas razões que exponho a seguir. Lembrando que o códigos hex é uma representação hexadecimal textual e padronizada do código de máquina, e portanto, não seriam 100% iguais.
A principio, eu acho que o software do PIC16F84 pode ou não rodar no PIC16F628, a depender de como o software funciona e quais instruções utiliza.
Um aspecto básico são os códigos de máquina associados a cada instrução, nunca parei para comparar se os códigos de máquina são iguais para instruções similares no PIC16F84 e PIC16F628. Ou seja, se para fazer a mesma coisa (exemplo: carregar o acumulador com uma constante) é usado o mesmo código de máquina (hex).
Outro aspecto é que, devido a estrutura de páginas dos registradores serem diferentes, alguns registradores requerem ser acessados numa página ou noutra e os endereços dos registradores também não são os mesmos. O que gera códigos de máquinas (hex) diferentes.
Essas diferenças também valem para os bits fusíveis (de proteção de memória de programa, habilitação de tipo de clock, ...).
-
Anderson,
Boa Noite Gil,
Obrigado pelo pronto atendimento as minhas dúvidas.
Com relação ao PIC12C671, aconselharan-me a substituição pelo PIC12F675, por ser memória flash e mais novo, o que acha ?
É melhor, o PIC12F675 atende também no quesito conversor A/D com 4 entradas.
Correto, então quanto aos pics, tanto da placa de comando como da placa de controle, ficam assim definidos. PIC12F675 para controle e PIC16F628A para comando. Agora preciso fazer alterações no software por conta desta mudança correto ? Que passos seguir ?
-
Anderson,
Correto, então quanto aos pics, tanto da placa de comando como da placa de controle, ficam assim definidos. PIC12F675 para controle e PIC16F628A para comando. Agora preciso fazer alterações no software por conta desta mudança correto ? Que passos seguir ?
Primeiramente baixe e instale o MPLAB em seu computador, depois carregue e teste (passo a passo) individualmente cada programa com os CIs originais de manera simulada. Os programas do site poderiam estar errados, não é??
Depois teste cada programa com o respectivo chip que será usado no lugar (PIC12F675 e PIC16F628). Alguns ajustes nos programas serão necessários pelas razões que expus anteriormente.
Mas tem que abrir e analisar e entender cada programa, entender o programa dá trabalho, mas é util, para aprender e principalmente, se for melhorar o sisteminha. Após isso, fazer as alterações necessárias em cada programa, analisando as instruções que diferem devido aos chips serem diferentes. Mas já vi que os programas sao pequenos e a análise será simples.
O modo simulado do MPLAB ajudará nos testes.
Depois também pode simular no Proteus, aí a simulação pode misturar SW e HW. Se tudo funcionar corretamente, é só montar.
-
Anderson,
Correto, então quanto aos pics, tanto da placa de comando como da placa de controle, ficam assim definidos. PIC12F675 para controle e PIC16F628A para comando. Agora preciso fazer alterações no software por conta desta mudança correto ? Que passos seguir ?
Primeiramente baixe e instale o MPLAB em seu computador, depois carregue e teste (passo a passo) individualmente cada programa com os CIs originais de manera simulada. Os programas do site poderiam estar errados, não é??
Depois teste cada programa com o respectivo chip que será usado no lugar (PIC12F675 e PIC16F628). Alguns ajustes nos programas serão necessários pelas razões que expus anteriormente.
Mas tem que abrir e analisar e entender cada programa, entender o programa dá trabalho, mas é util, para aprender e principalmente, se for melhorar o sisteminha. Após isso, fazer as alterações necessárias em cada programa, analisando as instruções que diferem devido aos chips serem diferentes. Mas já vi que os programas sao pequenos e a análise será simples.
O modo simulado do MPLAB ajudará nos testes.
Depois também pode simular no Proteus, aí a simulação pode misturar SW e HW. Se tudo funcionar corretamente, é só montar.
Correto, então assim que tenha novidades informo. Pelo visto terei bastante trabalho e estudo pela frente. Grato pelas informações.
-
Anderson,
Correto, então quanto aos pics, tanto da placa de comando como da placa de controle, ficam assim definidos. PIC12F675 para controle e PIC16F628A para comando. Agora preciso fazer alterações no software por conta desta mudança correto ? Que passos seguir ?
Primeiramente baixe e instale o MPLAB em seu computador, depois carregue e teste (passo a passo) individualmente cada programa com os CIs originais de manera simulada. Os programas do site poderiam estar errados, não é??
Depois teste cada programa com o respectivo chip que será usado no lugar (PIC12F675 e PIC16F628). Alguns ajustes nos programas serão necessários pelas razões que expus anteriormente.
Mas tem que abrir e analisar e entender cada programa, entender o programa dá trabalho, mas é util, para aprender e principalmente, se for melhorar o sisteminha. Após isso, fazer as alterações necessárias em cada programa, analisando as instruções que diferem devido aos chips serem diferentes. Mas já vi que os programas sao pequenos e a análise será simples.
O modo simulado do MPLAB ajudará nos testes.
Depois também pode simular no Proteus, aí a simulação pode misturar SW e HW. Se tudo funcionar corretamente, é só montar.
Correto, então assim que tenha novidades informo. Pelo visto terei bastante trabalho e estudo pela frente. Grato pelas informações.
Bom, estou com algumas dúvidas aqui. O projeto funciona da seguinte forma:
O joystick, quando movido:
- para frente == > liga dois motores simultaneamente ==> movimenta o rov para frente
- para trás ==> liga os dois motores para trás ==> movimenta o rov para trás
- para lado esquerdo ou direito ==> liga os dois motores em direções opostas ==> movimento de rotação em torno do próprio eixo do rov - curva fechada.
- em diagonal ==> liga somente um motor, esquerdo ou direito ==> movimenta o rov em curva aberta.
além do joystick um potenciometro para profundidade e botão para luz e câmera.
todas essas informações são transmitidas serialmente por cabo até a placa de contrôle dos motores, que fica no rov.
Olhando para o software de controle do joystick entendo que o primeiro byte usa os bits 0,1 e 2 para motor da direita, 3,4 e 5 para motor da esquerda e 6 e 7 para iluminação ou servo, correto.
O controle é feito pelo joystick que ao ser acionado produz uma variação de tensão que é transmitida ao circuito, essa tensão é transformada em um sinal digital e assume os valores a serem transmitidos correto ? Se os valores a serem passados aos bits são zeros ou uns, porque tenho três bits para direita e três para a esquerda.
-
no fim do ano passado fiz um trabalho bem semelhante, mas para motor DC a velocidade controlada por PWM. o sentido e direção através de 2 potenciometros ... para a transmissão eu utilizei um modulo de RF encontrado no ML ... ficou bem interessante ... pena q montei apenas em protoboard, devido a falta de tempo.
-
Anderson,
Olhando para o software de controle do joystick entendo que o primeiro byte usa os bits 0,1 e 2 para motor da direita, 3,4 e 5 para motor da esquerda e 6 e 7 para iluminação ou servo, correto.
O controle é feito pelo joystick que ao ser acionado produz uma variação de tensão que é transmitida ao circuito, essa tensão é transformada em um sinal digital e assume os valores a serem transmitidos correto ? Se os valores a serem passados aos bits são zeros ou uns, porque tenho três bits para direita e três para a esquerda.
Na verdade, os tres bits são para definir o sentido de rotação e a velocidade de cada motor, conforme o trecho do comentário do programa que recortei a seguir.
;********************************************************************************
;* POSJUMP -- Joystick Data to Motor Speed Jump Table *
;********************************************************************************
; Uses first six bits of received joystick position data X and Y (64 unique
; positions) to reference and return a left and right motor direction/speed
; combination as:
; ___7________6______ __5________4_______ _3________2________ 1________0___
; |_______||_______||_______||_______||_______||_______||_______||_______|
; 0 0 \DIR_L/ \-- SPEED_L ---/ \DIR_R/ \-- SPEED_R ---/
;
; Note that the joystick position grid contains a one position dead-zone about
; each axis. Example: X=011,Y=000 is identical speedwise as X=011,Y=100 (in
; both cases speed Y is zero).
-
Anderson,
A título de comentário e por falar em portar o software do PIC 84 para 628, olhando o software do receptor, percebi que a UART é implementada em software, se for usar o 628 poderá economizar muitas linhas de programa, otimizando bastante o código, visto que o 84 não possui UART. Mas isto não é indispensável.
-
... uma coisa que eu nunca tentei foi modificar o microcontrolador de um firmware já existente (diga-se apenas o .hex) por exemplo mudar um firmware originalmente compilado para um PIC16F84 para um PIC16F628 ?
o mestre sabe me dizer se isso é possível sem converter em assembly?
E como saberia onde e o que modificar ?
Bom exercício para masoquistas ... ;D
Nah, no mínimo tem que encarar o disassembly ... o que dá pra fazer de mais prático sem desmontar o prog é, por exemplo, localizar strings com um editor e alterá-las.
-
Usando o programa MPASMWIN no asm. do RX deu 17 conflitos e foram eliminados mudando sómente definição do processador de f84 para f628A e o inicio sa memoria de 0x0C para 0x20
;***************************************
;* Processor definition and configuration *
;**************************************
; Clock = 4MHz external resonator
LIST P=16F628A
#include "P16F628A.inc"
*************************************************
;* Variable declaration *
;**********************************************
cblock 0x20
-
Anderson,
Olhando para o software de controle do joystick entendo que o primeiro byte usa os bits 0,1 e 2 para motor da direita, 3,4 e 5 para motor da esquerda e 6 e 7 para iluminação ou servo, correto.
O controle é feito pelo joystick que ao ser acionado produz uma variação de tensão que é transmitida ao circuito, essa tensão é transformada em um sinal digital e assume os valores a serem transmitidos correto ? Se os valores a serem passados aos bits são zeros ou uns, porque tenho três bits para direita e três para a esquerda.
Na verdade, os tres bits são para definir o sentido de rotação e a velocidade de cada motor, conforme o trecho do comentário do programa que recortei a seguir.
;********************************************************************************
;* POSJUMP -- Joystick Data to Motor Speed Jump Table *
;********************************************************************************
; Uses first six bits of received joystick position data X and Y (64 unique
; positions) to reference and return a left and right motor direction/speed
; combination as:
; ___7________6______ __5________4_______ _3________2________ 1________0___
; |_______||_______||_______||_______||_______||_______||_______||_______|
; 0 0 \DIR_L/ \-- SPEED_L ---/ \DIR_R/ \-- SPEED_R ---/
;
; Note that the joystick position grid contains a one position dead-zone about
; each axis. Example: X=011,Y=000 is identical speedwise as X=011,Y=100 (in
; both cases speed Y is zero).
Estou fazendo uma confusão aqui: os bits 0 e 1 estão vinculados a velocidade do motor direito podendo assumir valores para stop, low, med e fast. O bit 2 está vinculado a direção de rotação do motor assumindo dois possíveis valores a frente e a ré. Assim ocorre para os seis primeiros bits e o bit 6 e 7 estão vinculados ao servo e iluminação. Então em um byte poderia ter informação simultanea para os três motores, mas por exemplo se eu comando motores a frente, vel med. esse byte ficaria 00100100, o bit 0 e o bit 4 que são os bits responsáveis por stop e low estariam com valor para stop e entrariam em conflito ???
-
Usando o programa MPASMWIN no asm. do RX deu 17 conflitos e foram eliminados mudando sómente definição do processador de f84 para f628A e o inicio sa memoria de 0x0C para 0x20
;***************************************
;* Processor definition and configuration *
;**************************************
; Clock = 4MHz external resonator
LIST P=16F628A
#include "P16F628A.inc"
*************************************************
;* Variable declaration *
;**********************************************
cblock 0x20
Eu rodei o SW no mplab e não encontrei conflitos, mas vou verificar novamente ????
-
Anderson,
A título de comentário e por falar em portar o software do PIC 84 para 628, olhando o software do receptor, percebi que a UART é implementada em software, se for usar o 628 poderá economizar muitas linhas de programa, otimizando bastante o código, visto que o 84 não possui UART. Mas isto não é indispensável.
Isto é ótimo. Estou estudando um bocado para poder desenvolver esse projeto. Encontrei aqui no Guia CNC um curso de microcontroladores e estou "mandando brasa".
-
Anderson,
Estou fazendo uma confusão aqui: os bits 0 e 1 estão vinculados a velocidade do motor direito podendo assumir valores para stop, low, med e fast. O bit 2 está vinculado a direção de rotação do motor assumindo dois possíveis valores a frente e a ré. Assim ocorre para os seis primeiros bits e o bit 6 e 7 estão vinculados ao servo e iluminação. Então em um byte poderia ter informação simultanea para os três motores, mas por exemplo se eu comando motores a frente, vel med. esse byte ficaria 00100100, o bit 0 e o bit 4 que são os bits responsáveis por stop e low estariam com valor para stop e entrariam em conflito ???
A idéia básica do cicuito é usar 6 bits para controle de movimento do ROV, formando uma "palavra" de comando com 64 opções de movimento, exemplo: frente lento, frente rápido, curva fechada à direita lento, curva aberta à direita rápido, ... Acho que não há conflitos, pois todas as combinações possíveis, e factíveis, estariam previstas.
-
Aguilan
O .asm que coloquei é o já modificado para o f628
Roberto
-
Anderson,
Estou fazendo uma confusão aqui: os bits 0 e 1 estão vinculados a velocidade do motor direito podendo assumir valores para stop, low, med e fast. O bit 2 está vinculado a direção de rotação do motor assumindo dois possíveis valores a frente e a ré. Assim ocorre para os seis primeiros bits e o bit 6 e 7 estão vinculados ao servo e iluminação. Então em um byte poderia ter informação simultanea para os três motores, mas por exemplo se eu comando motores a frente, vel med. esse byte ficaria 00100100, o bit 0 e o bit 4 que são os bits responsáveis por stop e low estariam com valor para stop e entrariam em conflito ???
A idéia básica do cicuito é usar 6 bits para controle de movimento do ROV, formando uma "palavra" de comando com 64 opções de movimento, exemplo: frente lento, frente rápido, curva fechada à direita lento, curva aberta à direita rápido, ... Acho que não há conflitos, pois todas as combinações possíveis, e factíveis, estariam previstas.
Minha dúvida é a seguinte: a "palavra" de comando, como vc muito bem coloca é formada por zeros e uns correto. Se temos apenas três bits para definir por exemplo direção e velocidade de um motor, em um dado momento, ou outros bits não seriam considerados ?? podem estar em zero??, porque quando em zero representam alterações no estado do outro motor, luz e servo.
-
Aguilan
O .asm que coloquei é o já modificado para o f628
Roberto
Correto, este teste ainda não fiz ...
-
Anderson,
Minha dúvida é a seguinte: a "palavra" de comando, como vc muito bem coloca é formada por zeros e uns correto. Se temos apenas três bits para definir por exemplo direção e velocidade de um motor, em um dado momento, ou outros bits não seriam considerados ?? podem estar em zero??, porque quando em zero representam alterações no estado do outro motor, luz e servo.
Considere que há 64 estados de movimentação e ainda mais alguns estados dos outros dispositivos. Cada conjunto de bits transmitidos / recebidos representará um estado do ROV, considerando todos esses sinais. Além disso, o(s) bit(s) de um dispositivo pode(m) ser acionado(s) independemente uns dos outros.
-
Anderson,
Minha dúvida é a seguinte: a "palavra" de comando, como vc muito bem coloca é formada por zeros e uns correto. Se temos apenas três bits para definir por exemplo direção e velocidade de um motor, em um dado momento, ou outros bits não seriam considerados ?? podem estar em zero??, porque quando em zero representam alterações no estado do outro motor, luz e servo.
Considere que há 64 estados de movimentação e ainda mais alguns estados dos outros dispositivos. Cada conjunto de bits transmitidos / recebidos representará um estado do ROV, considerando todos esses sinais. Além disso, o(s) bit(s) de um dispositivo pode(m) ser acionado(s) independemente uns dos outros.
Perfeito, então vou a outra etapa. Continuo estudando. Grato.
-
Continuando minhas pesquisas: a comunicação serial neste projeto envia os dados para movimentação dos motores, iluminação e servo motor. Posso comandar mais equipamentos ??
-
Anderson,
Continuando minhas pesquisas: a comunicação serial neste projeto envia os dados para movimentação dos motores, iluminação e servo motor. Posso comandar mais equipamentos ??
Se voce analisar os programas, verá que utiliza 2 bytes para comandar todos os dispositivos e todos os bits estão ocupados, se voce usar toda a funcionalidade prevista. Assim, para comandar novos dispositivos será necessário agregar um ou mais bytes à comunicação e fazer as devidas modificações nos programas. Bem como prever os pinos de saída necessários no PIC16F628.
Quais dispostivos deseja adicionar?
-
Anderson,
Continuando minhas pesquisas: a comunicação serial neste projeto envia os dados para movimentação dos motores, iluminação e servo motor. Posso comandar mais equipamentos ??
Se voce analisar os programas, verá que utiliza 2 bytes para comandar todos os dispositivos e todos os bits estão ocupados, se voce usar toda a funcionalidade prevista. Assim, para comandar novos dispositivos será necessário agregar um ou mais bytes à comunicação e fazer as devidas modificações nos programas. Bem como prever os pinos de saída necessários no PIC16F628.
Quais dispostivos deseja adicionar?
Sensores de: temperatura, humidade (presença de água no interior do ROV), pressão, etc.
-
Anderson,
Sensores de: temperatura, humidade (presença de água no interior do ROV), pressão, etc.
Então voce vai ler do ROV e não apenas comandar, como é feito originalmente. Existirão bytes sendo enviados e bytes sendo recebidos. Mas ok, é possível.
No caso de medir pressão, seria necessário um sensor de pressão e uma entrada analógica no PIC ou um conversor A/D externo. Acho melhor escolher outro PIC, pois o PIC16F628 não possui entradas analógicas. E se quiser ter vários pinos para uso futuro, sugiro partir logo para um PIC de 40 pinos, exemplo PIC16F877, com 8 entradas analógicas e várias funcionalidades úteis (UART, Timer, saída PWM, ...)
Acho que o ROV já possui um sensor de umidade, que no caso de vazamento de água manda o ROV para cima.
-
Anderson,
Sensores de: temperatura, humidade (presença de água no interior do ROV), pressão, etc.
Então voce vai ler do ROV e não apenas comandar, como é feito originalmente. Existirão bytes sendo enviados e bytes sendo recebidos. Mas ok, é possível.
No caso de medir pressão, seria necessário um sensor de pressão e uma entrada analógica no PIC ou um conversor A/D externo. Acho melhor escolher outro PIC, pois o PIC16F628 não possui entradas analógicas. E se quiser ter vários pinos para uso futuro, sugiro partir logo para um PIC de 40 pinos, exemplo PIC16F877, com 8 entradas analógicas e várias funcionalidades úteis (UART, Timer, saída PWM, ...)
Acho que o ROV já possui um sensor de umidade, que no caso de vazamento de água manda o ROV para cima.
OK, vou pesquisar este pic. Enquanto isso estou me aprofundando no curso de microcontroladores.
-
Continuando com os estudos:
No trecho de programa
;********************************************************************************
;* Initialize pic *
;********************************************************************************
INIT movlw 0x84 ; EPROM callibration (for EPROM only)
movwf OSCCAL ; Store factory callibration value
clrf GPIO ; clear GPIO
movlw 0x1F ; GPIO, 5 is serial output, the rest input
tris GPIO
movlw 0xC3 ; TMR0 enable with 1:16 prescalar
option
O que é OSCCAL ?
-
É um registrador interno do PIC.
-
Desculpem-me, mas não encontro esse registrador OSCALL em lugar nenhum no data sheet do 16f84A.
-
Vc esta vendo o programa do TX com 12c671 e não com o 16f84
-
Anderson,
Vc esta vendo o programa do TX com 12c671 e não com o 16f84
Este é mais um exemplo que mostra que portar o software de um PIC para o outro não é simplesmente carregar o arquivo hex.
As arquiteturas internas dos processadores em questão são diferentes, o registrador OSCCAL não existe no PIC16C84 nem no PIC16F628A. OSCCAL é usado para calibrar o oscilador RC interno (clock) do PIC12C671.
Além de não disponível nos 84 e 628A, esse procedimento é totalmente desnecessário se usar um oscilador a cristal (muito mais exato que um oscilador RC). Lembrando que a estabilidade de frequência é indispensável para tornar a comunicação serial viável e sem erros.
-
Nesse caso se uso o 16f84 trabalho com cristal externo, mas no caso do 628 posso utilizar o oscilador interno. Este oscilador interno em comparação com o externo (cristal), qual a melhor opção.
-
Vc esta vendo o programa do TX com 12c671 e não com o 16f84
Desculpem a falha, coisas de iniciante !!!
-
Anderson,
Vc esta vendo o programa do TX com 12c671 e não com o 16f84
Este é mais um exemplo que mostra que portar o software de um PIC para o outro não é simplesmente carregar o arquivo hex.
As arquiteturas internas dos processadores em questão são diferentes, o registrador OSCCAL não existe no PIC16C84 nem no PIC16F628A. OSCCAL é usado para calibrar o oscilador RC interno (clock) do PIC12C671.
Além de não disponível nos 84 e 628A, esse procedimento é totalmente desnecessário se usar um oscilador a cristal (muito mais exato que um oscilador RC). Lembrando que a estabilidade de frequência é indispensável para tornar a comunicação serial viável e sem erros.
Aproveitando essa confusão que fiz em relação ao PIC12C671 e PIC16C84 seria possível a substituição dos dois pelo 16F877, tanto na placa de comando como na de contrôle ??
-
Sim.
-
Anderson
Nesse caso se uso o 16f84 trabalho com cristal externo, mas no caso do 628 posso utilizar o oscilador interno. Este oscilador interno em comparação com o externo (cristal), qual a melhor opção.
O cristal não é o oscilador, mas sim o dispositivo que determina a frequência do oscilador interno do PIC. Sendo bem superior ao oscilador tipo RC, também interno. Dê uma olhada nos diversos tipos de osciladores internos do PIC.
-
Anderson
Nesse caso se uso o 16f84 trabalho com cristal externo, mas no caso do 628 posso utilizar o oscilador interno. Este oscilador interno em comparação com o externo (cristal), qual a melhor opção.
O cristal não é o oscilador, mas sim o dispositivo que determina a frequência do oscilador interno do PIC. Sendo bem superior ao oscilador tipo RC, também interno. Dê uma olhada nos diversos tipos de osciladores internos do PIC.
Fiz uma busca por informações e percebi que osciladores quando excitados por cristais conseguem manter uma frequência de ressonação bastante constante, o que garantirá melhores resultados na comunicação serial entre os componentes do equipamento. Levando em consideração que alguns dos dados que serão transmitidos devem ser precisos ( informações de pressão, temperatura, etc) opto pela utilização do cristal externo.
-
Anderson
Nesse caso se uso o 16f84 trabalho com cristal externo, mas no caso do 628 posso utilizar o oscilador interno. Este oscilador interno em comparação com o externo (cristal), qual a melhor opção.
O cristal não é o oscilador, mas sim o dispositivo que determina a frequência do oscilador interno do PIC. Sendo bem superior ao oscilador tipo RC, também interno. Dê uma olhada nos diversos tipos de osciladores internos do PIC.
Fiz uma busca por informações e percebi que osciladores quando excitados por cristais conseguem manter uma frequência de ressonação bastante constante, o que garantirá melhores resultados na comunicação serial entre os componentes do equipamento. Levando em consideração que alguns dos dados que serão transmitidos devem ser precisos ( informações de pressão, temperatura, etc) opto pela utilização do cristal externo.
Aproveitando a mensagem creio que para que haja uma visualização melhor deste trabalho preciso antes mesmo de definir o meu software, montar o hardware e para isso então utilizarei PIC16F877 nas duas placas, correto ?
Para siumulação do hardware, no ISIS, faltam alguns componentes. Como ou onde posso completar minha biblioteca ?
-
Quais componentes estão faltando?
De qualquer modo, há bibliotecas para o ISIS / Proteus na Net.
-
Por exemplo o MC34164 eu não encontrei na biblioteca do software.
-
Anderson, nenhuma biblioteca é completa, obviamente isto seria impossível.
Não importa qual o programa, temos que aprender a "montar" os componentes, sempre precisamos de algum não disponível, é competência básica que quem queira usar suites como o Proteus tem que adquirir e é algo bastante simples.
Curiosidade minha: em que pretende empregar o MC34164 ?
-
O MC34164 faz o contrôle mais preciso de tensão no circuito (ver no início do tópico o esquema TX)
Como fazer para montar esses componente ??
-
O MC34164 faz o contrôle mais preciso de tensão ...
É um monitor, não um controlador. Me parece dispensável neste caso.
Como fazer para montar esses componente ??
Veja no help do Isis o tutorial "Making a new device".
-
O MC34164 faz o contrôle mais preciso de tensão ...
É um monitor, não um controlador. Me parece dispensável neste caso.
Como fazer para montar esses componente ??
Veja no help do Isis o tutorial "Making a new device".
Sim, monitor. Você acha que não seria necessário ? Me parece que faz o monitoramento de baixas tensões o que pode acarretar falha na transmissão serial, é isso mesmo ?
Já encontrei no Isis a forma de fazer, estou estudando.
-
Sim, monitor. Você acha que não seria necessário ? Me parece que faz o monitoramento de baixas tensões o que pode acarretar falha na transmissão serial, é isso mesmo ?
Sim, provoca o reset do microcontrolador em caso de baixa tensão, o que não deve ocorrer, se ocorreu, a vaca já foi pro brejo, né ? ;D E durante o reset a transmissão é interrompida ... Pelo menos é esta a função padrão do chip, não analizei o prog para verificar se, por exemplo, ele apenas provoca o envio uma msg de alarme ... isto é algo que eu faria, ao invés de um reset.
Na prática a alimentação tem que ser mantida corretamente e se por qualquer motivo falhar, digamos, baixa tensão, de modo geral é melhor deixar como está, o sistema ainda funcionaria com 4V, o que é preferível à desligá-lo o que dá uma oportunidade para recuperação do veículo ...
PS: Fui dar uma espiada no prog e de fato a função é de reset:
;* Pin 7 (AN0) ,analogue input (X plane)
;* Pin 6 (AN1) ,analogue input (Y plane)
;* Pin 5 (AN2) ,analogue input (Depth)
;* Pin 3 (GP4) ,digital input (button)
;* Pin 2 (GP5) ,digital serial output
;* Pin 4 (GP3) ,reset
-
Sim, monitor. Você acha que não seria necessário ? Me parece que faz o monitoramento de baixas tensões o que pode acarretar falha na transmissão serial, é isso mesmo ?
Sim, provoca o reset do microcontrolador em caso de baixa tensão, o que não deve ocorrer, se ocorreu, a vaca já foi pro brejo, né ? ;D E durante o reset a transmissão é interrompida ... Pelo menos é esta a função padrão do chip, não analizei o prog para verificar se, por exemplo, ele apenas provoca o envio uma msg de alarme ... isto é algo que eu faria, ao invés de um reset.
Na prática a alimentação tem que ser mantida corretamente e se por qualquer motivo falhar, digamos, baixa tensão, de modo geral é melhor deixar como está, o sistema ainda funcionaria com 4V, o que é preferível à desligá-lo o que dá uma oportunidade para recuperação do veículo ...
PS: Fui dar uma espiada no prog e de fato a função é de reset:
;* Pin 7 (AN0) ,analogue input (X plane)
;* Pin 6 (AN1) ,analogue input (Y plane)
;* Pin 5 (AN2) ,analogue input (Depth)
;* Pin 3 (GP4) ,digital input (button)
;* Pin 2 (GP5) ,digital serial output
;* Pin 4 (GP3) ,reset
Correto. Vc deu uma excelente sugestão, ao ser verificada tensão baixa enviar um aviso e aí tomar as medidas para recuperação do veículo.
-
Lembrando que o PIC16F877 possui um comparador, que juntamente com um diodo zener, poderia ser usado para implementar um sistema de monitoração de sub-tensão, para verificar bateria fraca, ecomomizando este CI (MC34164).
-
Eu não achei no programa do TX nada que use pino reset.
Acho que é só enfeite ou esqueceram de colocar alguma rotina.
Ou alguma rotina do RX faça essa leitura.
Estou aprendendo também a programação ASM, e se falei alguma besteira me desculpe.
Roberto
-
Eu não achei no programa do TX nada que use pino reset.
Essas coisas só se revelam aos de aura clara, só quem é clarividente pode ver ... ;D ;D ;D
__CONFIG _CP_OFF & _MCLRE_ON & _WDT_OFF & _INTRC_OSC & _PWRTE_ON
-
Lembrando que o PIC16F877 possui um comparador, que juntamente com um diodo zener, poderia ser usado para implementar um sistema de monitoração de sub-tensão, para verificar bateria fraca, ecomomizando este CI (MC34164).
Ops, vou ver como se faz isso.
-
è isso aí Jorge.
Taí uma coisa que não sabia o uso. Já timha visto no datasheet, mas todos (poucos) programas que olhei, usava ele off..
Nunca é tarde para aprender e se eu não colocasse a duvda, não tena aprendido.
grato Roberto
-
Nunca é tarde para aprender e se eu não colocasse a duvda, não tena aprendido.
Pois é, Roberto, discutir as coisas é sempre muito bom, aprendemos todos ... ;D
-
Por falar em simulação, não é necessário simular 100% do circuito, mas principalmente as partes +críticas (software, algumas interfaces, ...). Caso seja usado, o chip de monitoração de sub-tensão (MC34164) basicamente, gera uma saída quando a tensão cai abaixo de certo valor. Isto pode ser simulado alterando o estado de um pino do PIC, através de uma chave, dispensando a criação e modelagem deste chip.
Além disso, o PIC16F877 pode ser alimentado de 2V a 5,5V. Facilitando o uso de baterias e do projeto do circuito de monitoração, se necessário. Eu faria algo simples do tipo: se a bateria cair abaixo de determinado nível ou se umidade for detectada, acionar a subida do ROV. Isso, aliás, pode ser facilmente realizado liberando um peso (lastro), como num submarino.
-
uma outra opção é utilizar uma entrada analógica e ler o valor da tensão onde poderá implementar avisos ... quantos achar necessário ...
-
Por falar em simulação, não é necessário simular 100% do circuito, mas principalmente as partes +críticas (software, algumas interfaces, ...). Caso seja usado, o chip de monitoração de sub-tensão (MC34164) basicamente, gera uma saída quando a tensão cai abaixo de certo valor. Isto pode ser simulado alterando o estado de um pino do PIC, através de uma chave, dispensando a criação e modelagem deste chip.
Além disso, o PIC16F877 pode ser alimentado de 2V a 5,5V. Facilitando o uso de baterias e do projeto do circuito de monitoração, se necessário. Eu faria algo simples do tipo: se a bateria cair abaixo de determinado nível ou se umidade for detectada, acionar a subida do ROV. Isso, aliás, pode ser facilmente realizado liberando um peso (lastro), como num submarino.
Exatamente, essa é a idéia. A subida do aparelho à superfície precisa ser feita independente de motorização ,pois em caso de pane que impeça sua movimentação este emergirá naturalmente com base no princípio do empuxo. A alimentação do equipamento não é feita por bateria e sim por cabo umbilical pelo seguinte motivo: debaixo d'água a comunicação remota se torna difícil e cara optando-se pela transmissão de dados via cabo, sendo assim aproveita-se este cabo para alimentação também.
-
Anderson,
Exatamente, essa é a idéia. A subida do aparelho à superfície precisa ser feita independente de motorização ,pois em caso de pane que impeça sua movimentação este emergirá naturalmente com base no princípio do empuxo. A alimentação do equipamento não é feita por bateria e sim por cabo umbilical pelo seguinte motivo: debaixo d'água a comunicação remota se torna difícil e cara optando-se pela transmissão de dados via cabo, sendo assim aproveita-se este cabo para alimentação também.
Sendo feita por cabo, a monitoração da alimentação é simples, e se falhar, pode ser liberado um peso para aumentar o empuxo. Ou mais simples, puxe o ROV pelo cabo (se este não tiver arrebentado...).
Eu já montei um submarino por controle remoto (usava tanque de lastro e GLP para deslocar a água), usei um radiocontrole Futaba FM na faixa de frequência de VHF e funcionou bem em água doce (piscinas), em agua salgada eu não testei mas a atenuação é bem maior. Os submarinos militares usam frequencias de VLF para se comunicar em qualquer parte do mundo, mas as antenas fixas são gigantescas.
Dê uma olhada no site:
http://www.qsl.net/vk5br/UwaterComms.htm
-
Ainda me encontro cheio de dúvidas. Para que entenda e possa desenvolver o software do projeto preciso compreender o funcionamento correto do hardware. Avaliem se estou correto: O joystick pode assumir várias posições físicas (parado, frente/low, frente/med, frente/fast, trás/low ... e assim por diante para todas as posições possíveis do joystick. Quando o joystick se movimenta aciona dois potenciômetros de 10k ohms e para cada posição, cada um assume um valor específico de resistência que resultam em uma tensão para cada dessas posições. Como isso se traduz para ser transmitido ? É convertido digitalmente e enviado ? São faixas de valores por exemplo: Entre 0 e X volts = y e esse y é que seria convertido para transmissão ?
Desde já grato pela ajuda
-
Entre 0 e X volts = y e esse y é que seria convertido para transmissão ?
Isso mesmo.
;********************************************************************************
;* Sample A/D channel and store value in W *
;********************************************************************************
SAMPLE
movwf ADCON0 ; set channel, and turn A/D on
bsf STATUS, RP0 ; select page 1
movlw 0x02 ; AN0, AN1 & AN2 analogue and GP4 digital
movwf ADCON1
bsf PIE1, ADIE ; enable A/D interrupt
bcf STATUS, RP0 ; select page 0
bcf PIR1, ADIE ; clear A/D interrupt flag (conversion not complete)
bsf INTCON, PEIE ; enable peripheral interrupts
bsf INTCON, GIE ; enable all interrupts
call DELAY_100us ; allow time for A/D caps to charge (sample time)
bsf ADCON0, GO ; start A/D conversion
sleep ; sleep while conversion takes place
movf ADRES, W ; place result in W
return
Para que entenda e possa desenvolver o software do projeto preciso compreender o funcionamento correto do hardware.
Não apenas do hardware ...
Vale a pena fazer um fluxograma para entender o prog e sua interação com o hardware ... é bom ter à mão as data sheets do PIC original e do alvo, comparando semelhanças e diferenças. Isto vai evidenciar o que pode ser mantido e o que deve ser alterado ...
-
Certo, estou caminhando aos poucos e aprendendo devagar. O joystick pode ser desses encontrados para games, eu já verifiquei que eles trabalham com pots de 10k. A variação de tensão nessas resistências serão muito pequenas, é assim mesmo ?? E nesse caso só utilizaremos os níveis altos e baixos de tensão ??? Se puder, favor exemplificar para que eu possa entender, estou tendo alguma dificuldade de visualizar esse processo.
-
A variação de tensão nessas resistências serão muito pequenas, é assim mesmo ??
O que é que vc considera "muito pequena" ? A tensão vai variar proporcionalmente à excursão, dependendo do modelo do joystick pode ser bastante grande, praticamente de 0V a 5V ...
E nesse caso só utilizaremos os níveis altos e baixos de tensão ???
Se fosse este o caso o joystick não seria necessário, né ? A tensão é proporcional à posição do stick ...
Se puder, favor exemplificar para que eu possa entender, estou tendo alguma dificuldade de visualizar esse processo.
A coisa é relativamente simples: Os pots são varridos e a tensão variável é convertida para um número representativo de sua magnitude pelo conversor AD e este valor é transmitido serialmente. No receptor isto é convertido para ciclo de trabalho de um PWM que controla a velocidade e direção de cada motor ou a posição de um servo ...
Viu o filminho ? :
http://www.ece.uvic.ca/~ece499/2001a/group11/Video/ROV%20top.avi
-
Ainda me encontro cheio de dúvidas. Para que entenda e possa desenvolver o software do projeto preciso compreender o funcionamento correto do hardware. Avaliem se estou correto: O joystick pode assumir várias posições físicas (parado, frente/low, frente/med, frente/fast, trás/low ... e assim por diante para todas as posições possíveis do joystick. Quando o joystick se movimenta aciona dois potenciômetros de 10k ohms e para cada posição, cada um assume um valor específico de resistência que resultam em uma tensão para cada dessas posições. Como isso se traduz para ser transmitido ? É convertido digitalmente e enviado ? São faixas de valores por exemplo: Entre 0 e X volts = y e esse y é que seria convertido para transmissão ?
O trecho de programa a seguir é o coração do transmissor, onde é lida a posição de cada potenciômetro do joystick (SAMPLE, que o Jorge mostrou), das chaves (BTNTEST) e em seguida os bits são enviados pela porta serial (SERIAL). E para caber tudo numa palavra, são efetuados deslocamentos dos bits (rrf).
;********************************************************************************
;* Main program loop *
;********************************************************************************
MAIN movlw 0xC9 ; channel 1 (GP1/AN1/Pin 6), A/D module on
call SAMPLE ; sample AN1 (Y axis), value returns in W
andlw 0xE0 ; mask 3 most sig bits, put result in W
movwf SER_DATA_1 ; SER_DATA_1 = [y7 y6 y5 0, 0 0 0 0]
rrf SER_DATA_1, F
rrf SER_DATA_1, F
rrf SER_DATA_1, F ; SER_DATA_1 = [0 0 0 y7, y6 y5 0 0]
movlw 0xC1 ; channel 0 (GP0/AN0/Pin 7), A/D module on
call SAMPLE ; sample AN0 (X axis), value returns in W
andlw 0xE0 ; mask 3 most sig bits, put result in W
addwf SER_DATA_1, F ; SER_DATA_1 = [x7 x6 x5 y7, y6 y5 0 0]
rrf SER_DATA_1, F
rrf SER_DATA_1, F ; SER_DATA_1 = [0 0 x7 x6, x5 y7 y6 y5]
movlw 0xD1 ; channel 2 (GP2/AN2/Pin 5), A/D module on
call SAMPLE ; sample AN2 (depth), value returns in W
movwf SER_DATA_2 ; second byte of serial data
call BTNTEST ; check button status and adjust light/servo bits
call SERIAL ; transmit SER_DATA_1 and SER_DATA_2
call PAUSE ; giver receiver time to syncronize
goto MAIN ; main program loop
Tem que analisar o programa.... :)
-
A variação de tensão nessas resistências serão muito pequenas, é assim mesmo ??
O que é que vc considera "muito pequena" ? A tensão vai variar proporcionalmente à excursão, dependendo do modelo do joystick pode ser bastante grande, praticamente de 0V a 5V ...
E nesse caso só utilizaremos os níveis altos e baixos de tensão ???
Se fosse este o caso o joystick não seria necessário, né ? A tensão é proporcional à posição do stick ...
Se puder, favor exemplificar para que eu possa entender, estou tendo alguma dificuldade de visualizar esse processo.
A coisa é relativamente simples: Os pots são varridos e a tensão variável é convertida para um número representativo de sua magnitude pelo conversor AD e este valor é transmitido serialmente. No receptor isto é convertido para ciclo de trabalho de um PWM que controla a velocidade e direção de cada motor ou a posição de um servo ...
Viu o filminho ? :
http://www.ece.uvic.ca/~ece499/2001a/group11/Video/ROV%20top.avi
Procurei informações sobre os conversores Ad e sobre PWM. Começo a compreender esse processo. Concluí o seguinte, corrija-me se eu estiver errado.
As variações de tensão , criadas pela variação da resistência dos pots, são lidas e interpretadas dentro de uma escala que varia de 0 a 5V e que estão relacionadas a posições em binários (conforme tamanho da minha informação em bits, no caso 8 bits - 64 posições possíveis). Esta informação, agora digital é enviada serialmente e já está adequada para o ciclo de trabalho de um PWM que possibilita a alteração de velocidade e sentido re rotação do motor. Correto ?
-
Ainda me encontro cheio de dúvidas. Para que entenda e possa desenvolver o software do projeto preciso compreender o funcionamento correto do hardware. Avaliem se estou correto: O joystick pode assumir várias posições físicas (parado, frente/low, frente/med, frente/fast, trás/low ... e assim por diante para todas as posições possíveis do joystick. Quando o joystick se movimenta aciona dois potenciômetros de 10k ohms e para cada posição, cada um assume um valor específico de resistência que resultam em uma tensão para cada dessas posições. Como isso se traduz para ser transmitido ? É convertido digitalmente e enviado ? São faixas de valores por exemplo: Entre 0 e X volts = y e esse y é que seria convertido para transmissão ?
O trecho de programa a seguir é o coração do transmissor, onde é lida a posição de cada potenciômetro do joystick (SAMPLE, que o Jorge mostrou), das chaves (BTNTEST) e em seguida os bits são enviados pela porta serial (SERIAL). E para caber tudo numa palavra, são efetuados deslocamentos dos bits (rrf).
;********************************************************************************
;* Main program loop *
;********************************************************************************
MAIN movlw 0xC9 ; channel 1 (GP1/AN1/Pin 6), A/D module on
call SAMPLE ; sample AN1 (Y axis), value returns in W
andlw 0xE0 ; mask 3 most sig bits, put result in W
movwf SER_DATA_1 ; SER_DATA_1 = [y7 y6 y5 0, 0 0 0 0]
rrf SER_DATA_1, F
rrf SER_DATA_1, F
rrf SER_DATA_1, F ; SER_DATA_1 = [0 0 0 y7, y6 y5 0 0]
movlw 0xC1 ; channel 0 (GP0/AN0/Pin 7), A/D module on
call SAMPLE ; sample AN0 (X axis), value returns in W
andlw 0xE0 ; mask 3 most sig bits, put result in W
addwf SER_DATA_1, F ; SER_DATA_1 = [x7 x6 x5 y7, y6 y5 0 0]
rrf SER_DATA_1, F
rrf SER_DATA_1, F ; SER_DATA_1 = [0 0 x7 x6, x5 y7 y6 y5]
movlw 0xD1 ; channel 2 (GP2/AN2/Pin 5), A/D module on
call SAMPLE ; sample AN2 (depth), value returns in W
movwf SER_DATA_2 ; second byte of serial data
call BTNTEST ; check button status and adjust light/servo bits
call SERIAL ; transmit SER_DATA_1 and SER_DATA_2
call PAUSE ; giver receiver time to syncronize
goto MAIN ; main program loop
Tem que analisar o programa.... :)
Gil,
Realmente estou precisando muito conhecimento para poder compreender todo o processo. Acabei de ler sobre conversores AD e PWM para entender um pouco mais do funcionamento dos componentes e saber o que posso fazer no software. Estou também estudando ASM e logo posso me situar melhor.
-
Entre 0 e X volts = y e esse y é que seria convertido para transmissão ?
Isso mesmo.
[info]
;********************************************************************************
;* Sample A/D channel and store value in W *
;********************************************************************************
SAMPLE
movwf ADCON0 ; set channel, and turn A/D on
bsf STATUS, RP0 ; select page 1
movlw 0x02 ; AN0, AN1 & AN2 analogue and GP4 digital
movwf ADCON1
bsf PIE1, ADIE ; enable A/D interrupt
bcf STATUS, RP0 ; select page 0
bcf PIR1, ADIE ; clear A/D interrupt flag (conversion not complete)
bsf INTCON, PEIE ; enable peripheral interrupts
bsf INTCON, GIE ; enable all interrupts
call DELAY_100us ; allow time for A/D caps to charge (sample time)
bsf ADCON0, GO ; start A/D conversion
sleep ; sleep while conversion takes place
movf ADRES, W ; place result in W
return
[/info]
Para que entenda e possa desenvolver o software do projeto preciso compreender o funcionamento correto do hardware.
Não apenas do hardware ...
Vale a pena fazer um fluxograma para entender o prog e sua interação com o hardware ... é bom ter à mão as data sheets do PIC original e do alvo, comparando semelhanças e diferenças. Isto vai evidenciar o que pode ser mantido e o que deve ser alterado ...
No código ADCON0 e ADCON1 o que são ??
-
As variações de tensão , criadas pela variação da resistência dos pots, são lidas e interpretadas dentro de uma escala que varia de 0 a 5V
A variação de tensão, o máximo e o mínimo, dependem do circuito divisor de tensão. Pode ser de 0V a 5V neste caso, do ponto de vista elétrico, mas isto tb depende da mecânica. Será verdade se a mecância permitir a excursão plena do pot, o que nem sempre acontece.
estão relacionadas a posições em binários
Prefiro dizer que está relacionado à posição dos pots e que a leitura do conversor AD será um número, um conjunto de bits, possivelmente contido em um único byte, se o conversor for de oito bits. Binário é um sistema de numeração, conveniente para humanos. O número poderá ser expresso em qualquer sistema que nos seja mais conveniente, o que é solenemente ignoradopela máquina ...
(conforme tamanho da minha informação em bits, no caso 8 bits - 64 posições possíveis).
Sim, oito bits quando o conversor for de oito bits ... nem sempre é o caso.
Oito bits permitem uma resolução de 256 pontos, não 64 ...
Esta informação, agora digital é enviada serialmente e já está adequada para o ciclo de trabalho de um PWM que possibilita a alteração de velocidade e sentido re rotação do motor. Correto ?
Pode estar adequada ou não ... eu não analisei o prog detalhadamente, mas é comum que os valores sofram processamento adicional. Pode não ser desejável uma tradução direta, pode ser interessante modificar a resolução ou tratar a grandeza não linearmente ...
PS: evite as citações integrais, isto não contribui para a inteligibilidade, desperdiça espaço e até atrapalha a visulaização da msg ...
-
No código ADCON0 e ADCON1 o que são ??
São posições de memória que funcionam como registradores especiais, para controle do conversor AD, neste caso.
(http://s2.postimage.org/ozJfr.jpg) (http://www.postimage.org/image.php?v=TsozJfr)
(http://s4.postimage.org/Gi_p0.jpg) (http://www.postimage.org/image.php?v=aVGi_p0)
-
PS: evite as citações integrais, isto não contribui para a inteligibilidade, desperdiça espaço e até atrapalha a visulaização da msg ...
Como assim ???
-
Como assim ???
Vc vem citando na íntegra as msgs imediatamente anteriores às suas ... o que é desnecessário, pq a msg referida está logo acima, perdulário pq duplica o espaço ocupado no banco de dados do fórum e atrapalha a legibilidade pq cria uma linguiça que obriga a rolar a tela para visualizar o que interessa ...
veja como os colegas respondem, citando apenas um fragmento pertinente para contextualizar a resposta ...
-
Como assim ???
veja como os colegas respondem, citando apenas um fragmento pertinente para contextualizar a resposta ...
;
Entendi, desculpem a falha. ;D
-
(http://s4.postimage.org/Gi_p0.jpg) (http://www.postimage.org/image.php?v=aVGi_p0)
[/quote]
ESTOU MIGRANDO DO 12C671 PARA O 16F628A E NESTE ÚLTIMO NÃO ENCONTRO O CONVERSOR A/D VERIFIQUEI QUE RA0 E RA1 SÃO ENTRADAS ANALÓGICAS(COMPARADORES ). COMO FAÇO PARA LER SINAIS ANALÓGICOS E TRANSFORMÁ-LOS EM DIGITAIS ?
-
Porque o 15f628 e não o 12f675 ?
-
Porque o 15f628 e não o 12f675 ?
Não analisei a substituição pelo 675. A opção de troca pelo 628 veio da necessidade de encontrar um Pic mais novo e com um pouco mais de recursos. Na realidade o projeto original usava o PIC12C671.
-
O 12F675 é igual o 12F629 com entrada A/D e usa os mesmos pinos do 12C671
-
O 12F675 é igual o 12F629 com entrada A/D e usa os mesmos pinos do 12C671
É uma outra boa opção.
-
ESTOU MIGRANDO DO 12C671 PARA O 16F628A E NESTE ÚLTIMO NÃO ENCONTRO O CONVERSOR A/D VERIFIQUEI QUE RA0 E RA1 SÃO ENTRADAS ANALÓGICAS(COMPARADORES ). COMO FAÇO PARA LER SINAIS ANALÓGICOS E TRANSFORMÁ-LOS EM DIGITAIS ?
Encontrei no registrador especial CMCON. No caso específico preciso usar DUAS entradas analógicas, concordam ? Sendo assim, vou configurar o registrador com os três primeiros bits em 100 (resulta em dois comparadores independentes )
-
COMO FAÇO PARA LER SINAIS ANALÓGICOS E TRANSFORMÁ-LOS EM DIGITAIS ?
Há muitas maneiras de fazer a conversão ... uma delas é utilizando a tensão de referência (Vref) variável e os comparadores.
Supondo que seu interesse seja tb dominar os PICs e não apenas o projeto do ROV, sugiro:
A bíblia de quem lida com PICs:
PICmicro Mid-Range Reference Manual
http://ww1.microchip.com/downloads/en/devicedoc/33023a.pdf
Sugiro tb um longo passeio pelo site da Microchip para familiarizar-se com a documentação existente. Além das data sheets, as notas de aplicação ajudam muito e são muito interessantes e divertidas. É possível encontrar código pronto pra quase tudo que possa precisar.
Há alguma literatura em português, os livros abaixo são dos mais populares:
Desbravando o PIC - Ampliado e Atualizado para PIC 16F628A
http://www.editoraerica.com.br/buscafinal.asp?cod=8674
Microcontroladores PIC - Técnicas Avançadas
http://www.editoraerica.com.br/buscafinal.asp?cod=7279
Se o inglês não for prob pra vc, prefira o site da Microchip, todos os livros que pude ver são baseados nas informações lá disponíveis, recompiladas, mas tem lá seu valor didático, mas afinal a Microchip é a fonte primária de referência. As mandrakarias mais interessantes vc vai encontrar em sites por aí, raramente em livros.
-
Entendi que iria usar o PIC16F877 no ROV e na unidade de comando, que possui mais pinos, entradas analógicas, porta serial,..... Desistiu?
Seria um PIC só dos dois lados, padronizando melhor o software...
-
Entendi que iria usar o PIC16F877 no ROV e na unidade de comando, que possui mais pinos, entradas analógicas, porta serial,..... Desistiu?
Não desisti não. O que estou fazendo por enquanto é pesquisa e estudo. Estou utilizando o material que já tenho para me familiarizar com microcontroladores e como havia comprado o livro desbravando o pic - PIC16F628A estou trabalhando com este componente.
[/quote]
Seria um PIC só dos dois lados, padronizando melhor o software...
Sim, a idéia é utilizar somente um. Para atender as necessidades básicas do projeto o 628 serve.'
-
Supondo que seu interesse seja tb dominar os PICs e não apenas o projeto do ROV, sugiro:
A bíblia de quem lida com PICs:
Jorge,
Já baixei o Manual de referência e achei EXCELENTE, tenho um bocado de diversão pela frente. O Desbravando o PIC eu já tenho e estou utilizando bastante. Grato pelas dicas.
-
Para atender as necessidades básicas do projeto o 628 serve.'
Mas não possui conversor A/D, apesar de ter comparadores. Um conversor A/D é diferente dos comparadores, inclusive para implementar várias entradas analógicas (o 628 não possui MUX analógico, software seria bem +complexo)...
Não entendi onde usaria o 628 no projeto.
-
Mas não possui conversor A/D, apesar de ter comparadores. Um conversor A/D é diferente dos comparadores, inclusive para implementar várias entradas analógicas (o 628 não possui MUX analógico, software seria bem +complexo)...
Não entendi onde usaria o 628 no projeto.
Esta mudança de microcontrolador foi orientada por um fornecedor (na época ele me informou que o projeto original com 16F84A era coisa ultrapassada e que poderia substituir pelo 628). O projeto ficou parado por dois meses e agora estou retomando as atividades. A orientação que vc está me passando realmente me conforta pois estava complicado para entender como fazer a conversão A/D.
Neste caso então posso alterar o que já fiz para o 877 como havíamos falado. Esse é o componente certo para esse tipo de aplicação ? O que acha ? Sou iniciante nessa área mas com um empurrãozinho consigo dar andamento ao projeto.
-
Esse é o componente certo para esse tipo de aplicação ?
Não há propriamente o certo, a escolha de um microcontrolador não é uma receitinha de bolo, é sempre espinhosa, há muitas opções, particularmente para projetos comerciais, onde cada centavo conta, cada milímetro cúbico conta, cada grama conta ... como não é este o caso, eu compartilho da opinião do Gil, acho que o 16F877 é uma boa opção, muito flexível, vai facilitar muito os estágios iniciais e permitir expansões significativas no futuro próximo. E não vai custar um rim, tá disponível no nosso mercado a baixo custo.
-
Esse é o componente certo para esse tipo de aplicação ?
, eu compartilho da opinião do Gil, acho que o 16F877 é uma boa opção, muito flexível, vai facilitar muito os estágios iniciais e permitir expansões significativas no futuro próximo.
Sendo assim já estou trabalhando com esse novo componente e preparando as alterações no código. A propósito, verifiquei no Manual de Referência a seguinte informação:
BSF STATUS, RP0 ; Select Bank1
CLRF ADCON1 ; Configure A/D inputs
BSF PIE1, ADIE ; Enable A/D interrupts
BCF STATUS, RP0 ; Select Bank0
MOVLW 0xC1 ; RC Clock, A/D is on, Channel 0 is selected
MOVWF ADCON0 ;
BCF PIR1, ADIF ; Clear A/D interrupt flag bit
BSF INTCON, PEIE ; Enable peripheral interrupts
BSF INTCON, GIE ; Enable all interrupts
;
; Ensure that the required sampling time for the selected input
; channel has elapsed. Then the conversion may be started.
;
BSF ADCON0, GO ; Start A/D Conversion
: ; The ADIF bit will be set and the GO/DONE
: ; bit is cleared upon completion of the
: ; A/D Conversion.
Posso utilizar como minha rotina de conversão A/D e ao retornar carrego o valor convertido em "W"
-
Posso utilizar como minha rotina de conversão A/D e ao retornar carrego o valor convertido em "W"
É por aí ...
Observe certas coisinhas ...
Vc deveria usar cristal para o clock, já que vai precisar de comunicação serial. Não é absolutamente necessário, mas é recomendável, pode poupar algumas enxaquecas ... neste caso nada justifica não usar ...
Cuidado com o tratamento das interrupções ... são utilíssimas, mas dão surra em gente grande ... saber usá-las adequadamente é o que separa os homens dos meninos ... ;D
Uma coisa que eu acho chatíssima nos PICs é a comutação dos bancos ...
-
NO TRECHO DO CÓDIGO:
BSF STATUS, RP0 ; Select Bank1
CLRF ADCON1 ; Configure A/D inputs
BSF PIE1, ADIE ; Enable A/D interrupts
A CONFIGURAÇÃO DESTE REGISTRADOR ESTÁ SENDO FEITA TODA EM ZEROS CORRETO, ENTÃO:
VERIFICANDO NO DATASHET ESSE BYTE ASSUMIRÁ QUE TODAS AS ENTRADAS SERÃO ANALÓGICAS, ISTO ESTÁ CORRETO ? É ASSIM QUE DEVO ANALIZAR ?
Posso utilizar como minha rotina de conversão A/D e ao retornar carrego o valor convertido em "W"
-
Esse é o componente certo para esse tipo de aplicação ?
, eu compartilho da opinião do Gil, acho que o 16F877 é uma boa opção, muito flexível, vai facilitar muito os estágios iniciais e permitir expansões significativas no futuro próximo.
Sendo assim já estou trabalhando com esse novo componente e preparando as alterações no código. A propósito, verifiquei no Manual de Referência a seguinte informação:
BSF STATUS, RP0 ; Select Bank1
CLRF ADCON1 ; Configure A/D inputs
BSF PIE1, ADIE ; Enable A/D interrupts
BCF STATUS, RP0 ; Select Bank0
MOVLW 0xC1 ; RC Clock, A/D is on, Channel 0 is selected
ALTERANDO ESSA LINHA PARA:
MOVLW 0x81 ; 20 MHZ Clock, A/D is on, Channel 0 is selected
ESTÁ CORRETA ESSA FREQUÊNCIA ???
MOVWF ADCON0 ;
BCF PIR1, ADIF ; Clear A/D interrupt flag bit
-
VERIFICANDO NO DATASHET ESSE BYTE ASSUMIRÁ QUE TODAS AS ENTRADAS SERÃO ANALÓGICAS, ISTO ESTÁ CORRETO ? É ASSIM QUE DEVO ANALIZAR ?
Sim, não esquecendo que outros bits do registrador tem outras funções e exigem atenção.
ALTERANDO ESSA LINHA PARA:
MOVLW 0x81 ; 20 MHZ Clock, A/D is on, Channel 0 is selected
ESTÁ CORRETA ESSA FREQUÊNCIA ???
(http://s2.postimage.org/xndm9.jpg) (http://www.postimage.org/image.php?v=Tsxndm9)
[warning]0x81 = 10000001b
ADCON0 <ADCS1:ADCS0> = 10
ADCON1 <ADCS2> 0 ==> Fosc/32
ADCON1 <ADCS2> 1 ==> Fosc/64[/warning]
[info]21.5 Selecting the A/D Conversion Clock
The A/D conversion time per bit is defined as TAD. The A/D conversion requires 9.5 TAD per 8-bit conversion. The source of the A/D conversion clock is software selected. The four possible options for TAD are:
• 2TOSC
• 8TOSC
• 32TOSC
• Internal RC oscillator
For correct A/D conversions, the A/D conversion clock (TAD) must be selected to ensure a minimum TAD time of 1.6 µs for all devices, as shown in parameter 130 of the devices electrical specifications.[/info]
Não cabe aqui falar em frequência (no que se refere à conversão), mas de tempo de amostragem ( tempo de aquisição + tempo de conversão ) ...
A configuração e consequentemente o tempo de conversão vai depender da fonte de clock do ADC e sua frequência.
-
[info]21.5 Selecting the A/D Conversion Clock
The A/D conversion time per bit is defined as TAD. The A/D conversion requires 9.5 TAD per 8-bit conversion. The source of the A/D conversion clock is software selected. The four possible options for TAD are:
• 2TOSC
• 8TOSC
• 32TOSC
• Internal RC oscillator
For correct A/D conversions, the A/D conversion clock (TAD) must be selected to ensure a minimum TAD time of 1.6 µs for all devices, as shown in parameter 130 of the devices electrical specifications.[/info]
Então cheguei a seguinte conclusão:
A configuração do registrro ADCON0 ficou assim:
Bit0=1 A/D operando
Bit2=1 somente no momento da conversão)
Bit3 a 5=000 (escolhi o canal RA0/AN0 - a escolhá é livre ???)
Bit6 e 7 = 10 (conforme tab. 23-1 do Manual de Ref. onde Freq do dispositivo = 20 MHz e TAD mínimo de 1.6 us Resultam em 32 TOSC
A leitura do resultado da conversão é feita na palavra de 16 bits gerada como resultado da conversão correto ? O valor que interessa tem 10 bits e podem estar justificados a direita ou esquerda e é este valor que vou ler como resultado da minha conversão ??? Como assim ?
-
Estou entendendo que vai usar o PIC16F877, não e?
Nesse caso, algumas recomendações:
(1) Voce não precisa usar interrupções em seu programa para o conversor A/D, o programa original que vc enviou não usa (módulo tx, que lê os sinais dos potenciômetros do Joystick).
(2) Voce pode usar a funcionalidade de comunicação serial do PIC, simplificará muito o programa.
A escolha do canal do conversor A/D depende de que potenciômetro estará lendo, o programa principal (MAIN) faz isso repetidamente, setando o valor do acumulador (W) antes de chamar a rotina SAMPLE:
[attachthumb=1]
Desse modo, o programa é simples e não usa interrupções...
-
Estou entendendo que vai usar o PIC16F877, não e?
Nesse caso, algumas recomendações:
(1) Voce não precisa usar interrupções em seu programa para o conversor A/D, o programa original que vc enviou não usa (módulo tx, que lê os sinais dos potenciômetros do Joystick).
(2) Voce pode usar a funcionalidade de comunicação serial do PIC, simplificará muito o programa.
Voce diz o USART ?
-
Anderson, faz uma forcinha aí pra formatar melhor as citações ... ;D
Vc fez assim logo acima:
Estou entendendo que vai usar o PIC16F877, não e?
Nesse caso, algumas recomendações:
(1) Voce não precisa usar interrupções em seu programa para o conversor A/D, o programa original que vc enviou não usa (módulo tx, que lê os sinais dos potenciômetros do Joystick).
(2) Voce pode usar a funcionalidade de comunicação serial do PIC, simplificará muito o programa.
Voce diz o USART ?
Minha sugestão:
2) Voce pode usar a funcionalidade de comunicação serial do PIC ...
Voce diz o USART ?
Compare, não fica mais legível e sucinto ?
-
Eu quis dizer UART, pois:
USART = Universal Synchronous Asynchronous Receiver Transmitter
UART = Universal Asynchronous Receiver Transmitter
E vc vai usar comunicação assincrona (em nível TTL, RS232 ou RS485).
-
Eu quis dizer UART, pois:
USART = Universal Synchronous Asynchronous Receiver Transmitter
UART = Universal Asynchronous Receiver Transmitter
E vc vai usar comunicação assincrona (em nível TTL, RS232 ou RS485).
Não estou encontrando nada sobre UART, alguma dica ???
-
Anderson, faz uma forcinha aí pra formatar melhor as citações ... ;D
Vc fez assim logo acima:
Estou entendendo que vai usar o PIC16F877, não e?
Nesse caso, algumas recomendações:
(1) Voce não precisa usar interrupções em seu programa para o conversor A/D, o programa original que vc enviou não usa (módulo tx, que lê os sinais dos potenciômetros do Joystick).
(2) Voce pode usar a funcionalidade de comunicação serial do PIC, simplificará muito o programa.
Voce diz o USART ?
Minha sugestão:
2) Voce pode usar a funcionalidade de comunicação serial do PIC ...
Voce diz o USART ?
Compare, não fica mais legível e sucinto ?
Deixa comigo, vou caprichar.
-
Não estou encontrando nada sobre UART, alguma dica ???
Sim, há muita coisa sobre UART na Net...
http://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter
-
Não estou encontrando nada sobre UART, alguma dica ???
Sim, há muita coisa sobre UART na Net...
Encontrei material na Internet e no manual de referência.
]http://www.postimage.org/image.php?gallery=37gtYc] (http://www.postimage.org/image.php?gallery=37gtYc)
Em que posição no meu programa esse código vai entrar (considerando como exemplo o código do programa já existente)
-
Estou lendo um artigo que fala sobre RS-232 e diz que há uma limitação de comprimento de cabo de transmissão de 20 metros. É isso mesmo ???
-
Sim, são 15 a 20 metros, dependendo da capacitância do cabo, mas se usar o RS485 pode ir de centenas de metros a 1km.
Ia me esquecendo, o seu cabo vai entrar dentro d´água não é? Existem multicabos a prova dágua.
-
Sim, são 15 a 20 metros, dependendo da capacitância do cabo, mas se usar o RS485 pode ir de centenas de metros a 1km.
Então vou ter que usar o RS485. Mais assunto para estudo.
Ia me esquecendo, o seu cabo vai entrar dentro d´água não é? Existem multicabos a prova dágua.
Sim, eu já fiz essa pesquisa e tenho alguma coisa arquivada. Os umbilicais hoje são feitos com uma tremenda tecnologia. Tem cabo balanceado para combater o empuxo e muitas outras novidades.
-
]http://www.postimage.org/image.php?gallery=37gtYc] (http://www.postimage.org/image.php?gallery=37gtYc)
Em que posição no meu programa esse código vai entrar (considerando como exemplo o código do programa já existente)
Este é um trecho de inicialização da porta serial, que vai executar uma única vez. Mas conforme já lhe disse, pode dispensar as instruções relacionadas à interrupção.
-
Estou lendo um artigo que fala sobre RS-232 e diz que há uma limitação de comprimento de cabo de transmissão de 20 metros. É isso mesmo ???
Definitivamente não. Este é um dos muitos mitos que circulam inquestionados há décadas por aí ...
Causo: há muitos anos um colega de trabalho se esgoelava, brandindo seu livrinho, absolutamente inconformado por eu dizer que aquilo era incorreto. Peguei algumas bobinas de fio drop, emendei de modo a obter cerca de 1.000 metros de cabo e conectei a um PC como loopback. Adivinha se funcionou ?
Os tais 20 metros podem sim ser o limite quando a velocidade é muito elevada. Depende das características do cabo e da interface tb. Vc pode esperar alcance da ordem de dezenas a centenas de metros com velocidades baixas ou moderadas.
Falar em distância sem mencionar os outros parâmetros relevantes é algo vazio, desprovido de qualquer sentido.
Isto posto, considere a sugestão do Gil, use RS422 ou RS485, a confiabilidade e o alcance sempre serão muito maiores e em nada onera o projeto.
-
]http://www.postimage.org/image.php?gallery=37gtYc] (http://www.postimage.org/image.php?gallery=37gtYc)
Este é um trecho de inicialização da porta serial, que vai executar uma única vez. Mas conforme já lhe disse, pode dispensar as instruções relacionadas à interrupção.
Basta excluir as duas linhas referentes as interrupções ?
http://www.postimage.org/image.php?v=aVUtpD0
(http://s4.postimage.org/UtpD0.jpg) (http://www.postimage.org/image.php?v=aVUtpD0)
-
Isto posto, considere a sugestão do Gil, use RS422 ou RS485, a confiabilidade e o alcance sempre serão muito maiores e em nada onera o projeto.
Perfeito, vou estudar a forma de utilizar um dos dois métodos.
-
BOM,
A rotina sample do meu código está ficando assim:
(http://s1.postimage.org/S6Pci.jpg) (http://www.postimage.org/image.php?v=gxS6Pci)
GIL, RETIREI OS COMANDOS REFERENTES A INTERRUPÇÕES E NÃO SEI SE ESTÁ TUDO OK ;D
-
Anderson,
Coloque seu programa como texto no corpo da mensagem, para que possa ser editado e alterado.
Voce está usando o MPLAB para testar?
-
Segue programa que eu fiz para testar o conversor A/D do PIC16F877A, simulei no Proteus e funcionou conforme previsto.
list P=16F877A
#include "P16F877A.INC"
__CONFIG _CP_OFF & _WDT_OFF & _XT_OSC & _PWRTE_ON
;__CONFIG 0x3F32
ERRORLEVEL -302 ; turn off bank bits warning
cblock H'20'
endc
; Inicio do Programa
ORG 0h
; Inicialização do PIC e do display
bcf STATUS,RP1
bsf STATUS,RP0 ; Habilita banco 1
clrf TRISD ; porta do display, de saída
movlw B'00000010' ; setup do conversor A/D
movwf ADCON1 ; left justify result
; port A = analogue inputs
bcf STATUS,RP0 ; Habilita banco 0
clrf PORTD ; zera saídas do display
movlw B'01000001' ; setup da entrada
movwf ADCON0 ; f/8, AN0, DONE, A/D On
;
; Loop principal
;
start:
call read_ad
call display
goto start
;
; Conversor A/D
;
read_ad:
bsf ADCON0,GO ; Iniciar conversão
wait:
btfsc ADCON0,GO ; Testa se terminou conversão
goto wait
movf ADRESH,W
return
;
; Display de LEDs
;
display:
movwf PORTD
return
END
Diagrama elétrico:
[attachthumb=1]
-
Apesar do conversor A/D estar funcionando, tenho uma perguntinha básica, não fica +fácil e +robusto usar um joystick baseado em microswitches? Usando 4, dá pra fazer: +X, -X, +Y, -Y. Poderia até usar 4 botões NA, não haveriam duas velocidades para cada movimento.
-
Coloque seu programa como texto no corpo da mensagem, para que possa ser editado e alterado.
Gil, aí está o programa. Fiz algumas alterações com base no código que você enviou e parece-me que está funcionando.
;**************************************************************************************
;* PROJETO DE PLACA DE COMANDO POR MEIO DE JOYSTICK PARA ROV *
;* DESENVOLVIDO POR ANDERSON GUIZAN SILVA *
;* VERSÃO 1.0 DATA 07/2010 *
;*------------------------------------------------------------------------------------------------------------*
;* MODELO DESENVOLVIDO PARA PIC 16F877 *
;**************************************************************************************
;**************************************************************************************
;* ARQUIVOS DE DEFINIÇÕES *
;**************************************************************************************
#INCLUDE <P16F877.INC> ;ARQUIVO PADRÃO DA MICROCHIP PARA PIC16F877
__CONFIG _CP_OFF & _WDT_OFF & _BODEN_ON & _PWRTE_ON & _XT_OSC & _WRT_ENABLE_ON &
_LVP_OFF & _CPD_OFF
ERRORLEVEL -302 ;
;**************************************************************************************
;* PAGINAÇÃO DE MEMÓRIA *
;**************************************************************************************
; DEFINIÇÃO DE COMANDOS DE USUÁRIO PARA ALTERAÇÃO DA PÁGINA DE MEMÓRIA
#DEFINE BANK0 BCF STATUS,RP0 ;SETA BANK 0 DE MEMÓRIA
#DEFINE BANK1 BSF STATUS,RP0 ;SETA BANK 1 DE MEMÓRIA
;************************************************************************************************************
;* VARIÁVEIS *
;************************************************************************************************************
; DEFINIÇÃO DOS NOMES E ENDEREÇOS DE TODAS AS VARIÁVEIS UTILIZADAS PELO SISTEMA
CBLOCK 0X020 ;ENDEREÇO INICIAL DA MEMÓRIA DE USUÁRIO
CNTR1 ;CONTADOR VARIÁVEL TEMPORÁRIO
CNTR2 ;CONTADOR VARIÁVEL TEMPORÁRIO
SER_DATA_1 ;PRIMEIRO BYTE DE DADOS A SER TRANSMITIDO SERIALMENTE
SER_DATA_2 ;SEGUNDO BYTE DE DADOS A SER TRANSMITIDO SERIALMENTE
SER_LOOP_1 ;NUMERO DE LOOPINGS PARA TRANSMISSÃO DOS BITS DO 1º BYTE
SER_LOOP_2 ;NUMERO DE LOOPINGS PARA TRANSMISSÃO DOS BITS DO 2º BYTE
SER_TIME ;TEMPO DE ESPERA DA TRANSMISSÃO
LAST_BTN ;GUARDA ULTIMO ESTADO DO BOTÃO PARA COMPARAÇÃO
CURRENT_BTN ;GUARDA ESTADO ATUAL DO BOTÃO PARA COMPARAÇÃO
BTN_COUNT ;CONTADOR DO NUMERO DE LLOPINGS QUE MANTEM O BOTÃO ACIONADO
LIGHT_STATUS ;GUARDA O ESTADO DO EQUIPAMENTO DE ILUMINAÇÃO
ENDC
;************************************************************************************************************
;* CONSTANTES *
;************************************************************************************************************
; DEFINIÇÃO DE TODAS AS CONSTANTES UTILIZADAS PELO SISTEMA
BTN_RST EQU .200 ;CONTADOR DO TEMPO DE ACIONAMENTO DO BOTÃO
;************************************************************************************************************
;* ENTRADAS *
;************************************************************************************************************
; DEFINIÇÃO DE TODOS OS PINOS QUE SERÃO UTILIZADOS COMO ENTRADA
#DEFINE X_AXIS PORTA,0 ;PINO 2 - ENTRADA DE SINAL ANALÓGICO VINDO DO JOYSTICK - EIXO X
#DEFINE Y_AXIS PORTA,1 ;PINO 3 - ENTRADA DE SINAL ANALÓGICO VINDO DO JOYSTICK - EIXO Y
#DEFINE DEPTH PORTA,2 ;PINO 4 - ENTRADA DE SINAL ANALÓGICO DO POTENCIÔMETRO DE PROFUNDIDADE
#DEFINE BUTTON PORTA,3 ;PINO 2 - ENTRADA DE SINAL DIGITAL VINDO DO BOTÃO - ILUMINAÇÃO
#DEFINE SEROUT PORTA,
;************************************************************************************************************
;* SAÍDAS *
;************************************************************************************************************
; DEFINIÇÃO DE TODOS OS PINOS QUE SERÃO UTILIZADOS COMO SAÍDA
#DEFINE SERIAL_OUT PORTA,4 ;PINO 3 - SAÍDA DE SINAL - TRANSMISSÃO SERIAL
;************************************************************************************************************
;* VETOR DE RESET *
;************************************************************************************************************
ORG 0X00 ;ENDEREÇO INICIAL DE PROCESSAMENTO
GOTO INICIO
;ORG 0X04 ;ENDEREÇO DO VETOR DE INTERRUPÇÃO
;GOTO INTR
;************************************************************************************************************
;* INICIO DO PROGRAMA *
;************************************************************************************************************
INICIO
CLRF PORTA ;LIMPA PORTA
CLRF PORTB ;LIMPA PORTB
BANK0 ;RETORNA AO BANK0
MOVLW 0X0F ;RA4=OUTPUT RA0...RA3=INPUT; DEMAIS SÃO IRRELEVANTES
TRIS PORTA
MOVLW 0XC3 ;TMR0 HABILITADO COM PREESCALER DE 1:16
MOVWF OPTION_REG
;************************************************************************************************************
;* INICIALIZAÇÃO DE VARIÁVEIS *
;************************************************************************************************************
CLRF CURRENT_BTN ;SETA O ESTADO ATUAL DO BOTÃO EM ZERO
CLRF LIGHT_STATUS ;SETA O ESTADO ATUAL DE ILUMINAÇÃO EM ZERO
MOVLW BTN_RST ;CARREGA O VALOR DA CONSTANTE "BTN_RST" NO REGISTRO DE TRABALHO "W"
MOVWF BTN_COUNT ;CARREGA O TIMER DO CONTADOR PARA O VALOR DE START.
GOTO MAIN
;************************************************************************************************************
;* ROTINAS E SUB-ROTINAS *
;************************************************************************************************************
;************************************************************************************************************
;* SAMPLE A/D - RECOLHE AMOSTRAGEM ANALÓGICA E ARMAZENA O VALOR EM "W" *
;************************************************************************************************************
;***CONFIGURANDO O MÓDULO A/D
SAMPLE
MOVWF ADCON0
BANK1
MOVLW 0X82
MOVWF ADCON1 ;CONFIGURA O REGISTRADOR ADCON1 COM: RELOGIO DE CONVERSÃO FOSC/32
;AN0...AN4 ANALÓGICAS AN5...AN7 DIGITAIS JUSTIFICADO A DIREITA
BANK1 ;SELECIONO BANK1
MOVLW 0X86
MOVWF ADCON0 ;CONFIGURA O REGISTRADOR ADCON COM: CONVERSÃO DO RELÓGIO FOSC/32
;CANAL ANALÓGICO=RA1/AN1 CONVERSÃO ATIVADA
;***INICIO DA CONVERSÃO ANALÓGICA/DIGITAL
BANK0
CALL DELAY_100uS ;CERETIFICAR-SE DE QUE O TEMPO COLETA DA AMOSTRAGEM JÁ ACABOU.
;SE ACABOU PODE COMEÇAR A DONVERSÃO
BSF ADCON0,GO ;INICIA A CONVERSÃO A/D.
ESPERA:
BTFSC ADCON0,GO ;TESTA SE TERMONOU A CONVERSÃO
GOTO ESPERA
MOVF ADRESH,W ;COLOCA O RESULTADO NO REGISTRO DE TRABALHO "W"
RETURN ;RETORNA AO PONTO DE ESCAPE PARA A ROTINA
;****************************************************************************************************************
;* DELAY 100uS *
;****************************************************************************************************************
DELAY_100uS
MOVLW .3
MOVWF CNTR1
LOOP NOP
NOP
DECFSZ CNTR1,F
GOTO LOOP
RETURN
;****************************************************************************************************************
;* VERIFICA O STATUS DO BOTÃO - LIGA SERVO E LUZ QUANDO NECESSÁRIO *
;****************************************************************************************************************
BTNTEST
MOVF CURRENT_BTN, W ;ESCREVE EM "W" O ÚLTIMO ESTADO DO BOTÃO
MOVWF LAST_BTN ;...E GUARDA O VALOR EM LAST_BTN
BTFSC LIGHT_STATUS, 0 ;CHECA O VALOR DE LIGHT_STATUS E PULA A PRÓXIMA LINHA SE FOR "0"
BSF SER_DATA_1, 7 ;...E UPDATE O BIT 7 (ILUMINAÇÃO)
BTN_DWN
BTFSS BUTTON ;CHECA O ESTADO DO BOTÃO E SE ESTE ESTIVER EM "1" PULA A PRÓXIMA LINHA
GOTO BTN_UP
BSF CURRENT_BTN, 0
MOVF BTN_COUNT, F
BTFSS STATUS, Z
DECF BTN_COUNT, F
BTFSC STATUS, Z
BSF SER_DATA_1, 6
RETURN
BTN_UP
CLRF CURRENT_BTN
BTFSS LAST_BTN, 0
RETURN
;****************************************************************************************************************
;* SUBROTINA DE TRANSMISSÃO SERIAL *
;****************************************************************************************************************
;* TRANSMITE O CONTEÚDO DOS DADOS CONTIDOE EM SER_DATA_1 E SER_DATA_2 COM BIT DE START, 16 BITS DE DADOS E UM BIT
;* DE PARADA (STOP BIT). TRANSMISSÃO EXECUTADA A 19.2 KBPs
SERIAL
MOVLW .9 ;8 BITS DE DADOS + 1 BIT DE COMEÇO (START BIT)
MOVWF SER_LOOP_1 ;1º BYTE
MOVLW .8 ;8 BITIS DE DADOS PARA O SEGUNDO BYTE
MOVWF SER_LOOP_2
BSF STATUS, C ;
;************************************************************************************************************
;* ROTINA PRINCIPAL *
;************************************************************************************************************
MAIN
MOVLW 0X81 ;CANAL 0, PINO 2 RA0, AN0, A/D ON
CALL SAMPLE
ANDLW 0XE0 ;MASCARAR OS TRÊS BITS MAIS SIGNIFICATIVOS, COLOCA O RESULTADO EM "W"
MOVWF SER_DATA_1 ;SER_DATA_1 = [X7 X6 X5 0, O 0 0 0]
RRF SER_DATA_1, F
RRF SER_DATA_1, F
RRF SER_DATA_1, F ;SER_DATA_1 = [0 0 0 X7, X6 X5 0 O 0]
MOVLW 0X89 ;CANAL 1, PINO 3 RA1, AN1, A/D ON
CALL SAMPLE ;VAI PARA A ROTINA SAMPLE
ANDLW 0XE0 ;MASCARAR OS TRÊS BITS MAIS SIGNIFICATIVOS, COLOCA O RESULTADO EM "W"
ADDWF SER_DATA_1, F ;SER_DATA_1 = [Y7 Y6 Y5 X7, X6 X5 O O]
RRF SER_DATA_1, F
RRF SER_DATA_1, F ;SER_DATA_1 = [0 0 Y7 Y6, Y5 X7 X6 X5]
MOVLW 0X91 ;CANAL 2, PINO 4 RA2, AN2, A/D ON
CALL SAMPLE ;VAI PARA A ROTINA SAMPLE
MOVWF SER_DATA_2 ;SEGUNDO BYTE DO DADO SERIAL
CALL BTNTEST ;CHECA ESTADO DO BOTÃO E AJUSTA BITS DO SERVO E ILUMINAÇÃO
CALL SERIAL
END
Voce está usando o MPLAB para testar?
[/quote]
-
Apesar do conversor A/D estar funcionando, tenho uma perguntinha básica, não fica +fácil e +robusto usar um joystick baseado em microswitches?
O primeiro protótipo que fiz funcionava assim, baseado em microswitches. Os problemas que encontrei foram:
1) No projeto que desenvolvi a comunicação precisava de várias vias para levar os sinais aos relés de acionamento dos motores, ficando com um cabo umbilical muito grosso.
2) Os relés ocupam um espaço muito grande dentro do equipamento e causam muito ruído, interferindo com a câmera de vídeo.
3) Esses Joysticks não são precisos em seus comandos.
-
Anderson,
Gil, aí está o programa. Fiz algumas alterações com base no código que você enviou e parece-me que está funcionando.
Onde foi testado?
-
Apesar do conversor A/D estar funcionando, tenho uma perguntinha básica, não fica +fácil e +robusto usar um joystick baseado em microswitches?
O primeiro protótipo que fiz funcionava assim, baseado em microswitches. Os problemas que encontrei foram:
1) No projeto que desenvolvi a comunicação precisava de várias vias para levar os sinais aos relés de acionamento dos motores, ficando com um cabo umbilical muito grosso.
2) Os relés ocupam um espaço muito grande dentro do equipamento e causam muito ruído, interferindo com a câmera de vídeo.
3) Esses Joysticks não são precisos em seus comandos.
Não falo em usar relés e enviar os sinais por vários fios, mas apenas usar joysticks com microchaves. Mas se não são confiáveis esqueça...
-
Não falo em usar relés e enviar os sinais por vários fios, mas apenas usar joysticks com microchaves. Mas se não são confiáveis esqueça...
O Joystick que utilizei é para arcade, extremamente robusto, não gostei do resultado. Veja as fotos:
(http://s4.postimage.org/2BWxi.jpg) (http://www.postimage.org/image.php?v=aV2BWxi)
(http://s1.postimage.org/U9Cg0.jpg) (http://www.postimage.org/image.php?v=gxU9Cg0)
-
Onde foi testado?
Testei no MPLAB
-
Então vc só está compilando no MPLAB não é?
Apesar de poder estar compilando, a sua rotina serial não está correta, também não há código de incialização da UART.
-
Apesar de poder estar compilando, a sua rotina serial não está correta.
Ainda estou terminando essa rotina...
, também não há código de incialização da UART.
Lembro-me de já haver algum comentário a repeito da UART anteriormente. Vou procurar por aqui.
...Encontrei algo:
Basta configurar o registro TXSTA ?
-
Apesar de poder estar compilando, a sua rotina serial não está correta,
A ROTINA SERIAL FICOU ASSIM:
;****************************************************************************************************************
;* SUBROTINA DE TRANSMISSÃO SERIAL *
;****************************************************************************************************************
;* TRANSMITE O CONTEÚDO DOS DADOS CONTIDOE EM SER_DATA_1 E SER_DATA_2 COM BIT DE START, 16 BITS DE DADOS E UM BIT
;* DE PARADA (STOP BIT). TRANSMISSÃO EXECUTADA A 19.2 KBPs
SERIAL
MOVLW .9 ;8 BITS DE DADOS + 1 BIT DE COMEÇO (START BIT)
MOVWF SER_LOOP_1 ;1º BYTE
MOVLW .8 ;8 BITIS DE DADOS PARA O SEGUNDO BYTE
MOVWF SER_LOOP_2
BSF STATUS,C ;
OUT_1
BTFSC STATUS,C
BSF SEROUT
BTFSS STATUS,C
BCF SEROUT
MOVLW .14
MOVWF SER_TIME
OUT_2
DECFSZ SER_TIME,F
GOTO OUT_2
NOP
RRF SER_DATA_1,F
DECFSZ SER_LOOP_1,F
GOTO OUT_1
OUT_3
RRF SER_DATA_2,F
BTFSC STATUS,C
BSF SEROUT
BTFSS STATUS,C
BCF SEROUT
MOVLW .14
MOVWF SER_TIME
OUT_4
DECFSZ SER_TIME,F
GOTO OUT_4
NOP
DECFSZ SER_LOOP_2,F
GOTO OUT_3
BCF SEROUT
MOVLW .14
MOVWF SER_TIME
OUT_5
DECFSZ SER_TIME,F
GOTO OUT_5
NOP
RETURN
-
Anderson,
Seu programa é do tipo "bit-bang" e não está usando os registradores da UART (foi feito para o PIC16F84)... Para começar, voce não precisa carregar a quantidade de bits a cada envio e gerar a temporização a cada bit, se for usar a UART.
A sua rotina poderia ficar com 4 ou 5 linhas se voce usar a UART interna do PIC. E acho que o "debug" é mais fácil se usar a UART interna.
Isto não é indispensável, mas entendi que iria isar a UART não é?
-
A sua rotina poderia ficar com 4 ou 5 linhas se voce usar a UART interna do PIC. E acho que o "debug" é mais fácil se usar a UART interna.
Isto não é indispensável, mas entendi que iria isar a UART não é?
Bem que eu quero, mas ainda não entendi como fazer. Tem alguma fonte onde eu possa estudar ?? No Datasheet somente achei uma forma de configurar a "USART" no modo asincrono, é por aí ?
-
Para ilustrar esse bate papo quem quiser ver um ROV funcionando veja o filme:
-
A sua rotina poderia ficar com 4 ou 5 linhas se voce usar a UART interna do PIC. E acho que o "debug" é mais fácil se usar a UART interna.
Isto não é indispensável, mas entendi que iria isar a UART não é?
Bem que eu quero, mas ainda não entendi como fazer. Tem alguma fonte onde eu possa estudar ?? No Datasheet somente achei uma forma de configurar a "USART" no modo asincrono, é por aí ?
Sim, é por ai...
Há muitas fontes sobre uso da UART e USART com PICs, inclusive vários Application Notes no site da Microchip.
-
eu tenho acompanhado este tópico ... e vejo que as informações são bem assimiladas pelo colega forista ... mas uma coisa que eu quero perguntar, apenas a título de curiosidade por não ter visto isso em nenhum post anterior ... Porquê a programação é em Assembly e não em C ? Veja bem ... não digo que esta ou aquela é melhor que a outra ... mas é que pelo "bloqueio" que tenho em desenvolver firmwares em ASM então quando acompanho tópicos com tanta atenção do pessoal eu fico meio q "viajando" ...
-
Porquê a programação é em Assembly e não em C ?
Posso estar errado mas acredito que se eu conseguir dominar um pouco de assembler terei mais facilidade com outras linguagens.
-
Porquê a programação é em Assembly e não em C ?
Posso estar errado mas acredito que se eu conseguir dominar um pouco de assembler terei mais facilidade com outras linguagens.
Basicamente ambas são linguagens mas possuem estruturas de contrução de programas bem diferentes. Desse modo, a linguagem assembly ajudaria parcialmente no entendimento da linguagem C.
Além disso, C proporciona maior facilidade de criação, debug e de entendimento do programa. Por outro lado, para economia de recursos (de memória e tempo de processamento), o assembly é bem melhor. Gerando programas menores e mais velozes. Importante em algumas aplicações mais críticas.
Essa economia geralmente é mais importante em sistemas que dispõe de pouca memória ou programas muito grandes para a memória disponível.
Um fator critico ao usar o C ou outra linguagem de mais alto nível (Basic, Forth, Pascal, C#) é a qualidade do compilador e isto é frequentemente desprezado. Pois no final do processo da compilação, é gerado um programa assembly, que é traduzido para linguagem de máquina, que será carregado do microcontrolador. Se esse programa assembly estiver errado (já vi acontecer) ou for grande, há desvantagens no uso de linguagem de nível +alto. E qualidade se compra e custa caro frequentemente.
Assembly também permite que se esteja mais próximo do hardware do microcontrolador, acessando registradores com todas as suas vantagens (velocidade) e limitações (troca de bancos de memória). Permite entender o que é um microcontrolador em detalhes, o que facilitará outros projetos ou a melhoria de um projeto. Mas para o programador eventual, pode ser mais trabalhoso.
Para mim, usar assembly é como guiar um modelo de carro de passeio adaptado para carro de corrida, não há bancos bonitos, não há estofamento interno, os faróis são básicos, ... Ou seja assembly é muito mais poderoso....
Conheço e uso bastante as duas linguagens. Mas tenho preferência pelo assembly pelas razões que expûs e também por que não disponho de um compilador gratuito de boa qualidade, exceto para os PIC18F2550 ou 4550, para os quais a Microchip disponibiliza.
Geralmente, com microcontroladores, eu uso o assembly sempre que possível. Mas se aplicação é mais complexa (usa Ethernet, TCP/IP, USB, acesso a drives de memória de alta capacidade, acessa muitas informações estuturadas ...), aí fujo dele rápido para o C.
-
aguizan
entendo ... :) não está errado, é bom conhecer ASM até mesmo pq em muitos aplications notes o código disponível é em ASM, e se não conhecer, vc pode ficar igual a mim, perdido algumas vezes.
minilathe
concordo com sua opnião, porém eu entendo que cada vez mais as memórias dos microcontroladores terão maior capacidade (ARM por exemplo alguns com 512k de memória!), mas o conhecimento em ASM não pode ser desprezado.
Não sou conhecedor, não fiz nada de muita exigência de tempo, mas ainda não vi aplicações em que fossem necessário colocar um poquim de ASM nos códigos.
Com tudo isso, vejo que com o tempo apenas a questão "tempo de processamento" será o que fará com que se utilize ASM. :)
abrax!
-
Anderson,
Para ilustrar esse bate papo quem quiser ver um ROV funcionando veja o filme:
Muito bacana esse ROV, percebi que possui vários eixos de liberdade, além de x e y, há eixos de rotação em torno dos eixos (x, z?). Usar um PIC de maior capacidade (quantidade de portas, memória) vai ajudar.
Se puder responder,... tenho visto que ROVs são normalmente usados na área de petróleo (off-shore), para achar navios naufragados,.... para que pretende usar o seu?
-
Se puder responder,... tenho visto que ROVs são normalmente usados na área de petróleo (off-shore), para achar navios naufragados,.... para que pretende usar o seu?
Estou pesquisando a construção com materiais alternativos, mas as utilizações são inúmeras desde a área petrolífera, inspeção de estruturas e cascos de embarcações, inspeção de tubulações, pesquisa, etc, etc, etc. A parte mecânica eu já tenho quase toda resolvida o que está pegando é a eletrônica que ainda preciso aprender e nesse ponto o fórum tem sido de enorme importância.
-
aguizan
No ano passado, fiz um controle com RF simples de 2 motores DC para o PIPA da faculdade (PIPA é a sigla de Projeto Interdisciplinar de Pesquisa Acadêmica) e devido a necessidade de controlar 2 motores ao mesmo tempo eu utilizei um PIC18F252, tem 2 PWM, serial, AD ... ou seja tudo o que eu precisava para o meu trabalho, montei em protoboard e funcionou certinho apenas sem o módulo RF, mas toda a programação foi feita em C (compilador CCS) e devido a dificuldes profissionais não terminei o trabalho e o semestre. :-\
Vou procurar o esquema e disponibilizo para que você possa estudar e talvez utilizar alguma coisa em seu projeto.
abrax!
-
aguizan
No ano passado, fiz um controle simples de 2 motores DC para o PIPA da faculdade, devido a necessidade de controlar 2 motores ao mesmo tempo eu utilizei um PIC18F252, tem 2 PWM, serial, AD ... ou seja tudo o que eu precisava para o meu trabalho, montei em protoboard e funcionou certinho, mas toda a programação foi em C (compilador CCS) e devido a dificuldes profissionais não terminei o trabalho.
Vou procurar o esquema e disponibilizo para que você possa estudar e talvez utilizar alguma coisa em seu projeto.
abrax!
Blz,
Agradeço desde já. Toda colaboração é bem vinda.
-
A sua rotina poderia ficar com 4 ou 5 linhas se voce usar a UART interna do PIC. E acho que o "debug" é mais fácil se usar a UART interna.
Bom, vamos ver se consigo. Iniciei uma rotina com utilização do módulo UART conforme abaixo. Estou no caminho???
;
;******************************************************************************
;* SUBROTINA DE TRANSMISSÃO SERIAL utilizando o módulo UART *
;******************************************************************************
BANK1
CLRF TRISA ;PORTA DE SAÍDA
MOVLW "01100100" ;SETUP DA TRANSMISSÃO
MOVWF TXSTA
BANK0
CLRF PORTA
MOVLW "11011000"
MOVWF RCSTA
-
Anderson,
Pra te ajudar, fiz o teste a seguir no Proteus, coloquei o trecho com conversor A/D e a porta serial. A cada segundo, o PIC lê da entrada analógica e escreve na porta serial. Conforme mostra a simulação da figura abaixo, onde os valores no terminal são os valores em binários enviados pela UART ao terminal (que seria um PC ou um outro microcontrolador).
Eu fui variando o potenciômetro, por isso os valores no terminal mudam com o tempo.
[attachthumb=1]
Programa asm:
list P=16F877A
#include "P16F877A.INC"
__CONFIG _CP_OFF & _WDT_OFF & _XT_OSC & _PWRTE_ON
;__CONFIG 0x3F32
errorlevel -302 ; turn off bank bits warning
cblock H'20'
ld_loop_ex
ld_loop_in
endc
; Inicio do Programa
ORG 0h
; Inicializaçao do PIC, do display e da porta serial
bcf STATUS,RP1
bsf STATUS,RP0 ; Habilita banco 1
clrf TRISD ; porta do display, de saída
movlw B'00000010' ; setup do conversor A/D
movwf ADCON1 ; left justify result
; port A = analogue inputs
;
; Ajusta parametros da UART (usando cristal externo de 4MHz)
; Baud Rate = 9600 bps, No Parity, 1 Stop Bit
;
movlw 0x19 ; 0x19=9600 bps / 0x0C=19200 bps
movwf SPBRG
movlw b'00100100' ; TX_Enable, assync. mode, brgh = high (2)
movwf TXSTA ; enable Async Transmission, BRGH=1
movlw b'10111111' ; RC6 saida, outros bits da PORTC são de entrada
movwf TRISC
bcf STATUS,RP0 ; Habilita banco 0
clrf PORTD ; zera saídas do display
movlw B'01000001' ; setup da entrada
movwf ADCON0 ; f/8, AN0, DONE, A/D On
movlw b'01000000' ; Setup Port C
movwf PORTC ; RC6(TX)=1 others are 0
movlw b'10000000' ; habilita a UART
movwf RCSTA
;
; Loop principal
;
start:
call read_ad
call display
call send
call delay250ms
call delay250ms
call delay250ms
call delay250ms
goto start
;
; Conversor A/D
;
read_ad:
bsf ADCON0,GO ; Iniciar conversao
wait:
btfsc ADCON0,GO ; Testa se terminou conversao
goto wait
movf ADRESH,W
return
;
; Display de LEDs
;
display:
movwf PORTD
return
;
; Envia byte (contido em W) pela UART e espera terminar
;
send:
movwf TXREG ; send data in W
TransWt:
bsf STATUS,RP0 ; banco 1
WtHere:
btfss TXSTA,TRMT ; Transmissão terminou se TRUE
goto WtHere ; Senão, espera
bcf STATUS,RP0 ; banco 0
return
;
;-----------------------------------------------------------------------------
;
; Delay for about 250 ms
;
delay250ms:
movlw D'250'
goto waitx400
;
;-----------------------------------------------------------------------------
;
; Delay for about 400x cycles
;
; Se w=1, temporiza 1ms @ fck = 4MHz
;
waitx400:
movwf ld_loop_ex
ld_loopex:
movlw (400-4)/4
movwf ld_loop_in
ld_loopin:
decf ld_loop_in,F
skpz
goto ld_loopin
decf ld_loop_ex,F
skpz
goto ld_loopex
return
END
Agora é contigo....
-
Anderson,
Pra te ajudar,
Gil, você não tem idéia de como ajudou. Agradeço muito. Vou agora mesmo trabalhar e estudar seu código.
Grato
-
Eu fui variando o potenciômetro, por isso os valores no terminal mudam com o tempo.
Agora é contigo....
Gil,
No projeto, cada potenciômetro enviará um sinal analógico que depois de convertido terá que ser acumulado até formar uma "palavra" com todas as informações para um estado específico. Isso posso fazer como na rotina que lhe havia enviado, mascarando três bits e deslocando-os até completar o byte para transmissão ?
-
Anderson,
No projeto, cada potenciômetro enviará um sinal analógico que depois de convertido terá que ser acumulado até formar uma "palavra" com todas as informações para um estado específico. Isso posso fazer como na rotina que lhe havia enviado, mascarando três bits e deslocando-os até completar o byte para transmissão ?
A partir do conversor A/D do PIC16F877, cada potenciômetro gera um sinal de 10 bits (1024 níveis) ou 8 bits (256 níveis), depedendo da palavra que for utilizar. Porém, voce só vai enviar 3 bits (8 níveis), é só mascarar os bits +significativos da saída do A/D (equivale a dividir por 25). Apesar de usar tres bits, acho que o projeto original usa menos do que 8 níveis, se for fazer assim, seria necessário fazer alguma outra conta ou usar uma tabela. Já que vai enviar tres bits..., eu usaria os tres bits com 8 níveis e faria um ROV com maior resolução de movimentação.
-
Dei uma lida no programa receptor, o projeto na verdade usa 7 níveis: 3 para frente, 3 para tras e um parado, como mostrado a seguir:
;********************************************************************************
;* Constants Declaration *
;********************************************************************************
; the duty cycle of the DC motors ranges from 0% to 100% and is represented by
; 0 to 200
STOP equ .0 ; motor stopped, 0% duty cycle
SLOW equ .75 ; motor slow speed, 25% duty cycle
MED equ .150 ; motor medium speed, 50% duty cycle
FAST equ .200 ; motor fast speed, 100% duty cycle
Ou seja, um nível, dos 8 possíveis do transmissor, fica sem uso no receptor.
-
A partir do conversor A/D do PIC16F877, cada potenciômetro gera um sinal de 10 bits (1024 níveis) ou 8 bits (256 níveis), depedendo da palavra que for utilizar. Porém, voce só vai enviar 3 bits (8 níveis), é só mascarar os bits +significativos da saída do A/D (equivale a dividir por 25).
ASSIM ?
;------------------------------------------------------------------------------------------------------------
; ROTINA PRINCIPAL
;------------------------------------------------------------------------------------------------------------
MAIN
MOVLW 0X81 ;ADCON0 (CANAL 0, PINO 2 RA0, AN0, A/D ON)
CALL CONVERTE
Aqui estou retornando da minha conversão
ANDLW 0XE0 ;MASCARAR OS TRÊS BITS MAIS SIGNIFICATIVOS, COLOCA O RESULTADO EM "W"
MOVWF SER_DATA_1 ;SER_DATA_1 = [X7 X6 X5 0, O 0 0 0]
RRF SER_DATA_1, F
RRF SER_DATA_1, F
RRF SER_DATA_1, F ;SER_DATA_1 = [0 0 0 X7, X6 X5 0 O 0]
MOVLW 0X89 ;ADCON0 (CANAL 1, PINO 3 RA1, AN1, A/D ON)
CALL CONVERTE ;VAI PARA A ROTINA SAMPLE
ANDLW 0XE0 ;MASCARAR OS TRÊS BITS MAIS SIGNIFICATIVOS, COLOCA O RESULTADO EM "W"
ADDWF SER_DATA_1, F ;SER_DATA_1 = [Y7 Y6 Y5 X7, X6 X5 O O]
RRF SER_DATA_1, F
RRF SER_DATA_1, F ;SER_DATA_1 = [0 0 Y7 Y6, Y5 X7 X6 X5]
MOVLW 0X91 ;ADCON0 (CANAL 2, PINO 4 RA2, AN2, A/D ON)
CALL CONVERTE ;VAI PARA A ROTINA SAMPLE
MOVWF SER_DATA_2 ;SEGUNDO BYTE DO DADO SERIAL
CALL BTNTEST ;CHECA ESTADO DO BOTÃO E AJUSTA BITS DO SERVO E ILUMINAÇÃO
CALL ENVIA
END
Apesar de usar tres bits, acho que o projeto original usa menos do que 8 níveis, se for fazer assim, seria necessário fazer alguma outra conta ou usar uma tabela. Já que vai enviar tres bits..., eu usaria os tres bits com 8 níveis e faria um ROV com maior resolução de movimentação.
Isso agora eu não entendi ;D
Não havia lido sua última mensagem. Agora como só resta um nível, no 2º Byte de transmissão eu não poderia fazer o mesmo que no 1º e com isso ganhar mais níveis ?? Será que entendi direito ???
-
Anderson,
------------------------------------------------------------------------------------------------------------
; ROTINA PRINCIPAL
;------------------------------------------------------------------------------------------------------------
MAIN
MOVLW 0X81 ;ADCON0 (CANAL 0, PINO 2 RA0, AN0, A/D ON)
CALL CONVERTE
Aqui estou retornando da minha conversão
ANDLW 0XE0 ;MASCARAR OS TRÊS BITS MAIS SIGNIFICATIVOS, COLOCA O RESULTADO EM "W"
MOVWF SER_DATA_1 ;SER_DATA_1 = [X7 X6 X5 0, O 0 0 0]
RRF SER_DATA_1, F
RRF SER_DATA_1, F
RRF SER_DATA_1, F ;SER_DATA_1 = [0 0 0 X7, X6 X5 0 O 0]
MOVLW 0X89 ;ADCON0 (CANAL 1, PINO 3 RA1, AN1, A/D ON)
CALL CONVERTE ;VAI PARA A ROTINA SAMPLE
ANDLW 0XE0 ;MASCARAR OS TRÊS BITS MAIS SIGNIFICATIVOS, COLOCA O RESULTADO EM "W"
ADDWF SER_DATA_1, F ;SER_DATA_1 = [Y7 Y6 Y5 X7, X6 X5 O O]
RRF SER_DATA_1, F
RRF SER_DATA_1, F ;SER_DATA_1 = [0 0 Y7 Y6, Y5 X7 X6 X5]
MOVLW 0X91 ;ADCON0 (CANAL 2, PINO 4 RA2, AN2, A/D ON)
CALL CONVERTE ;VAI PARA A ROTINA SAMPLE
MOVWF SER_DATA_2 ;SEGUNDO BYTE DO DADO SERIAL
CALL BTNTEST ;CHECA ESTADO DO BOTÃO E AJUSTA BITS DO SERVO E ILUMINAÇÃO
CALL ENVIA
END[/size]
Parece que está certo, teria que simular. Acho que tem que zerar o Carry Bit (Status register) antes da soma (ADDWF).
Apesar de usar tres bits, acho que o projeto original usa menos do que 8 níveis, se for fazer assim, seria necessário fazer alguma outra conta ou usar uma tabela. Já que vai enviar tres bits..., eu usaria os tres bits com 8 níveis e faria um ROV com maior resolução de movimentação.
Isso agora eu não entendi ;D
Esqueça..., falei demais :), eu não lembrava do programa.
-
Parece que está certo, teria que simular. Acho que tem que zerar o Carry Bit (Status register) antes da soma (ADDWF).
No trecho da rotina de conversão A/D está travando
;***CONFIGURANDO O MÓDULO A/D
CONVERTE
MOVWF ADCON0
BANK1 ;seleciona BANK1
MOVLW 0X82 ;setup do conversor A/D
MOVWF ADCON1 ;CONFIGURA O REGISTRADOR ADCON1 COM: RELOGIO DE CONVERSÃO FOSC/32
;AN0...AN4 ANALÓGICAS AN5...AN7 DIGITAIS JUSTIFICADO A DIREITA
BANK1 ;SELECIONO BANK1
MOVLW 0X86
MOVWF ADCON0 ;CONFIGURA O REGISTRADOR ADCON COM: CONVERSÃO DO RELÓGIO FOSC/32
;CANAL ANALÓGICO=RA1/AN1 CONVERSÃO ATIVADA
;***INICIO DA CONVERSÃO ANALÓGICA/DIGITAL
BANK0
BSF ADCON0,GO ;INICIA A CONVERSÃO A/D.
ESPERA:
btfsc ADCON0,GO ;TESTA SE TERMONOU A CONVERSÃO
GOTO ESPERA
MOVF ADRESH,W ;COLOCA O RESULTADO NO REGISTRO DE TRABALHO "W"
RETURN ;RETORNA AO PONTO DE ESCAPE PARA A ROTINA
No "loop" está travado ou demora muito para sair na simulção ?
-
Lendo no manual, achei alguns erros, na escrita no registro ADDCON0, os valores estão errados.
Como assim está travando? Se for no MPLAB, é necessário verificar se este simula o conversor A/D, senão vai travar mesmo.
No Proteus funcionou.
-
Lendo no manual, achei alguns erros, na escrita no registro ADDCON0, os valores estão errados.
Como assim está travando? Se for no MPLAB, é necessário verificar se este simula o conversor A/D, senão vai travar mesmo.
No Proteus funcionou.
Quando instalei o Proteus na realidade foraqm instalados o ISIS e o ARES. Falta algo ???
-
Vc instalou as bibliotecas? A simulação não funciona no Proteus?
-
Vc instalou as bibliotecas? A simulação não funciona no Proteus?
Sim funciona no ISIS. Pelo Visto eu não tenho o Proteus. O proteus funciona com editor dos programas???
-
esclarecendo ... o Proteus é o nome do software para desenho (CAD) e simulação (CAE) dos esquemas e programas feitos pelos desenvolvedores.
O ISIS (CAD esquemas) e o ARES (CAD PCB) são os aplicativos do Proteus, então quando falar em simular ou desenhar o esquema você sempre utilizará o ISIS, quando chegar o ponto de você desenhar (ou rotear) as placas de circuito impresso você utilizará o ARES.
Quanto ao fato do Proteus "travar", existem alguns componentes que não são simulados devido a não ter o "modelo matemático" do componente, então o Proteus não entenderá como será o funcionamento daquele componente e vai 1 - avisar do problema, 2 - travar o software, claro que isso ainda vai depender do computador que você tem para trabalhar e do estado dele.
-
esclarecendo ... o Proteus é o nome do software para desenho (CAD) e simulação (CAE) dos esquemas e programas feitos pelos desenvolvedores.
O ISIS (CAD esquemas) e o ARES (CAD PCB) são os aplicativos do Proteus, então quando falar em simular ou desenhar o esquema você sempre utilizará o ISIS, quando chegar o ponto de você desenhar (ou rotear) as placas de circuito impresso você utilizará o ARES.
Concluindo eu não tenho o PROTEUS. No meu computador tenho o ISIS e ARES o software que escreve o programa e que eu uso é o MPLAB
-
Concluindo eu não tenho o PROTEUS
ok ... tudo bem ... :-X
http://www.labcenter.com/products/vsm_overview.cfm
-
Lendo no manual, achei alguns erros, na escrita no registro ADDCON0, os valores estão errados.
Estou a tanto tempo estudando que estou ficando meio confuso ....
No registro ADCON0 quando seleciono o "channel" estou selecionando os meus pinos de entrada ou saída de sinal correto. Então se eu seleciono o canal 0, na realidade eu selecionei o pino 2 RA0/AN0, mas os outros pinos ?
-
Anderson, já que vc está reescrevendo o prog pra tirar partido das características de um PIC mais avançado, acho que vale a pena cogitar em utilizar o AD com plena resolução (um byte para cada canal) e aperfeiçoar a comunicação implementando verificação da integridade dos dados, algo como CRC ou mesmo simples checksum. Talvez implementar tb handshaking. Isto onera muito pouco o desenvolvimento mas melhora significativamente a confiabilidade. De quebra melhora tb a modularidade do prog ...
-
Anderson, já que vc está reescrevendo o prog pra tirar partido das características de um PIC mais avançado, acho que vale a pena cogitar em utilizar o AD com plena resolução (um byte para cada canal) e aperfeiçoar a comunicação implementando verificação da integridade dos dados, algo como CRC ou mesmo simples checksum. Talvez implementar tb handshaking. Isto onera muito pouco o desenvolvimento mas melhora significativamente a confiabilidade. De quebra melhora tb a modularidade do prog ...
Todas as sugestões são muito bem vindas. Quanto a utilização de canais independentes você pode me explicar melhor. Acho que estou fazendo confusão exatamente nesta questão conforme minha citação anterior.
-
[info]bit 5-3 CHS2:CHS0: Analog Channel Select bits
000 = Channel 0 (AN0)
001 = Channel 1 (AN1)
010 = Channel 2 (AN2)
011 = Channel 3 (AN3)
100 = Channel 4 (AN4)
101 = Channel 5 (AN5)
110 = Channel 6 (AN6)
111 = Channel 7 (AN7) [/info]
(http://s2.postimage.org/Jtsdr.jpg) (http://www.postimage.org/image.php?v=TsJtsdr)
-
[info]bit 5-3 CHS2:CHS0: Analog Channel Select bits
000 = Channel 0 (AN0)
001 = Channel 1 (AN1)
010 = Channel 2 (AN2)
011 = Channel 3 (AN3)
100 = Channel 4 (AN4)
101 = Channel 5 (AN5)
110 = Channel 6 (AN6)
111 = Channel 7 (AN7) [/info]
Então eu posso fazer um laço para selecionar um por vez todos os caniais que vou utilizar e a cada passada eu já faço a conversão AD e vou mascarando de três em três bits até completar meu Byte para transmissão. Pode ser assim, não é?
-
Pode ser assim, não é?
Pode.
-
Anderson,
[info]bit 5-3 CHS2:CHS0: Analog Channel Select bits
000 = Channel 0 (AN0)
001 = Channel 1 (AN1)
010 = Channel 2 (AN2)
011 = Channel 3 (AN3)
100 = Channel 4 (AN4)
101 = Channel 5 (AN5)
110 = Channel 6 (AN6)
111 = Channel 7 (AN7) [/info]
Então eu posso fazer um laço para selecionar um por vez todos os caniais que vou utilizar e a cada passada eu já faço a conversão AD e vou mascarando de três em três bits até completar meu Byte para transmissão. Pode ser assim, não é?
Primeiramente, deve-se dividir o problema à "La Jack" (por partes)...
Eu faria desse jeito:
(1) Ler todas as entradas (analógicas e digitais)
(2) Enviar todos os sinais via porta serial
Isso garante que o tempo entre leituras será mínimo e o estado do sistema (joystick, chaves, ...) será amostrado de maneira completa a cada varredura.
O conversor A/D do PIC16F877A possui um tipo de "chave" interna (multiplexador) que a cada comando de leitura (instrução de escrita nos bits CHS0..CHS2 de ADDCON0), seleciona qual entrada do multiplexador (ou pino do microcontrolador) será amostrada e posteriormente convertida para o formato digital. Como a figura a seguir:
[attachthumb=1]
O sinal de saída do poteciômetro é conectado ao conversor A/D, de preferência, usando a mesma base de tensão de referência, mínima e máxima, para minimizar os erros. Normalmente se usa o +5 e 0V (GND), mas sendo talvez excessivamente purista, pode existir uma pequena discrepância entre o +5V do potenciômetro e o +Vref do conversor A/D. Sendo 5/256 = 19mV ou 5/1024 = 4,9mV, que seria a tolerância de erro do sistema. Como serão usadas apenas 7 faixas para cada potenciômetro e 256 níveis no conversor A/D, essa diferença seria desprezível e sem importância se a montagem possuir adequados filtros e desacoplamentos. Bem como ter cuidado em usar pontos comuns de aterramento (0V) e de alimentação (+5V) dos potenciômetros e do conversor A/D.
Mas por enquanto vamos pular essa parte.
-
Vale a pena uma espiada:
[info]Using the Analog to Digital Converter
http://ww1.microchip.com/downloads/en/AppNotes/00546e.pdf[/info]
-
O que o Jorge mandou vale a pena ler, sobre a tensão de referência, principalmente:
[attachthumb=1]
Melhorei o programa e a simulação, agora lê e envia tres entradas analógicas. O terminnal mostra o envio sequenciado de AN0 (0% = 0), AN1 (50%=7F) e AN2 (100%=FF).
[attachthumb=2]
Programa assembly:
list P=16F877A
#include "P16F877A.INC"
__CONFIG _CP_OFF & _WDT_OFF & _XT_OSC & _PWRTE_ON
;__CONFIG 0x3F32
errorlevel -302 ; turn off bank bits warning
;
; Seleção de entradas do MUX (ADDCON0)
;
#DEFINE EAN_0 B'01000001' ; f/8, AN0, DONE, A/D On
#DEFINE EAN_1 B'01001001' ; f/8, AN1, DONE, A/D On
#DEFINE EAN_2 B'01010001' ; f/8, AN2, DONE, A/D On
;
; Variáveis da RAM internas
;
cblock H'20'
ld_loop_ex
ld_loop_in
endc
;
; Inicio do Programa
;
ORG 0h
; Inicializaçao do PIC, do display e da porta serial
bcf STATUS,RP1
bsf STATUS,RP0 ; Habilita banco 1
clrf TRISD ; porta do display, de saída
movlw B'00000010' ; setup do conversor A/D
movwf ADCON1 ; left justify result
; port A: only analogue inputs
;
; Ajusta parametros da UART (usando cristal externo de 4MHz)
; Baud Rate = 9600 bps, No Parity, 1 Stop Bit
;
movlw 0x19 ; 0x19=9600 bps / 0x0C=19200 bps
movwf SPBRG
movlw b'00100100' ; TX_Enable, assync. mode, brgh = high (2)
movwf TXSTA ; enable Async Transmission, BRGH=1
movlw b'10111111' ; RC6 saida, outros bits da PORTC sao de entrada
movwf TRISC
bcf STATUS,RP0 ; Habilita banco 0
clrf PORTD ; zera saídas do display
; movlw EAN_0 ; seleciona entrada analógica
; movwf ADCON0
movlw b'01000000' ; Setup Port C
movwf PORTC ; RC6(TX)=1 others are 0
movlw b'10000000' ; habilita a UART
movwf RCSTA
;
; Loop principal
;
start:
movlw EAN_0 ; entrada analógica 0
call read_ad
call display
call send
call delay1s
movlw EAN_1 ; entrada analógica 1
call read_ad
call display
call send
call delay1s
movlw EAN_2 ; entrada analógica 2
call read_ad
call display
call send
call delay1s
goto start
;
; Conversor A/D, palavra ADDCON0 em W
;
read_ad:
movwf ADCON0
bsf ADCON0,GO ; Iniciar conversao
wait:
btfsc ADCON0,GO ; Testa se terminou conversao
goto wait
movf ADRESH,W
return
;
; Display de LEDs
;
display:
movwf PORTD
return
;
; Envia byte (contido em W) pela UART e espera terminar
;
send:
movwf TXREG ; send data in W
TransWt:
bsf STATUS,RP0 ; banco 1
WtHere:
btfss TXSTA,TRMT ; Transmissao terminou se TRUE
goto WtHere ; Senao, espera
bcf STATUS,RP0 ; banco 0
return
;
;-----------------------------------------------------------------------------
;
; Delay for about 1s
;
delay1s:
movlw D'250'
call waitx400
movlw D'250'
call waitx400
movlw D'250'
goto waitx400
;
;-----------------------------------------------------------------------------
;
; Delay for about 250 ms
;
delay250ms:
movlw D'250'
goto waitx400
;
;-----------------------------------------------------------------------------
;
; Delay for about 400x cycles
;
; Se w=1, temporiza 1ms @ fck = 4MHz
;
waitx400:
movwf ld_loop_ex
ld_loopex:
movlw (400-4)/4
movwf ld_loop_in
ld_loopin:
decf ld_loop_in,F
skpz
goto ld_loopin
decf ld_loop_ex,F
skpz
goto ld_loopex
return
END
-
O programa não está na forma ideal, pois le e envia cada entrada em sequência, o ideal seria ler as tres entradas e depois enviá-las em sequência.
Assim:
;
; Loop principal
;
start:
; Ler entradas
movlw EAN_0 ; entrada analógica 0
call read_ad
movwf VALOR_AN0
movlw EAN_1 ; entrada analógica 1
call read_ad
movwf VALOR_AN1
movlw EAN_2 ; entrada analógica 2
call read_ad
movwf VALOR_AN2
; Envia pela serial
movfw VALOR_AN0
call send
movfw VALOR_AN1
call send
movfw VALOR_AN2
call send
call delay1s
goto start
-
Vale a pena uma espiada:
Sim, posso usar no lugar do monitoramento da minha tensão, em substituição ao MC34164, não é mesmo ? Ainda não deu tempo de ler tudo, mas depois vou esmiuçar esse material. Grato
-
Vale a pena uma espiada:
Sim, posso usar no lugar do monitoramento da minha tensão, em substituição ao MC34164, não é mesmo ? Ainda não deu tempo de ler tudo, mas depois vou esmiuçar esse material. Grato
É possível medir a tensão da bateria através de uma entrada, mas atente que é necessária uma tensão de referência, pois o conversor A/D usa +Vref (por exemplo +5V) e -Vref (0) para determinar o valor digital convertido.
Se alimentar tudo com bateria e a tensão +Vcc, supostamente de 5V, variar, então "babau"....
-
Melhorei o programa e a simulação, agora lê e envia tres entradas analógicas. O terminnal mostra o envio sequenciado de AN0 (0% = 0), AN1 (50%=7F) e AN2 (100%=FF).
Muito bom Gil, aos poucos vou acumulando material para aperfeiçoar o projeto. Eu carreguei o software e montei o circuito igual ao seu mas o resultado da simulação não ficou igual. Tem alguma configuração necessária no ISIS que eu não esteja cumprindo ?
(http://s3.postimage.org/pEm0J.jpg) (http://www.postimage.org/image.php?v=PqpEm0J)
-
Se alimentar tudo com bateria e a tensão +Vcc, supostamente de 5V, variar, então "babau"....
E para usar a tensão de ref. faço essa leitura através dos pinos 4 (RA2/AN2/VREF-) e 5 (RA3/AN3/VREF+) do pic
-
Melhorei o programa e a simulação, agora lê e envia tres entradas analógicas. O terminnal mostra o envio sequenciado de AN0 (0% = 0), AN1 (50%=7F) e AN2 (100%=FF).
Muito bom Gil, aos poucos vou acumulando material para aperfeiçoar o projeto. Eu carreguei o software e montei o circuito igual ao seu mas o resultado da simulação não ficou igual. Tem alguma configuração necessária no ISIS que eu não esteja cumprindo ?
(http://s3.postimage.org/pEm0J.jpg) (http://www.postimage.org/image.php?v=PqpEm0J)
Já achei o erro, o dispositivo estava com o clock errado
-
Anderson,
Se alimentar tudo com bateria e a tensão +Vcc, supostamente de 5V, variar, então "babau"....
E para usar a tensão de ref. faço essa leitura através dos pinos 4 (RA2/AN2/VREF-) e 5 (RA3/AN3/VREF+) do pic
Na verdade a tensão +Vref não é medida (pois é uma referência), apenas entra por este pino para uso do conversor A/D. Dê uma lida nos materiais sobre o assunto (leia o data sheet, o que o Jorge enviou, existema vários Application Notes da Microchip) e procure entender como funciona o conversor A/D.
Se o módulo de comando for a bateria, seria interessante usar um regulador de tensão de referência só para o A/D e os potenciômetros, para que usem a mesma referência de tensão. Minimizando os erros e ruído. Se ligar tudo (pots e +Vref do A/D) no +5V geral do circuito também "funciona", mas não é o ideal. Já vi projetos com conversor A/D com leituras ruidosas e onde esses aspectos são ignorados.
Como seria a ligação da fonte de referência externa:
[attachthumb=1]
A tensão -Vref pode ser o terra do PIC, mas a montagem deve bem feita, com amplas área de cobre e ligações curtas para minimizar o ruído e as eventuais diferenças de tensão entre o conversor A/D e os potenciômetros.
-
minilathe
mestre ... me esclareça uma dúvida.
Quando se possui um equipamento que é alimentado por baterias, mas é necessário o monitoramento da tensão das baterias para que estas não sejam sugadas até o ponto de não ser recuperadas, vc acredita que é necessário ou que seja disperdício colocar uma bateria (tipo botão) apenas para referência de tensão? ou mesmo no caso de utilzar algum circuito que possuam aqueles DS1307 (RTC) e utilizar da bateria dele como referência de tensão para o microcontrolador ... isso é uma prática aceitável ou um disperdício?
abrax!
-
Blackmore,
Quando se possui um equipamento que é alimentado por baterias, mas é necessário o monitoramento da tensão das baterias para que estas não sejam sugadas até o ponto de não ser recuperadas, vc acredita que é necessário ou que seja disperdício colocar uma bateria (tipo botão) apenas para referência de tensão? ou mesmo no caso de utilzar algum circuito que possuam aqueles DS1307 (RTC) e utilizar da bateria dele como referência de tensão para o microcontrolador ... isso é uma prática aceitável ou um disperdício?
Isto depende muito dos requisitos da aplicação.
Sendo um sistema autônomo (a bateria) em que isso é necessário, ok. Geralmente essas baterias botão suprem apenas funções vitais mínimas, tais como módulos de memória voláteis ou relógios de tempo real (a hora / data do sistema). Ou então a carga necessária para salvar tudo em memória e manter a CPU em hibernação.
Geralmente, quando a bateria está "caindo", todas as informações são salvas em memória para que o sistema seja restabelecido de onde parou. Mas depende para que serve o sistema (controle de processo, equipamentos de comunicações, automação industrial, equipamento médico-hospitalar, sistemas de sinalização urbana, aplicações militares, ...).
Hoje também existem capacitores eletrolíticos especiais, de baixas perdas e alta capacitância, que funcionam como se fossem baterias de curta duração, o necessário para as funções de emergência (parada suave do sistema e sinalização durante a falha).
-
Hoje também existem capacitores eletrolíticos especiais, de baixas perdas e alta capacitância, que funcionam como se fossem baterias de curta duração,
opa opa !! onde tem isso? fiz uma vez uma "bateria" desta com 1 capacitor de 1000uF ... mas era um trabuco na placa que dava dó !! hahaha
abrax!
-
opa opa !! onde tem isso?
É conhecido por supercap, não é fácil de encontrar no comércio local.
Para experiências uma boa fonte são os velhos VCRs que costumam trazer um de alguns farads (!)
-
Quando se possui um equipamento que é alimentado por baterias, mas é necessário o monitoramento da tensão das baterias para que estas não sejam sugadas até o ponto de não ser recuperadas ... ?
O Gil já pintou o panorama em largas pinceladas, mais genericamente, mas acho que vale comentar alguns aspectos mais específicos da aplicação discutida aqui:
O controle de um submersível é considerado tarefa crítica, portanto a manutenção do controle, se possível, ou pelo menos a recuperação do veículo, ganha precedência sobre a conservação da bateria: "Dane-se a bateria, eu quero é cair fora daqui !".
Não é incomum que os ROVs sejam equipados com sistema de alimentação redundante, remotamente alimentados em condições normais de operação e pela bateria em situação de emergência. Os aparelhos mais sofisticados são capazes de efetuar manobras de evasão autonomamente e/ou manter a comunicação por outros meios que não o cordão umbilical (acústicos).
Quase todo submersível exige lastro para alcançar a densidade aparente da água e obter flutuabilidade neutra e baterias são bem convenientes para isto, uma vantagem adicional.
A qualidade da tensão de referência é bastante importante de modo geral e é comum que sejam utilizados componentes como os sugeridos na AN546:
(http://s3.postimage.org/qERVS.jpg) (http://www.postimage.org/image.php?v=PqqERVS)
Mas neste caso específico, considerando o projeto original, estamos dispensados de qualquer preocupação quanto à Vref e Vdd, o valor absoluto de tensão amostrado é absolutamente irrelevante ! ;D
Uma característica importante - e pouco compreendida por muitos programadores - é o fato do conversor AD do PIC ser raciométrico, ou seja, o resultado da amostragem é uma razão da tensão de alimentação ou da tensão de referência.
Como o que queremos de fato saber não é a tensão, mas sim a posição relativa do joystick, a tensão de alimentação / referência pode variar amplamente e ainda teremos a informação acurada quanto à posição do joystick. Exemplo: com o pot a meio curso a tensão amostrada será Vref (Vdd)/2, não importando o qual seja Vref ou mesmo que seja variável e o resultado binário será sempre o mesmo, indicando corretamente o meio curso ...
Este é o tipo do detalhe que separa os homens dos meninos, indicativo da competência de quem escreveu o prog e desenhou hardware ... ;D
Um outro aspecto a considerar é que a resolução efetiva é de apenas três bits ( 0,625V ), o que reforça ainda mais ainda a imunidade às variações ...
-
Não é incomum que os ROVs sejam equipados com sistema de alimentação redundante, remotamente alimentados em condições normais de operação e pela bateria em situação de emergência. Os aparelhos mais sofisticados são capazes de efetuar manobras de evasão autonomamente e/ou manter a comunicação por outros meios que não o cordão umbilical (acústicos).
Jorge,
Neste primeiro projeto não haverá sofisticação, alias esta é a diretriz do trabalho, no entanto implementações futuras ao módulo poderão ser feitas e portanto é interessante deixar a base pronta para receber novos acessórios.
Como o que queremos de fato saber não é a tensão, mas sim a posição relativa do joystick, a tensão de alimentação / referência pode variar amplamente e ainda teremos a informação acurada quanto à posição do joystick.
Quanto ao sistema de movimentação do aparelho realmente não existem problemas com relação a tensão, mas para a transmissão e recepção de dados como pressão, salinidade, temperatura, etc.. ??
-
Quanto ao sistema de movimentação do aparelho realmente não existem problemas com relação a tensão, mas para a transmissão e recepção de dados como pressão, salinidade, temperatura, etc.. ??
Como dizíamos: "Considerando o projeto original ..." ;D
Eu tb acho que vale muito a pena planejar para expansões futuras ... por outro lado, nunca é boa coisa dar o passo maior que as pernas, né ?
Tb acho que vale muito a pena construir um protótipo simples e barato, com poucas modificações em relação ao projeto original, um "submersível de banheira", um judas pra malhar, para ganhar insight and feeling ... alguma experiência com a coisa pode ajudar a remover muitas pedras do caminho ...
-
aguizan
como lhe falei ... eu fiz um controle simples para motores DC para a faculdade .. (estou caçando para lhe disponibilizar conforme prometido) ... apenas a título de curiosidade pergunto eu ...
Qual é o tipo e modelo de motores utilizados em um ROV? DC brushed? brushless? com multiplicador de RPM?
-
Motores com baixo nível de ruído, para que não interfiram com a transmissão de sinais (vídeo, áudio, sinais digitais). Preocupação adicional com o problema da pressão e agressividade do meio ambiente. Testei vários tipos e todos funcionaram, inclusive mergulhados na água sem nenhuma proteção adicional. Quanto ao giro dos motores ainda estou em estudo para verificar a melhor rotação para os propulsores pois há uma relação entre giro e paço dos hélices que não consegui destrinchar.
-
por exemplo motores brushless de aeromodelismo?
-
O programa não está na forma ideal, pois le e envia cada entrada em sequência, o ideal seria ler as tres entradas e depois enviá-las em sequência.
Está enviando de três em três porem sempre valores iguais. Não consegui achar o problema :-\
-
Anderson,
O programa não está na forma ideal, pois le e envia cada entrada em sequência, o ideal seria ler as tres entradas e depois enviá-las em sequência.
Está enviando de três em três porem sempre valores iguais. Não consegui achar o problema :-\
Está enviando? Porém tres valores repetidos? Poderia enviar o seu programa?
-
por exemplo motores brushless de aeromodelismo?
Esses nunca testei, são muito caros. Utilizei motores encontrados nas lojas de autopeças. São robustos e baratos, mas existem várias experiências com motores de aeromodelismo muito bem sucedidas.
Tem alguma informação neste site:
http://www.submarineboat.com/rov_joystick_for_props.htm
-
opa opa !! onde tem isso? fiz uma vez uma "bateria" desta com 1 capacitor de 1000uF ... mas era um trabuco na placa que dava dó !! hahaha
Capacitor de 0,1 a 1,5 Farad para equipamentos eletrônicos:
[attachthumb=1]
-
Está enviando? Porém tres valores repetidos? Poderia enviar o seu programa?
Eu copiei e colei o código que vc enviou e fiz a alteração com o segundo trecho de código.
list P=16F877A
#include "P16F877A.INC"
__CONFIG _CP_OFF & _WDT_OFF & _XT_OSC & _PWRTE_ON
;__CONFIG 0x3F32
errorlevel -302 ; turn off bank bits warning
;
; Seleção de entradas do MUX (ADDCON0)
;
#DEFINE EAN_0 B'01000001' ; f/8, AN0, DONE, A/D On
#DEFINE EAN_1 B'01001001' ; f/8, AN1, DONE, A/D On
#DEFINE EAN_2 B'01010001' ; f/8, AN2, DONE, A/D On
;
; Variáveis da RAM internas
;
cblock H'20'
ld_loop_ex
ld_loop_in
VALOR_AN0
VALOR_AN1
VALOR_AN2
endc
;
; Inicio do Programa
;
ORG 0h
; Inicializaçao do PIC, do display e da porta serial
bcf STATUS,RP1
bsf STATUS,RP0 ; Habilita banco 1
clrf TRISD ; porta do display, de saída
movlw B'00000010' ; setup do conversor A/D
movwf ADCON1 ; left justify result
; port A: only analogue inputs
;
; Ajusta parametros da UART (usando cristal externo de 4MHz)
; Baud Rate = 9600 bps, No Parity, 1 Stop Bit
;
movlw 0x19 ; 0x19=9600 bps / 0x0C=19200 bps
movwf SPBRG
movlw b'00100100' ; TX_Enable, assync. mode, brgh = high (2)
movwf TXSTA ; enable Async Transmission, BRGH=1
movlw b'10111111' ; RC6 saida, outros bits da PORTC sao de entrada
movwf TRISC
bcf STATUS,RP0 ; Habilita banco 0
clrf PORTD ; zera saídas do display
; movlw EAN_0 ; seleciona entrada analógica
; movwf ADCON0
movlw b'01000000' ; Setup Port C
movwf PORTC ; RC6(TX)=1 others are 0
movlw b'10000000' ; habilita a UART
movwf RCSTA
;
; Loop principal
;
start:
; Ler Entradas
movlw EAN_0 ;entrada analógica 0
call read_ad
movwf VALOR_AN0
movlw EAN_1 ;entrada analógica 1
call read_ad
movwf VALOR_AN1
movlw EAN_2 ;entrada analógica 2
call read_ad
movwf VALOR_AN2
; Envia pela porta serial
movwf VALOR_AN0
call send
movwf VALOR_AN1
call send
movwf VALOR_AN2
call send
call delay1s
goto start
;
; Conversor A/D, palavra ADDCON0 em W
;
read_ad:
movwf ADCON0
bsf ADCON0,GO ; Iniciar conversao
wait:
btfsc ADCON0,GO ; Testa se terminou conversao
goto wait
movf ADRESH,W
return
;
; Display de LEDs
;
display:
movwf PORTD
return
;
; Envia byte (contido em W) pela UART e espera terminar
;
send:
movwf TXREG ; send data in W
TransWt:
bsf STATUS,RP0 ; banco 1
WtHere:
btfss TXSTA,TRMT ; Transmissao terminou se TRUE
goto WtHere ; Senao, espera
bcf STATUS,RP0 ; banco 0
return
;
;-----------------------------------------------------------------------------
;
; Delay for about 1s
;
delay1s:
movlw D'250'
call waitx400
movlw D'250'
call waitx400
movlw D'250'
goto waitx400
;
;-----------------------------------------------------------------------------
;
; Delay for about 250 ms
;
delay250ms:
movlw D'250'
goto waitx400
;
;-----------------------------------------------------------------------------
;
; Delay for about 400x cycles
;
; Se w=1, temporiza 1ms @ fck = 4MHz
;
waitx400:
movwf ld_loop_ex
ld_loopex:
movlw (400-4)/4
movwf ld_loop_in
ld_loopin:
decf ld_loop_in,F
skpz
goto ld_loopin
decf ld_loop_ex,F
skpz
goto ld_loopex
return
END
-
Anderson,
por exemplo motores brushless de aeromodelismo?
Esses nunca testei, são muito caros. Utilizei motores encontrados nas lojas de autopeças. São robustos e baratos, mas existem várias experiências com motores de aeromodelismo muito bem sucedidas.
Tem alguma informação neste site:
http://www.submarineboat.com/rov_joystick_for_props.htm
Como é que fica a corrosão? Aço+cobre+água (com algum eletrólito) = pilha => Corrosão do aço
-
acrescento ...
e como se comportam os rolamentos? não oxidam e posteriormente travam?
-
Como é que fica a corrosão? Aço+cobre+água (com algum eletrólito) = pilha => Corrosão do aço
O que tenho feito é como fazem os donos de lanchas, "após o uso um bom banho de água doce" e com motores custando algo em torno de R$ 20,00 (motores de bomba dágua de parabrisa) fica fácil fazer a substituição periódica. Essa descartabilidade é aceita devido as dificuldades e altíssimos preços de propulsores apropriados para utilização sob a água. Muitos projetos que já observei utilizam motores de bombas d'água de porão, mas as carenagens destes não suportam altas pressões. Quando permitimos o acesso da água no interior dos motores eliminamos o problema complicado de se trabalhar a 5 ATMs - 50 metros abaixo d'água.
-
Anderson,
O programa não está na forma ideal, pois le e envia cada entrada em sequência, o ideal seria ler as tres entradas e depois enviá-las em sequência.
Está enviando de três em três porem sempre valores iguais. Não consegui achar o problema :-\
O programa está funcionando...
Voce ajustou o terminal para o modo "Hex Display Mode"? Senão os valores binários, que o PIC envia, não aparecem, ou aparece como um "lixo" no terminal.
Conforme a figura:
[attachthumb=1]
-
Anderson,
O programa não está na forma ideal, pois le e envia cada entrada em sequência, o ideal seria ler as tres entradas e depois enviá-las em sequência.
Está enviando de três em três porem sempre valores iguais. Não consegui achar o problema :-\
O programa está funcionando...
Voce ajustou o terminal para o modo "Hex Display Mode"? Senão os valores binários, que o PIC envia, não aparecem, ou aparece como um "lixo" no terminal.
Conforme a figura:
[attachthumb=1]
Resolvido,
Era configuração, realmente.
-
Estamos projetando para três potenciômetros de 10K ohms que na realidade estão representando os joystick (controle de direção e controle de profundidade). Na hora de executar o protótipo serão utilizados joysticks existentes no mercado. Haverá necessidade de interface para essa utilização ?
-
Estamos projetando para três potenciômetros de 10K ohms que na realidade estão representando os joystick (controle de direção e controle de profundidade). Na hora de executar o protótipo serão utilizados joysticks existentes no mercado. Haverá necessidade de interface para essa utilização ?
(http://s1.postimage.org/8OqVJ.jpg) (http://www.postimage.org/image.php?v=gx8OqVJ)
-
aguizan
Estamos projetando para três potenciômetros de 10K ohms que na realidade estão representando os joystick (controle de direção e controle de profundidade). Na hora de executar o protótipo serão utilizados joysticks existentes no mercado. Haverá necessidade de interface para essa utilização ?
vc(s) está(ão) fazendo um bom trabalho de desenvolvimento, onde a meu entender é utilizado desde a eletrônica básica até o término do trabalho com a montagem do protótipo e possíveis melhorias decididas através de análise da performance do aparelho.
Com o uso de um controle deste (PS) a comunicação deverá ser toda em serial (RS232) a 9600bps, a cada 0,1S se não me engano é enviado pelo controle o estado de todos os botões e joysticks, ou seja, boa parte do trabalho que você(s) tiveram até agora será perdida e ainda será necessário desenvolver a comunicação com este controle.
Apesar de um controle deste não ser muito caro, existe no mercado até com certa facilidade "manches" mais profissionais (robustos) a preços bem razoáveis, basta uma boa procurada e esperar alguns dias para entrega.
-
Anderson, nesta fase do projeto eu optaria por uma seção de corte e costura, ou seja, desprezaria o controlador e rotearia os pots e botôes diretamente ao PIC.
Em todo o caso, aqui a coisa tá destrinchada:
http://www.mikroe.com/esupport/index.php?_m=downloads&_a=viewdownload&downloaditemid=78&nav=0,9,12
Veja tb:
http://www.google.com.br/url?sa=t&source=web&cd=1&ved=0CBsQFjAA&url=http%3A%2F%2Fwww.parallax.com%2Fdl%2Fdocs%2Fcols%2Fnv%2Fvol4%2Fcol%2Fnv101.pdf&ei=Rc09TL26CoKruAe86ah9&usg=AFQjCNEmN5fEn6cqOk78JU8NRy2l4up_rw&sig2=duvQjwdoNuGx3QWx_opbOA
-
Estamos projetando para três potenciômetros de 10K ohms que na realidade estão representando os joystick (controle de direção e controle de profundidade). Na hora de executar o protótipo serão utilizados joysticks existentes no mercado. Haverá necessidade de interface para essa utilização ?
Sim, conforme o manual do PIC16F877A, é necessário que a impedância de saída das fontes de sinal sejam inferiores a 2,5 Kohms para não haver erro de leitura. Ou seja, cada potenciômetro, de 10 K ohms, deve ser ligado a um "buffer" de sinal, com ganho unitário e baixa impedância de saída. Poderia usar o CI LM-324, que possui 4 amplificadores operacionais. Sugestão:
[attachthumb=1]
Outra opção é usar potenciômetros de 1K, sem amplificador nenhum.
-
C N C N o w !
mestre !! este documento do site da parallax está perfeito hein !!! agora descobri de onde um pessoal da faculdade fez o trabalho deles rapidin rapidin !!! hahaha !!!
-
Sim, conforme o manual do PIC16F877A, é necessário que a impedância de saída das fontes de sinal sejam inferiores a 2,5 Kohms para não haver erro de leitura.
Creio que interpretamos a recomendação de maneiras diversas ... O fragmento relevante da DS:
[info]
11.1 A/D Acquisition Requirements
For the A/D converter to meet its specified accuracy, the charge holding capacitor (CHOLD) must be allowed to fully charge to the input channel voltage level. The analog input model is shown in Figure 11-2. The source impedance (RS) and the internal sampling switch impedance (RSS) directly affect the time required to charge the capacitor CHOLD. The sampling switch (RSS) impedance varies over the device voltage (VDD); see Figure 11-2. The maximum recommended impedance for analog sources is 2.5 kΩ. As the impedance is decreased, the acquisition time may be decreased. After the analog input channel is selected (changed), this acquisition must be done before the conversion can be started.[/info]
Se bem entendo, a questão aqui é garantir a carga de CHOLD até a tensão amostrada, o que pode ser obtido pela manipulação de Tacq ... tô enganado ?
Não analisei para o valor discutido [ 10K ] mas creio que este é um recurso viável, se não neste caso específico, em outros ...
-
... agora descobri de onde um pessoal da faculdade fez o trabalho deles rapidin rapidin !!! hahaha !!!
Há um montão de artigos por aí, mais um:
http://store.curiousinventor.com/guides/PS2/
-
Sim Sim ... sei que existem muitos ... mas acontece que a cara de pau do pessoal é demais !!
Eu já usei alguns artigos bem completos também, mas SEMPRE procuro entender e fazer o meu e não copiar descaradamente !! hahaha
Os cabras não tem intimidade com programação e entregaram um trabalho com BasicStep !! hehehe
-
... a cara de pau do pessoal é demais !!
Pois é ... mais de uma vez fui consultado para fazer trabalhos acadêmicos, o que obviamente sempre recusei ... e os que tenho visto em sua maioria não passam de ctrl+c / crtl+v, não chegam sequer a ser plágio ... dureza ...
-
aguizan
existe no mercado até com certa facilidade "manches" mais profissionais (robustos) a preços bem razoáveis, basta uma boa procurada e esperar alguns dias para entrega.
Se facilita, não vejo nenhum problema na utilização desses "manches". Havia colocado os controles de PS pois tenho adquirido em uma manutenção desses equipamentos os micro joysticks (peças encontradas nesses controles ).
(http://s1.postimage.org/bKJoi.jpg) (http://www.postimage.org/)
-
Anderson, nesta fase do projeto eu optaria por uma seção de corte e costura, ou seja, desprezaria o controlador e rotearia os pots e botôes diretamente ao PIC.
Neste caso eu teria que usar um Joystick analógico, correto? ....Quanto mais simples for o projeto melhor, mais não encontrei ainda o componente certo para essa utilização, alguma sugestão ?
-
Sim, conforme o manual do PIC16F877A, é necessário que a impedância de saída das fontes de sinal sejam inferiores a 2,5 Kohms para não haver erro de leitura. Ou seja, cada potenciômetro, de 10 K ohms, deve ser ligado a um "buffer" de sinal, com ganho unitário e baixa impedância de saída. Poderia usar o CI LM-324, que possui 4 amplificadores operacionais. Sugestão:
Desta forma estaria utilizando os Joysticks do PS (potenciômetros de 10K) e desprezando os outros controles oferecidos.
Outra opção é usar potenciômetros de 1K, sem amplificador nenhum.
Se esta opção não perder em qualidade do sinal eu prefiro pela simplificação, mas será que consigo mini Joysticks com pots de 1K ?
-
Neste caso eu teria que usar um Joystick analógico, correto?
Sim, seria o mais fácil. Os joysticks do controle do Playstation não são analógicos ? Eu tenho a impressão que sim, ao menos algum modelo ... se não me engano já usei os pots retirados de um deles ...
Quanto mais simples for o projeto melhor, mais não encontrei ainda o componente certo para essa utilização, alguma sugestão ?
Se os do Playstation não forem analógicos, certamente há uns por aí que são, com toda a certeza, só não pergunte qual ... vejo nos camelôs da Santa, a caixa de alguns controladores são transparentes, dá pra ver que são analógicos ...
Por outro lado, se vc viu os artigos que citei, deve ter percebido que não é difícil interfacear o controlador.
Há tb a opção de adquirir os joysticks no comércio. Nunca comprei, mas recentemente vi o comentário de alguém em uma lista de discussão que havia comprado alguns ...
Acho que vale lembrar que não é difícil fabricar um joystick ... vou rabiscar algo pra mostrar como já fiz e depois posto aqui.
-
Sim, conforme o manual do PIC16F877A, é necessário que a impedância de saída das fontes de sinal sejam inferiores a 2,5 Kohms para não haver erro de leitura.
Creio que interpretamos a recomendação de maneiras diversas ... O fragmento relevante da DS:
[info]
11.1 A/D Acquisition Requirements
For the A/D converter to meet its specified accuracy, the charge holding capacitor (CHOLD) must be allowed to fully charge to the input channel voltage level. The analog input model is shown in Figure 11-2. The source impedance (RS) and the internal sampling switch impedance (RSS) directly affect the time required to charge the capacitor CHOLD. The sampling switch (RSS) impedance varies over the device voltage (VDD); see Figure 11-2. The maximum recommended impedance for analog sources is 2.5 kΩ. As the impedance is decreased, the acquisition time may be decreased. After the analog input channel is selected (changed), this acquisition must be done before the conversion can be started.[/info]
Se bem entendo, a questão aqui é garantir a carga de CHOLD até a tensão amostrada, o que pode ser obtido pela manipulação de Tacq ... tô enganado ?
Não analisei para o valor discutido [ 10K ] mas creio que este é um recurso viável, se não neste caso específico, em outros ...
A impedância da fonte de sinal deve ser mantida dentro de certos limites aceitáveis pelo conversor A/D.
Considerando que a entrada analógica possui o circuito a seguir:
[attachthumb=1]
O valor máximo da resistência da fonte de sinal (Rs) poderia ser calculado a partir do valor do tempo de conversão do A/D. Do mesmo modo, o valor de Tacq poderia ser manipulado para atender a simplificação do circuito (com menor quantidade de componentes).
Porém, há outras questões envolvidas na determinação do valor mínimo de Rs, entre elas, a corrente de fuga do PIC. O próprio manual recomenda em mais de um lugar uma resistência menor que 2,5 K ohms.
[attachthumb=2]
Então, eu particularmente usaria esse valor máximo, como a resistência máxima de saída de um potenciômetro (pelo teorema de Thevenin) seria a metade de sua resistência total. Para atender a esse quesito, deveria ser usado uma potenciômetro com resistência máxima de 5K. Se os joysticks de mercado forem realmente padronizados em 10K ohm, só resta usar um amplificador operacional.
Calculando a resistência máxima, para que a corrente de fuga não gere erros no conversor A/D, podemos usar:
Rs < Vadc(min) / Ifuga
Sendo:
(1) Vadc(min): tensão mínima na entrada do conversor, algo em torno de 4 mV para conversor A/D de 10 bits e Vref = 5V.
(2) Ifuga = 500nA
Rs < 8 K ohm
Ainda assim, eu usaria 2,5 K ohm... :)
-
Sim, seria o mais fácil. Os joysticks do controle do Playstation não são analógicos ?Sim, tem dois contrôles analógicos e um digital (na imagem que enviei em citação anterior o digital seria o da câmera)
Eu uso esses mini joysticks que são do PS. (http://www.postimage.org/image.php?v=aVdxrXA)
Por outro lado, se vc viu os artigos que citei, deve ter percebido que não é difícil interfacear o controlador.
Ainda não li não. Vou olhar em seguida.
Acho que vale lembrar que não é difícil fabricar um joystick ... vou rabiscar algo pra mostrar como já fiz e depois posto aqui.
Para ilustrar eis um protótipo de alavanca para movimentar dois potenciômetros simultaneamente.
(http://s3.postimage.org/tJ4g0.jpg) (http://www.postimage.org/image.php?v=PqtJ4g0)
-
para simplificar ainda mais .. eu utilizaria um (ou dois) potenciômetro deslizante ( http://www.futurlec.com/PotSliding.shtml ) ... barato ... fácil de encontrar .. não vai perder "sensibilidade" na mão na hora de fazer funcionar ...
mas se quiser gastar mais ... ( http://produto.mercadolivre.com.br/MLB-144268575-controle-de-arcade-profissional-comando-joystick-_JM )
-
para simplificar ainda mais .. eu utilizaria um (ou dois) potenciômetro deslizante ( http://www.futurlec.com/PotSliding.shtml ) ... barato ... fácil de encontrar .. não vai perder "sensibilidade" na mão na hora de fazer funcionar ...
Excelente solução para o controle de profundidade.òtima sugestão !!!
O Joystick Arcade não utiliza potenciômetro e sim microswitchs.
-
Eis aí o rabisco muito mal rabiscado, mas serve pra ilustrar o conceito, espero. :P
(http://s1.postimage.org/bWucJ.jpg) (http://www.postimage.org/image.php?v=gxbWucJ)
-
(1) Vadc(min): tensão mínima na entrada do conversor, algo em torno de 4 mV para conversor A/D de 10 bits e Vref = 5V.
(2) Ifuga = 500nA
Rs < 8 K ohm
Ainda assim, eu usaria 2,5 K ohm... :)
Pois é Gil, todo o seu arrazoado parece apontar na direção que eu imaginei, sem analisar a coisa com a profundidade que vc fez ... nada contra obedecer a especificação, claro, mas explorar os limites de vez em quando rende soluções interessantes ...
Vou ficar de olho, acho que tenho por aqui os cacos de um antigo projeto com pots de 5K ou 10K ... se achar eu mando foto e mais algum detalhe ... se a memória não me trai a coisa funfou direitinho ...
-
O programa não está na forma ideal, pois le e envia cada entrada em sequência, o ideal seria ler as tres entradas e depois enviá-las em sequência.
Gil,
No projeto original os bits eram rotacionados até formar o 1º Byte de transmissão e ficavam em zero o bit 6 e 7. O bit 7 poderia então ter seu estado modificado dependendo do comando de acionamento ou não da iluminação assim como o bit 6 para comandar servo. Como posso fazer nessa nova situação ? Serão quatro bytes de transmissão ? E nesse caso enviá-los de quatro em quatro ?
-
existe um padrão para a comunicação? se vc mandar um start bit e um stop bit e definir um padrão de comunicação vc fará o trabalho apenas 1 vez, pois se vc decidir por sempre enviar 5 ou 6 "palavras" onde seus valores virão de variáveis definidas se vc não utilizar no receptor todas as palavras acredito que você ganhará tempo de desenvolvimento.
-
Anderson,
Gil,
No projeto original os bits eram rotacionados até formar o 1º Byte de transmissão e ficavam em zero o bit 6 e 7. O bit 7 poderia então ter seu estado modificado dependendo do comando de acionamento ou não da iluminação assim como o bit 6 para comandar servo. Como posso fazer nessa nova situação ? Serão quatro bytes de transmissão ? E nesse caso enviá-los de quatro em quatro ?
O quadro de transmissão (conjunto de bytes) original é composto de 2 bytes:
;* SER_DATA_1 register: *
;* *
;* ___7______6______5_ _____4______3______ 2______1______0__ *
;* | | | | | | | | | *
;* ___________________ ___________________ _________________ *
;* LIGHT SERVO --- LEFT MOTOR --- --- RIGHT MOTOR ---- *
;* *
;* SER_DATA_2 register: *
;* *
;* ___7______6______5_ _____4______3______ 2______1______0__ *
;* | | | | | | | | | *
;* ___________________ ___________________ _________________ *
;* -------------- DEPTH CONTROL A/D VALUE ---------------- *
O quadro pode ser aumentado de acordo com a necessidade, acrescentando-se mais bytes. Seguindo a sugestão do Jorge, podemos considerar uma sistemática de verificação de erros, que poderia ser um algoritmo de Checksum, aí gasta-se mais um byte.
Mas tem que ver se é realmente necessário. Como estamos falando de software, a mudança é simples. Pode-se depois sofisticar o protocolo de comunicação. Com um ou mais bytes de verificação ou de correção de erros, que são usados quando o meio de comunicação é ruidoso e há perdas com certa frequência. Como será usado um cabo ponto a ponto e o meio onde este passa deve proporcionar pouco ruído, assim, uma estratégia de verificação de erros pode ser dispensável. Mas isso, talvez, só saberemos depois.
Mas como alguém já disse, "o molho não deve ser mais caro que o peixe".
Num projeto desse tipo, eu acho importante desenhar primeiramente o que o quadro tem que levar de informação (requisitos) e dai implementar o software do protocolo.
A palavra de controle de cada motor terá 3 bytes não é? Mas quantos motores serão? Quantos sinais digitais do tipo liga/desliga (ON/OFF)? O comando do servo terá quantos bits?
Entendi que voce também espera receber algo do ROV não é? Tirando o sinal da câmera (que deve ser um sinal de alta largura de banda de transmissão, algo em torno de 5MHz, via cabo coaxial) que não passaria pelo PIC. Os sinais de sensores de pressão (profundidade), temperatura, ... Nesse caso, vai um quadro num sentido e no outro sentido. Havendo uma "conversa" entre os módulos.
-
Blackmore,
existe um padrão para a comunicação? se vc mandar um start bit e um stop bit e definir um padrão de comunicação vc fará o trabalho apenas 1 vez, pois se vc decidir por sempre enviar 5 ou 6 "palavras" onde seus valores virão de variáveis definidas se vc não utilizar no receptor todas as palavras acredito que você ganhará tempo de desenvolvimento.
Esclarecendo que, sendo a comunicação assincrona, o start e stop bits estão sempre presentes a cada byte enviado. Está implicito no trabalho da USART e transparente para o programador. Que só tem que estabelecer o mesmo padrão nos dois lados da comunicação.
-
"o molho não deve ser mais caro que o peixe".
Como parece que a solução minimalista original está sendo abandonada em favor de algo um pouco mais elaborado, é incontornável a adoção de um protocolo multibyte que inclua o indispensável preâmbulo e o barato checksum ou CRC. É desejável e útil o handshaking e alarme em caso de falha ...
Algo do tipo:
preâmbulo (indica o início do quadro)
joystick 1
joystick 2
joystick 3
joystick 4
I/O
Checksum
O Tx pode responder com checksum + código de erro, se incorreto, indica falha de comunicação ou outra qualquer, como flooding ...
PS: Linguado à la belle meunière é o que escolho quando tenho opção. É bem possível que eu goste do minimalismo mais que qualquer um por aqui ... ;D
-
minilathe
como sempre, não consegui me expressar direito :(
mas ok ... tocamos o barco para frente ... melhor .. o ROV !! :)
-
Gil,
A palavra de controle de cada motor terá 3 bytes não é? Mas quantos motores serão?
Três motores dois no eixo X e um no Y
Quantos sinais digitais do tipo liga/desliga (ON/OFF)?
- Iluminação frontal
- iluminação posterior
- servo
O comando do servo terá quantos bits?
O servo movimentará a câmera no eixo y somente, com 3 posições possíveis, frente, esq. e dir.
Entendi que voce também espera receber algo do ROV não é? Tirando o sinal da câmera (que deve ser um sinal de alta largura de banda de transmissão, algo em torno de 5MHz, via cabo coaxial) que não passaria pelo PIC. Os sinais de sensores de pressão (profundidade), temperatura, ... Nesse caso, vai um quadro num sentido e no outro sentido. Havendo uma "conversa" entre os módulos.
Sim, retornam sinais referentes a pressão, temperatura, salinidade, compass, etc.
-
Jorge,
"o molho não deve ser mais caro que o peixe".
Como parece que a solução minimalista original está sendo abandonada em favor de algo um pouco mais elaborado, é incontornável a adoção de um protocolo multibyte que inclua o indispensável preâmbulo e o barato checksum ou CRC. É desejável e útil o handshaking e alarme em caso de falha ...
Algo do tipo:
preâmbulo (indica o início do quadro)
joystick 1
joystick 2
joystick 3
joystick 4
I/O
Checksum
O Tx pode responder com checksum + código de erro, se incorreto, indica falha de comunicação ou outra qualquer, como flooding ...
PS: Linguado à la belle meunière é o que escolho quando tenho opção. É bem possível que eu goste do minimalismo mais que qualquer um por aqui ... ;D
Há duas questões colocadas por voce, bem especificas da camada de enlace, da qual estamos tratando:
(1) Controle (detecção) de erros
(2) Delimitação de quadros
(1) No caso da deteção de erros, eu não faria a principio, por uma questão de começar pelo +simples. Não é complexo fazer um checksum. Mas coloco aqui a questão, acho que se os autores não usaram será mesmo necessário? O que acham?
(2) No caso da delimitação do quadro, voce sugeriu um preâmbulo. Que normalmente seria uma sequência de ocorrência única na transmissão. Nesse caso, seria necessário adotar também uma codificação orientada a caractere, para que esta sequência não se repetisse no meio do quadro. O que, acho, complicaria um pouco mais.
Estava pensando em fazer algo simples, delimitar os quadros usando temporização, que é como o programa original trabalha.
Na seguinte sequência: T1 - T2 - T1 - T2 - T1 - ....
Onde:
T1: tempo de transmissão (todos os bytes do quadro em sequência, separados por um pequeno intervalo entre bytes menor ou igual a 1 byte)
T2: Intervalo de silêncio, igual ou maior que T1 (por exemplo: 2xT1)
Usando uma simples rotina de temporização, e sendo T2 >= T1, é sempre possível o receptor sincronizar com o transmissor.
Havendo comunicação bidirecional, teríamos:
T1 - T2 - T3 - T4 - T1 - T2 - T3 - T4 - T1 - T2 - T3 - T4 - T1 - T2 - T3 - T4 - ....
Onde
T1 - tempo de transmissão da estação base (EB)
T2 - tempo de silêncio da EB (>=T1)
T3 - tempo de transmissão do ROV
T2 - tempo de silêncio do ROV (>=T3)
Para haver sincronismo nos dois sentidos, usa-se um temporizador em cada estação.
O que acham??
-
(1) No caso da deteção de erros, eu não faria a principio, por uma questão de começar pelo +simples. Não é complexo fazer um checksum. Mas coloco aqui a questão, acho que se os autores não usaram será mesmo necessário? O que acham?
Acho que o fato de os autores terem usado ou não isto ou aquilo, não é um bom argumento, mormente quando se pretende chegar a algo um pouco mais elaborado. Como a manteiga do meu linguado, checksum custa muito pouco mas faz muita diferença, é a diferença entre o gostoso e o delicioso. ;D
(2) No caso da delimitação do quadro, voce sugeriu um preâmbulo.
É mais que uma sugestão, é uma necessidade. Há mais de uma maneira de esfolar um gato e a temporização tb é um preâmbulo. Tenho a tendência de evitar temporização, mas não tenho nada contra ela neste caso.
-
Jorge,
"o molho não deve ser mais caro que o peixe".
Como parece que a solução minimalista original está sendo abandonada em favor de algo um pouco mais elaborado, é incontornável a adoção de um protocolo multibyte que inclua o indispensável preâmbulo e o barato checksum ou CRC. É desejável e útil o handshaking e alarme em caso de falha ...
Algo do tipo:
preâmbulo (indica o início do quadro)
joystick 1
joystick 2
joystick 3
joystick 4
I/O
Checksum
O Tx pode responder com checksum + código de erro, se incorreto, indica falha de comunicação ou outra qualquer, como flooding ...
PS: Linguado à la belle meunière é o que escolho quando tenho opção. É bem possível que eu goste do minimalismo mais que qualquer um por aqui ... ;D
Há duas questões colocadas por voce, bem especificas da camada de enlace, da qual estamos tratando:
(1) Controle (detecção) de erros
(2) Delimitação de quadros
(1) No caso da deteção de erros, eu não faria a principio, por uma questão de começar pelo +simples. Não é complexo fazer um checksum. Mas coloco aqui a questão, acho que se os autores não usaram será mesmo necessário? O que acham?
(2) No caso da delimitação do quadro, voce sugeriu um preâmbulo. Que normalmente seria uma sequência de ocorrência única na transmissão. Nesse caso, seria necessário adotar também uma codificação orientada a caractere, para que esta sequência não se repetisse no meio do quadro. O que, acho, complicaria um pouco mais.
Estava pensando em fazer algo simples, delimitar os quadros usando temporização, que é como o programa original trabalha.
Na seguinte sequência: T1 - T2 - T1 - T2 - T1 - ....
Onde:
T1: tempo de transmissão (todos os bytes do quadro em sequência, separados por um pequeno intervalo entre bytes menor ou igual a 1 byte)
T2: Intervalo de silêncio, igual ou maior que T1 (por exemplo: 2xT1)
Usando uma simples rotina de temporização, e sendo T2 >= T1, é sempre possível o receptor sincronizar com o transmissor.
Havendo comunicação bidirecional, teríamos:
T1 - T2 - T3 - T4 - T1 - T2 - T3 - T4 - T1 - T2 - T3 - T4 - T1 - T2 - T3 - T4 - ....
Onde
T1 - tempo de transmissão da estação base (EB)
T2 - tempo de silêncio da EB (>=T1)
T3 - tempo de transmissão do ROV
T2 - tempo de silêncio do ROV (>=T3)
Para haver sincronismo nos dois sentidos, usa-se um temporizador em cada estação.
O que acham??
Se eu entendi direito acho que fica bem simples, o quadro transmitido a starta um tempo de silêncio sempre igual ou maior que o tempo que ele levou para ser transmitido e assim sucessivamente, por toda a transmissão ?
-
Se eu entendi direito acho que fica bem simples, o quadro transmitido a starta um tempo de silêncio sempre igual ou maior que o tempo que ele levou para ser transmitido e assim sucessivamente, por toda a transmissão ?
Pelamordasdeusas Anderson ! Tá certo que as iluminadas palavras do Gil merecem repetição, mas pra que esse linguição aí que inclui até minhas bobagens ?! Credo ! Tá gastando minhas retinas, homi ! ;D
O intervalo é, a partir de um mínimo de dois bits, arbitrário. Pode ser, digamos, o equivalente a um byte. Quanto mais longo, mais seguro, mas tb mais perdulário.
-
Seria algo assim:
Comunicação uni-direcional (+simples)
Estação de comando:
(1) A comunicação sempre começa pela estação de controle, o envio de um quadro de comando.
(2) A estação de comando sempre envia um quadro a intervalos regulares (T2).
ROV:
(1) Fica escutando a rede (cabo), se um comando chegar, verifica se chegou sem erros (a manteiga do linguado do Jorge... ;D ) se chegou com erro, descarta. Se chegou sem erros processa o comando.
Comunicação bi-direcional:
Estação de comando:
(1) A comunicação sempre começa pela estação de controle, o envio de um quadro de comando.
(2) A estação de comando sempre envia um quadro a intervalos regulares (T2).
(3) A estação aguarda por uma resposta do ROV, se não chegar no tempo esperado (T2), vai para o passo (1).
(4) Se recebeu um quadro, verifica se chegou sem erros, se ok processa e espera T4 antes de ir para o passo (1), senão vai para o passo (1).
ROV:
(1) Fica escutando a rede (cabo), se um comando chegar, se chegou com erro, descarta. Se chegou sem erros processa o comando.
(2) Envia um quadro de resposta.
-
Senhores,
A diretriz do projeto é que possa ser bastante simples. Quanto..., é uma questão de coerência pois não se pode abdicar de qualidade e bom funcionamento. Há que se pensar porém na possibilidade de execução com o mínimo possível de implementos para que estes possam ser adquiridos como acessórios, o que capacita o projeto a um grande número de usuários. Portanto acredito que para este primeiro módulo o projeto precise atender as seguintes necessidades:
- Locomoção com dois eixos de liberdade - Joystick
- Profundidade - Potenciômetro deslizante
- Iluminação para utilização de camera Frontal
- Iluminação camera trazeira
- camera de vídeo frontal
- camera de vídeo trazeira
- Servo
O mínimo possível de sofsticação com relação a segurança também é interessante. Como exemplo o sensor de umidade. Este equipamento navegará em águas rasas, chegando a uma profundidade máxima de 50 metros.
-
Pelamordasdeusas Anderson !
O dedo caiu aqui em cima do enviar, foi mal... ;D
[/quote]
-
Seria algo assim:
Entendi.
Pode-se usar a bi-direcional, ganha-se em velocidade, correto ?
-
já escolheu a(s) bateria(as) e motor(es) e tem definido o peso do sistema? Não sei porquê ... mas eu acredito que a comunicação serial apesar de importante e já ter sido muito bem comentada aqui poderia ser deixada mais para frente ... não?
-
já escolheu a(s) bateria(as) e motor(es) e tem definido o peso do sistema? Não sei porquê ... mas eu acredito que a comunicação serial apesar de importante e já ter sido muito bem comentada aqui poderia ser deixada mais para frente ... não?
Sim, eu já montei vários protótipos. O aparelho não usa bateria, é alimentado por cabo. Assim que eu tenha um tempinho vou editar uns vídeos que tenho e envio para que possam ver.
-
Anderson,
Senhores,
A diretriz do projeto é que possa ser bastante simples. Quanto..., é uma questão de coerência pois não se pode abdicar de qualidade e bom funcionamento. Há que se pensar porém na possibilidade de execução com o mínimo possível de implementos para que estes possam ser adquiridos como acessórios, o que capacita o projeto a um grande número de usuários. Portanto acredito que para este primeiro módulo o projeto precise atender as seguintes necessidades:
- Locomoção com dois eixos de liberdade - Joystick
- Profundidade - Potenciômetro deslizante
- Iluminação para utilização de camera Frontal
- Iluminação camera trazeira
- camera de vídeo frontal
- camera de vídeo trazeira
- Servo
O mínimo possível de sofsticação com relação a segurança também é interessante. Como exemplo o sensor de umidade. Este equipamento navegará em águas rasas, chegando a uma profundidade máxima de 50 metros.
Comandos enviados:
(1) Locomoção com dois eixos de liberdade - Joystick
Eixo X - 3 bits
Eixo Y - 3 bits
(2)Profundidade - Potenciômetro deslizante
Eixo Z - 8 bits??
(3)Iluminação para utilização de camera Frontal
L1 ON/OFF - 1 bit
(4)Iluminação camera trazeira
L2 ON/OFF - 1 bit
(4)Servo
Posição do servo - 2 bits
A profundidade tem a ver com o foco / zoom da câmera ou a profundidade do ROV?
-
Assim que eu tenha um tempinho vou editar uns vídeos que tenho e envio para que possam ver
poxa manda sim ... fiquei curioso em ver o motor funcionando debaixo d'agua sem qualquer proteção ou blindagem :) será que meu brushless de aeromodelismo aguenta um mergulho?? ;D
-
A profundidade tem a ver com o foco / zoom da câmera ou a profundidade do ROV?
Gil,
Não, essa profundidade é de locomoção do aparelho mesmo. Agora você tocou em um ponto interessante, a câmera com zoom abre um leque muito grande de opções. É uma função que será opcional (câmera com ou sem zoom).
-
poxa manda sim ... fiquei curioso em ver o motor funcionando debaixo d'agua sem qualquer proteção ou blindagem :) será que meu brushless de aeromodelismo aguenta um mergulho?? ;D
Pode apostar. Na mensagem que lhe mandei no dia 13/07 tem um artigo falando a respeito
-
Por gentileza:
Quando forem fazer citações de textos dos colegas, evitem de r4eprodurir o conteúdo completo das mensagens..
Esta é uma campanha da "Ablação Caudal"...
-
.... a câmera com zoom abre um leque muito grande de opções.
He, he, he ... e la nave va ...
-
Senhores,
Fiz uma pequena parte do código para acionar iluminação frontal e posterior. A idéia é que possa funcionar da seguinte maneira.
- Aciono o botão pela primeira vez e ligo a iluminação frontal
- aciono o botão novamente e desligo a iluminação frontal
- aciono o botão novamente e ligo a iluminação trazeira
- aciono o botão novamente e desligo a iluminação trazeira
- aciono o botão novamente e ligo a iluminação frontal e trazeira
- aciono o botão novamente e desligo toda a iluminação
Fiz uma parte e ficou assim: (está funcionando parcialmente. Ainda não consegui fazer a comutação das funçoes do botão funcionarem corretamente)
;
;
;
;
;Software para comando de Joystick e potenciometro
;ROV
list P=16F877A
#include "P16F877A.INC"
__CONFIG _CP_OFF & _WDT_OFF & _XT_OSC & _PWRTE_ON
;__CONFIG 0x3F32
errorlevel -302 ; turn off bank bits warning
;
; Entradas
;
#DEFINE EAN_0 B'01000001' ; f/8, AN0, DONE, A/D On
#DEFINE EAN_1 B'01001001' ; f/8, AN1, DONE, A/D On
#DEFINE EAN_2 B'01010001' ; f/8, AN2, DONE, A/D On
#DEFINE BOTAO PORTA,4 ;Porta do botão
;0 = pressionado
;1 = liberado
;
; Saídas
;
#DEFINE LED PORTD,7 ;Porta do led 7
; 0 = apagado
; 1 = aceso
#DEFINE LED2 PORTD,6 ;Porta do led 6
; 0 = apagado
; 1 = aceso
;
; Variáveis
;
cblock H'20'
ld_loop_ex
ld_loop_in
VALOR_AN0
VALOR_AN1
VALOR_AN2
BT_atual
BT_ultimo
BT_estado
BT_loop
endc
;
; Constantes
;
BT_rst equ .200
;
; Inicio do Programa
;
ORG 0h
; Inicializaçao do PIC, do display e da porta serial
bcf STATUS,RP1
bsf STATUS,RP0 ; Habilita banco 1
clrf TRISD ; porta do display, de saída
movlw B'00000010' ; setup do conversor A/D
movwf ADCON1 ; left justify result
; port A: only analogue inputs
;
; Inicializa variáveis
;
clrf BT_atual
clrf BT_estado
movlw BT_rst
;
; Ajusta parametros da UART (usando cristal externo de 4MHz)
; Baud Rate = 9600 bps, No Parity, 1 Stop Bit
;
movlw 0x19 ; 0x19=9600 bps / 0x0C=19200 bps
movwf SPBRG
movlw b'00100100' ; TX_Enable, assync. mode, brgh = high (2)
movwf TXSTA ; enable Async Transmission, BRGH=1
movlw b'10111111' ; RC6 saida, outros bits da PORTC sao de entrada
movwf TRISC
bcf STATUS,RP0 ; Habilita banco 0
clrf PORTD ; zera saídas do display
movlw b'01000000' ; Setup Port C
movwf PORTC ; RC6(TX)=1 others are 0
movlw b'10000000' ; habilita a UART
movwf RCSTA
;
; Loop principal
;
start:
; Ler entradas
movlw EAN_0 ; entrada analógica 0
call read_ad
movwf VALOR_AN0
movlw EAN_1 ; entrada analógica 1
call read_ad
movwf VALOR_AN1
movlw EAN_2 ; entrada analógica 2
call read_ad
movwf VALOR_AN2
; Envia pela serial
movfw VALOR_AN0
call send
movfw VALOR_AN1
call send
movfw VALOR_AN2
call send
call iluminacao
movf LED
call send
call delay1s
goto start
;
; Conversor A/D, palavra ADDCON0 em W
;
read_ad:
movwf ADCON0
bsf ADCON0,GO ; Iniciar conversao
wait:
btfsc ADCON0,GO ; Testa se terminou conversao
goto wait
movf ADRESH,W
return
;
;Verifica estado do botão de iluminação
;
iluminacao:
movf BT_atual,W ;Coloca o valor do BT_atual em W
movwf BT_ultimo ;coloca o valor de W em BT_ultimo
btfsc BT_estado,0 ;testa estado do botão e pula a próxima linha se for = 0
bsf LED ;acende o LED = PORTD,7
BT_down:
btfss BOTAO ;testa o estado do botão e pula a próxima linha se for = 1
goto BT_up
bsf BT_atual,0 ;
movf BT_loop,F
btfss STATUS,Z
decf BT_loop
btfsc STATUS,Z
bsf LED2
return
BT_up:
clrf BT_atual
btfss BT_ultimo,0
return
bcf LED2
movf BT_loop,F
btfss STATUS,Z
call ilumina
movlw BT_rst
movwf BT_loop
return
ilumina:
btfsc BT_estado,0
goto ilumina2
bsf LED
bsf BT_estado,0
return
ilumina2:
bcf LED
clrf BT_estado
return
;
; Display de LEDs
;
display:
movwf PORTD
return
;
; Envia byte (contido em W) pela UART e espera terminar
;
send:
movwf TXREG ; send data in W
TransWt:
bsf STATUS,RP0 ; banco 1
WtHere:
btfss TXSTA,TRMT ; Transmissao terminou se TRUE
goto WtHere ; Senao, espera
bcf STATUS,RP0 ; banco 0
return
;
;-----------------------------------------------------------------------------
;
; Delay for about 1s
;
delay1s:
movlw D'250'
call waitx400
movlw D'250'
call waitx400
movlw D'250'
goto waitx400
;
;-----------------------------------------------------------------------------
;
; Delay for about 250 ms
;
delay250ms:
movlw D'250'
goto waitx400
;
;-----------------------------------------------------------------------------
;
; Delay for about 400x cycles
;
; Se w=1, temporiza 1ms @ fck = 4MHz
;
waitx400:
movwf ld_loop_ex
ld_loopex:
movlw (400-4)/4
movwf ld_loop_in
ld_loopin:
decf ld_loop_in,F
skpz
goto ld_loopin
decf ld_loop_ex,F
skpz
goto ld_loopex
return
END
-
Anderson,
A profundidade tem a ver com o foco / zoom da câmera ou a profundidade do ROV?
Gil,
Não, essa profundidade é de locomoção do aparelho mesmo.
Explique melhor o comando de profundidade, seria um potenciômetro com escala em metros, mm ou cm? (Sei que são multiplos), mas como voce imagina que o ROV vai saber a que profundidade se encontra? E como manter a profundidade escolhida?
Alertando que, sendo um controle de profundidade, esta seria limitada pelo faixa atribuída (range) ao curso do potenciômetro e pela resolução deste. Por exemplo, uma faixa de 10 metros e uma resolução de 10/256 = 3,9 mm. A cada 27 graus de rotação o submarino se moveria 1 metro, é isso mesmo?? Além disso, para manter uma certa profundidade seria necessário uma malha de controle de profundidade (de pressão) e de um sensor de pressão com essa resolução (3,0 mm de água).
Não seria mais fácil simplesmente mover o ROV para cima e para baixo apenas, com mais um ou dois motores ou hidroplanos apenas, ao invés de um controle de profundidade.
Construi um modelo de submarino que possui controle de profundidade através de hidroplanos apenas e leme para a direção. É um modelo de submarino militar americano da II Guerra (uma das razões do meu interesse no assunto ;D). Ainda possui um sistema de lastro para emergir/submergir apenas.
Dei uma lida no software, o controle de profundidade é apenas o ciclo de trabalho do motor (controle PWM) de profundidade. Não é a profundidade apenas, mas a rotação do motor do eixo Z. Ok?
-
Anderson,
Antes de escrever o programa, que tal definir algumas coisas??
Senhores,
Fiz uma pequena parte do código para acionar iluminação frontal e posterior. A idéia é que possa funcionar da seguinte maneira.
- Aciono o botão pela primeira vez e ligo a iluminação frontal
- aciono o botão novamente e desligo a iluminação frontal
- aciono o botão novamente e ligo a iluminação trazeira
- aciono o botão novamente e desligo a iluminação trazeira
- aciono o botão novamente e ligo a iluminação frontal e trazeira
- aciono o botão novamente e desligo toda a iluminação
Ao invés de fazer essa ginástica toda para ligar e desligar as lâmpadas, dê uma olhada...
Sugestão: usar o mesmo tipo de acionamento para o motor de profundidade, o projeto usa 8 bits. Porque? 3 Bits não atenderiam (como nos outros motores), proposta, usando 2 bytes de comando apenas:
Byte 1:
Bits 0 1 2 3 4 5 6 7
M1 M1 M1 M2 M2 M2 S1 S1
Byte 2:
Bits 0 1 2 3 4 5 6 7
M3 M3 M3 L1 L2 L3 Z+ Z-
M1 - controle do motor 1 (estados RR,MR,LR,P,LF,MF,RF)
M2 - controle do motor 2 (estados RR,MR,LR,P,LF,MF,RF)
M3 - controle do motor 3 (estados RB,MB,LB,P,LC,MC,RC)
S1 - aciona servo 1
L1 - liga/desliga a iluminação frontal
L2 - liga/desliga a iluminação traseira
L3 - liga/desliga a iluminação ou alguma outra carga extra
Z+ - aproximar Zoom
Z- - afastar Zoom
Estados de cada motor DC (M1, M2):
RR = rápido à ré
MR = média velocidade à ré
LR = lento à ré
P - motor parado
LF = lento à frente
MF = média velocidade à frente
RF = rápido à frente
Estados do motor DC de produndidade (M3):
RB = rápido ao fundo
MB = média velocidade ao fundo
LB = lento ao fundo
P - motor parado
LC = lento para cima
MC = média velocidade para cima
RC = rápido para cima
Estados do servo motor (S1):
-90 Graus
0 Graus
+45 Graus
+90 Graus
Não coloquei a reposta do ROV (ainda), o que acha de fazer o ROV sair logo do papel, mais parecido com o projeto original? E apenas com comandos?
-
Dei uma lida no software, o controle de profundidade é apenas o ciclo de trabalho do motor (controle PWM) de profundidade. Não é a profundidade apenas, mas a rotação do motor do eixo Z. Ok?
Gil,
Acho que talvez eu tenha me expressado mal. Não há um controle de profundidade, o rov se movimenta no eixo z sempre que o motor é acionado para cima ou para baixo. Através de um sensor de pressão são coletados dados para cálculo de profundidade, mas não são utilizados para contrôle de profundidade. O rov manten-se em flutuabilidade neutra mantendo-se parado em qualquer profundidade, necessitando apenas de pequenas correções que são conseguidas com pequenos acionamentos no motor.
-
Antes de escrever o programa, que tal definir algumas coisas??
Estão perfeitas suas colocações. É exatamente isso que será necessário.
Não coloquei a reposta do ROV (ainda), o que acha de fazer o ROV sair logo do papel, mais parecido com o projeto original? E apenas com comandos?
Eu não entendi ??? (E apenas com comandos )
-
Anderson,
Não coloquei a reposta do ROV (ainda), o que acha de fazer o ROV sair logo do papel, mais parecido com o projeto original? E apenas com comandos?
Eu não entendi ??? (E apenas com comandos )
É só uma sugestão.... ;D
Não gosto de projetos não terminados, eu mesmo tenho alguns emperrados por aí, por falta de tempo e "excesso de centros de interesse" ;D
Podemos fazer um sistema bidirecional, .... Quais sinais seriam enviados pelo ROV?
-
Podemos fazer um sistema bidirecional, .... Quais sinais seriam enviados pelo ROV?
Sim o sistema bidirecional me parece ser melhor.
Sinais enviados ROV ==> Base
- Pressão
- Salinidade
- compass
- Salinidade
- Umidade no interior do aparelho
Estas são básicas.
-
e os sensores para estas finalidades? já possui?
-
e os sensores para estas finalidades? já possui?
Ainda não, fisicamente. Se tiver alguma sugestão que possa baratear o projeto ?? Os sensores costumam ser caros !!!
-
Anderson,
Podemos fazer um sistema bidirecional, .... Quais sinais seriam enviados pelo ROV?
Sim o sistema bidirecional me parece ser melhor.
Sinais enviados ROV ==> Base
- Pressão
- Salinidade
- compass
- Salinidade
- Umidade no interior do aparelho
Estas são básicas.
Ok, seriam todas variáveis analógicas? Salinidade está repetida?
Pressão - analógica / 8 bits
Salinidade - analógica / 4 bits
Umidade no interior do aparelho - digital / 1 bit
Bússola (compass) com saída serial (TTL) - poderia ser desenvolvida uma interface depois (quando??):
http://en.zc-sensor.com/Detail_Product.php?id=96
[attachthumb=1]
Sugestão do quadro de resposta, 2 bytes como no comando, com o seguinte conteúdo:
Byte 1:
Bits 7 6 5 4 3 2 1 0
Informação: |----------- P1 ------------|
Byte 2:
Bits 7 6 5 4 3 2 1 0
Informação: |-- S1 ---| U1 E1 E2 E3
P1 - sensor de pressão (sinal analógico de 8 bits)
S1 - sensor de salinidade (sinal analógico de 4 bits)
U1 - sensor de umidade
E1 - sensor digital 1 (extra)
E2 - sensor digital 2 (extra)
E3 - sensor digital 3 (extra)
Os sensores digitais extras podem ser: chaves de fim de curso, sensor de fundo, sonda de toque de 1 bit
Os bits S1, S2 e S3 também poderiam ser a saída da bússola com 8 níveis (000 a 111 binário): N - NW - W - SW - S - SO - O - NO
O sinal de salinidade seria de 4 bits ou 1 bit (água salgada / doce)? O valor de salinidade seria expresso em condutividade (concentração salina), em microsiemens x cm? Seria necessário um sensor específico, poderia ser um sensor sem contato com a água (magnético) do tipo toroidal. Daria até para fazer um sensor desses:
http://www.sensorex.com/support/education/conductivity_education.html
-
Se tiver alguma sugestão que possa baratear o projeto ?? Os sensores costumam ser caros !!!
baratos não são ... mas eram bem mais dispendiosos ... se eu encontrar algo em conta lhe aviso.
abrax!
-
De volta aos trabalhos, depois de afastamento por conta de outros serviços.
Estava analizando o projeto original e este não utiliza RS232 nem RS485, simplesmente faz a comunicação entre os dois módulos diretamente. Isso traz que tipo de inconvenientes ???
-
Isso traz que tipo de inconvenientes ???
A interface direta é mais susceptível às interferências.
-
A interface direta é mais susceptível às interferências.
Se os dados a serem transmitidos fossem somente os sinais para a movimentação dos motores, a iluminação e um sinal para servo motor, você faria a transmissaõ pela interface direta ???
-
Se os dados a serem transmitidos fossem somente os sinais para a movimentação dos motores, a iluminação e um sinal para servo motor, você faria a transmissaõ pela interface direta ???
Anderson, veja, a questão não é o que é transmitido, o volume dos dados, mas sua importância, o impacto que a perda da comunicação ou interferências pode causar. Evidentemente a incapacidade, ainda que momentânea, de controlar o veículo, é algo que pode ter consequências funestas ...
Há dois aspectos que eu acho mais importantes, no que se refere à interface de comunicação. Um é a possibilidade de interferência, outra é a distância alcançável.
O ambiente subaquático é bastante limpo, no que se refere às interferências exógenas, eu não me preocuparia muito com este aspecto, mas as interferências endógenas são muito possíveis. Os motores do veículo podem interferir, mas é o tipo de coisa que se deve matar no ninho, eliminar na origem, mas cuidados adicionais melhoram a confiabilidade do sistema.
Quanto a distância, depende da velocidade e das características da interface, aqui não há dúvidas que RS232 ou 485 são muito superiores à interface direta.
Em suma, eu não temeria fazer a transmissão com interface direta no caso de curta distância, mas tenho que dizer que isto é um falso dilema, de vez que é algo muito simples, barato, pequeno peso e volume, não há pq não implementar, exceto talvez para testes.
-
Em suma, eu não temeria fazer a transmissão com interface direta no caso de curta distância, mas tenho que dizer que isto é um falso dilema, de vez que é algo muito simples, barato, pequeno peso e volume, não há pq não implementar, exceto talvez para testes.
Correto, de qualquer forma as informações serviram para fortalecer a decisão de utilizar a RS-485. Vou dar uma estudada no assunto e assim que tenha novidades retorno ao fórum.
Obrigado.
-
Vou dar uma estudada no assunto ...
Um bom ponto de partida:
http://www.maxim-ic.com/app-notes/index.mvp/id/723
-
Um bom ponto de partida:
VALEU !!!
-
[size=2]
;-------------------------------------------------------------
;Software para comando de Joystick e potenciometro
;ROV - Abissal
;Byte 1:
; 7 6 5 4 3 2 1 0
; |----S1---|--------M2-------|--------M1--------|
;
;Byte 2:
; 7 6 5 4 3 2 1 0
; Z- Z+ L3 L2 L1 |-------M3--------|
;
;
; M1 - controle do motor 1 (estados RR,MR,LR,P,LF,MF,RF)
; M2 - controle do motor 2 (estados RR,MR,LR,P,LF,MF,RF)
; M3 - controle do motor 3 (estados RB,MB,LB,P,LC,MC,RC)
; S1 - aciona servo 1
;
; L1 - liga/desliga a iluminação frontal
; L2 - liga/desliga a iluminação traseira
; L3 - liga/desliga a iluminação ou alguma outra carga extra
; Z+ - aproximar Zoom
; Z- - afastar Zoom
;---------------------------------------------------------------
list P=16F877A
#include "P16F877A.INC"
__CONFIG _CP_OFF & _WDT_OFF & _XT_OSC & _PWRTE_ON
errorlevel -302 ; turn off bank bits warning
;
; Seleção de entradas do MUX (ADDCON0)
;
#DEFINE EAN_0 B'01000001' ; f/8, AN0, DONE, A/D On
#DEFINE EAN_1 B'01001001' ; f/8, AN1, DONE, A/D On
#DEFINE EAN_2 B'01010001' ; f/8, AN2, DONE, A/D On
#DEFINE EAN_3 B'01011001' ; f/8, AN3, DONE, A/D On
#DEFINE BOTAO PORTB,7 ; porta do botão da iluminação - 0 = pressionado 1 = liberado
#DEFINE ZOOM_P PORTB,6 ; porta do zoom+ 0 = pressionado 1 = liberado
;
; Saídas
;
#DEFINE LED1 PORTD,7 ;Porta do LED 0 = apagado 1 = aceso
#DEFINE LED2 PORTD,6 ;Porta do LED_D2 0 = apagado 1 = aceso
#DEFINE LED3 PORTD,5 ;Porta do LED_D3 0 = apagado 1 = aceso
#DEFINE LED4 PORTD,4 ;Porta do LED_D4 0 = apagado 1 = aceso
;
; Variáveis da RAM internas
;
cblock H'20'
ld_loop_ex
ld_loop_in
Valor_AN0
Valor_AN1
Valor_AN2
Valor_AN3
Valor_DIG_0
Valor_ZOOM_P
Estado_botao
endc
;
; Inicio do Programa
;
ORG 0h
; Inicializaçao do PIC, do display e da porta serial
bcf STATUS,RP1
bsf STATUS,RP0 ; Habilita banco 1
clrf TRISD ; porta do display, de saída
movlw B'00000010' ; setup do conversor A/D
movwf ADCON1 ; left justify result
; port A: only analogue inputs
;
; Ajusta parametros da UART (usando cristal externo de 4MHz)
; Baud Rate = 9600 bps, No Parity, 1 Stop Bit
;
movlw 0x19 ; 0x19=9600 bps / 0x0C=19200 bps
movwf SPBRG
movlw b'00100100' ; TX_Enable, assync. mode, brgh = high (2)
movwf TXSTA ; enable Async Transmission, BRGH=1
movlw b'10111111' ; RC6 saida, outros bits da PORTC sao de entrada
movwf TRISC
bcf STATUS,RP0 ; Habilita banco 0
clrf PORTD ; zera saídas do display
movlw b'01000000' ; Setup Port C
movwf PORTC ; RC6(TX)=1 others are 0
movlw b'10000000' ; habilita a UART
movwf RCSTA
movlw b'11111111' ; PORTB todo como entrada
movwf TRISB
;
; Loop principal
;
start:
;-------Ler entradas
movlw EAN_0 ; lendo entrada analógica 0
call read_ad ; chama a rotina de conversão AD
movwf Valor_AN0 ; carrega o valor convertido em Valor_AN0
movlw EAN_1 ; lendo entrada analógica 1
call read_ad ; chama a rotina de conversão AD
movwf Valor_AN1 ; carrega o valor convertido em Valor_AN1
movlw EAN_2 ; lendo entrada analógica 2
call read_ad ; chama a rotina de conversão AD
movwf Valor_AN2 ; carrega o valor convertido em Valor_AN2
movlw EAN_3 ; lendo entrada analógica 3
call read_ad ; chama a rotina de conversão AD
movwf Valor_AN3 ; carrega o valor convertido em Valor_AN3
btfsc BOTAO ; lendo entrada digital 0. O botão está pressionado ?
call pressionado ; Sim, então vá para rotina pressionado.
call liberado ; Não, então vá para rotina liberado.
btfsc ZOOM_P ; lendo entrada digital 0. O botão está pressionado ?
call zoom_menos ; Não, então vá para rotina zoom_mais.
call zoom_mais ; Sim, então vá para rotina zoom_menos.
movwf Valor_ZOOM_P ;carrega o valor de LED aceso em Valor_DIG_0
goto envia ;vai para a rotina envia
liberado:
bsf LED1 ;apaga o LED
movlw b'00001000'
movwf Valor_DIG_0 ;carrega o valor de LED apagado em Valor_DIG_0
goto envia ;vai para a rotina envia
return
pressionado:
bcf LED1
movlw b'00000000' ;acende o LED
movwf Valor_DIG_0 ;carrega o valor de LED aceso em Valor_DIG_0
goto envia ;vai para a rotina envia
return
zoom_mais:
bsf LED2
movlw b'00001000' ;acende o LED
;movwf Valor_ZOOM_P ;carrega o valor de LED aceso em Valor_DIG_0
;goto envia ;vai para a rotina envia
return
zoom_menos:
bcf LED2
movlw b'00000000' ;acende o LED
;movwf Valor_ZOOM_P ;carrega o valor de LED aceso em Valor_DIG_0
;goto envia ;vai para a rotina envia
return
;-------Enviando dadops pela serial
envia:
movfw Valor_AN0 ; recupera o valor convertido para ser enviado
call send ; chama a rotina de envio pela serial
movfw Valor_AN1 ; recupera o valor convertido para ser enviado
call send ; chama a rotina de envio pela serial
movfw Valor_AN2 ; recupera o valor convertido para ser enviado
call send ; chama a rotina de envio pela serial
movfw Valor_AN3 ; recupera o valor convertido para ser enviado
call send ; chama a rotina de envio pela serial
movfw Valor_DIG_0 ; recupera o valor do LED para ser enviado
call send ; chama a rotina de envio pela serial
movfw Valor_ZOOM_P ; recupera o valor do LED para ser enviado
call send ; chama a rotina de envio pela serial
call delay1s ; chama as rotinas de tempo para aguardar o termino da transmissão
goto start
;
; Envia byte (contido em W) pela UART e espera terminar
;
send:
movwf TXREG ; send data in W
TransWt:
bsf STATUS,RP0 ; banco 1
WtHere:
btfss TXSTA,TRMT ; Transmissao terminou se TRUE
goto WtHere ; Senao, espera
bcf STATUS,RP0 ; banco 0
return
;
; Conversor A/D, palavra ADDCON0 em W
;
read_ad:
movwf ADCON0
bsf ADCON0,GO ; Iniciar conversao
wait:
btfsc ADCON0,GO ; Testa se terminou conversao
goto wait
movf ADRESH,W
return
;
; Display de LEDs
;
display:
movwf PORTD
return
;
;-----------------------------------------------------------------------------
;
; Delay for about 1s
;
delay1s:
movlw D'250'
call waitx400
movlw D'250'
call waitx400
movlw D'250'
goto waitx400
;
;-----------------------------------------------------------------------------
;
; Delay for about 250 ms
;
delay250ms:
movlw D'250'
goto waitx400
;
;-----------------------------------------------------------------------------
;
; Delay for about 400x cycles
;
; Se w=1, temporiza 1ms @ fck = 4MHz
;
waitx400:
movwf ld_loop_ex
ld_loopex:
movlw (400-4)/4
movwf ld_loop_in
ld_loopin:
decf ld_loop_in,F
skpz
goto ld_loopin
decf ld_loop_ex,F
skpz
goto ld_loopex
return
END[/size]
No código não estou conseguindo equacionar um problema relativamente simples: Tenho 4 entradas analógicas e duas digitais, as analógicas estão sendo lidas e transmitidas regularmente. A entrada digital "BOTAO" também funciona normalmente, mas a "ZOOM_P" simplesmente não consigo fazer funcionar. Não transmite, não consigo fazer acender os leds , nada.
-
Anderson, eu esperaria dois botões para zoom, (+) e (-) e um bit para cada função, no entanto parece que vc não definiu corretamente os bits e as chamadas para as subrotinas, veja:
7 6 5 4 3 2 1 0
Z- Z+ L3 L2 L1 |-------M3--------|
#DEFINE BOTAO PORTB,7 ; porta do botão da iluminação - 0 = pressionado 1 = liberado
#DEFINE ZOOM_P PORTB,6 ; porta do zoom+ 0 = pressionado 1 = liberado
-
Pessoal,
Estou realizando testes no código e ao utilizar a janela watch do MPLab pude verificar que estão disponíveis somente os SFR. Como faço para habilitar Add Symbol para visualização ?
Grato,
-
Watch Window FAQ
How do I:
Add a watch (address, SFR or symbol) to a Watch window?
Select the Watch window you want by clicking on the appropriate button in the bottom of the window.
To add a watch at a specific address, click in the Address column of the first available row and enter a hex address.
To add a special function register to a Watch view, select the SFR from the list next to the Add SFR button and then click on the button. To add a symbol to a Watch view, select the symbol from the list next to the Add Symbol button and then click on the button.
-
Select the Watch window you want by clicking on the appropriate button in the bottom of the window.
To add a watch at a specific address, click in the Address column of the first available row and enter a hex address.
Certo, mas o que está acontecendo é que na janela "Watch" o botão para seleção dos SFR está disponível e o botão para seleção de "Add Symbol" está desabilitado, não permitindo a inclusão de nenhum registro para visualização.
-
... o que está acontecendo é que na janela "Watch" o botão para seleção dos SFR está disponível e o botão para seleção de "Add Symbol" está desabilitado ...
O programa está carregado e o simulador habilitado ?
-
O programa está carregado e o simulador habilitado ?
Sim, programa carregado e simulador habilitado....
....Acaba que fiquei procurando alguma configuração e agora está funcionando normalmente. O pior é que não sei em que eu mexi que retornou ao funcionamento normal.
-
Estou montando meus dois bytes para transmissão, está ficando assim:
;-------Ler entradas Analógicas
bcf STATUS,RP0 ; Habilita banco 0
movlw EAN_0 ; lendo entrada analógica 0
call read_ad ; chama a rotina de conversão AD
andlw 0xE0 ; mascara os três bits mais significativos e coloca o resultado em W
movwf SER_DATA_1 ; SER_DATA_1 = [X7 X6 X5 0, 0 0 0 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [0 X7 X6 X5, 0 0 0 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [0 0 X7 X6, X5 0 0 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [0 0 0 X7, X6 X5 0 0]
movlw EAN_1 ; lendo entrada analógica 1
call read_ad ; chama a rotina de conversão AD
andlw 0xE0 ; mascara os três bits mais significativos e coloca o resultado em W
addwf SER_DATA_1,F ; SER_DATA_1 = [Y7 Y6 Y5 X7, X6 X5 0 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [ 0 Y7 Y6 Y5, X7 X6 X5 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [ 0 0 Y7 Y6, Y5 X7 X6 X5]
movlw EAN_2 ; lendo entrada analógica 2
call read_ad ; chama a rotina de conversão AD
andlw 0xE0 ; mascara os três bits mais significativos e coloca o resultado em W
addwf SER_DATA_1,F ; SER_DATA_1 = [Y7 Y6 Y5 X7, X6 X5 0 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [ 0 Y7 Y6 Y5, X7 X6 X5 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [ 0 0 Y7 Y6, Y5 X7 X6 X5]
movlw EAN_3 ; lendo entrada analógica 3
call read_ad ; chama a rotina de conversão AD
andlw 0xE0 ; mascara os três bits mais significativos e coloca o resultado em W
addwf SER_DATA_2,F ; SER_DATA_2 = [Z7 Z6 Z5 0, 0 0 0 0]
rrf SER_DATA_2,F ; SER_DATA_2 = [ 0 Z7 Z6 Z5, 0 0 0 0]
rrf SER_DATA_2,F ; SER_DATA_2 = [ 0 0 Z7 Z6, Z5 0 0 0]
rrf SER_DATA_2,F ; SER_DATA_2 = [ 0 0 0 Z7, Z6 Z5 0 0]
rrf SER_DATA_2,F ; SER_DATA_2 = [ 0 0 0 0, Z7 Z6 Z5 0]
rrf SER_DATA_2,F ; SER_DATA_2 = [ 0 0 0 0, 0 Z7 Z6 Z5]
É isso mesmo ???
-
Pessoal,
Meu Proteus travou e precisei desinstalá-lo. Agora não consigo instalar novamente o software. Alguma sugestão ?
O software é carregado mas na hora da simulação sempre falta alguma dll. Segue a mensagem que aparece:
SIMULATION LOG
==============
Design: H:\Arquivos de Instalação\PROTEUS\SAMPLES\Chess\avrchess.DSN
Doc. no.: <NONE>
Revision: <NONE>
Author: <NONE>
Created: 19/09/01
Modified: 21/02/02
Compiling source files...
Build completed OK.
Compiling netlist...
Linking netlist...
Partition analysis...
Simulating partition 1 [0717C76C]...
PROSPICE Release 6.2 SP0 (C) Labcenter Electronics 1993-2002.
SPICE Kernel Version 3f5. (C) Berkeley University ERL.
Reading netlist...
FATAL: [CHESS-KEYPAD#0011] External model DLL "KEYPAD.DLL" not found. GLE=0x00000003.
Simulation FAILED due to fatal simulator errors.
Grato
-
vc jah desinstalou ... fez uma limpeza no arquivo de registro .. apagou a pasta onde o proteus foi instalado ... reiniciou o pc e tentou reinstalar tudo de novo?
-
vc jah desinstalou ... fez uma limpeza no arquivo de registro .. apagou a pasta onde o proteus foi instalado ... reiniciou o pc e tentou reinstalar tudo de novo?
Vou experimentar a limpeza no arquivo de registro, o resto fiz tudo.
Resolvido. O software já está funcionando normalmente.
-
Neste projeto as duas unidades (comando = Joystick e Controle = Rov) comunicam-se serialmente. Serão transmitidos dois bytes com a seguinte estrutura:
;Byte 1:
; 7 6 5 4 3 2 1 0
; |----S1---|--------M2-------|--------M1--------|
;
;Byte 2:
; 7 6 5 4 3 2 1 0
; Z- Z+ L3 L2 L1 |-------M3--------|
Pergunto:
1) No programa da unidade de comando vou enviar bit a bit e montar o meu byte no software da unidade de controle ?
2) Quando faço o mascaramento do meu byte e rotaciono os bits eles não deveriam aparecer para M1, M2 e M3 agrupados ? ou eles são rotacionados bit a bit e transmitidos para depois serem agrupados formando o meu byte de transmissão ?
Grato,
-
Anderson, se usar fonte com espaçamento constante como a Courier os diagramas ficam bem mais legíveis:
;Byte 1:
; 7 6 5 4 3 2 1 0
; |----S1---|--------M2-------|--------M1--------|
;
;Byte 2:
; 7 6 5 4 3 2 1 0
; Z- Z+ L3 L2 L1 |-------M3--------|
Pelo teor das questões receio que vc não tenha ainda compreendido todo o processo ...
1) No programa da unidade de comando vou enviar bit a bit e montar o meu byte no software da unidade de controle ?
Veja, podemos dizer que a transmissão é bit-a-bit pq a transmissão é serial, mas isto pode confundir ... na verdade a UART transmite e recebe byte a byte ... isto é verdade mesmo quando não se dispõe de UART no hardware e se usa bit banging* ...
O habitual é colocar os bytes recebidos em um buffer para processamento posterior, após todo o pacote ter sido transmitido, mas nada impede que sejam processados on the fly se houver handshaking adequado ...
2) Quando faço o mascaramento do meu byte e rotaciono os bits eles não deveriam aparecer para M1, M2 e M3 agrupados ?
Os bits correspondentes a M1 e M2 devem aparecer agrupados no primeiro byte, os de M3 no segundo byte ... ou seja, como os tiver agrupado ...
ou eles são rotacionados bit a bit e transmitidos para depois serem agrupados formando o meu byte de transmissão ?
Vc monta o(s) byte(s) com os grupos de bits e depois transmite. A operação inversa será efetuada no receptor, o(s) byte(s) será(ão) recebido(s) e depois quebrado(s), separando os bits ou grupo de bits componentes, que por sua vez serão processados, redundando na ação desejada.
* Fui espiar o código do projeto original e se bem entendi são transmitidos 16 bits precedidos por um start bit e sucedidos por um stop bit e um delay para sincronismo entre as sucessivas transmissões. Isto foge um pouco do convencional mas o dito acima ainda é válido.
-
Anderson, se usar fonte com espaçamento constante como a Courier os diagramas ficam bem mais legíveis:
Certo, valeu a dica.
Então, pelo que entendi cheguei ao seguinte:
.....
1) fiz a leitura da minha entrada analógica
2) converto o valor em digital e retorno com o valor digital carregado em "W" e aí:
[okay]
Neste trecho rotacionaei os bits do MOTOR X
andlw 0xE0 ; mascara os três bits mais significativos e coloca o resultado em W
movwf SER_DATA_1 ; SER_DATA_1 = [X7 X6 X5 0, 0 0 0 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [ 0 X7, X6 X5, 0 0 0 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [ 0 0 X7 X6, X5 0 0 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [ 0 0 0 X7, X6 X5 0 0]
Neste trecho rotacionaei os bits do MOTOR Y
call read_ad ; chama a rotina de conversão AD
andlw 0xE0 ; mascara os três bits mais significativos e coloca o resultado em W
addwf SER_DATA_1,F ; SER_DATA_1 = [Y7 Y6 Y5 X7, X6 X5 0 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [ 0 Y7 Y6 Y5, X7 X6 X5 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [ 0 0 Y7 Y6, Y5 X7 X6 X5] ....
Após eu vou rotacionar os bits do motor Z e depois disso vou fazer a minha transmissão. É por aí ???
[/okay]
O meu joystick envia valores para conversão AD. Esses valores, após a conversão, terão três bits. Ainda não entendi como isso acontece. :-\
-
* Fui espiar o código do projeto original e se bem entendi são transmitidos 16 bits precedidos por um start bit e sucedidos por um stop bit e um delay para sincronismo entre as sucessivas transmissões. Isto foge um pouco do convencional mas o dito acima ainda é válido.
Como assim...., eu ainda preciso aprender muito. Quando você diz que foge do convencional, poderia me dar uma explicação à respeito ?
Grato
-
Após eu vou rotacionar os bits do motor Z e depois disso vou fazer a minha transmissão. É por aí ???
É por aí ...
O meu joystick envia valores para conversão AD. Esses valores, após a conversão, terão três bits. Ainda não entendi como isso acontece. :-\
Veja um trecho do prog original:
[info];********************************************************************************
;* Main program loop *
;********************************************************************************
MAIN movlw 0xC9 ; channel 1 (GP1/AN1/Pin 6), A/D module on
call SAMPLE ; sample AN1 (Y axis), value returns in W
andlw 0xE0 ; mask 3 most sig bits, put result in W
.
.
.[/info]
Observe que a rotina de leitura do conversor AD é chamada e a leitura retorna em W, uma grandeza de oito bits. A seguir o byte é mascarado, restando apenas os três bits mais significativos ...
-
Observe que a rotina de leitura do conversor AD é chamada e a leitura retorna em W, uma grandeza de oito bits. A seguir o byte é mascarado, restando apenas os três bits mais significativos ...
Entendo, e sempre utilizaremos os três bits mais significativos ?
-
Entendo, e sempre utilizaremos os três bits mais significativos ?
Quase sempre os bits mais significativos, não necessariamente três. Isto está ligado à resolução adequada para o caso, aqui o autor entendeu que três bits oferecem resolução suficiente para o controle dos motores, para outras aplicações pode ser necessária uma maior granularidade, pan-tilt de uma cam, por exemplo ...
-
Quase sempre os bits mais significativos, não necessariamente três. Isto está ligado à resolução adequada para o caso, aqui o autor entendeu que três bits oferecem resolução suficiente para o controle dos motores, para outras aplicações pode ser necessária uma maior granularidade, pan-tilt de uma cam, por exemplo ...
Então a definição da quantidade de bits é feita pela mascara ?
-
Então a definição da quantidade de bits é feita pela mascara ?
Sim, a máscara determina quantos e quais bits serão selecionados para o posterior processamento. Como são três bits e os mais significativos, a excursão total do potenciômetro será dividida em oito regiões distintas:
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|<--- curso total --->|
ou seja, apenas oito valores discretos serão possíveis, pequenos movimentos do joystick não serão percebidos.
-
Como são três bits e os mais significativos, a excursão total do potenciômetro será dividida em oito regiões distintas:
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|<--- curso total --->|
ou seja, apenas oito valores discretos serão possíveis, pequenos movimentos do joystick não serão percebidos.
Isso pode ser traduzido em precisão de movimentos, correto ?
Os três bits se conjugam para possibilitar os movimentos conforme tabela onde conjugo velocidades e direções, por ex.:
A---B---C A=0 (à ré) B------C
1---1---1 à frente, alta vel. A=1 (à frente) 1------1 Alta vel
1---1---0 à frente, vel. média 1------0 vel. média
1---0---1 à frente, baixa vel. 0------1 baixa vel.
1---0---0 parado 0------0 parado
0---1---1 à ré, alta vel.
0---1---0 à ré, vel. média
0---0---1 à ré, baixa vel.
0---0---0 parado
Conforme o que você coloca o curso total do potenciômetro será dividido em oito porções. Considerando que a posição de descanso do potenciômetro no joystick fica a meio curso, pode-se dizer que R/2 equivalerá a inexistência de movimento. Essa equivalência de valores eu é quem determino ? Por ex. Para cada percentual de leitura de curso dos potenciômetros eu atribuo um valor conforme minha tabela de possibilidades de conjugação de movimentos e velocidades entre os três bits considerados para cada motor e envio esses valores para transmissão ?
-
Isso pode ser traduzido em precisão de movimentos, correto ?
A rigor estamos falando de resolução e não de precisão.
Essa equivalência de valores eu é quem determino ?
Sim.
Por ex. Para cada percentual de leitura de curso dos potenciômetros eu atribuo um valor conforme minha tabela de possibilidades de conjugação de movimentos e velocidades entre os três bits considerados para cada motor e envio esses valores para transmissão ?
Vc pode fazer a conversão no transmissor ou no receptor. No prog original o Tx envia a posição bruta do pot, sem qualquer processamento adicional, o que vai ocorrer no Rx:
[info]
;********************************************************************************
;* POSJUMP -- Joystick Data to Motor Speed Jump Table *
;********************************************************************************
; Uses first six bits of received joystick position data X and Y (64 unique
; positions) to reference and return a left and right motor direction/speed
; combination as:
;
; 7 6 5 4 3 2 1 0
; |_______||_______||_______||_______||_______||_______||_______||_______|
; 0 0 \DIR_L/ \-- SPEED_L ---/ \DIR_R/ \-- SPEED_R ---/
;
; Note that the joystick position grid contains a one position dead-zone about
; each axis. Example: X=011,Y=000 is identical speedwise as X=011,Y=100 (in
; both cases speed Y is zero).
;
[/info]
-
Jorge, não posso deixar de agradecer. Sua ajuda tem sido de extrema importância. Obrigado :)
-
Jorge, não posso deixar de agradecer. Sua ajuda tem sido de extrema importância. Obrigado :)
É sempre um prazer, Anderson ! ;D
-
Bom pessoal, parece que o código da unidade de comando está funcionando. Eu agora vou passar ao código da unidade de controle, onde ficam os motores. Para quem quiser dar uma olhada ficou assim:
;-------------------------------------------------------------
;Software para comando de Joystick e potenciometro
;ROV - Abissal
;Byte 1:
; 7 6 5 4 3 2 1 0
; |----S1---|--------M2-------|--------M1--------|
;
;Byte 2:
; 7 6 5 4 3 2 1 0
; Z- Z+ |--------L--------|-------M3--------|
;
;
; M1 - controle do motor 1 (estados RR,MR,LR,P,LF,MF,RF)
; M2 - controle do motor 2 (estados RR,MR,LR,P,LF,MF,RF)
; M3 - controle do motor 3 (estados RB,MB,LB,P,LC,MC,RC)
; S1 - aciona servo 1
; L - controle da iluminação (estado 50% - 75% - 100%)
; Z+ - aproximar Zoom
; Z- - afastar Zoom
;---------------------------------------------------------------
list P=16F877A
#include "P16F877A.INC"
__CONFIG _CP_OFF & _WDT_OFF & _XT_OSC & _PWRTE_ON
errorlevel -302 ; turn off bank bits warning
;
; Seleção de entradas do MUX (ADDCON0)
;
#DEFINE EAN_0 B'01000001' ; f/8, AN0, DONE, A/D On - Eixo X
#DEFINE EAN_1 B'01001001' ; f/8, AN1, DONE, A/D On - Eixo Y
#DEFINE EAN_2 B'01010001' ; f/8, AN2, DONE, A/D On - Eixo Z
#DEFINE EAN_3 B'01011001' ; f/8, AN3, DONE, A/D On - Iluminação
#DEFINE SERVO B'01100001' ; f/8, AN5, DONE, A/D On - Servo Motor 0º - 45º - 90° - 135° = pressionado 1 = liberado
#DEFINE ZOOM_AP PORTB,6 ; porta do zoom+ 0 = liberado 1 = pressionado
#DEFINE ZOOM_AF PORTB,5 ; porta do zoom- 0 = liberado 1 = pressionado
;
; Saídas
;
#DEFINE LED2 PORTD,6 ;Porta do LED_D2 0 = apagado 1 = aceso
#DEFINE LED1 PORTD,5 ;Porta do LED_D1 0 = apagado 1 = aceso
;
; Variáveis da RAM internas
;
cblock H'20'
ld_loop_ex
ld_loop_in
Valor_AN0
Valor_AN1
Valor_AN2
Valor_AN3
Valor_DIG_0
Valor_ZOOM_AP
Valor_ZOOM_AF
SER_DATA_1
SER_DATA_2
endc
;
; Inicio do Programa
;
ORG 0h
; Inicializaçao do PIC e da porta serial
bcf STATUS,RP1
bsf STATUS,RP0 ; Habilita banco 1
movlw b'00000000' ; PORTD todo como saída
movwf TRISD
movlw B'00000010' ; setup do conversor A/D
movwf ADCON1 ; left justify result, 6 least significant bits are read as "0"
; port A: [D D D A, A A A A] (digital and analog inputs)
;
; Ajusta parametros da UART (usando cristal externo de 4MHz)
; Baud Rate = 9600 bps, No Parity, 1 Stop Bit
;
movlw 0x19 ; 0x19=9600 bps / 0x0C=19200 bps
movwf SPBRG
movlw b'00100100' ; TX_Enable, assync. mode, brgh = high (2)
movwf TXSTA ; enable Async Transmission, BRGH=1
movlw b'10111111' ; RC6 saida, outros bits da PORTC sao de entrada
movwf TRISC
bcf STATUS,RP0 ; Habilita banco 0
clrf PORTD ; zera saídas do display
movlw b'01000000' ; Setup Port C
movwf PORTC ; RC6(TX)=1 others are 0
movlw b'10000000' ; habilita a UART
movwf RCSTA
movlw b'11111111' ; PORTB todo como entrada
movwf TRISB
;
; Loop principal
;
start:
;-------Ler entradas Analógicas e ...
;------- ... preparar BYTE 1 para transmissão
bcf STATUS,RP0 ; Habilita banco 0
movlw EAN_0 ; lendo entrada analógica 0, colocando valor em W
call read_ad ; chama a rotina de conversão AD
andlw 0xE0 ; mascara os três bits mais significativos e coloca o resultado em W
movwf SER_DATA_1 ; SER_DATA_1 = [X7 X6 X5 0, 0 0 0 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [0 X7 X6 X5, 0 0 0 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [0 0 X7 X6, X5 0 0 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [0 0 0 X7, X6 X5 0 0]
movlw EAN_1 ; lendo entrada analógica 1
call read_ad ; chama a rotina de conversão AD
andlw 0xE0 ; mascara os três bits mais significativos e coloca o resultado em W
addwf SER_DATA_1,F ; SER_DATA_1 = [Y7 Y6 Y5 X7, X6 X5 0 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [ 0 Y7 Y6 Y5, X7 X6 X5 0]
rrf SER_DATA_1,F ; SER_DATA_1 = [ 0 0 Y7 Y6, Y5 X7 X6 X5]
movlw SERVO ; lendo entrada analógica do servo motor
call read_ad ;chama a rotina de conversão AD
andlw 0XC0
addwf SER_DATA_1,F ; SER_DATA_1 = [S2 S1 Y7 Y6, Y5 X7 X6 X5]
movlw EAN_2 ; lendo entrada analógica 2
call read_ad ; chama a rotina de conversão AD
andlw 0xE0 ; mascara os três bits mais significativos e coloca o resultado em W
movwf SER_DATA_2 ; SER_DATA_2 = [Z7 Z6 Z5 0, 0 0 0 0]
rrf SER_DATA_2,F ; SER_DATA_2 = [ 0 Z7 Z6 Z5, 0 0 0 0]
rrf SER_DATA_2,F ; SER_DATA_2 = [ 0 0 Z7 Z6, Z5 0 0 0]
rrf SER_DATA_2,F ; SER_DATA_2 = [ 0 0 0 Z7, Z6 Z5 0 0]
movlw EAN_3 ; lendo entrada analógica 3
call read_ad ; chama a rotina de conversão AD
andlw 0xE0 ; mascara os três bits mais significativos e coloca o resultado em W
addwf SER_DATA_2,F ; SER_DATA_2 = [L7 L6 L5 Z7, Z6 Z5 0 0]
rrf SER_DATA_2,F ; SER_DATA_2 = [ 0 L7 L6 L5, Z7 Z6 Z5 0]
rrf SER_DATA_2,F ; SER_DATA_2 = [ 0 0 L7 L6, L5 Z7 Z6 Z5]
;-------Ler entradas Digitais
btfss ZOOM_AP ; lendo entrada digital RB6. O botão está pressionado ?
call zoom_ap_mais ; Sim, então vá para rotina zoom_ap_mais.
btfss ZOOM_AF ; lendo entrada digital RB5. O botão está pressionado ?
call zoom_af_mais ; Sim, então vá para rotina zoom_menos.
goto envia
;-------Rotinas
;
; Conversor A/D, palavra ADDCON0 em W
;
read_ad:
movwf ADCON0
bsf STATUS,RP0
movlw 0x02
movwf ADCON1
bcf STATUS,RP0
bsf ADCON0,GO ; Iniciar conversao
wait:
btfsc ADCON0,GO ; Testa se terminou conversao
goto wait
; movlw b'11111100' ;*************************************************** esta linha deverá ser retirada daquí.
;movwf ADRESH
movf ADRESH,W
return
zoom_ap_mais:
bsf LED2
bsf SER_DATA_2,6
movlw b'01000000' ;acende o LED
movwf Valor_ZOOM_AP ;carrega o valor de LED2 em Valor_ZOOM_AP
movwf PORTD
return
zera_zoom_ap_mais:
call waitx400
bcf LED2
movlw b'00000000'
movwf Valor_ZOOM_AP
bcf PORTD,6
return
zoom_af_mais:
bsf LED1
bsf SER_DATA_2,7
movlw b'00100000' ;apaga o LED
movwf Valor_ZOOM_AF ;carrega o valor de LED1 em Valor_ZOOM_AP
return
zera_zoom_af_mais:
call waitx400
bcf LED1
movlw b'00000000'
movwf Valor_ZOOM_AF
bcf PORTD,5
return
;-------Enviando dados pela serial
envia:
movfw SER_DATA_1 ; recupera o valor convertido para ser enviado
call send ; chama a rotina de envio pela serial
movfw SER_DATA_2 ; recupera o valor convertido para ser enviado
call send ; chama a rotina de envio pela serial
call delay1s ; chama as rotinas de tempo para aguardar o termino da transmissão
call zera_zoom_ap_mais
call zera_zoom_af_mais
goto start
;
; Envia byte (contido em W) pela UART e espera terminar
;
send:
movwf TXREG ; send data in W
TransWt:
bsf STATUS,RP0 ; banco 1
WtHere:
btfss TXSTA,TRMT ; Transmissao terminou se TRUE
goto WtHere ; Senao, espera
bcf STATUS,RP0 ; banco 0
return
;
; Display de LEDs
;
display:
movwf PORTD
return
;
;-----------------------------------------------------------------------------
;
; Delay for about 1s
;
delay1s:
movlw D'250'
call waitx400
movlw D'250'
call waitx400
movlw D'250'
goto waitx400
;
;-----------------------------------------------------------------------------
;
; Delay for about 250 ms
;
delay250ms:
movlw D'250'
goto waitx400
;
;-----------------------------------------------------------------------------
;
; Delay for about 400x cycles
;
; Se w=1, temporiza 1ms @ fck = 4MHz
;
waitx400:
movwf ld_loop_ex
ld_loopex:
movlw (400-4)/4
movwf ld_loop_in
ld_loopin:
decf ld_loop_in,F
skpz
goto ld_loopin
decf ld_loop_ex,F
skpz
goto ld_loopex
return
END
-
Pessoal,
Uma pergunta muito básica, mas que não estou encontrando resposta clara em lugar algum.
Quando trabalhamos no MPLAB criamos um Workspace que guarda as configurações referentes ao trabalho. Dentro deste teremos gravado o projeto e dentro do projeto o código fonte. Quando temos mais de um código fonte vou colocá-lo dentro do mesmo projeto ?
-
Quando temos mais de um código fonte vou colocá-lo dentro do mesmo projeto ?
Se o código é pertinente ao mesmo projeto faz sentido, se é parte de outro projeto vai acabar criando confusão ... O help do MPLAB me parece esclarecedor:
[info]
Projects and Workspaces
--------------------------------------------------------------------------------
Two major features of MPLAB IDE are projects and workspaces.
A project contains the files needed to build an application (source code, linker script files, etc.) along with their associations to various build tools and build options.
A workspace contains information on the selected device, debug tool and/or programmer, open windows and their location and other IDE configuration settings.
The best way to set up your project and its associated workspace is by using the Project Wizard. This will set up one project in one workspace.
To set up more advanced applications, you may set up your project and workspace manually. You can take advantage of the workspace setup and open multiple projects in one workspace. Also, you can tailor each project in a multiple-project workspace to create one part of a larger application (concurrent projects).
If you are working with a single assembly file application, you can use Quickbuild (Project>Quickbuild) to assemble your code and not create a project. You will, however, have an associated workspace, so your settings will be saved.
[/info]
No caso do ROV eu consideraria Tx e RX projetos diferentes que podem ser tratados em um mesmo workspace.
-
No caso do ROV eu consideraria Tx e RX projetos diferentes que podem ser tratados em um mesmo workspace.
Assim os códigos podem ter maior "portabilidade", pode-se dizer.
-
[error]Parece-me que falta algo na transmissão serial no meu código. Como estou fazendo, os bytes transmitidos não tem nem stop nem start bit. Andei lendo a respeito ma não entendi direito como faço a transmissão. Entendi que preciso criar um contador que fará a transmissão em nove tempos distintos. E no caso de fazer a transmissão do byte inteiro como falamos anteriormente. ???[/error]
-
Como estou fazendo, os bytes transmitidos não tem nem stop nem start bit.
Como chegou a esta conclusão ?
A USART cuida da inserção dos bits de início e fim ...
Andei lendo a respeito mas não entendi direito como faço a transmissão. Entendi que preciso criar um contador que fará a transmissão em nove tempos distintos.
Vc leu a Section 18. USART do PIC Mid-Range MCU Family Reference Manual ?
E no caso de fazer a transmissão do byte inteiro como falamos anteriormente. ???
Nada de fundamental muda, mas pode simplificar o prog do transmissor e o debugging via terminal ...
-
Como chegou a esta conclusão ?
;D
A USART cuida da inserção dos bits de início e fim ...
;D ;D
Vc leu a Section 18. USART do PIC Mid-Range MCU Family Reference Manual ?
;D ;D ;D
Preciso estudar muito... ;D ;D ;D ;D
-
No trecho de código do meu programa....
[info]; Ajusta parametros da UART (usando cristal externo de 4MHz)
; Baud Rate = 9600 bps, No Parity, 1 Stop Bit
;
movlw 0x19 ; 0x19=9600 bps / 0x0C=19200 bps
movwf SPBRG
movlw b'00100100' ; TX_Enable, assync. mode, brgh = high (2)
movwf TXSTA ; enable Async Transmission, BRGH=1[/info]
O bit grafado não deveria estar em "1" para habilitar a transmissão do "9-bit transmission"
-
Estou procurando por sensor de pressão para utilização no projeto do ROV. Alguém conhece ou já utiliou algum sensor que possa me indicar. As carcterísticas são: Preesão máxima 600 Kpa, alimentação até 12 VCC.
Grato
-
Estou procurando por sensor de pressão ...
A Freescale tem uma linha extensa e não é difícil encontrar os componentes em nosso mercado:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPX5999
-
O bit grafado não deveria estar em "1" para habilitar a transmissão do "9-bit transmission"
Sim. É isto o que vc quer ?
[info]bit 6 TX9: 9-bit Transmit Enable bit
1 = Selects 9-bit transmission
0 = Selects 8-bit transmission [/info]
-
Sim. É isto o que vc quer ?
Sim, para fazer a transmissão com start e stop bit isto não é necessário ?
-
Sim, para fazer a transmissão com start e stop bit isto não é necessário ?
Não. Aquele bit TX9 determina o número de bits de dados ou eventualmente pode-se utilizar um nono bit como o de paridade ( a ser inserido e verificado pelo software).
É importante que vc entenda que sempre há pelo menos um bit de partida e outro de parada quando a comunicação é assíncrona. É isto que permite o sincronismo e verificação de erro caracter-a-caracter, não importando de quantos bits o caracter é composto.
Eu optaria por oito bits, que é o formato mais comum, as exceções são raras. Todos os microcontroladores trabalham com oito bits ou múltiplos, é mais conveniente lidar com este tamanho e isto permite tb utilizar muitas rotinas enlatadas e a utilização de diversos instrumentos de simulação, testes e pesquisa de defeitos, como um PC ou um terminal serial, o que frequentemente é muito útil.
[info]18.4 USART Asynchronous Mode
In this mode, the USART uses standard nonreturn-to-zero (NRZ) format (one start bit, eight or
nine data bits and one stop bit). The most common data format is 8-bits.
.
.
.
Parity is not supported by the hardware, but can be implemented in software (stored as the ninth
data bit)
[/info]