Before I embark on a voluminous treatise on the nuances of on-the-fly clock signal modulation I had better think about the potential pitfalls that might arise.
Assuming that a DS1077 Programmable Oscillator is hooked up to a Propeller P8X32A microcontroller so as to have the Propeller take it's external clock directly from the DS1077, is it possible to write code in such a way that the system becomes bricked?
Yes, in certain circumstances. The DS1077 has two enable pins which, if configured correctly, can shut off the outgoing clock pulses from both OUT0 and OUT1 pins. If this happens while the microcontroller is still using the DS1077 as it's clock source, the program will halt completely. In the case of the Propeller, all 8 cogs and the Hub will all cease activity altogether and will therefore be unable to communicate with the rest of the system. The only way to get out of this is to put some simple safeguards in there...
Safeguard 1: Have the Propeller perform it's initialisation code using it's own internal silicon clock. This will ensure that the DS1077 chip will always be contactable after a reset or a power-cycle.
Safeguard 2: Force the DS1077 to be running all the time. This can be done by choosing sensible configuration settings and then tying the two enable pins (CTRL0 and CTRL1) directly to GND.
Safeguard 3: When using I2C to reconfigure the DS1077, always make your microcontroller change over to it's internal oscillator BEFORE starting the I2C sequence. Then allow a sensible amount of time (a couple of microseconds is probably enough) to elapse before switching back to using the external clock source again. This guarantees that your communications with the DS1077 are always glitch-free and reliable.
Something to remember: changing the clock speed of your circuit programmatically requires your microcontroller firmware to be a bit more sophisticated with it's handling of things like fixed duration waits or delays. Waiting 1,000,000 clock cycles at 16KHz will take more than one minute to elapse, whereas waiting 1,000,000 clock cycles at 133MHz will take 7.5 milliseconds! Consequently it is vitally important to remember what clock speed you're running at at any given moment. Again, a fail-safe method of being absolutely sure that you have a known clock rate is to fall back on using your microcontroller's internal oscillator.
Assuming that a DS1077 Programmable Oscillator is hooked up to a Propeller P8X32A microcontroller so as to have the Propeller take it's external clock directly from the DS1077, is it possible to write code in such a way that the system becomes bricked?
Yes, in certain circumstances. The DS1077 has two enable pins which, if configured correctly, can shut off the outgoing clock pulses from both OUT0 and OUT1 pins. If this happens while the microcontroller is still using the DS1077 as it's clock source, the program will halt completely. In the case of the Propeller, all 8 cogs and the Hub will all cease activity altogether and will therefore be unable to communicate with the rest of the system. The only way to get out of this is to put some simple safeguards in there...
Safeguard 1: Have the Propeller perform it's initialisation code using it's own internal silicon clock. This will ensure that the DS1077 chip will always be contactable after a reset or a power-cycle.
Safeguard 2: Force the DS1077 to be running all the time. This can be done by choosing sensible configuration settings and then tying the two enable pins (CTRL0 and CTRL1) directly to GND.
Safeguard 3: When using I2C to reconfigure the DS1077, always make your microcontroller change over to it's internal oscillator BEFORE starting the I2C sequence. Then allow a sensible amount of time (a couple of microseconds is probably enough) to elapse before switching back to using the external clock source again. This guarantees that your communications with the DS1077 are always glitch-free and reliable.
Something to remember: changing the clock speed of your circuit programmatically requires your microcontroller firmware to be a bit more sophisticated with it's handling of things like fixed duration waits or delays. Waiting 1,000,000 clock cycles at 16KHz will take more than one minute to elapse, whereas waiting 1,000,000 clock cycles at 133MHz will take 7.5 milliseconds! Consequently it is vitally important to remember what clock speed you're running at at any given moment. Again, a fail-safe method of being absolutely sure that you have a known clock rate is to fall back on using your microcontroller's internal oscillator.