Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

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.

SparkFun Electronics - RF Link 4800bps Receiver - 434MHz

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.
 
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.
 
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
 
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
 
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) 
 * Copyright:
     (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
                      http://ww1.microchip.com/downloads/en/DeviceDoc/41291F.pdf
     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
    byte_read = Soft_UART_Read(&error);   // Read byte, then test error flag
    if (error)                            // If error was detected
      PORTB = error;                      //   signal it on PORTB
    else
      Soft_UART_Write(byte_read);         // If error was not detected, return byte read
    }      
}
 
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.
 
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) 
 * Copyright:
     (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
                      http://ww1.microchip.com/downloads/en/DeviceDoc/41291F.pdf
     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
    byte_read = Soft_UART_Read(&error);   // Read byte, then test error flag
    if (error)                            // If error was detected
      PORTB = error;                      //   signal it on PORTB
    else
      Soft_UART_Write(byte_read);         // If error was not detected, return byte read
    }      
}

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?
 
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.
 
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 :rolleyes:

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

Nigel they can't get any more simple you did all the hard work :D
 
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]

2) You can operate the UART without using interrupts. This requires, however, the "attention" of your software. You MUST be able to service received bytes CONSTANTLY at the receiver side - otherwise you will overflow your 1 byte receive buffer. In other words, if the transmitter sent 2 bytes - the first byte will be read by the receiver's hardware UART into RCREG (UART receive register) and RCIF would be set (indicating - byte waiting, read me). If the software does not read RCREG by the time the second byte is received, you will get an overflow (lose the second byte and any consequent byte). You can do this at first, but very quickly you will see that you reach overflow conditions no matter what you do - unless you are literally doing zero processing of received bytes.

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.
 
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?

also, on your main tute 12 page, you mention that your header is made up of 20 byte 1's and one byte 0. Do headers really need to be this long...for the receiver to adjust?

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
 
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.
 
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.

https://www.electro-tech-online.com/threads/manchester-routines-in-c-for-pic.92375/

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.
 
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.

https://www.electro-tech-online.com/threads/manchester-routines-in-c-for-pic.92375/

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.

Latest threads

New Articles From Microcontroller Tips

Back
Top