• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 650 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Clock Selection

Hector Tosado
Prodigy 190 points


Hello,

I've been diving into the world of Microprocessors these couple of months and been reading a bit of literature to try and get up to speed to work in a school project. To start working in any project related to UART I've noticed that the selection of the correct Clock frequency, in order to get the best baud rate possible (if possible perfectly calculated) is really important to avoid errors in the transmit and receiving of data. The LM4F120H5QR has the possibility to divide into a variety of possible clock frequencies since it has the PLL at 400MHz, a 16MHz oscillator and the hibernation clock. These clocks can be chosen and then divided into a integer value from 3 to 128, given the SYSDIV bits in the RCC and RCC2 register, and the obligated HES bit (8 or 16 integer) that further divides this clock. This clock is then divided using the the auto-baud generator allows us to choose a baud rate dividing the clock chosen by an integer in the range of 2^16 bits with a fractional part of 6 bits. After ALOT of number crunching I was able to retrieve baud rate of 115207.373 which was the closest to 115200 (which is my target baud-rate because I want to transfer data from pictures I'm capturing at the fastest rate possible). This gives me a max error rate of 0.06% (see link below). Now a couple questions pop into my mind after all this, if all my components can reach 115200 baud rate, would i have trouble with my micro baud rate being over by 7 (115200->115207.373), and is there actually not a clock frequency that I can successfully divide exactly into a common baud-rate using the Stellaris?

P.S for the number crunching I used 400MHz (Only taking into consideration the max of 80MHz), 200MHz(Max of 80MHz), and 16MHz. The successful clock frequency was 3571428.571 or 3571428.571*2. 

http://mspgcc.sourceforge.net/cgi-bin/msp-uart.pl?clock=3571428.571&baud=115200&submit=calculate 

As well, I check all the possible pins and their optional peripherals that I can choose from. None had a possibility of adding an external clock. Possible way to solve this? Or I have to make due with the ones already on the board. 

Thanks! Will be waiting to answer any type of misunderstanding. 

  • 0
    Mastermind 9890 points

    UART transmission will work properly if both devices are within 2.5% of the specified baud rate.  .06% is incredibly precise for UART baud rate.  Often the clocks on parts being used in the communication network themselves are not precise to 1%, so having a dead-on baud rate for your UART won't make any difference.

  • 0 in reply to slandrum
    Guru 117855 points

    Recalled that 2p5% number from long past - here's quick/dirty "back of envelope/napkin" calc. to confirm:

    To simplify - let's choose 9600 baud - 8 data bits - 1 Start - 1 Stop.  (10 bit package)  Now 1/9600 = 104uS bit time - let's round to 100uS.  (logic/reasoning applies similarly to most all baud rates - not just 9600 - although I'd tighten spec at highest speeds...)

    So - we have 10 successive bits to "capture" - assume that we attempt to "sync" - TX and RX - by reading each bit at its "projected" center.  This implies that our receive side must "read" every 100uS - and commence this "read sequence" some 50uS after the Start Bit's detection.  (we start the read critically here - so that we read each bit nearest its center)

    Now the final serial bit (Stop) will be "centered" 950uS after Start bit's lead transition.  This Stop bit will exist between 900 - 1000uS after the Start bit's onset.  To best read this bit - our receiver must measure the serial signal line 950uS after the Start bit's onset.  If we read either 50uS too soon - or too late - we'll read "outside" of the Stop bit's legal time-frame - and most likely error. 

    Thus 50uS is our maximum, total (accumulative) allowable error.   And 50uS/1000uS yields 5% - not Slandrum's suggested 2p5%.  However - we've dealt only with "one side" of our communication channel - in worst case scenario - TX and RX may err in opposite directions!   (Ratz)  It is this "opposite error condition" - one too fast - the other too slow - which cuts our 5% error margin in half!

    By holding both TX and RX w/in Slandrum's 2p5% spec. - the total error cannot exceed our 5% "error budget" - (50uS this case) - and our commo is likely to succeed.  (provided we get "all else" right)   It is the absolute value of this error difference that is crucial... 

  • 0 in reply to cb1_mobile
    Prodigy 190 points

    Thanks alot for them comments. Loved the timing explanation alot, made me understand the UART communication a bit more. We're going to go ahead and use the clock that gives us the 0.06% and keep you posted of any good or bad developments. 

  • 0 in reply to Hector Tosado
    Guru 117855 points

    @Hector - Kind comments such as yours always appreciated - makes time/effort worthwhile.

    Had hoped that some here would find my analysis of some interest/value...   Thanks...