GeoSounduino

[Ricardo]

Boas!

Obrigado a todos pelas criticas e pelas sugestões!

Antes de mais, devo avisar que fiz uma pequena correção no código, mas ainda não tive oportunidade de substituir no post inicial. Um erro entre a utilização do “o” e  do “w” para a direcção oeste, fazia com que a caixa se “passasse” de vez em quando. E só percebi  realmente qual era o problema quando verifiquei que isso que só acontecia sempre que eu virava num determinado sentido...

Entretanto cheguei  de férias mas como fiz muitos Kms por portugal  aproveitei para testar a caixa de forma intensiva, e só posso dizer que fiquei  completamente maravihado!  Não falhou uma única vez, e aguentou-se em viagens de várias horas sempre ligado.

Apenas o módulo de som parece meio baralhado, obrigando-me a chamar a faixa de áudio, não pelo número de ordem, mas... pelo dobro (2 para a faixa 1, 20 para a faixa 10, etc...), mas suspeito que também já teve melhores dias...

De resto, pouco mais vou fazer até dar o projecto por concluido (nesta fase), pelo menos a nivel de hardware.  Talvez coloque um botão ou dois para algumas tarefas paralelas, e estou a tentar “encaixar” uma pequena bateria de 7,2v para o tornar autónomo.

Quanto à questão do heading em baixas velocidades, já tinha colocado uma condição para só avaliar o sentido a partir de 1Km/h,  e aparentemente  tem sido suficiente.

Relembro que a  ideia inicial deste projecto é criar um equipamento simples e “barato” que servisse de alternativa aos complexos sistemas profissionais que existem no mercado. Uma especie de produto “low cost” para um mercado que, acreditem, tem algum potencial. Até o LCD seria dispensavel, pois o “cliente” só precisa mesmo de ter a certeza que uma determinada caixa vai “cuspir” o som certo num determinado ponto do percurso.

O  maior desafio neste momento é criar o “interface” mais simples possivel para o “programador” do itinerário poder, ele mesmo, programar a caixa com os pontos especificos, e com o som para cada ponto. 

Já alguém aqui criou alguma ferramenta que automatize a compilação e o upload de um skecth para o arduino, sem usar o IDE? Já fiz algumas experiencias, mas por enquanto ainda não tenho a solução final...

Quanto a outras ideias a aplicar, o facto de manter o outro tópico, e criar este novo, tem mesmo a ver com isso. Principalmente a questão do OBDII. Gostava de criar uma espécie da caixa negra, que de forma completamente autonoma, guarde toda a informação possivel de registar num veiculo. Mas isso fica para depois...

[senso]

Não seria mais facil enviar esses dados via serial, utilizando por exemplo um programa em C ou C++ ou C# ou java, ou python ou outra linguagem com um gui pipi e depois era só meter a caixa num modo de programação por assim dizer ligando um botão qualquer e guardava os dados novos, sem alterar nada no programa que já está no atmega, é que assim tens de dar o teu source code com o programa e assim qualquer um copia, pelo menos se for algo comercial são coisas meio contraditórias.

[TigPT]

Concordo com o senso. Recebes os dados dos pontos por serial e metes na eeprom para não haver problemas de perda de informação com falha de energia.

Quando à tua caixa negra.. é muito interessante e podes aproveitar coisas do opengauge e até contribuir:
http://code.google.com/p/opengauge/

[Ricardo]

Boas.

Essa ideia de criar uma função para carregar os dados via serial parece-me boa ideia, mas uma vez que me parece que a eeprom do arduino não "aguenta" com toda a informação necessária (40 pontos são 80 long int + 40 char), e como nunca experimentei usar eeprom "externas", tenho algum receio de não ter sequer "espaço" suficiente para essa alteração.

Mas que evitava uma série de problemas, isso concordo...

Vou ver mais sobre o assunto.

[senso]

Eu estou agora mesmo de volta de uma biblioteca feita por mim para usar eeproms da microchip e tenho andado a brincar com umas de 512K bits, ou seja 64Kbytes, penso que chega para guardar tudo o que precisas.
Será que não consegues ai optimizar o teu código em relação a variaveis?

[Ricardo]

Eu estou agora mesmo de volta de uma biblioteca feita por mim para usar eeproms da microchip e tenho andado a brincar com umas de 512K bits, ou seja 64Kbytes, penso que chega para guardar tudo o que precisas.
Será que não consegues ai optimizar o teu código em relação a variaveis?

Se em relação a algumas variáveis temporárias é mais que provável que tudo possa ser optimizado, já com a “dimensão” dos dados das coordenadas penso que é impossível fazer melhor. Se quiser ter alguma precisão nos pontos, um inteiro não chega. E entretanto já ignoro o sinal negativo da longitude pois assumo que em Portugal será sempre igual (constatação: Este produto não funciona em… Inglaterra!)

Pelo que percebi do tutorial do tr3s, são necessários apenas 2 pins do arduino para ler/escrever na eeprom, certo? E podem ser 2 pinos quaisquer (2 analogicos), certo?
Talvez isso não seja tão problemático assim…

Vou encomendar uns quantos chips da loja e fazer algumas experiências. 521K é mais que suficiente.

A biblioteca que estás a desenvolver é “volumosa”?

A leitura dos valores da eeprom pode ser feita em tempo real, ou deverei passar os valores quando inicializo, da eeprom para o arduino (flash)?

[ricardo-reis]

errado.. são os pinos 4 e 5 analógicos que são usados para a comunicação i2c..

[senso]

Penso que não, mas tenho tido pouco tempo para me meter de volta dela, basicamente ocupa o que ocupa a biblioteca 2wire, e podes ler e escrever na eeprom sempre que quiseres e em qualquer lugar do programa, como já foi dito é preciso os pinos analógico 4 e 5 pois a eeprom usa comunicação i2c/twi como a atmel lhe chama, queria era criar abstrações para guardar ints, longs e coisas assim fazem um simples longWrite e funções do género sem dar ao utilizador final o trabalho de contar bytes e o que tem de ir e onde está o que na eeprom.

[ngoncalves]

queria era criar abstrações para guardar ints, longs e coisas assim fazem um simples longWrite e funções do género sem dar ao utilizador final o trabalho de contar bytes e o que tem de ir e onde está o que na eeprom.

Tenho pouca experiência com o arduino mas acho que utiliza o compilador de C gnu-avr. Se sim, podes incluir no código:

Código: [Seleccione]

#include <inttypes.h> // cabeçalho standard que define inteiros com tamanhos fixos

uint8_t umByte ;
uint16_t doisBytes ;
uint32_t quatroBytes ;

// ler um byte. twi_read(): lê um byte da posição indicada no endereço. O Arduino deve ter uma função para isto, acho
twi_read(address) ;

// ler dois bytes (word)
uint16_t lowValue, highValue ;
   
highValue = (uint16_t)twi_read(address) ;
lowValue  = (uint16_t)twi_read(address + 1) ;
   
doisBytes =  ((highValue << 8) | lowValue) ;


[senso]

Eu sei como o fazer, falta é tempo para o fazer, estou agora na pausa para o lanche que breve é para ir trabalhar mais um bocadinho.

[Ricardo]

Chegaram hoje as I2C EEPROM - 256kbit que mandei vir da sparkfun, e já fiz uns testes com elas.
Com a ajuda do tuturial do tr3s, e com mais uns exemplos da net, já consegui "carregar" a eeprom com o conteudo do meu array 40x2 long), e depois ler esse conteudo em tempo real.

Agora vou ver a melhor forma de criar a rotina de "gravação" dos novos pontos e depois juntar tudo no mesmo código e ver o que acontece! 

[andre_f_carvalho]

crach

estou a brincar, so lhe falta um lcd a cores e com um mapa para mostrar o caminho

[senso]

Talvez usar uma estrutura de dados, assim é simples de usar os dados no programa e tambem de criar uma rotina simples para carregar os dados da eeprom para a estrutura e da estrutura para a eeprom.

[Ricardo]

Talvez usar uma estrutura de dados, assim é simples de usar os dados no programa e tambem de criar uma rotina simples para carregar os dados da eeprom para a estrutura e da estrutura para a eeprom.

Sim, estou cada vez mais perto dessa solução. Mas ainda tenho uma dúvida que ainda não consegui tirar:
Na solução actual, logo de inicio passo os dados para a flash de forma a libertar a ram.
Agora não sei se deverei fazer o mesmo, ou seja, ler a eeprom, passar para a flash, e libertar a ram.
É que Tenho a impressão que não será praticável correr a eprom a cada segundo à procura dos pontos.

[senso]

Podes ler as vezes que quiseres, mas é mais rapido ler a flash que ler a eeprom, a escrita é que tem ciclos limitados.