collapse

* Posts Recentes

Amplificador - Rockboard HA 1 In-Ear por almamater
[Ontem às 19:13]


O que é isto ? por KammutierSpule
[26 de Março de 2024, 19:35]


Bateria - Portátil por almamater
[25 de Março de 2024, 22:14]


Emulador NES em ESP32 por dropes
[13 de Março de 2024, 21:19]


Escolher Osciloscópio por jm_araujo
[06 de Fevereiro de 2024, 23:07]


TP4056 - Dúvida por dropes
[31 de Janeiro de 2024, 14:13]


Leitura de dados por Porta Serie por jm_araujo
[22 de Janeiro de 2024, 14:00]


Distancia Cabo por jm_araujo
[08 de Janeiro de 2024, 16:30]


Meu novo robô por josecarlos
[06 de Janeiro de 2024, 16:46]


Laser Engraver - Alguém tem? por almamater
[16 de Dezembro de 2023, 14:23]

Autor Tópico: Delay OneWire Thermo  (Lida 8203 vezes)

0 Membros e 1 Visitante estão a ver este tópico.

Offline bdesigns

  • Mini Robot
  • *
  • Mensagens: 38
  • Return 1
Delay OneWire Thermo
« em: 21 de Junho de 2010, 00:02 »
Boas Noites  ;D
Ando aqui numas brincadeiras utilizando o 74HC164 (serial In, Parallel Out), e 3 displays de 7-segmentos, todos ligados ao mesmo 74HC164  e depois comuto entre eles.
O código está bastante funcional quanto a essa parte, já testei a contar eventos, ou até mesmo a fazer percorrer os números de 0 a 999 e vice versa.
Hoje lembrei-me de brincar com o ds18s20, e adicionar ao projecto já existente, pois bem, o mesmo parece que cria quase um atraso de 1 segundo para obter a temperatura e depois realizar a conversão.
Alguém sabe de alguma maneira de reduzir isso?


Código: [Seleccione]
#include <OneWire.h>
#include <DallasTemperature.h>

#define ONE_WIRE_BUS 8 //ds18s20
#define data 2 //data 74hc164
#define clock 3 //clock 74hc164
#define set1 4 //7segment 1 l
#define set2 5 //7segment 2 c
#define set3 6 //7segment3  r4z5i

OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
DallasTemperature sensors(&oneWire); // Pass our oneWire reference to Dallas Temperature.

// bit por led
byte zero  = B01111110;
byte one   = B00000110;
byte two   = B11011010;
byte three = B11010110;
byte four  = B10100110;
byte five  = B11110100;
byte six   = B11111100;
byte seven = B01000110;
byte eight = B11111110;
byte nine  = B11110110;
byte space = B00000000;
byte h =     B10101110;
byte e =     B11111000;
byte l =     B00111000;
int a=0;
int b= 0;
int c;
byte digit[3];
//char tempo=0;
byte var;
char i;
void setup()
{

  sensors.begin();
  pinMode(clock, OUTPUT); //  clock pin  output
  pinMode(data , OUTPUT); // data pin  output3
  pinMode(set1, OUTPUT);
  pinMode(set2, OUTPUT);
  pinMode(set3, OUTPUT);
}

void loop()
{
  sensors.requestTemperatures(); // Send the command to get temperatures
  a=sensors.getTempCByIndex(0);
  for(i=0;i<100;i++){  //para ver o tempo
    rot(a);
  }
}



void rot (int a){
  c=a;

  digit[2] = c % 10;           
  digit[1] = (c / 10) % 10; 
  digit[0] = (c/ 100) % 10;
  for(byte d=0;d<3;d++){
    digit[d]=caso(digit[d]);
  }
  seg(digit[0],digit[1],digit[2]);
  //delay(1);
}

byte caso(byte test){
  switch (test){
  case 0:
    return zero;
    break;
  case 1:
    return one;
    break;
  case 2:
    return two;
    break;
  case 3:
    return three;
    break;
  case 4:
    return four;
    break;
  case 5:
    return five;
    break;
  case 6:
    return six;
    break;
  case 7:
    return seven;
    break;
  case 8:
    return eight;
    break;
  case 9:
    return nine;
    break;
  }
}
void seg(byte un,byte dos, byte tres){
  digitalWrite(set1,HIGH);
  digitalWrite(set2, LOW); //Primeiro Segmento
  digitalWrite(set3, LOW);
  shiftOut(data, clock, LSBFIRST, un);
  delay(6);
  digitalWrite(set1,LOW);
  digitalWrite(set2, HIGH); //Segundo segmeto
  digitalWrite(set3, LOW);
  shiftOut(data, clock, LSBFIRST, dos);
  delay(6);
  digitalWrite(set1,LOW);
  digitalWrite(set2, LOW); //terceiro segmento
  digitalWrite(set3, HIGH);
  shiftOut(data, clock, LSBFIRST, tres);
  delay(6);
  digitalWrite(set1,LOW);
  digitalWrite(set2, LOW); //se atrasar nenhum acende, e o inverso no que dará, ficara o valor antigo ?
  digitalWrite(set3, LOW);
}


Até ver está assim, ainda ando a testar, mas se alguem souber como reduzir o atraso do ds18s20 força.

Nota: Ainda não optimizei o codigo  ??? deve ter uma ou duas variáveis a mais ;) ou consumo desnecessário de sram, (char vs int).

Dicas são bem vindas :D

Offline FET_Destroyer

  • Mini Robot
  • *
  • Mensagens: 213
    • Fet Destroyer
Re: Delay OneWire Thermo
« Responder #1 em: 21 de Junho de 2010, 02:42 »
Boas
O protocolo 1-wire é feito por tempo, não sei as temporizações mas é do género, X us equivale a um comando, Y us equivale a outro, é provável que demore algum tempo para comunicar mas 1 segundo se calhar também é de mais.
Tenta ver o protocolo 1-wire.

Offline Sérgio_Sena

  • Administrator
  • Mini Robot
  • *****
  • Mensagens: 1.649
    • Electronic Gear for Musicians
Re: Delay OneWire Thermo
« Responder #2 em: 21 de Junho de 2010, 10:15 »
Se fores ver as especificações do chip termómetro, vais ver que a linha de dados tem que estar a 1, sem limitação de corrente, durante no mínimo 750ms. Este é o tempo que demora a aquisição e conversão.

Devido a ser um chip de baixo consumo, e q está pendurado numa linha onde só tem duas ligações: dados e massa, é natural que isto assim seja.
Tem a ver com o protocolo criado.

No entanto, depois deste tempo, obter o valor convertido é bastante rápido, é o tempo de envio de ROM e leitura dos dois bytes.


Offline bdesigns

  • Mini Robot
  • *
  • Mensagens: 38
  • Return 1
Re: Delay OneWire Thermo
« Responder #3 em: 21 de Junho de 2010, 16:42 »
Sim, eu percebo que existe esse atraso, afinal está lá mesmo expecificado na pagina inicial do pdf,
O problema é mais de hardware do que outra coisa, é que eu estou somente a utilizar um IC SiPo para 3 displays de 7 segmentos, ora quando para de percorrer a escolha de cada um deles, fica nenhum acesso, ou a ficarem todas ficam todos com o mesmo digito (ex:026->666);

A minha questão é se alguem tem algum truqe para manter a saida a correr a função seg(...)...
Por basicamente é isso que me tá a limitar agora a implementação ???
será que um do{....}while("qualquer coisa"); funcionaria..(a ideia era não parar o ciclo).

alguem tem ideias?

Senão tenho de me virar para sensores analogicos e a probabilidade de ruido.
« Última modificação: 21 de Junho de 2010, 16:59 por bdesigns »

Offline FET_Destroyer

  • Mini Robot
  • *
  • Mensagens: 213
    • Fet Destroyer
Re: Delay OneWire Thermo
« Responder #4 em: 21 de Junho de 2010, 16:53 »
Não estou a ver as duas coisas a funcionar ao mesmo tempo. Segundo o que está no datasheet o tempo máximo de conversão é de 750ms, mas são 750ms em que o processador fica preso nessa função de receber dados. Em arduino não sei se existem interrupções mas penso que não. Logo se ele fica preso nessa função a função de correr os 7segmentos não está activa logo vão lá aparecer coisas esquisitas ou nem sequer aparecer nada. Ele mostra-se sempre o mesmo digito, pois como fica preso na função de 1-wire não te vai fazer o varrimento dos leds. tenta por a ler o ds1820 de 2s em 2s, assim so te acontece isso de 2s em 2s.
« Última modificação: 21 de Junho de 2010, 16:55 por FET_Destroyer »

Offline Sérgio_Sena

  • Administrator
  • Mini Robot
  • *****
  • Mensagens: 1.649
    • Electronic Gear for Musicians
Re: Delay OneWire Thermo
« Responder #5 em: 21 de Junho de 2010, 17:08 »
Estão confusos vocês, e por má interpretação do datasheet.

Os 750ms são necessários para que o chip consiga fazer aquisição/conversão. APENAS isto. O micro não tem que prestar atenção ao que o chip faz. A única coisa que tem que fazer, é esperar o tempo mínimo. Até pode esperar 5seg... é indiferente.

E claro, depois do micro comunicar a ordem ao chip, põem o pino 1Wire a 1, e vão à vida.
Não vão ficar presos enqt o chip converte.
Afinal... ambos trabalham sózinhos, ou não? :)


Podem usar um temporizador por hardware, que gera uma interrupção, para vos dizer que acabou o tempo mínimo necessário.
Findo esse tempo, chamam a função de leitura do chip, e já está.

Se contarem o tempo que o micro está preso por causa do chip, é muito muito pouco. A comunicação é rápida mesmo assim. É um chip muito simples e fiavel. Aguenta-se bem em barramento com muitos juntos.

Offline bdesigns

  • Mini Robot
  • *
  • Mensagens: 38
  • Return 1
Re: Delay OneWire Thermo
« Responder #6 em: 21 de Junho de 2010, 19:18 »
Já percebi ;) Obrigado asena  ;D
a questão é que mesmo trabalhando com o millis(); fico com um pausa quase imperceptivel e outra grande.
Código: [Seleccione]
unsigned long currentMillis = millis();
  if(b==0){ 
    sensors.requestTemperatures();
    b=1;
    } /// Send the command to get temperatures //0.75s para obter
  }
 if(b==1){
   if(currentMillis- pretime > time){
    pretime = currentMillis;
    a=sensors.getTempCByIndex(0); //*enquanto não obter bloqueia.
    b=0;
  }
****
 
Inicialmente :
time=1000;
pretime=0;
b=0;
Acho que 1 segundo entre o pedido e a leitura chega?

mas mesmo assim :S pisca


...Tive a fazer um pouco de debug utilizando o led para me dizer que acção estava a demorar +, é o sensors.requestTemperatures();  hmm então a minha linha de pensamento não esta correcta.
« Última modificação: 21 de Junho de 2010, 19:39 por bdesigns »

Offline Sérgio_Sena

  • Administrator
  • Mini Robot
  • *****
  • Mensagens: 1.649
    • Electronic Gear for Musicians
Re: Delay OneWire Thermo
« Responder #7 em: 21 de Junho de 2010, 19:46 »
1seg é mais que sificiente.

Não esquecer de deixar o pino 1-wire no estado lógico 1, para fornecer a corrente necessária ao sensor.

Offline FET_Destroyer

  • Mini Robot
  • *
  • Mensagens: 213
    • Fet Destroyer
Re: Delay OneWire Thermo
« Responder #8 em: 21 de Junho de 2010, 20:35 »
Pois. Eu não conheço o protocolo 1-wire, tenho só uma ideia de como funciona e pela minha rapida passagem pelo datasshet pensei que ele demorasse 750ms a fazer a aquisição depois de ser mandado o pedido de dados, mas pelos vistos não.

Offline Sérgio_Sena

  • Administrator
  • Mini Robot
  • *****
  • Mensagens: 1.649
    • Electronic Gear for Musicians
Re: Delay OneWire Thermo
« Responder #9 em: 21 de Junho de 2010, 21:07 »
Sim, tens razão, demora minimo de 750ms na aquisição/conversão.

Offline FET_Destroyer

  • Mini Robot
  • *
  • Mensagens: 213
    • Fet Destroyer
Re: Delay OneWire Thermo
« Responder #10 em: 21 de Junho de 2010, 21:12 »
Sim, mas não da maneira que eu estava a pensar. Pensei que depois de ele ter recebido o pedido de dados, é que ia converter.

Offline Sérgio_Sena

  • Administrator
  • Mini Robot
  • *****
  • Mensagens: 1.649
    • Electronic Gear for Musicians
Re: Delay OneWire Thermo
« Responder #11 em: 21 de Junho de 2010, 21:25 »
Envias ::

# ROM
# ordem de conversão
-espera
# ROM
# pedido de dados

Isto porque podes emitir um broadcast, e todos os sensores fazem a aquisição ao mesmo tempo.
Depois do tempo passado, vais um-a-um pedir a informação.


Offline bdesigns

  • Mini Robot
  • *
  • Mensagens: 38
  • Return 1
Re: Delay OneWire Thermo
« Responder #12 em: 21 de Junho de 2010, 23:22 »
Ok, após andar aqui nas voltas (troquei para modo normal para ver se acelarava um pouco o processo), continuo com o mesmo problema.

Guardei o registo do endereço para obter só dados apartir deste, o problema persiste.
O problema situa-se no sensors.requestTemperatures(); por maior que aumente o tempo até este correr o tempo persiste.

Tive analizar a libraria  Dallas Temperature...
e aqui se encontra o porque do atraso, o codigo base que estava a utilizar (que obti no arduino playground)

Código: [Seleccione]
void DallasTemperature::requestTemperatures(void)
{
  _wire->reset();
  _wire->skip();
  _wire->write(STARTCONVO, parasite);

  switch (conversionDelay)
  {
    case TEMP_9_BIT:
      delay(94);
      break;
    case TEMP_10_BIT:
      delay(188);
      break;
    case TEMP_11_BIT:
      delay(375);
      break;
    case TEMP_12_BIT:
    default:
      delay(750);
      break;
  }
}

Então estou a tentar de outra maneira, mas sinceramente sinto-me perdi-do, como aínda não percebo muito bem os protocolos e a formato de comunicação do one wire, encontrei um codigo semelhante para teste do sensor, que me da todos os dados do sensor, agora o meu problema é obter e processar a temperatura :S
Código: [Seleccione]
{
  if(b==0){ 
    ds.reset();
    ds.select(addr);
    ds.write(0x44,1);         // start conversion, with parasite power on at the end
    b=1;
    } /// Send the command to get temperatures //0.75s para obter
 
 if(b==1){
   if(currentMillis- pretime > time){
    pretime = currentMillis;
    present = ds.reset();
    ds.select(addr);   
    ds.write(0xBE);         // Read Scratchpad

    for ( i = 0; i < 9; i++){ // we need 9 bytes
      data[i] = ds.read();
    }
   
//
// Parte da conversão que falta
//
  a=...; //a temperatura
   }
 }
   b=0;
   rot(a);
}

Mais uma vez agradeço ajuda, o que é certo é que se o display tive-se buffer podia "esquecer" este problema, mas neste caso, quero tentar dar-lhe a volta..


Mais uma vez agradeço ajuda ;)

Offline Sérgio_Sena

  • Administrator
  • Mini Robot
  • *****
  • Mensagens: 1.649
    • Electronic Gear for Musicians
Re: Delay OneWire Thermo
« Responder #13 em: 21 de Junho de 2010, 23:44 »
Mais uma vez agradeço ajuda, o que é certo é que se o display tive-se buffer podia "esquecer" este problema, mas neste caso, quero tentar dar-lhe a volta..

O que queres dizer com o display ter buffer? qual o sentido?

Os buffers podem ser criados no micro. O CPU é o micro, o resto são periféricos.

Offline Njay

  • Mini Robot
  • *
  • Mensagens: 3.598
    • Tróniquices
Re: Delay OneWire Thermo
« Responder #14 em: 21 de Junho de 2010, 23:53 »
O teu problema é facilimo de resolver. Só tens que partir o método requestTemperatures(void) em 2, mandar fora a 2ª parte,

Código: [Seleccione]
void DallasTemperature::requestTemperatures(void)
{
  _wire->reset();
  _wire->skip();
  _wire->write(STARTCONVO, parasite);
}

e ficares responsável por garantir que, depois de invocar este método, aguentas pelo menos o tempo necessário (ver o switch do método original) para a conversão terminar. Durante este tempo podes mostrar números no display, fazer contas, contar carneiros, o que quer que seja.

Aconselho-te ler com atenção este artigo aqui e começares a pensar e a estruturar os teus programas desta forma. Não é preciso ir mexer em interrupções.