TODOPIC
Microcontroladores PIC => Lenguaje C para microcontroladores PIC => Mensaje iniciado por: Automata78 en 10 de Enero de 2007, 16:44:01
-
Hola a todos !! quería comentarles que he establecido una relativa comunicación entre el PIC 16f628 y la compu !.., lo de relativo es porque cuando le envio un comando de lectura ( de acuerdo a mi protocolo sería .200, .1, .1) y el PIC me responde con: .200 .1 .1 .0 .0 .0 .0 .0 .0 .0 .0 ..... .0; como verán, he recibido los mísmos "datos" que le envié al PIC además de los datos que este lee de la eeprom, que son 35 posiciones de memoria ( que se encuentran almacenando el valor 0 ) !
La cuestión es que no entiendo porqué me devuelve los comando de lectura si en mi código núnca programé algo como:
putc(getc()); o algo por el estilo que devolviera al PC lo que este le envió al pic !
Otra cosa importante es que tengo habilitada la interrupcion del puerto serie cuando este recibe algún dato, además, en el momento que se provocó esta interrupción hago lo siguiente : Dato_recibido = getc();, y utilizo esta variable para lo que yo necesite !!!
El programa de la compu lo programé con builder c++ y el componente comm32. Este componente permite mediante el evento en que el buffer de transmición esté vacio, cosa que yo uso para asegurarme que salieron todos los datos !!!
1) Puede que las funciones getc(), fgetc(), al momento de recibir el dato lo retransmitan al TXREG por defecto ??
2) Puede ser que deba generar algún retardo en el PIC en el momento de recibir a pasar a transmitir ????
Realice una contra prueba con la PC y una calculadora HP 48 GX y el proceso se lleva a cabo sin ninguna anomalía, el PC envia el comando de lectura (.200 .1 .1) y recibe por parte de la HP 48 los valores almacenados, o sea, no volvio a retransmitir el comando de lectura !!!
Se que escribir todo esto es un quebradero de cabeza, pero la verdad que me tiene desconcertado !!!
aquí le dejo parte del código, desde ya muchas gracias !!!!
/////////////////////////////// INT_RS232 //////////////////////////////////////
#int_RDA
void RDA_isr()
{
//*************************************************************************************
//
// El PROTOCOLO ES EL SIGUIENTE :
// 1) EL BYTE DE START ES EL .200
// 2) ES EL BYTE QUE CONTIENE EL NUMERO DE BYTE QUE SERAN ENVIADO POR EL PC AL PIC
// 3) ES EL BYTE QUE CONTIENE LA ACCION A REALIZAR
// a) SI EL BYTE ES .1 : LA ACCION ES UNA LECTURA DE PARAMETROS Y CODIGOS DE ERROR !
// b) SI EL BYTE ES .2 : LA ACCION ES UNA ESCRITURA DE PARAMETROS!
// c) SI EL BTYE ES .3 : LA ACCION ES BORRADO DE LOS CODIGOS DE ERROR !
//
// SI EL 3º BYTE ES .2 (ESCRITURA)
// 4) ESTE BYTE PERTENECE AL VALOR PWM_ON !
// 5) ESTE BYTE PERTENECE AL VALOR PWM_OFF !
// 6) ESTE BYTE PERTENECE AL VALOR DE ACTIVACION DEL PWM !
// 7) ESTE BYTE SERÁ DE VALOR '0' (CERO), INDICA FINAL DE LA TRAMA !
//
//*************************************************************************************
Dato_recib = getc();
if(bit_test(Status,Bit_Strt)) //Todavía no se detectó el byte de Start ???
{
if(bit_test(Status2,Bit_Get)) //Ya había ingresado el 2º byte ???
{
if(bit_test(Status,Bit_Escr)) // Está activo este flag ?
{
//"ESCRITURA"
ESCRIBIR_PARAM();
}
else
{
if(Dato_recib == 1) // Lo que se hará a continuacion es una LECTRUA ??
{
// " LECTURA "
delay_ms(1000); // Aquí agregue un retardo de un segundo, pero desde la PC llegaron (.200 .1 .1) en el
LEER_CODE(); // instante siguiente de dar la orden de lectura, justo un segundo mas tarde "delay_ms(1000)
// llegaron los datos leidos por el PIC al la PC !!!
}
else
{
if(Dato_recib == 3) // Lo que se hará a continuación es un BORRADO ??
{
// "BORRAR "
BORRAR_EEPROM();
}
else
{
if(Dato_recib == 2)
{
bit_set(Status,Bit_Escr);
}
else
{
//Como no fue ningunas de las opciones posibles reinicio los flag's
Ini_P_Serie(); // Inicializo las variables dedicadas a la comunicación Serie !!
}
}
}
}
}
else
{
N_Datos = Dato_recib; //Leo es 2º byte y lo almaceno en N_Datos !!!
bit_set(Status2,Bit_Get); //Coloco en 1 este bit, indicando que ya ingresó el 2º byte !!
}
}
else
{
if( Dato_recib == 200 ) //Es el byte de START ??
{
Ini_P_Serie();
bit_set(Status,Bit_Strt); //Coloco este bit a uno, indicando que se detectó el byte de START !!
}
}
}
///////////////////////////////////////////////////////////////////////////////////////
-
Intenta asegurarte de que tienes un byte recibido esperando ser descargado de la USART. Esto puedes, y debes, hacerlo con kbhit() en la forma
#int_RDA
void RDA_isr()
{
Dato_recib = 0x00;
if(kbhit()){
Dato_recib = getc();
//El resto de tu código tal como está
}
}
Prueba y nos cuentas.
-
Hola RedPic y gracias por tu respuesta !!!
Probé hacer lo que me sugeriste... pero no dio resultado.. sigue con el mismo problema.
Quería agregar que cuando estoy fuera de la interrupción hasta espererar el siguiente dato, no hay ninguna instrucción que tenga que ver con el puerto serie, por lo que no entiendo cual será la causa de este problema,... mas allá de este "defectito" el pic responde a los comandos de lectura, escritura y borrado de la eeprom !!!!
Yo voy a seguir buscando en el código, ahh... voy a probar con desactivar el wdt, a lo mejor hace algo ... bueno, no se... je je je ... cualquier aporte será bien venido !!
Muchas gracias RedPic !!! ta lueguito !
-
Ahh .... quería agregar que no estoy utilizando cristal, estoy utilizando el oscilador interno configurado en 4 MHZ !! Por si puede servir para algo !! muchas gracia !!!!
-
Entonces ponle el oscilador o cristal de 4 Mhz externo, el oscilador interno no es apto para comunicaciones ya que varia demasiado por temperatura, haciendo que varien mucho los tiempos de bit, lo cual hace que no sean confiables las comunicaciones... :P :P
Cual es la velocidad de comunicaciones que usas???
No lo veo en el codigo que subiste...
-
Hola MGLSOFT !!.... te cuento... la comunicación se realiza de lo mas bien, el problema es que si yo le envio por ejemplo un '1' a travez del puerto serie al pic, este me responde '1' cuando en ningún lugar de mi programa del pic indico que me reenvie el dato que entró. al puerto serie lo tengo configurado así :
#include <16F628.h>
#use delay(clock=4000000) //#use delay(clock=4000000,RESTART_WDT)
#fuses NOWDT,INTRC_IO, PUT, NOPROTECT, BROWNOUT, NOMCLR, NOLVP, NOCPD
#use rs232(baud=1200,parity=N,xmit=PIN_B2,rcv=PIN_B1)
Lo configuré a 1200 baudios para disminuir la probabilidad de falla, aunque tambien lo he usado a 9600 sin ningún problema, salvo el que estoy exponiendo en este mensaje !! :-)
En definitiva, el pic reacciona a las "ordenes" que le envio a travez del puerto serie, pero me reenvia todo byte que le envio !!!
Te dejo el código mas sencillo para ver si salta algo !!
gracias !!
#include <16F628.h>
#use delay(clock=4000000) //#use delay(clock=4000000,RESTART_WDT)
#fuses NOWDT,INTRC_IO, PUT, NOPROTECT, BROWNOUT, NOMCLR, NOLVP, NOCPD
#use rs232(baud=1200,parity=N,xmit=PIN_B2,rcv=PIN_B1)
//-------------------------------------------------------------------------------//
#BYTE PORTA = 0X05
#BYTE PORTB = 0X06
#BYTE STAT = 0X03
#define RP0 5
#define RP1 6
#BYTE EEDATA = 0X9A
#BYTE EEADR = 0X9B
#BYTE EECON1 = 0X9C
#define RD 0
byte Dato_recib;
////////////////////////////////////////////////////////////////////////////////
/////////////////////////////// INT_RS232 //////////////////////////////////////
#int_RDA
void RDA_isr()
{
//*************************************************************************************
//
// ESTA FUNCION SE ENCARGA DE LEER DEL PUERTO PARAMETROS COMO POR EJEMPLO
// : EL duty up_pwm; ciclo down_pwm; tiempo de activacion del PWM, Y TAMBIEN
// DEVELVE ESTOS PARAMETROS Y LOS CODIGOS CORRESPONDIENTES A LOS ERRORES
// DETECTADO POR EL SISTEMA !!
//
//
// El PROTOCOLO ES EL SIGUIENTE :
// 1) EL BYTE DE START ES EL .200
// 2) ES EL BYTE QUE CONTIENE EL NUMERO DE BYTE QUE SERAN ENVIADO POR EL PC AL PIC
// 3) ES EL BYTE QUE CONTIENE LA ACCION A REALIZAR
// a) SI EL BYTE ES .1 : LA ACCION ES UNA LECTURA DE PARAMETROS Y CODIGOS DE ERROR !
// b) SI EL BYTE ES .2 : LA ACCION ES UNA ESCRITURA DE PARAMETROS!
// c) SI EL BTYE ES .3 : LA ACCION ES BORRADO DE LOS CODIGOS DE ERROR !
//
// SI EL 3º BYTE ES .2 (ESCRITURA)
// 4) ESTE BYTE PERTENECE AL VALOR PWM_ON !
// 5) ESTE BYTE PERTENECE AL VALOR PWM_OFF !
// 6) ESTE BYTE PERTENECE AL VALOR DE ACTIVACION DEL PWM !
// 7) ESTE BYTE SERÁ DE VALOR '0' (CERO), INDICA FINAL DE LA TRAMA !
//
//*************************************************************************************
Dato_recib = 0;
if(kbhit())
{
Dato_recib = getc(); //Aquí siempre se guarda el dato, y no se hace nada con él ! ... pero como dije antes, el dato que
//recibido no se como pero sale por el puerto del pic !!!
}
}
///////////////////////////////////////////////////////////////////////////////////////
void main()
{
PORTA=0;
PORTB=0;
set_tris_A(0b00111100); //Configuro los pines del puerto A
set_tris_B(0b00001011); //Configuro los pines del puerto B
PORTA=0b00000011; // Inicio apagando el motor !!
PORTB=0b00110000;
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
disable_interrupts(INT_EXT);
disable_interrupts(INT_TBE);
enable_interrupts(INT_RDA);
enable_interrupts(GLOBAL);
Dato_recib = 0;
//***************************************************************************//
// Aquí chequeo los sensores de: //
// - Corriente máximas. //
// - Tension mínimas. //
//***************************************************************************//
while(TRUE)
{
//Aquí no hago nada, solo veo lo que hace la interrupcion !
}
}
-
Bueno, empezamos:
Yo tambien tengo el mismo problema y creo que es debido a la función getch() si te fijas este devuelve un caracter y no um byte como tienes puesto en:
byte Dato_recib;
Dato_recib = getc();
Con lo que posiblemente tengas mierda por detrás de lo enviado o incluso directamente no lo pueda pasar de un char a un byte, ya que un byte es un unsignedchar.
Después tienes que configurar el COM para que tenga los mismos parámatros que pones en el programa del PIC.
Otra es que te falta poner la longitud de la trama que envias:
#use rs232(baud=19200, xmit=PIN_C6, rcv=PIN_C7,PARITY=N,BITS=8)
La verdad es que yo estoy como tú y toavía no lo he conseguido corregir, así que si lo consigues o avanzas un poco más postea de nuevo y te doy nuevas ideas desde mi experiencia.
Te recomiendo que quites todas las sentencias de PWM e interrupciones para que pruebes sólo la comunicación, porque muchas veces puede ser que al poner funciones y demás puede que habilites o deshabilites cosas que no ves en el código, prueba con algo tan sencillo como esto pero adaptado a tu pic:
#include <18F4550.h>
#fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,PLL3,CPUDIV1,VREGEN
#use delay(clock=12000000)
#define use_portb_lcd TRUE //definir portb lcd
#include<lcd.c>
#use rs232(baud=19200, xmit=PIN_C6, rcv=PIN_C7,PARITY=N,BITS=8) //Hay que ponerlo debajo de la instrucción de LCD sino el LCD
char crecibido='0';
void main(void) {
lcd_init();
printf(lcd_putc,"ESPERANDO DATOS");
while (TRUE)
{
if (kbhit()) //si el endpoint de salida contiene datos del host
{
crecibido=getc();
lcd_putc("\f");//LCD en blanco
printf(LCD_PUTC,"RECIBIDO");
printf(LCD_PUTC," %C",crecibido);
putc(crecibido);//Envia al PC un caracter
if(crecibido=='0')
{
printf(LCD_PUTC," DATOS");
puts("g");//Envia al PC una cadena de caracteres
}
else
{
printf(LCD_PUTC," OK");
puts("h");
}
}
}
}
-
Hola c4_esp_VR y a todos los demás !... les tengo que decir que probé hasta instalar una de las últimas versiones de ccs 4.018 y el problema persistió, .... hasta que me cansé y utilicé un programita hecho en assembler y saben una cosa ... hizo exactamente lo mismo de siempre !.... Primero el pic envia un mensaje en el momento de encenderlo que dice " 16f628 live ! " y luego espera a que llegue un dato al RCREG para luego enviarlo .... por lo que cuando le envio un dato no lo recibo solo una vez si no, dos veces !! je je je .... esto me vuela la cabeza... no entiendo porqué hace esto !!
aquí les dejo el código !
;*******************************************************************
; Function: Sends alive message, then echoes characters at 9600 bps
; Processor: PIC16F628 at 4 MHz using internal RC oscillator
; Hardware: Testboard K4
; Filename: 628uart.asm
; Author: Lars Petersen, oz1bxm@qsl.net
; Website: www.qsl.net/oz1bxm/PIC/pic.htm
; Credit: Tony Nixon's test program at
; www.piclist.com/techref/microchip/16f877/setup.htm
;*******************************************************************
LIST P=16F628, R=DEC ; Use the PIC16F628 and decimal system
#include "P16F628.INC" ; Include header file
__config _INTRC_OSC_NOCLKOUT & _LVP_OFF & _WDT_OFF & _PWRTE_ON & _BODEN_ON
CBLOCK 0x20 ; Declare variable addresses starting at 0x20
dataL
ENDC
ORG 0x000 ; Program starts at 0x000
;
; --------------------------------
; SET ANALOG/DIGITAL INPUTS PORT A
; --------------------------------
;
bcf STATUS,RP0
bcf STATUS,RP1
movlw 7
movwf CMCON ; CMCON=7 set comperators off
;
; ----------------
; INITIALIZE PORTS
; ----------------
;
movlw b'00000000' ; set up portA
movwf PORTA
movlw b'00000100' ; RB2(TX)=1 others are 0
movwf PORTB
bsf STATUS,RP0 ; RAM PAGE 1
movlw b'00111100'
movwf TRISA ; portA all pins input
movlw b'00001011' ; RB7-RB4 and RB1(RX)=input, others output
movwf TRISB
; ------------------------------------
; SET BAUD RATE TO COMMUNICATE WITH PC
; ------------------------------------
; Boot Baud Rate = 9600, No Parity, 1 Stop Bit
;
movlw 0x19 ; 0x19=9600 bps (0x0C=19200 bps)
movwf SPBRG
movlw b'00100100' ; brgh = high (2)
movwf TXSTA ; enable Async Transmission, set brgh
bcf STATUS,RP0 ; RAM PAGE 0
movlw b'10010000' ; enable Async Reception
movwf RCSTA
;
; ------------------------------------
; PROVIDE A SETTLING TIME FOR START UP
; ------------------------------------
;
clrf dataL
settle
decfsz dataL,F
goto settle
movf RCREG,W
movf RCREG,W
movf RCREG,W ; flush receive buffer
;
; ---------
; MAIN LOOP
; ---------
;
call message ; send "16F628 alive"
loop call receive ; wait for a char
call send ; send the char
goto loop
;
; -------------------------------------------
; RECEIVE CHARACTER FROM RS232 AND STORE IN W
; -------------------------------------------
; This routine does not return until a character is received.
;
receive btfss PIR1,RCIF ; (5) check for received data
goto receive
movf RCREG,W ; save received data in W
return
;
; -------------------------------------------------------------
; SEND CHARACTER IN W VIA RS232 AND WAIT UNTIL FINISHED SENDING
; -------------------------------------------------------------
;
send movwf TXREG ; send data in W
TransWt bsf STATUS,RP0 ; RAM PAGE 1
WtHere btfss TXSTA,TRMT ; (1) transmission is complete if hi
goto WtHere
bcf STATUS,RP0 ; RAM PAGE 0
return
;
; -------
; MESSAGE
; -------
;
message
movlw '1'
call send
movlw '6'
call send
movlw 'F'
call send
movlw '6'
call send
movlw '2'
call send
movlw '8'
call send
movlw ' '
call send
movlw 'a'
call send
movlw 'l'
call send
movlw 'i'
call send
movlw 'v'
call send
movlw 'e'
call send
movlw 0x0D ; CR
call send
movlw 0x0A ; LF
call send
return
END
Gracias a todos.....seguiré investigando !... y hasta el momento no he encontrado nada que explique esto en los datasheet !
Saludos
-
Hola, no tendras el echo local activado en el programa con que envias?, aca te pego un ejemplo muy sencilo que envia lo que recibe.
Por lo que entiendo, envias dos caracteres . y 200 (.200), cualquier duda a tus ordenes.
#USE RS232(BAUD=9600, XMIT=PIN_B0, RCV=PIN_B1)
main() {
char c;
printf("Conectado...\n\r");
while(TRUE) {
c = getc();
putc(c);
}
}
-
Hola Pikman ! gracias por ponerte en contacto !! .... disculpa mi ignorancia.., pero que es el "echo local " ? No tengo muy enclaro que eventos se producen antes, durante y después de una comunicación serial, .. si no te entendí mal el "echo local" sería parte de la configuración del puerto serie en la pc, no?
Pero de todas maneras me gustaría si es posible me explicaras un poquito de ese tema !
Te recuerdo que el fin de mi sistema es: la pc envia una orden de lectura y el pic lee la eeprom y responde con lo leido!
Mi problema a resolver es: que el PIC no me reenvie (que no me haga eco) de cada byte que la pc envia al pic !
Muchas gracias !!
-
Hola Automata78, disculpas esta bien me equivoque pense que pretendias que el PIC hiciera echo de lo que enviabas a desde la PC, si estas usando hyperterminal, por ejemplo podes tener activado el echo local lo que significa que ves los carateres tipeados, pero este no es tu problema.
Cuando definis los bytes de tu trama incluis un punto adelante, .200,.0 etc, tambien definis un cero (0) como carater de fin de trama, este me imagino que no lleva punto adelante si no vas a tener que tomarte el trabajo de ir contado los bytes recibidos y ver si es la cantidad y es =0 para saber que la trama se recibio, aqui justamente esta el error de tu programa, como recomendacion deberias recibir la trama completa y despues examinar cada caracter para ver que haces despues, usando un buffer, este debera tener la cantidad de caracteres completos de la trama, osea 13, porque .200 no es un byte son dos uno el punto y otro 200, y como no estoy seguro si el ultimo cero es precedido por . digo que son 13 carateres 7 bytes y 6 de los puntos, no se si es correcta mi interpretacion.
El programa en asm deberia hacer lo mismo que el programa que te pegue yo, cuando arranca envia el string pic16f628 alive y despues cada carater que recive lo envia de nuevo a la PC, por lo tanto no esta mal.
-
Hola Pikman !... te cuento que los puntos (.) fue un error de mi parte al escribirlos en estos textos !!!!!!
Todos los valores que expuse en los mensajes anteriores como .200 o .0 eran en realidad 200 o 0 respectivamente !!!
Yo me pregunto si existe alguna posibilidad de que este modelo de pic con oscilador interno a 4 Mhz 16f628 funcione de esta manera ya que tengo otro pic 16f628 y hace exactamente lo mismo !!!
Pido mil disculpas por poner información que dió lugar a un mal entendido. !!!!
Saludos !
-
Automata78 , bueno, entonces deberias alamacenar la trama de datos y despues analizar los bytes para ejecutar un comando, ademas si por ejemplo tu idea es ajustar el PWM con datos serie, no olvides que recibiras datos ascii, de cualquier manera proba lo siguiente, lo que hace es recibir 7 caracteres y esperar que pulses enter, luego imprime en pantalla la cadena recibida, de esta manera podras corroborar que el pic no envia lo que recibe.
Usar el oscilador interno puede traer problemas en este modelo, pues no es de lo mas estable, hay algunos modelos con UART con oscilador propio de alta precision, en todo caso te recomiendo hacer las pruebas con un cristal.
char trama[7];
do{
printf("Bienvenido al Test del 16F628, ingrese 7 carateres y presione enter");
gets(trama);
printf("%s",trama);
}while(1)
-
Hola pikman !! ... te cuento lo que sucede paso por paso cuando le envio cada dato (byte) por el serie al pic con el código que me pasaste utilizando la herramienta de comunicación serial (Serial Port Monitor) que trae el CCS version 4.013.
Ingreso por ejemplo el 01 (este es un nº hexadecimal que corresponde a 1 en decimal ) y sin esperar a que envie los siete datos (bytes) y presionar Enter, el pic me va "contestando" cada dato practicamente de forma instantanea, cosa que no debería ocurrir hasta completar los siete datos y la tecla enter ! no se así ????
Evidentemente el problema de este pic no es si llega el dato correctamente o no, (en mi caso esto se logra satisfactoriamente) si no, el problema se evidencia cuando el pic recibe un dato por el puerto serie y automaticamente lo reenvia por este al exterior sin que exista una instrucción que así se lo ordene, como ser "putc(dato);"
Comento además que he simulado el código con el Mplab V7.5 y anda de maravilla, pero lamentablemente en la realidad no sucede lo mísmo !! :(
Otra cosa, es que antes de comunicarme con el PIC deshabilito el LOCAL ECHO !!!
MUCHACHOS .... SE ME QUEMARON LOS PAPELES !!!!! :(
-
Hola, Automata78, pues no, el codigo que yo te pegue no devuelve nada hasta que no presiones enter, subi todo el codigo tal cual lo compilas, a ver donde puede estar el error.
-
Hola Pikman... y nuevamente muchas gracias por tomarte la molestia de ayudarme !!
aquí te cuelgo el codigo;
//"PRUEBA.H"
//***************************************************************************************************
#include <16F628.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES INTRC //Internal RC Osc
#FUSES NOPUT //No Power Up Timer
#FUSES NOPROTECT //Code not protected from reading
#FUSES BROWNOUT //Reset when brownout detected
#FUSES NOMCLR //Master Clear pin used for I/O
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOCPD //No EE protection
#use delay(clock=4000000)
#use rs232(baud=1200,parity=N,xmit=PIN_B2,rcv=PIN_B1,bits=8)
//***************************************************************************************************
//***************************************************************************************************
//"PRUEBA.C"
//***************************************************************************************************
#include "F:\Documents and Settings\Carlos\Escritorio\drer2\Nueva carpeta\prueba.h"
#byte PORTA = 0x05
#byte PORTB = 0x06
char trama[7];
void main()
{
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
// TODO: USER CODE!!
PORTA=0;
PORTB=0;
set_tris_A(0b00111100); //Configuro los pines del puerto A
set_tris_B(0b00001011); //Configuro los pines del puerto B
PORTA=0b00000011; // Inicio apagando el motor !!
PORTB=0b00110000;
do{
printf("Bienvenido al Test del 16F628, ingrese 7 carateres y presione enter");
gets(trama);
printf("%s",trama);
}while(TRUE);
}
Este es el programita, espero que encuentres algo !!! :? je je je
Muchas gracias por todo ! nos escribimos !!!!
-
Bueno, no hay problemas, lo voy probar, pero hay algo que no se para que usas,
set_tris_A(0b00111100); //Configuro los pines del puerto A
set_tris_B(0b00001011); //Configuro los pines del puerto B
Si queres usar esto deberias incluir la directiva #use fast_io
-
Hola gente !!! te cuento pikman, corregí ese error del #use fast_io , pero lamentablemente sigue sin funcionar correctamente !
Les cuento lo que hice para descartar posibles fuentes de problemas:
1- realicé el circuito en un protoboard donde utilice en este caso un cristal de 4mhz con sus correspondientes capacitores.
2- utilicé tres pic 16f628 para comprobar si era una falla del micro, ya que el primero que estaba usando era una muestra gratis de microchip, el segundo era otra muestra gratis y el tercero es uno que compré en una tienda de electronica !!!!
!!!! Pero todos con el mismo resultado !!!!! sigue haciendo lo mismo !
Pikman, probaste el código que te he posteado en algun 16f628 ?
La designación del pic que tengo en este momento (el que compré) es : PIC16F628-20/P y los de las muestras gratis eran : PIC16F628-20 I/P
gracias !!!!
-
Automata78, estoy un poco complicado con el trabajo pero voy a probarlo en cuanto pueda te comento que pasa.
-
PROBLEMA SOLUCIONADOOOO !!!!!!!!!!! :-/ :-/ :-/ :-/ :mrgreen: :D :-) JE JE JE !!!
Les cuento un chiste !!!.... había una vez un hombre que era medio hipocondríaco je je je ... un día llendo en moto tiene un buen golpe en un accidente !!! .... el hombre abre los ojos y se comienza a tocar todo el cuerpo dintiendo un gran dolor por donde se tocara, una ambulancia lo lleva al hospital, una vez allí el médico comienza a hacer el chequeo del estado del hombre, y este le decia que se tocaba en el brazo y le dolia, se tocaba, je je .. le dolía todo el cuerpo .. je je je .. el médico lo miró y simplemente le dijo ....... ¡¡¡¡ hombre usted solo tiene quebrado el dedo con que se toca el cuerpo !!!! jua jua jua jua !!!!! :mrgreen: :shock:
Bueno, para todos aquellos que se acercaron a leer estos mensajes les dejé este chiste un poco malo como para dejar una moraleja !!!!
¡¡¡¡¡ Si ustedes prueban con distintas versiones de compiladores C, lo mismo con el mplab, como así también con distintos modelos de micros y la comunicación no parece andar como debiera ..... prendan fuego el circuito que se encuentra en la página de "pablin" porque no anda ... este circuito como confusamente dice en ese sitio, que reemplaza al MAX232, despues de insistir con tantas cosas me hice una simple pregunta, ¿ No será que el dato que le estoy enviando al pin receptor del pic se le esté "escurriendo" por las resitencias y reenviado al PC sin que el pic se entere ?.... pues sí, reemplace este circuito por un max232 y todo salió andando como debería haber sucedido hace ya 15 días atras !!!!
Leyendo atentamente lo que dice en esa pagina, decia que es un circuito que muy comunmente se encontraban en los mouse, de ahí que me pregunté si anda ya que el mouse solo envia datos pero no recibe nada (por lo menos los antiguos), por lo que no necesariamente funcione bien para que el pic reciba datos !!!!!
Muchas gracias a todos por ayudarme, no pretendo que se queden con mi experiencia personal, mas adelante cuando tenga un osciloscopio lo voy a probar mas objetivamente !!!!
Nuevamente a Pikman, c4_esp_VR, MGLSOFT, muchas gracias !!!!!!
-
Nunca proble un circuito publicado por 'pablin' parece serio el sitio, pero la verdad tampoco nunca me puse a construir un adaptador rs232-ttl pues existiendo el max232 y lo que vale, de cualquier modo, en una oportunidad escribi un firmware para un equipo que tenia conexion rs-232 y andaba, era para un cliente que por razones de espacio, era un equipo de mano, no puso el max, voy a mirar el circuito, como recomendacion, siempre que tengo una interface la pruebo sola antes de conectar el micro, me alegor que hayas solucionado el problema.
-
Hola pikman !, no descarto que pueda ser algun valor de resistencia que esté justo fuera del umbral del funcionamiento del circuito en sí, ya que no hay mucho para rectocar del circuito !
Ok entonces, espero a ver si me podés facilitar ese circuito !!
Muchas gracias !!! :-/
-
Enhorabuena Automata78, primeramente lo siento porque desgraciadamente no te pude ayudar lo que yo hubiese querido debido al poco tiempo que dispongo (trabajo, examenes...), y segundo me parece estupendo que ya hayas solucionado el tema, a ver si pudes hacer un pequeño tutorial o pdf de todo esto de rs232, del código del pic, del pc y demás, ayudarias a mucha gente a que no tuviese el mismo error...
Un saludete y recuerda que aqui estamos para ayudarnos y hacer lo que podamos :-/ :-/ :-/ :-/ :-/ así que si tienes más dificultades no dudes en postear :-) :-) :-)
-
Hola c4_esp_VR !!!... me pareció buena idea la de confeccionar un pequeño pdf, con mis "andanzas" sobre este tema !!
Quería agregar que he encontrado dos circuitos parecidos a los de "pablin", uno que practicamente igual y el otro algo disnto que fue el que probé y funcionó barbaro !!
El primer circuito, al que hago referencia, la única diferencia con respecto al de "pablin" es que el transistor pnp me parece que está conectado mal, el colector mirando a vcc, de todas formas lo probé y en mi experiencia resultó con los mísmos síntomas extraños que con el que tuve problemas !!!!
Aquí estan los dos circuitos al los que hago referencia !!!!
http://www.tecnotopia.com/content/view/7/2/
El circuito #2 parece andar sin problemas !!!
Volviendo al tema del pdf, cuando disponga de un osciloscopio voy a estudiar cada circuito, y realizar un informe !!
Saludos a todos y estamos en contacto !!
-
Buena idea lo del PDF, pero estoy mirando en cirtuito de pablin y no es dificil darse cuenta que quien lo diseño lo hizo con la intencion de que el mismo produzca echo local, pues si obserban hay una resistencia de 4.7 K puenteando la linea de rx y tx de la entrada rs232, ademas de pensar que quien lo hizo tuvo una razon, sigo pensando que es una verdadera estupidez no haberlo especificado, o que esta hecho con mala intencion, o finalmente el que lo hizo no entiende una papa o lo copio mal, jamas vi un circuito asi en un mouse tampoco.
Automata78, en todo caso preguntale a los de pablin porque publican fruta podrida, lamento que hayas perdido tanto tiempo y me alegro de haberte ayudado, aunque no me fije antes en el circuito porque no me imaginaba semejante calamidad.