8-bit Microcontrollers中的主题 Re: SCI port initialisation

SCI port initialisation

miSta — Mon, 04 Jun 2007 02:27:30 GMT

I am wondering .. i'm looking at the demo9s08app.c and it seems that every time a character is sent , it opens the port
send : SCIC2 =0x08;
receive: SCIC2 =0x04;

but when i initialised the port in my own code , at the start , i will get an initial word .. ( eg. Hello ) followed by funny characters ...

i talked to some pple , and they said that i have to calibrate the chip with ICSTRIM using an oscillator ...
a thread has mentioned this as well .. (internal ref clock accurate ... thread)

what is the difference between the demo app file usage and the intention of opening the port from the beginning ?

*just wondering*

Re: SCI port initialisation

peg — Mon, 04 Jun 2007 06:02:08 GMT

Hi miSta,

Even though I was the one that pointed you at this code, I had never really looked into it much.

It does turn the TXENA and RXENA on and off all the time. I don't know why they are doing this. The more normal case is just to enable both along with the rest of the SCI initialisation (baudrate etc) and just leave them on.

Re: SCI port initialisation

bigmac — Mon, 04 Jun 2007 10:03:21 GMT

Hello,

Setting transmit enable prior to sending each character, and then disabling, will have another side effect. Whenever the TE bit is set active, an "idle" character will be queued. With continuous enabling and disabling, this would give a one character space between each group of send characters. For many applications, this delay would be unnecessary and undesireable unless the remote end were to need a small "end of line" delay.

The only other reason I can think of is, if the code were "lifted" from an application that had Tx and Rx lines common (paralleled). Of course, for the 'QG8, this mode of operation may be directly configured.

Regards,

Mac

Re: SCI port initialisation

miSta — Mon, 04 Jun 2007 11:48:08 GMT

Yeah .. that's the normal case to keep the ports open ..that's what i am doing
but as i mentioned earlier .. by keeping it opened, i get a funny character like looping2 ...

but as mac mentioned , the on and off of the ports gives out a character space, so in other words , to emulate it , i would have to code a stop bit , if i were to leave the ports on at the start of init. ? (with baud rate ec ?)

Re: SCI port initialisation

peg — Mon, 04 Jun 2007 12:14:33 GMT

Hi,

I have no direct experience with this, but as I understand it, no idle char would be queued.

In order to do this you must TE=0 while the shifter is still busy. The code presented does not do TE=0 until TC.

Message Edited by peg on 2007-06-04 03:18 PM

Re: SCI port initialisation

bigmac — Mon, 04 Jun 2007 22:27:25 GMT

Hello,

How are you monitoring the characters sent by the SCI? The "funny characters" may be a representation of control characters that might be unknowingly sent. If you are terminating your string with a null character, is it possible this is being sent?

The actual representation of control characters may depend on the terminal program in use, assuming this is what you are using. The idle "character" will be seen as a delay, and should not generate any displayed character.

Peg,

The following is an exerpt from the 'QG8 data sheet -

The transmitter is enabled by setting the TE bit in SCIC2. This queues a preamble character that is one full character frame of the idle state. The transmitter then remains idle until data is available in the transmit data buffer.

Another excerpt from the same section -

Writing 0 to TE does not immediately release the pin to be a general-purpose I/O pin. Any transmit activity that is in progress must first be completed. This includes data characters in progress, queued idle characters, and queued break characters.

So it would appear that the idle is queued when first enabled, and when disabling the transmitter, this does not take effect until the transmit buffer is emptied and transmission is complete.

Regards,

Mac

Re: SCI port initialisation

miSta — Tue, 05 Jun 2007 00:17:38 GMT

hmm..
So that means that when i first initialised the ports (rxd and txd)the ports are enabled , and when transmission is completed, it turns to a general i/o port ?
so when i want to transmit another character , i still have to enable the transmit ports ?
or is it that after i sent a transmission and it is completed , i can leave it at idle? (my mate says we could do that .. he does it in assembly , and i'm doing it in C )

i'm pretty much confused at the moment
but 'm going to 'try' to get the chip calibrated .. (using oscilloscope)

Re: SCI port initialisation

peg — Tue, 05 Jun 2007 05:58:43 GMT

Hi miSta,

Don't worry, if you set TE and RE it will stay enabled always. What we are talking about here is clearing TE during shifter operation won't revert to GPIO until the shifter is finished.

This little side issue being discussed does not really affect you. It only affects rapid, high turn-around communications.

Mac, those excerpts certainly look very clear in that it will happen. I didn't see these before but I did see these which seem to muddy the waters somewhat:

TE also can be used to queue an idle character by writing TE = 0 then TE = 1 while a transmission is in progress.

and this:

Normally, a program would wait for TDRE to become set to indicate the last

character of a message has moved to the transmit shifter, then write 0 and then write 1 to the TE bit. This

action queues an idle character to be sent as soon as the shifter is available. As long as the character in the

shifter does not finish while TE = 0, the SCI transmitter never actually releases control of the TxD1 pin. If

there is a possibility of the shifter finishing while TE = 0, set the general-purpose I/O controls so the pin

that is shared with TxD1 is an output driving a logic 1. This ensures that the TxD1 line will look like a

normal idle line even if the SCI loses control of the port pin between writing 0 and then 1 to TE.

Although I have not used this idle wakeup before I will be soon on a GT16A so I will see what happens there. I believe I have already detected a bug in the silicon in the SCI there, but want to test further first (by comparing with QG8).