Boa tarde pessoal,

Alguém conhece alguma lib para banco de dados que crie os "archives" de dados no SD?

A maioria utiliza o EEPROM, que é limitado em tamanho e ciclos de gravação.

Exibições: 4763

Responder esta

Respostas a este tópico

Opa Geovani,

acho que é isso oq vc está procurando.

http://arduino.cc/en/Tutorial/Datalogger

Abraços.

Bom dia Guilherme,

Na verdade, não quero manipular arquivos texto diretamente. É bem mais simples e resolve a maioria dos problemas, mas queria algo mais robusto, tipo um banco de dados.

Estava pensando em um porte do SQLite. O que vc acha?

Olá Geovani.

 

Infelizmente não conheço muito sobre o SQLite, mas creio que compreendi onde quer chegar. 

Pelo que pesquisei não encontrei nenhuma biblioteca que crie os "archives" de dados no SD, que provavelmente você deseja que esteja no formato dos "database files" nativos do SQLite.

Como você citou o porte do SQLite, isso demandaria a criação de uma biblioteca (library) nova para o Arduino.

Nesse primeiro momento não encontrei uma biblioteca comum em C do SQLite para nos basearmos no porte para o Arduino. O que mais se encontra são códigos em C que geram scripts para o banco de dados.

Tem algo que poderia ajudar nesta tarefa, que é estudar a estrutura dos arquivos utilizados pelo database.

Segue o link:

                    http://www.sqlite.org/fileformat.html

Com isto conseguiriamos criar arquivos já no formato do SQLite.  Mas o interessante mesmo é criar-se funções que se comportassem como uma API ou Interface para tais arquivos. 

Dependendo se é isto o que procurava, e se alguém da comunidade se disponibilizar, podemos conversar sobre a criação desta biblioteca (library) para este banco de dados.

Poderia ser baseada no SQLite, mas se houver alguma outra tecnologia mais "acessível", nem que seja para trabalhar com "bancos" usando os arquivos textos que já estão disponíveis, podemos pensar na estrutura e implementação deste projeto, que acho bem interessante e valoroso para a comunidade.

Espero ter ajudado. 

Att.

Boa tarde Daniel, obrigado pela resposta.

O SQLite, por mais compacto que seja, implementa tantas coisas que acho quase inviável um porte consistente em menos de 100kb. No caso do Arduino Mega, tudo bem, mas o Uno não desfrutaria desse recurso.

Estava pensando e me ocorreu: E se não houver SQL? E se fosse implementado um banco de dados não relacional, como documento (CouchDB, MongoDB), Chave-valor (redis, memcached) ou de grafo (Neo4J)?

Estava pensando num modelo Chave-Valor, como uma estrutura JSON, com tipagem flexível (que pudesse suportar qualquer tipo de dado), reentrante, schemaless, onde os dados pudessem ser armazenados no EEPROM ou SD, em archives binários ou texto, com indexação para acelerar as buscas por critérios, baixo footprint de memória.

Nesse caso, as estruturas básicas seriam:

- um conjunto de funções (API) consistente e flúida para manipulação dos dados;

- struct manipulando as chaves/valores;

- algoritmos de indexação (apenas os índices permanecem em memória durante uma busca/manipulação);

- algoritmo para evitar duplicidade de chaves;

- opção de armazenamento TXT / Bin;

- opção de armazenamento EEPROM / SD;

- backup/restore via Ethernet? (Ok, isso é sonho)

- clusterização com outros arduinos via I²C / SPI? (OK, outro sonho... kkk)

Qual o grau de complexidade disso?

Olá Geovani.

Realmente no sistema com pouca memória teríamos que pensar em algo otimizado, especialmente na indexação e manipulação de chaves/valores.

Dei uma olhada nas tecnologias que citou. E a que mais se aproximou de algo em que estava pensando com o arquivo txt/bin é o da estrutura do JSON, que lembra bastante um XML.

Estou acostumado a programar escovando bits em assembler. Posso ajudar a pensar em algo no formato JSON mas usando pouquíssimos bytes para a manipulação da estrutura.

É um projeto de médio a grande porte pelo que observo. 

Médio no primeiro momento, em que estamos discutindo a estrutura, formatos, e periféricos de armazenamento, e implementação da API de manipulação, busca, etc..

E grande quando isto se tornar uma necessidade/utilizade para a comunidade. Dai virão as exigências naturais, como o suporte para backup/restore, protocolos de comunicação eth/I2C/SPI/Uart... só que neste ponto pode ser que mais pessoas da comunidade estejam contribuindo.

"E os sonhos se tornarão realidade." rsrs

Você tem conhecimento em desenvolvimento compartilhado? Poderiamos já pensar em algo para mais pessoas poderem contribuir com esta biblioteca.

Está ficando mais interessante esta idéia. Vamos ver no que vai dar. ^^

Att.

Isso parece consistente?

 

DataStore store(STORE_IN_SD | STORE_BINARY_ARCHIVES);
store.collection("table")
.onKey("key1").setValue("value")
.deleteKey("key2");
int res1 = store.collection("table")
.whereKey("key1")
.asArray()
.hasValue(5)
.getIntOrDefault();
char * res2 = store.collection("table")
.first()
.getStringOrDefault();

getInt();
getFloat();
getString();
getBoolean();
getDateTime();

getIntOrDefault();
getFloatOrDefault();
getStringOrDefault();
getDateTimeOrDefault();

 

 

Sim, já é um conjunto interessante de funções.

Como não conheço algo parecido, me explique por favor:

1) O que o "int res1" recebe, e o que "char *res2" recebe? Me parece que res1 recebe um valor TRUE ( != 0) ou FALSE (==0). E res2 recebe o endereço de onde está uma 

string.

2) Qual é a diferença entre um getInt() para o getIntOrDefault() ? A primeira poderia retornar um código de erro caso o dado não seja int?

Os métodos parecem bons. Você se baseou em algo que já utiliza estes métodos? Por acaso é o JSON?

Estou pensando agora é no formato de leitura e armazenamento no cartão SD ou EEPROM. Praticamente o que conheço é que os dados seriam "serializados", mesmo que tenham seu cabeçalho padrão.

Então poderíamos definir uma estrutura fixa para facilitar. Por exemplo, 2 bytes para a chave primária, o que daria 2^16 itens máximos em um arquivo. Tags de 1 ou 2 bytes para definir o tipo de variável ou campo, dai já saberiamos a quantidade de bytes sequentes e configurações diversas. Ou mais campos para lista ligada e endereços, relativos ou não.

Vou ver a forma de manipulação para o cartão SD e EEPROM, pois isto pode realmente limitar as coisas para tornar o funcionamento otimizado.

Boa tarde Daniel! Essa conversa está rendendo hein?! kkk

Sim, baseei essa "API" na experiência que tenho com API's fluentes de alto nível, principalmente em C++ / C#.

Imagine "int res1" e "char* res2" como variáveis com os dados que você precisa em um algoritmo. A API fluente configura uma série de parâmetros para indexação e leitura dos "archives". Acho que fica melhor assim, sem ponteiros, 5 métodos pra buscar um valor...

Trabalho com JSON há um bom tempo e foi justamente nesse tipo de estrutura flexível que estava pensando. :D

O termo "OrDefault()" serve para indicar uma verificação extra de segurança. Por exemplo, se você chama getInt() ele pode retornar um inteiro ou nulo, no caso da chave (ou uma chave anterior) não existir. Se usar o "OrDefault()" o resultado pode ser 0 ou -1, garantindo que o algoritmo possa continuar sem falha. Essa é uma característica das interfaces fluentes: resiliência.

No caso do armazenamento, talvez criar um objeto de "storage" para isolar e abstrair a forma como os dados são gravados, pois no caso do EEPROM, é uma matriz que precisa ser escrita byte-a-byte e já no caso do SD, temos um filesystem e arquivos (inclusive com pastas! rs).

A serialização seria perfeita, contanto que os índices consigam organizar e manter tudo consistente.

 Está rendendo sim, e discutindo os features, constrains e outros antes de colocar a mão na massa realmente ajuda bastante no desenvolvimento. Nestas horas é que recordo do livro "Code Complete" do Steve McConnell. rs

 Entendi o tipo de retorno dos métodos, como não estou familiarizado poderia entender errado. Valeu pela resposta.

 

 Quanto ao arquivos/cartão/eeprom, vejo que ainda pretende manter a estrutura do filesystem. Sei que era a premissa, mas já estava pensando que na discussão da criação da biblioteca estariamos vendo a possibilidade de criar algo fechado apenas ao Arduino e seus shields com SD. Por isso estava pensando nas otimizações e talvez criar um formato novo.

 Então manteriamos a estrutura do JSON, usando o filesystem para o cartão, mas com os métodos( aqueles citados) feitos para o Arduino ?

Vejo que tem bastante conhecimento em alto nível. Estou pensando em que eu contribuiria em 8 bits.rsrs Brincadeira. Só não sou tão fluente em alto nível, mas já trabalhei com C++ e C#, compreendo O.O. e algo de RTOS, e trago um pouco destes conceitos para o C e Assembly, fazendo um baixo nível mais legível. ^^

Então, vai mesmo querer colocar a mão na massa nesta idéia? =)

Boa tarde Daniel!

Manter a estrutura de filesystem, não é uma premissa. Eu acho que seria interessante fazer o "core" (estruturas, indexação, busca) em C++Std (com possibilidade de mudar para algoritmos de alta performance), enquanto os mecanismos de storage podem ser específicos para cada plataforma. No Arduino temos SD, EEPROM, etc. Em sistemas operacionais tradicionais e Raspberry's da vida, temos filesystem.

Dessa forma, acho que a premissa principal seria "o menor banco de dados não relacional escrito em C do mundo"... rs

Acho muito legal que vc entenda de "escovar bits", pq sinceramente, até hoje apanho pra fazer bit-shift ou aritmética hexadecimal... kkk

Gostaria de investir um pouco no estudo e desenvolvimento de uma lib de banco de dados decente pra microcontroladores e sistemas embarcados... :)

O que você acha de abrirmos um repo no github pro projeto?

Bom dia Flavio,

Conheço essa lib, e o fato de só usar a EEPROM é que me incomoda. O problema da EEPROM é que, se estiver pensando em fazer um "data logger" de longo prazo, poucos dados serão armazenados e por pouco tempo.

Além disso a API da lib pode não ser tão intuitiva ou fluida como gostaria.

Abraço!

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço