LusoRobótica - Robótica em Português
Sistemas específicos => Arduino / AVR => Tópico iniciado por: Ricardo em 06 de Agosto de 2010, 16:07
-
Bom dia.
Este tópico pode ser considerado um “spinoff” do Arduino áudio gps http://lusorobotica.com/index.php?topic=2293.0 (http://lusorobotica.com/index.php?topic=2293.0)
Resolvi criar um novo por duas razões:
1º- Finalmente arranjei um nome para baptizar o projecto: GeoSounduino. 8)
2º - O projecto inicial sofreu algumas alterações, não tanto no conceito, mas mais na apresentação/materiais utilizados.
Ainda assim, a ideia mantém-se a mesma: Criar um equipamento autónomo que utilizando a localização GPS, e depois de programado com pontos predefinidos, responde com conteúdos áudio específicos para cada um desses pontos.
Depois de alguns protótipos, e de vários “road-test”, cheguei a um produto semi-finalizado, estando numa fase de criação de uma aplicação VB para criar e gerir os itinerários.
As grandes diferenças para o protótipo original estão na utilização de um módulo gps da libelium (em vez da demoboard original, que embora respondesse bem, é demasiado grande e, parece-me, muito exigente ao nível da corrente). Outra grande diferença é que ao invés de utilizar um atmega328, optei por colocar um arduino nano, mas pretendo voltar ao 328 assim que terminar a optimização do código.
Para isso também irá contribuir (espero) a criação de uma pcb personalizada que irei tentar por em pratica assim que chegarem os produtos da venda colectiva! A seguir, entra em produção em série! ;D
O módulo de som é o mesmo, o LCD é vermelho em vez de azul, e as entradas e saídas têm mais ou menos a mesma filosofia.
Um dos maiores desafios dos últimos dias tem sido a optimização do código de forma a trabalhar com muitos pontos (40) utilizando também a direcção (heading) como variável para escolha do som (ex: se for para norte no ponto A passa o som 1, se for para sul no mesmo ponto, passa o som 2).
Uma das coisas que experimentei, embora ainda não tenha grande certeza da vantagem, foi colocar os pontos na memória flash (progmem) de modo a libertar a ram, pois pareceu-me que a certa altura o comportamento da caixa começava a ficar muito estranho, reiniciando sozinha ou apresentado caracteres esquisitos no lcd…
Calculei que estivesse a exigir muito da memória com tantos dados ao mesmo tempo. Pelo menos agora, e com os 40 pontos, tem funcionado sempre.
Aqui ficam algumas imagens da caixa e do código. O interior fica para mais tarde ;)
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.iznogud.com%2Fgeosounduino%2Fpics%2Fimag0509.jpg&hash=ad8a696a6651fcb76dfdc0b79c14b81b1c41cfdd)
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.iznogud.com%2Fgeosounduino%2Fpics%2Fimag0510.jpg&hash=8ac699b824e22b29679e4d2dd374a0c8ded279ef)
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.iznogud.com%2Fgeosounduino%2Fpics%2Fimag0511.jpg&hash=444f1b39af0d8a189e85ee60d327b90c912981da)
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.iznogud.com%2Fgeosounduino%2Fpics%2Fgeosounduino_display.jpg&hash=5cfe6279981ad4e065ca84256e341e3e6c888bc9)
http://www.youtube.com/watch?v=E7i2aXZiXLo# (http://www.youtube.com/watch?v=E7i2aXZiXLo#)
/* GeoSounduino v.1.0
Criado por Ricardo Nogueira em 2010
Audioguia georeferenciado
*/
#include <avr/pgmspace.h>
#include <LiquidCrystal.h>
#include "LB_GPS.h"
//pinos e variaveis para SOMO 14d
const int pinClock= 12; //3;
const int pinData =11; //4;
const int pinBusy =10; //6;
const int pinReset=14; //7;
int busy=0;
//pinos e variaveis para lcd
LiquidCrystal lcd(4,5,6,7,8,9);
char symb[4][3] = {"\\",
"|",
"/",
"-"};
int custom_0[] = { 0x0,0x10,0x8,0x4,0x2,0x1,0x0 ,0x0}; // char "\"
int custom_1[] = { 0x0,0x1b,0xe,0x4,0xe,0x1b,0x0 ,0x0}; // char "x"
int custom_2[] = { 0x0,0x1,0x3,0x16,0x1c,0x8,0x0 ,0x0}; // char ok "\_"
int custom_3[] = { 0x1,0x3,0xf,0xf,0xf,0x3,0x1 ,0x0}; // char "som"
int custom_4[] = { 0x0,0xf,0x3,0x5,0x9,0x10,0x0, 0x0}; // char NE "/->"
int custom_5[] = { 0x0,0x10,0x9,0x5,0x3,0xf,0x0 ,0x0}; // char SE "\->"
int custom_6[] = { 0x0,0x1,0x12,0x14,0x18,0x1e,0x0, 0x0}; // char SW"<-/"
int custom_7[] = { 0x0,0x1e,0x18,0x14,0x12,0x1,0x0 ,0x0}; //char NW <-\"
int s=0; //estado do detector de actividade
int np=40; //total de pontos
int ps=0; //pontos encontrados
char* raw; //string recebida pelo gps
double xx; //latitude
double yy; //longitude
char* stt=0; //estado do FIX
char* head; //heading
double speeed;//velocidade
//estado de cada ponto: true-encontrado; false-por encontrar
boolean stts[40]=
{false,false,false,false,false,false,false,false,false,false,
false,false,false,false,false,false,false,false,false,false,
false,false,false,false,false,false,false,false,false,false,
false,false,false,false,false,false,false,false,false,false};
//direcção associada a cada ponto:N;S;E;W;4(NE);5(SE);6(SW);7(NW)
PROGMEM prog_char dirs[40]=
{'N','N','S','5','S','S','5','E','E','S','N','S','E','O','A','B','C','D','N','S',
'N','S','E','O','A','B','C','D','N','S','N','S','E','O','A','B','C','D','N','S'};
//pontos do itinerário
PROGMEM prog_uint32_t memp[40][2]=
{
{3874348, 930374},{3874012, 930732},{3873645, 930876},{3873470, 930623},{3872969, 930972},
{3872275, 930974},{3871875, 930593},{3871683, 930219},{3871407, 929718},{3870917, 929618},
{3874657, 918054},{3874517, 917489},{3874336, 917434},{3874336, 917435},{3874200, 917085},
{3874254, 917870},{3874402, 918202},{3874517, 918085},{3874585, 918210},{3874822, 918047},
{3874657, 918054},{3874517, 917489},{3874336, 917434},{3874336, 917435},{3874200, 917085},
{3874254, 917870},{3874402, 918202},{3874517, 918085},{3874585, 918210},{3874822, 918047},
{3874822, 918047},{3874822, 918047},{3874822, 918047},{3874822, 918047},{3874822, 918047},
{3874822, 918047},{3874822, 918047},{3874822, 918047},{3874822, 918047},{3874822, 918047}};
void setup(){
pinMode(pinData,OUTPUT);
pinMode(pinClock,OUTPUT);
pinMode(pinReset,OUTPUT);
pinMode(pinBusy,INPUT);
lcd.begin(16, 2);
//definir caracteres especiais
defineCharacter(0, custom_0);
defineCharacter(1, custom_1);
defineCharacter(2, custom_2);
defineCharacter(3, custom_3);
defineCharacter(4, custom_4);
defineCharacter(5, custom_5);
defineCharacter(6, custom_6);
defineCharacter(7, custom_7);
lcd.print("GeoSounduino 1.0");
lcd.setCursor(0,1);
lcd.print("a Inicializar...");
//definir tipo de dados gps a analisar (gprmc)
GPS.setSentences(GPRMC);
delay(100);
//definir localizaçao inicial, data e hora
GPS.init();
//GPS.setDate("6,08,2010");
//GPS.setTime("10,00,00");
}
void loop(){
//variaveis auxiliares
char xxs[10];
int xx_d;
double xx_m;
char yys[10];
int yy_d;
double yy_m;
char* vel;
char* lat=" ";
char* lon=" ";
// stt=" ";
vel=" ";
head=" ";
speeed=0;
xx=0;
yy=0;
//recaber string gps
raw=GPS.getRaw(100);
GPS.GPSStringExplode(GPS.inBuffer,',');
//identificar variaveis utilizadas
lat=(char*)GPS.arguments[3];
lon=(char*)GPS.arguments[5];
stt=(char*)GPS.arguments[2];
vel=(char*)GPS.arguments[7];
head=(char*)GPS.arguments[8];
speeed=atof(vel);
//conversão de coordenadas gps (polares) para coordenadas cartesianas
xx=atof(lat);
xx_d=xx/100;
xx_m=xx-xx_d*100;
xx_m=xx_m/60;
xx=xx_d+xx_m;
yy=atof(lon);
yy_d=yy/100;
yy_m=yy-yy_d*100;
yy_m=yy_m/60;
yy=yy_d+yy_m;
//comparação do ponto actual com os pontos gravados
ponto(xx,yy);
//escrever dados no lcd
display1();
//incremento do detector de actividade
s++;
if(s>3){
s=0;
}
delay(500);
}
//tocar faixa audio - código retirado de: Doyle Maleche -> maleche1 at comcast dot net
void sendData(int ThisSong){
int TheSong = ThisSong;
int ClockCounter=0;
int ClockCycle=15;//0x0f;
digitalWrite(pinClock,HIGH);
delay(300);
digitalWrite(pinClock,LOW);
delay(10);
while(ClockCounter <= ClockCycle){
digitalWrite(pinClock,LOW);
if (TheSong & 0x8000){
digitalWrite(pinData,HIGH);
}
else{
digitalWrite(pinData,LOW);
}
TheSong = TheSong << 1;
delayMicroseconds(200);
digitalWrite(pinClock,HIGH);
ClockCounter++;
delayMicroseconds(200);
}
digitalWrite(pinData,LOW);
digitalWrite(pinClock,HIGH);
digitalWrite(pinClock,LOW);
}
//definir caracters especiais
int defineCharacter(int ascii, int *data) {
int baseAddress = (ascii * 8) + 64;
// baseAddress = 64 | (ascii << 3);
lcd.command(baseAddress);
for (int i = 0; i < 8; i++)
lcd.write(data[i]);
lcd.command(128);
return ascii;
}
//verificação de pontos
void ponto(double x, double y)
{
for(int n=0;n<np;n++){
//só percorre pontos ainda não encontrados
if(stts[n]==false){
//calculo para confirmar ponto dentro de um raio de +- 50m
if(pow(x-(0.00001*pgm_read_dword_near(memp[0] + n*2)),2) + pow(y-(0.00001*pgm_read_dword_near(memp[0] + (n*2)+1)),2) <= pow(0.00055,2)){
//confirma a direcção associada ao ponto
if(direct(head)==(char)pgm_read_word_near(dirs + n)){
//dá ponto com encontrado
stts[n]=true;
//toca som associado ao ponto
sendData((n+1)*2);
//incrementa pontos encontrados
ps++;
}
}
}
}
}
//informação no lcd
void display1()
{
lcd.clear();
lcd.setCursor(0, 0);
lcd.print(xx,5);
lcd.setCursor(8, 0);
lcd.print("/");
lcd.print(yy,5);
lcd.setCursor(0, 1);
if(stt[0]=='A'){
lcd.write(2);
}
else{
lcd.write(1);
}
lcd.setCursor(2,1);
if(speeed<=1){
lcd.print("-");
}
else{
char d=direct(head);
if(d=='N'||d=='S'||d=='E'||d=='O'){
lcd.print(d);
}
else{
char* letra;
letra[0]=d;
letra[1]='/0';
lcd.write(atoi(letra));
}
}
lcd.setCursor(4,1);
lcd.print(speeed*1.6093,0);
lcd.setCursor(8, 1);
lcd.write(3);
lcd.print(ps);
lcd.print("/");
lcd.print(np);
busy =digitalRead(pinBusy);
lcd.setCursor(14,1);
if(busy==1){
lcd.write(3);
}
else{
//para futuramente colocar musica(s) "ambiente"
}
lcd.setCursor(15, 1);
if(s==0){
lcd.write(0);
}
else{
lcd.print(symb[s]);
}
}
//conversão do heading para 8 pontos cardeais
char direct(char* head)
{
double head_f=atof(head);
if(head_f>=20 && head_f<=110){
//NE
return '4';
}
else if(head_f>=70 && head_f<=110){
return 'E';
}
else if(head_f>110 && head_f<160){
//SE
return '5';
}
else if(head_f>=160 && head_f<=200){
return 'S';
}
else if(head_f>200 && head_f<250){
//SW
return '6';
}
else if(head_f>=250 && head_f<=290){
return 'W';
}
else if(head_f>290 && head_f<340){
//NW
return '7';
}
else{
return 'N';
}
}
Ah, e obrigado a todos pelas ajudas e sugestões no outro tópico!
-
Adorei o projecto!
Está muito bom, os meus parabéns.
E já agora que tenha sucesso quando entrar na produção em série ;D
Uma perguntinha: pode-se saber onde arranjaste a caixa? foi fácil encaixar o LCD?
-
Adorei o projecto!
Está muito bom, os meus parabéns.
E já agora que tenha sucesso quando entrar na produção em série ;D
Uma perguntinha: pode-se saber onde arranjaste a caixa? foi fácil encaixar o LCD?
Obrigado!
A caixa foi comprada na dimofel em lisboa, e custa cerca de 4€. É de plástico, tem um sistema de encaixe sem parafusos, o que à primeira vista parecia mau, mas depois até se revelou uma vantagem. Como é de plástico, foi só usar a dremel para fazer o buraco para o lcd, e mesmo não ficando perfeito, tenho uma ideia de como disfarçar a “junta”... :)
-
O projecto ficou com bastante bom aspecto :) coloca uma mensagem no outro tópico a indicar que a continuação é neste. Se calhar o ideal era usares um micro mais potente como por exemplo o arduino mega mas não sei se este existe numa placa mais pequena. O ideal era não usar linguagem arduino como produto final mas programar em C pois é mais eficiente.
-
O projecto ficou com bastante bom aspecto :) coloca uma mensagem no outro tópico a indicar que a continuação é neste.
Obrigado! Farei isso.
Se calhar o ideal era usares um micro mais potente como por exemplo o arduino mega mas não sei se este existe numa placa mais pequena. O ideal era não usar linguagem arduino como produto final mas programar em C pois é mais eficiente.
Em c, em vez de arduino? Agora baralhaste-me...
Não fazia ideia que podia usar o c. Mas como carrego um programa em C?
E qual "versão" de C? Vou ver se percebo o que queres dizer com isso...
Até ver, o atmega328 tem aguentado com o código, e os pequenos bugs têm sido resolvidos... mas por vezes falha de forma estranha (reinicia, ou bloqueia). Presumo que o problema está nas conversões (atof e atoi) que não devem correr muito bem.
-
Para usar puro C e acesso directo a tudo no atmega podes ler isto:
http://www.smileymicros.com/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=70&MMN_position=117:117 (http://www.smileymicros.com/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=70&MMN_position=117:117)
E aproveita para ler todos os outros tutoriais desse site que são de topo mesmo, depois regista-te no avrfreaks e lê toda a secção de tutoriais que está aqui:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewforum&f=11&sid=758e68a2f0269e762ad222c5942549f5 (http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewforum&f=11&sid=758e68a2f0269e762ad222c5942549f5)
É que coisas simples como usar a usart(serial) ou o adc é bem mais "complexo" usando acesso directo aos registos e assim que usando o arduino.
Terás tambem de instalar o AvrStudio e o WinAvr, mas isso é explicado nos primeiros tutoriais desse site que já acima aconselhei a ler.
Por exemplo usar acesso directo ás portas em vez de usar os digitalWrite poupa-te cerca de 40 ciclos de relógio de cada vez, o que dá um diferença massiva de performance.
-
Podes continuar a usar o IDE do arduino.
-
Já andei a dar uma vista de olhos nos links que o senso forneceu... e para já só posso dizer... ainda bem que entrei de férias! :P
Já estou a trabalhar há muito tempo em linguagens de alto nivel em máquinas relativamente potentes, e habituei-me a descurar as implicações ao nivel do desempenho. Mas agora, com esta incursão nos pics, percebo que faz toda a diferença optimizar as coisas de forma a "abreviar" algumas acções. Vou estudar o assunto. ;)
-
Muito bom. O futuro dos guias turisticos.
Atenção à direçcão Norte / Sul por GPS, não é nada de fiar em baixas velocidades ou quando se está parado. Complementa com uma bussula digital!
Parabéns, estou a adorar ver. Muito semelhante a uma ideia minha para geo caching.
-
Muito fixe! :) Parabéns...
Gostei bastante de ver as fotos do projecto... E é bom ver o pessoal a meter o código sem problemas.
É bom para todos... Aprendes tu e aprendemos todos os que lemos.
Continua...
-
:D LINDO !!!
-
Isto mete-me mesmo a babar-me. Quero ver mais ideias a sugeri daqui.
-
http://www.engadget.com/2010/08/11/disney-converting-droid-eris-into-gps-tour-guide/ (http://www.engadget.com/2010/08/11/disney-converting-droid-eris-into-gps-tour-guide/)
-
Muito bom. O futuro dos guias turisticos.
Atenção à direçcão Norte / Sul por GPS, não é nada de fiar em baixas velocidades ou quando se está parado. Complementa com uma bussula digital!
Parabéns, estou a adorar ver. Muito semelhante a uma ideia minha para geo caching.
olhando a esta ideia da bússola digital, acho que poderias usar um servo de 360º e colocar o esquema de uma bússola e sempre que o carro anda-se as voltas a bússola faria mover o servo pondo-o sempre a apontar para norte, que achas da ideia?
-
Neste momento o que faz ao certo?
-
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... :P
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! 8) 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...
-
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.
-
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/ (http://code.google.com/p/opengauge/)
-
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.
-
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?
-
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)?
-
errado.. são os pinos 4 e 5 analógicos que são usados para a comunicação i2c..
-
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.
-
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:
#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) ;
-
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.
-
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! :P
-
crach :P
estou a brincar, so lhe falta um lcd a cores e com um mapa para mostrar o caminho :D
-
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.
-
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.
-
Podes ler as vezes que quiseres, mas é mais rapido ler a flash que ler a eeprom, a escrita é que tem ciclos limitados.
-
Ola a todos.
Após mais alguns retoques quer no código, quer no hardware, sendo que o mais significativo foi a introdução de uma eeprom de 256Kb que será usada para guardar os pontos, tenho feito mais alguns testes que só não me deixam 100% satisfeito porque o som não está ainda "perfeito".
Sendo o módulo somo14d de 16bits mono, não quero ser muito exigente, mas o que acontece é que, usando a saida spk + e -, consigo ter um som fantástico nos headphones. Quando ligo essa saída a uma entrada line-in de um amplificador (ou mesmo do radio do carro), tenho um barulho de fundo (tipo estatica...) bastante incomodativo.
Sendo esta uma área que domino pouco, presumo que tal tem a haver com as impedâncias dos "receptores", mas sendo assim como posso resolver o problema?
Na datasheet do módulo somo, falam na possibilidade de utilizar a sáida audio out que é do tipo DAC/PWM, mas o circuito de exemplo parece-se mais com um amplificador que outra coisa... e neste momento a potencia do som é mais que suficiente, mas o ruido é que incomoda.
Alguém me pode sugerir uma opção mais simples?
-
podes sempre fazer um filtro passa baixo ou passa alto, ou ate mesmo juntar os dois, eu é que já n me lembro de como é que se faz isso :S
-
Só por piada, e porque agora estão na moda os "teasers" comerciais... aqui ficam duas imagens estilizadas do "produto" em causa...
:P
-
Experimenta utilizar um op-amp e um condensador para bloquear o dc entre a saida do teu modolo de som e o dac, não te sei dizer que modelos de op-amps podes usar, mas alguem aqui deve saber.