Comunicación SPI con PIC16F877A y CC1101

#21
Temía eso, los módulos que también utilicé tenían una secuencia de inicialización. Lo que puedes hacer es solicitar al distribuidor algunos ejemplos de inicialización para el Tx como para el Rx.
Para los módulos que tengo están unos ejemplos en la red, de igual forma tienen bastantes registros, te dejo los ejemplos para que te orientes (y pruebes, con suerte y funcionan).

http://www.robodacta.mx/images/RF31_receive_DEMO.pdf

http://www.robodacta.mx/images/RF43_transmit_DEMO.pdf
Hola
el distribuidor me envio este link, dice que aca hay informacion y un codigo ejemplo
http://www.elechouse.com/elechouse/index.php?main_page=product_info&cPath=90_92&products_id=568
pero es para arduino yo no he utilizado nunca arduino asi que soy ignorante en el tema
 
#22
Lo ando viendo, veamos ¿que tanto dominas el C? con una idea vaga se puede intentar traducir desde C a PICBasic, lo importante es deducir el algoritmo de inicialización de los módulos. Yo tuve que hacer lo mismo para los módulos que conseguí, el ejemplo que venía estaba en C y yo lo quería en .ASM, en un rato puedo ayudarte con la traducción pero a un lenguaje "algoritmo" porque de PICBasic ando muy verde.
Solo me queda una duda, ¿cada módulo es Rx/Tx verdad? osea la comunicación es bidireccional. Por que en el ejemplo solo muestran el código para uno

Saludos
 
#23
mi dominio en c no es muy bueno que digamos
pero picbasic tiene @asm para agregar codigos en asm dentro de el mismo basic, se podria implementar en el codigo
los modulos son rx/tx
se supone que los modulos se les llama un registro no? ese registro no se utiliza del pic?
como el ADCON1
o los de spi
no es asi?
 
#24
Entonces agregando algo de @asm se puede sacar adelante el problema. Los módulos son OTRO microcontrolador con el que el maestro se comunica y este tiene SUS propios registros aparte; son los que en la hoja de datos se especifican y en los que se tienen que cargar determinados valores para el correcto funcionamiento del módulo. Estos datos se envían por medio del bus SPI al uC del módulo. Algo así:

1-El maestro envía un byte donde se especifica en que dirección del uC se escribirá o leerá el byte de datos
2-El maestro envía el byte de datos
 
#25
Ok entonces quiere decir que estos módulos son prácticamente otros microcontroladores. ok
el distribuidor me dijo que no había necesidad de programarlos que ya estaba listos entonces toca generar un código para establecer una comunicación entre el maestro y el modulo usando los registros específicos del modulo. y luego ahi si enviar los datos por comunicación spi :unsure: que mal (n)
entonces
podrías ayudarme con los registros? estoy seguro que manejar eso por asm es mas a fondo, tendría entonces que hacer un código de comunicación spi e implementar esos registros en asm
cada vez se esta poniendo mas complicado esa comunicación, no pensé que lo fuera tanto, y todo por querer ahorrar un poco de dinero, debí comprar los xbee :LOL:
 
#26
Supongo el distribuidor se refiere a que no tienes que programar el uC como tal pero si sus registros.

Existen otros módulos más económicos en donde no es necesaria ningún protocolo de envío de datos, el uC maestro solamente pone en alto o bajo tal pin, este estado lógico se envía por RF al receptor donde hace que su pin de salida actúe conforme al emisor.
El otro caso es como tus módulos donde el emisor se espera a que el uC escriba un "paquete" (byte) completo de datos, una vez hecho esto, el Tx envía el byte completo vía RF al receptor donde es decodificado. Una vez decodificado le avisa al uC del receptor por medio de una señal destinada (int) que hay datos presentes por leer, entonces el micro lee el byte entero y lo procesa.

Dame unas horas y en la noche te ayudo a traducir el ejemplo que posteaste. En lo personal creo que es mejor batallarle a problemas así que usar lo popular en el mercado, vamos el conocimiento es más satisfactorio si te cuesta algo de trabajo (y)
 
#28
#29
Yo tengo dificultades para la traducción, es que el ejemplo viene con enlaces a dos programas mediante funciones, y nos sé en que orden se ejecutan. Mientras no hayas hecho un corto entre sus pines o conectado al revés las tensiones de alimentación se puede confiar en que los módulos funcionan
 
#30
Saludos.

Éstos ejemplos que adjunto de comunicación bilateral por SPI, vienen directamente de melabs (microEngineering Labs)
Tienen algunos cambios que realicé por comodidad para la pantalla, agregué los fuses y configuré los puertos.
El proyecto está probado físicamente, pero como no tengo dos 16F877A, usé un 16F876A.

Sobre los CC1100 no tengo idea, pero estos programas con PIC Master & Slave, funcionan.

Espero les sirvan.

Suerte.
 

Adjuntos

Última edición:
#31
Saludos.

Éstos ejemplos que adjunto de comunicación bilateral por SPI, vienen directamente de melabs (microEngineering Labs)
Tienen algunos cambios que realicé por comodidad para la pantalla, agregué los fuses y configuré los puertos.
El proyecto está probado físicamente, pero como no tengo dos 16F877A, usé un 16F876A.

Sobre los CC1100 no tengo idea, pero estos programas con PIC Master & Slave, funcionan.

Espero les sirvan.

Suerte.
muchisismas gracias por este aporte, me servira de mucho en el tema de spi, pero con el tema de los cc1100 esta bastante trabajoso ya no logro hacer que funcionen tienen registros propios y no se como hacerlos en picbasic subi un codigo ejemplo de arduino pero en pic nada, yo no he aprendido arduino
 
Arriba