In SX Microcontrollers, SX/B Compiler and SX-Key Tool, mrchadwickusa wrote: Hi Peter, I think the proof is the fact that Javalin did the test and the fifo overflows just when the error happens! I see from what you wrote above, that you are postulating that the receive clock and the transmit clock are *exactly* the same as the incoming data clock. Well, that isn't the case. The foreign data is faster, by some fraction, than the clock the SX is using to control the transmit of each bit. Internal to the SX the clock for receiving data and sending data is the same. It has to be unless you went to great trouble to do otherwise. But that isn't the same as being exactly the same clock rate that the PC used to send the characters the SX is receiving. That clock is almost surely different in speed to the SX interrupt rate, which is our receive and transmit clock for the SX. I think you are interpreting the received clock to be the SX ISR clock used to sync to the incoming data. That isn't what I was saying. What I'm saying is that the data we receive is clocked at 115200 but the data we send is clocked at 115000. That mismatch will have no effect on receiving individual characters (which we do with the 115000 baud clock), but the aggregate data rates being different, will cause the fifo to fill. There is no way around that! The whole point of having a fifo is to accommodate mis-matched data rates. Yes each character will be synchronized by it's start bit, but it still takes less time to come in than it takes for us to send it out. The received data rate, as transmitted from the PC is faster than the outgoing data rate from the SX. It doesn't matter how soon you transmit the characters relative to receiving input from the PC; you still take 10 bit times per character at whatever your transmit clock rate is. If the outgoing bit time is longer than the PC's transmitted bit time (what we received), you will fill the fifo and lose characters when it is completely filled. I think it would be good to try such a test setup, but make sure your SX's data clock is just a little slower than the input data source's clock. Your fifo will fill up eventually, unless you have pauses between your incoming characters. Another way to think about it that might make it clear would be to do the following: Draw a one inch line on some 10 square per inch graph paper. Call the 1 inch the character from the PC. Continue for some number of characters, putting a tick mark to indicate the boundaries of the characters, each character being 10 squares long. Below that line, starting 1.5 squares before the end of the first character, draw another line 10.5 squares long and repeat to simulate a slower outgoing bit rate than the incoming bit rate. Very quickly the start of your output characters will move past the start of the input characters and at that point the fifo will fill by one, and never catch up. Unless there is a pause in the input data. Yet another way to think about the fifo and mismatched input and output data rates would be to picture a can with a small hole in the bottom. Take a second larger can with a bigger hole in the bottom. Hold it over the first can, and fill it with water so that water comes out of the big hole and goes into the first can with the smaller hole. The bottom can will start to fill up, until the top can runs out of water. If the top can is much bigger than the bottom can and holds enough water, the can with the smaller hole will overflow. I will try to illustrate here with what I think is a fixed size font: Each input character is 10 [b]I[/b]s, each output character is 11 [b]O[/b]s. The first output starts halfway through the stop bit of the first received character. I used a [b]![/b] to indicate the border between characters. The [b]^[/b] is used to indicate when the input character has been completely received and ready to be transmitted. IIIIIIIIII!IIIIIIIIII!IIIIIIIIII!IIIIIIIIII!IIIIIIIIII!IIIIIIIIII! OOOOOOOOOOO!OOOOOOOOOOO!OOOOOOOOOOO!OOOOOOOOOOO!OOOOOOOOOOO! ^ first in ^ 2nd just ^ 3rd must ^ fourth must is sent makes it wait for wait for third immediately without 2nd out to finish having to finish so goes into to wait so goes fifo until into fifo transmitter until done with 3rd transmitter done with 2nd Notice how quickly the output starts to slip behind the input! This is a gross mismatch, but exactly the same thing happens with a small mismatch. The output character takes longer to send than the input character did to be received, and so the output gets further and further behind. Another analogy is an escalator, the speed of the hand rail never matches the speed of the stairs, so your hand either starts to go ahead of you or behind you. The easy solution for Javalin is to make sure his SX is outputting bits faster than the PC is sending them. In that case the fifo will never fill at all. It would at most have 1 character in it at a time. That would be like this where I use 11 [b]I[/b]s to be input and 10 [b]O[/b]s for output. Again the [b]![/b] is the border between characters, and the [b]^[/b] indicates when a character is fully received and available to be sent. IIIIIIIIIII!IIIIIIIIIII!IIIIIIIIIII!IIIIIIIIIII!IIIIIIIIIII! OOOOOOOOOO! OOOOOOOOOO! OOOOOOOOOO! OOOOOOOOOO! ^ ^ ^ ^ The output character takes less time to send it's 10 bits than the input character, so there is no problem keeping up. In this case the transmitter is always done before the next input character is done. For 50Mhz clock at 3x 115,200 baud the ISR count would be 144.67 cycles. If we round up to 145 cycles the real ISR rate will be 114,942 which almost guarantees the fifo will fill. If we round down to 144 cycles we get 115740 which should guarantee the fifo never fills, unless the PC transmit clock is faster still. In the first case we are .2% too slow, in the second we are .4% too high, but being too high is the preferable way to err in this situation where we have continuous input to process and then to output. Any pause in the input before the fifo fills up will also prevent the problem, but having a pause in input doesn't seem to be an option here. ---------- End of Message ---------- You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=2&m=109670#m112607 Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2006 (http://www.dotNetBB.com)