Hi all,
This might be redundant but I did a fair bit of searching in the forum before turning to you guys again.
I am using a GT16A and I wanted to use the SCI with a LCD display which has a 9600 bps baudrate. When I configured the baud rate of the GT16A , the closest I could get was only 9615.385 which is about 0.1% accurate, but I am afraid that I accumulate over time and become corrupt. The display takes a start bit + 8 bits + stop bit (no parity).
Is there any way to resolve this issue? Any suggestions guys?
Thanks
Karthick
Not an expert here, but the frequency seems close enough.
Do you experience any issues?
After the 10th bit, the measurement is just 1.5% (0.16%*9) off, I would think this should still be fine.
Note that there is no accumulation across multiple bytes received, the SCI synchronized on the start bits again.
Daniel
One more thing I wanted to put out to you guys -
I calculated that if I shave off about 6.4k from the MHz and then use 26 as the baud rate divisor the baud rate is exactly 9600bps. So how do I fine tune the Bus frequency, I need to get 8MHz - 12.8kHz.
Hello Karthick,
This much error is well within acceptable limits for reliable communications.
The reciever resyncronises on every negative going transistion, worst case is every byte.
It may depend on what sort of reciever is at the other end and whetether it properly re-syncs.
If you are using the internal clock, you can offset the internal oscillator this much to achieve exactly 9600 baud. Otherwise you would need to change to an external device that produces the correct frequency when divided down.
Thanks peg
could you tell me how I can alter the internal clock (by that do you mean the bus clock?) to get a better frequency so it divides nicely. I worked it out and it turns out to be 8MHz - 12.8kHz = 7.9872MHz and this when divided by 16 and 26 and 2 gives us 9600. So any suggestions ?
Cheers
Karthick
Hello Karthick,
Using standard the trim value for the ICG, there are many bus frequency alternatives that give a baud accuracy of about 0.25 percent. However, keep in mind that the ICG itself has a tolerance over temperature and voltage of typically 0.5%, but 2 percent worst case. The SCI module receive process will tolerate a baud error of up to about 4 percent.
In your case, the allowable baud error will depend on the LCD display hardware, and maybe whether this is crystal controlled within the display. However, I suspect that the send baud accuracy from the MCU should be adequate.
If you wish to adjust the ICG trim value, without the need to implement your own calibration procedure using an external timing reference, the calculated (or experimental) constant trim offset relative to the standard trim value ( for 243kHz reference) would need to be as small as possible.
Using the internal reference, the available bus frequencies with standard trim, and assuming a reduced frequency divisor of 1, are as follows:
Bus(MHz) Baud div. Error<=0.26%
4.443 29 *
6.665 43
8.887 58 *
11.109 72
13.330 87 *
15.552 101 *
17.774 116 *
19.995 130 *
.
.
Regards,
Mac
Hi Mac,
I tried to sort out the 9600 bps but couldnt get it. It seems like the serial is working fine but the LCD isnt printing the right characters on the screen, so I am left to think that its somthing to do with the baud rate. Hence How do I get a baud rate of
7.9872 MHz. IS this possible or not? I am only using the internal clock generator (No external XTAL).
So please let me know that would be nice. Thank you in advance.
Cheers
Karrthick
Hello Karrthick,
I think you mean a bus frequency of 7.9872 MHz? Using the standard trim setting for the internal reference, only the bus frequencies previously listed are avaiable. You would need a very significant departure frim this trim setting to achieve 7.9872 MHz, which would require a special calibration procedure using an external frequency source - to be avoided if at all possible.
If you were to choose a nominal trimmed bus frequency of 8.887 MHz (using multiplier value 8), a baud rate divisor of 58 should give a baud rate error of about 0.25 percent. I re-iterate that this should be sufficiently close to the required baud rate, without the need for further trim adjustment.
Perhaps you should post your current code for the clock generator and SCI initialisation.
Regards,
Mac
Ok i got it working!
You were right Mac. it seems like 9615 is close enough. I had to fiddle around a bit. But its good now. I wanted to know something else though. This is what my serial code looks like (I am not using interrupts here).
SCI1D = i;
while(SCI1S1_TC == 1)
{ }
and in the main for loop i have
for(;
{
LCD_write('y');
LCD_write('o');
/* __RESET_WATCHDOG(); by default, COP is disabled with device init. When enabling, also reset the watchdog. */
} /* loop forever */
LCD_write() is the function that contains the first piece of code.
Now I did notice on the LCD screen that it displayed a series of y's followed by a series of o's ! It should have been a series of yo's continuously instead!
This has led me to think that I am using the wrong approach to serial communication here. So please tell me if i am actually missing something out ? like the transmit buffer or something of that sort. Also I wanted to know what your approach to this would be like?
Please advice.
Cheers
Karthick
Hello Karthick,
I notice that this query has been posted twice within this forum. Please do not post the same question more than once.
Your test of the TC flag is incorrect -
The following send function should normally work -
void LCD_write( byte val)
{
while (!SCI1S1_TDRE); // Wait until ready to send
SCI1D = val; // Send character
}
If problems should remain, is it possible that the LCD display requires a delay between the sending of consecutive characters?
Regards,
Mac
Sorry about the redundant post.
And thanks for the info Mac. I got it working now!
I also wanted to know how to transmit serially without the use of the PE micro USB multi link interface. I am using it to load the program into flash. The issue here is that whenever i use the PE micro USB multi link interface to burn the program into flash my LCD display works but when ever I disconnect the PE micro USB multi link and just connect it to the power source the LCD display dosent seem to work.
So any suggessions? what do you think is happeniing?
Cheers
Karthick