Propeller OS versions - what about CLKFREQ & CLKMODE ?

Cluso99

A few of us have developed different OSes for the Prop. This question is more of a common issue to all of these OSes...

Let me describe the background/usage first.

I regularly move my microSD card between my various prop boards. This is not a normal situation as most users probably use the one SD card for a board type.

My EEPROM BOOT program only knows which pins the SD card uses. It then reads the SD and looks for the file AUTOEXEC.BAT and if found, will read this file to get a filename of the binary prop file on the SD card to boot from. If this file is not found, or autoexec.at is not found, then the program will read the file BOOTPROP.BIN on the SD card and boot from this. If this file is not found either, the program stops.

My OS program on the SD card can determine a number of different hardware types (a standard prop board, or one of RamBlade, TriBlade, RamBlade3 - I can tell my different boards from pullups on different pins).

However, what I cannot tell is the xtal frequency (5MHz, 6MHz, 6.5MHz and occasionally 13.5MHz) because I often change these (they are socketed).

Once the OS is loaded, I can call various OS commands. These are all modules which use a now resident set of routines and mailboxes to communicate. Currently, I have to recompile all the OS for different clock frequencies, but I don't need to do this for the various hardware. So I am thinking of changing my loader to keep the existing clock frequency and mode.

My OS can also reload any prop binary, and that binary can return to the OS by a prop reboot. (eg I can boot ZiCog/CPM and a HALT command will reboot the prop).

The Problem and Possible Solution(s)...

I want to be able to produce prop binaries that do not require recompiling. But they may be used on hardware with different clock frequencies and modes.

1. Modify the loader to keep the existing clock frequency and mode.
   • Add an OS program to change the EEPROM boot program clock frequency and mode bytes on the eeprom.
   • Alternately, read a file on the SD to obtain the clock frequency and mode.

BTW IIRC Spinix keeps the existing clock frequency and mode from the first loaded program.

Does anyone have any other suggestions?

Bill Henning

Add a long at a known location (hub or eeprom) that contains the multiplier and clock frequency,

sysclk    long    16 << 26 + 6250000

This would allow a six bit multiplier value (leaving headroom for a Prop3) and base clock frequencies up to 64MHz+change.

Dave Hein

The first time you boot up you could run in the RCFAST mode, and prompt the user to enter the clock configuration. You could then write this back to EEPROM so you wouldn't need to ask any more.

Spinix requires re-building the boot program to change the clock configuration. Any program that is run under spinix will run at the clock frequency set by the boot program.

Cluso99

I change the xtals frequently, but I can work around this.

I suspect normal users do not change the xtals. Anyone care to comment???

It is easy enough to rewrite the first 5 eeprom locations of the boot code with a new clkfreq and mode. That way the boot code would know, and all other program loads could skip over these locations during a load.

In RCFAST mode, the program would need to time the baud first???

I am just looking to see if there are other easy ways of doing this that could be standard.

jazzed

You could have a properties file for settings. EEPROM seems to be the optimal place for frequency and clock modes though.

Isn't RCFAST and RCSLOW too imprecise for baud serial IO, so why bother? Maybe I missed the point.

Mike Green

@Cluso99,
This has come up at least once before. The problem is that there's no minimum hardware that includes some kind of time standard. The minimum hardware would normally include an EEPROM and sometimes a serial connection to a PC. The serial connection might be absent if you're using some kind of display and keyboard / keypad and it might be absent with a device that doesn't communicate with a user. You could store the clock frequency in EEPROM somewhere other than the 1st 32K, but you might have changed the crystal since the EEPROM was written last. On the Prop 2, the internal RC oscillator might be able to be calibrated well enough and a "hint" stored in a few bits of the fused PROM that would get you close enough to figure the crystal frequency to the nearest MHz or 0.5 MHz or so, but I don't know what to do with the Prop 1

Dave Hein

jazzed wrote: »

Isn't RCFAST and RCSLOW too imprecise for baud serial IO, so why bother? Maybe I missed the point.

The boot program could perform an auto-baud measurement to determine the bit-time. The user would just have to type a character that contains a 1 in the least significant bit, such as "A" so that the width of the start bit could be measured. I believe the Prop's internal boot code does some form of auto-baud measurement at startup.

jazzed

Dave Hein wrote: »

The boot program could perform an auto-baud measurement to determine the bit-time. The user would just have to type a character that contains a 1 in the least significant bit, such as "A" so that the width of the start bit could be measured. I believe the Prop's internal boot code does some form of auto-baud measurement at startup.

Yes, the boot code does crude auto-bauding, but a loader byte is not 8 bits. A single 4 "byte" packet is actually 21 bytes with the 4 bytes encoded. That allows for the slop inherent in the RCFAST mode. The entire protocol is fairly interesting. I've never seen an RCFAST propeller that could do even a slow bit per bit baud rate precisely.

Dave Hein

Async communications only requires enough accuracy to stay within a half-bit time window from the start bit to the stop bit since it resyncs at the falling edge of each start bit. So with the start, stop and data bits the accuracy has to be with 0.5/10 = 5%. The manual says that RCFAST can range from 8 to 20 MHz, which is much more than 5%. However, the clock rate should be fairly stable over short periods of time.

prof_braino

So, is this in finished stand alone boards, or can we assume you will always be connected to an external device, say a terminal of some kind?

If connected to a terminal, you could just step through different setting and output "hit enter" until the terminal displays "hit enter" and the app sees a proper CR-LF. If you only use a couple, like 9600 and 57600, and you only have four valid crystals, it should only take a few seconds.

Dave Hein

Here's a quick and dirty autobaud program. After the program boots just hit enter, or any key that has a 1 in the LSB. With my terminal set at a baud rate of 115,200 I measure a baud rate of 105,263 on my Prop when running with RCFAST. That just means that my Prop is running at 13.1 MHz instead of 12 MHz.

Dave Hein

Here's a modified version of the autobaud program that loops. I found that it fails above 115,200. A more precise measurement that works above 115,200 would need to use a counter.

Cluso99

Autobaud certainly would work and thanks for the code. I have done this many times before. My 1-pin tv/kbd drivers autobaud for the ps2 keyboard because the speed varies between keyboards. Once found, I can write this away.

IMHO 115,200 baud is fine for a max, at least for this section.

Humanoido

Dave Hein wrote: »

Here's a quick and dirty autobaud program. After the program boots just hit enter, or any key that has a 1 in the LSB. With my terminal set at a baud rate of 115,200 I measure a baud rate of 105,263 on my Prop when running with RCFAST. That just means that my Prop is running at 13.1 MHz instead of 12 MHz.

Thank you for this very nice little program. I get 116,504 baud. How are you converting this to MHz? How to add a statement in the program to also display MHz? This is very useful!

Regarding the accuracy limit of the program, has this prop chip already exceeded that limit? Thanks for your reply.

Dave Hein

If you know that the real baud rate is 115,200 you can compute your actual system clock frequency by multiplying 12 MHz times 115200/Measured_Baudrate.

The problem is that at 12 MHz and 230,400 baud there are only 52 clock cycles in a bit time. So the measurement accuracy is now down to 2%. This appears to be enough to mess up the serial timing, even though I think it should work up to a 5% clock error. If you run the autobaud program at 80 MHz it can go up to 1 Megabaud.

jazzed

Good work Dave. Thanks for taking time to do it and explaining what I missed.

So it seems to be a matter of accuracy of the internal crystal for the propeller population more than precision of the individual propeller's frequency. Does the precision change much over a temperature range? That is, will adding more device load to propeller pins (which causes the chip to warm up) change the measured frequency?

prof_braino

You guys rock!

Dave Hein

jazzed wrote: »

Does the precision change much over a temperature range? That is, will adding more device load to propeller pins (which causes the chip to warm up) change the measured frequency?

When I first turned on my C3 board it reported baud rates of 103.4 and 104.3 kbaud with about a 50/50 ratio. I checked it again after being on for a few hours, and was reporting 104.3 kbaud most of the time, with an occasional measurement of 105.3 kbaud. I stuck it in an insulated box for an hour, which caused it to warm up a bit. Under this condition it measured 105.3 kbaud most of the time.

Then I stuck it in a small ice chest I use to carry my lunch with a Blue Ice pack. After a few minutes it's now printing 101.7 and 102.6 kbaud. So it appears that the RC clock runs faster at colder temperatures. I would have thought it would be the other way around.

EDIT: After a few more minutes with the Blue Ice it's down to 100.0 kbaud.

EDIT2: After a few more minutes with the Blue Ice it's down to 99.2 kbaud. I checked the Prop Data Sheet, and there's a graph in section 10.1 that shows the RCFAST frequency as a function of temperature. It verifies that the frequency does decrease with increasing temperature.

Cluso99

Steve, it is not the accuracy of the xtal, but rather the accuracy of the prop in its execution. The prop can only determine the accuracy of the bit time to an individual clock cycle.

If you have the prop performing a waitpxx then at some time after the input changes (goes low for the start bit) the prop will continue from this waitpxx instruction. This can be up to almost (say 99%) of a clock width. So, at 80MHz this is 12.5ns. Now you do the opposite waitpxx waiting for the end of the start bit (ie first data bit, presuming it is going to be a "1"). Now this can also be almost up to a clock width. But, if the bit changed just prior to sampling, then between the first and second edges you may have incorrectly counted +/- one clock pulse. This is fine with slow baud, but not for fast ones because +/-12.5ns makes a difference.

A diagram would be better but no time to do this. Perhaps there is an article on the web that explains it better.

jazzed

Thanks for running those experiments Dave. Do you have a hair dryer or heat gun?

Dave Hein

I don't have one handy right now, but I'll leave it up to someone else to torture their Prop with a heat gun. BTW, I checked the Prop one last time before taking it off the Blue Ice and it measured 96.7 kbaud. So that corresponds to a system clock value of 14.3 MHz when cold, and 13.1 MHz when it was at its warmest.

jazzed

Dave Hein wrote: »

I don't have one handy right now, but I'll leave it up to someone else to torture their Prop with a heat gun. BTW, I checked the Prop one last time before taking it off the Blue Ice and it measured 96.7 kbaud. So that corresponds to a system clock value of 14.3 MHz when cold, and 13.1 MHz when it was at its warmest.

Would be nice to repeat experiments and maybe add more data. Maybe someone has access to an environmental chamber.

Sapieha

Hi Cluso.

I don't found what thread You used for question about CPM HD sizes so I post in this one.

Maybe that can help You. Read description in CBIOOS.asm