If i got my facts straight the 32u4 runs at a clock rate of 8Mhz while an ancient lower end 286 (used mostly in 80’s PC-s) runs at 6. Have one monster like this at my disposal right now - a finnish Nokia made MikroMikko 3. It’s interesting because in mere 30 years we have gotten more processing power into a damn business card, lol.
*rantend, (also let me now if these kind of discussions are acceptable here. @ekem.)
Even better, (got in on the Arduboy party like few days ago so haven’t learned all the details yet) well the higher end 286 ran at 8Mhz, that means double power in your wallet, not taking a whole desk in your room, lol. Anyway i’ve been also thinking about combining the Arduino lang./C with the Atmel AVR Assembler. I know of older PC titles that did this (combining main language with a corresponding ASM) to speed up the code, make it more efficient (namely id-s Doom). It’s just an idea for now however.
Adding also the fact that NES was like assembly language only (the good old 6502) although i’m not sure how this ties in with the subject at hand now.
Yeah, I’ve been wondering if it would be worth trying to improve performance with assembly. I know the Arduino’s compiler is supposed to be quite efficient, but there are always little hacks to be found.
Yes. Optimization was the word I was looking for. I’m pretty sure performance can be improved in certain situations even on Arduino (must look further into that). Currently i’m working through several of Michael Abrash’s writings on these subjects and this guy knows is assemblys and can make you think completely outside the box, in fact you can’t even see the box from where he’s coming from haha.
It can run at 16MHz, however I’m pretty sure it will be set at 8MHz by default. 16MHz requires a higher voltage which I don’t think the battery can push. You may be able to overclock it to higher than 8MHz without a voltage increase at the expense of battery life and possibly stability.
I also think there will be plenty of room for optimization. Unlike a modern computer, where accessing the hardware directly is not really feasible. It is more than possible here and some interesting optimizations can definitely be made with direct access to the hardware. And if someone can get the screen to use 1bit per pixel that would save a huge amount in RAM.
“And if someone can get the screen to use 1bit per pixel that would save a huge amount in RAM”
I don’t get this statement. The screen is 128x64 pixel that is 8192 pixels that are represented by exactly 1KB. That is what the example game does.
(In fact, the OLED display has its own driver and own memory. What the game does is setup of driver at the beginning and then copying array from SRAM to OLED’s RAM again and again. So if you want save some of leonardo’s ram, just write directly to OLED.
And one note on hand assembly - the ATMEL chip has 32 registers and orthogonal instruction set. That really fits well for C compiler, so don’t expect that your hand assembled code would be significantly faster or smaller. Yes, the Arduboy hw is fixed, you can do some shortcomings that general C lib can’t do because it have to run everywhere but I wonder it is worth of time.
We are at 16mhz!! Dev kit is overlocked when using the coin cell (3.0-2.4 volts) but the final version uses a lipo battery so it’s maybe still slightly overlocked at 4.7.
If you guys get some assembly code running on this bad boy you will seriously be my heroes. I’m not elite enough in the ways of coding to get that done! Will have to come up with some rewards for badass community members
And I can’t really believe you are comparing this to a 286 but hey, why not lol
[quote=“bateske, post:12, topic:84”]
We are at 16mhz!! Dev kit is overlocked when using the coin cell (3.0-2.4 volts) but the final version uses a lipo battery so it’s maybe still slightly overlocked at 4.7.[/quote]
Are you sure you don’t mean 3.7, not 4.7? Every single cell lithium-polymer battery I’ve seen has a nominal output voltage of 3.7V.
If it actually is 3.7V then I wouldn’t overclock it at 16Mhz. You’re just asking for trouble when some users get chips that aren’t very tolerant of overclocking and start complaining about the unit crashing or being flakey. Overclocking is fine for a user to experiment with at their own risk, but not for the design of a standard high volume product. Please stay within the recommendations in the datasheet.
On the other hand, if you actually did mean 4.7V then I hope you’ve included level shifting for the signals going from the CPU to the display (MOSI, CLK, CS, DC, RST). These signals are specified as 3.3V and even driving them at 3.7V is getting close to being above the comfort zone. The voltage from a fully charged 3.7V battery may even be too high.
And what do you do when powering from USB? Do you regulate the overall voltage down to something safe for the display, or do you have level shifters on the signals to the display?
16MHz is meant for when the chip is running at 4.7V. 8MHz is for 2.7V. It’s possible to get 16MHz but it may result in some instability and even crashes. At 1.7V it is set to 2MHz. Potentially usable if we are looking for a longer-lasting battery and applications that are not so demanding.
Also a suggestion to devs, if it is possible, allow us to set custom clock speeds on the fly with relative ease. If we are sitting in a menu it isn’t likely that we would be using a full 8MHz and could clock down. And with testing, at certain stages of the game we may find low CPU usage, so we can change it for those specific points. Just thinking about ways of maximising battery life that’s all.
I got this information from a book and a google search, so I have not tested this. There is a Prescaler.h library for arduino which easily allows you to switch clock speeds from 16MHz, 8MHz, 4MHz, 2Mhz, 1Mhz, 500Khz 250khz, 125khz, 62.5khz with one function call.
“The AVR USB has a system clock prescaler, and the system clock can be divided by setting the “CLKPR – Clock Prescaler Register” on page 37. This feature can be used to decrease the system clock frequency and the power consumption when the requirement for processing power is low. This can be used with all clock source options, and it will affect the clock frequency of the CPU and all synchronous peripherals. clkI/O, clkADC, clkCPU, and clkFLASH are divided by a factor as shown in Table 6-10 on page 37.”
So actually I think that’s a yes. You can divide the clock 1, 2, 4, 8, 16,32, 64, 128, or 256. I’d think the OLED screen uses a lot more power than the CPU though… so I’m not sure it would help significantly to slow the CPU down…
8-12MHz might be more reasonable (for 3.7V) based on the docs. Might require a different external oscillator chip though. Of course after boot we can always slow it down to 8MHz ourselves, provided we can get thru the boot sequence.