Página 1 de 1
Estrutura de dados para datalogger

Enviado:
30 Out 2010 12:12
por jonowsky
Tenho a seguinte dúvida, preciso fazer um datalogger, armazenar por exemplo, temperatura, umidade, velocidade do vento, data, hora, etc...
Eu poderia criar uma estrutura com esses dados, e de tempos em tempos armazenar em ordem em um arquivo texto, e na proxima coleta armazenar na seuquencia... ai quando eu for ler, sei qual a sequência e tamanho de minha estrutura, assim posso recuperar estes dados...
Mas e se eu quiser adicionar um novo dado ao datalogger depois? o tamanho da estrutura irá se alterar, se eu ler um arquivo antigo bagunça tudo...
Minha pergunta é, qual seria a melhor maneira de armazenar estes dados, para que no futuro eu posso alterar a quantidade de dados coletados e não ter dor de cabeça... pensei em caracteres delimitadores no incio e fim de cada dado, mas e se der o azar de um dado ter o mesmo valor do meu delimitador??
Valeu

Enviado:
30 Out 2010 12:49
por Djalma Toledo Rodrigues
Talvez, como ja coloquei aqui no Fórum, uma boa prática é colocar no Primeiro Byte,
ou Word, o comprimento, quantos bytes ocupa
Vale o mesmo para Tabelas
pensei em caracteres delimitadores no incio e fim de cada dado, mas e se der o azar de um dado ter o mesmo valor do meu delimitador??
Neste segundo caso como o Arquivo é em texto, isto é , em ASCII, existem os Caracteres não imprimiveis , de contrôle
Ver :
http://pt.wikipedia.org/wiki/ASCII
DJ

Enviado:
30 Out 2010 12:54
por jonowsky
Djalma Toledo Rodrigues escreveu:Talvez, como ja coloquei aqui no Fórum, uma boa prática é colocar no Primeiro Byte,
ou Word, o comprimento, quantos bytes ocupa
Vale o mesmo para Tabelas
DJ
Boa DJ, já tinha lido essa sua sugestão no tópico anterior, só não tinha associado ao meu problema

é uma boa solução!
obrigado

Enviado:
30 Out 2010 13:05
por Djalma Toledo Rodrigues
releia que foi editado e ampliado
DJ

Enviado:
30 Out 2010 13:11
por jonowsky
Djalma Toledo Rodrigues escreveu:releia que foi editado e ampliado
DJ
Entendi a questão dos caracteres não imprimiveis, mas digamos que meu delimitador seja um caractere não imprimivel... nada impede de meu dado ser este mesmo valor.. ai lascou... Ou não entendi direito?

Enviado:
30 Out 2010 15:53
por guest2003
Acho que nao entendeu direito Jonowsky...
Tudo que voce vai guardar la vai ser ASCII (exceto os delimitadores ou ate eles)
Veio 244 numa variavel char sua qquer... isso sera guardado como sendo 0x32 0x34 0x34 ( 2 4 4 em ASCII )
Como ja deve ter percebido o negocio vai ocupar mais espaco.
Outra forma de fazer seria criar um header, e no header voce colocaria a quantidade de parametros e o tamanho deles... com isso ficaria flexivel no futuro.
[]'s

Enviado:
30 Out 2010 15:56
por jonowsky
guest2003 escreveu:Acho que nao entendeu direito Jonowsky...
Tudo que voce vai guardar la vai ser ASCII (exceto os delimitadores ou ate eles)
Veio 244 numa variavel char sua qquer... isso sera guardado como sendo 0x32 0x34 0x34 ( 2 4 4 em ASCII )
Como ja deve ter percebido o negocio vai ocupar mais espaco.
Outra forma de fazer seria criar um header, e no header voce colocaria a quantidade de parametros e o tamanho deles... com isso ficaria flexivel no futuro.
[]'s
hummm
Agora saquei!
é, e num datalogger cada byte que você consegue economizar eh lucro, pois serão aquisições de 1 em 1 segundo ~12h/dia

Enviado:
30 Out 2010 16:34
por MOR_AL
guest2003 escreveu:... Outra forma de fazer seria criar um header, e no header voce colocaria a quantidade de parametros e o tamanho deles... com isso ficaria flexivel no futuro.
[]'s
Essa opção é muito boa, Guest2003.
Não sei se é o caso do Jonowsky. No meu caso eu uso arquivos com parâmetro binário (uso o VB). Com outros tipos de arquivos é necessário ler o arquivo desde o início, para acessar o enésimo dado. Não sei se isso ocorre com outras linguagens. Se o arquivo for grande, começa a ficar lento para lê-lo, caso a leitura não acesse dados consecutivos.
MOR_AL

Enviado:
30 Out 2010 19:03
por Red Neck Guy
O preço que se paga por um pouco de generalismo é um pequeno overhead. Colocando-se um byte no inicio das estruturas para controle pode-se ler o bloco de memória com base no tamanho da estrutura. Porém, quando se tem blocos com tamanhos diferentes numa fila de eventos que é logada em memória externa e essa é uma fila circular, haverá problemas quando a fila começar a sobreescrever o inicio onde os tamanhos são diferentes. A solução para esse problema é um gerenciador para essa memória, que lida com esse problema. Não é dificil implementar, porém, há o overhead.
Nas centrais de incêndio que eu projetei eu já fiz de várias maneiras: Fiz os blocos de log com o tamanho do maior log e coloquei um byte no inicio para ver em qual estrutura eu jogo os dados quando ler da memória, já fiz com gerenciador externo emulando malloc e free para o banco de dataflash, e recentemente fiz uma onde coloco os blocos jogados na eeprom e na estrutura fico com uma lista para os ponteiros onde estão os eventos, mas, isso pq nessa central nova os eventos podem ter o tamanho variado pois o operador pode digitar um texto que pode ter até 8 0 caracteres para cara ocorrência.

Enviado:
30 Out 2010 19:34
por rcakto
bom, iria dividir cada campo da tabela em arquivos separados contendo o dia e a hora, no PC eu iria fazer o trabalho de unir tudo em uma unica tabela... agora eu recomendo mesmo é salvar tudo em um arquivo, caso seja adcionado um novo campo, não tera problema, pois se houver alguma "atualização" os dados anteriores ja não deverão ser de importancia pois os novos dados estarão mais completos, os antigos so deverao ser guardados para futuras referencias ou necessidades....

Enviado:
31 Out 2010 11:35
por Red Neck Guy
rcakto escreveu:bom, iria dividir cada campo da tabela em arquivos separados contendo o dia e a hora, no PC eu iria fazer o trabalho de unir tudo em uma unica tabela... agora eu recomendo mesmo é salvar tudo em um arquivo, caso seja adcionado um novo campo, não tera problema, pois se houver alguma "atualização" os dados anteriores ja não deverão ser de importancia pois os novos dados estarão mais completos, os antigos so deverao ser guardados para futuras referencias ou necessidades....
Explica melhor, pq não deu pra entender o que tu queres fazer.

Enviado:
31 Out 2010 11:53
por rcakto
tenho uma tabela com 5 campos, cada campo irei salvar em um arquivo separado com a data e hora, depois no PC irei unir os dados dos 5 arquivos em um unico como um DB, assim quando precisar de colocar um novo campo não terei problema, pois como os dados antigos irão faltar esse novo campo, simplesmente guardo eles se preciser caso precise deles no futuro e de agora em diante o novo DB tera todos os campos que estou trabalhando agora... o problema disso é que pode vir a ocupar muito espaco dependendo do tempo entre as gravações de dados... es.: salvando todos os dados dos sensores a cada 0,1s..... vai ficar pesado pra burro a memoria... nesse caso seria melhor enviar os dados diretamente a um pc e o programa no pc ja vai adcionando os dados em um DB como mysql...

Enviado:
31 Out 2010 12:25
por Red Neck Guy
rcakto escreveu:tenho uma tabela com 5 campos, cada campo irei salvar em um arquivo separado com a data e hora, depois no PC irei unir os dados dos 5 arquivos em um unico como um DB, assim quando precisar de colocar um novo campo não terei problema, pois como os dados antigos irão faltar esse novo campo, simplesmente guardo eles se preciser caso precise deles no futuro e de agora em diante o novo DB tera todos os campos que estou trabalhando agora... o problema disso é que pode vir a ocupar muito espaco dependendo do tempo entre as gravações de dados... es.: salvando todos os dados dos sensores a cada 0,1s..... vai ficar pesado pra burro a memoria... nesse caso seria melhor enviar os dados diretamente a um pc e o programa no pc ja vai adcionando os dados em um DB como mysql...
O problema aqui é otimização na hora de salvar na memória que está no módulo embarcado não no PC....