Tested: Display Libraries - Adafruit, u8glib, Homebrew Code
ฝัง
- เผยแพร่เมื่อ 11 ธ.ค. 2014
- Comparison of 3 different techniques for driving an SPI OLED display. The Adafruit SSD1306 library, the u8glib and some code I threw together myself.
github.com/adafruit/Adafruit_...
code.google.com/p/u8glib/
Arduino sketches used in this video:
Adafruit sketch: hastebin.com/awiwiwatas.avrasm
u8glib sketch: hastebin.com/mefuhayega.coffee
Julian's sketch: hastebin.com/irivukulef.coffee
font.h: hastebin.com/wizowutuji.vala (this font file is required by Julian's code and sits in the same folder as the .ino file) - วิทยาศาสตร์และเทคโนโลยี
Very interesting! I mostly use the adafruit library just because I'm use to it but sometime it does take quite the memory. Thanks for sharing!
A (possibly) interesting extension to this experiment would be to use the IIC based display which might be faster. Also, programming the chip directly without the Arduino IDE libraries might be more efficient.
Nice video Julian, I've just ordered one of these displays, hopefully here today. I'm not too concerned about speed but I do prefer the U8G library with its nice big fonts. Thanks for sharing
This is awesome! I am working on an electronic ignition module and the time it takes to write to a display is critical if you want to show information on the fly plus keep accurate ignition timing. I was about to use to micro-controllers to do it but this (at least for now) will work as a solution...up to about 7000rpm anyway. Thanks for sharing :) any hints on how to get the text where you want it would go a long way
Great comparison. Thank You
Thanks for sharing the video! Just to be sure, all three methodes use bitmap fonts, correct?
Very nice video. I have tried both adafruit and u8g libs, and Ada wins in the frame rate. However, ada takes insane amount of dram, which causes code crashes. I need graphics so I cannot use Ascii only ssd1306 lib - I am printing custom fonts for volume level as bitmaps. is there a fast and small library for both fonts and bitmaps?
Hi Julian,
thanks for this video its very helpful for us. i m design laser tag game so i use OLED in gun to show player score name and other things. i test Adafruit Lib. for frame rate but i have a Question i m print a 64x64 PX BMP but its take only 28ms and in your video some only some text are using ~30ms why? ( sorry for grammar mistake English is not my first language )
Great practical demo. Was wondering about smooth animations on these OLEDs, 30FPS or so. The other thing about the u8glib would be the omission of the Adafruit 'greeting' screen that's required to be left in.
You can easily get rid of Adafruit splash screen by removing from Julian's code first display.display() and delay.
when you use static unsigned long can you put register in there?
I have decided to get back into Arduino and building things with displays once more, so I am reviewing your old videos to get back in step. Great stuff here, you are indeed a good teacher, however a question comes to mind. With the Arduino, you pointed out where we could save a bit of memory, however the way the Arduino works, it is difficult to run two programs at once, so saving space is not necessary a good way to write code for it. The memory is there to be used, so unless one is getting to a point where the program is getting near the max, I would use all that is needed, and should the need arise use less, then would be the time to try and cut back. Just and observation.
Thank you for sharing this!
I wonder if we can drive a SPI display with I2C interface?
Nice video, as always! Could you (one day...) make a video where you show your lab or "room"?
I will do that - maybe over Christmas. It is just a junk-filled room though!
Julian Ilett
Don't worry, my room is certainly in a worse shape than yours. Especially because you have your batteries outside, since I cannot put them outside I have them in my room (Of course hydrogen is vented outside) :D
can you use a register int instead of a static long for your timer math you call every refresh What is the difference?
Julian, very nice bit of work.
You might have a look at the SPI bus speed. Of course, efficiency is achieved in simply not having to send data for each and every bitmapped display location versus writing to a small subset, but at the baseline you have display data update delay and of course the processing time to calculate your microsecond value itself (which one hopes is nanoseconds).
would there be a substantial difference with a Arduino Due ( CORTEX M3) ?
Does the greater amount of text printed in the first test (as compared to the second) make the first run slower?
I can't find your code in hastebin any more.... any chance we can have it somewhere else? :) :) :)
This is badass. The Adafruit library is probably the bloatest thing I've seen being used on Arduinos.
I'd be curious if you could do this refresh rate test again with current versions of the libraries to see if they have been optimized to run faster after 6 years.
they are the same yet...
what speed is the spi set to?
I have a library that basically does all the raster ops in memory then only updates the entire screen in a single efficient batch. The best part of this is it's easy to support new devices as the only bit that has to be implemented is getting the memory bitmap -> hardware. It also has the ability to just refresh parts of the screen. As usual the software bitmap and the hardware layout rarely if ever match so usually some bit bashing is required. However it's easier to make the graphicd as simple and as efficient as possible and do the bit bashing on the fly when writing to the hardware. I needed small delays in the sending of the SPI data... so instead of using delays did some calculations in their place which worked perfectly. From the same code I can output to MAX7219 8x8 arrays, various OLED screens and some Nokia LCD screens. This approach also eliminates flickering when updating fields that change.
To solve the frame rate issue is simple. Write a function that sends only bit maps to the display. Create several frame buffers with the dimensions of the display: 128x64 bits. Have another frame buffer that is the "last-shown" one. The paint loop allocates a new frame buffer, zeroes it to black, and then paints what it wants on it. This is sent to the display thread, which compares this new frame buffer with the previous one. It can then send ONLY those lines (8 bit-lines actually), that have changed to the display. It can also determine the LEFT-SIDE and RIGHT-SIDE that has changed and only send that portion of the line that has changed. There are only 8-pages so the loop needs to consider only 8-groups of lines. The amount you transmit over i2c to the display radically is reduced and thus you can drive the display at a very high frame rate. You can also precisely control the frame rate in this way. Say 30 FPS is your desired frame rate, the display thread dequeues the new frame buffer, sends differences to the display, and then waits the remaining time before getting the next frame. If your familiar with how VNC clients work, this is what they do. They only alter that portion of the display that changes -- to save bandwidth. Lastly, you might send the entire display every so often to "fix" any glitches that occur from time to time.
probably wont work the way you think. avr chips are not powerhouses of cpu processing power. your suggestion would also mean that a "non update" gap needs to be skipped over by moving the cursor, which by all means would require new x AND y coordinates, such a move cursor command might be longer bitwise than just sending the data to overwrite identical data. and you also need to figure out which parts are unchanged and which are not which might consume more processor time than just sending all the data without checking.
assembly might be the way to go because a clever assembly programmer can think of things that the compiler dont.
I've already implemented this. The CPU can be say 30 Mhz, and its ability to compare two frame buffers in dram is FAR faster than the slow I2C communication pipe. There is a command you can send to oled to give it a RECTANGLE image. That command has the X start and end, and Y start and end. Its a bounded rectangle. You just send only those portions of the display that is changing. Animation can thus be very fast -- 30 FPS say. I've also tried it with an RGB OLED, 96x64, 16-bit color. Same thing.
If the animation is NOT painting most of the screen most of the time, you can easily keep up.
Julian has got 143 fps. SPI communication is 20 times faster than I2C.
How's the power usage between them?
SRAM usage should also be a consideration.
Adafruits library also supports various other display types. the display.clearDisplay routes etc are all part of AdafruitGFX, they then have a few minor libraries which adapt the GFX library to each additional display type.
Did you test them all with the same exact string? i.e. "library" instead of u8g library
As always, brilliant content. But please don't be too harsh on these libraries, lets remember that they are available for FREE!
I have a screen which I dont remember where I bought it from it oled and I check the label behind screen written 2864KLBE I suppose its 2864 oled but labels on the modules are confusing .. GND, VCC, CLK, MOSI(I know all these ) but DC, CS1, FSO, CS2(dont konw about this) :( what are these pins ??
do you have some example code for xmega avr-gcc?
Here's a super weird issue:
I need to get U8glib working with my display, but it doesn't at all.. Copying the code from your adafruit sketch works perfectly (as do the library's examples), but when I copy the code from your U8glib sketch, nothing happens on the display.
Any idea what's going on here? I didn't change any connections between both attempts..
It is great tutorial Julian, still learning ;)
Could you tell me how to set high brightness by SPI in u8glib library?
I've noticed when I use u8g it is printing code in some kind of grey scale on my OLED,
however your code is high bright and white. Interesting thing is that when I upload u8b code to arduino it is in grey scale on display, but when I upload your code first and then u8g code then u8b is bright and white as well, but after I unplug arduino from usb and plug it again it is in grey scale again, but your code still stays white and bright after this operation.
try the bw version of the u8glib init routine. there is "_gr_" for greyscale, and "_bw_" for black and white.
where I can get upir lib? the links do not work anymore...
I know this is a very old video but I noticed that Julian is using Software SPI with the Adafruit library.
With Hardware SPI I get around 4500.
Good job with "Julian's code" :)
I'm not sure what you would do with a 1000Hz refresh rate... to put it in perspective a typical PC game refreshes at 60Hz, many console games are even 30Hz. A high-end monitor can do 240Hz provided the game can also support it. But I guess you want to have the display code in every loop iteration right? In that case yeah, it would be nice if the refresh was faster - although you can just do it if say, 1/30sec has passed since last time, it is a bit annoying to have the stutter in the rest of the code while the screen is refreshing.
Depending on what you are drawing and the type of screen you are using, sometimes it is quicker to overwrite the existing display with black instead of doing a full screen clear. I made a more permanent version of my mini-oscilloscope using a display that is very slow to do a full screen clear (SKU132034), so I draw the previous line in black instead, before drawing the new line.
I used a slightly modified version of your code to calculate the frames per second, or the screen updates per second to the hundreths place, instead of the microseconds between updates. I got a stable value (showing just this fps number) of 141 fps running on an Arduino Mega (knockoff), and a whopping 205 fps on an UNO!! It makes me wonder what the maximum refresh rate is for these and how much slower the I2C displays are in comparison, or how easy it would be to make a homebrew code for that one too.
And as an update using the GFX libraries to do the same thing, the UNO gets ~72fps and the Mega gets ~61fps. using a library makes it easier but really shows the extra workload required
Are you using the standard clock speed setting for SPI? You should be able to bump up the SPI speed by quite a bit.
I think this display can be driven up to 6Mhz SPI, according to the SPEC. BUT, most microcontrollers are not that fast. You have to consider how many cycles, per-byte, the micro-controller can handle. So if CPU is 32Mhz, for example, you probably shouldn't attempt more the 2Mhz SPI, leaving only 16-cycles per byte which is not much.
julian -
i don't want to be stupid about this, but i am having trouble getting your homebrew sketch to run. it hangs up looking for the font.h
i went to the hastebin and found the .vala file, and saved it as a .txt file called wizowutuji.vala
you say to put it with the .ino file. but that is also a problem. is the .ino file in the sketch folder or appdata or where. i pasted the file in all over the place and it still can't find it.
a little help please.
Thanks for sharing.
What about RAM usage for the bitmap buffer? I heard the Adafruit one was 4 times larger than the u8glib which might be an issue on micro-controllers with limited memory.
Arduino is not the only microcontroller in the universe. If your application requires more memory, by a board that supports more memory.
what about the Global variables used in each library?
The Adafruit library is not terribly optimized and has a 'bug' in it that causes a huge loss in framerate. In the SPI write function, there is a delaymicroseconds(). This seems to be there for compatibility, perhaps when running the library on the DUE or a Teensy 3.0, it spits the data out too fast for some displays. But on the 16MHz Uno, it doesn't seem to be required and you can more than double the frame rate by removing that line.
Very useful! Thank you.
nice videos, if possible can you do something on CANBus?
The adafruit library has a hardware SPI mode which is faster. Also for u8glib there is a library for creating user interfaces called m2tklib.
Oh yes, that m2tklib looks very nice. An even more compelling reason to switch to u8glib.
wow, that m2tklib is awesome! Almost makes me want to create a project just to use it :D
I'm not familiar with Arduino but I think they use a Hardware abstraction layer so is easier for the user to make a simple application but with impact on performance.
If you are interested in performance and code size then using Arduino is not the best choice. (But not sure since like I mentioned I have no experience with Arduino).
I started with z80 CPU not microcontroller in the last years at university programing in assembly. Then I designed my own development board based on AVR and I was still programing in assembly. Assembly seemed simpler for me since was much closer to HW. I new exactly what will happen when I wrote a code but for complex stuff it took to much time so when I recently started working with ARM cortex I decided to start programing in C. That is less transparent but I can do more complex code faster and easier.
As microcontrollers are more and more powerful and have more memory you can switch to higher level programing since you will not care so much about code optimization.
When I started with the SBMS I chose an ARM cortex M0 from ST and at that time in that family the high end part had 64k of program memory and 8k RAM but decided to start with the 32k Flash and if I could fit all in 16k I will get that part for a few cent less.
I started with the LCD library and some of the menu code and things looked good.
As soon as I implemented some of the ST libraries like the touch capacitive buttons I started to realize that I will need the 64k Flash for sure.
The code was already around 47 or 48k Flash and I was not sure if I will be able to optimize the code to make space for the FAT file system to ad SD card capabilities.
Just at that time the ST released a 128k Flash and 16k RAM micro in the same family so I switch to that not to spend time in optimizing the code for size. I need maybe 100pcs and each was 50 or 60 cent more I think so for 60$ is not worth spending time on the code optimization.
Now the code is close to 80k still some space left but with many new futures in next SBMS version I may exceed 128k. Not a problem since ST just released a 256k version with 32k of RAM not sure about the price since is not available for sale but it will be soon enough and is not important even if is 1$ more considering the small volume 100 or 200 units is just not enough to justify spending hundreds of hour to optimize the code for size for just 100 or 200$.
I went overboard with this replay :) The idea is that technology advance is so fast and we are so slow at developing a product even in a large team that it makes no sense to worry to much about the size of the code or even the speed that code is run at.
The dtostrf gives you a formatted sting. To align it left, you are in fact trimming the text which is in that tmp variable. If there is a trim function, you might get it to budge to the left.
Note I have no knowledge of the Arduino language, this is just common sense and other programming skills applied.
You beat me to it - assumed he was printing a few spaces infront of the numbers - right justified.
Nice :) What transferspeed can the display handle?
Well, fast, very fast. The SSD1306 datasheet has all the timing diagrams. Fast enough to keep up with Arduino digital outputs being waggled up and down at the maximum rate.
Fast yes, but I find there are glitches in the display if you attempt to go TOO fast relative to what your microcontroller can handle. You also have to know if your i2c hardware has a FIFO, and what depth that FIFO is. A deep fifo frees up the microcontroller to do other things.
Very useful!
interesting. Anyway i want to ask you what is the pinout difference between this model 7 pins and the other with comes 4 pins.
you didn't show pinout of this model...
Valerio Guagnelli Scanzani in particular i'd like to know if I can run this type with just 4 pin, like the other
+Valerio Guagnelli Scanzani I have the 4 pin one, it uses I2C not SPI
Have a look at the SPI speed...
I2C is slow but SPI can be very fast.
Using an MCU that can do DMA and getting the DMA to feed the SPI for the data transfer also means it can happen in background while you do other stuff.
Great comparative. Is your super fast code available for us noobs?
Hey the codes are in the comment i think
So where is the bottleneck? The uc does not send the data fast enough or the display takes its time to display the data? If so what is the maximum frequency of the display?
i2c has two speeds. 100Mbps or 400Mbps. The latter is so called "fast" mode. You can work out, with some math, how many pixels you can send at these two speeds. The TRICK, in driving these displays fast is to have software that doesn't send the entire frame each time. Rather, send only what is changing. If you go to a SPI interface, you can drive it much faster, such as 2Mbps.
Any chance of doing an update to this showing how much SRAM is being used by each sketch? I'm having issues getting my 'Arduino PRo Mini, SD Card data logging, GPS with OLED' up and running because of the 2k SRAM limit of my pro mini. Any advice warmly welcomed.
Jimmy Stoba Just realised there were links to the sketches above (DOH!). I've compiled them all and they use 1357, 258 and 39 bytes of SRAM as global variables respectively.
Brilliant subbed!
Any way to draw like a simple rectangle fast? Or is this just and only text? Not even single pixels?
Yes. Draw the pixels in memory first ... then transmit ONLY that portion of the display that is changing using the command to send bit maps. That command wants min-X, max-X, min-Y, max-Y coordinates, with the bit map following. The display will bit that bit map @ the correct place on the screen.
Sketches links are dead.
How you connect this oled?
There's a modified adafruit library which runs with HARDWARE SPI - a lot faster. Adafruit standard library uses a bit banging.
+vmeansvelocity, works nicely! Now Adafruit does 9.1ms in Julian's test. Or 4 times as fast as it used to be!
That number was left-most but was just accounting for how big the number could be.
Hi Julian. Your "botched" code cannot be very optimized... I am currently writing a library for these OLED displays using I2C, which (as you probably know) is slower than SPI. I wrote my own version of your test-sketch and with a clrScr() in each loop I get 4.373ms. Without the clrScr() I am down to 3.998ms (and the number is overwritten each time). My test-sketch also includes averaging of the time which also adds a few ms per loop.
The library is not quite ready for release yet but it shouldn't be too long. Please let me know if you want to test it.
Oh... And the compiled test-sketch is around 6.6kB. I am using an Arduino Mega2560 for these tests.
The library will support Arduino Uno/Mega, Arduino Due, several chipKit boards and possibly more.
+Rinky-Dink Electronics, did you release the library?
+Андрій Макуха The library was released on March 1st 2015... You can find it on my website.
It is good library (downloaded it, OLED_I2C) and it is the fastest of all. I use it for fast update graphics, to display a VU meter for example. Also make some defines to test different libraries with the same code, such as Adafruit, U8GLib and your library. Adafruit is the biggest in size (but suitable for the task), U8GLib is absolutely unusable for this task, don't use it to display images, it is jerky. U8GLib is second in size. Your library is the winner of all, less size and very usable speed.
The disable interrupts when drawing is a key to succes. However, changed your code allot because it is not compatible with other screen sizes (with the same chip) and the bitmap routine doesn't seems to be (always) compatible with image programs. Coding style is a little ugly and in some ways nasty, it could be optimized, for example duplicated code that do almost the same with a little change. I believe you 'copied' the good things of the Adafruit library for your needs with your own twist. This is not bad but your CC-license.... stupid. I think Adafruit does a better job on this.
I will share my code some day and it will be free, I don't care about what you think about that. Don't make it open-source if you don't want to make it open-source, use a paywall. The Arduino platform is a good thing to make money but not when others did most of the job, you have to be honest about that. Make the world a better place. Maybe a basic income (or some patrions) will help to make it a better place, it's not just for you, it is for us all, people. Consider that, patrion or other financial injection method to support the improvement. No stupid license to limit or block development/improvement.
Is your homebrew sketch somewhere, the links above don't return anything? Thanks.
The hastebin links still seem to be working
No longer working.
FYI - updating a 128x32 OLED using 8MHz SPI on a pic32mx takes 1.24ms. So I guess your 128x64 should take about 2.5ms to refresh.
muito obrigado
It would be nice to have a word about the pinout.
i've modified your code to run on a stm32 mcu and i get 972-1023!
This pretty much is the same on any type of computer. If you did any kind of graphics programming on 'old' computers like the C64, Amiga, PC (CGA, early VGA). A lof of the performance gains are actually made by reducing the amount of pixels you need to touch. It's a low rez screen, but at the same time it's also a low speed CPU. A lot of the same ole tricks that worked on those old machines are making a come back.
So pruning out the screan clearing is an obvious one. Only draw the pixels you paint. Or if you have to only clear the portion of the screen that's needed instead of the whole screen.
Also... long to string on a 8bit CPU is an expensive conversion. See what speed you get by not doing the long to string, but instead writing the same fixed string each time, that'll prob trim off some of the time as well. (and if yes, there are alternatives to displaying long's (and float/double which are even worse).
Also. if you want the faster "julian" code, but a nicer looking font, that really is just about adding a different bit pattern for the characters (and code to accomodate larger sizes). You can do that without a library as well.
I agree, try printing the same text in background colour to clear it prior to printing you new text rather than using clear display
Why does it need to be super fast, are you aiming at playing Fortnite on it?
Is it just me, or code on hastebin is not available anymore...
Nope, the code is indeed gone..
There is no need to clear te screen. When writing to the display, there is a extra parameter that allows you to set the background color of wat you are writing. I think that clearing the display takes a lot of time.
Hmm .. background color only works with TFT displays. Oled does not seem to have this.
You are telling it to make a 8 character long string, so you get what you ask for. :)
please try spi oled with esp8266 12 arduino.
Although the SSD1306 certainly supports SPI, re-working some of these I2C displays might be too difficult. This is all surface mount stuff and very tiny. A soldering iron is too fat. Your better off just buying the SPI variant of this display. By the way, the 16-bit COLOR RGB OLED, which is 64x96, is very nice.
@@morpher44 Really wish Julian would have posted his code, that would have made development on other platforms much easier.
Rewriting the entire display each time is the problem here. The library should use invalid-rectangles to partially update the display - only the bit that needs updating. Have no idea if the display can handle that. Managing invalid-rects with procedural code (drawText method instead of a text-object) can be tricky but should be doable. When using double buffers a comparison between the current display buffer and the next may also be a way to solve the problem - if you can do that quick enough...
+Marc Jacobi Your first sentence shows a lack of understanding about what is being discussed. Your second sentence confirms this. This isn't about a windows API, it is a library for direct hardware control.
+Tad Pole And that library rewrites everything when it shouldn't have to. That is my point. So your first sentence.... nah, lets not go there.
+Marc Jacobi No no, let's go there. I think the issue is hardware vs software here. You are saying that a solution is to just rewrite part of the screen, because you have done that with a Windows API. You are using software to tell the Operating System that you only want part of the screen re-written. The monitor on your computer is refreshing at a certain rate, and it is reading a screen buffer each time, but only part of that buffer is being re-written by the OS. Yeah, that is more efficient than rewriting the entire buffer. So much for the windows API. HERE there is no operating system. The software is bitcoded and interacts with the hardware directly. There may (or may not) be any sort of buffer on the screen at all.
+Tad Pole Okay. The idea of invalidation is an optimization concept. It has nothing to do with an OS, although you're right, I encountered that in windows for the first time (way back). The display itself (hardware) does not need continuous refreshes. You only need to send it its data once - unless you want to change what is displayed. So that in itself is a buffer. That is the hardware I see no issue. It is the library that insists on sending all the data all the time. However you want to implement it, it will get better when you send only changes. Double buffering might be a little over the top and not the best way to go for a software implementation on "resource impaired" device - granted.
+Marc Jacobi I give up.
Change the 8 in dtostrf to -8 and you'll get a left justified 8character string instead of the default right justified.
Maybe your code already is below 1ms? You have too much other stuff in the loop that takes up time, but is not related to the graphics library ("long" manipulation on an 8bit MCU, reading of the timers [again includes long manipulation], number to string conversion).
For a "raw" timing measurement you should just toggle a pin and read the frequency with an oscilloscope. Of course not that easy, but much more representative. Try
digitalWrite(tPIN, !digitalRead(tPIN));
for example. Direct port manipulation would be even faster, using the PORTx registers.
Generally for debugging purposes everything that changes the timing too much will just lead you in the wrong direction. Serial output is also one of these culprits for example.
sub'd! Great video!
why do you want sub 1 millisecond?
It's more that I was expecting something under a millisecond. That's why I used micros() rather than millis(). I'm just surprised at how slowly this code runs.
Julian Ilett The fastest I've got on these oleds is just over 300Hz or 3ms. And that was using a 96MHz micro with the library hacked to pieces to use the fastest possible SPI.
Julian Ilett
Julian, the code is not a limitation, rather transfer of entire framebuffer using SPI. I2C version of this OLED is even slower, because I2C is slower than SPI. After smart optimization - copying only parts of framebuffer, as you did, it is possible to speed it up significantly.
correct. You only need transmit what is changing on the display. If you keep a copy of previous frame, you can compare it to NEW frame and only send over bit maps of the pages that are changing. There are only 8 pages (8-lines each). You can look for the left-side and right-side of where the page has changed, and only send over that middle portion. A game like pong, for example, has 3 items moving: the ball, two paddles. Everything else on the display, the net, and other graphics, might be FIXED and not changing on the display. So the result is very little being transmitted over i2c to the display. If, however, your animation is TOO complicated, then the frame rate does indeed degrade and you probably want to use this board with SPI instead of I2C. I'm using a 20Mhz, FPGA based microcontrolled, and it can drive a game like pong at 30 FPS easily.
I2C but software based is much faster even than SPI version of this OLED. It can be refreshed even 40-50fps (full frame). Look at my videos - I displayed realtime b&w video clip.
Code links are junk
Even more fantastic improvement?
Recently, I've been playing with Eclipse and the AVR plugin. Naturally, I forfeited the 'luxury' of the Arduino etc. libs. OK, not the same as your test, but using Arduino IDE I loaded 'Blink' (standard-no mods.) . It consumed 1,056 bytes. Trying a rewrite, without the libraries (code below) it consumes...162 bytes!
It *really* shows the value of spending time - and I admit it ain't easy - of getting to grips with a 'decent' ide and letting go of the Arduino Wiring system and using AVR's toolchain. Oh, and don't for goodness sake use WinAVR - far too old (last update in 2010) , xmega processors aren't supported even! Use AVR's toolset, even if it means creating a free Atmel account.
CODE:
/*
* main.c
*
* Created on: 12 Dec 2014
* Author: andy
*/
#include
#include
#include
//#include
/*
* the delay routine is limited to a maximum of 250 ms / clock
*
* This method will call delay 32 times per second,
* providing a one second interval on a 20Mhz clock
*
*/
void delay(int seconds) {
//count how many times we called delay
long i = 0;
//while we still have time to wait
while (i < (seconds * 32)) {
//wait
_delay_ms(250);
//increase the counter by one
i++;
}
}
int main(void) {
while (1) {
/* set PORTB high */
PORTB |= (1
u8glib has much better performance on graphics primitives like line drawing, for some reason all the libraries I've tried have poor performance when it comes to rendering fonts.
Do you know a driver SSD1306 for AVR but not ARDUINO? I dont work with arduino
the adafruit is about 30 ms and the human eye is about 25 ms, well fuck this. I WANT GOOD RESULTS, WHAT THE FUCK IS THIS?
u8g2 ???