Auto Baud Rate Detection

Printable View

- 25th October 2005, 19:50
mytekcontrols

Auto Baud Rate Detection

The Problem: How can you automatically detect and set the hardware USART to match the incoming baudrate of an external source?

In the example below you will find my initial solution written entirely in PBP. It requires only one character be sent for synchronization (I chose the ascii space character as my baud rate detect character).

Code:

'******************************************* ' USART Auto Baud Rate Detection ' Author: Michael St. Pierre ' Date: 10/25/2005 ' Notes: Based on Eddy Carroll article, ' April 1989 '******************************************* DEFINE LOADER_USED 1 ' use for Boot Loader DEFINE OSC 40 '============================================ ' Equates (for PIC18F252 or PIC18F452) '============================================ baudset var bit rxdata var byte Clear RCIF VAR PIR1.5 ' USART receive interrupt flag BRGH VAR TXSTA.2 ' High Baud Rate Select bit OERR VAR RCSTA.1 ' Overrun Error bit CREN VAR RCSTA.4 ' Continuous Receive Enable bit '============================================ ' Initialize USART '============================================ ' Set-up USART for initial 19.2K Baud Operation for 40 Mhz oscillator SPBRG = 129 TXSTA = %00100100 RCSTA = %10010000 '============================================ ' Program Start (MAIN) '============================================ mainloop: While RCIF = 0: Wend ; loop until data present in USART buffer rxdata = RCREG ; retrieve data. If baudset = 0 Then ; If this is the initial pass... Gosub Autobaud ; detect and set baudrate, baudset = 1 ; deactivate Auto-Baud Rate Detection, Goto mainloop ; and skip data send. Endif TXREG = rxdata ; Send valid data bytes only! Goto mainloop '============================================ ' Auto Baud Rate Detection Routine ' (Entry Baud Rate set to 19.2K) '============================================ ; A single space " " character required for auto detect function ; !!! No other characters should be sent prior to space !!! ; Format of data upon reception of space " " character: ; 4800 baud: 0 128 (2 bytes) ; 9600 baud: 0 248 (2 bytes) ; 19.2k baud: 32 ; 38.4k baud: 244 or 252 (slight amount of uncertainty in data) Autobaud: If rxdata = 0 Then ; If 1st byte received = 0 then... While RCIF = 0: Wend ; Loop until 2nd valid byte received, rxdata = RCREG ; and fetch data. Endif Select Case rxdata Case 128 ; @4800 Baud (2nd of two data bytes received) BRGH = 0 SPBRG = 129 Case 248 ; @9600 Baud (2nd of two data bytes received) BRGH = 0 SPBRG = 64 Case 32 ; @19.2K Baud (1st and only data byte received) BRGH = 1 SPBRG = 129 Case Else ; @38.4K Baud (1st and only data byte received) BRGH = 1 SPBRG = 64 End Select If OERR Then ; If receive buffer overflowed, clear it! CREN = 0 CREN = 1 Endif Return ; Done, baud rate now set!

The original idea for this came from an article written by Eddy Carroll www.iol.ie/~ecarroll/autobaud.html in April of 1989. The idea of which was, that a given character would be interpreted in unique bit patterns if sent at different baud rates, and assuming the receiver was set to a "fixed" baud rate.

In my example, I have enabled 4 different baud rate frequencies to be detected (4800, 9600, 19.2K, 38.4K). These just happened to be the 4 that would properly work with an oscillator freq = 40 Mhz, without producing excessive bit errors. Other ranges can be used, but will require a crystal change, and different SPBRG and BRGH settings, and possibly different comparison strings based on the incoming data.

Any ideas on how to impove it?
- 26th October 2005, 02:55
Melanie

Another solution is to use any PIC with an EUSART - Enhanced USART - (example 18F2525, 18F2620 etc). The EUSART has Automatic Baudrate Detection capability.
- 26th October 2005, 18:00
mytekcontrols

Quote:

Another solution is to use any PIC with an EUSART - Enhanced USART - (example 18F2525, 18F2620 etc)

Yes I would totally agree that this would be the best option as a hardware solution. And certainly would be the way to go, especially considering the additional RAM, Flash Memory, and EEprom capacities that come with it. Also for only about $1.00 more than the 18F252 (in quantities of 25 pieces from Digi-Key), it certainly is a bargain.

However, please bear in mind that although I have used an 18F252 as my text model, the software only approach to Auto-Baud detection can be applied to any PIC having the standard USART. For some this may be the way to go, especially with a large inventory of chips on hand, or where using an alternative less capable chip makes sense from a monentary standpoint.

Melanie I do have a question to ask of you on the 18F2525/18F2620 chips about some rumors floating around about some quirky issues with this family. I have not worked with this chip myself, and am wondering if any of the rumors are, or were true, but now corrected?

As always, thanks for your great insights and freely given experience,
- 26th October 2005, 18:36
Melanie

I don't like being the first kid on the block with any new technology. I've seen many people get burned. Two years ago there were too many issues with 18F's altogether. Corporate Management was pushing me on getting a lead time to market of sub-one month and the slightest chance of products not working was not an option.

Today, the Compilers and Assemblers work as they should, I have a thousand pieces of varous types working in the field without fault and am pretty happy all round. For example, I've replaced a 16F876, 24LC32 and Resonator with a single 18F2420 (without changing the PCB at all), and in process saved inventory, speeded up manufacture and significantly improved profitability of a popular board. No complaints.

I've not needed the capacity of a 18F2620, I have none actually in the field as yet so I can't comment on it. 18F2420 and 2520... no issues. I'm certainly not going to avoid the part if I need it.

Personally I think many problems are down to user application design flaws, poor PCB layout, or just picking the wrong part for the job.
- 27th October 2005, 02:27
mister_e

Quote:

Personally I think many problems are down to user application design flaws, poor PCB layout, or just picking the wrong part for the job.

I agree with that too. Poor supply filtering, poor component placement, poor PCB design, unsufficient ground plane, poor noise supression, floating I/O... are common problems. ONE thing, 18F are much noise sensitive than the 16F... WORST when you use 18LF. just be sure you're using the common sense when you design your PCB. I prefer to use external resistor instead of internal for a final design. Internal one are just 'virtual' IMHO.

Have we already talk about capacitor close to each and every ICs??? ;) Tantalum and ceramic are the one i use.
- 27th October 2005, 04:03
mytekcontrols

All good points, but it appears that some of the rumors are not just rumors. Here is a very recent erratta sheet issued by Microchip on these particular series of chips and the problems that have been due to as manufactured mistakes, and not due to inappropriate usage http://ww1.microchip.com/downloads/e...Doc/80224b.pdf

I am assuming that the problems as listed in this publication have been corrected in the new silcon coming off the production lines. So hopefully nothing new has crept in after the changes. Of course depending upon how the chips have been utilized in a particular project, these problems may have never been an issue.

Apparently the topic of this particular post "Auto Baud Rate Detection" was one of the areas where the chip's EUSARTS have had reliability problems.
- 27th October 2005, 16:51
mister_e

Quote:

Apparently the topic of this particular post "Auto Baud Rate Detection" was one of the areas where the chip's EUSARTS have had reliability problems.

mmm, interesting, as i say often the only person you should trust is yourself ;)

For the auto-baud, i'd never had the requirement for that so i can't comment on. Probably i'll never need it but in case of... i'll prefer my own method to detect instead of the PIC capability. mm i should try those i have here in stock.

Thanks for the info!
- 27th October 2005, 17:11
mytekcontrols

Steve,
I'll be ordering a couple 18F2525's today to also fool around with. When I get one set up for a test it'll be interesting to see what happens (I'll post my results here).

If you discover something, please let us know as well.

Thanks,
- 28th October 2005, 05:17
mister_e

Yup, i use 18F2525 and 18F2680 a lot now for various application. I got a thousand of them today. When i find some time, i'll give a try to the auto-baud-detection stuff..
- 30th October 2005, 16:41
mytekcontrols

2 Attachment(s)

Aotobaud Detect on 18F2525: A progress report...

Hi you all,

I got some 18F2525's yesterday. First thing I had to do was go to my workshop and put together an In-Circuit Serial Programming adapter for my new chip (I'm running this directly on a StampVue production board which doesn't have an ICSP). Previously I had been making due with this ugly thing pictured below:

<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=575&stc=1&d=1130687950 ">

But I thought it was about time I came up with a better solution. Something that would allow me to pop in any 28 pin device for testing purposes. So the "Ugly Blob" is no more, and in steps my "Universal 28 PDIP ICSP adapter".

<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=574&stc=1&d=1130687841 ">

All fun aside, lets get down to some actual tests.

Well I thought: "What the heck, this thing is an 18F series device, and the previous 18F252 was also. I'll just plug it in, don't change my code, and see what happens".

Well you probably know the answer to this one. Of course it didn't work, I ended up getting no video output on my StampVue production board. Hmm... what was wroung. I took out the scope probe and discovered some of my PortB pins were not producing the signals that they should, and then it hit me. Looking at the data sheet showed me that some of these pins are multiplexed as additional analog inputs, something that the 18F252 did not have.

So I needed to change the initialization value for ADCON1 to reflect my desire to have all the PORTB pins be Digital I/O, and only AN0 - AN4 be analog inputs (ADCON1 = %00001010). So now I got my PORTB outputs back, and also my video functions were restored as a result. However I noticed my analog inputs were not working. Delving back into the datasheet also showed that some rearranging, and an additional register had been added to deal with the added analog capability. The GO/DONE bit had been moved from bit2 of ADCON0 to bit1 instead. This allowed them to increase the channel selection bits from 3 to 4, by shifting the GO/DONE bit to the right. Also some of the other functions such A/D oscillator selection had been moved to a new register ADCON2.

After I got all of this sorted out, everything was once again working correctly (or should I say, I think it is).

Melanie and Steve, can you guys think of any other register changes that could cause potential conflicts when porting over to the 18F2525 from an 18F252? Like I said everything appears to be ok now that I have adjusted things in the ADCON registers.

Anyway, today I will try to run some tests on the AutoBaud Feature of the 18F2525's EUSART, and let you know what I find out.
- 31st October 2005, 02:17
mytekcontrols

Auto-Baud Detect 18F2525: Test Update

Success!!!

I tested the following code on a recently purchased PIC18F2525, which I do believe is a newer revision level then the earlier problem parts that Microchip reported.

Code:

'******************************************* ' EUSART Auto Baud Rate Detection ' PIC18F2525/2620/4525/4620 ' Author: Michael St. Pierre ' Date: 10/30/2005 '******************************************* DEFINE OSC 40 '============================================ ' Equates '============================================ rxdata VAR byte ' temporary storage for received data RCIF VAR PIR1.5 ' EUSART receive interrupt flag ABDEN VAR BAUDCON.0 ' Auto-Baud Detect Enable bit '============================================ ' Set-up EUSART for Auto-Baud detection '============================================ ' Note: The BRG clock source needs to be set for the optimum ' match at all anticipated incoming baud rates (we are optimized ' for a 40Mhz clock source and can detect from 300 to 115,200 Baud). TXSTA = %00100100 ' Transmit enabled ' BRGH set = 1 for High Baud enable RCSTA = %10010000 ' Receive enabled BAUDCON = %00001001 ' Auto-Baud Detect enabled ' BRG16 set = 1 for 16 Bit BRG counter '============================================ ' Program Start '============================================ ' The EUSART's built-in Auto-Baud Detect function waits to receive ' a single ascii "U" character as the synchronizing event. Once ' received and processed, the SPBRG and SPBRGH registers will be ' automatically set for the best possible baud rate match. While ABDEN = 1: Wend ' loop until Auto-Baud Detect is cleared... rxdata = RCREG ' then clear RCIF (discard "U" character) mainloop: While RCIF = 0: Wend ' loop until data present in EUSART buffer... rxdata = RCREG ' then retrieve data, TXREG = rxdata ' and send it! Goto mainloop ' Get next character

I tried it repeatably at baud rates spanning from 300 to 115,200 Baud with no apparent problems. Each and every time the baud rate was properly detected and set by sending a single ascii "U" character (uppercase).

It's not only nice having the Auto-Baud Detect as a built-in hardware function, but also very sweet to have a 16 bit BRG counter. This allows for a much wider range of usable baud rates as compared to the normal 8 bit version in the standard USART's.

I'm definately sold on this one!