Serial with RCFast

crgwbr

I have heard some people say that Serial Communication with a PC is impossible if your using RCFast instead of a crystal. However, unfortunately, a project I'm doing requires this. The reason I think it might be possible, is that when a propellor is being programmed by a PC, it is communicating Serially and it is running off an internal resonator. Has anyone had experience with this problem in the past.

Thanks,
Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Blog: Prog | Electro | Mech

I would love to change the world, but they won't give me the source code

People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.

I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"

Mike Green

Craig,
When the Propeller is being programmed, it has no idea of the Baud being used. The programming protocol uses what's called a ratiometric system. If you consider the bit times in an asynchronous serial character (including the start bit), you've got 9 bit times or 3 x 3 bit times with the first bit always a zero. If you make the first bit of every group of 3 a zero bit and the last bit of every group of 3 a one bit, you can encode a data bit in the middle bit. The width of the zero pulse is always 1/3 or 2/3 of the total time for the "cell". The width of the one pulse is always 2/3 or 1/3 of the total time. It's very easy to derive the timing from the data coming in and the Propeller can adjust the timing continuously.

The problem you get into with the RCFast oscillator is that you don't know its frequency at all for a given Propeller chip ... it can vary over a fairly wide range. If you have some way to determine it, it will remain fairly stable over short periods of time, but will slowly drift with changes in temperature and supply voltage.

If your PC program can send a calibration sequence, the Prop can adjust its serial timing. You could write your own serial routines that would check for pulse edges and adjust the timing. You're not guaranteed that any given bit time would have a transition (0-1 or 1-0) that you could identify, but you'd have at least one identifiable edge in a given character and you could compare when it actually arrives with when it's expected and adjust your timing accordingly.

crgwbr

So, if I were to write my own drivers, would something like this work?

PC -> %00111100

Prop -> Times how long the High pulse is, then divides it by 4 it get bit time. Then uses the bit time to communicate normally with PC.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Blog: Prog | Electro | Mech

I would love to change the world, but they won't give me the source code

People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.

I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"

Mike Green

I'd probably use %01111000. The start bit is always zero. This way you'd have a series of 4 zero bits, then 4 one bits. You'd look for the 1 to 0 transition, time the zero pulse, time the one pulse, compare the two times (should be the same or nearly so), then divide by 4.

You'd still need to adjust the bit time over time by looking for bit transitions starting just before they're expected. If they seem to occur early, shorten the bit time a little. If they seem to occur late, lengthen the bit time a little.

crgwbr

Thanks, this should be quite a challenge to do properly. At least I'm getting paid for it.

Thanks,
Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Blog: Prog | Electro | Mech

I would love to change the world, but they won't give me the source code

People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.

I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"

Beau Schwabe

crgwbr,

There are many forms of Serial Communication. Asynchronous serial communication is what you are referring to, and it is one of the more common forms of serial communication. It requires that both communication ends have a precision time base in order to process information correctly. Opposite of that is isochronous or Synchronous serial communication. In this form you have a separate clock signal that is sent along with the data. In other forms of Synchronous serial communication, the clock signal can be embedded within the data stream so that only one I/O line is required. Here are a few forms of Serial communication:

Asynchronous serial communication (one wire interface):
RS232C serial standard - PBASIC SEROUT/SERIN
Modems using MNP2 (v2)

Synchronous serial communication (two wire interface):
SPI - PBASIC SHIFTOUT/SHIFTIN
I2C - PBASIC I2CIN/I2COUT

Synchronous serial communication (one wire interface):
8B/10B encoding - used in Firewire
Manchester code - used in Ethernet
Modems using MNP3 (v5)
MFM - used in magnetic media storage (disk drive/tape drive)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 7/24/2007 3:50:59 PM GMT

Bean

There was a recent post about the D-BUS interface using by TI calculators.
I found it very interesting, it uses 2 wires and the speed is controlled by both sides.
I don't know why it is not used as a general communication interface. It seems like a great protocol for microcontrollers.

It has two signals that are pulled-up with resistors. So when both lines are high the bus is idle.
If the sender wants to send a zero, it pulls the "A" wire low. When the receiver "see" that the "A" wire is low, it shifts in a zero bit and pulls the "B" wire low. When the sender sees that the "B" wire is low, it releases the "A" wire (which is pulled-up). When the receiver sees that the "A" wire has gone high, it releases the "B" wire.

To send a one, the same thing happens except on the opposite pins.

So either side can take as long as it needs to process any bit. And either side can initiate a send.

Seems like a great protocol to me...

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Teacher: What is the difference between ignorance and apathy ?
Student: I don't know and I don't care
Teacher: Correct !
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·

crgwbr

It would be great if I was able to use one of these other protocols, but I am stuck with RS232. I think I am going to have to write my own drivers, just using some kind of start byte to find bit times; any help or suggestions would be greatly appreciated.

Thanks,
Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Blog: Prog | Electro | Mech

I would love to change the world, but they won't give me the source code

People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.

I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"

Tracy Allen

Another option, if you have a real time clock chip that has a square wave output (e.g., DS1307), is to use that to measure the frequency of the RCfast. Then use that number in the bit time calculation. That has to be recalculated from time to time as temperature changes.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

crgwbr

Thanks for the tip. But, unfortunately, I do not have an RTCC on the PC board. I didn't think I would need one at the time I designed it.

Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Blog: Prog | Electro | Mech

I would love to change the world, but they won't give me the source code

People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.

I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"

crgwbr

I wrote a bit of code to act as a baud rate finder. However, it doesn't seen to be working. I'll post it, if possible please take a look over it. I'm sure that it is something stupid I am forgetting.

Thanks,
Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Blog: Prog | Electro | Mech

I would love to change the world, but they won't give me the source code

People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.

I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"

Mike Green

crgwbr,
Your code won't work unless the I/O pin is #0. It's the WAITPEQ for the serial line to go high. I like to use WAITPNE with a zero as the first parameter. That way I won't get into trouble if I use the wrong state compare value.

deSilva

Bean (Hitt Consulting) said...
.. D-BUS interface .....If the sender wants to send a zero, it pulls the "A" wire low. When the receiver "see" that the "A" wire is low, it shifts in a zero bit and pulls the "B" wire low. When the sender sees that the "B" wire is low, it releases the "A" wire (which is pulled-up). When the receiver sees that the "A" wire has gone high, it releases the "B" wire.
To send a one, the same thing happens except on the opposite pins.

This is a very nice "self-clocking" protocol with built-in error detection (mind you need an additional time-out detector!)

At the first glance it does not seem to have any advantage over I2C with clock stretching, but it is a "no-master" protocol and very flexible wrt to speed....

crgwbr

Mike Green said...
crgwbr,
Your code won't work unless the I/O pin is #0. It's the WAITPEQ for the serial line to go high. I like to use WAITPNE with a zero as the first parameter. That way I won't get into trouble if I use the wrong state compare value.

Thanks Mike! So, basically your saying that instead of:

rx_en := |< rx                                       'Decode Rx into 32-bit binary values
waitpeq(1, rx_en, 0)                                 'Wait for Rx line to go high

I should use:

rx_en := |< rx                                       'Decode Rx into 32-bit binary values
waitpne(0, rx_en, 0)                                 'Wait for Rx line to go high

Did I interpret your answer correctly?

Thanks Again,
Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Blog: Prog | Electro | Mech

I would love to change the world, but they won't give me the source code

People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.

I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"

Mike Green

Yes. Do you understand why?

crgwbr

No, not entirely. It seems like waitpne and waitpeq are exactly the same except that waitpne is applys a 'not' gate to the pin. If you have time, it would be nice to have an explanation.

Thanks,
Craig Weber

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Blog: Prog | Electro | Mech

I would love to change the world, but they won't give me the source code

People say that if you play Microsoft CD's backwards, you hear satanic things, but that's nothing, because if you play them forwards, they install Windows.

I spent a minute looking at my own code by accident. I was thinking "What the heck is this guy doing?"