Estrutura de dados para datalogger

[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

[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

[jonowsky]

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

[Djalma Toledo Rodrigues]

releia que foi editado e ampliado

DJ

[jonowsky]

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?

[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

[jonowsky]

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

[MOR_AL]

... 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

[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.

[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....

[Red Neck Guy]

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.

[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...

[Red Neck Guy]

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....