TODOPIC
Microcontroladores PIC => Almacén del Assembler => Mensaje iniciado por: groundman en 06 de Mayo de 2007, 17:33:13
-
hola,tengo un problemilla.
tengo que realizar la comunicacion con un gps,mediante la usart del 16f876,la velocidad de comunicacion es de 38400bps.y segun veo el registro BRGH,esa velocidad no viene,por lo menos en el datashet del pic.
con que cristal y configuracion del registro obtendria esta velocidad?
-
tengo que realizar la comunicacion con un gps,mediante la usart del 16f876,la velocidad de comunicacion es de 38400bps.y segun veo el registro BRGH,esa velocidad no viene,por lo menos en el datashet del pic.
groundman, creo que te estas confundiendo el registro SPBRG con el bit BRGH. Uno es para setear el baudeaje y el otro el modo de muestreo que te permitirá trabajar con baudeajes más altos.
con que cristal y configuracion del registro obtendria esta velocidad?
Las combinaciones pueden ser muchísimas!
En el datasheet hay una simple formula de cálculo que en base al cristal que tengas te permitirá saber qué valor de SPBRG necesitas para lograr el baudeaje que quieres.
Si hay algo que te genera duda de esa fórmula, nos preguntas y te lo decimos.
-
es verdad,perdon.yo iba mal encaminado solo ha sido una confusion de letras,yo me referia al SPBRG.
ah y he estado mirando la formula. Baud Rate= Fosc/(16(x+1)) donde Fosc sera el crystal a utilizar y x el valor que se le introducira al registro SPBRG.
pero si ya se el BaudRate que voy a utilizar,38400bps.cual sera la formula para calcular el crystal?
es que la regla de tres ya hace tiempo que no la utilizo. :lol:
-
ah tambien esta la otra formula para low speed:
Baud Rate=Fosc/(64(x+1))
cual sera la mas apropiada?la que se acerque mas al cristal y dato en SPBRG?
-
ah tambien esta la otra formula para low speed:
Baud Rate=Fosc/(64(x+1))
cual sera la mas apropiada?la que se acerque mas al cristal y dato en SPBRG?
Para baudeajes sobre los 9600 lo más apropiado es usar el modo de alta velocidad, y para el baudeaje que tu utilizas, te dará mayor precisión.
Oye, para saber el cristal a utilizar despejas Fosc de la fórmula y listo!
Tampoco necesitas 100% de precisión!, con un pequeño error funcionará igual, es por eso que te sugiero pruebes calcular con algún cristal que tengas a mano , no se, 16MHz, 20MHz, 8MHz, alguno que elijas y hagas el cálculo. Si quieres lo subes acá y lo verificamos.
Cómo te darás cuenta, pretendo que lo aprendas a hacer y no a que yo te de el resultado, de esa forma te aseguro que lo aprenderás y jamás lo olvidarás. Si te doy la respuesta... no sabrás bien el porqué. :) :)
-
te entiendo y te lo agradezco,porque me ha serbido para aprender.pues..
creo que lo he logrado.tengo que poner BRGH=1 que corresponde a la formula Baud Rate=Fosc/(16(x+1))
donde x va al SPBRG ,pondre el valor 5 ya que (16(5+1))=96 y la formula que he hecho xtal=(16(5+1))(BaudRate) = 96x38400 =3.686400Mhz
y mira por donde ese crystal se comercializa :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ espero no haberme equivocado.lo he hecho bien?
-
upss,acabo de darme cuenta de que en el datashet de este pic ,en la tabla viene los datos a introducir,para conseguir las velocidades de 33.6 kbaud y 57.6 kbaud
pero ya podian haber puesto entre medias el valor para 38400,ya les vale. :x.
-
y mira por donde ese crystal se comercializa :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ :-/ espero no haberme equivocado.lo he hecho bien?
Sí, lo has hecho bien, ahora si solo quieres usar el PIC para transmisiones precisas y el resto de los tiempos de tu aplicación no necesitan cálculos muy precisos, no habrá ningún inconveniente, pero si necesitas tiempos precisos también con otras rutinas te aclaro que ese valor de cristal te complicará la forma de pensar ya que cada ciclo de instrucción demorará 1,085 microsegundos.
upss,acabo de darme cuenta de que en el datashet de este pic ,en la tabla viene los datos a introducir,para conseguir las velocidades de 33.6 kbaud y 57.6 kbaud
pero ya podian haber puesto entre medias el valor para 38400,ya les vale. :x.
Je, bueno, ¿tampoco se puede tener todo en la vida no? Y hubieras tenido el dato ya resuelto, no habrías aprendido a cómo calcularlo. :)
Si quieres como ejercicio, puedes calcular el X que te daría para un cristal de 16MHz, y luego compara el baudeaje obtenido con el que quieres obtener y calcula el error. Allí veras que el error... no es tanto :)
-
para 16MHz hay un crystal muy cercano el 15.9744MHz que el valor de x es 25.pero para un crystal que tambien sirva para.manejar tiempos esta el 16.777.216MHz pero no se esa diferencia de 802.816KHz tendra mala influencia para la usart.
y para el crystal de 3.6864MHz valor x=5 el mas cercano para tiempos mas exactos es el 4.194304MHz que tiene una diferencia de 507.904KHz.
pero como es una frecuencia 4 veces menor,supongo que hay mas margen de error ya que para que hubiera menor margen de error, la frecuencia de diferencia
deberia ser menor de 200.704KHz.
-
para 16MHz hay un crystal muy cercano el 15.9744MHz que el valor de x es 25.pero para un crystal que tambien sirva para.manejar tiempos esta el 16.777.216MHz pero no se esa diferencia de 802.816KHz tendra mala influencia para la usart.
y para el crystal de 3.6864MHz valor x=5 el mas cercano para tiempos mas exactos es el 4.194304MHz que tiene una diferencia de 507.904KHz.
pero como es una frecuencia 4 veces menor,supongo que hay mas margen de error ya que para que hubiera menor margen de error, la frecuencia de diferencia
deberia ser menor de 200.704KHz.
Para qué complicarsela tanto
Si se usa un cristal de 16.0000 MHz veamos el error que se obtiene
X = (Fosc/Baud * 16) - 1
X = (16000000 / (38400 * 16) ) - 1 = 25,0416667
Tomamos X = 25
Baud. Obtenido = Fosc / (16*(x+1)) = 38461,5385
Error (%) = 100 * (Baud Obtenido - Baud Deseado) / BaudDeseado = 0,16%
Como ven el error es ínfimo y les aseguro que funcionará de maravillas.
-
entiendo,pero hasta que % de error,no es conveniente sobrepasar? y que pasaria si sobrepasamos ese % de error?
ah,otra cosilla.
he estado transmitiendo desde el pc al pic,por el usart.y no me concuerdan los datos recividos por el pic.por ejemplo:
a las teclas que he pulsado he obtenido los siguientes valores.
a=4Fh
b=27h
c=4Eh
d=13h
1=67h
2=33h
los he estado comparando con tablas ASCII que he visto por internet y no me coinciden los valores,con los que deberian poner.
-
Puedes probar primero al revés? PIC primero hacia la PC? digamos, pensando en que tal vez tengas un problema con el baudeaje o bien con la masa, o con otra cosa.
Saludos
-
tendre que provar,pero lo raro es que si fuera una mala masa, la tecla que pulsara,el valor seria casi siempre diferente.
y en mi caso el valor siempre es el mismo para la tecla que pulso,la verdad es que algo he tenido que hacer mal,porque me estoy acordando
de que durante la realizacion del programa ,las primeras pruevas ,las teclas del 1 al 9 tenian como un orden relativo.es decir que el valor iba incrementando.
pero segun la configuracion de los registro esta todo corecto.
BANK1
clrf TRISB ;Puerta B como salida
movlw b'10111111' ;RC7/Rx entrada,
movwf TRISC ;RC6/Tx salida.
movlw 0x06
movwf ADCON1 ;porta entradas digitales
movlw 0xcf
movwf TRISA
movlw b'00100100' ;Configuracion USART modo alta velocidad 9600 baud
movwf TXSTA ;y activacion de transmision
movlw .25 ;9600 baudios
movwf SPBRG
BANK0 ;Cambio al banco 0 -------------
movlw b'10010000' ;Configuracion de la usart
movwf RCSTA ;para recepcion continua y habilitacion de la usart
movlw b'11000000' ;Habilitacion para las
movwf INTCON ;interrupciones en general y perifericas
-
El error de baudeaje aceptable, depende del hardware que esté del otro lado, pero no debieras tener mayores problemas si el error es menor al 5%. No me dijiste si probaste del pic hacia la PC...
Respecto a tu código, fijate esto
movlw b'10111111' ;RC7/Rx entrada,
movwf TRISC ;RC6/Tx salida.
En los 16F, trisc<7:6> ambos deben estar en 1.
movlw b'11000000' ;Habilitacion para las
movwf INTCON ;interrupciones en general y perifericas
¿realmente usas las interrupciones? sino es así, no hace falta habilitarlas.
Por otra parte, no has posteado el código de la recepción , tal vez allí esté el problema.
-
tengo que repasar el programa ,no quiero marearte tampoco bucho hasta que no este seguro de no poder solucionarlo.
una cosa,el trisc lo he configurado de esa manera porque rc6 es una salida tx,o no va de esta manera?
yo se que una vez tube problemas con el porta,pero porque antes de utilizar este puerto como entradas o salidas,habia que configuralo como entradas digitales o analogicas.pero el puero de la ¿ usart?,no se.????? hay algo que se me escapa?
-
aaaaaaaaaaarrrrg,tenias razon me equivoque de cable al conectar a masa,y solo tenia conectador rx y tx.
ya decia yo que el mismo programa lo vi funcionando bien.que perdida de tiempo.perdon,pero porfavor aclarame lo del trisc,no lo entiendo.
-
ah,la interrupcion la uso ,por que mientras el rx no reciva ningun dato el pic esta enviando constantemente unos caracteres al pc.y cuando toque una tecla en el pc ,el codigo ascII aparece el el portb.solo es una forma se saber que el pic esta funcionando.
-
porfavor aclarame lo del trisc,no lo entiendo.
Fíjate en el datasheet. En los 16F ambos bits del tris deben estar en 1 para que sean configurados como "pines de usart". Esto no es así en los 18F.
Saludos
-
con mi ingles-indio.me ha parecido ver que es asi.pero a mi me esta funcionando el tx y el rx.claro que no se si en el tiempo de ejecucion,pudiera tener algun conficto con otros sistemas perifericos integrados.
realmente que sistema puede influir el el incorrecto funcionamiento al dejar los bits,como los tengo?.solo por curiosidad. y ganas de aprender ,por supuesto.
-
realmente que sistema puede influir el el incorrecto funcionamiento al dejar los bits,como los tengo?.solo por curiosidad. y ganas de aprender ,por supuesto.
La verdad no lo he probado de la forma 'mal', simplemente hago caso a lo que dice le fabricante.
En este punto, de los bits del TRISC<7:6> es muy insistente en todas las datasheet de los 16F, en las notas de aplicacion y en su foro.
No hay detalles de qué puede funcionar mal o no, ya que sería conocer cómo es la microelectrónica del PIC pero sí te puedo confirmar que es un tema bastante conocido del cual jamás vi indicación en contrario como para hacer o recomendar un seteo como lo haces tu.
En los 18F sí es así como dices, pero los 18F son otra arquitectura.
Saludos
-
bueno pues todo bien,he logrado comunicar un gps,el holux gr236bt por el puerto serie al pic a 38400.para eso he tenido que poner al pic un crystal de 3.579545MHz
que es el que tenia a mano,pero ya le pondre el sullo de 3.6864MHzpara que tenga menor margen de error.
luego he hecho un pequeño programa para que me localize la sentencia NMEA que me interesa.y funciona,ahora me queda coger la parte de la latitud y longitud,para meter los datos en los registros de proposito general.y luego leerlos con un lcd.
vamos a ver cuanto me cuesta. :-)
-
groundman, me pone muy contento que lo estes haciendo andar... y ya ves que el cristal no es lo más importante... lo más importante es tu código. :mrgreen: :mrgreen:
-
hola de nuevo maunix.
por un tiempo he tenido que dejar medio parado el proyecto.por motivos de tiempo,y aunque el cristal de 3.579545 Mhz funciono.pedi el de 3.6864 Mhz.
asi supongo que ira mejor.
de todos modos esos problemas ya no los tengo,pero tengo otros un poco mas gordos,porque no se pa donde tirar.
el problema es el siguiente:
veras,tengo comunicacion desde el hiperterminal al pic,y desde el gps al hiperterminal,y todo va correcto.
he hecho un programa que busca las siguientes pulsaciones de tecla del ordenador ,son: $GPGGA,XXXXXXXXXX,NNNNNNNNN,X,NNNNNNNNNN,,,,,,,,,,,,
para luego visualizarlos en un display.
donde N son las coordenadas de longitud y latitud, el $GPGGA es el comando NMEA como tu ya sabes,y las comas son para que el programa las detecte del gps,y el pic vuelva a buscar de nuevo el siguiente comando.
este programa solo busca este comando ya que contiene los unicos datos que me hacen falta para el proyecto.
ahora bien,cuando yo tecleo estos caracteres desde el hiperterminal ,simulando que fueran los que el gps saca por tx,hacia el pic.
en el display salen perfectamente;
pero si lo que hago es conectar la salida tx al pic,para que salga los datos por el display.entonces no sale nada.
es como si los datos que proporciona el gps,no fueran los mismos que se ven en el hiperterminal.
mi pregunta es:
son realmente las tramas que proporciona el gps,igual que las que lee el hiperterminal? o hay algun caracter de control entre caracteres que envia el gps?
como si $GPGGA fuera $xGxPxGxGxAx,x......etc. o $$GGPPGGGGAA,, ? no se que pensar. :(
-
hola.he hecho un circuito que manda por tx los siguientes datos en ascii
$GPGGA,220396.000,3914.1575,N,00440.7307,W,1,05,4.6,261.2,M,49.4,M,,0000*40
y si lo conexto al al pictrainer por rx del pic,los datos me salen por el display.
pero si conecto el tx del gps al pictrainer,no sale nada.
bueno,voy ha hacer mas pruevas ya que la trama escrita arriva va en orden,y como el gps entrega los datos en serie todos mezclados;
a lo mejor ese es el problema.voy a probar.
-
definitivamente,no se lo que pasa.he metido esta trama en el pic emisor 4$GPGGA,220396.000,3914.1575,N,................
al pictrainer que tengo el pic receptor.
y efectivamente el programa que he desarrollado funciona a la perfeccion,no ha tenido en cuenta el 4 que va delante de $.
ya que este lo que busca solo son las tramas que empiezan por $GPGGA ,pero no funciona al leer las tramas del gps.
o los caracteres que envia el gps al hiperterminal,aunque los veamos como$GPGGA,no sean caracteres ASCII que pertenezcan a las tablas standar o no se lo que pasa.
-
groundman a ver si te entiendo.
Cuando conectas el PC al GPS, ves en el hyperterminal lo que se envía al GPS , pero cuando conectas el PIC a la PC y "simulas con el hiperterminal" que eres el GPS, no sale nada? ¿Es esta tu duda?
-
bueno realmente lo que veo el el hiperterminal son las tramas que envia el gps.
ejem. $GPGGA,143748.808,3345.1464,N,00457.6333,W,0,00,,234.6,M,49.4,M,,0000*626383,W,..............
y cuando simulo con el hiper al gps.el pic si recive las tramas.
es mas he hecho un cicuito que simula un gps,y este envia las tramas a otro circuito que las recive y va perfectamente.
el problema esta cuando conecto el gps al circuito que las recibe.que no reconoce las tramas.
no entiendo como no funciona, si los caracteres son los mismos.o almenos son los que veo en el hiperterminal. :?
-
el problema esta cuando conecto el gps al circuito que las recibe.que no reconoce las tramas.
¿podrias subir un gráfico simple de como es la interconexión de los dispositivos? realmente estoy mareado :?
no entiendo como no funciona, si los caracteres son los mismos.o almenos son los que veo en el hiperterminal. :?
Tal vez haya algún retorno de carro , un retorno de línea o ambos que faltan en uno u otro. Esto no lo puedes ver con el hyperterminal porque es un editor solo ascii y los caracteres mencionados lo que hacen es ir a la linea siguiente.
Saludos
-
ok.haber si soluciono un problema que se me ha presentado,y lo pongo un poco mas claro.
es que resulta que en el programa.tengo en parte estas lineas:
KEY_TABLA
movf KEY_1,W
addwf PCL,F
retlw "$"
retlw "G"
retlw "P"
retlw "G"
retlw "G"
retlw "A"
y se ve que si salto con un call a esta direccion,desde una direccion de mas de 255 bytes.
al guardar en el SP la direccion de retorno.
el programa me salta a una direccion que no le corresponde,como soluciono esto?.
-
BUENO,YA LO HE SOLUCIONADO CON ESTO:
SECTOR_000 MACRO
BCF PCLATH,0
BCF PCLATH,1
ENDM
SECTOR_100 MACRO
BSF PCLATH,0
BCF PCLATH,1
ENDM
SECTOR_200 MACR
BCF PCLATH,0
BSF PCLATH,1
ENDM
SECTOR_300 MACRO
BSF PCLATH,0
BSF PCLATH,1
ENDM
se ve que aunque no salgamos de la pagina 0 o 1 o la que sea,si se modifica el pcl,como este solo abarca 255 direcciones.
pues hay que conmutar los 4 sectores de la pagina donde estemos. :lol:
-
despues de muchas comprobaciones he descartado que el fallo fuera el codigo.
he comprovado con el osciloscopio las señales,y creo que el fallo esta en que la salida de datos del gps,es de 3v.y puede ser que al tener un valor inferior a 5v.
pues el pic lo interpreta como un 0 logico.y por eso no lee na del gps.
tendre que buscar algun circuito para adaptar la señal.y entonces probar. :)
-
por finnnnnn. :-/ :D :-/ :D :-/ :D :-/ :D
ya he logrado que las coordenadas del gps se visualicen en un display.
era eso ,la adaptacion de las señales.
he utilizado el 7432 un CI de 4 puertas or ,con las dos entradas juntas.y me pasado los 3v de la entrada a los 5v que necesito a la salida para que el pic,detecte la señal por la entrada de la usart.
haber si lo saco con un transistor,para reducir tamaño en el circuito.
quizas parezca que estoy loco,por contestarme a mi mismo.pero lo hago para que los demas aprendan algo de mis errores.
saludos.
-
Bueno , me alegro, has posteado todo tu solo , no me has dado tiempo a responder jaja.
Lo importante es que te funcione bien.
Saludos!
-
ya,es que solo tengo los sabados y domingos para programar.y claro entiendo que cada uno tiene su tiempo para si mismo y para hacer lo que mas le gusta.
y no quiero quitarle el tiempo a ninguna persona,ni forzar a nadie a que me contesten.
aunque si no fuera por gente como tu,quizas los demas no avanzariamos tan rapido.
la verdad que tienes que estar muy abanzado en programacion de microcontroladores.yo no paso del 16f84 16f876 y 16f877.
y por eso muy pocas vezes respondo a gente que necesita ayuda,por no mandarles por camino equivocado,a no ser que nadie les responda,entonces si suelo intervenir.aconsejandoles lo mas correctamente posible.
mientras que en mis proyectos no necesite mayores requisitos de funcionalidad,quiero profundizar en esta gama de microcontroladores.
si en un futuro tengo que ampliar,entonces me ire a los 18f o superiores.porque ahora mismo no se casi nada de estos.
-
de eso se trata amigo groundman, que tu hagas el esfuerzo y que 'nosotros' (los del foro) te echemos una luz para indicarte el rumbo a seguir.
De esa forma ahorras muchiiiiiiiisimo tiempo y vas en el camino correcto (por supuesto , esto requiere que confíes en lo que te decimos).
La confianza lleva tiempo lograrla y bueno, al principio puede que se dude de lo que te digan pero cuando compruebas que estaban en lo correcto te da más ánimo y ganas de oir los consejos de esa persona.
Creo que me hubiera gustado tener un mentor que me guíe en mis pasos, la verdad tuve que equivocarme solo... por no tenerlo y solo espero evitarle las penurias de perder tiempo yendo por el camino equivocado.
:) :)
-
hola maunix,por eso me gustaria poner esta parte del proyecto en algun sitio ,para que quien quiera montarselo o ver el programa ,aprenda algo de lo que he hecho.
ya que no he visto en este foro nada relacionado con visualizar las coordenadas de un gps en un display.
aun sabiendo que hay usuarios mas avanzados que yo.
la verdad no lo entiendo.je je .me hubiera benido bien.
cuando lo limpie un poco,lo posteare en un nuevo tema. en proyectos,o hay otra forma mejor?
saludos.
este es el enlace al proyecto:http://www.todopic.com.ar/foros/index.php?topic=17786.0
-
la verdad no lo entiendo.je je .me hubiera benido bien.
¿Qué es lo que no entiendes? No comprendo a que te refieres
cuando lo limpie un poco,lo posteare en un nuevo tema. en proyectos,o hay otra forma mejor?
Creo que en proyecto está más que bien. :)