8-bit MicrocontrollersのトピックRe: QG8 Higher Baud Rates

QG8 Higher Baud Rates

datamstr — Fri, 20 Jul 2007 23:17:02 GMT

Greetings!

Using the QG8 internal clock, I can receive a byte (SCI) at up to 38400 BAUD. Has anyone got it working at either 57600 or 115200 BAUD? How did you do it? Do I have to go up to a "non-standard" BAUD Rate?

Thanks,
David

Re: QG8 Higher Baud Rates

peg — Sat, 21 Jul 2007 07:51:55 GMT

Hi David,

A search of the forums with the keywords QG8 baud revealed the following:

http://forums.freescale.com/freescale/board/message?board.id=8BITCOMM&message.id=2397

along with several others that cover this well enough I think.

Re: QG8 Higher Baud Rates

datamstr — Sat, 21 Jul 2007 09:51:08 GMT

Thanks Peg!

David

Re: QG8 Higher Baud Rates

datamstr — Mon, 23 Jul 2007 23:03:05 GMT

Hi Peg,

I set the Internal Clock Freq to 36 KHZ and the Baud Rate Divisor to 5. The CW Bean Inspector shows the Baud Rate at 115,200, so far so good. I am actually missing every other byte using the SCI Port even when the transmitter sends only a few bytes at a time. If I add a delay after each byte on the transmitter side, the SCI receiver does get every byte. Therefore I suspect that have a small mismatch on the Baud Rate between Transmitter and Receiver. So I have two questions:

1. Do I need to deal the the Trim Values or does CW take care of that?
2. What is the simplest method to measure the Internal Bus Clock? (9.216 MHZ)

Thanks So Much!
David

Re: QG8 Higher Baud Rates

peg — Tue, 24 Jul 2007 03:46:41 GMT

Hi David,

Your code should check for framing errors, then you could be pretty sure you have a mismatch. Also depending on what else the QG8 is doing you could be missing characters.

What happens if you slow the baudrate?

CW should handle the TRIM if it is set to do so.

One method to confirm baudrate is to get the SCI to output continuous stream of 'A''s. This gives a square wave you can check for timing.

Otherwise write a little port pin toggle programme and measure the frequency of the pin.

Are you completely missing chars of are some garbled?

Re: QG8 Higher Baud Rates

rocco — Tue, 24 Jul 2007 04:01:46 GMT

Hi David (both of you),

If you are missing every other byte, I would not suspect the baud rate. I would suspect something wrong within the SCI driver firmware.

Are you disabling the transmitter or receiver at any time other than initialization? Are you running polled or interupt driven? Are you getting overrun errors? How about framing errors?

Maybe if we could look at the code . . .

Re: QG8 Higher Baud Rates

datamstr — Tue, 24 Jul 2007 05:58:31 GMT

Hi Peg and Rocco,

I have posted my SCI ISR code below, now I am toggling a pin (PTB6) to scope when the ISR is executed.
Also, the SCI Interrupt is the only interrupt source. The only other code running is loading the SPI register and now I bypassed that as well just in case. The scope shows a pulse (PTB6) on every byte received so the ISR is executing on every byte, so my problem must be somewhere else in the code.

Thanks for your help!
David

** ===================================================================
**     Interrupt handler : isrVscirx
**
**     Description :
**         User interrupt service routine.
**     Parameters : None
**     Returns     : Nothing
** ===================================================================
*/
__interrupt void isrVscirx(void)
{
/* Write your interrupt code here ... */
if(SCIS1)             // Acknowledge Receiver Full Flag
    {
    PTBD_PTBD6 = ~PTBD_PTBD6;
    tmp_data = SCID; // Read the Data Buffer
    PTBD_PTBD6 = ~PTBD_PTBD6;
    }
}
/* end of isrVscirx */

Re: QG8 Higher Baud Rates

peg — Tue, 24 Jul 2007 19:28:40 GMT

Hi David,

Your simple ISR does not achieve a great deal as you just write the recieved data to one variable.

If your main loop does not service this variable at a rate greater than the byte rate then you will still lose the byte. So you may as well just poll for the recieved byte. If this is the case then slowing down the baudrate as a test will find this out.

Also I was presuming you are running the same code that you were before when you had this going before at 38400 baud. Is this the case?

Remember, 4MHz PC's used to be able to run 115kbaud serial ports.

Nowadays 2GHz ones require the help of a hardware FIFO buffer to be able to cope with much less than this.

Message Edited by peg on 2007-07-24 10:35 PM

Re: QG8 Higher Baud Rates

datamstr — Tue, 24 Jul 2007 20:30:55 GMT

Hi Peg,

Yes, indeed, I changed the ISR to simply grab the received character. I wanted to make sure there was no problem with a mismatch between transmitter and receiver at the 115,200 Baud Rate. I am actually receiving 96 bytes and putting each one in a buffer with a pointer. The ISR is doing the following:

1. Copy received byte to a buffer
2. Maintain Bytes Received Counter
3. Maintain Pointer increment and reset

Now that I have a pin toggle in the ISR, I can see how long the execution takes. I don't think the time spent is too long in the ISR and I have not optomized the code yet, but I shall see. Also, I am actually using a double buffer scheme for now. ie. Copy 96 incoming bytes to Buffer1 then copy the next 96 bytes to Buffer2 and keep alternating. When I ran at 38400 BAUD, the application perfomed OK.

I will post the results of my next test. I probably have some timing issues with the application. Also, adding some code for error checking would be a good thing.

Also, I have not kept up with Serial Communications on the 2 GHZ machines. Can you elaborate on this?

Thanks,
David

Re: QG8 Higher Baud Rates

datamstr — Wed, 25 Jul 2007 01:17:18 GMT

Hi Peg,

Well, I am bit puzzled at this point as I added some code in the SCI ISR to check for the value of the received character. Also, the code in main() has been shortened to a simple for(; loop and the COP is disabled.
At 115,200 BAUD I can detect the character 0x55, but not 0x54 and the transmitter is sending one character at a time. Normally, two pulses are seen on the scope, but when I transmit 0x54, the output pin does not generate two pulses even though the ISR has been executed. BTW, the scope shows the period of one bit at 115,200 BAUD to be 8.7 uS.

ISR Code:

if(SCIS1)             // Acknowledge Receiver Full Flag
    {
      PTBD_PTBD6 = ~PTBD_PTBD6; //toggle pin
      tmp_data = SCID; // Read the Data Buffer
      PTBD_PTBD6 = ~PTBD_PTBD6; //toggle pin
      if(tmp_data == 0x55)
      {
      PTBD_PTBD6 = ~PTBD_PTBD6; //toggle pin
      SCI_COUNTER = 0; // short delay between pin transistions
      PTBD_PTBD6 = ~PTBD_PTBD6; //toggle pin
      }
    }

Now if I change the code to check for 0x54, and send a 0x54 from the transmitter, the second pulse does not occur. I wonder why changing 1 bit in the character causes this effect?

Still investigating ...

Thanks,
David

Re: QG8 Higher Baud Rates

bigmac — Wed, 25 Jul 2007 02:23:35 GMT

Hello David,

Yes, at 115200 baud the bit period will be 8.7us, however the transmission period for one byte will be about 87 us. So if a continuous transmission of characters is received, you should observe a gap of 87 us between pulses at PTBD6. If the gap is twice as long, this would demonstrate the loss of alternate characters. Is this what you observe? Assuming a bus frequency of 9.216 MHz, the byte transmission period actually represents 800 cycles, so you are looking for processing delays of more than this amount.

Another test to confirm how many characters you are losing would be to immediately echo back each received character, within the ISR code.

You do not mention whether you checked for framing errors. If there are still baud rate accuracy problems (due to oscillator trimming issues), framing errors would be probable. Character dependent errors do suggest there might be a problem in this area. You might try the character value 0x40 to exacerbate the problem even further. This contains a run of seven bits with zero value. The 0x54 character has a run of three bits to produce bit timing errors.

Regards,

Mac

Re: QG8 Higher Baud Rates

datamstr — Wed, 25 Jul 2007 02:58:59 GMT

Hi Bigmac,

When transmitting 0xFF characters, the timing is 87 us between pulses. When transmitting 0x40, the problem is worse. I am missing one out of 4 characters sent and the time between pulses is about 108 us.
This indicates to me that the receiver is looking for more transitions before a character is actually received.

I have not added the error checking code yet.

Also, the TX pin is used for GPIO. I could change the config to TX output and scope it for timing.

Thanks,
David

Re: QG8 Higher Baud Rates

datamstr — Wed, 25 Jul 2007 03:22:48 GMT

Hi Bigmac,

The TX output bit period is 26 us, that sure explains the problem! (about 3 times longer than it should be)
How can CW be so far off in setting the trim value?

Thanks,
David

Re: QG8 Higher Baud Rates

datamstr — Wed, 25 Jul 2007 03:31:36 GMT

Hi Bigmac,

Forget about the last post, I made an error in the setting. The bit period on the TX output is 10 us, when it shoud be 8.7us. So the Bus Freq is running on the slow side.
Now that's a better explanation and it makes sense! The 26us period was way too far off to make any sense.

Now I just need to figure out how to calibrate the trim.

Thanks,
David

Re: QG8 Higher Baud Rates

peg — Wed, 25 Jul 2007 04:15:32 GMT

Hi,

So the problem is one of mismatched baudrate! (random post rater take note!)

The byte $55 is the easiest to get through on a mis-matched baudrate as it is a square wave and all those falling edges re-synch the reciever sampler.

Why not do like Mac suggested, in the isr, just tx the byte back out, now you can scope both tx and rx at the same time and compare - no silly errors reading the timebase etc.

Check your code for a write to the TRIM register.

Got to go now.

Re: QG8 Higher Baud Rates

peg — Wed, 25 Jul 2007 09:41:34 GMT

Hi,

Following on from my previous post....

Note that the programmer will calculate and programme a trim value into flash if you ask it to. However this value needs to be copied across into the working trim register at runtime by your code (or some generated by Codewarrior). You need to check that both of these steps are occurring.

My point with the fast modern PC was that at higher baudrates and no buffers you need to be careful about how often you service the serial port. With Windows etc a modern PC is much busier than before and even with the phenominal speed increases still struggles to keep up with high baudrates that could be done before when little else other than one programme was running.

Re: QG8 Higher Baud Rates

bigmac — Wed, 25 Jul 2007 10:55:47 GMT

Hello,

It is also possible that the programmer is calibrating the internal oscillator for a "default" frequency that is less than the required 36 kHz.

Note that, when a character value of 0xFF is sent, there should not be framing errors, even with severe baud rate errors. This is because all data bit values are the same state as the stop bit. This character value is not really suitable for testing purposes.

Regards,

Mac

Re: QG8 Higher Baud Rates

peg — Wed, 25 Jul 2007 11:39:17 GMT

Hi Mac,

I meant to touch on this, about the 36kHz. The OP said "I set the Internal Clock Freq to 36 KHZ". I am not sure where this setting is made (PE?).

The P&E programmer calculates the trim for 31.250kHz so maybe they fiddle it for about 36 when they move it from the NV register to the working one. I don't know!

Re: QG8 Higher Baud Rates

datamstr — Wed, 25 Jul 2007 21:46:05 GMT

Hi Bigmac and Peg,

I tried a few values in the TRIM register, it turns out that 0x7C results in the TX output bit period to be very close to 8.7 us. I reran the test using 0x40 value characters from the transmitter and it works great!!

I found Peg's comment very interesting about the receiver re-synch, I was not aware of this.
"The byte $55 is the easiest to get through on a mis-matched baudrate as it is a square wave and all those falling edges re-synch the reciever sampler."

I am now working on how to auto calibrate the ICS.

Out of curiosity, I tried to find where the NV_ICSTRM_INITVAL is actually initialized in Flash (0xFFAF), but so far I have only found the following Tip and #define in the MC9S08QG8.h file.

/* Tip for register initialization in the user code: const byte NV_ICSTRM_INIT @0x0000FFAF = <NV_ICSTRM_INITVAL>; */
#define _NV_ICSTRM (*(const NV_ICSTRMSTR * __far)0x0000FFAF)

I looked through the startup code as well.

Thanks so much for your help!
David

Re: QG8 Higher Baud Rates

peg — Thu, 26 Jul 2007 04:48:41 GMT

Hi David

You won't find an initialisation of NVTRIM($FFAE:FFAF) it is determined and programmed by the programmer irrespective of the code being programmed into the device (if enabled to do so). You will only find (hopefully) code to move these values into $3B:3A.

Where did you specify that you wantes 36kHz?

David