desktop

Curso de programación de PIC en PICBasic Pro

entonces al inicio quedaria mas o menos asi:

on interrupt goto programa_2
INTCON = %11010000

programa_1:
..................
..................
goto programa_1


disable
programa_2:
.......................
.......................
......................
INTCON = %11010010
disable
resume

Hola, debe ir asi INTCON = %11010000, ya el bit7 activa interrupciones globales, el bit6 activa interrupciones externas, el bit 4 activa interrupciones por RB0, el detalle seria que el bit1 es el indicador de interrupción externa en RB0, no lo debes tu poner en 1, el bit1 se ponen el solo en alto cuando detecta una interrupción en RB0, lo que necesitas hacer tú sería,es volver a poner a bajo el bit1, para que pueda volver al detectar otra interrupción volver a poner ese en alto.

seria algo asi



programa_2:

Disable ; Desactivar interrupciones.

If INTCON.1 = 1 Then INTCON.1 = 0 ;si el bit.1 de INTCON está en uno, ponerlo a cero

Resume ; Retornar al programa

Enable ; Volver a activar interrupciones.

De este modo vuelve a quedar listo para recibir otra interrupción por RB0
 
Última edición:
muchachos saben como puedo declarar para hacer el envio del resultado de una variable, ya sea en binario decimal o hexadecimal.

ejemplo: tengo declarado esto

numero var byte
NUMERO1 VAR BYTE
NUMERO2 VAR BYTE
NUMERO3 VAR BYTE
NUMERO4 VAR BYTE
-----------------------------
-----------------------------
-----------------------------
-----------------------------
despues de toda la logica me queda:
numero = NUMERO1 + NUMERO2 + NUMERO3 + NUMERO4

estoy tratando de enviar asi:

serout portb.2,n2400,["numero"]

pero nunca logro que llegue el dato, en cambio si envio una letra cualquiera llega.
 
Última edición:
¿Y con qué y cómo recibes el dato?
Si dato es superior a 255 no lo podrás ver completo, necesitas separarlo y enviar MSB y LSB
En RS-232 nada más puedes enviar un Byte, o sea, de 0 a 255.
Y también es importante la forma en que se envía, porque no es lo mismo enviarlo como texto usando Dec, que enviarlo en ASCII. O sea, enviarlo directamente sin conversiones.

Así que... Aunque el dato se envié, nunca lo verás en una interfaz común.
 
Última edición:
Envíalo sin formato, ya después de recibirlo le puedes dar el formato quieras.
Por ejemplo, caso 1 sin formato:
PHP:
    If PORTA.2 = 0 Then
        Numero = 50
        SerOut PORTB.2, T9600, [Numero]
        
        While PORTA.2 = 0: Wend
    
    EndIf
Verás lo siguiente:
Caso 1.jpg
O sea, un 2, que corresponde al decimal 50 de la tabla ASCII.
Eso es enviar un número sin formato y de esa forma habrá números que no se podrán ver si la interfaz va a mostrar lo que reciba cómo texto.

Caso 2, con formato:
PHP:
    If PORTA.2 = 0 Then
        Numero = 50
        SerOut PORTB.2, T9600, [#Numero]
        
        While PORTA.2 = 0: Wend
    
    EndIf
Caso 2.jpg
Aquí ya se ve el número 50, pero se enviaron dos bytes, porque fue enviado cómo texto.
Así que todo depende de la forma en que se manden e interpreten los datos.

No es nada complicado, pero muchas personas batallan con esto.

Edit: Si le quieres dar otro formato, PBP tiene instrucciones para eso.
Por ejemplo: SerOut2 PORTB.2, T9600, [Hex Numero]
O por Hardware: HSerOut [Hex Numero]
Pero por hardware, ya se tiene que configurar el módulo USART.
Con algo así por ejemplo:
PHP:
    ; Configuración USART: (9600 Bps @ 4 MHz. 9615 Bps Reales 0.16% de error.)
    SPBRG =    25    ; 00011001
    TXSTA =    36    ; 00100100
    RCSTA =    144   ; 10010000
A mi en lo personal me gusta usar los registros directamente, pero PBP tiene sus declaraciones.
 
Última edición:
Buenas a todos, despues de tantas pruebas y batallar con la comunicacion rf con pic, obtuve muchas resultados y la mayoria no era lo que esperaba, se torna tedioso al trabajar con modulos rf y el pic, devido a que existe mucho ruido electrico en el ambiente señales de radio, etc que hicieron que el pic actue de forma erronea, segui los consejos y obtuve mejores resultados pero aun con error.

PRUEBAS Y RESULTADOS:

1. se establecio la conexion entre los 2 pic: TX usando las instrucciones SERIN, enviando datos todo el tiempo mientres se pulse o no, esto debido a que si se apaga el trasmisor el receptor se queda en 0 por mucho tiempo e ingresan datos erroneos.
2.con ambos circuitos TX/RX enlazados siempre, al cabo de unas horas el receptor recibe algun codigo producto del ruido lo cual activa las salidas cualquiera, sin aver enviado ningun dato.

lo que me llevo a deducir que aun sigue el ruido y confunde al pic e interpreta codigo y se queda enganchado con salidas activadas.

Ahora se que necesariamente tengo que codificar los datos a enviar y una de esas codificacion es manchester,que segun la teoria funcionaria asi:

dato = 17, sus equivalencias
decimal = 17
binario = 0001 0001
manchester=01010110 01010110

navegando por la red encontre un ejemplo de comunicacion rf con codificacion manchester, encontre una rutina para la codificacion:

Variables declaradas:


S_Byte Var Byte
D VAR BYTE
I var byte
ENCODED VAR WORD
ENCODED_LOW VAR ENCODED.LOWBYTE
ENCODED_H VAR ENCODED.HIGHBYTE
DECODED VAR BYTE
.............................................
............................................
.............................................

MAN_ENCODING:
FOR D = 0 TO 7
IF S_BYTE.0[D] = 0 THEN
ENCODED.0[D*2] = 0
ENCODED.0[D*2+1] = 1
ELSE
ENCODED.0[D*2] = 1
ENCODED.0[D*2+1] = 0
ENDIF
next D
return

El problema es que me da el resultado invertido po ejemplo en :
ENCODED_H: me queda asi 10101001
ENCODED_LOW: me queda asi 10101001

El codigo queda en 2 BYTES: BYTELOW y BYTEHIGH

no entiendo el motivo del resultado invertido ya que tenia realizar opearciones con la codificacion tal y como debe de ser.
 
Última edición:
Dejo un ejemplo de codificación y decodificación Manchester.
En el receptor o decodificador existe un bug al cual no le encontré el motivo, pero si solución.
Lo dejo comentado en el código, tal vez alguien pueda encontrar el error.
 

Adjuntos

  • 16F628A Manchester CODEC.rar
    63.4 KB · Visitas: 51
Dejo un ejemplo de codificación y decodificación Manchester.
En el receptor o decodificador existe un bug al cual no le encontré el motivo, pero si solución.
Lo dejo comentado en el código, tal vez alguien pueda encontrar el error.

Buenas
En el receptor cuando comparas la variable Dato(tipo word) = $BB sin el 1 sencillamente no hace la comparación, pero si creas otra variable por ejemplo:
Comparar var byte
comparar = Dato
if comparar = $BB then portb.4 = 1, en ese caso si funciona, ahora no se porque al comparar una variable tipo word no funciona y si lo hace con una variable tipo byte(solo soy un hobbista).

PD: también dejo un ejemplo que encontré en el foro de picbasic con algunas modificaciones que hice, pero no lo probé en físico:
 

Adjuntos

  • RF pbp Manchester.rar
    99 KB · Visitas: 42
Hola a todos denuevo aqui, un poco con demora pero esque anduve ocupado, bueno les quiero decir que logre un comunicacion hasta el momento muy buena falta probar una par de dias para descartar errores, ya que el proyecto se trata de un radio control de 4 canales donde lo que activare seran coches a bateria para niños, ya logicamente con su interfaz con relays que casi ya la tengo terminada, lo que quiero conseguir esque no falle o mejor dicho que no se balla activar nada solito sin pulsar algun boton. loque me dio problemas fue el ruido ya que al probar funcionaba ok pero al apagar el trasmisor, en el receptor se prendian y se apagaban solos, lo que hice fue seguir unos tics que me dieron y pues use codificacion manchester, con una cabesera de datos y mejoro el tema.

En el trasmisor uso la interrupcion por cambio de estado del RB4 - RB7, en el receptor en un inicio use la interrupcion por RB0 pero, ya no la uso debido a que el receptor en todo momento esta capatando datos del exterior asi que siempre abra una interrupcion y el dato lo tendria que descartar por sofware asumo que seria lo mismo si no la uso, no se si estoy equivocado,adjunto el proyecto para que me digan como vas pues como les digolo hice investigando un poco pero se que es tedioso establecer una comunicacion estable y segura, talvez se mejore o se pueda agregar algo, ya que no quiero que el cochesito camine solito con un niño dentro. necesito su apoyo gracias a todos los que vallan a opinar.
 

Adjuntos

  • RF Usar + INT_v1.0.rar
    84.1 KB · Visitas: 40
Hola gente, tanto tiempo. aqui de nuevo molestando con una consulta jeje... :D
resulta que estoy intentando hacer funcionar un modulo DFPLAYER MINI y he logrado comunicar el pic con el modulo. el unico problema que tengo, es que cuando reproduce la pista que le he ordenado reproducir, en este caso la numero 1, reproduce la ultima pista cargada. y si le cambio el numero de pista, por ejemlo, la 2, no funciona. queria saber si alguno de uds. ha trabajado con pbp y este modulo y me puede orientar un poquito. desde ya, se agradece cualquier idea. aqui les dejo el codigo que escribi, saludosss ;)(y)
PD: (ya vi un ejemplo en este mismo thread, pero no lo puedo entender y ademas no puedo usar el hserout en el micro... :oops:, perdon:oops::oops::oops: )

Código:
@ device  pic16F876A, hs_osc, wdt_off, pwrt_on, lvp_off, protect_off, bod_off
define loader_used 1
define osc 20     ; especifica que se va a utilizar uno de 20 Mhz
'*****************************************************************
adcon1 = 7        'se desactivan entradas analógicas'
cmcon  = 7        'se desactivan los comparadores (I/O digitales)'
trisa = %00000001         'se programa el puerto A como salida' 
trisb = %00000000         'se programa el puerto B como salida'
trisc = %00000000         'se programa el puerto C como salida'
PORTA=%00000001
PORTB=%00000000
PORTC=%00000000

'*****************************************************************
include "modedefs.bas"



LOOP:
IF PORTA.0=0 THEN 
GOSUB TRANSMITE
ENDIF
PAUSE 100
GOTO LOOP

TRANSMITE: 'PLAY TRACK n-1 
IF PORTA.0=0 THEN TRANSMITE
SEROUT portb.7,t9600,[$7E,$FF,$06,$03,$00,$00,$01,$FE,$F7,$EF] ' play track n.1 
PAUSE 10
RETURN

END
 
Yo tuve ese problema, pero no recuerdo si fue con el dfplayer mini o con otro módulo.
El asunto era que reproducía las pistas por fecha de creación y no por nombre de pista.

¿Renombraste los archivos como 001.mp3, 002.mp3, 003.mp3, etc.?
 
Entonces puede ser que sí sea ese el módulo con el que tuve ese problema.
Posteriormente conseguí un módulo WT5001M02, pero lo olvidé y nunca lo usé.

Prueba cambiando la fecha a los archivos con esta aplicación: SetFileDate
Si cambia el orden de reproducción, entonces se debe a lo que comenté anteriormente.
 
Ok, muchas gracias por tu tiempo amigo D@rkbytes, ya lo logre jeje... solo habia que hacer la siguiente modificacion::D
FOROS EXPLICACION.jpg

Y el codigo quedaria asi:

Código:
@ device  pic16F876A, hs_osc, wdt_off, pwrt_on, lvp_off, protect_off, bod_off
define loader_used 1
define osc 20     ; especifica que se va a utilizar uno de 20 Mhz
'*****************************************************************
adcon1 = 7        'se desactivan entradas analógicas'
cmcon  = 7        'se desactivan los comparadores (I/O digitales)'
trisa = %00000001         'se programa el puerto A como salida escepto A0' 
trisb = %00000000         'se programa el puerto B como salida'
trisc = %00000000         'se programa el puerto C como salida'
PORTA=%00000001
PORTB=%00000000
PORTC=%00000000

'*****************************************************************
include "modedefs.bas"

LOOP:
IF PORTA.0=0 THEN 
GOSUB TRANSMITE
ENDIF
PAUSE 100
GOTO LOOP

TRANSMITE: 
SEROUT portb.0,T9600,[$7E,$FF,$06,$03,$00,$00,$01,$EF] ' play track n.1 
PAUSE 1000
RETURN

END
 
Última edición:
Muy bien. (y) Yo siempre enviaba el checksum.
En un rato que tenga tiempo me daré a la tarea de volver a probar ese módulo sin enviarlo.

Por ahora estoy bastante ocupado realizando una interfaz para el ELM327
Y aunque en el mercado ya existen, la que estoy realizando es bastante especial.
 
Atrás
Arriba