// header files
#include "main.h"
#include "port.h"
#include "delay_loop.h"
//Function Prototypes
void serial_init();
void send_serial(unsigned char *s);
void serial_init()
{
SCON=0x50; //Setup for 8-bit data
TMOD=0x20; //Setup timer 1 for auto-reload
TH1=0xF3; //Setup for 2400 Baud
TR1=1; //Turn on timer 1
TI=1; //Indicate ready to transmit
}
void send_serial(unsigned char *s)
{
while(*s !=0x00)
{
SBUF=*s;
while(! TI)
{
}
TI=0;
s++;
}
}
void main(void)
{
serial_init();
//send_serial('1');
while(1)
{
// SECOND_LED=0;
// FIRST_LED=0;
if (FIRST_BUTTON == PRESSED)
{
send_serial('1');
while(1)
{
if (FIRST_BUTTON == NOT_PRESSED)
{
FIRST_BUTTON = NOT_PRESSED;
break;
}
}
}
if (SECOND_BUTTON == PRESSED)
{
send_serial('2');
while(1)
{
if (SECOND_BUTTON == NOT_PRESSED)
{
SECOND_BUTTON = NOT_PRESSED;
break;
}
}
}
Delay_Loop(5);
}
}
// header files
#include "main.h"
#include "port.h"
#include "delay_loop.h"
//Global variable
tByte received_data_G;
int received_flag_G;
//Function Prototypes
void serial_init();
void serial_init()
{
SCON=0x50; //Setup for 8-bit data
TMOD=0x20; //Setup timer 1 for auto-reload
TH1=0xF3; //Setup for 2400 Baud
TR1=1; //Turn on timer 1
TI=1; //Indicate ready to transmit
EA=1; //Enable Interrupts
ES=1; //Enable serial port interrupt
}
serial() interrupt 4
{
if(RI)
{
received_data_G=SBUF;
RI=0;
received_flag_G=1; //Set received flag
}
}
void main(void)
{
received_flag_G=0;
serial_init();
FIRST_LED=OFF;
SECOND_LED=OFF;
for(;;)
{
while(received_flag_G==0)
{
}
received_flag_G=0;
if (received_data_G==1)
{
FIRST_LED=ON;
// SECOND_LED=ON;
Delay_Loop(50);
FIRST_LED=OFF;
// SECOND_LED=OFF;
}
if (received_data_G==2)
{
// FIRST_LED=ON;
SECOND_LED=ON;
Delay_Loop(50);
// FIRST_LED=OFF;
SECOND_LED=OFF;
}
}
}
Remember that I am going to implment manchester encoding in transmitter and decoding in the receiver. So what is the best way of transmitting encoded bits and how the receiver capture the serial data?
Now I am very confused because someone just told me that I cannot implement UART and I have to use bit-banging codes and advise me to modify my schematic as well
Imagine that:
I get the bits - 1111000
When logic goes high at the begining, it stays there for a while. How my microcontroller know that bit stay high at three times?
Buriedcode said:Lastly, I don't know why I suggested using a UART at the receiver. Its fine for the Tx, but because the Rx is getting a lot of interference and noise, it will trigger the UART to receive.
Yin-Yang said:Hiya Buriedcode
Out of curosity, have you experienced this problem in your previous project?
I found your posts very interesting about manchester coding and bit-bashing. But would you save a lot of time if you buy Radio chip with features like linear coding and RS-232? This would speed the process up for me, maverick max and people in EDAboard.
If it is possible to get one, do you know any good RF chip?
Yin-Yang
MaverickMax,
Sorry for the delay, been a bit busy.
Well, if you checked the forum, you would have found code snippets and links on manchester encoding on a micro, I admit all my work was on the PIC micro, and written in assembly. But I'm sure you could convert pseudo-code to C.
Firstly you need to encode your bytes to manchester bits. As I'm sure you know, in manchester encoding: 1 -> 01, and 0 -> 10. So data 1 is an upward transistion in the output, and a data 0 is a downward transistion. Someitmes its the other way around, as long as encoder and decoder agree it'll be fine.
So, because you're putting two bits in, and getting two bits out, you put a byte in and get two bytes out. The easiest way it to use a look-up table, with 16 entries.
I say 16 instead of 256 because you can encode in 'nibbles' (half a byte). This saves alot of memory. Pseudo-code goes something like this:
Move 'INbyte' to the accumulator
AND with 0x0F; - this gets rid of the 4 MSB's, 0x0F is 00001111.
Call lookup table.
Move result into LOWbyte.
Move 'INbyte' to the accumulator
Swap nibbles; dunno how to do this in C. Now we work on the other 4 bits.
AND with 0x0F; - again, gets rid of 4 MSB's.
Call lookup table.
Move result into HIGHbyte.
Lookup table:
00000000 - > 10101010
00000001 - > 10101001
00000010 - > 10100110
etc....
00001111 - > 01010101
Remember, only 'useable data' is encoded. Any other packets (described later) are sent 'as is'.
I'm sure you've probably done this, but just incase...
Right, so with that, you put one byte in, and get two bytes out. 8 data -> 16 manchester bits. Thats an easy way to encode, but you still need to send it.
Now, 'bit banging' is an option, it takes up instructions and time, but can run very quickly. But some may not realise that you CAN use a UART for manchester data.
Does this mean you are 'not allowed' to use your UART? From a teacher/lecturer/boss? Or did they say it 'cannot be done' with a UART?
Either way, I'll try and explain both. Firstly heres a great article on UART's and manchester encoding:
**broken link removed**
Firstly, using your UART:
The standard format for data transmission is : SDDDDDDDDS. Now, the whole point of manchester encoding, is that is easy to syncronize(many transistions), and is DC-balanced (equal number of 1's and 0's). However, if we use our UART we already have syncronization (it does it for us) but we still need DC balancing. You've already 'balanced' your data byte, giving you two data bytes, using the above method, and the START bit is 0, and the STOP bit is 1. So every packet is already balaced.
In order for you to keep it going, you must send packets 'back-to-back' wihtout large gaps (a few bits gap may be ok) . Just load your byte into your micro's Serial buffer (so it send it), then keep checking a flag to tell if its finished sending. Or you can use an interupt if your micro have one (just checked, it does).
I've just checked your chip, there are loads of AT89C51's, and I do not know if you have a 'hardware UART'. But looking at your C-code, you use 'SBUF' which I think means that it has indeed got a serial port.
Right, now remember I mentioned 'the first few bits of a packet will be garbled'??
Thats the PLL in the RX getting acustom to the incoming data, it needs to lock.
Your First packet, the 'Preamble', should be 0xAA. In binary thats '10101010'. This is just to 'wake up' the RF reciever, but is not needed by your reciver micro, and serves no other purpose. So, after that packet, the next packet you send would probably get to your reciever OK (not garbled) but how do we know whether its data or not?? Simple. If you read the 'Quick Builder' article you would have seen a 'sync pattern'. This 'sync pattern' is NOT manchester encoded, it purposefully violates the code, so its not mistaken for data. Usually its '00011101' or just '00001111'. After you've sent this, then you send your TWO bytes of manchester data (thats 8 data bits in total).
So, wrapping it all up, using your UART, you send 4 packets consecutively (one straight after the other). And your whole packet should look like this:
<Preamble><Sync pattern><Data HIGH><Data LOW> - each is a byte, with its own 'start and stop' bits.
If you sent this to a gneric manchester decoder (01 -> 1, 10 -> 0) then you would see this for your two data bytes:
0DDDD0DDDDD0
(The bold '0's are simply the stop bit from the previous packet, and the start bit from the next packet producing a '10', which in manchester, is a '0').
You may want to add a 'STOP packet' but I don' think its necassary, you just look for the sync pattern, then the next two bytes after that are your data.
At the reciever, you have another UART. This is connected directly to the DATAOUT pin on your RF receiver (maybe with a 'buffer' or a schmitt trigger to square it up). This, like a UART used for cabled links is constantly waiting for a start bit. And no doubt noise will still trigger it, and maybe even add a stop bit as well, so your receiver micro gets a whoel packet in. BUT.....your code should only look for the 'SYNC pattern'. Once it has this, it knows thats the next two bytes it will get, will be data, and you should save them as such. So when ever your UART interupt pings, the first thing you do is check whether its your sync pattern. If not, then discard it, and continue lookingfor the SYNC. Once you've received it, read in the next two packets.
Right, Im getting tired
Bit Banging. Theres plenty of info on bit-banging on the net, and if you use the above methods (designed for a standard UART) you will only need bit banging routines for a standard UART. Since its just replacing hardware with software.
Juat make sure, in either case, that the baud is set the same for both the TX and RX.
Ok, well, thats it. I've explained this many times before, but I suppose it doesn't hurt. Sorry Admin if you think this is a repeated post.
Good Luck,
BuriedCode.[/b]
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?