The FPS number goes up, but is it actually getting any faster?
The code that actually changes the speed is in mbed’s system file, which does not include My_settings.h.
Not sure, I trusted the FPS 
I’ll take a closer look at it.
If in the #defines, the clock counter will speed up and the fps will appear faster. But for OSCT to actually affect the SysClock speed, it has to be given on the build settings
I have a stupid question… would overclocking mess up the RTC time ?
1 Like
Not a stupid question at all
The RTC has its own 32kHz crystal exactly for these kind of reasons. It is independent of the core
1 Like
Maybe another stupid question: are there negative side effects by doing this overclocking? Or are there situations where you definitely would not want to use overclocking?
sd card reading fails sometimes
sometimes there is a little noise on screen
Ah the price of going ludicrous speed.
Doesn’t it have an impact on the produced heat and consequently also on the lifespan of the pokitto?
Or is this effect very limited?
The same core runs at 100Mhz in the LPC M4F dual-core (M4 & M0) chip.
72 Mhz is nothing for modern chips
Ok nothing to worry about then 
1 Like
I don’t fully understand how to do this in Embitz.
Where do you add this _OSCT=2?
In project properties - build settings - defines tab
1 Like
If I go to project properties, there is no such thing as build settings
However there is a Project build options:
And here I do not find the defines tab…
Maybe I should be looking somewhere else?
1 Like
I do see a #defines tab on that screenshot…
1 Like
If I get chance I’ll look into improving the instructions and/or maybe finding a better way than doing it per-project, but I don’t really use EmBitz much anymore (partly because I got fed up with dealing with those build settings menus).
Ok I have found it now… I was a bit confused by the # symbol, thinking that would result in a regular #define
Technically it is a regular define,
but it has to be defined before the compiler even starts for the right library to see it and respond to it.
(Or that’s how I understood it anway.)
Putting it in the #define tab basically makes the IDE pass the right command line option to the compiler to make sure it’s defined at the start of compilation.
I would also add, that when it is given as a compiler argument the scope which is affects is every file the compiler uses
If it is given as a #define inside a file, the pre-compilation #define macro only influences files that directly refer to it
Won’t battery last shorter?
BTW you were right, despite showing higher FPS my programs seem to run at the same speed if I only do the #define. Though with the compile flag it seems to run at the same speed too… can this be tested with the emulator, or is it not affected?
EDIT: Okay I tested it, the emulator looks like not affected at all, runs at the same speed, while actual Pokitto runs faster now (also has some small noise as mentioned, but is okay).
Also when you’re using Makefile, do make -B (rebuild all) when you change it, I think that’s why I though it didn’t work.