collapse

* Posts Recentes

Amplificador - Rockboard HA 1 In-Ear por almamater
[Ontem às 19:13]


O que é isto ? por KammutierSpule
[26 de Março de 2024, 19:35]


Bateria - Portátil por almamater
[25 de Março de 2024, 22:14]


Emulador NES em ESP32 por dropes
[13 de Março de 2024, 21:19]


Escolher Osciloscópio por jm_araujo
[06 de Fevereiro de 2024, 23:07]


TP4056 - Dúvida por dropes
[31 de Janeiro de 2024, 14:13]


Leitura de dados por Porta Serie por jm_araujo
[22 de Janeiro de 2024, 14:00]


Distancia Cabo por jm_araujo
[08 de Janeiro de 2024, 16:30]


Meu novo robô por josecarlos
[06 de Janeiro de 2024, 16:46]


Laser Engraver - Alguém tem? por almamater
[16 de Dezembro de 2023, 14:23]

Autor Tópico: Módulo gsm  (Lida 29808 vezes)

0 Membros e 1 Visitante estão a ver este tópico.

Offline dropes

  • Mini Robot
  • *
  • Mensagens: 2.189
Re: Módulo gsm
« Responder #45 em: 19 de Junho de 2016, 11:49 »
Se os terminais do atmega estão azuis é porque fica do lado bottom, segue o circuito logo não pode ficar inverso.

Em eagle nem é possível colocar um IC ao contrário, as ligações seriam negadas, parece-me bem o que desenhaste, falta o plano de terra e uns condensadores de desacoplamento junto ao micro.

Offline dio123

  • Mini Robot
  • *
  • Mensagens: 1.032
Re: Módulo gsm
« Responder #46 em: 19 de Junho de 2016, 16:38 »
Pois os condensadores e que faltava mas já la estão, apesar de não terem ficado muito juntos ao atmega.
Plano terra ja tenho feito. 
No entanto é a primeira vez que vou soldar TQFP e estou um pouco na duvida se os pads do atmega não deveriam sair um pouco mais para fora, para dar mais espaço de manobra para soldar.


Offline dio123

  • Mini Robot
  • *
  • Mensagens: 1.032
Re: Módulo gsm
« Responder #47 em: 21 de Agosto de 2016, 19:25 »
boa tarde,
No avr studio da para ver quanto tempo demora o atmega no ciclo principal while a repetir o ciclo.
A ideia era saber quanto tempo demora o meu codigo a fazer um loop, e a memoria ocupada com as variaveis globias.

Atmega no lado botton fica ao contraio, e tem logica se o eagle diz que é top nao devia contrariar.   Consegui corrigir refiz tudo do lado top.

Foi uma dificuldade enorme soldar tqfp, ainda vi bastantes videos no youtube mas mesmo assim vi-me a rasca. nem com malha os curtos desapareciam. Consegui apenas estanhando todos os pads depois com ferro sem solda ficar em 2 patas. Meti fluxo nos pads todos e ferro sem solda encostar.
Acho que pads de origem do eagle sao muito largos e haviam de ser um pouco mais compridos.

Se nao fosse o vinco do folha celefone tinha ficado bom, mas comprei um rolo e tem esse vinco nele todo.

« Última modificação: 21 de Agosto de 2016, 19:30 por dio123 »

Offline Sérgio_Sena

  • Administrator
  • Mini Robot
  • *****
  • Mensagens: 1.649
    • Electronic Gear for Musicians
Re: Módulo gsm
« Responder #48 em: 21 de Agosto de 2016, 22:06 »
Soldar QFP eh tranquilo. Qd fores p QFP 100 pinos entao podes queixar-te, mas tb se soldam bem. Depois vais querer soldar QFN e mais tarde alguns BGA p testes em casa. Todos se soldam bem c o equipamento e ferramentas correctas.
Solda fina, ferro ponta fina, boa tranca dessoldadora (escolher bem pq ha mt porcaria) e mt fluxo (tb escolher bem pq ha mt porcaria)

Ja agora, fizeste as contas ao material q usaste p fazer as PCBs ?
Eh q conseguem-se 5x5cm por $10+portes e de qualidade aceitavel p hobbies.


Offline dio123

  • Mini Robot
  • *
  • Mensagens: 1.032
Re: Módulo gsm
« Responder #49 em: 27 de Agosto de 2016, 16:59 »
Contas ao material não fiz, mas sei que nao compensa. Mas fica aquele prazer de fazer tudo de raiz, e ver o projecto crescer aos poucos.

Estou a organizar/testar o meu codigo e decidi meter uns quantos sub-programas e tentar deixar o while(1) principal com o menos possivel. ficando apenas 3 if's. Se detectar chamada, mensagem  ou activar alarme.

A questao aqui é que as coordenadas deixaram de funcionar quando tirei do programa principal e nao consigo resolver a questão por nao conhecer a linguagem assim tao bem.

coordenadas(); tem de estar no while para funcionar, e eu só criar obter coordenadas quando chamar sub programa. Mas ao colocar em sub programa as latitude longitude ficam em branco

Foi copiado daqui por ser simples http://stackoverflow.com/questions/36967099/parse-gnss-nmea-string o codigo que esta no final.

Codigo foi cortado parte para nao ficar muito extenso.
Código: [Seleccione]
#define F_CPU 16000000UL
#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include <string.h>
#include <stdlib.h>


#define BAUDRATE 9600
#define BAUD_PRESCALLER (((F_CPU / (BAUDRATE * 16UL))) - 1)

 
void USART_init(void);
static char *strtok_single(char *str, char const *delims);
void coordenadas(void);
unsigned char USART_receive(void);
void USART_send( unsigned char data);
void USART_putstring(char* StringPtr);
void adc_init(void);

uint16_t read_adc(uint8_t channel);

// declaracao variaveis

char buffer[100];
char * s;
char * pch;
int adc_value;
char busgps[100];
char latitude[11];
char logitude[12];


int main(void)
{
sei();
USART_init();
adc_init();
lcd_begin();
lcd_msg("Iniciar GPS 2.3");

while (1){
if ( strcmp(telefone, "966666666") == 0  ){
lcd_msg("user aceite");
endcall(); //  termina chamada
coordenadas(); // le coordenadas
sms(); // envia sms
limpa(); // limpa buffers
menup(); // volta menu
}
}

ISR (USART_RX_vect)
{
}

void coordenadas(void)
{
USART_putstring("AT+CGNSINF\r\n"); // le coordenadas

strcpy(busgps, buffer);
// Parses the string
strtok_single(busgps, " ");
strcpy(latitude, strtok_single(NULL, ",")); // Gets latitude
strcpy(logitude, strtok_single(NULL, ",")); // Gets longitude
}

static char *strtok_single(char *str, char const *delims)
{
static char  *src = NULL;
char  *p,  *ret = 0;

if (str != NULL)
src = str;

if (src == NULL || *src == '\0')    // Fix 1
return NULL;

ret = src;                          // Fix 2
if ((p = strpbrk(src, delims)) != NULL)
{
*p  = 0;
src = ++p;
}
else
src += strlen(src);

return ret;
}


Online jm_araujo

  • Mini Robot
  • *
  • Mensagens: 2.947
  • NERD!
Re: Módulo gsm
« Responder #50 em: 27 de Agosto de 2016, 17:57 »
Onde é que estás a encher o buffer?
Quando envias um comando a resposta demora um bocado a vir, não é imediata.

Citar
   USART_putstring("AT+CGNSINF\r\n"); // le coordenadas

   strcpy(busgps, buffer);


Aí no meio deve faltar qualquer coisa....

Offline dio123

  • Mini Robot
  • *
  • Mensagens: 1.032
Re: Módulo gsm
« Responder #51 em: 27 de Agosto de 2016, 19:39 »
buffer enche no ISR.
Quando faço delay 10s por baixo  strcpy(busgps, buffer); e no proteus vou ver buffer tem as coordenadas e busgps não tem nada.
No meio nao falta nada, so se agora como esta sub programa tenha de levar alguma coisa, mas também não estou a ver.

Código: [Seleccione]
ISR (USART_RX_vect)
{
buffer[posicao] = UDR0;
if (buffer[posicao] == '\n') {
count_cr++;
}

if (count_cr == 1) {
print = 1;
}
if (count_cr == 2) {
print = 2;
}
if (count_cr == 3) {
print = 3;
}
if (print == 1 ) {
data1[pdata1] = buffer[posicao];
pdata1++;
}
if (print == 2 ) {
data2[pdata2] = buffer[posicao];
pdata2++;
}
if (print == 3 ) {
data3[pdata3] = buffer[posicao];
pdata3++;
}
posicao++;

}
« Última modificação: 27 de Agosto de 2016, 19:41 por dio123 »

Online jm_araujo

  • Mini Robot
  • *
  • Mensagens: 2.947
  • NERD!
Re: Módulo gsm
« Responder #52 em: 27 de Agosto de 2016, 20:37 »
Tá-me a falhar algo.
No código que meteste não tem nenhum delay.

Tens de ter o delay entre o pustring que envia o comando para o módulo e a cópia do buffer para o busgps com o strcopy, para dar tempo ao módulo para responder.


O código que mostras do ISR também está confuso. A variável posição não está definida no código original, e não vejo no código verificação que a mesma se mantém dentro dos limites do tamanho do buffer.

Tens de rever esse código e perceber o que está a fazer, parece que estás a ultrapassar os limites do cut&paste, mas é difícil de dizer com certeza.


Offline dio123

  • Mini Robot
  • *
  • Mensagens: 1.032
Re: Módulo gsm
« Responder #53 em: 27 de Agosto de 2016, 21:24 »
Com o delay ja resolveu meti _ms_delay(100) e ja funcionou, pois anteriormente tinha posto 20 nao ficava latitude longitude altitude certa.
Tinha ideia que o delay dava uma pausa geral ao programa que durante esse tempo nao fazia mais nada.

A minha teoria foi: se coloco o delay por baixo do comando ele envia o comando para o modulo, o modulo responde, mas como esta resposta vem dentro do tempo do delay nao vai apanhar.

O meu ISR esta um pouco confuso, mas na verdade e por causa dos sms. Na pratica divide-me buffer em 3 partes depois pego na parte 2 que onde  esta o conteudo da mensagem.

Nao deu para colocar codigo todo por esta mesmo muito extenso por isso e que falta pdata e afins
« Última modificação: 27 de Agosto de 2016, 21:28 por dio123 »

Online jm_araujo

  • Mini Robot
  • *
  • Mensagens: 2.947
  • NERD!
Re: Módulo gsm
« Responder #54 em: 27 de Agosto de 2016, 21:42 »
Afinal acertei à primeira ;)

No ISR deves meter o mínimo possível. no caso da porta série metes para o buffer e vaza. Processamento extra deves fazer fora.
Quando um ISR está a correr se ocorrerem outros interrupts ficam bloqueados à espera. Ora se tens algo que "exige" atenção imediata do processador e não a consegue, podem surgir todo um mundo perverso de anomalias. Por exemplo os delays dependem de interrupts, se o processador estiver preso a tratar da porta série e dependeres da precisão dos delays, já eras.





Offline Hugu

  • Mini Robot
  • *
  • Mensagens: 5.602
  • Keyboard not found. Press any key to continue.
    • [url=www.g7electronica.net]G7 Electrónica.net[/url]
Re: Módulo gsm
« Responder #55 em: 28 de Agosto de 2016, 15:40 »
Real problema esta descoberto,  graças a grande qualidade de produção dos chineses não é que os gajos soldaram os conectores ipex ao contrario, o do gsm e gps estão ao contrario, só Bluetooth e que esta certo.

Entanto tentei tirar ipex com jeitinho mas acabei por estragar  arranquei ipex e soldei 2 fios directamente para a antena.   e agora tenho rede. csq 13.
como é que estavam os dois conectores soldados ao contrário?
é esquisito, porque as boards sao produzidas aos milhares e normalmente testadas, e automaticamente, mas mm que fossem soldadas à mao, os pinos dos conectores teriam de coincidir com os sitios/pads onde vao a soldar (as pads normalmente em comunhao com a disposiçao dos pinos dos componentes, funcionam como sistemas poka-yoke para evitar más montagens..)
Por acaso tens foto da board antes de re-posicionares e ressoldares os conectores só pra ver?
« Última modificação: 28 de Agosto de 2016, 15:42 por Hugu »

Offline dio123

  • Mini Robot
  • *
  • Mensagens: 1.032
Re: Módulo gsm
« Responder #56 em: 28 de Agosto de 2016, 20:23 »
O conector ipex tem 3 pinos massa e 1 pino é sinal. o meu pino sinal estava rodado 90º para esquerda se nao me engano e ficando ligado a massa

Offline dio123

  • Mini Robot
  • *
  • Mensagens: 1.032
Re: Módulo gsm
« Responder #57 em: 19 de Setembro de 2016, 22:22 »
Afinal não funciona, e está me aqui a escapar alguma coisa e continuo a nao perceber o poque.
(codigo total em anexo)

Se o subprograma estiver dentro ciclo while funciona bem se estiver dentro de um if em que so la passa 1 vez ja nao funciona. e no meu caso nao consigo obter as coordenadas , e quando obtem coordenadas nao copia  strcpy(logitudeg,logitude); fica a variavel em branco.
Será que strcpy ate alguma regras para funcionar bem.

 
Citar
int as = 0;
while (1){
   if (as == 0){
      as = 1;
      alarmestate = 1;
      limpa();
               coordenadas();
          lcd_msg("ja esta");
      }
}
}

Offline Njay

  • Mini Robot
  • *
  • Mensagens: 3.598
    • Tróniquices
Re: Módulo gsm
« Responder #58 em: 19 de Setembro de 2016, 23:42 »
Não olhei com atenção, mas tens algumas coisas mal ou potencialmente mal:

-> Normalmente só se habilitam as interrupções depois de feita a inicialização do hw.

-> Todas as variáveis globais que são usadas em interrupções e simultaneamente em ciclos dentro da função principal têm que ser declaradas com volatile, caso contrário a variável pode não ser actualizada; mas podes ter ou vir a ter problemas mais graves (esporádicos), porque não tens sincronização nenhuma no acesso a essas variáveis (pode não ser necessário, não analisei).

-> Cuidado com variáveis locais grandes (como arrays) ou muitas, pois podes estar a ter stack overflow sem te aperceberes.

-> Se declarares as funções (excepto a main()) e variáveis globais com static, o código gerado encolhe.

-> Interrupções vazias podes declarar com EMPTY_INTERRUPT que gera menos código e é mais eficiente, por exemplo: EMPTY_INTERRUPT(WDT_vect)

-> A indentação tá um bocado má, por isso não vejo mais. Precisas de trabalhar um pouco nisso, pois é essencial para aumentar a ergonomia da leitura de código.
« Última modificação: 19 de Setembro de 2016, 23:45 por Njay »

Offline dio123

  • Mini Robot
  • *
  • Mensagens: 1.032
Re: Módulo gsm
« Responder #59 em: 13 de Novembro de 2016, 22:26 »
boa noite, ando aqui com uns grandes bugs, penso que tenha a ver com a comunicação entre avr e o modulo.
Depois de umas maratonas no google e varios testes, de modo a refazer a comunicacao no melhor possivel, não percebo porque é que o meu data_in é alterado quando uso strcpy.

ISR (USART_RX_vect)  diz-me  cmd_ok= TRUE; quer dizer que ja recebi tudo o que tinha a receber e que posso processar os dados.
no while tem ordem e ao dividir a resposta em 3 char,  o meu data_in altera-se e nao consigo perceber porque, nao devia alterar.

imagem do problema lado esquerdo bom direito mau: https://l68w8n.s.cld.pt
codigo completo em anexo

Código: [Seleccione]
while (1){
if (cmd_ok == TRUE){
copy_cmd();
cmd_ok = FALSE;
}
}
}

void copy_cmd(void){
strtok(data_in,"\n");
strcpy(data1, strtok(NULL, "\n"));
strcpy(data2, strtok(NULL, "\n"));
strcpy(data3, strtok(NULL, "\n"));
}

ISR (USART_RX_vect)
{
data_in[posicao] = UDR0;
if (data_in[posicao] != '\0' ){
posicao++;
}
if (data_in[posicao +1] == '\0'){
cmd_ok= TRUE;
}
}