mc9s12dp256 - Problem with transmitting out a stream of bytes through SCI..

[Dev]

Hi!

Firstly, let me explain what I'm trying to do.
I'm using mc9s12dp256.

The idea is to

->transmit a stream of bytes from one mcirocontroller
to another(say from muc1 to muc2) thru SPI- this part works fine.

->next the received stream of bytes in muc2 are to be
sent out on the SCI to the hyperterminal on the comp
thru RS232.

Everything is being done using interrupts.
Now, at the receiver end(i.e.muc2) the Interrupt Service
Routine for both SPI reception and subsequent SCI transmission has been written.

The sequence of events that occur( as I've understood them)are as below- if I'm wrong, please correct me
1. muc1 transmits 1st byte. At the receiver end, since
SPTIE interrupt is enabled, on receiving the byte, an interrupt will be raised, followed by copying the byte in to an array.
2. mean while, in SCI, since TIE and TCIE bits are set, the corresponding interrupts are enabled, and for the 1st
byte since TDRE and TC flags are set, an interrupt is raised and the byte must be sent out.

But, here's where a potential timing problem arises. If the SPI is programmed to receive data @ a rate slower than the SCI can transmit, then the SCI will end up skipping a few bytes.

To overcome this, what we did was, we equated the time taken for SPI to receive 8 "bits" with the time taken for the SCI to transmit 10 "bits"( 8 data+ 1 start+ 1 stop) and found out the value to be loaded into SCIBDL. Is this how it is done? What other method can be used to transmit data out from SCI with out timing data errors occuring in the program that I've described above?

Added p/n to subject.

Message Edited by NLFSJ on 2008-02-29 09:15 AM

[mke_et]

I have a question... Actually, a problem understanding why SCI speed has to be matched? That's what start and stop bits are for in the datastream, so that characters have definable start and stop edges, and they do not have to be 'sync'ed to anything. Each 'character' is it's own little world.

Now, you're probably trying to trigger an event on the far end at conclusion of data, where you can't detect it from the data contained in the stream. So just have a timer running at say the equivilent rate of 5 characters on your SPI stream. Every received character on the far end resets the timer. When you see the idle period timeout, you know it's done. Then you can run your SCI as fast as practical and not worry about it's timing at all, as long as you stay ahead of the SPI.

[colinh]

Hi Dev

How did you go with this?  One thing I couldn't work out from your post is "What are your fixed requirements?"
ie Is there a minimum data throughput you need to achieve? For simplicity I would start with that requirement first.  Design your SPI speed to be maybe 25-50% faster than your desired minimum throughput, and then if practical set your SCI data rate to the lowest speed that is say at least 40% faster than your SPI rate.  If you take this approach then there is no need for buffering and you can Tx on the SCI directly from the SPI interrupt, and you do not need to use the SCI interrupts at all.  Be warned that this simple approach has limitations, but if you have good control over what is going on at both micro's then it should work quite well.

Cheers
Colin

[bigmac]

Hello,

If the SPI bit rate is always slower than 80 percent of the chosen SCI baud rate, simply put each byte to the SCI, as it is received.  A gap will occur between successive SCI bytes, but this does not matter for an asynchronous transmission.  If there are no other complications, the use of a send buffer and the SCI send interrupt would seem unnecessary.

Regards,

Mac

Message Edited by bigmac on 2008-03-04 12:29 AM

[JimDon]

- First I would think that you want to use a standard baud rate for the SCI, not one you just calculated. Your calculations would indicate the minimum standard baud rate that would work, but I would think you would want to move that up to the nearest standard baud rate.
- In any event you should have a buffering system, so that the timing does not have to be 1:1.
- If the data from the SPI is continuous the SCI must be faster. If the data in not continuous, it would be possible to let the SCI fall behind with buffering then catch up.
- The larger the buffer, the further the SCI can fall behind.