Continue to Site

# Multiple connections to PIC

Status
Not open for further replies.

#### hobby_85

##### New Member
Hi,

I am currently in the middle of a project where my PIC 16f690 is connected to the PC via a RS232. Its constantly sending up information. So basically, the RX/TX pins of the pins are being used.

Now, i need to expand the project and include a RF module. I need a transmitter and receiver attached to the same PIC as well. Below is a link of the RF module bought.

I also bought the corresponding transmitter plus I have purchased holtek's encoder and decoder...HT12 E/D. Now, Im not sure how to go about using them together, but I have found some sites so i know how to connect them up. I just dont know which pins I could connect the RF transmitter and receiver module to the PIC.

My question is this. Will I be able to connect a RF transmitter, RF receiver AND a RS232 to the same PIC. I'm using a 16f690 at the moment, and ideally would like to carry on using the same chip. Mostly because I only have the development board for that PIC type.

Thanks.

#### Nigel Goodwin

##### Super Moderator
Yes, check my tutorials, you don't need a hardware UART to feed an RF module, and it actually makes life more difficult. The Holtek chips are to make a simple remote control, not transfer data from a micro, the micro can do it itself.

#### hobby_85

##### New Member
Yes, check my tutorials, you don't need a hardware UART to feed an RF module, and it actually makes life more difficult. The Holtek chips are to make a simple remote control, not transfer data from a micro, the micro can do it itself.

Hey, thanks for the reply. I am going through your tute at the moment, but i just had a couple of quick questions.

your saying that connect the rf modules via the UART of the PIC is harder than just connecting it to any I/O of the PIC?

I was told the holtek chips do the encoding/decoding for you, and makes like alot easier. Ive never used it, but the guy at the shops told me to get em.

So I can connect 1 RF transmitter, 1 RF receiver and a rs232 to the same PIC?

thanks

#### hobby_85

##### New Member
Yes, check my tutorials, you don't need a hardware UART to feed an RF module, and it actually makes life more difficult. The Holtek chips are to make a simple remote control, not transfer data from a micro, the micro can do it itself.

Hey nigel, im just going through your tute at the moment, but im hitting my head against the wall cause its in assembly. Im terribly useless at assembly, so would you happen to have the C equivalent by any chance?

thanks heaps

#### be80be

##### Well-Known Member
If your using C most have sample of software uart like this from microC
Code:
/*
* Project name:
Soft_UART (Demonstration of using Soft UART library routines)
(c) Mikroelektronika, 2008.
* Revision History:
20081218:
- initial release;
* Description:
This code demonstrates how to use software UART library routines.
Upon receiving data via RS232, MCU immediately sends it back to the sender.
* Test configuration:
MCU:             PIC16F887
Dev.Board:       EasyPIC5
http://www.mikroe.com/en/tools/easypic5/
Oscillator:      HS, 08.0000 MHz
Ext. Modules:    -
SW:              mikroC PRO for PIC
http://www.mikroe.com/en/compilers/mikroc/pro/pic/
* NOTES:
- RX and TX UART switches on EasyPIC5 should be turned On SW7.1 SW8.1.
*/

char i, error, byte_read;                 // Auxiliary variables

void main(){

ANSEL  = 0;                             // Configure AN pins as digital I/O
ANSELH = 0;

TRISB = 0x00;                           // Set PORTB as output (error signalization)
PORTB = 0;                              // No error

error = Soft_UART_Init(&PORTC, 7, 6, 14400, 0); // Initialize Soft UART at 14400 bps
if (error > 0) {
PORTB = error;                        // Signalize Init error
while(1) ;                            // Stop program
}
Delay_ms(100);

for (i = 'z'; i >= 'A'; i--) {          // Send bytes from 'z' downto 'A'
Soft_UART_Write(i);
Delay_ms(100);
}

while(1) {                              // Endless loop
if (error)                            // If error was detected
PORTB = error;                      //   signal it on PORTB
else
}
}

#### Nigel Goodwin

##### Super Moderator
Hey, thanks for the reply. I am going through your tute at the moment, but i just had a couple of quick questions.

your saying that connect the rf modules via the UART of the PIC is harder than just connecting it to any I/O of the PIC?

Yes, Manchester coding isn't compatible with a UART.

I was told the holtek chips do the encoding/decoding for you, and makes like alot easier. Ive never used it, but the guy at the shops told me to get em.

They do, but only for a simple remote control - not for data transmission. If you want to do that in hardware, there are various Manchester encoder/decoder chips available.

So I can connect 1 RF transmitter, 1 RF receiver and a rs232 to the same PIC?

Yes you can.

#### be80be

##### Well-Known Member
Yes, Manchester coding isn't compatible with a UART.

MicroC has samples for Manchester to

#### hobby_85

##### New Member
If your using C most have sample of software uart like this from microC
Code:
/*
* Project name:
Soft_UART (Demonstration of using Soft UART library routines)
(c) Mikroelektronika, 2008.
* Revision History:
20081218:
- initial release;
* Description:
This code demonstrates how to use software UART library routines.
Upon receiving data via RS232, MCU immediately sends it back to the sender.
* Test configuration:
MCU:             PIC16F887
Dev.Board:       EasyPIC5
http://www.mikroe.com/en/tools/easypic5/
Oscillator:      HS, 08.0000 MHz
Ext. Modules:    -
SW:              mikroC PRO for PIC
http://www.mikroe.com/en/compilers/mikroc/pro/pic/
* NOTES:
- RX and TX UART switches on EasyPIC5 should be turned On SW7.1 SW8.1.
*/

char i, error, byte_read;                 // Auxiliary variables

void main(){

ANSEL  = 0;                             // Configure AN pins as digital I/O
ANSELH = 0;

TRISB = 0x00;                           // Set PORTB as output (error signalization)
PORTB = 0;                              // No error

error = Soft_UART_Init(&PORTC, 7, 6, 14400, 0); // Initialize Soft UART at 14400 bps
if (error > 0) {
PORTB = error;                        // Signalize Init error
while(1) ;                            // Stop program
}
Delay_ms(100);

for (i = 'z'; i >= 'A'; i--) {          // Send bytes from 'z' downto 'A'
Soft_UART_Write(i);
Delay_ms(100);
}

while(1) {                              // Endless loop
if (error)                            // If error was detected
PORTB = error;                      //   signal it on PORTB
else
}
}

Wow...so thats softeare uart? I was under the impression i had to play with interupts and what not. Could I control a RF transmitter and receiver in the same manner?

#### Nigel Goodwin

##### Super Moderator
Wow...so thats softeare uart? I was under the impression i had to play with interupts and what not. Could I control a RF transmitter and receiver in the same manner?

You generally can't just use a UART for RF, you need some kind of coding, of which Manchester is the normal one.

Software UART's are dead simple, my tutorials do them in assembler.

#### be80be

##### Well-Known Member
You generally can't just use a UART for RF, you need some kind of coding, of which Manchester is the normal one.

Software UART's are dead simple, my tutorials do them in assembler.

I think it's funny that people think C is easier then assembly

Kind of like my dog is faster then yours but you have a chain holding yours back.

Nigel they can't get any more simple you did all the hard work

#### Nigel Goodwin

##### Super Moderator
Nigel they can't get any more simple you did all the hard work

I stole my software UART routines!

They were in a VERY old Parallax application note written using their own non-MicroChip assembler.

I just did a MPASM version of it.

#### Pavius

##### New Member
If you are set on using UART as a transport mechanism, note the following:

1) The UART transport is byte framed - that is, you send and receive data one byte at a time. In a perfect world, if you'd like to send "hello" to the receiver, you'd simply send (in the transmitter) h, e, l, l , o. The receiver would read, byte by byte, and process this. However, in our imperfect noisy world you will need to account for a few things:
a) The receiver may receive false bytes. The transmitter might be completely idle, but the receiver may think it received a byte. You need to detect this and discard such bytes.
b) The receiver may receive a distorted version of what the transmitter sent. You need to either detect and fix this or discard such distorted data.

To help with a, you can simply send a pattern (synchronization) byte before each transaction. For example, a byte made up of 4 bits of 1101 (or whatever constant pattern) and then the length of the packet you are sending (up to 16 bytes). When the receiver receives a byte when it is idle (that is, it is not in the process of reading a packet), it first checks if the first 4 bits of the received byte are 1101. If they aren't, it simply discards the byte and returns to idle. If they are, it will wait for the next N bytes, as specified in the lower 4 bits of the synchronization byte.
To help with b, you append a checksum or CRC to the end of the packet.

This means that if you'd like to send "hello", you would send:
[sync byte = 11010101][h][e][l][l][o][8/16bit checksum or CRC]

Using interrupts, you have a high priority ISR that will be called whenever a byte is ready to be read, no matter what your SW is doing. Your ISR will simply read this into a circular software buffer of your choice. The application can then read this circular buffer at its leisure, allowing for much more lax timing.

#### hobby_85

##### New Member
Hey all,

sorry i havent replied in a while. Ive been trying to learn how to do this for a while now.

Nigel,

Had a quick question regarding connecting RF to I/O pins. I have gone through your first two tutes, and while I understanding most of it, Im still trying to adapt to assembly, so things are a little difficult.

But from what I have seen in your first two tutes..(tutes 12), the transmitting procedure is the same as connecting the RF to the TX pin of the PIC, except you have to have a manchester subroutine if you use the I/O pin. While im still trying to decipher what is actually going on, i did notice that your using the exact same manchester subroutine everytime. And from what i have gathered, your manipulating the output pin to act like a TX pin.

am i somewhat on the right track here?

For my transmitter, Im sending three NUL's (zeroes) as my preamble. Whats the normal practice...send heaps of o's or 1's? or both?

thanks

#### Nigel Goodwin

##### Super Moderator
As my tutorial explains, I didn't write it - and while the transmit routine is very simple, the receive routine is really quite complicated.

You are quite right in that the I/O pin is used as a TX pin, you can't use a hardware UART because it's not RS232 type data.

The reason for the long preamble is to ensure it's syncronised, unlike RS232 there's no guaranteed clock speed, the receiver locks to the transmitter based on that preamble. The trick is to ensure your packet size is large enough to give a reasonable throughput.

#### hobby_85

##### New Member
The trick is to ensure your packet size is large enough to give a reasonable throughput.

When you mean packet size, thats including the preamble? So even if I were to send, say, 'RF' as my data, Id still want to have a massive preamble, and make the receiver lock onto the signal.

Am i on track so far?

I also found a C program on this forum, which does another type of encoding/decoding. You've posted on that post as well. Heres the link to refresh your memory. Its a couple of threads down where a user has attached two files.

I quickly changed the codes around slightly so i could use it on my PIC 16f690. Changed the pins too so they were simple IO pins. When i hooked up the oscilloscope to the tx, I got a really nice signal. (Exactly as the picture on the pdf file attached actually....identicle). The rx signal, though similar, was alot more 'shaky' and inconsistent. It looked similar to the tx signal, but not identical. I was curious to know if this meant that the data was essentially corrupted? Im thinking of adjusting the code around a little, so i could add an LED test, if the message was captured properly. Just wanted to know what you thought about this.

Thanks.

#### Nigel Goodwin

##### Super Moderator
When you mean packet size, thats including the preamble? So even if I were to send, say, 'RF' as my data, Id still want to have a massive preamble, and make the receiver lock onto the signal.

You can either count the entire packet (including preamble etc.) or just count the actual data bytes, it doesn't really matter.

I also found a C program on this forum, which does another type of encoding/decoding. You've posted on that post as well. Heres the link to refresh your memory. Its a couple of threads down where a user has attached two files.

I quickly changed the codes around slightly so i could use it on my PIC 16f690. Changed the pins too so they were simple IO pins. When i hooked up the oscilloscope to the tx, I got a really nice signal. (Exactly as the picture on the pdf file attached actually....identicle). The rx signal, though similar, was alot more 'shaky' and inconsistent. It looked similar to the tx signal, but not identical. I was curious to know if this meant that the data was essentially corrupted? Im thinking of adjusting the code around a little, so i could add an LED test, if the message was captured properly. Just wanted to know what you thought about this.

The reason for using Manchester coding is because the RX output is usually quite different to what you transmitted.

By all means, try that code and see how well it works.

Status
Not open for further replies.

Replies
4
Views
2K
Replies
47
Views
4K
Replies
42
Views
4K
Replies
70
Views
5K
Replies
17
Views
2K