Searching \ for ' [PIC] Automatic baud detection' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Automatic baud detection'.

No exact or substring matches. trying for part
PICList Thread
'[PICLIST] [PIC] Automatic baud detection'
2002\05\30@051235 by Andreas Nyholm

flavicon
face
Hi,
Have anyone tried make automatic baud detection for RS232 on the PIC?
Let's say that the PC send AT to the serial port and if the PIC receive it
correctly it's using the right baud rate.
Here is a piece of the code I have been trying to use:
RadioRSSetup ; Boot Baud Rate = X, No Parity, 1 Stop Bit
       Bank0                   ;Change to bank0
       bsf PORTB,RTS_OUTPUT    ;set RTS off before setting as output
       Bank1
       bcf TRISB,RTS_OUTPUT    ;enable RTS pin as output
       movlw BAUD_C38400       ; 38400 baud so far
       movwf SPBRG
       movlw b'00100100'       ; brgh = high
       movwf TXSTA             ; enable Async Transmission, set brgh
       Bank0
       movlw b'10010000'       ; enable Async Reception
       movwf RCSTA
       call Receive
       xorlw 'A'
       btfss STATUS,Z
       goto B19                ; test at 19200 baud
       return

Receive gets a byte from RCREG. I have been trying to use a loop until I
get a character and a routine that just move data from RCREG and continue.
This far it just checks if I got an 'A'.

The result I get is that mostly I get it to work with 38400 and 19200 baud
(I do have tried that it use the right baud rate) But with 9600 it doesn't
work at all.
I hope someone have comments about my code to say if this is a good
solution. Otherwise I'll just keep on trying and hope I'll get it to work
:)

Thanks for your answers!
Andreas

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2002\05\30@052934 by Alan B. Pearce

face picon face
>Receive gets a byte from RCREG. I have been trying
>to use a loop until I get a character and a routine
>that just move data from RCREG and continue.
>This far it just checks if I got an 'A'.

I suspect you will need to be a bit more proactive about how you detect the
first character. For example take the character 'A', that is binary
01000001, and consider how this will be received at the wrong baud rate.

case 1 - character seen in your test is 10011111 or 00001111 then baud rate
at the receiving end is probably half the transmitted baud rate.

case 2 - character seen at receiving end is 00011000 then baud rate at
receiving end is probably twice the transmitter. (stop and think about why
there is an extra 0 at the left hand end).

case 3 - character seen at receiving end is 00000001 then baud rate at
receiving end is probably 4 times the transmitted baud rate. (again think
about what happens with the start bit).

If you do some of these checks you can probably set the baud rate and
receive the second character at the correct baud rate.

It is a bit awkward to attempt to detect the baudrate using a hardware UART.
If you can arrange to measure the bit widths on the pin then you will
probably arrive at the required baud rate a lot quicker.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2002\05\30@075508 by Bob Ammerman

picon face
Autobaud detection normally works by timing the actual bits received, not
using the UART, then programming the UART for the correct baud rate.

Bob Ammerman
RAm Systems


{Original Message removed}

2002\05\30@075937 by Andreas Nyholm

flavicon
face
> I suspect you will need to be a bit more proactive about how you detect the
> first character. For example take the character 'A', that is binary
> 01000001, and consider how this will be received at the wrong baud rate.
>
> case 1 - character seen in your test is 10011111 or 00001111 then baud rate
> at the receiving end is probably half the transmitted baud rate.

Ok, I got this one, but why are the rest 1 and not 0?
>
> case 2 - character seen at receiving end is 00011000 then baud rate at
> receiving end is probably twice the transmitter. (stop and think about why
> there is an extra 0 at the left hand end).

I can't find a good answer...
>
> case 3 - character seen at receiving end is 00000001 then baud rate at
> receiving end is probably 4 times the transmitted baud rate. (again think
> about what happens with the start bit).

If there is one extra 0 in the beginning like in case 2, why isn't it
00000111?
>
I tried to compare with those but the only one working was the baud
rate I started with. I think the program didn't get out of the loop that
receives the first byte.

> If you can arrange to measure the bit widths on the pin then you will
> probably arrive at the required baud rate a lot quicker.

Exactly what do you mean?

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2002\05\30@090158 by Alan B. Pearce

face picon face
>> case 1 - character seen in your test is 10011111 or 00001111 then baud
rate
>> at the receiving end is probably half the transmitted baud rate.

>Ok, I got this one, but why are the rest 1 and not 0?

Well they may not be 1's, it will depend on how many stop bits the
transmitter is programmed to send, and how soon after the first character
the next character is sent. If it is all set up for 1 stop bit, and the next
character is sent immediately then you may end up with seeing 10011xxx or
00001xxx where xxx will depend on the next character

>> case 2 - character seen at receiving end is 00011000 then baud rate at
>> receiving end is probably twice the transmitter. (stop and think about
why
>> there is an extra 0 at the left hand end).

>I can't find a good answer...

See diagram below

>> case 3 - character seen at receiving end is 00000001 then baud rate at
>> receiving end is probably 4 times the transmitted baud rate. (again think
>> about what happens with the start bit).

>If there is one extra 0 in the beginning like in case 2, why isn't it
>00000111?

Again see diagram below

>I tried to compare with those but the only one working was the baud
>rate I started with. I think the program didn't get out of the loop that
>receives the first byte.

>> If you can arrange to measure the bit widths on the pin then you will
>> probably arrive at the required baud rate a lot quicker.

>Exactly what do you mean?

The character for an 'A' will have a picture like this on an oscilloscope
(except there will not be all the vertical lines I have put in to show the
boundaries of the bits). A capital S is a start bit, and a lower case S is a
stop bit. I have shown the start bit of the next character assuming it
follows immediately after the first.

           _____          _____                         __________
waveform         |  S |  0 |  1 |  0 |  0 |  0 |  0 |  0 |  1 |  s |  S |
                -----------    --------------------------         ------

rx at baud rate  ^  ^    ^    ^    ^    ^    ^    ^    ^    ^    ^    ^    ^
rx 1/2 baud rate ^       ^         ^         ^         ^         ^         ^
rx 2x baud rate  ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
rx 4x baud rate  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

each arrow represents a sampling of the waveform by the UART to determine
the state of the bit that is to be shifted into the register. The very first
arrow represents the beginning of the start bit that starts the UART
receiving a character, the next arrow the UART verifies it is a proper start
bit, not a noise pulse, and then the next 8 arrows are the 8 data bits, The
arrow after that is to determine that there is a correct stop bit. If this
is not correct you will get framing errors.

Now from the above picture you can see that at the correct baud rate, the
data starts from the 3rd arrow, and then is sampled as 01000001, which is
correct for 'A'.

At half the baudrate the first data bit is still a 0, so a proper start bit
is seen, and the data shifted into the UART will be 0001xxx on my picture.

At the 2x baud rate the first data bit seen is actually 3/4 way through the
start bit, so you would have 00011100 as the first character, the next bit
that should be a stop bit will be a 0 instead of a 1, and so will produce a
framing error. This requires corrective action in PIC code for the uart to
work correctly afterwards.

At 4x baud rate the first data bit will be seen only half way through the
start bit, so the data will look like 00000000 and as the next bit is a 1
then it will see a valid stop bit, and so there will be a second character
following of all 0's, which in this case will have a framing error.

My data bits in the previous email were a bit out as well from mentally
shifting bits instead of drawing diagrams. If you are not aware of why there
are start and stop bits, then learn a little theory on how serial
transmission with a UART works.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2002\05\30@201805 by Lee Jones

flavicon
face
>> I suspect you will need to be a bit more proactive about how
>> you detect the first character. For example take the character
>> 'A', that is binary 01000001

Assuming US-ASCII character set and 8-bit no parity framing (or
7-bit data portion plus even parity or mark (I think) parity).
These are fairly common settings, but not the only ones used.

>> case 1 - character seen in your test is 10011111 or 00001111
>> then baud rate at the receiving end is probably half the
>> transmitted baud rate.

> Ok, I got this one, but why are the rest 1 and not 0?

If your hardware UART is set for a faster baud rate than the
sender is using, then the sender's start bit will slop over
into the data bits portion.  This artificially widened start
bit is the source of the "extra" 1's bits.


>> If you can arrange to measure the bit widths on the pin then
>> you will probably arrive at the required baud rate a lot quicker.

> Exactly what do you mean?

Normally, auto-baud is done by measuring the width of a single
bit.  That bit is normally the start bit of the frame.  To ensure
that a single bit is measured, the first data bit (low order bit)
has to be a 1.  This criteriun is met by the sending using an
ASCII character of carriage return, '1', '3', '5', '7', '9', 'A',
'a', 'C', 'c', 'E', 'e', etc.  All that matters is that the low
order bit of the character is a 1.

Wire the receive data line to a pin.  Watch the pin for voltage
transition (direction depends on your hardware).  Start a timer.
When you see the next transtition, stop timer.  Invert bit time
(via table or If-Else tree) into baud rate.  Program hardware
UART.  Then check next character for validity & framing.  If it
doesn't "look right", start over.
carriage return, ASCII '1', ASCII 'A', ASCII 'a',

Someone else replied:

> The character for [a US-ASCII] 'A' will have a picture like
> this on an oscilloscope [...].  A capital S is a start bit, and
> a lower case S is a stop bit.
>
>             _____          _____                         __________
> waveform         |  S |  0 |  1 |  0 |  0 |  0 |  0 |  0 |  1 |  s |  S |
>                  -----------    --------------------------         ------

This diagram shows the bits being sent most significant bit first.
It is reversed.

This is incorrect.  Serial data is transmitted low order bit first.
It has to be since the number of bits per byte may vary.  Common
sizes have been 5 bits/byte up to 9 bits per byte.

                                               Lee Jones

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2002\05\31@042212 by Alan B. Pearce

face picon face
>This diagram shows the bits being sent most
>significant bit first. It is reversed.

>This is incorrect.  Serial data is transmitted
>low order bit first. It has to be since the
>number of bits per byte may vary.  Common
>sizes have been 5 bits/byte up to 9 bits per byte.

You are correct, and I had this Doh moment just before falling asleep last
night about doing this. Been doing too much I2C lately which does have it
this way round.

My apologies to the original poster, but if you follow the same logical
process you may still be able to sort out doing basic auto-baud detection.

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu



'[PICLIST] [PIC] Automatic baud detection'
2002\06\11@042719 by Andreas Nyholm
flavicon
face
Hello again!

On Thu, 30 May 2002, Lee Jones wrote:

{Quote hidden}

I was trying this quite sucessfully at first. I was measuring the width of
one bit with every baudrate I need. Everything was working properly and I
was happy, but when I put everything together it wasn't working that good
anymore. One problem I have is that when I turn on the PIC before I send
the character I get one time, and when I send the character and then turn
on the PIC I get another.. So, it looks like I'm measuring an extra bit
when I send the character before turning on my PIC. (the measuring time
was ~2*the first time.) Any ideas what this is? It must be something
before the start bit or am I wrong?

I have been taking some days off with this autobaud, but yesterday I
started to try my first idea, to xorlw the received character with 'A' and
try again with next baudrate if it's wrong. This I got now is improved
from the first one, I've got frame error checking and so one... I also
forgot to flush the receiver buffer in the first version, but now I have
tried with that too. But I'm not really sure how and when to do that so
I've tried many different ways. But since I'm still writing I didn't get
it to work...
I start with 38400 baud and goes down to 19200 and then to 9600 and last
4800 baud. My version works with 38400 without problems, and with 19200
when I press A two times, but when I'm going down to 9600 I don't get it
to work anymore. I have BRGH=1 at 9600 and higher and BRGH=0 at 4800.
I hope someone can give me more ideas what to do.

/Andreas

> Someone else replied:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...