Propeller stand-alone

Rsadeika

Somewhere along the line, I thought I read that the Propeller can be programmed, and used without the eeprom or the crystal. I also vaguely remember that the internal crystal is about 4 MHz, so how fast of baud rate could I achieve in this configuration, and how stable would this be. Having worked with the SX chip, the recomendation was not to use the internal crystal for any comm work, is this also true with the Propeller. Also, I have not seen an example program using this configuration, what would be the necessary lines of code for this.

Thanks

Ray

Leon

You can run programs from RAM without a crystal or EEPROM. The program will be lost when power is removed, of course.

It hasn't got an internal crystal. The internal oscillator isn't stable or accurate enough for RS-232.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

Post Edited (Leon) : 1/13/2008 7:06:12 PM GMT

deSilva

In my classes and with many experiments I use the propeller without EEPROM, crystal and supplied by a 3.7 LiPo cell, reducing the voltage through a Schottky diode.

It does not take much to add a crystal (which is 25 EuroCents), and you need no additional cap load.

The internal RC oscillator - running around 12 MHz BTW - is not stable as Leon already remarked. It will not even work for lowest bit rates as 1200 Baud.

For a stand alone version you need of course an EEPROM

hippy

I'm not sure it's that the internal oscillator isn't stable, just that there's no easy way to know what speed it's running at. Nominally RCFAST is 12MHz, but can be anything between 8MHz and 20MHz.

If the oscillator is relatively stable during running and consistent across power-cycles it should be usable for reasonably accurate timing ( serial ) although each chip would require calibrating.

Even if only stable during running and not consistent across power-cycles it could be calibrated at each power-up. One could measure the byte/bit timing of a received byte to set the baud rate. That could be done at the start of every data transfer if there were oscillator drift long term but less short term.

If the internal oscillator did drift widely at run-time I wouldn't have thought the download protocol would have worked as well as it does.

deSilva

Have you ever used an RC oscillator?

Phil Pilgrim (PhiPi)

Stability is a relative thing. An RC oscillator is fine for asynchronous serial I/O, assuming it's getting input at regular intervals, from which it can resynchronize its timing. The simplest way to do this is with a command/response protocol that begins with an exclamation point (!) or some other character whose LSB is a one. This permits retiming the serial clock at every transaction, using the width of the incoming start bit as a reference.

-Phil

hippy

deSilva said...
Have you ever used an RC oscillator?

Frequently; PICAXE and PICmicro. Internal RC oscillators there are rated to +/-1% accuracy in the right conditions, and +/- 2% over most 'normal' voltage and temperature ranges. Some models aren't as well spec'd.

It's far from perfect but well within the +/-6% accuracy required for a serial stream. I've bit-banged 38400 baud with no noted problems.

Maybe the RC in the Propeller is "simply Smile" but I wouldn't have thought so, although I admit I haven't tried it. The proof's in the eating

Leon

The stability doesn't seem to be mentioned in the spec, unlike those for some PICs, so I wouldn't use it for RS-232.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

deSilva

ATMEL's Mega ATs are specifically calibrated on part basis; the calibration data is put into a special non volatile register, which is extremely practical. The only effect to be considered is temperature. I seem to remeber that this is about 1% per 10 centigrade, but this is from my memory only...

Rsadeika

Thinking out loud, I wonder why Parallax did not go with an accurate internal oscilator for the Propeller. The chip is rated for 80 MHz for reliable use, so why not make it an accurate internal oscilator.

Ray

deSilva

This is not possible technically. The second best solution is a hybrid with a crystal on it. Take the SpinStamp. This is an excellent device! Everyone I showed it had to admire it!

hippy

I think the question is why the Propeller's RC isn't anywhere near as accurate as others. Some manage +/- 1%, Propeller manages -50%/+60%. I expect it is down to manufacturing / process.

Phil Pilgrim (PhiPi)

The controllers that spec 1% have internal clock adjustment registers that trim the RC clock using data that's programmed in post-manufacture. The oscillators themselves are probably no better than the one in the Propeller. It's just that their timing can be adjusted via a register setting.

Because the Propeller is capable of such timing flexibility as regards its counters and PLLs, it may have been felt on the part of the developers that being able to adjust the system clock, too, was superfluous. This is to say that one should be able to come up with a FRQx and PLL setting that, once calibrated, will give a baudrate clock of equivalent accuracy to the adjustable system clocks in other controllers.

What remains to compare are the various clock stabilities over temperature, once the system clock or counters/PLLs have been calibrated.

-Phil

Mike Green

The main problem with the RC clock is that the Propeller has no standard timebase and the RC clock speed can vary widely from chip to chip and with significant changes in temperature and supply voltage. In most applications, the RC clock would be stable enough to do asynchronous serial I/O since the regulated supply voltage would be stable and the temperature would be fairly stable in an indoor setting. If a sync byte were used to establish a calibration point, there should be no problem using the internal clock. Crystals are really cheap and don't take much board space and simplify the whole thing.

stevenmess2004

Isn't loading the program done using the internal RC clock? If it can reliably program the chip why not other communications? At least as a receiver.

Steven

Phil Pilgrim (PhiPi)

During program uploading, normal asynchronous serial communication is not used, but rather a special protocol which doesn't require an accurate baudrate.

-Phil

stevenmess2004

So how hard is it to use for something else. Sounds like it could be useful.

Steven

hippy

The download protocol is just a series of pulses, a short one indicates a 1-bit, a long one indicates a 0-bit, a pre-download sequence allows the Propeller chip to determine what the length of the pulses used will be. The receiver compares the length of each pulse received with the lengths expected and builds up data a bit at a time. It's not that hard to implement. More details in forum elsewhere.

A similar 'timing calibration mechanism' is to send a serial byte of known value so the Propeller can determine bit timing and then read a genuine serial byte sent after it. If the oscillator doesn't drift too much the byte can be read using that calibrated bit time. It's very easy to add an extra two bits to the front of each serial byte transmission to provide that bit time calibration for Propeller-to-Propeller communications. I think that should work, others aren't so confident.