I am working w/ a pic16F690 and adding a rfd21733 transceiver to make wireless UART communications. The RFD21733 sends and receives its data at 9600 8 n 1 (9600 baud, 8 bits, no parity, one stop bit) and I have my pic set up the same way. I have created a program to blink an led with 2 pics hard wired to confirm I am at 9600 8 n 1. The issue I see ( when I attempt to integrate the rfd21733) is that my PIC works with a start bit, then the 8 bits of data and then a stop bit but the RFD21733 does NOT have a start bit. Can anyone help me with understanding how I would be able to make this work? The start bit (low) is a 'space' and the stop bit is a mark (high). When I send 0x40 (b01000000) (64 decimal), the rfd21733 is sending to the PIC, the PIC is seeing 0xfd (b11111101) or 253 decimal. I have written an assembly program that receives the byte and then I blink an LED for one sec on one sec off and count the blinks to tell me what the byte value is .
I am just not sure if I can even make this work but wanted to post this here to see if this could have some fresh eyes.

Thanks all for your continued help.

 

There is an obvious relationship between those two binary values (bits reversed and inverted). Does that relationship hold if you send other bytes?

 

There is an obvious relationship between those two binary values (bits reversed and inverted). Does that relationship hold if you send other bytes?

Thank you for your response. I am unable to answer your question due to the fact that I am away from the location where this project resides. I will be trying to send different bytes and get a response to you.

TY

 

After I thought about this some more, I figured this would be my next attempt at a solution. I believe I can change the polarity by use of the SCKP bit. Now for the byte being reversed I can write an assembly program to change from the msb being first to lsb being first (which the pic sees) and I think this will solve my issues.

Questions I have:
Is it common to have the results that I have seen...reversed and inverted.
I was not able to see on the RFD21733 datasheet the fact that the byte could be send msb first.
Still not sure about why it would still work if there is no start bit being used when the RFD21733 sends the data to the PIC.

TY

 

The reversal for that sent byte may just be coincidence. It may not hold true for other values.

 

I am working w/ a pic16F690 and adding a rfd21733 transceiver to make wireless UART communications. The RFD21733 sends and receives its data at 9600 8 n 1 (9600 baud, 8 bits, no parity, one stop bit) and I have my pic set up the same way. I have created a program to blink an led with 2 pics hard wired to confirm I am at 9600 8 n 1. The issue I see ( when I attempt to integrate the rfd21733) is that my PIC works with a start bit, then the 8 bits of data and then a stop bit but the RFD21733 does NOT have a start bit. Can anyone help me with understanding how I would be able to make this work? The start bit (low) is a 'space' and the stop bit is a mark (high). When I send 0x40 (b01000000) (64 decimal), the rfd21733 is sending to the PIC, the PIC is seeing 0xfd (b11111101) or 253 decimal. I have written an assembly program that receives the byte and then I blink an LED for one sec on one sec off and count the blinks to tell me what the byte value is .
I am just not sure if I can even make this work but wanted to post this here to see if this could have some fresh eyes.

Thanks all for your continued help.

It sure looks like it should have start/stop bits and the datasheet describes what looks like a standard UART in modes 2 and 3. pp35 references start and stop bits so I'm inclined to think they are there as in any UART.
The polarity looks right for connecting directly to the PIC UART i.e. mark is '1', space is '0'.
Mode 2 looks like what you want for a point to point i.e. wireless pipe as they put it.
Note that these are half duplex and can't transmit and receive at the same time. They also operate in a 'burst' mode where it accumulates up to 12 byte packets then sends them. Your PIC receiver has to be able to receive continuous 9600baud (~1ms/char) for at least 12 bytes. If you are flashing an LED with delay() type loops and not receiving with an interrupt driven buffer you'll miss characters and get an overflow. That would account for your goofy data. Note that after an overflow, RCIF no longer works until you reset the UART in the PIC. See 'End to End Latency' on pp35 of the datasheet.

I'd start by sending one byte only then delay a long time. That would cause the transmitter to time out (16ms) and send that one byte. It should be received and output to the other PIC's UART RX pin. Since you are sending only one byte, it should be easy to troubleshoot the link one way. After that, echo the byte back using the same method if you are contemplating bi-directional comms.

You didn't say what diagnostic tools you have. A scope would be invaluable - note that async sends LSB first, the UART sorts it out. If you have a PICkit, set a breakpoint on the receiver when it detects RCIF then examine RCREG to see what the data is and examine the flags too for framing or overflow errors.

Flashing an LED burns up CPU time that should be used to receive characters. I'd try using a few LEDs on extra port pins. Decode each from a received character e.g. 'A' turns on LED1, 'B' turns on LED2 and so on. Any unexpected / unknown character turns them all on - that sort of thing. Even with a simple setup like this, once you successfully receive a few known characters you'll be able to expand from there.

Datasheet is attached.

Good luck!

 

Thank you very much for your detailed help with the issues I am having. I will have a go of it tomorrow and return here with my results.

TY

I'd start by sending one byte only then delay a long time. That would cause the transmitter to time out (16ms) and send that one byte. It should be received and output to the other PIC's UART RX pin. Since you are sending only one byte, it should be easy to troubleshoot the link one way. After that, echo the byte back using the same method if you are contemplating bi-directional comms.

You didn't say what diagnostic tools you have. A scope would be invaluable - note that async sends LSB first, the UART sorts it out. If you have a PICkit, set a breakpoint on the receiver when it detects RCIF then examine RCREG to see what the data is and examine the flags too for framing or overflow errors.

Flashing an LED burns up CPU time that should be used to receive characters. I'd try using a few LEDs on extra port pins. Decode each from a received character e.g. 'A' turns on LED1, 'B' turns on LED2 and so on. Any unexpected / unknown character turns them all on - that sort of thing. Even with a simple setup like this, once you successfully receive a few known characters you'll be able to expand from there.

Datasheet is attached.

Good luck!

Moderator edit: added QUOTE tags

 

Another question I have after reading the datasheet for both the PIC16F690 and the RFD21733 is that the 21733 says it is to be in half duplex at 9600 8 n 1. The pic can do either half or full duplex. Is that right when the 21733 says that it is half duplex? Meaning I will have my rx line as the send and receive data line and the tx as my clock line? That just doesnt seem right to me. How are you able to clock that wirelessly and be accurate?

Could someone please clarify this for me.

TY

 

Another question I have after reading the datasheet for both the PIC16F690 and the RFD21733 is that the 21733 says it is to be in half duplex at 9600 8 n 1. The pic can do either half or full duplex. Is that right when the 21733 says that it is half duplex? Meaning I will have my rx line as the send and receive data line and the tx as my clock line? That just doesnt seem right to me. How are you able to clock that wirelessly and be accurate?

Could someone please clarify this for me.

TY

In this context, half duplex means that you can't send and receive over the RF link simultaneously. You still have the same connections in both directions but you can only use one at a time. Note that 9600 n 8 1 refers to serial ASYNCHRONOUS communication, there is no clock line or signal. The transmitter frames a character by sending the start bit (a space), 8 data bits (LSbit first) then a stop bit (a mark). If everyone is running at the same settings, the receiver will sync to the transmitter on the start bit and maintain a stable internal clock to shift in the data. After 8 bits, the receiver makes sure it is getting a mark (the stop bit) to verify that it successfully received one character. 9600 baud means that once started, the transmitter will shift a new bit out each 104us and every 104us the receiver will samsaple its input to detect a 1 or 0. Both have to run at the same baud rate to make the sampling times work with no error. (And in case you are wondering, the receiver starts its 104us bit-sampling 1/2 bittime after the mark-to-space transition of the start bit so that subsequent 104us sample intervals are at the center of the transmitted bit cell).

To send to the RF transmitter you send 1 to 12 characters. Note that the PIC is double buffered meaning you can write to TXREG while it is shifting out the previous character but for more chars, you have to check that TXREG is empty (TXIF==1) before sending subsequent chars. That's why I suggest sending one char only to get the RF link up. Characters sent to the RF module are buffered to make up packets. When the 12th character is buffered, the transmitter sends a burst containing all 12. If you send less than 12 to the RF module, it will send those 16ms after the first character, according to the datasheet.

The half duplex limitation is a function of the RF link, not the PIC UART. The PIC is capable of full duplex i.e. simultaneous transmit and receive. The RF module can't receive while transmitting so it can't send anything back to the PIC if the PIC is sending characters at a rate that keeps the buffer full. Think of it like a two lane road (the PIC UART) that crosses a one lane bridge with a flagman at each end. Even though traffic on the approach road can move in two directions always, only one direction at a time is allowed over the bridge so everyone has to take turns. Same with the comms. You can transmit or receive but only in one direction at a time. This means that 1)even though the PIC hardware is full duplex-capable, it is reduced to half duplex because the RF link is only one direction at a time and 2) your software will have to take that into account. If you are exchanging data between the PICs over a one way at a time link (the RF module) you'll need a protocol (a set of rules like the flagman) to coordinate everyone taking turns kind of like saying 'over' on a walkie-talkie so that someone else can speak.

On each PIC, the TX pin connects to TXD on it's RF module and the RX pin to RXD. When you send data from PIC 1 to 2, PIC 1 UART sends the async data to the RFmodule's TXD pin. The RF module buffers the data until 12 chars or 16ms after the first char then it transmits a burst of data. The burst is received by RF module 2, decoded and sent character by character to PIC2's UART RX pin. As each character is received by the UART, RCIF is set and the receiving firmware reads RCREG. When all the characters have been read, the transmission of that packet is complete. The protocol will specify from there what to do next e.g. wait for another packet from PIC1 or reply to the packet while PIC1 waits.

Pretty sure that's how the RF module works.

Good luck!
BTW, I specified the PIC registers from memory. YMMV

 

Thank you John for your detailed explanation of the rf module and the PIC UART. I worked with this all day today to the point of frustration over the fact that I still am not able to transmit over wireless. I am sending only one byte from one pic to the other in one direction only as I want to make sure it will send one byte correctly in one direction to strip it down to the basics and work it up to both directions (like a pipe). My intent with this UART is to only send 4-5 bytes of data which will all be going in one direction then received and a confirmation sent back by echoing the data. I am using full duplex asynchronous here with the PICS. I will not be sending and receiving from both PICS at the same time. I have confirmed that the code I wrote works which is sending the binary value 8 to the 2nd PIC and the 2nd PIC will then, after it has been received, blink an led for what I hoped for would be 8 times to signify that the data transmitted correctly. I was successful at doing this. I then connected the rf modules up w/ pic tx to rf tx and rf rx to pic rx which is following the data sheet. I am running in mode two and have a 15k pull down resistor on my logic i/o pins. These rf modules are running at 3.3v. (my pic is running at 5v) (I am converting the logic with a TI TX0104) I have confirmed the functionality by use of multimeter. I see in the data sheet (for the RF) that there is a 3ms latency at power up so I delay sending my data over RF for one second. I have written some programs to try many different scenarios including sending 12 bytes and saving them in RAM and then taking the first byte (my data number 8 in binary) and blinking the led 8 times but this didnt work correctly and know my code is correct. I have tried putting a delay for 15ms as per the datasheet which did not give me the correct results.
I did notice when I power up my PICS that I was seeing inconsistency with the program running. By this I mean I had programmed the PIC to send the number 32 to the other PIC and that worked. I went and changed that to the number 8 (or any number for that matter) and went and ran the program (for 8 blinks), and my code for the 32 blinks ran. So, I re-powered my pics and would sometimes get one program(32 blinks) and another time I powered the PIC I would get the other progra (8 blinks). What can this be? Is this a reset issue? I reprogrammed the PICS and had the same problem. Is this somehow going into a reset? I am really not sure what to do next here.

Thanks for your continued help with my RF issues.

 

but the RFD21733 does NOT have a start bit.

unless this thing uses something completely odd-ball, your statement is unlikely true.

worked with this all day today to the point of frustration

it is a time to rethink your approach to this.

I typically separate this into two layers and deal with them individually:

1) make sure that your uart routines work. that means you can transmit / receive over uart on the pic.
2) then read the rf device's datasheet and follow its protocol using the routines you built in step 1 above.

transmitting is much easier than receiving so I would start over that.

 

Hmmm..
A good strategy at this point might be to connect the PICs without the RF, debug the basics and get that working. Then add the RF link.
Posting a schematic and your test code would help.

 

Hmmm..
A good strategy at this point might be to connect the PICs without the RF, debug the basics and get that working. Then add the RF link.
Posting a schematic and your test code would help.

Yeah, that's what I had done all along but just could not figure out why when adding the RF that it would not send the data correctly. I added a circular buffer to my rx at the 2nd pic side but that gave me the same result. It was not until I went back and checked my math on the formulas for computing the baud rate that I saw that I had changed them when I switched over and ran Half duplex mode (on the pic) with the rx line being data line and tx being clock line. As soon as I saw my error and re-assembled the circuit the rf worked perfectly the first time. I then wrote and executed a few test programs to verify the data to be sent was sent correctly, and it worked w/o fault.
I would like to that everyone that helped me and guided me in solving this puzzle. I have learned a lot from this. Thank you!

Peaches

 

Thanks for the update!
Well done!