Como gravar na memória EEPROM os dados recolhidos pelos sensores? AJUDA SFF!!

Antes de mais quero agradecer por qualquer tipo de ajuda que me possam dar, estou apertado no prazo de um projeto de aquisição e memória de dados obtidos por 1 sensor LM35 e 1 DHT11.

No fundo necessito de registar a temperatura do LM35 e a temperatura e humidade do sensor DHT11, e guardar na memória EEPROM de maneira a poder posteriormente efetuar a leitura dos dados num só ficheiro.

O código que tenho até ao momento é o seguinte:

[code]#include <LiquidCrystal.h>
#include <dht11.h>

LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

int Temp, Humidity, hCheck, Temperatura;

#define tempPin 0
#define humidityPin 6

dht11 DHT11;

// initialise LCD library and pins
void setup() {
  Serial.begin(9600);
  lcd.begin(16, 2);
}

void loop()
{
  Temp = (5.0 * analogRead(tempPin) * 100.0) / 1024;
  delay(10);
  hCheck = DHT11.read(humidityPin);
  if(hCheck != 0)
    Humidity = 255; //Must be an error
  else
    Humidity = DHT11.humidity;
  delay(10);
  Temperatura = DHT11.temperature;
  
  showData(Temp, Humidity, Temperatura);
  Serial.print("Interior:");Serial.println(Temp);
  Serial.print("Humidade:");Serial.println(Humidity);
  Serial.print("Tampa:");Serial.println(Temperatura);
  delay(1000);
}

void showData (int Temp, int Humidity, int Temperatura)
{
  lcd.setCursor(0,0);
  lcd.print("TempINT=") + lcd.print(Temp) + lcd.print(char ( 0xdf)) + lcd.print("C");
  lcd.setCursor(0,1);
  lcd.print("EXT: H=") + lcd.print(Humidity) + lcd.print("%");
  lcd.setCursor(10,1);
  lcd.print("T=") + lcd.print(Temperatura) + lcd.print(char ( 0xdf)) + lcd.print("C");
}

[/code]

Produzi este código para proceder à leitura dos valores dos sensores que acoplei ao arduino, preciso então de os armazenar. A memória EEPROM a utilizar é a de origem do Arduino Leonardo.

Alguém me pode ajudar?

Código.txt (1.14 KB)

Luís, não entendi a pergunta. Para além disso também não entendi o código, porque não foi usada a tag "code" para o postar. Edite o seu post, seleccione o código e clique no botão da barra de ferramentas ' # '.
Não entendi a pergunta, porque não vejo nada relacionado com EEPROM. Também ajudava saber que tipo de EEPROM é se é a própria EEPROM do microcontrolador ou é alguma EEPROM externa.

Antes de mais muito obrigado e desculpe pela confusão, mas sou novo neste mundo.

No fundo só preciso de proceder ao armazenamento dos dados lidos, mas não sei como fazer. Li que a memória interna EEPROM possui capaz de armazenamento sem que sejam perdidos os dados, portanto pensei ser a melhor possibilidade. Estou errado?

Obrigado

Na memória EEPROM interna pode armazenar dados sem que eles sejam perdido quando o chip deixa de estar alimentado. No entanto, isso acrescenta uma série de problemas, por exemplo:

  • Qual é o Arduino (ou seja, qual é o tamanho da memória EEPROM)?
  • Durante quanto tempo têm que ser armazenados os dados?
  • Se os dados são guardados, também têm que ser lidos (se não, não vale a pena guarda-los). Como pensa tirar os dados da EEPROM?
  • Uma EEPROM, possui um número limite de ciclos de escrita. Sendo assim, convém que os dados não sejam constantemente escritos na mesma posição. Sendo assim, a forma mais fácil é usar a EEPROM é escrever sequencialmente nesta e usar um "ponteiro" que indique a posição em que deve ser escrito o próximo elemento, mas não convém que este esteja escrito nesta EEPROM, se não viola o princípio indicado anteriormente. Por isso deve arranjar-se um método para fazer isto.

O Arduino em questão é o Leonardo, portanto com a memória de 1kb.
Na verdade só preciso de fazer 48 medições, 1 para cada hora. Nunca serão feitas muitas medições visto isto ser só experimental, num desenvolvimento futuro será possivelmente acoplado um cartão SD.

O que me sugere luisilva?

Para começar, dar uma "olhadela" às funções de escrita e leitura da EEPROM:

Depois repensar o programa, uma vez que este apenas lê os sensores de segundo a segundo e não é feita nenhuma media, nem nada parecido para que sejam armazenados de hora a hora.

A memória EEPROM não é ideal para guardar dados... pricincipalmente por causa do tamanho.

Depois tens também de ter algum cuidado com a forma como guardas os dados. Ou seja, não será só gravar para lá, tens de saber quantos dados foram gravados, etc...

Nota que usar muito a EEPROM em ciclos de escrita/leitura pode danificar os dados guardados lá, logo ter um chuecksum não seria pior, mas só se encontrares problemas.

Este projecto, é académico? Se sim, a que nível?

bubulindo:
A memória EEPROM não é ideal para guardar dados... pricincipalmente por causa do tamanho.

Depois tens também de ter algum cuidado com a forma como guardas os dados. Ou seja, não será só gravar para lá, tens de saber quantos dados foram gravados, etc...

Nota que usar muito a EEPROM em ciclos de escrita/leitura pode danificar os dados guardados lá, logo ter um chuecksum não seria pior, mas só se encontrares problemas.

Este projecto, é académico? Se sim, a que nível?

É sim, faz parte do desenvolvimento de uma tese de mestrado em engenharia civil. O estudo era realizado através de um DataTaker DT505 que é de elevado custo, e eu adaptei para o arduino. Não altera o estudo científico que fiz, apenas estou a realizar este estudo como parte dos desenvolvimentos futuros, para provar que dá para fazer a leitura de uma maneira relativamente barata e não usar aparelhos de 3mil euros.

Então isso é mais um incentivo a fazer isto bem feito.
Já agora, e sabendo qual é e área (e mais ou menos a aplicação) não era de mais se tivesse também a data/hora da leitura. Existem muitos RTC's prontos para serem usados com o Arduino e trazem outro tipo de vantagens como por exemplo o armazenamento de dados em memória SRAM "protegida" por bateria. Isto serve para ultrapassar o constrangimento de que falei antes.
Para descarregar os dados pode usar a porta série, usando um comando qualquer, ou então, premindo uma tecla para começar a descarga (mas uma vez que a porta série deve estar pronta para receber os dados, talvez a ideia do comando seja melhor).

Outra forma seria enviar os dados para um cartao SD com a leitura , data, e hora.
Se guardares isso num ficheiro csv( Comma-separated values) depois podes abrir no excel e ate desenhar um gráfico por exemplo com os dados obtidos.
Em termos de hardware necessitas de ligar o cartao SD ao interface SPI e o RTC via I2C.

Eu acho que o HugoPT tem razão. Compensa mais, usar o cartão SD e um ficheiro "Excel", porque se poupa bastante na programação da "descarga de dados". Para quem não tem experiência talvez seja a opção mais rápida e fácil de implementar..

Adicionar o RTC é bastante interessante... As memórias do RTC não servem para guardar muita coisa. Principalmente neste tipo de aplicação.

Como referiu o Hugo, acho que a melhor coisa a fazer será mesmo mandar os dados para um SD em vez da EEPROM. No entanto, e tendo já feito um projecto semelhante para civil, muitas vezes o que interessa é recolher os dados e não necessariamente fazê-lo da maneira mais correcta tecnicamente.
É esse o caso aqui? Ou queres projectar um instrumento?

A parte boa dos fóruns é que cada um começa a "lançar achas para a fogueira" e acabam por surgir novas ideias (que podem ou não ser interessantes). Como não sei qual é a razão pela qual se têm que gravar valores só de hora a hora, o que eu digo é que se podem gravar num ficheiro csv dum cartão SD valores de minuto a minuto, ou mesmo de segundo a segundo e fazer os cálculos (médias, modas, medianas, o que quer que seja) no próprio Excel. Qual é a vantagem? Talvez se tenha muito mais informação tendo todos os dados, que apenas os valores horários (uma média sem um desvio padrão, não vale grande coisa). Por exemplo uma média horária não "mostra" uma descida ou subida brusca de temperatura (e imagino que para esta aplicação em particular isso até seja importante).

Depende da aplicação... O Mundo da Engenharia Civil mexe bem devagar. LOL

Na aplicação que eu fiz, a experiência demorava mais de um dia... Apenas conseguimos cerca de 10 horas de dados porque o betão partiu os sensores de temperatura (embutimos sensores de temperatura dentro de betão). Na altura não me lembra da frequência de aquisição, mas como tinha feito um programinha para guardar aquilo num ficheiro de texto a correr num portátil, não havia problemas em ter dados a mais.

Neste caso, a escolha de valores de hora a hora pode ser devido à limitação da EEPROM, talvez? Acho que só sabendo ao certo qual a aplicação é que poderemos dar mais dicas...

Antes de mais queria agradecer a todos as respostas rápidas, e a enorme ajuda.
O projecto consiste na leitura da temperatura da temperatura do betão na fase de endurecimento (LM35) e das condições atmosféricas como humidade e temperatura (DHT11) durante 48 horas.
Quanto mais informação existir melhor, mas por saber que a memória EEPROM é limitada, achei que 48 medições chegariam. Eu já tinha comprado um adaptador para leitura de cartão SD, mas não cheguei a conectar por necessitar do ecrã LCD 16x2 para visualização a tempo real da temperatura, como podem ver no código que publiquei.
A acoplação do cartão SD em combinação com o ecrã LCD é simples? e a programação do arduino para gravar os dados no cartão SD onde posso encontrar? Peço desculpa pela ignorância, mas realmente a Eng. Civil não é muito evoluida em termos informáticos e eletrotecnicos.

Muito obrigado mais uma vez.

Este é um exemplo da utilização do cartão SD, guardando num ficheiro de texto deste os valores das leituras de 3 "sensores":

Cuidado que eles estão a usar os pinos:
** MOSI - pin 11
** MISO - pin 12
** CLK - pin 13
** CS - pin 4

para o cartão SD. Como a sua placa é o Arduino Leonardo, isto penso que não é bem assim - veja aqui. Não consigo ajudar muito mais, porque não tenho nenhuma placa dessas, no entanto, pela minha leitura deste último link, não precisa de se preocupar com o LCD, uma vez que nessa placa o barramento SPI, para comunicar com o cartão SD não está nos pinos que indicados antes, mas no header identificado com as letras ICSP da sua placa.

Seno assim, vai precisar de:
4 pinos para o cartão SD; (noutro header, portanto não contabilizado aqui)
6 pinos para o LCD;
1 pino para o LM35;
1 pino para o DHT11;
dá um total de 8 pinos. Como o Arduino Leonardo tem um total de 20 pinos para I/O, ainda lhe sobram muitos I/O's para adicionar outras coisas, como por exemplo o tal RTC que se falou antes.

Um exemplo:

outro:

e ainda outro:
http://www.ebay.co.uk/itm/MODULO-RELOJ-ARDUINO-TIEMPO-REAL-DS1307-BATERIA-Lir2032-I2C-RTC-AT24C32-AVR-/221486888079?pt=LH_DefaultDomain_186&hash=item3391a5b48f

se tiveres 1024 bytes de memória, e atendendo ao facto que precisas de dois bytes para guardares o numero de dados guardados, isso dá-te espaço para 1022 bytes de dados.

Se guardares tudo em integers (como estás a fazer de momento), ficas com:

1022/(2 bytes (temperatura) + 2 bytes (humidade) + 2 bytes (temperatura exterior)) = 170

Ou seja, podes tirar 170 amostras. No espaço de 48 horas dá 2880 minutos. Dividindo por 170, dá 16.9 minutos por amostragem.
Concluindo, se tirares uma amostra a cada 17 minutos enches a EEPROM e ficas com mais dados guardados.

Relativamente ao cartão SD, nunca usei no Arduino, mas creio ser fácil se as ligações estiverem bem feitas. No entanto, convém ter algum cuidado e poupar o número de escritas no cartão para prolongar a vida do mesmo.

Existem exemplos para usar o cartão SD na IDE do Arduino.

O outro problema da EEPROM é que tens de fazer o programa de forma a não apagar a EEPROM e também de forma a que, quando quiseres, ele te possa enviar os dados de volta ao computador.

Diz-me uma coisa, como vais embeber o LM35 no betão? Isto porque o projecto em que participei, acabou por não dar muitos dados devido ao betão quebrar os sensores (DS18B20). Na altura o que fiz foi uma camara adiabática para testar betão também.

Em relação à última questão levantada pelo bubulinudo, e se for uma coisa assim:

será que também dará problemas?

Isto é um projecto académico, por isso acredito que as amostras possam se acondicionadas correctamente para que o sensor não parta, seja colocando-o dentro de um tubo VD, seja acondicionando-o dentro da armadura, certo?

Em relação ao resto, reconheço que o raciocínio está muito bem estruturado, no entanto, não concordo com os valores. Por exemplo, a humidade (humidade relativa do ar) mede-se em percentagem (em valores de 0 a 100%) e o DHT11 tem uma resolução de 1%. Sendo assim, apenas um byte é suficiente para guardar este valor. O mesmo para a temperatura do ar (também apenas resolução de 1ºC), variando numa escala que depende da altura do ano, mas não deverá chegar a uma amplitude de 20ºC. No entanto se se quiser guardar o valor "inteiro" da temperatura, deverá olhar-se para o valor máximo que se vai ler, e sendo assim, pode-mo-nos preparar para medir valores entre 0 e 45ºC. Portanto um byte também é mais que suficiente. Para a temperatura dada pelo LM35, aí sim, se calhar se podem "guardar mais bytes". Podemos dizer que é um valor entre 0 e 45º, à mesma, mas com uma resolução de 0,1ºC. Sendo assim, e guardando os valores em décimas de grau, para não guardar o "float", terão que se guardar valores entre 0 e 450, isto é, 2 bytes chegam e sobram.

1022/4=255 amostras
2880/255 = 11,29 minutos por amostra

Isto é, fazendo uma medição cada 15 min. iriam fazer-se 192 medições que ocupariam 768 bytes da memória EEPROM.

Utilizando o cartão SD e fazendo amostragens de segundo a segundo, teria-se um ficheiro com menos de 20MB. (neste caso as contas são ligeiramente diferentes porque têm que se contar os caracteres e não o valor armazenado na memória) Mas este valor serve para ilustrar que um pequeno cartão de memória serve perfeitamente para este fim.

Não estamos a considerar a data/hora. Para o caso do cartão SD, o valor talvez triplique ou quadruplique, mas para o caso da EEPROM, tinha que se pensar muito bem como guardar esse valor para que não se guardasse informação desnecessária.

As minhas contas foram baseadas no código apresentado... Mas sim, um byte chega, efectivamente duplicando o espaço de armazenamento.

bubulindo:
se tiveres 1024 bytes de memória, e atendendo ao facto que precisas de dois bytes para guardares o numero de dados guardados, isso dá-te espaço para 1022 bytes de dados.

Se guardares tudo em integers (como estás a fazer de momento), ficas com:

1022/(2 bytes (temperatura) + 2 bytes (humidade) + 2 bytes (temperatura exterior)) = 170

Ou seja, podes tirar 170 amostras. No espaço de 48 horas dá 2880 minutos. Dividindo por 170, dá 16.9 minutos por amostragem.
Concluindo, se tirares uma amostra a cada 17 minutos enches a EEPROM e ficas com mais dados guardados.

Relativamente ao cartão SD, nunca usei no Arduino, mas creio ser fácil se as ligações estiverem bem feitas. No entanto, convém ter algum cuidado e poupar o número de escritas no cartão para prolongar a vida do mesmo.

Existem exemplos para usar o cartão SD na IDE do Arduino.

O outro problema da EEPROM é que tens de fazer o programa de forma a não apagar a EEPROM e também de forma a que, quando quiseres, ele te possa enviar os dados de volta ao computador.

Diz-me uma coisa, como vais embeber o LM35 no betão? Isto porque o projecto em que participei, acabou por não dar muitos dados devido ao betão quebrar os sensores (DS18B20). Na altura o que fiz foi uma camara adiabática para testar betão também.

O molde que eu desenvolvi tem encastrado o termómetro na base isolado por uma fina camada de um componente que não é afetado pela reação química do processo de hidratação. Idealmente deveria ser colocado o termómetro/termopar no centro do provete, mas devido ao facto de não poder ser utilizado outra vez, afectar a leitura dos ensaios à compressão não foi adoptado.
Vou então tentar acoplar o cartão SD para poder reunir as informações num ficheiro de texto, e poder fazer o registo de minuto a minuto.
Ao meu projeto não interessa os valores máximo e mínimo, mas a curva de variação da temperatura, é isso que estou a estudar.

Obrigado a todos pela ajuda, vou tentar desenvolver isto!

Cumprimentos