Auto Baud Rate Detection

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

[mister_e]

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!

[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,

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

[mytekcontrols]

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:



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



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.

[mytekcontrols]

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.

'*******************************************
' 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!