DIY Tiny OLED I2C full graphics controller

What is this, a controller for ants?

[www.youtube.com]

I did some follow up on Chri's idea of positioning the rotary encoder horizontally on the side instead of vertically on the front...

The first problem to tackle was the horizontal mounting of the encoder. Even though it's possible to buy encoders which are made for this type of mounting, these are not easy to find and I also already still have a good number of vertical ones... So I decided to convert the vertical encoder to become horizontal with tiny 10x14mm PCB and a straight 4-pin header:


Then I adapted the PCB for the horizontal encoder. At the same time I also removed the protection diode of the buzzer, as I realized that these buzzers are not piezo buzzers, but a "active magnetic" buzzer, i.e. an oscillator with a small speaker. I also added the possibility for an optional resistor in series with the buzzer, in case it buzzes too loud or draws too much current.


Here the resulting electronics


and the "finished" tinyOLED display controller (I will eventually publish the frame on thingiverse, but my SCAD file still needs some tidying up)


I really think that Chri's idea makes much sense: it's more intuitive to use, smaller to implement and also (in my case at least) the encoder pushing force is better absorbed by the frame.

Thanks, Chri, for your excellent idea!

PS: The only thing that is still irritating me is changing the feed rate on the status screen: turning up will decrease the feed rate and turning down will increase it I'll probably change that in my copy of Marlin...

Edited 2 time(s). Last edit at 05/06/2015 02:18AM by enif.

Quote
enif
I did some follow up on Chri's idea of positioning the rotary encoder horizontally on the side instead of vertically on the front...

The first problem to tackle was the horizontal mounting of the encoder. Even though it's possible to buy encoders which are made for this type of mounting, these are not easy to find and I also already still have a good number of vertical ones... So I decided to convert the vertical encoder to become horizontal with tiny 10x14mm PCB and a straight 4-pin header:

Then I adapted the PCB for the horizontal encoder. At the same time I also removed the protection diode of the buzzer, as I realized that these buzzers are not piezo buzzers, but a "active magnetic" buzzer, i.e. an oscillator with a small speaker. I also added the possibility for an optional resistor in series with the buzzer, in case it buzzes too loud or draws too much current.

Here the resulting electronics

and the "finished" tinyOLED display controller (I will eventually publish the frame on thingiverse, but my SCAD file still needs some tidying up)

I really think that Chri's idea makes much sense: it's more intuitive to use, smaller to implement and also (in my case at least) the encoder pushing force is better absorbed by the frame.

Thanks, Chri, for your excellent idea!

PS: The only thing that is still irritating me is changing the feed rate on the status screen: turning up will decrease the feed rate and turning down will increase it I'll probably change that in my copy of Marlin...

Is that not a setting in Pins.h?

Quote
enif
The first problem to tackle was the horizontal mounting of the encoder. Even though it's possible to buy encoders which are made for this type of mounting, these are not easy to find and I also already still have a good number of vertical ones...

They aren't THAT hard to find: right angle rotary encoders with detent and built in switch

If someone needs to buy the encoder anyways, might as well get the right one from the start. It'll require tweaking the circuit board though.

Wow thats a fast release , cool
I never tought that a encoder would be so large compaired to the rest of the LCD

Although i think a original vertical encoder would be better for longtherm stability as it would have a square soldered footprinted compaired to the modified normal that only has a "line" soldering.

I hope to also can make one soon, just have to find a source to make the pcb ^^"

Chri

---

[chrisu02.wordpress.com] Quadmax Intel Delid Tools

Quote
Chri
I never tought that a encoder would be so large compaired to the rest of the LCD

And I already cut off 5mm of the encoder shaft, otherwise the knob would be even longer...

Quote
Chri
Although i think a original vertical encoder would be better for longtherm stability as it would have a square soldered footprinted compaired to the modified normal that only has a "line" soldering.
Chri

Note that there is also the (bent out) lower case ground pin which can be soldered to the PCB below the encoder case (that's the large pin on the PCB in the center of the encoder), so stability is not really an issue. Also, note that the screw nut on the encoder thread tightened to the display frame should itself give enough stability. Note that actually I ended up not soldering the case ground pin and just use the screw nut for securing the encoder, this made is easier to insert the finished PCB into the frame, allowing to slightly bend up the encoder while inserting it...

I agree that using a commercial "right angle" encoder would be cleaner. However, the solution I now use has a total height above PCB of only 12mm, which is just 1mm below the OLED display surface. The commercial ones I saw so far were all at least 2mm higher.

enif, how do I open your files? I don0t have SW that recognize .patch file.

Quote
3dMistery
enif, how do I open your files? I don0t have SW that recognize .patch file.

It's just a simple text file which contains the differences as lines marked with + and - . Under Unix there is a utility called patch which can be used to apply the patch, but since it's only a few lines, you can just as well do it manually.

Ok, so I must add + lines and it will be ok?

Yes ... and remove "-" lines - but I don't think that there are any in this patch!

I still have problems-it's not clear where to copy, what to copy and what to replace.

It's really confusing.

Quote
3dMistery
I still have problems-it's not clear where to copy, what to copy and what to replace.

It's really confusing.

[en.wikipedia.org]

The SCAD and STL files for the 0.96" and 1.3" versions of the TinyOLED with the side mounted rotary encoder are now on thingiverse.

Quote
xoan

Quote
3dMistery
I still have problems-it's not clear where to copy, what to copy and what to replace.

It's really confusing.

[en.wikipedia.org]

Can't do anything with that.

There is NO Windows program that can do that patching.

I need pre-configured Marlin or detailed explanation about this changes.

Conditionals.h and pins_RAMPS_13.h are not Marlin-do I need to create those files or what? Also, what are line number that I need to change?

This is the most confusing thing I ever saw.............................

Edited 1 time(s). Last edit at 05/08/2015 01:45PM by 3dMistery.

FYI, those files *are* part of current Marlin, but did not exist in older versions.

- Tim

Quote
tadawson
FYI, those files *are* part of current Marlin, but did not exist in older versions.

- Tim

Thank you very much. I downloaded the lastest version and now it works. Awesome!!!!!

Such an awesome idea, couldn't resist






Great job enif!

Nice! Thanks for posting the photos, Mandrav!

tinyboy x tiny OLED controller

Good Fit mming

anybody here willing to assist how i can wire this to a gen6 board if possible

enif, I have question for you-could this OLED be used in older versions of Marlin and can it be also used with Repetier firmware?

Unfortunately, I don't have any experience with Repetier...

As for older versions of Marlin, I don't think that there should be any problem. I use it with Marlin versions 1.0.2 and 1.0.3. Even older versions should work in principle, but you have to find the right place to make the changes, especially in the old long pins.h.

I have it working with repetier.

Assuming you keep the wiring exactly the same as with Marlin, you need to select "custom lcd" in the configuration (#define FEATURE_CONTROLLER 1) and you also need to edit uiconfig.h. Here's the patch for this:

diff --git a/uiconfig.h b/uiconfig.h
index da02325..1e47611 100644
--- a/../../Repetier-Firmware/Repetier/uiconfig.h
+++ b/uiconfig.h
@@ -110,11 +110,11 @@ What display type do you use?
 // CD Pin:   UI_DISPLAY_RS_PIN
 
 // ST7920 with software SPI
-#define U8GLIB_ST7920
+//#define U8GLIB_ST7920
 // SSD1306 with software SPI
 //#define U8GLIB_SSD1306_SW_SPI
 // SSD1306 over I2C using hardware I2C pins
-//#define U8GLIB_SSD1306_I2C
+#define U8GLIB_SSD1306_I2C
 // For the 8 bit ks0108 display you need to set these pins
 // UI_DISPLAY_D0_PIN,UI_DISPLAY_D1_PIN,UI_DISPLAY_D2_PIN,UI_DISPLAY_D3_PIN,UI_DISPLAY_D4_PIN,UI_DISPLAY_D5_PIN,UI_DISPLAY_D6_PIN,UI_DISPLAY_D7_PIN
 // UI_DISPLAY_ENABLE_PIN,UI_DISPLAY_CS1,UI_DISPLAY_CS2,
@@ -238,7 +238,7 @@ Define the pin
 0 = No keys attached - disables also menu
 1 = Some keys attached
 */
-#define UI_HAS_KEYS 0
+#define UI_HAS_KEYS 1
 
 
 /** \brief Is a back key present.
@@ -246,7 +246,7 @@ Define the pin
 If you have menus enabled, you need a method to leave it. If you have a back key, you can always go one level higher.
 Without a back key, you need to navigate to the back entry in the menu. Setting this value to 1 removes the back entry.
 */
-#define UI_HAS_BACK_KEY 1
+#define UI_HAS_BACK_KEY 0
 
 /* Then you have the next/previous keys more like up/down keys, it may be more intuitive to change the direction you skip through the menus.
 If you set it to true, next will go to previous menu instead of the next menu.
@@ -363,12 +363,13 @@ const int matrixActions[] PROGMEM = UI_MATRIX_ACTIONS;
 
 void uiInitKeys() {
 #if UI_HAS_KEYS!=0
-  //UI_KEYS_INIT_CLICKENCODER_LOW(33,31); // click encoder on pins 47 and 45. Phase is connected with gnd for signals.
-  UI_KEYS_INIT_BUTTON_LOW(4); // push button, connects gnd to pin
-  UI_KEYS_INIT_BUTTON_LOW(5);
-  UI_KEYS_INIT_BUTTON_LOW(6);
-  UI_KEYS_INIT_BUTTON_LOW(11);
-  UI_KEYS_INIT_BUTTON_LOW(42);
+  UI_KEYS_INIT_CLICKENCODER_LOW(33,31); // click encoder on pins 47 and 45. Phase is connected with gnd for signals.
+  UI_KEYS_INIT_BUTTON_LOW(35); // push button, connects gnd to pin
+  //UI_KEYS_INIT_BUTTON_LOW(4); // push button, connects gnd to pin
+  //UI_KEYS_INIT_BUTTON_LOW(5);
+  //UI_KEYS_INIT_BUTTON_LOW(6);
+  //UI_KEYS_INIT_BUTTON_LOW(11);
+  //UI_KEYS_INIT_BUTTON_LOW(42);
 
 //  UI_KEYS_INIT_CLICKENCODER_LOW(47,45); // click encoder on pins 47 and 45. Phase is connected with gnd for signals.
 //  UI_KEYS_INIT_BUTTON_LOW(43); // push button, connects gnd to pin
@@ -378,12 +379,13 @@ void uiInitKeys() {
 void uiCheckKeys(int &action) {
 #if UI_HAS_KEYS!=0
 
- //UI_KEYS_CLICKENCODER_LOW_REV(33,31); // click encoder on pins 47 and 45. Phase is connected with gnd for signals.
- UI_KEYS_BUTTON_LOW(4,UI_ACTION_OK); // push button, connects gnd to pin
- UI_KEYS_BUTTON_LOW(5,UI_ACTION_NEXT); // push button, connects gnd to pin
- UI_KEYS_BUTTON_LOW(6,UI_ACTION_PREVIOUS); // push button, connects gnd to pin
- UI_KEYS_BUTTON_LOW(11,UI_ACTION_BACK); // push button, connects gnd to pin
- UI_KEYS_BUTTON_LOW(42,UI_ACTION_SD_PRINT ); // push button, connects gnd to pin
+ UI_KEYS_CLICKENCODER_LOW_REV(33,31); // click encoder on pins 47 and 45. Phase is connected with gnd for signals.
+ UI_KEYS_BUTTON_LOW(35,UI_ACTION_OK); // push button, connects gnd to pin
+ //UI_KEYS_BUTTON_LOW(4,UI_ACTION_OK); // push button, connects gnd to pin
+ //UI_KEYS_BUTTON_LOW(5,UI_ACTION_NEXT); // push button, connects gnd to pin
+ //UI_KEYS_BUTTON_LOW(6,UI_ACTION_PREVIOUS); // push button, connects gnd to pin
+ //UI_KEYS_BUTTON_LOW(11,UI_ACTION_BACK); // push button, connects gnd to pin
+ //UI_KEYS_BUTTON_LOW(42,UI_ACTION_SD_PRINT ); // push button, connects gnd to pin
 //  UI_KEYS_CLICKENCODER_LOW_REV(47,45); // click encoder on pins 47 and 45. Phase is connected with gnd for signals.
 //  UI_KEYS_BUTTON_LOW(43,UI_ACTION_OK); // push button, connects gnd to pin
 #endif

Just make sure that FEATURE_CONTROLLER is 1 in your Configuration.h.
I don't know if it's some bug in the configurator but initially it would put the wrong value there and it didn't work for me...

Hope this helps.

Nice, I will try that.

Thank you,guys!

I have the oled display here in the spi version, not the i2c version as used in this project.

Since the SD reader is using the spi bus anyways, could I also use the SPI display instead of the i2c?

That should work - at least in theroy But you would need to have one extra signal for the oled's CS, e.g. you could use one of the I2C signals for that, as long as you don't need the I2C for the EEPROM.

Also, check out if your oled module cannot be reconfigured for I2C by modifying some of the resistors on the back. Many modules I saw, allow for both SPI and I2C protocols. So far, I have only used "I2C-only" oleds, so I have not hands-on experiences with these SPI/I2C type oleds ... yet!

enif, I would like to change the board layout in order to use the spi display.

I can´t find the source files.. did you use kicad or eagle?

Yellobello, no I just use the PCB program on Linux. The source is here - but I warn you, it's not professional at all ...

Hi, I have a hard time wiring the SPI display up... no datasheet for the sainsmart display seems to be available.
The connectors are called CS,RST,DC,SCLK,SDIN,GND and 3,3V.

SCLK is the clearest one and does not need any explanation, SDIN seems to be MOSI, CS seems to be SS.
However, I have no clue what RST (Reset ? what does that have to do with SPI?) and DC are. MISO should not be needed, since the display is one-way comms.

And then, marlin-wise what do you guys think I should need to do except changing the pin assignments? I mean, u8glib needs to know that it is to communicate via SPI instead of I2C, or is just changing the pin assignments enough?


Also, changing the display from SPI to I2c seems to be possible by swapping some resistors, but also, I have no clue on how ot do this, lacking any datasheet. Also R2-R5 are on a resistor bank on the SPI module.. so this too is quite difficult.