Pin bank clock rate observation
Humanoido
Posts: 5,770
(just for study) re: Propeller
The internal clock frequency changes based on the pin bank.
Compare pins 8 and then 16 using the program below.
With pin 8, the on time is much shorter.
What can you say about the system counter register (cnt) in each case?
The program (and circuit) are from the PE kit manual, see page 35.
What other clock rate effects can you find?
humanoido
Post Edited (humanoido) : 12/4/2009 6:04:12 PM GMT
The internal clock frequency changes based on the pin bank.
Compare pins 8 and then 16 using the program below.
With pin 8, the on time is much shorter.
What can you say about the system counter register (cnt) in each case?
The program (and circuit) are from the PE kit manual, see page 35.
What other clock rate effects can you find?
humanoido
CON
_CLKMODE = RCFAST ' This mode is fast (12 MHz)
LEDs_START = 0 ' Start of I/O pin group for on/off signals
LEDs_END = 15 ' End of I/O pin group for on/off signals
PUSHBUTTON = 8 ' Pushbutton Input Pin
' PUSHBUTTON = 16 ' Pushbutton Input Pin
PUB ButtonBlinkSpeed ' Main method ' Sends on/off signals approx 1 Hz
dira[noparse][[/noparse]LEDs_START..LEDs_END]~~ ' Set entire pin group to output
repeat ' Endless loop
! outa[noparse][[/noparse]LEDs_START..LEDs_END] ' Change the state of pin group
if ina[noparse][[/noparse]PUSHBUTTON] == 1 ' If pushbutton pressed
waitcnt(clkfreq / 20 + cnt) ' Wait
else ' If pushbutton not pressed
waitcnt(clkfreq / 1 + cnt) ' Wait
Post Edited (humanoido) : 12/4/2009 6:04:12 PM GMT
Comments
and left floating with nothing connected, exactly the same
results are observed -
the two pins remain different in timing consistently. Is there a
rule that is used to determine the frequency and why is
the opposite state different for both pins? What is affecting
the state to change the clock? I may need a much more simple
explanation. Thanks Mike.
You need to change the pins used for PUSHBUTTON to not include pins 0-15 for the reasons I stated. You could use 16 and 24 if you want to use other pin groups.
Floating inputs are indeed affected by other signals nearby on the chip because they're high impedance. They're supposed to work that way. If you want a defined state, you have to provide it. There will be variations in pin thresholds from chip to chip and the signal received by the pin will vary from PCB to PCB, so it's anybody's guess how a particular floating input will react. There are no rules. You have to provide some kind of known state if you want it.
If this is an internal heat difference, it affects two blocks very differently. Is there that much of a dramatic difference in blink rate between the two blocks that internal heat can cause? I am not so convinced that one entire side of the chip would be so affected compared to the other side. There must be something else going on?
The other effect you mentioned, an increase of clock speed based on voltage is confirmed. As the voltage increases, so does the rate of blinking. In this experiment, I used 1.8 to 3.5 volts to observe a change in rate. However, I have kept the voltage constant and regulated when testing the blocks.
Floating or not, I see the same rate within the block.
The circuit provides a known state across the two pin banks. The results are stable and unchanging in each block. The known state is a switch with a pull down arrangement.
Whatever is causing the variance, it is certainly interesting, and, if it is consistent from chip to chip, it could be exploited in some programming techniques. But I think we need to know more about exactly what is happening first...
Post Edited (humanoido) : 12/5/2009 12:22:05 AM GMT
Part of my objections to your characterization of the difference in performance based on pin banks is that there's nothing in the hardware that would account for this behavior. There are differences in signal propagation across the chip and along the DIR/OUT logic chain to the actual I/O pins, but we're talking about nanosecond and subnanosecond differences that are independent of clock speed rather than the several orders of magnitude greater differences you're observing in a Spin program.
The characterization of the difference in the observed results should be accurately represented, and by all means, the information you have provided to rule out hardware is certainly noted and well appreciated.
Is there a way to read the special "push constant" bytecodes (that could lead to developing a quantitative algorithm)?
Where is the byte code of interest that indicates a difference when one pin bank is selected over the over?
PORT = 8 BANK = 1
Post Edited (humanoido) : 12/5/2009 5:02:52 PM GMT
difference in the compiled code. So how does this show there is
a change in compiled byte codes leading to different execution time?
The code gives the same blink rate when changed to any switch in group 1. The blink rate changes when the switch is anywhere in group 2. So I tried all these values, including all the pins in the group (other than 8 and above 16). The examples I gave used a pin from each group.
If it toggles the pin in group 1, it should also toggle the pin in group 2. I don't see how that would give a different observed blinking rate.
Group one has a quick short blink rate while group 2 has a much longer blink rate, i.e. the led on time is much longer.
As far as I know, the LED start and end statements should be the same. It's for LEDs on p0 through p7 which are not moved from one program to the next. The pin that is changed is the pushbutton on p8 to a pushbutton on p16 and you can see this change in the defined statement at the compilation beginning.
Post Edited (humanoido) : 12/6/2009 2:14:28 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
CON _CLKMODE = RCFAST ' This mode is fast (12 MHz) LEDs_START = 0 ' Start of I/O pin group for on/off signals LEDs_END = 7 ' End of I/O pin group for on/off signals PUSHBUTTON = 8 ' Pushbutton Input Pin ' PUSHBUTTON = 16 ' Pushbutton Input Pin PUB ButtonBlinkSpeed ' Main method ' Sends on/off signals approx 1 Hz dira[noparse][[/noparse]LEDs_START..LEDs_END]~~ ' Set entire pin group to output repeat ' Endless loop ! outa[noparse][[/noparse]LEDs_START..LEDs_END] ' Change the state of pin group if ina[noparse][[/noparse]PUSHBUTTON] == 1 ' If pushbutton pressed waitcnt(clkfreq / 20 + cnt) ' Wait else ' If pushbutton not pressed waitcnt(clkfreq / 1 + cnt) ' WaitIf you set dira[noparse][[/noparse]PUSHBUTTON] to 1 (as you were doing initially) your test is _aways_ invalid and broken. Ensure that dira[noparse][[/noparse]PUSHBUTTON] always = 0 and re-run all your tests please.
See added line below.
CON _CLKMODE = RCFAST ' This mode is fast (12 MHz) LEDs_START = 0 ' Start of I/O pin group for on/off signals LEDs_END = 7 ' End of I/O pin group for on/off signals PUSHBUTTON = 8 ' Pushbutton Input Pin ' PUSHBUTTON = 16 ' Pushbutton Input Pin PUB ButtonBlinkSpeed ' Main method ' Sends on/off signals approx 1 Hz dira[noparse][[/noparse]LEDs_START..LEDs_END]~~ ' Set entire pin group to output dira[noparse][[/noparse]PUSHBUTTON]~ repeat ' Endless loop ! outa[noparse][[/noparse]LEDs_START..LEDs_END] ' Change the state of pin group if ina[noparse][[/noparse]PUSHBUTTON] == 1 ' If pushbutton pressed waitcnt(clkfreq / 20 + cnt) ' Wait else ' If pushbutton not pressed waitcnt(clkfreq / 1 + cnt) ' Wait▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
are perfect. The addition of dira[noparse][[/noparse]PUSHBUTTON]~ took care of the anomaly. Thanks for pointing
this out and for providing the working code. It just goes to show that what appears on the surface
is not always the case. Here it was coding that resulted in what appeared to be a variance inside
hardware, clock, from pins on one side of the chip to the other side. Thanks to Mike for making the
state change information clear. But now... I wonder if there is any useful application for speeding
up the apparent rate using the previous program as a technique...