Over/Underclocking?

I was just playing around with adding a 'set clock frequency' command on the Espruino Boards.

Thought you might be interested in these figures - they're the idle power consumption of the Pico board.

• Default - 84Mhz - 9.6mA
  
• 42Mhz - 6.8mA
  
• 24Mhz - 5.4mA (but USB is unusable)
  
• 120Mhz - 11.8mA
  
  

It looks like you can overclock it to 120Mhz as-is, so quite a speed boost. And if you have something that requires Espruino idle (eg. Serial data, or PWM) you can half consumption by slowing it down.

So now comes the question... In order to change speed, you have to tweak different multipliers and divisors, which is pretty chip-specific. If I don't expose those then you only have a few choices of clock speed (and only on some boards) because Espruino will try and keep USB working (realistically 120Mhz and 42Mhz are the only frequencies with usable USB though) - but it's easy.

However I could allow you to specify the divisors and multipliers - for example: E.setFreq({m:16, n:384, p:8, q:4}).

This is a bit more painful but we can document a few that work or can put them in a library - and the people that like fiddling with their microcontroller can really fiddle. Nothing to stop you running down to 1Mhz or less if you don't care about USB, or perhaps fiddling with regulator voltages and flash latencies and running it at 168Mhz.

Beautiful!

I vote for exposing the multipliers and divisors, and listing ones that work (or letting it take an integer argument for the common ones?) - That'll be particularly interesting on the upcoming Espruino Cheapo, which as I understand will by default run at a lower clock speed than then Pico or Espruino, and you don't have USB to worry about.

Does it break serial baud rates and stuff like that?

Turbo charged Espruino!

I like that just as I liked my 78 Saab 93, the first turbo charged 'regular' - off the shelf - sedan... at least what it looked from the outside! ...or my CDP 1802 MP/MC.

Espruino manifests itself as incredibly flexibility in clocking, almost like the RCA CDP 1802 from early 1976: ...The RCA 1802 has a static core CMOS design with no minimum clock frequency, so that it can be run at very low 'speeds' and extreme low power... Two chips - the CDP 1802 and a fused diode CMOS ROM - and a crystal and power from a lemon with a rusty nail and piece of copper wire got you going... tell the stories.

Even though conceived as a micro PROCESSOR, it had already incorporated (single chip) micro CONTROLLER capabilities:

• 1 GPO - general purpose output - pin and related instructions.
  
• 4 GPI - general purpose input - pins and related test-and-branch-instructions.
  
  

...'perfect' for video games with 4 way (switching) joy-stick and (mono-chrome) video output. For simple control apps, a minimal system could work without (external) RAM - all living in the general purpose registers - and just an external fused (or hardwired DIODE) ROM to fetch the instructions / code from.

Because its static design, the clock was manually tick-able: educationally excellent to study the states of processor control lines, data lines and address bus lines throughout all cycles of op code / memory fetch, write to I/O and memory...

Guess the applications: space exploration... and it is still in use as a high-reliable MicroProcessor... I liked to play around with it a lot... there was even a Basic Interpreter available to help out with some dynamic language... with automatic garbage collection for string variables and easy programmable for other variables, just as Javascript has. - JavaScript was not there yet, but ancestors like Simula 67 from Oslo, Norway, had already matured and (first modern) Smalltalk 76 and Smalltalk 80 were about to be born at Xerox, Palo Alto, CA: all supporting objects, classes, and lambda calculus, and automatic garbage collection.

I like history repeating itself... but luckily in this domain in a very positive way... with no life loosing wars!

1 Attachment

Actually I think you might be able to single-step the Espruino clock - but you'll be stepping it quite a lot before you see much happen on the pins!

Thanks! The more I think about it, more options makes sense - absolutely nothing stops us making chip-specific modules with useful clock speeds in.

... and the way I'd been calculating the correct clock divisors was quite time consuming as well, so wouldn't have been great for low power stuff.

Changing clock speeds can mess up the baud rate and PWM, but to fix it you just re-initialise them with Serial.setup/etc. However when you set the divisors right, you can start off running the peripherals with a high clock divisor, and can then lower that divisor as you lower the main clock speed, to keep them running at the same speed as before.

Ok, just committed, so you should be able to download one of the Git builds in an hour or so and do the following (on a Pico):

// Do nothing (hopefully!)
E.setClock({M:8, N:336, P:4, Q:7, PCLK1:2, PCLK2:4})
// Halve clock speed to 42Mhz, keeping UART/etc working fine
E.setClock({M:8, N:336, P:8, Q:7, PCLK:1, PCLK2:2})

You can do loads of different stuff, but you'll have to look at the chip's reference manual to get the correct values.

You can also experiment with changing the flash latency with latency. At lower clock speeds you should be able to get away with a latency of 0, which will make the processor a bit more efficient.

The STM32F1 in the original Espruino board is completely different clock-wise, so I haven't included anything for that yet.

VMs everywhere: OS, memory, and now clock... thanks for the 'engenius' work. Next step is built in auto-speed-setting, depending on the sleep - javascript idle - Espruino experiences. Similar to cloud elasticity - expand and shrink capacity on demand - Espruino has an elastic clock or elastic power saving... and I know, over time auto-init of timing based things will 'sneak in' (after all, Espruino 'know' what is currently running of the clock and how it is running of the clock).

Indeed:

absolutely nothing stops us making chip-specific modules with useful xyz feature...

PS: slightly paraphrased.

Regarding:

...but you'll be stepping it quite a lot before you see much happen on the pins!

Triggering a stop by a GPIO and and some external hardware could overcome that - initialization and 'go to the point of interest'. On the other hand no real value to it, because there is none of the bus and control lines externalized for watching... and single-clock-tick-stepping in time driven communication is a mute point... For a clocked communication, it could be interesting, but (external) device constraint may mute it as well.

Just to add, you can get down to 3mA in idle with E.setClock({M:63, N:192, P:8, Q:15}) which is basically the slowest you can go - but USB won't work.

Everything should be ok if you speed it back up though.

...and E.setClock({M:63, N:192, P:8, Q:15}) is equivalent to ???(M?)Hz?

@Gordon - echoing allObject's confusion on what the numbers stand for, you should mention that in the reference doc for that function, or cite the page and link to the document where ST explains it all (this is ST, so "see datasheet" (which is fine with Atmel, since they have one datasheet that contains everything you need to know about a given part) won't cut it)

It'll be documented

System clock = 8Mhz * N / ( M * P )

so

8*192/(63*8) = 3Mhz

But it's in the reference manual under 6.2. Reset and clock control (RCC) for STM32F401xB/C and STM32F401xD/E then Clocks.

The diagram at the start is the interesting bit.